Building Information Modelling for Building Control

Renato Filipe Gonçalves Vieira

Thesis to obtain the Master of Science Degree in Information Systems and Computer Engineering

Supervisor: Prof. Doutor Paulo Jorge Fernandes Carreira

Examination Committee Chairperson: Prof. Doutor João António Madeiras Pereira Supervisor: Prof. Doutor Paulo Jorge Fernandes Carreira Member of the Committee: Prof. Doutor Vasco Miguel Moreira Amaral

June 2015 ii “God, grant me the serenity to accept the things I cannot change, The courage to change the things I can, And the wisdom to know the difference.” — Reinhold Niebuhr

iii iv Acknowledgments

Em primeiro lugar, gostaria de expressar a minha eterna gratidao˜ ao meu orientador de mestrado, Professor Paulo Carreira, pelo apoio sem precedentes, pela dedicac¸ao,˜ pelo empenho e a exigencia,ˆ pelas cr´ıticas cheias de forc¸a, pelos elogios e, acima de tudo, por ter acreditado em mim e no meu trabalho. Uma palavra de gratidao˜ ao Professor Vasco Amaral, pela boa vontade com que despendeu de ho- ras para me introduzir a` tematica´ do Model-Driven Engineering, e ao Professor Francisco Regateiro, pela ajuda na iniciac¸ao˜ ao Building Information Modeling. Agradec¸o tambem´ a` minha fam´ılia, a quem dedico este trabalho, em particular a` minha mae˜ Anabela Gonc¸alves, ao meu pai Joao˜ Vieira, a` minha irma˜ Barbara´ Vieira, e a` minha avo´ Maria de Fatima´ Pereira, pela forma com que, na sua uniao,˜ serviram de primeira linha de apoio nos momentos mais trabalhosos, naqueles em que a motivac¸ao˜ faltava, e ao meu avoˆ Mario´ Gonc¸alves, pelas boleias de Taxi´ de e para a faculdade, muitas vezes abrindo mao˜ das suas proprias´ prioridades, para que nao˜ me faltasse nada. A eles devo a pessoa que sou. Aos meus companheiros Pedro Mira Lopes e Pedro Nogueira, que percorreram comigo o caminho da academia, nos seus melhores e piores momentos, nas noitadas, nos projectos, nas boas e mas´ notas, nas gargalhadas e nos olhares apreensivos. Para eles, o meu F-R-A. Aos meus amigos, que nos ultimos´ meses carregaram comigo as minhas frustrac¸oes˜ e alegrias, que me ouviram a falar sempre no mesmo assunto, horas a fio, que me encheram de forc¸a e que me ajudaram no meu trabalho: Diana Pinguicha, Pedro Domingues, Gonc¸alo Almeida, Diogo Anjos e Soraia Martins, entre muitos outros. E a` Taniaˆ Frade, por me ter dado a mao˜ quando mais precisei. Obrigado.

v vi Resumo

Apesar do aparecimento de standards de Building Information Modeling (BIM), nem todas as dimensoes˜ dos edif´ıcios sao˜ suportadas em igual extensao.˜ Um exemplo claro e´ o dom´ınio da automac¸ao,˜ em que os aspectos suportados se resumem somente a` disposic¸ao˜ f´ısica dos aparelhos. Esta abrangenciaˆ e´ claramente insuficiente para permitir a modelac¸ao˜ de cenarios´ de automac¸ao˜ de edif´ıcios. Esta modelac¸ao˜ engloba um conjunto mais alargado e heterogeneo´ de aspectos, sem que seja necessario´ o compromisso precoce com uma tecnologia especifica de automac¸ao.˜ Os standards BIM, como as Industry Foundation Classes (IFC), posicionam-se como candidatos naturais para permitir a modelac¸ao˜ e troca de informac¸ao˜ relativa a` automac¸ao˜ de edif´ıcios. No entanto, a completude com a que o BIM suporta os conceitos relativos a` automac¸ao˜ nunca foi, ate´ agora, analisada com rigor. Este trabalho explora a hipotese´ de extensao˜ do BIM com vista ao suporte de conceitos de automac¸ao˜ de edif´ıcios, propondo uma adenda ao modelo das IFC, baseado numa analise´ da literatura cientifica e tecnica´ relevante. O presente estudo levanta os requisitos de informac¸ao˜ do dom´ınio da automac¸ao˜ de edif´ıcios, encetando uma analise´ da lacuna existente entre estes e os standards BIM como o IFC, propondo um conjunto de novos conceitos, usando tecnicas´ model-driven, dotando as IFC da capaci- dade de transportar dados acerca de cenarios´ de automac¸ao.˜ Esta abordagem e´ validada atraves´ de transformac¸oes˜ ao modelo.

Palavras-chave: Building Information Moodels, Building Automation, Model-Driven Engi- neering

vii viii Abstract

Despite the emergence of Building Information Modeling (BIM) standards, not all dimensions of con- struction are supported to the same extent. Such is the case of the Building Automation (BA) dimension, where only aspects related to mostly physical setup of devices are supported, which are largely insuffi- cient to enable modeling automation scenarios. BA requires modeling a richer set of aspects, still very heterogeneous, without becoming bound to a specific technology upfront. BIM standards such as Indus- try Foundation Classes (IFC) position themselves as natural candidates for modeling and exchanging information regarding BA. However, the extent to which BIM supports automation aspects has never been rigorously analyzed. This work explores the hypothesis of extending BIM to support BA concepts, proposing a new exten- sion to the IFC model, based on an assessment of scientific and technical literature. This study elicits the information requirements of BA and performs a gap analysis with current BIM standards such as IFC, upholding the proposal of a set of new concepts, using model-driven techniques, which enable IFC to exchange automation scenario data. This approach is validated for completeness using model transformations.

Keywords: Building Information Moodels, Building Automation, Model-Driven Engineering

ix x Contents

Acknowledgments...... v Resumo...... vii Abstract...... ix List of Tables...... xv List of Figures...... xvii Glossary...... xx

1 Introduction 1 1.1 Problem Definition...... 3 1.2 Proposed Solution...... 4 1.3 Methodology and Contributions...... 4 1.3.1 Literature and Standards Review...... 5 1.3.2 Review Dimensions...... 5 1.4 Document Organization...... 6

2 Concepts 7 2.1 Building Information Modelling...... 7 2.1.1 BIM Tools, Platforms and Environments...... 8 2.1.2 BIM Schemas...... 8 2.1.3 Model View Definitions...... 8 2.1.4 Exchange Formats...... 9 2.2 Building Automation...... 9 2.2.1 Field Level...... 11 2.2.2 Automation Level...... 11 2.2.3 Management Level...... 12 2.3 Building Automation Services...... 12 2.3.1 Zoning...... 13 2.3.2 Device Groups...... 13 2.3.3 Scheduling...... 13 2.3.4 Events and Alarms...... 14 2.3.5 Scenarios...... 14

xi 2.4 Domain Model...... 14 2.5 Model-Driven Engineering...... 16 2.5.1 Models and Meta-Models...... 17 2.5.2 Model Transformations...... 19 2.5.3 Model-Driven Architecture...... 20

3 Related Work 22 3.1 Building Models...... 22 3.1.1 Industry Foundation Classes...... 22 3.1.2 COBie...... 24 3.1.3 BAMie...... 25 3.2 Automation Models...... 25 3.2.1 EIB/KNX...... 26 3.2.2 LonWorks...... 26 3.2.3 BACNet...... 27 3.3 Management Level Service Frameworks...... 29 3.3.1 oBIX...... 29 3.3.2 OPC UA...... 30 3.4 MDE Platforms and Applications...... 32 3.4.1 Eclipse Modeling Framework...... 33 3.4.2 Epsilon...... 34 3.4.3 BIMServer...... 36 3.5 Discussion...... 36 3.5.1 Completeness Analysis...... 37 3.5.2 Complexity Analysis...... 39 3.5.3 Flexibility Analysis...... 40 3.5.4 Applicability Analysis...... 40 3.5.5 The Role of MDE...... 40

4 Solution 42 4.1 Solution Overview...... 42 4.1.1 EXPRESS...... 43 4.1.2 MDE...... 43 4.1.3 EMF...... 43 4.1.4 IFC compliance...... 44 4.1.5 Abstraction...... 44 4.2 Architecture of the Solution...... 44 4.2.1 IFC structural setting...... 44 4.2.2 Element Realms...... 46 4.2.3 Non-functional Requirements...... 46

xii 4.3 Domain Model...... 47 4.3.1 Base Elements...... 48 4.3.2 Device topology...... 49 4.3.3 Structural Configuration...... 51 4.3.4 Behavioral Configuration...... 52 4.3.5 Relationships...... 55 4.4 Model Transformation...... 55 4.4.1 The Epsilon Transformation Language...... 56 4.4.2 The KNX Ecore model...... 56 4.4.3 IFC to KNX mapping...... 57 4.5 Modeling Methodology and Tools...... 59 4.5.1 Modeling Pipeline...... 59 4.5.2 Transformation Pipeline...... 61

5 Evaluation 62 5.1 Model Evaluation...... 62 5.1.1 Completeness Assessment...... 63 5.1.2 Complexity Assessment...... 63 5.1.3 Flexibility Assessment...... 64 5.1.4 Applicability Assessment...... 64 5.1.5 Discussion...... 64 5.2 Case Study: Sustainability Systems Room...... 65 5.2.1 The Room 1.58...... 65 5.2.2 Base installation...... 66 5.2.3 Room 1.58 IFC4A model...... 67 5.2.4 Generated Installation...... 68 5.2.5 Discussion...... 70

6 Conclusions 71 6.1 Retrospective...... 71 6.2 Lessons Learned...... 72 6.3 Future Work...... 73

Bibliography 81

A Information Models 83 A.1 KNX Ecore Information Model...... 83

B Transformation Rules 85 B.1 IFC4Automation to KNX Transformation Rules...... 85

xiii C Tables 93 C.1 List of Datapoints on Room 1.58...... 93

xiv List of Tables

2.1 BAS aspects information requirements...... 15 2.2 Model requirements...... 18

3.1 Epsilon main constructs...... 34 3.2 Summary and comparative analysis of the studied BA models...... 38 3.3 Evaluation of the BA models regarding Complexity and Flexibility...... 39

4.1 IFC4Automation element list...... 49 4.2 IFC4Automation model contraints...... 51 4.3 Transformation rules summary...... 57

5.1 Room 1.58 group addresses...... 66

C.1 Room 1.58 datapoint list...... 95

xv xvi List of Figures

2.1 Equipment decomposition...... 9 2.2 HVAC split system equipment tree...... 10 2.3 BAS hierarchical levels...... 12 2.4 MDE ecosystem...... 17 2.5 OMG Model-Driven Architecture...... 19 2.6 MDE transformation workflow...... 20

3.1 IFC4 schema layered hierarchy...... 23 3.2 EMF and MDA mapping...... 33 3.3 Architecture of Epsilon...... 35 3.4 Comparison of studied models regarding flexibility, complexity and relative completeness. 38

4.1 Proposed BIM extension...... 43 4.2 IFC typing mechanism...... 45 4.3 Object-ObjectType relationship...... 48 4.4 IFC4Automation information model...... 54 4.5 Solution pipeline...... 60

5.1 Room 1.58 installation schema...... 65 5.2 Room 1.58 IFC4A model...... 67 5.3 Room 1.58 EMF model...... 68 5.4 Room 1.58 blind controller schema...... 69 5.5 Resulting Room 1.58 KNX model...... 70

A.1 KNX Ecore model...... 83

B.1 IFC4Automation to KNX ETL code...... 86 B.2 IFC4Automation to KNX ETL code. (cont.)...... 87 B.3 IFC4Automation to KNX ETL code. (cont.)...... 88 B.4 IFC4Automation to KNX ETL code. (cont.)...... 89 B.5 IFC4Automation to KNX ETL code. (cont.)...... 90 B.6 IFC4Automation to KNX ETL code. (cont.)...... 91

xvii xviii Glossary

AEC/O Architecture, Engineering, Construc- tion/Operation ASHRAE American Society of Heating, Refrigerating and Air-Conditioning Engineers BAMie Building Automation Modeling information ex- change BAS Building Automation System(s) BA Building Automation BIM Building Information Models(ing) CAD Computer Aided Design CAFM Computer Aided Facility Management CAMM Computer Aided Maintenance Management CIM Computer Independent Model CIS/2 CIMSteel Integration Standards v2 COBie Construction Operations Building information exchange DSL Domain-Specific Language DXF Drawing eXchange Format EHS European Home System EIB European Installation Bus EMC Epsilon Model Connectivity EMF Eclipse Modeling Framework EMS Energy Management Systems EOL Epsilon Object Language FM Facility Management GMF Generative Modeling Technology HVAC Heating, Ventilation, and Air Conditioning sys- tem(s) IFC Industry Foundation Classes IGES Initial Graphics Exchange Specification

xix IST-T Instituto Superior Tecnico´ - Taguspark IT Information Technology(ies) M2C Model-to-Code (Transformation) M2M Model-to-Model (Transformation) M2T Model-to-Text (Transformation) MDA Model-Driven Architecture MDE Model-Driven Engineering MOF Meta-Object Facility MVD Model View Definition(s) NIBS National Institute of Building Sciences OCL Object Constraint Language OMG Open Management Group OPC Object Linking and Embedding for Process Control PIM Platform Independent Model PSM Platform Specific Model SOA Service Oriented Architecture(s) UA Unified Architecture UML Unified Modeling Language URI Unified Resource Identifier oBIX open Building eXchange Format

xx Chapter 1

Introduction

Efficient Facility Management (FM) is becoming an increasingly important topic that relies on Infor- mation Technology (IT) to support the achievement of energy and managerial efficiency goals [53], supported by tools such as Computer-Aided Facility Management (CAFM) and Computer-Aided Main- tenance Management (CAMM) as well as tools for Building Automation (BA) and Energy Management Systems (EMS). Ideally, the operation of these tools should be supported by a common representation as Building Information Modeling(BIM) [19,1]. Although some progress has been accomplished in mak- ing CAFM and CAMM applications interoperable with BIM models [89, 12] BA and EMS still lack in terms of integration with BIM. The focus of this work is to establish such connection, proposing an extension that is able to express the requirements of heterogeneous BA, enabling distinct tools to share details regarding the configuration and setup of automation systems through BIM models.

A BAS consists of a network of sensors, actuators and controllers that collect data and manage the operation of a wide span of electric equipment, such as Heating, Ventilation, and Air Conditioning systems (HVAC), or lighting, according to a set of control procedures previously configured. BASs also enable monitoring of equipment and building performance as well as remotely managing electric loads to improve operation and energy efficiency [61, 43]. Information regarding structure and implementation of a BAS—network topology, device configuration, control loops—is very complex to grasp from the documentation delivered to the building manager when the system is installed [79]. Despite the fact that a part of this information is available, the implementation details are frequently not understood by the building owner nor by technical maintenance personnel. In fact, only the vendor can comprehend the entire BAS, making the building owners highly dependent on their contractors whenever they want to modify, commission, or tune the BAS [78]. Ideally, this information should be represented in a BAS- independent way, enabling facility managers to easily contract system alteration, hiring specialists, and using third- party tools or technologies.

BIM supports a more efficient management of facilities since all building information, from design to operation, is contained in a shared digital repository [6]. Thus, a BIM-supported FM is more effective, once the information is promptly available to the applications and more efficient, since it is shared across the building’s peers avoiding losses, replication and incoherence of data [3, 66]. BIM focuses on inte-

1 grating all the data concerning building’s life cycle in one digital single model, providing a cross-entity representation of it, and making it easier for every stakeholder to get involved on each of the Architec- ture, Engineering, Construction and Operation (AEC/O) phases [22, pp. 1]. Nevertheless, this approach is still deeply connected to the structural phases of the building life cycle, such as Architecture, Engi- neering and Construction in sharp contrast with several limitations of the Operational phase, specially in what concerns modeling and sharing information regarding BA elements. The lack of connection between AEC and Operation dimensions is mostly due to two factors. The first has to do with the targeting of efforts to the design phases, where Computer Aided Design (CAD) software vendors play an important role on influencing research and development [33]. The second has to do with the automation information itself, that is of a more volatile nature than information regard- ing other constructive elements (characteristics and arrangement of automation elements are subject to change faster than the constructive elements). Although BIM exchange formats, such as Industry Foundation Classes 4 (IFC)1, already feature constructs for the BA domain, these are only used for delivery of information such as installation instructions or device specification. Efforts are being made for integrating BAS data into BIM’s exchange format, but the information supported by the current BIM standard is limited only to the system structure, like devices and wiring relations, disregarding the logical and operational dimensions, such as control loops, bindings or configuration management [12]. As will be clear later, data regarding BAS in BIM is still largely incomplete to enable interoperability with BAS tools, negatively impacting operation efficiency [41]. Model-Driven Engineering (MDE) provides a non-traditional approach to system development. MDE conceives the domain model as the central concept for developing a system, separating the formal de- scription of the domain from the concrete platforms on which it will be built [20]. In other words, MDE enables the independent specification of the functionality, abstracting from the concrete idiosyncrasies of the target platform on which the system is implemented. This allows the same model to be implemented on several infrastructures, through the specification of mappings between the model and target plat- forms. Since the model specification is independent from specific implementation, and the mappings handle the conversion between platforms, different platforms can interoperate more easily, sharing a common representation [70, 81]. In a practical sense, MDE eases system development due to, amongst others, the following aspects. Firstly, the correctness of the core domain (model) of the system is more easily evaluated since the functionality is isolated from the implementation. Secondly, the generation of implementations under several platforms is semi-automated, saving time. Thirdly, the integration of different platforms is more simple to achieve through the usage of a common, independent model rep- resentation. Finally, the domain is more easily maintainable, since changes are executed in the model and easily propagated through target platforms [45]. Despite being developed as a data exchange format, IFC can be perceived under the light of MDE [30]. Since IFC is an independent model for representing building data, model transformations can be speci- fied, using MDE techniques, in order to map IFC constructs into different platforms such as BA protocols or commissioning tools instead of serving as input for applications which have to conform with its speci-

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

2 fication [37]. Using this approach, further IFC versions can evolve independently of the target platforms, as long as the model transformations remain coherent, thus favoring maintainability. Also, the target platforms can be fed by information contained in IFC models without having to implement IFC specifica- tions.

The convergence between BIM and BA worlds using model-driven techniques opens an array of in- teresting possibilities regarding building efficient operation such as (i) reducing scattering and improving consistency of BA data, (ii) favoring interoperability between BA tools which reduces maintenance costs and finally, (iii) improving the independence of the representation of BA data, eventually leading to alle- viating customer lock-in. Studies have suggested the development of extensions to BIM [89, 63, 80] and also of platforms that integrate information with it for use in applications related to buildings [8,2, 95]. There are also, several initiatives relying on MDE for interacting with BIM [31, 31, 30, 10]. This un- derscores the importance of BIM as interoperable source of data. However, IFC version 4 elements concerning BAS do not fully cover the entire BA domain concerns. In addition, the only tools available for realizing, analyzing and managing BAS are proprietary, and do not support BIM, keeping FM ineffi- cient and locked-in to tool vendors, that are the only ones that can understand the details of Automation Systems and manage their implementation [16]. Interoperability of BA with BIM would, therefore, con- tribute to more efficient building automation.

This work reviews the literature regarding BA modeling standards, analyzing and discussing the limitations of each one, and presents a new BIM-based standard for modeling BA requirements in a vendor-independent manner. Such approach will enable the development of open tools to manage, con- trol, and analyze BA systems. Indeed, the results presented herein are far-reaching as they contribute to alleviating the customer dependency from the vendor that installed the systems. The model extension developed in this work will be validated using a model transformation mechanism, mapping it into the BA protocols studied, in order to prove the completeness and equivalence of the extension, facing the above-mentioned BA protocols.

1.1 Problem Definition

Currently, there is no BIM extension that makes possible to represent the details from automation sys- tems’ sufficient detail, accounting for platform heterogeneity and vendor independence. Our hypothesis is that designing a common, BIM-based, and vendor independent information model for BAS would make easier to develop open tools to manage, control, and analyze this systems, making possible for the market to run on a different way, alleviating the customer dependency from the vendor that installed the system. Having market to run on a more free and competitive manner, it would be much easier to have solutions that minimize the energy consumption and make the building operate in more efficiently. Since the information would be stored in a common digital repository much as BIM, the operational processes regarding BAS management will be much more efficient and flexible.

3 1.2 Proposed Solution

This work aims at developing a BIM extension to support modeling of BAS concepts concerning au- tomation and management levels. In other words, it will be able to model automation systems using a set of constructs regarding its structure—such as devices, bindings, or data points—and to define its configurations—like scenarios, setpoints, or schedules—using information embedded in BIM data mod- els. The developed model will extend IFC with new objects, relations and resources which renders it interoperable with BIM’s information model.

Those constructs will be adequately abstracted in order to enable the creation of generic models, that are interoperable with building automation technologies. For example, BACnet, EIB/KNX or LonWorks. This will be possible using model-driven techniques, which provide tools for developing transformations between the developed model and several target models. The development of one of these translation tools will validate the correctness of our extension.

The modeling extension will be developed using the standard EXPRESS modeling language2, em- ployed in the development of IFC, the standard exchange for BIM and also other industry standards.

For dealing with MDE features, this work will make use of the Eclipse Modeling Framework (EMF) as well as some tools from BIMserver application. The former provides a multitude of tools and facilities for designing and working with model-driven applications. The latter consists of an open-source server application for BIM, which cores on MDE for dealing with IFC format evolution, thus providing a set of tools for reading, writing and processing IFC, and converting it into the EMF formats.

1.3 Methodology and Contributions

The objective of this work is, based on a gap analysis between BAS and BIM, to extend BIM through the definition of new abstractions. This new set of concepts regards a set of aspects concerning BAS configuration. To this aim, it makes a detailed review to current BIM and BAS standards following 4 steps. It starts by making an overview of BIM technology, exposing fundamental concepts behind it. A set of features regarding BAS modeling will also be captured, which are required to express functionality and components that are common to this domain. Secondly, a set of information models supporting BA aspects will be studied, including common BIM standard formats, focusing on their structure and how they address the features previously identified. Thirdly, a gap analysis study is conducted considering a set of metrics regarding completeness, flexibility, complexity and applicability against each BAS level. Fourthly, the solution to the problem is developed by extending IFC model specification with a new set of entities and relationships. Finally, this work is validated by means of a model-to-model transformation between the IFC extension and well known building automation standards.

2http://www.omg.org/spec/EXPRESS/

4 1.3.1 Literature and Standards Review

As stated before, this document undertakes a detailed literature review that is based on the following sources of information:

• Books and review works – Books describing technologies [22] or information models [75] and review works that synthesize knowledge about BAS aspects or technology [43, 86, 87].

• Research literature and case studies – Work concerning technological developments on BIM and BAS, like extensions [93, 89], or interoperability frameworks [3, 66, 95].

• Specifications and documentation – Schematics, technical reports or other type of documentation that describe the structure of an information model [5, 47, 72,4].

• Regulatory documents – Directives, standards, white papers, or other kind of document that in- tends to regulate or specify a set of constrains over a given entity, protocol or system [25].

1.3.2 Review Dimensions

Information models will be analyzed according to distinct dimensions (in Section 3.5). In the following, each dimension is presented including its rationale and enumerating the metrics that are used to evaluate it.

Completeness can be defined as the ability of an information model to express certain features of a problem domain. A given information model covers a particular feature if it has adequate data structures or constructs in its specification to represent that feature. When the model is capa- ble of representing a feature—through a model extension or using an external tool, device, or technique—despite not having any predefined construct, we will consider that the model partially covers that feature. This metric is important for conducting a comparative analysis of information models regarding model completeness. Completeness is used to assess the capability of models to capture the scope of BAS concepts.

Complexity captures the easiness with which a model can be learned and used relative to other models. Models with clear and concise lists of data structures, which can be manipulated with least effort are considered, therefore, the least complex. Less complex models are easier to maintain. The complexity metric assesses the relative cognitive load associated which each information model.

The Complexity dimension is evaluated by combining three metrics. The first metric is the number of entities defined in the model, that measures the effort needed to comprehend it entirely. The second measurement is the depth of the inheritance tree, that captures the effort needed to un- derstand the entity behavior. The last metric aims at distinguishing between models and meta- models. Some of the models are so abstract that they are capable of creating other models— a degree of freedom that is considered more complex due to the added cognitive overload they require.

5 Flexibility refers to the availability of built-in mechanisms in the model that enable its modification and extension. Flexible models are designed considering evolution, hence, the addition of new concepts is foreseen in their structure, and their constructs are prepared to be easily modified and are interoperable with new ones. Flexibility aims at framing each model in terms of its evolution and inter-operation capabilities.

For evaluating Flexibility, the models were checked for three metrics. The first one has to do with the openness of the model specification: models with open specifications tend to be more easily modified since more people have access to the specification, and hence, can contribute to the evolution of the model.The second one has to do with the extensibility features. Some models include features which facilitate extension, making it easier to extend its specification. The last metric evaluates whether the model enables the user to define custom constructs, such as a new entity or relationship type, or even to redefine the existing ones. This feature is important to adapt the model to specific scenarios.

The contributions of this document are as follows:

• An overview on the Building Information Modeling and Building Automation Systems concepts to identify relationships between them.

• A systematic analysis of the several approaches to model BAS considering their strengths and weaknesses, comparing them with each other in the scope of the concepts stated above

• The proposal of a model extension for BIM to model the identified BAS concepts considering the analysis above, using the EXPRESS modeling language, and Model-Driven Engineering tech- niques.

• The evaluation of the model extension, recurring to the development of an application pipeline that uses instances from the model extension and implement the system in different automation platforms, making use of model-to-model transformations.

1.4 Document Organization

This document starts by presenting the fundamental concepts related to BIM and BA. Sections 2.1 and 2.2 detail relevant concepts regarding, among other, zoning, device grouping, data point, sensors, actuators, as well distinct concepts related to BIM. Section3 addresses related work, presenting the relevant research being conducted in the scope of this document, including the description of the most important information models and how they respond to the problem of the building automation modeling. Section4, document ends outlines the solution to the challenge of modeling BA concepts in BIM. Finally, the validation methodology is presented in Section5.

6 Chapter 2

Concepts

This section presents a series of relevant definitions for understanding the problem discussed in this work. Firstly, we are going to describe BIM, making a brief analysis to its motivations and features. Secondly, some concepts regarding BAS will be visited, defining the features that compose its several layers. Thirdly, this work explores the data that characterizes the BAS features, showing what kind of information is worth keeping for describing each one of them. Finally, the most relevant aspects related to Model-Driven Engineering are visited, with special regard to ones that intimately relate to the scope of this works, such as models, meta-models and model-to-model transformations.

2.1 Building Information Modelling

BIM is an open technology for digital building modeling. The National Institute of Building Sciences (NIBS)1 describes BIM as “an improved planning, design, construction, operation, and maintenance process using a standardized machine-readable information model for each facility, new or old, which contains all appropriate information created or gathered about that facility in a format usable by all throughout its life cycle” [67]. The motivation for BIM has sprung from the need to simplify the process of passing the information 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 reducing the complexity inherent to the construction process and making it more agile. BIMs also serve as unified data sources that centralize all relevant building information. A computational model containing the facility’s data enables integration of a wide variety of tools that modify and collect data on the model, enabling several kinds of analysis. One common example is energy simulation [4]. The second aspect of BIM is that digital models may be shared and updated concurrently. Distinct stakeholders can insert, update or delete information from it, contributing to the enrichment of the model. The recurring example is the architect adding sketches of the building, the structural engineer modifying it to comply with engineering requirements, the builder using it to plan the construction phase, and the

1http://www.nibs.org/

7 facilities manager analyzing it to operate the facility properly [95,6, 38]. Finally, the third aspect is that BIM organizes information in a structured way. This contributes to making processes more consistent and also to preserving the information coherence, preventing data quality issues. Moreover, structuring automates the analysis of the models, favoring error traceability. For example, it is possible to query the model to check for collisions between different components or construction errors, like an air duct colliding with the building roof [22, 84, pp. 21-22, 24].

2.1.1 BIM Tools, Platforms and Environments

A multitude of specialized applications are available to handle BIMs. These applications have very dif- ferent purposes, ranging from cost estimation to project planning, and can be classified as BIM tools, platforms and environments. BIM Tools aim at using the building information model for executing spe- cific tasks, such as cost estimation or energy simulation. These tools often produce reports or files to be exported to other applications. Primavera P62 and EnergyPlus 3 are good examples of BIM Tools. BIM Platforms help developing building models. They provide a UI for designing building products, like Revit Architecture4 or ArchiCAD5. Most of these solutions provide features seen on BIM tools such as clash detection. Finally, BIM Environments combine functionality from the two above. They provide pipelines for integrating BIM tools and platforms inside an organization. BIM environments are useful for automating the generation of BIM reports and data sets produced by BIM platforms, and enable collab- oration between stakeholders [22, pp.70-71]. Examples of BIM environments are Autodesk Buzzsaw6 or Bentley Projectwise7.

2.1.2 BIM Schemas

A BIM Schema is a data structure that, in practice, defines the common vocabulary to be used to create building models—a format. While the BIM model describes the information regarding an instance of a building, the BIM Schema defines how each element of the building is described. In practice, a BIM model represents an instance of a building stored according to a given schema. There are two types of BIM schemas, internal and external. An internal BIM Schema designates the representations used inside the environment of a modeling tool. In turn, an external BIM Schema denotes the schema outside BIM applications. It represents a common, application-independent model, used to enable interoperability between applications [17].

2.1.3 Model View Definitions

BIM models contain information about distinct aspects regarding the building, from design to opera- tion, resulting in diverse and large models that are complex to understand and explore. To handle this

2http://www.oracle.com/us/products/applications/primavera/p6 -enterprise-project-portfolio-management/resources/index.html 3http://apps1.eere.energy.gov/buildings/energyplus/energyplus about.cfm 4http://www.autodesk.com/products/revit- family/overview 5http://archicad.com 6http://www.autodesk.com/products/buzzsaw/overview 7http://www.bentley.com/en-US/Products/projectwis e+project+team+collaboration/

8 complexity, Model View Definitions (MVDs) define subset models that are concerned with particular as- pects of the building domain. Therefore, model views define a simpler and more specific set of data for use in data exchange scenarios required by different stakeholders and applications [44, 32]. BIM exchange formats, such as IFC, are provided with a set of these MVD. MVDs define the scope of each exchange scenario ensuring that only the relevant information is passed in the model, excluding a great volume of unimportant information that could also be used erroneously. For example, MVD formats , such as Construction-Operations Building Information Exchange (COBie), aim at solving the problem of handover by representing the information typically required to be delivered from construction to opera- tion [22, pp. 120-122].

2.1.4 Exchange Formats

In order to achieve interoperability between distinct BIM tools and platforms, information must flow in an independent format that can be understood by different applications. Exchange formats are external schemas meant to facilitate the exchange of information between applications with different internal schemas. IFC and COBie are by now commonly accepted as two information exchange formats.

2.2 Building Automation

A BAS connects electrical and mechanical components in a facility enabling them to interact. Typically a BAS is responsible for managing HVAC, lighting, among other aspects and possibly interacting with other systems, such as access control and fire safety [43]. A large number of concepts have to be analyzed in order to support BA aspects in BIM. With respect to the conceptualization of a BAS, it is important to define upfront the difference between the concepts of equipment and control device. This distinction is as follows:

Equipment stands for a part of, or an entire electrical or mechanical system, that interacts with the

Exposes Equipment 1..* Reading Sensor Datapoint

1..* Writing Actuator Datapoint

Sub-Equipment 1..* R/W Meter Datapoint

1..* R/W Controller Datapoint

Devices

Figure 2.1: Decomposition of an equipment in smaller equipment or control devices. Each control device exposes one or more datapoints in the BAS network.

9 building environment, namely HVAC systems, electrical blinds, or luminaries. Equipement can be atomic, or composed of simpler equipment. This composition is depicted in the Figure 2.1.

Control devices consist of equipment with logical behavior in a BAS control network. Sensors, actua- tors, meters, controllers, or gateways are examples of control devices. They can sense, act and execute logic on the environment directly or on another equipment, for example, a sensor detecting movement on a given room or a dimmer controlling the output of a luminary.

Control devices and equipment in general can be arranged in several ways. For example, there are devices that connect externally to another equipment, as is the case of external on/off actuators, while others are part of a complex equipment, such as a fan controller inside an HVAC module. Figure 2.2 illustrates this idea.

HVAC

Termostat ON/OFF

ON/OFF Datapoint

Legend Controller Fan Temperature Equipment

Device Setpoint Speed Temperature Datapoint Datapoint Datapoint Exposed Datapoint

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

One BAS can be organized according to three levels: the Field level, the Automation level, and the Management level. The field level consists of equipment that interacts with the building environment, as well as the control devices. Automation level consists of controllers responsible for orchestrating other control devices, according to predefined control-loops, and collecting the data produced. Management Level receives information from controllers and manages their configuration. Management Level also unifies an interface for manual management tasks such as system state monitoring, event logging, manual variable configuration, access to historical data, or alarm notifications. [28, 43, 29].

10 The next subsections explore the concepts related to each one of these levels, detailing how they relate with each other to enable an informed and systematic analysis of how information regarding each level is supported in BIM (in Section3). The organization of these levels is depicted by the Figure 2.3.

2.2.1 Field Level

At the Field level, equipment and control devices (sensors, meters, controllers and actuators) are con- nected physically through a wiring scheme. Equipment and control devices are often connected in a way where several equipment can be controlled by one or many control devices, enabling hardware grouping [29]. Every equipment, including the control devices, have an equipment specification, in other words, a description of its properties such as classification, physical characteristics, electrical speci- fications or installation instructions. Another important notion is the one of location that refers to the localization and placement of each equipment in the infrastructure. This location can be fixed or variable depending on the type of equipment.

It is also worth highlighting the behavioral relation that control devices have with spaces. The Influ- ence zone denotes the area that influences or is influenced by a control device. For example, this could be a room in case of some HVAC actuator, or a measuring range in case of a sensor device. Control devices can also be understood as having a set of influenced devices, that represent the equipment that will influence or be influenced by its operation.

2.2.2 Automation Level

The Automation Level consists of controllers, gateways and communication bridges which form a logi- cal network that executes BAS control loops and procedures over the previously defined sensors and actuators. Each control device has a set of inputs and outputs abstracted by the concept of datapoint. Datapoints are the basic addressable units of information in a BAS. Each datapoint has a value and a set of meta-data attributes that characterizes it, such as its network address, unit, precision, or alarm trigger condition. For example, the reading of a luminance sensor can be seen as an output datapoint, whose unit is lux. Datapoints can be grouped to form functional blocks, often used to abstract specific func- tions of the BAS. Such is the case of an HVAC system functional block, which is composed of several datapoints from many separate devices, for example.

Each control device can have one or more datapoints and a datapoint belongs to one and only one control device. The relationship Control device/datapoint expresses this correspondence between dat- apoints and devices (sensors and actuators). Every BAS has also list of datapoints. These datapoints can be seen as elements of a directed graph, where each one can be input or output, and the con- nections (called bindings) are the edges that define communication links between the datapoints. The BAS network is defined by the aforementioned graph and a set of control loops and rules that describe actions associated to changes of values on datapoints.

11 Logs Management Setpoints Configuration Level

Bindings Automation Datapoints Level

Sensors Actuators Field Equipment Level

Figure 2.3: Stacking of hierarchical levels of BAS, according to [43]. Field level comprises the interaction with the environment. Automation level is responsible for orchestrating the control devices. Management level manages the entire BAS configuration.

2.2.3 Management Level

Management Level consists on an application that manages the entire Automation System. Here, the operator can configure the system’s attributes, such as the setpoints, and services, such as scenarios or schedules. The application also generates reports about the BAS operation, shows event logs and warns about the alarms that were triggered.

As it has been seen before, a BAS is composed of several datapoints that input or output system’s variables. These variables are typically between a range of values. Some of this values are considered more favorable than others. For example, if datapoint temperature of a certain room reports a value of 29 degrees, one can infer — assuming the ideal temperature is 21 degrees — that the room is hot. Based on this, we can assume that every time the temperature in a certain environment is different from the ideal, the automation system should act in order to get it back to the desired value. This value is an example of a setpoint. A setpoint is a target value for a given datapoint. If the current value is different from the setpoint value, the system should take the measures expected for taking current value back to the configured value, in other words, approximate it to the set point [43].

Another important concepts considering this level regards building services, that are detailed in the next section.

2.3 Building Automation Services

There is a set of services that usually are provided inside a building automation application. In this section, we present those services.

12 2.3.1 Zoning

Building Automation Systems intend to influence the entire facilities. However, this facilities are divided into several different zones in which the automation system behaves differently. A building can be divided in floors, parts or entire rooms, hallways or other kind of area that deserve distinction. This zones are related with each other by containment or adjacency. This relations help providing an idea of how each zone is placed on the building, and which zones are part of its context. Zones are also characterized by meta-data that describes the properties concerning that space. Information like name of the zone, its usage profile, the location, parent zone and geometry are typically the meta-data that describes each space. This zoning division also helps users on the task of guiding through and recognizing the different controllable parts of the building when using an application. Besides, the zoning is also useful for giving information about the context of each device, which is important to perceive how they will operate.

2.3.2 Device Groups

Device grouping can be defined as a way to logically aggregate a set of devices that share a common interface. We can say that two devices have a common interface when they share at least one concept. For example, consider two interfaces, one for controlling a HVAC unit and another a blind control device, both with ”UP” and ”DOWN” commands. Despite representing distinct actions we can say that they share a common concept, therefore have a common interface. The primary objective of grouping is to abstract a set of devices into a single one, so that they can be controlled together like it was one device. If we define a certain property to the group, this will affect each device that is contained in the group. For example consider the group ”Hallways Lighting”. Applying the command ”ON” on this group will turn on every light in every hallway of the building. One can define device groups by two distinct ways, hardware or software. The first way, hardware, consist on connecting a set of devices to a physical module that abstracts them into one single device. For example a set of lights on a corridor all connected to an aggregation module that, when turned on, turns on the entire set of lights. This module works as an abstraction once it acts as a device for the BAS but, in fact it represents several ones. Hardware grouping can also be defined by a network abstraction, in other words, one can define a set of devices as belonging to a certain sub-network. On the other hand, software grouping consists on making this aggregation using the applications’ data structures. For example, one can define the group stated in the paragraph above by creating a list containing all the corridor’s lights. This approach turns out to be the most flexible once it gets much more difficult to add and remove devices when we define hardware device groups than when we use software grouping, since to do that one has to modify the automation system’s structure.

2.3.3 Scheduling

BAS are supposed to automate tasks related to the building according given schedules. Scheduling ser- vice is the capacity of a BAS to automatically set the execution of a task at a given moment. Schedules

13 are identified by the date, time, and the action to perform. As the time passes, the schedule events are triggered according to the date and time they were defined to. For example, consider a building which is empty at night. One can schedule the task of turning all the building’s lights off from 11 PM to 7 PM. This notion is extremely important for a BAS since it enables it to act without the presence or command of an operator. Schedule events can be one- time or repeatable. A scheduling service must also implement the creation of specific calendars for different purposed, for example, managing lighting for the entire building.

2.3.4 Events and Alarms

An event stands for something that occurs in the system at a given time that changes it’s current state, for example, a change in room temperature or the entrance of someone in a certain room. This events can trigger, depending on the building manager’s preferences, notifications to the system log. Alternatively, alarms express exceptional events, in other words, situations that are not expected to happen, like a device that stopped working, a lack of resource to execute some process or any condition that ceased to be met. Typically, alarm events occur on a certain device or group of devices. Alarms events are defined by the component that originated the problem and a severity condition that indicates the level of disruption against the component’s normal operation. In contrast with regular events, alarms can require manual confirmation or be transient, in other words, disappear if the causing condition ceases to be met.

2.3.5 Scenarios

When we talk about the several spaces of the building, we have to acknowledge that this spaces are places where several kinds of activities perform. Therefore, the spaces have different demands depend- ing on the activity or context they are inserted. This is called scenario. For example, consider a room. Depending on the time of the year and on the occupancy rate we can say that the room characteristics are greatly different. The environment sensed when is summer and the room is full is totally distinct from the one felt when is winter and the room is nearly empty. In this case we can say that the room has two scenarios. For BAS the definition of scenario is greatly important once for the system to be effective is fundamental that it can sense and adapt to the each one of the relevant scenarios of each space. For example, considering the first scenario above, the BAS would act on the HVAC to lower the room temperature.

2.4 Domain Model

This section systematizes the information requirements from the BAS aspects mentioned in the previous section, supporting the concrete analysis conducted in Section3. For each aspect, this subsection defines the information that needs to be captured in order to express it. This information is summarized in Table 2.1.

Field Level

14 Level Concept Information required Device Connection Wiring Device Connection Type Equipment Specification Specific Device Information Spacial Element Location Field Position Influence Area Influence Zone Influence Type Influence Devices Influenced Devices Influence Type Bindings List of bindings Datapoints List of datapoints Automation List of Datapoints Device/Datapoint Relation Relation with devices List of setpoints Setpoints Unit of measure Relation with datapoints List of scenarios Scenarios Relation with trigger conditions Relation with datapoints List of Schedules Scheduling Relation with datapoints Management Relation with date and time List of Groups and Zones Groups and Zoning Relation with datapoints Relation with building spaces List of events and alarms Alarms and Events Relation with datapoints Action to trigger

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

Wiring relations are described through a list of device connections, which represents every link between devices. It is also necessary to specify the device connection type of each relation, for example RS232 or RJ45 cable.

54 Equipment Specification requires detailing the characteristics of each device, namely specific device information provided by manufacturers.

Location is supported by data about the spatial element where the device is contained, as well as the position of the device within that element.

Influence Zone supports the knowledge about the spaces influenced by devices, namely the influence area. It is also necessary to know the 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 connections. They are also defined by the type of influence exerted.

15 Automation Level

Datapoints information is captured through the list of datapoints that compose the BAS, and its meta- data.

Bindings require the specification of a list of logical connections between datapoints.

Control Device/Datapoint Relation encodes a mapping between control devices and datapoints. Hence, to express this concept it is necessary to know both the datapoint list and the control device list, as well as the mapping between control devices and datapoints.

Management Level

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

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

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

Groups and Zoning are defined by the list of group and zone objects and the datapoints they contain. For zoning it is also necessary to capture the spatial elements related to the zone object.

Alarms and Events are described by the list of occurrences, the datapoints related to those occur- rences and the action they trigger.

2.5 Model-Driven Engineering

Model-Driven Engineering (MDE) is an advanced Software Engineering methodology that has been becoming increasingly popular in both academia and industry. Essentially, MDE perceives the model as a centric entity when developing a system. According to Mellor et al., a model can be defined as a “coherent set of formal elements describing something, built for some purpose that is amenable to a particular form of analysis” [64]. In other words, a model is a seizure of a set of concepts that characterize a given reality, independently of the implementation [26, 64, 20]. Models capture a variable set of topics, according to the will of the modeler. This means that one can define the level of abstraction or the span of concepts a models addresses [64]. Indeed, this abstract model captures the essential concepts of the system and will later be refined into multiple implementations on multiple platforms. Models also tend themselves to automated manipulation, in that models can be mapped on to other models by means of model transformations, or transformed to code. There is also a set of activities for handling models that facilitate MDE, such as, among others, validation, comparison, generation, merging or testing [20, 34, 48]. The motivation for MDE comes from the recurring need of software researchers and engineers to abstract the domain of the problems they are dealing with, to identify the essential properties of the system. Essentially, MDE stands on the following pillars:

16 Model Comparison

Model Model Transformation Generation Another (M2M) (M2C) Code Model The Model

Model Model Validation Testing

Figure 2.4: Depiction of the MDE ecosystem. The model is the central entity of the development process, undergoing distinct activities such as validation, testing, or transformation.

1. The model is isolated from the implementation, which means that the functionality of the system is decoupled form the concrete implementations. This allows the correctness of the model to be more easily assessed, since the technical details of the platforms are dissociated from the model, thus enabling developers to concentrate only on the functionality.

2. Platform independent models may be converted into platform specific models using code genera- tion tools, based on models transformations. This feature greatly favors productivity once it saves developers from having to write highly repetitive code.

3. MDE also enables interoperability between platforms and between different models. The former is due to the fact that different implementations share a common model, facilitating interoperability between different implementations (without having to define further mappings between the imple- mentations, or between the implementations and the model), the latter is due to the ability to define model transformations between models, that map the equivalent concepts between them.

4. The model isolation also promotes maintainability, once the model can be modified independently, without having to alter the the implementations. Then, the changes are propagated to the imple- mentations by means of code generation, favoring coherence between models and implementa- tions [45].

2.5.1 Models and Meta-Models

Models themselves can be seen as instances of a more abstract model, the meta- model. A meta- model is therefore, according to Seidewitz, “a specification model for a class of systems under study where each system under study in the class is itself a valid model expressed in a certain modeling lan- guage” [82]. For a model to be considered useful and effective, it must conform to the characteristics of

17 Characteristic Description

A model must always be a less detailed view on a given topic. Since a certain level of detail is Abstraction detached from the model, one can perceive the core concepts more easily.

A model must be presented in a way that is easily perceivable, according to ones intuition. Un- Understandability derstandable models are capa- ble of conveying a complex idea using simple language.

Models must accurately reflect Accuracy the topics they are addressing.

One must be capable of infer- Predictiveness ring the non-trivial properties of a system, through its model.

The model must be constructed Inexpensibility with considerable less effort that than the system it models.

Table 2.2: Description of the main effectiveness and usefulness requirements of a model.

abstraction, understandability, accuracy, predictiveness and inexpensibility [20, 83]. These characteris- tics are summarized in Table 2.2.

When modeling a system, one should abstract from the platform that will be used to implement it. However, since there are a multitude of platforms containing several conflicting requirements, modelers sometimes tend to disagree in one common solution, falling for the specificities of a given platform. For addressing this concern, Open Management Group’s (OMG)8 Model-Driven Architecture (MDA) — which will be presented in further detail later— suggests that systems must be described by 3 types of models, each one handling a different level of abstraction, and be refined or abstracted into each other, using model transformations. The first, the Computational-Independent Model (CIM), must not show the structural details of the system, being a conceptual domain model. The second model, the Platform- Independent Model (PIM), despite considering the constraints inherent to the computational domains, must not depend on any specific technology. Finally, the Platform-Specific Model (PSM) captures the details related with a given platform. This arrangement dissociates the more abstract models from the concrete ones, enabling the developers to think about the more abstract models (CIM, PIM), without thinking about the specificities of the PSM, which can be created using code generation tools [20, 45, 70]. MDA stack is schematized in Figure 2.5.

8http://omg.org

18 MDA

CIM M3

PIM M2

PSM M1

Figure 2.5: Depiction of OMG Model-Driven Architecture. CIM describe systems as sets of concepts. PIM contains constrained aspects, that are not dependent on any technology. PSM describe models conforming to a specific technology.

2.5.2 Model Transformations

MDE rests on the capacity of transforming models into other models, either for generating code or simply to convert it to another equivalent model. This capacity is fulfilled through the concept of model transformation. A model transformation is the act of automatically generating a target model from a source model, according to a given transformation definition [46]. A model transformation definition consists of ”a set of transformation rules that together describe how a model in the source language can be transformed into a model in the target language” [46], which means that a transformation is defined as a set of mappings between model constructs, called transformation rules. These transformation rules describe how one or more constructs from the source are transformed into one or more constructs in the target model. Transformation rules apply to sets of model entities, and are thus independent from the instances. Model transformations are executed within transformation tools. In order for model transformations to be useful, they must be consistent. In other words, the target model must mean the same as the source model. However, consistency only makes sense when target models are able to express the meaning of the constructs that are transformed from the source model [46]. Apart from consistency, there is a set of desirable features that model transformations must comply with. The first one is Tunability, which means one can parametrize the transformation rule, according to the target. The second, Traceability, that enables the tracking of the construct from the source model that originated the construct from the target model. The third is Incremental consistency, which renders the user capable of adding information to the target model without being compromised in case the transformation is re-applied. The last one is Bi-directionality, which means that a target model can be

19 Rule A Rule B Rule C Transformation Definition

Transformation Tool

Model A Model B

Figure 2.6: An MDE transformation workflow. The transformation tool takes the model as input and executes a transformation according to a set of transformation rules. transformed back into the source model [46]. There are two fundamental types of transformations: Model-To-Model (M2M) and Model-To- Text 9 (M2T) transformations, which are described below.

Model-To-Model transformations take an instance of a model and transform it into another instance of a model, whether these conform to the same meta-model or not. This means that the output of a M2M transformation is always a model. Transformations that accept and produce models that conform to the same meta-model are called endogenous, whereas the ones that produce models conforming to a distinct meta-model are called exogenous. In terms of multiplicity, M2M transformations can be one-to-one, one-to-many, many-to-one, or many-to-many. In other words, a given transformation can accept and produce more than one model [14].

Model-To-Text transformations take an instance of a model and transform it into text strings, which can be code, documentation or task lists, for example. However, the most common and important objective of M2T transformations is code-generation. These are vertical transitions from high-level models into low-level code implementations, often generating more artifacts than the running code itself. Such is the case of test case or implementation script generation for example. The generated code is often partial, which means that it is necessary to manually implement some specificities of the code, since model generation tools cannot fully infer those specificities [14].

2.5.3 Model-Driven Architecture

The Model-Driven Architecture is a meta-modeling architecture proposed by the OMG in 2001 as an attempt to provide “an approach for deriving value from models and architecture in support of the full life cycle of physical, organizational and I.T. systems” [70]. MDA proposes a stack of standards for modeling IT systems, organized in 4 conceptual layers [20]. The Meta-Meta-Modeling level (M3) is

9M2T transformations are often called Model-to- code(M2C) transformations

20 the upper layer, which defines the Meta-Object Facility (MOF). MOF enables the creation, construction and management of meta-models. The Meta-Modeling level (M2) contains all the meta-models used for defining real-life models. The Universal Modeling Language (UML), which provides a framework for meta-modeling software systems is defined in this level. The Modeling level (M1) encloses all the models concerning the real-world domains, created using the meta-modeling languages of the M2 level. Finally, the Instance level (M0) contains the instances of the concepts captured in the M1 models, whether they are computational objects, or real-world objects [20].

21 Chapter 3

Related Work

So far, this work presented the concepts that are the basis for discussing the topic of BIM and BA. In order to appropriately develop a solution to the presented problem, one must firstly study the actual research on the topic. This section analyzes the current most relevant modeling standards covering the BA stack of aspects. Firstly BIM models are visited, followed by BA standards and protocols. Relevant research regarding the most popular MDE approaches is also presented. Finally, the evaluation of each one of these models is discussed, drawing a set of guidelines for the solution that will follow.

3.1 Building Models

The next section describes the internal architecture of building information models like IFC, BAMie and COBie, considering the building automation domain constructs that are included in the model as well as elements from other domains that are relevant for supporting the description of BAS, facing the features mentioned in the previous section.

3.1.1 Industry Foundation Classes

IFC, developed by buildingSMART1 (former International Alliance for Interoperability), is an open ex- change format designed to accommodate virtually all data aspects of the building’s life cycle. IFC’s open nature is underscored by the fact that it is the actual standard format for openBIM2, a software toolkit for developing BIM extensions. IFC is based on a metamodel that enables the modeler to define new abstractions, therefore, making the model extensible and interoperable [38, 90]. IFC comprises a set of constructs that connect themselves through relations. Each construct has attributes that describe the semantic of that object. The specification of each object, alongside with all its attributes, is a class. IFCs are modeled recurring to the EXPRESS language — there is also a xml Schema for IFC [54] — and describe a series of these classes. EXPRESS is the actual ISO

1http://www.buildingsmart.org/ 2http://www.openbim.org/

22 standard for developing and exchanging product models such as automation systems 3 and construction projects 4. There are three main kinds of classes, object, relation and resource classes. Object classes represent the several entities inside a building which are identified by a global identifier and a ownership identifier. Each object class has attributes that describe its details and the context where it is being used (such as topology, geometry, etc.). Relation classes represent the way elements connect to other objects. There are many kinds of relation classes that implement diverse types of interaction, such as aggregation, containment, or control. The applicability of each relation is limited, in other words, relations specify which objects can be bound to them. Resource classes represent the attributes used to describe entities [89].

Building Electrical Controls Domain-specific Domain Domain Layer Domain modules

Cross domain Interoperability Layer and shared modules

Abstract model definitions Kernel Extensions (Kernel) Sub-Layer Core Layer Sub-Layer Base modules (Extensions)

Resource Layer Utility modules

Figure 3.1: IFC4 schema layered hierarchy. Building Controls Domain and Electrical Domain contain constructs on Building Automation regarding devices

IFC structure (as it can be found in buildingSMART’s website5) consists of several data schemas, each one addressing a different concern [9]. Data schemas, as depicted in Figure 3.1, are divided in four conceptual layers.

Resource Layer As depicted in Figure 3.1, the first layer at the bottom is the Resource Layer that captures individual business concerns such as cost, geometry, or material. Resource schemas are used to define properties of classes from the remaining layers [36, 94, 52].

Core Layer This layer addresses the most basic concepts within IFC schema hierarchy. It is divided in two subschemas, the Kernel and the Extensions. The first contains the most abstract model definitions such as IFCObject, IFCRelationship or IFCProperty. The second defines the basic classes, such as products, processes, and control based on the concepts defined in Kernel sub- schema [36, 94, 52].

3IFC ISO standard for data sharing http://www.iso.org/iso/home/store/catalogue tc/catalogue detail.htm?csnumber=51622 4Building automation representation standard http://www.iso.org/iso/home/store/catalogue tc/catalogue detail.htm?csnumber=38047 5http://www.buildingsmart-tech.org/ifc/IFC4/final/html/index.htm

23 Interoperability Layer contains modules that are shared across multiple entities. The purpose of this layer is to enable inter-domain exchange and information sharing between the Domain Layer classes, for example, construction information to be utilized by multiple disciplines [36, 94, 52].

Domain Layer Finally, the highest layer is the Domain Layer, which includes the entities that concern to specializations of products, processes or resources from a specific discipline. The schemas related to BA are included in this layer [36, 94, 52].

With respect to BA, IFC is conceived to contain physical aspects about BAS, in other words, focuses on features related to field level. It defines a schema—IfcBuildingControlsDomain—that contains all the classes related to control devices such as actuators, sensors, or controllers. These are referred as control elements and are sub-types of the class DistributionControlElement. Each control element is defined (through RelDefines relationships) by a type and some property sets that describe the equipment details, such as type specific variables, warranty or manufacturer. There is also a material associated to it, which denotes its constitution, a location, which is provided by a relation of containment in a spatial structure, and one nested port that has information about the I/O port attached to the element. Influence devices relationship is fulfilled through the definition of a relation (IfcRelFlowControlElements), which connects control elements to physical devices on which they influence. For example, connecting a temperature sensor to an evaporator coil. The relations to other elements also denote the wiring between devices. In terms of logical specification, the control elements relate to a classification element (IfcRelAssociatesClassification) which specifies the logical address of the control device, where a set of predefined protocols are included. IFC defines a set of constructs from other schemas that can be used to model control constructs like IfcEvent for events and alarms, IfcProcedure for scenarios and IfcTask for schedules. However, these constructs just allow the specification of abstract types and textual descriptions, lacking specific information about how they are programmed, hence it cannot be said that it fully covers the feature’s requirements.

3.1.2 COBie

COBie MVD6 was created to eliminate the excess of waste arising from the information delivered to the building manager when the project finishes being in paper. Avoiding to re-introduce information enables deploying facility management processes faster. COBie is used as a data exchange format for handover of operational and maintenance information, such as equipment lists, preventive maintenance schedules or warranty information. It is typically presented as spreadsheets exported by specific BIM tools [21]. Regarding BA features, COBie provides a list of relations (the Connections tab in the spreadsheet) that denote all the relationships between components of the building. Wiring relationships are a sub- set of these entries, as well as is the containment within spatial element, making the devices location information explicit. The equipment details feature is present in the attributes of each element in the Components sheet. Each row represents a device and equipment details such as warranty, geometry,

6http://docs.buildingsmartalliance.org/MVD_COBIE/

24 or vendor are amongst the attributes that classify each row. An important remark is that all the infor- mation produced by COBie is listed as rows in tables. Thus, although the data is available, it is hard to grasp when the objective is to analyze the BAS network. Information as represented by COBie serves solely for analysis of the construction status, as far as automation systems are concerned.

3.1.3 BAMie

Building Automation Modeling information exchange (BAMie) is another MVD7 that aims at exchanging data about the specification and installation details of the BAS installed in a facility, in particular focusing on how components connect physically. BAMie is still in development and information about it is scarce. According to buildingSMART8, the motivation behind BAMie is handling the delivery of information about the automation component of a building to its owner, once the construction finishes. Another objective is giving the owner a perception of how the BAS is installed, so that resource usage in the facility can be traced. BAMie also aims at exchanging data between other players of a project. For instance, regarding the delivery of equipment specifications from manufacturers to engineers. In what concerns the implementation of BAS aspects, BAMie turns out to be very similar to IFC in terms of structure, since it defines a subset of its schemas, such as, among others, IfcBuilding- ControlsDomain or IfcElectricalDomain. It implements wiring by creating relations between device I/O ports (IfcRelFlowControlElements), which is also used to denote influenced devices. Equipment details feature is met by property sets that describe a device’s specification, such as warranty or operation instructions. Location is mentioned through a relation that denotes the containment relationship with the spacial element, and the position of it. As in IFC, BAMie defines structures that model events and alarms, scenarios and schedules. They are IfcEvent, IfcProcedure and IfcTask respectively. However, these provide only textual descriptions of the features they want to model, lacking process information, they serve only to inform building managers about what the system does in each case. For example, IfcProcedure elements can only provide textual information about which scenarios the system imple- ments, and how they act on certain conditions.

3.2 Automation Models

Automation models define a set of abstractions over the most common concepts related to building automation and relate them in order to characterize and represent concrete domains. They define communication protocols and provide data structures for connecting the devices in a way they can transmit, using a common representation, control data that influences the operation of other devices and, consequently, the entire BAS. In this section the most used automation models are described regarding their information models.

7http://docs.buildingsmartalliance.org/MVD_BAMIE/ 8http://www.nibs.org/?page=bsa_bamie

25 3.2.1 EIB/KNX

EIB/KNX arises as a merge between European Installation Bus (EIB), European Home System (EHS) and Batibus. The purpose of this fusion was to create a single standard for controlling automation systems in home and building, following a distributed system approach [43]. EIB/KNX philosophy bases on the concept of functional block, a structure that abstracts the data points and behavioral aspects of a device. For example, an on/off switch represented by a ”Light Switch- ing Actuator Basic” functional block. Each functional block has exactly one device, although a device can relate to more than one functional block. It consists on a set of data points and the behavioral aspects concerning the device. Data points can be input/output (representing the device’s inputs and outputs) or parameters concerning the application (like a setpoint or an alarm). Parameters are special inputs that influence the way functional block’s outputs are generated from inputs. There is also a diagnostic data output that is used for debugging during installation and operation. Data points are, therefore, the functional block’s interface for receiving and sending data [77]. Data points can be logically connected to each other through Group Addresses. This connection is independent from the devices physical location. If a data point changes it’s value in a given moment, all the data points sharing the binding with it will be informed of the new value. For example, consider a light switch bounded to a room’s luminaries. If the switch changes it’s state from OFF to ON, the new value will be propagated to the luminaries, making them turn on. Consequently, group addresses are useful for creating groupings between devices. KNX implements bindings in three distinct ways. The first one is free binding, which lets any data point sharing the same type to be bounded freely, without any other consideration. Structured binding, the second one, in which the application model forces data points to be linked concerning a certain pattern, typically corresponding to functional blocks or channels. For example, the output of a switch must be connected to input of the device it controls. The third one, Tagged binding, allows devices to be bonded having in consideration some aspect they have in common by fixing part of the address (like a tag). This makes possible the grouping of data points for example by zone, where tags represent the building’s zones [47]. Therefore, tagged binding can be used for implementing zoning. KNX Association provides a set of tools to manipulate the BAS such as ETS tools. These tools enable the network configuration management from a higher level. Operations like retrieving the list of datapoints and the bindings between them and setpoint management are possible through the use of these tools [43].

3.2.2 LonWorks

LonWorks is a platform for implementing control networks developed by Echelon Corporation. LonWorks bases on the existence of intelligent devices — provided with computational power — that communicate between themselves through a control network using the LonTalk 9 protocol [24]. A LonWorks network is composed by nodes that are identified by an unique ID (called selector)

9although other protocols can be used

26 and an address. Nodes communicate with themselves by modifying each others network variables, which are exposed by each node in order to exchange information. Network variables have a data type, which defines the data structure, such as units or scaling. Variables with the same data type can bind to other nodes’ variables. LonWorks define a set of well-defined templates for network variables called Standard Network Variables Types (SNVT) that are typically used to guarantee the interoperability between nodes [58]. Network variables follow the assumption that each device has the necessary intelligence to decide what to do when a new input arrives instead of obeying a new command received from another source, otherwise it would be necessary to know the meaning of every command from all other devices what would bring more complexity to each node. This approach makes the development of new nodes easier once abstracts them from the other nodes’ details. Each node can implement one or more functional profiles. Functional profiles describe the node’s interface aspects such as functionality, properties, network variables and relations to other nodes. For example, a device that implements the Light Sensor functional profile exposes a network variable that represents the lux level sensed at the moment [56]. This variable can bind to another from a controller node that implements the Constant Light Controller functional profile, which receives as input a lux level [55]. Nodes can query the network for other nodes, through fetching for Device Interface Files that de- scribe the set of information about what each node shares, such as it’s network variables, device IDs or supported protocols [23]. This way, it is possible to fetch for data points. Device Interface Files are generated by LonWorks commissioning tools, although some vendors are already including it into the devices. Despite making interoperability easier between devices sharing the same interface, the set of func- tional profiles always end up by being narrow. Therefore, some manufacturers implement their own proprietary interfaces, which harms interoperability. LonWorks provides the creation of logical virtual networks within the physical ones recurring to do- mains and subnets. The first ones come from the idea of separating each major category of devices, such as HVAC or lighting, in independent groups inside a network. The second ones refer to logical ag- gregates within the domains, such as rooms for example. These concepts enable the creation of zones and device groups. Nodes inside subnets can be addressed individually or in broadcast. In case of being necessary to group devices that are in different subnets, LonWorks provides another mechanism called groups. In a group, devices must only be in the same domain, being possible to aggregate nodes from different subnets. Groups are also identified by an address which represents the entire group, therefore, communications addressed to this ID will broadcast the message to every member.

3.2.3 BACNet

Building Automation and Control Network (BACnet) is a standard communication protocol for BAS devel- oped by American Society of Heating, Refrigerating, and Air-Conditioning Engineers (ASHRAE) [5, 18] regarding the needs of automation systems of all sizes and kinds. BACnet is an object oriented proto-

27 col, therefore, it models its constructs — such as devices, schedules or input points — as objects, that contain all the information that enables other systems to understand its operation. Objects have a set of properties, such as name, type, current value, or setpoint, which describe and influence its behavior. There are three types of objects, standard, vendor, and device objects [18]. Standard objects are a collection of objects considered typical to describe a BAS, for example, inputs, outputs, schedules, or groups. Device objects represent the control hardware, in other words, the device itself. Although each physical equipment may have zero or more standard objects associated, device object must be present in each one of them. This rule makes easier to trace the data point/equipment relation. It defines in- formation (in form of properties) regarding the device—the equipment details—such as model name or vendor, and also a list of objects that are connected to it. For example, a device object with one analog input and an digital output. Vendor objects consist in proprietary types developed by vendors to specify objects that are not covered by standard objects. Despite existing to fill the necessity to adapt the proto- col to new object types, device objects cause impacts on interoperability, once the new defined elements don’t have a known interface [27]. Because in BACnet devices and data points are modeled as objects that communicate between themselves independently, the only way to know the entire list of devices or objects is through BACnet Advanced Workstations [88], that offer network queries. Another major problem that derives from the BACnet object-oriented philosophy is that there’s no way to know all the bindings that exist between the objects. BACnet enables the creation of groups through the definition of group objects, which consist on a list of different objects and a list of properties belonging to them. It is used for the simultaneous attribution of all members. Group objects make possible the definition of device groups and zones. The notion of scheduling is fulfilled recurring to calendar and schedule objects. The first one consists on a list of relevant dates, such as holidays or other special occasions. Schedule objects define the execution of a certain function in a given time frame, for example, turning the lights off after midnight during holidays. Schedule events can be one time or repeatable. There is also a priority mechanism that enables the definition of which is the most important process to execute. When an object triggers a certain event, the notifications to other devices depending on that event is made through a Notification Class Object. This objects contain a priority number that define the importance of its underlying event, an option to specify the need for a recipient’s acknowledgment, and a list of targets. This list is composed of the device’s identification (Device unique identifier or BACnet address) and the time intervals where the event must be triggered. Subscription of new targets is made throughout the addition of devices to the list of targets. BACnet also has a structure to represent command presets—or scenarios—called Command object. They are used to write a several number of attributes into a set of other objects when invoked. Therefore they enable the implementation of use scenarios in a room. For example, one can define presets like ”unoccupied” or ”occupied” for setting room conditions regarding those room states. Command objects contain a list of action properties that specify the target object/device, the property to be written, the value to write, and a flag to indicate if the action carried out successfully. There is also a

28 conditional priority property. The action to be executed depends on the modification of a property called ”Present Value”, that initiates the execution of an action according to the value written. For example, if the variable is set to 3, the third action will be executed. When the command is triggered, the flag ”In Process” is set to TRUE, this indicates a command is being executed and inhibits ”Present Value” to be set again, throwing an error. Command objects also have a flag for indication the overall success of command chains. However, if a chain fails in some point, there’s no way to rollback the actions carried out [92]. BACnet/WS an extension to the model that enables it with SOA capacities. It defines a series of services that are used to manipulate data on the server as well as on devices. BACnet/WS defines read, write and option services. The first ones enable the reading of object’s attributes in several ways. The second ones provide manners to write objects’ attributes. Finally, the third ones permit manipulating optional parameter of the BACnet server [42].

3.3 Management Level Service Frameworks

Some technologies define BAS using Service Oriented Architectures (SOA). Part of the models de- scribed in the previous section have extensions that use SOA, however, the following technologies are developed as stand-alone frameworks that try to abstract from the specific implementations of BAS and define a high level model that enable all of these implementations to communicate, favoring interoper- ability between heterogeneous systems.

3.3.1 oBIX

Open Building Information eXchange (oBIX) stands for a technology that enables buildings’ mechanical and electrical systems to communicate with each other inside networks using web technologies such as XML or REST. oBIX came in with the development of devices equipped with embedded computational power once they are capable of communicating with each other autonomously and focuses on imple- menting a SOA approach to automation networks. There are three kinds of services, read service that is supported by every object, write service which can only be executed by writable objects and invoke service that is only supported by operations [40]. The basic data element in oBIX model is Object. Objects have a type, that can be primitive or complex types (called contracts), and a set of attributes that describe the object. The identity of an object is given by its name ans a Unified Resource Identifier (URI). Objects are provided with composition, multiple inheritance, and extension mechanisms that enable the creation of new abstractions. The entire list of objects is stored in an oBIX server, and it’s received by the client when it contacts the server. Each object can contain references to others, representing the bindings between them [68]. oBIX objects are represented in XML. Each object corresponds to an element in XML and each object’s attribute is represented as that element’s attribute. There are a set primitive data types such as int, string, or val. To enable invoke services, operations are modeled as primitive objects. op objects,

29 similarly to web services, have an input attribute and an output one and abstract the execution of some operation [69]. The Data point notion is captured by a primitive object called Point. Regarding interoperability be- tween vendor compatibility, Point objects use a low level abstraction composed of one primitive value type, optional unit and status information. By default, oBIX doesn’t have objects to handle device groups, and zoning. However, this concepts can be defined manually recurring to inheritance or through com- posing and referencing objects. Since oBIX enables the creation of readable and writable objects, one can define and modify setpoints, typically within point objects. Alarms and events are handled recurring to Watch and Alarm objects. Watch objects implement a repository where events are stored. These events represent changes to certain tracked attributes, previously registered by the clients on watch ob- jects. Each time a client polls the watch object, it returns the last changes that occurred to the tracked attributes. All the services for manipulating the watch objects are provided as primitives by oBIX. On the other hand, Alarms are responsible for triggering events each time some exceptional conditions are met, for example, a value that became out of bounds. Alarms are associated to watch objects so that the second can keep track of the events generated by the first and send them to the client [39].

3.3.2 OPC UA

Object Linking and Embedding for Process Control Unified Architecture(OPC) consists on a series of specifications developed and maintained by OPC Foundat ion10, a consortium created in 1994 consisting of five industrial automation vendors. It defines a set of data and communication modeling standards for exchanging information inside automation systems using devices from distinct vendors, through a TCP/IP network. The initial effort was to define a standard to manipulate common automation data, such as alarms and events or device information [73]. The main goal is to resolve vendor dependency issues, bringing a standard which provides a portable, secure and extensible platform for modeling BAS. OPC UA defines the interactions between devices fol- lowing a SOA approach, using OPC servers and OPC clients, through HTTP, SOAP or binary TCP/IP as transmission protocol. Despite having specialized devices, OPC servers can run in a normal computers. In order to make devices compatible with OPC, vendors must implement OPC drivers on them, which abstracts OPC from the protocols they implement [59]. The kernel of OPC UA conceptual model lies on two concepts, Nodes and References. Node is the class that models every object in OPC, which relate themselves through references. Nodes are uniquely identified by an ID and its purpose is specified by the node’s class. Every OPC node has Attributes and References. The first contains a set of data elements, that describe the node’s details. OPC defines a set of standard attributes for node, such as DisplayName, the name user sees in the screen, NodeClass, that denotes the node’s class, or NodeId that specifies the node identifier [59, p. 22]. OPC UA defines a set of standards node classes, where the most important are Objects, Methods, and Variables. References express connections between nodes, for example, inheritance or composition. Although they are not nodes, they are present in the address space. Each reference has a ReferenceType that

10http://www.opcfoundation.org/Default.aspx/01 about/UA.asp?MID=Ab outOPC

30 describes it’s purpose. Despite references are not nodes, reference types are, once they can have relations between them. There are two types of references, Symmetric and Asymmetric. Symmetric references represent connections that mean the same for each of the nodes, for example, the compo- sition reference connecting two objects. Asymmetric references represent the inverse, in other words, they have different meanings for each of the nodes, for example, an inheritance relation, where one of the nodes represent superclass and the others subclass [59, p. 23] [77, pp. 15]. Objects in OPC UA are used to structure an information model. They inherit the attributes from node class and have no other information by default. They divide in simple objects, that contain no methods nor variables and are used to define semantics of the address space, and complex objects that are composed of variables and methods. Objects have an ObjectType attribute that denotes the type of object. Although there is a set of object types predefined, the developer can extend this set to include more types. Object instances connect to their types through an HasTypeDefinition reference. For example, consider an object instance called ”room1 Fan”, that relates to the complex type ”FanType”. Saying that means ”room1 Fan” has the variables and methods defined int ”FanType”. Objects can also generates events and notifications when exposed to certain conditions. This events are subscribed by clients through subscriptions services provided by the OPC servers. Another class that derives from node is the Variable class. Variables have a Value attribute which denotes the current value of the variable, and a DataType one, that describes the type of data that the variable represents. Like in objects, there are also simple and complex variables. The first ones only define semantics of the variable while second ones expose functionality from ones beneath it. Data types can divide in 4 groups, Built-in DataTypes which correspond to basic types such as Int32 or Boolean, Simple DataTypes that are subtypes of the built-in data types and define some additional abstraction on the them, Enumeration DataTypes that represent a set of values, and Structured DataTypes that enable the developer to extend the model with new types for more complex models. Variables can be logged for recording previous values, according to a user defined sampling rate and clients can subscribe to the value modification, receiving notifications to track the value’s evolution [59, pp. 30] [77, pp. 16]. Views are another important concept in OPC UA. It provides mechanisms for emphgrouping con- structs from address space such as objects, variables, or references according to a certain manner, therefore enabling the capacity to organize the system in a perceivable way. For example, we can de- fine a view for each room in a building and another to group every device that belongs to the HVAC domain citeOPCFoundation2012, OPCFoundation2009a. OPC UA bases itself on a SOA, where clients and servers invoke services between themselves when they need to interact. Therefore, it defines a set of standard services that organize in several categories. The categories that are related to the features covered by this project are Discovery Services, Node Management Services, View Manipulations Services, Querying and Attribute Services, Method Services and Monitored Items and Subscription Services. Discovery services are used by nodes to find available servers on the network and to provide them its endpoint description. A service endpoint is something — an application or port for example — to where the messages can be routed. The endpoint description provides information necessary for other entities

31 to access the endpoint. Devices can invoke discovery services on servers one by one, or through a Discovery Server which maintains information about each Server’s endpoints. Node Management Services enables the modification of servers’ model by adding, modifying and deleting node definitions and references. This makes possible to, in run-time, modify the BAS meta- model by adding or removing a concept, for example, consider a single floor building. If at a certain time other floor was added to the building, it would be possible to insert into BAS meta- model the concept of floor. This feature makes OPC UA a extremely flexible platform. View Manipulation Services provide the necessary operations for browsing system’s Views. Querying and Attribute Services make clients capable of retrieving information about the BAS model. Queries are made following a search criteria on the model and return data regarding nodes and its attributes. Clients cane query the entire model or just a subset of it (a View). Queries can be made regarding different points in time, for example, a client can query an early version of the model or retrieve past attribute values. Method Services are used to invoke methods on nodes of the model. This methods receive a set of input parameters and return several output ones. To avoid repeated invocations, methods have a series pf conditions that, when not met, causes the method to abort and rollback the invocation. Monitored Items and Subscription Services are related to events and notifications. They enable the creation, modification and deletion of monitored items. This services let clients be notified of changes and events by subscribing to monitors that contain the items to be monitored. It is possible to add and delete items from these monitors and each one has a list containing information about (i) the item to monitor (any node’s attribute, like the name or the current value), (ii) the subscription that receives the notifications, and (iii) a sampling rate (the rate at which the item will be queried for changes). Any monitored item can be enabled or disabled at any moment and the notifications can be dependent of another objects, called the triggering objects. Notifications that come from monitors are passed to a subscription, where client register to receive information about items. Each subscription has a publishing interval that defines when to query the monitors for notifications. Events are triggers associated with a determined condition about some object (that typically is related to a device in the BAS). These objects can be seen as event notifiers that can be subscribed [71, 74]. OPC UA is indeed a very interesting and flexible system, making possible the modeling of almost any BAS. However, this system is very complex to understand what makes it very difficult to extend and work on. The support for OPC UA is also difficult to achieve and because of this many of the free tools that exist to manipulate OPC US systems are outdated or don’t cover the entire specification [35, 28]. OPC UA can even be applied to other areas due to its high level of abstraction [76, 91, 60].

3.4 MDE Platforms and Applications

This section overviews the most relevant MDE platforms and applications, with respect to their rela- tionship to the development of BIM-related applications. Each visited application is introduced and its structure briefly described, followed by an analysis of its MDE features, the role these features perform

32 EMF MDA

model PIM .ecore

model PSM .genmodel

model .java Instance

Figure 3.2: Mapping between the different levels of the EMF and MDA stack. The Ecore models rep- resent the PIM, the generator models correspond to PSM and the Java early binding classes represent the instances. in the application workflow, and the applicability to the problem of BIM.

3.4.1 Eclipse Modeling Framework

The Eclipse Modeling Framework (EMF) is a framework developed under the Eclipse Platform 11, an open-source project which aims at providing a set of tools for software development mainly using Java- related technologies(although many others are supported) [65, 11]. The main objective of EMF is to provide a series of tools for designing and implementing structured models, including, among others, model creation, code generation, or model serialization. The main driver of EMF is to implement the OMG MDA specification, uniting three technologies: Java for implementation, UML for domain modeling, and XML for serialization. One of the main features of EMF is that it is built inside the Eclipse platform, that enables the development of plugins for extending its functionality. A noteworthy example is the ATL transformation language, for model transformation specification. Moreover, it is possible to build entire applications on top of this platform (Eclipse Applications) [11]. EMF also offers a simple way for defining Domain-Specific Languages (DSL), since it is capable of generating graphical editors and syntax validators [85]. One of the most important features of EMF is code generation. After the model is created, it is possible to generate a Java implementation of it, using a Generator Model. A generator model is an intermediate EMF model that is responsible for storing all the data concerning to a particular code generation such as the location where to put the code or the package prefixes. In fact, a generator model behaves as a PSM since it contains information concerning a specific implementation, but it is not yet code. From the creation and edition of the generator model, EMF is capable of generating a set

11https://www.eclipse.org/

33 of Java interfaces and classes, that implement the specified model [85]. For representing models, EMF includes a metamodeling language named Ecore. Ecore defines the constructs for creating models under EMF, and thus corresponds to the M2 level of the MDA abstraction stack. The main constructs of Ecore kernel are, among other, EClass, EReference, EDataType, and EAttribute [11] (see also Table 3.1).

Construct Description

Represents an entity of a given EClass model. EClasses have EAt- tributes and are linked through EReferences.

Represents a given characteris- tic therefore is used to describe EAttribute a given EClass. Attributes have a Name (represented by a text string) and a EDataType.

Represent relationships be- tween EClasses. Each ERef- erence has, therefore a target EClass that corresponds to the EReference other end of the relationship. It also has a Name (encoded as a text string) and a boolean for distinguishing containment relationships.

Represent the carrier type of a given EAttribute. The carrier EDataType type can be a primitive, such as an integer or boolean or com- plex type.

Table 3.1: Description of the main constructs that compose the Ecore specification.

3.4.2 Epsilon

Epsilon 12 is a Eclipse-based platform for making easier the development of task-specific languages for model management, such as model transformation, validation, refactoring, comparison, or code gener- ation [48]. It is part of the Generative Modeling Technology(GMF), an Eclipse sub- project. Although developed under the Eclipse platform, Epsilon can be used to manage models created not only using EMF but also other metamodeling facilities. The objectives of the Epsilon platform are (i) to make easy the development of task-specific languages for model management, (ii) to enable the abstraction from the underlying metamodeling platforms (EMF, MDR, etc..), (iii) to help the developers of such languages

12http://eclipse.org/epsilon/

34 to focus only on the development of the language itself, instead of dispersing with the trivial features, and (iv) to define a common interface for executing tasks on models [49].

The core of Epsilon consists of two main components: the Epsilon Model Connectivity (EMC) and the Epsilon Object Language (EOL). EMC provides a common interface for dealing with the multiple model management technologies such as EMF or MDR. A set of drivers map this common interface to the target modeling technologies. EOL is the common language used to specify models, which is based on Object Constraint Language (OCL), with an additional set of features such as statement sequencing, or multi-model access. Its main purpose is to be used as base for the created task-specific language [49, 48].

As mentioned before, Epsilon enables the definition of languages for dealing with a set of model- related tasks. Currently, Epsilon provides a set of languages for dealing with model-related tasks, which are depicted in Figure 3.3.

Epsilon Merging Epsilon Generation Epsilon Wizard Language Language Language (EML) (EGL) (EWL)

Epsilon Transformation Epsilon Comparison Epsilon Validation Language Language Language (ETL) (ECL) (EVL)

Task-specific languages

Epsilon Object Language (EOL)

Epsilon Model Connectivity (EMC)

EMF XML MDR … Driver Driver Driver

Technology-specific drivers

Figure 3.3: Depiction of the Epsilon architecture. On the bottom, several drivers implement connectivity through several technologies. In the middle, EMC abstracts a common interface used by the EOL. On top, a set of languages is developed based on EOL.

Since this work focuses on the usage of ETL, it is worth to describe the main features of this lan- guage. ETL is a rule-based M2M transformation language, capable of transforming a given number of models into another set of models, independently of the model language, or the technology used for creating the models. ETL is a hybrid language which combines features from declarative and imperative transformation languages, since it enables the definition of simple mappings as well as fine grain control of the operations [50, 49].

35 3.4.3 BIMServer

BIMServer 13 is a BIM server application, that is capable of storing, maintaining and querying buildings in the IFC format. Its main purpose is to provide a way for small, medium, and large enterprises to store and manage their BIMs at a low cost and with minimum technical knowledge, serving also as a framework for the research to develop new BIM tools and applications [10,7]. In fact, there is a wide span of applications that use this tool as a framework for storing and managing BIMs [7, 96, 62, 13]. BIMServer is equipped with a multitude of features that make it easier to manage IFC encoded buildings, such as history and revision of IFC projects, configurable queries to the building model, SOAP interface bindings, or web-based user interfaces. Moreover, BIMServer is able to adapt to the several versions of IFC specification (such as IFC2X3 or IFC4), and also to read from and write to alternative file formats such as IfcXML or ifcZip [10,7]. This platform is in constant evolution, planning to introduce new features such as MVD file automatic generation [10]. The architecture of BIMServer is divided in four layers. On the top of the stack, the client layer pro- vides interfaces for communicating through a set of protocols and formats such as SOAP or IFC. These clients are modular, and new ones can be developed and added to the application (such as, for exam- ple, REST interfaces). The service layer contains the main service implementations of BIMServer, and hosts the core logic of the application. Several MDE features are used to make the management of the IFC schema more flexible, that are discussed in further detail below. The third layer provides abstrac- tions for the persistent storage of the information, which is, by default, a column- oriented database, although other kinds of databases can be used. Finally, the bottom layer is composed by a BerkleyDB, a key-value database. BIMServer runs on Java, which favors portability between several computational architectures [10,7]. With respect to MDE, BIMServer uses EMF to maintain an Ecore model of each version of IFC, as well as several other utility models, which means that the traditional EXPRESS representation is turned into an ecore representation. This implies an M2M transformation between the EXPRESS metamodel and the Ecore metamodel. For doing this, each IFC schema version is parsed by a generic EXPRESS parser, and then converted to Ecore. The mapping between the constructs of these metamodels is almost trivial for the most constructs, except for some special cases. Once the models are properly converted, an M2T transformation is used to generate early-binding Java classes, for each construct of the ecore model. When a new building model is uploaded, a STEP 14 file parser instantiates these early-binding classes, creating an in-memory representation of the building [10,7].

3.5 Discussion

So far the text has visited the most important information models that describe buildings and automation systems, as well as the most popular tools for supporting MDE practices on BIM. This section develops a comparative analysis of the information models focusing on the model completeness with respect to

13http://bimserver.org 14http://www.steptools.com/support/stdev docs/about step.html

36 BAS aspects, complexity, and flexibility in adapting to domain evolution. Also, considering the coverage analysis conducted, the applicability of the models to specific aspects of the BAS domain is considered. The discussion closes by assessing the pertinence of applying MDE concepts to the topic of BIM and BA.

3.5.1 Completeness Analysis

Table 3.2 summarizes the features covered by the models and highlights the BAS levels according to the most suited models for covering their features. Figure 3.4 compares models, in relative terms, regarding completeness, flexibility, complexity. Table 3.3 depicts the score obtained by each model, considering the dimensions of complexity and flexibility. For each dimension, 3 metrics were evaluated in which each model can obtain a score between 0 and 1. Flexibility metrics are binary, assuming the values zero or one. With respect to complexity metrics, the distinction between “Model” and “Meta-model” will also be binary, where “Model” will be evaluated with zero points and “Meta-model” will be evaluated with one point. For the remaining complexity metrics, the score assumes a relative value between 1/8 and 1. To calculate relative completeness, a fully implemented feature is mapped to 1, a partially implemented feature is mapped to 0.5, and a nonimplemented feature is mapped to 0. Wiring, equipment details and location details are equally supported by IFC, BAMie and COBie. IFC covers wiring by relating IFCPort elements (that relate to devices by nesting) with cable segments which are related to another port, denoting a wiring relation between these two devices. Equipment details feature is implemented by defining a set of properties over the device objects, which store details con- cerning the object. Devices can also be related to a spatial element denoting its spatial location. BAMie and COBie, being views over IFC, implement these relations in the same way. Equipment details are also supported by BACNet which makes possible to define properties over the device objects, representing the equipment. IFC, COBie, and BAMie express influenced devices by enabling querying the model for related equip- ment through relations between them. However, no model provides constructs for modeling influence zones. EIB/KNX handles binding and datapoint listing features through the eteC framework [47] that is ca- pable of querying the network for datapoint and binding lists. LonWorks and OPC UA achieve datapoint listing recurring to querying services. In LonWorks, queries to structures called device interface files are made by nodes themselves [57]. OPC UA uses OPC servers to mediate the OPC client request [71]. In the case of oBIX, the datapoint list can be accessed in the server, through the object list [69]. BACNet can only list datapoints using an advanced workstation [15]. With respect to the relationship between datapoints and equipment, KNX covers the device/datapoint relation aspect through the existence of functional blocks [77], which abstract control devices, even though other arrangements can be used. OPC UA is built on the assumption that each control device is an OPC server, enabling the creation of objects that represent control devices and relate them with variables, which represent datapoints [59, pp. 3]. BACnet’s specification supports this feature through device objects [18], since each device object,

37 Building models Automation models Service frameworks Level Feature IFC COBie BAMie EIB/KNX LonWorks BACnet oBIX OPC Wiring Equipment Details # # # # # Field Location # # # # Influence Zone # # # # # Influence Devices # # ###### Bindings # # # # # # Automation Datapoint list ### # H# DP/Equipment Relation ### H# Groups and Zoning ### H# # # Schedule ### H# H# Scenarios H# # H# # # H# # Management Alarms/Events H# # H# # # # # Setpoints H# # H# # # # # # TableTable 3: Summary 3.2: Summary and comparative and of comparative the studied information analysis models of regarding the studied coverage information of BAS features. models Shaded regardingareas show which complete- information models are most suited for covering distinct BA levels. – Unsupported – Supported – Supported partially or recurring to specific devices ness facing BAS aspects. Shaded areas# show which informationH# models are most suited for covering distinct BA levels. – Unsupported – Supported – Supported partially or through to specialized devices. # H# models much as IFC, BAMie or COBie are fit for mod- References eling the field level aspects of BAS. Models underlying automationwhich represent protocols, physical such as nodes, LonWorks has andto be EIB related/KNX, with[1] each J. Lee, of its Y. datapoints. Jeong, Y.-S. EIB/KNX Oh, J.-C. Lee, achieves N. Ahn, device J. Lee, S.-H. Yoon, An integrated approach to intelligent ur- aregrouping able to represent through taggedlogical components binding [47 and]. BACNet some man- realizes this feature defining a special type of object, agement functionalities. Service frameworks, like BAC- ban facilities management for real-time emergency Net,the oBIX group and object OPC [UA,92], intend that contains to model thea list management of other objectsresponse, with their properties, Automation and in Construction propagates 30 actions (2013) 256–264. functionalityit receives toas services,them. LonWorks being relatively provides complete three in different this approaches: domains, subnets and groups [24]. regard, despite the complexity of some models like OPC [2] E. Curry, J. O’Donnell, E. Corry, S. Hasan, UA.The However, first two no are model based is on able the to creation capture the of virtualfull gamut networks,M. and Keane, the third S. O’Riain, on a special Linking construct building to data include in the ofdevices aspects fromunderlying the same BAS. domain. cloud: Integrating cross-domain building data using Finally, this work concludes with a set of recommen- linked data, Advanced Engineering Informatics 27 dationsHigh towards the development of a BIM extension to (2013) 206–219. cover more BAS aspects. Coarsely speaking, the impact of one such development is twofold: first, it enables au- [3] A. Akcamete, B. Akinci, J. H. Garrett, Potential uti- oBIX IFC OPC tomation tools to inter operate, and second, it may con- lization of building information models for planning 35% 42% 42% tribute to mitigate costumer lock-in effects of vendor spe- maintenance activities (2010). cific automation solutions. [4] R. Vanlande, C. Nicolle, C. Cruz, IFC and building lifecycle management, Automation in Construction Acknowledgements 18 (2008) 70–78. [5] C.BACnet Bogen, D. Ph, M. Rashid, E. W. East, F. Asce, This work was supported by national funds through A framework for building information fusion (2011) FCT – Fundac¸ao˜ para a Cienciaˆ e a Tecnologia, un- 58%

Flexibility 26–28. der project PEst- OE/EEI/LA0021/2013 and DataStorm Research Line of ExcellencyCOBie fundingBAMie (EXCL /EEI- [6] V. Marinakis, H. Doukas, C. Karakosta, J. Psarras, ESS/0257/2012). 23% 42% An integrated system for buildings’ energy-efficient EIB/KNX 17 LON 35% 31% Low Low Complexity High

Figure 3.4: Comparison of studied models regarding flexibility, complexity and relative completeness.

Although oBIX and OPC UA do not define groups in their specification, they enable the definition of group objects, in oBIX through composition, inheritance, or referencing and, in OPC UA, by creating a

38 group object. Scheduling is supported partially by IFC and BAMie. These standards define task objects that can be implemented as schedules that only support generic textual descriptions about the tasks. BACNet defines calendar and schedule objects on its information model [92] that relate execution of functions with predefined dates and times. oBIX partially supports scheduling by defining the basic date and time constructs, leaving the definition of the schedule object to the modeler [69]. BACNet is the only model that fully supports scenarios through command objects that encapsulate a list of commands to be executed under certain conditions [92]. Alarms and events are partially implemented in IFC and BAMie through the IFCEvent construct. However, IFCEvents are too generic, containing only a textual description of the event. BACNet and oBIX support alarms and events by defining objects in their information model [92, 69]. The former uses notification class objects while the latter uses watch and alarm objects. OPC UA makes it possible to use notification items and subscription services [71]. EIB/KNX handles setpoint management making setpoints part of the datapoint structure [51]. BACNet encapsulates setpoints inside objects [5]. These will be later accessed by BACnet’s read and write services for handling them. LonWorks stores setpoints in nodes that can be managed by application servers that query device interface files [58]. oBIX models setpoints as writable points [69]. Like every writable object in oBIX, points can be accessed by write and read services for modifying its content. OPC UA enables the definition of setpoints through variables [72], that can be related to datapoint objects and accessed by OPC UA querying and attribute services for manipulating their values.

Building models Automation models Service frameworks Dimension Metric IFC COBie BAMie EIB/KNX LonWorks BACnet oBIX OPC Open Specification Flexibility User-defined entities # # # Extendable Model # # # Model/Metamodel Model Model#Model #Model #Model #Model #Model Metamodel Complexity Number of Entities 766 100 163 347 210 18 16 94 Inheritance Tree Depth 7 5 7 1 1 1 1 7

TableTable 3: Table 3.3: assessing Evaluation the studied of the models studied in what models concerns to with the dimensions respect ofto Complexity the dimensions and Flexibility. of Complexity “ ”and “Model”– and 0 Flexibility. points “ ” and “Meta-model”– 1 point. The remaining Complexity metrics have a relative score. # “ ”– non-applicable “ ”– applicable. # the list of bindings. Since none of models captures BAS Finally, from a management perspective, one such ex- features, it is sometimes necessary to use more than one tension to BIM, would also alleviate customer lock-in technology3.5.2 Complexity to implement a BAS. Analysis with respect to automation systems vendors. For exam- ple, by endowing building owners with the freedom to Most fieldbus models, like EIB/KNX or LonWorks (as suchchange in and Table maintain 3.3) feature the BAS extensive configuration lists of without entities, hav- 7. Recommendations and Potential ing to contract the same vendor every time. Enabling BAS data types and relations, which makes the model complex to comprehend and manipulate. IFC, more- Regarding the representation of BA aspects, despite be- to change faster also contributes to meet energy eciency ingover, relatively represents complex, information the IFC information concerning model several aims domainstargets of [30]. a building, requiring a plethora of entities atand a unified a deep and inheritance independent tree. data To model address that can this be complexity ex- in IFC, views like COBie and BAMie were de- plored by a span of applications such as automation tools andveloped, EMS. IFC, that therefore, represent takes smaller the lead subsets when of it thecomes building to 8. information, Conclusions regarding a specific domain, but still interoperabilityaverage sized and in flexibility.terms of complexity. Yet, IFC lacks OPC in coverage UA is defined as a meta-model, which enables the creation of Automation and Management aspects when compared This work studies the possibility of integrating BAS withof nearly the remaining any model. models However, (like oBIX, most OPC, definitions and BAC- havemodeling to be created in BIM. manually. Focusing OPC, on the although advantages extremely of such Net).flexible Model and views powerful, like BAMie is the most and COBie complex are notmodel better of all,connection, due to its ithigh reviews level existing of abstraction; literature italso towards defines devel- than IFC as they do not fully cover most BA aspects ei- oping a BIM-based information model for BAS. The doc- ther.a relatively extensive list of predefined classes andument a fairly also deep presents, inheritance systematically, tree. oBIX a series and of BACnet, key con- onThere the isother clearly hand, a need have for thea BIM simplest extension information for automa- models.cepts Theseand requirements models define for representing the most BAS concise information. set of tion and management levels that abstracts the details of The most popular building automation information each specific automation technology. models were then studied in detail focusing on feature Enriching BIM’s information model would also con-39coverage, flexibility, complexity and domain applicabil- tribute for BIM to stand out as a helpful tool for property ity. From this analysis, this work concludes that no com- owners, for whom the advantages of digital building mod- plete model exists for representing BAS. Building infor- eling are not yet completely clear [14], by simplifying the mation models such as IFC, BAMie or COBie are fit interoperability with FM tools. for modeling the field level aspects of BAS. Models un- The development of such extension to BIM will also derlying automation protocols, such as LonWorks and help to mitigate the problems of BAS heterogeneity and EIB/KNX, are able to represent logical components and vendor dependency. Moreover, it would make easier the some management functionalities. Service frameworks, development of a range of tools that could re-use the in- like BACNet, oBIX and OPC UA, intend to model the formation stored in it, thus favoring interoperability. To management functionality as services, being relatively this end, the model may serve as intermediate, enabling to complete in this regard, despite the complexity of some translate between multiple concrete BA information mod- models like OPC UA. However, no model is able to cap- els. ture the full gamut of aspects underlying BAS.

16 classes.

3.5.3 Flexibility Analysis

IFC, BAMie and COBie specifications are open, which means that their models can be changed to enable defining new objects, classes, relations, and properties, making these models highly adaptable regarding modifications. It is also possible to create user-defined entities using property sets. EIB/KNX, BACNet and LonWorks, despite having some extensibility concerns (like vendor objects in BACNet, or SNVT’s in LonWorks), tend to be rigid since these implement protocols that are hardly modifiable. In contrast, OPC UA and oBIX have been designed to be extended. They define high level constructs that enable the definition of new concepts without having to deeply modify the information model.

3.5.4 Applicability Analysis

Some technologies are better suited to model certain levels of the BAS hierarchy—this can be easily grasped from the grayed areas on Table 3.2. Typically, building information models—such as IFC, COBie and BAMie—are better suited to model field level constructs, since they comprise spatial concepts and relations between them. Fieldbus information models—such as EIB/KNX and LonWorks—are meant to model information from the automation level. Finally, service frameworks, like BACNet, oBIX and OPC UA, intend to fully cover management level concerns. Table 3.2 clearly shows this aspect. Hence, there is no model that is fully complete regarding all the levels of BAS. Without surprise, IFC and, consequently, BAMie and COBie stand out as the most adequate models to represent all BAS concepts about field level features, implementing every feature except influenced zone. Regarding automation models, BACNet (when considering BACNet/WS) is shown to be the most complete with respect to automation and management levels, lacking only completeness regarding the list of bindings. Since none of models captures BAS features, it is sometimes necessary to use more than one technology to implement a BAS.

3.5.5 The Role of MDE

Since all studied technologies rely on models of BAS concepts, it is clear that the problem raised in the scope of this thesis must be handled using MDE. Despite the application of MDE being independent of any technology, once it can be viewed as a set of engineering practices, the usage of MDE tools make the development much easier and focused on the critical tasks such as the model development itself. BIMserver has the potential to be a powerful framework for maintaining and developing IFC model extensions, specially if combined with EMF. The advantages of this combination are:

• EMF provides Ecore, a common, wide-used metamodel that can be mapped from EXPRESS, the metamodel of IFC.

• Built-in code-generation tools of EMF can be used on the development of applications for handling IFC models.

40 • EMF also provides a wide community support, which makes its learning curve more soft, and the development faster.

• BIMserver includes parsers and serializers for both EXPRESS and IFC formats, which greatly alleviate the work effort, since the development of such tools is a large effort (and not the central aspect of this work).

• BIMserver is also ready for dealing with the evolution of the IFC schema, since it contains compo- nents that automate the conversion of new IFC schemas into EMF representations. This greatly eases the development of the proposed IFC extension, since it is no longer necessary to manually map the IFC schemas from EXPRESS into Ecore.

On the other hand, Epsilon platform eases the effort with the development of model transformations, which are fundamental for the usage of the information stored in the IFC extension. Using ETL, one can define a set of transformation over the IFC model extension in order to convert a given building instance into a model conforming to other automation standards such as KNX or BACnet.

41 Chapter 4

Solution

In earlier sections a gap analysis was conducted on several BIM and BAS standards in order evalu- ate, amongst other aspects, how complete was their coverage regarding BA concepts. The analysis concluded that IFC lacks coverage on BA aspects relating to the two uppermost levels, namely the Au- tomation and the Management level. Still, it was concluded that IFC offers sufficient flexibility to easily support model extensions, since its structure predicts future modifications. IFC also exhibits great inter- operability features, that motivates its usage as a format for exchanging building information, as is the case of BAS configuration data. In order to enable BIM to cover the remaining aspects of the BAS do- main, this work presents IFC4Automation, a model extension to IFC, the standard exchange format for BIM. This enables BIM to capture the modeling of the automation component of buildings, bringing the advantages of this approach to the BA domain. This section presents IFC4Automation in what concerns to its functional and non-functional aspects. Firstly, this section conducts an overview on the solution, followed by the description of its architecture. Secondly, the domain model is explained with detail, vis- iting each created construct, and illustrating how the constructs interact with each other. Thirdly, this section visits the development of a model transformation targeting the KNX information model. Finally, the methodology followed for working IFC4Automation is described.

4.1 Solution Overview

IFC4Automation is an extension the IFC4 information model, that covers the remaining relevant BAS aspects 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 the reuse of constructs already available, such as equipment details, wiring, or location. In other words, it is designed to make possible the interaction between existing IFC elements and the new ones.

42 IFC4.exp

extends

LON ETL IFC4 Automation.exp

BACnet KNX

Figure 4.1: Illustration of the proposed BIM extension. Extended BIM models can be translated to existing BA models through transformations.

4.1.1 EXPRESS

IFC4Automation is developed using the EXPRESS modeling language. EXPRESS is the modeling language used for specifying IFC. Writing an extension using EXPRESS provides a powerful mechanism for expressing all the elements, relations and resources required without ambiguities, and guarantees the consistency needed in a BIM extension, in the sense that there is no need for translating between different modeling approaches.

4.1.2 MDE

IFC4Automation defines a set of abstract constructs that capture the core information of each BA as- pects in order to keep the model independent from the several implementations. The instances of this model are ready to be later translated into different implementations, depending on the target platform, detaching the core specification of a BAS from the several technologies in which it could be realized, thus favoring reusability and flexibility. Using MDE tools makes model validation easier, as well as automates the generation of code, skipping what would otherwise be a repetitive task.

4.1.3 EMF

IFC4Automation is also represented using the Ecore metamodeling language. Ecore is part of the EMF platform where, in contrast with EXPRESS which is less established in the MDE community, a multitude of open-source tools for handling models and metamodels are already developed and well supported. Once represented as an Ecore model, it is possible for IFC4Automation to interact with a larger variety

43 of MDE tools. One good example is BIMserver, which provides parsers and serializers for EXPRESS and IFC specifications. The mapping between IFC4Automation and the EMF also enables future work to be more simple, making it easier to develop new features and extensions to this model.

4.1.4 IFC compliance

The structure of the IFC4Automation extension follows the same design principles as the rest of the IFC specification. It consists of a set of entities, relationships and data types that are organized as described in Section 3.1.1. Each entity aims at representing one BA aspect (excluding some exceptions). Similarly to IFC, IFC4Automation also expects the definition of property sets for characterizing each element, enabling vendors to convey all the relevant information concerning a product inside these property sets. The concrete structure of the extension will be detailed in the following subsections.

4.1.5 Abstraction

Finally, constructs developed in IFC4Automation express each feature in a sufficiently high level manner, enabling the creation of generic BAS domains that are independent from the underlying technology, as shown in Figure 4.1. These abstract domains are able to be converted into a concrete implementation of any automation technology, such as KNX, BACnet or LonWorks, through specific translations. This makes possible the integration of multiple technologies in one BAS, favoring interoperability.

4.2 Architecture of the Solution

A model extension to the IFC specification requires adding a new set of concepts to an already existing model, that comes with a well-defined structure. For the sake of coherence, the new constructs must be developed taking into account the already existing ones. On the other hand, the newly created constructs must display a structural organization of their own, reflecting the architectural requirements of the automation domain. In the following, we describe the structure of IFC4Automation, bearing in mind the constraints posed by the rest of the IFC architectural setting, as well as the extension’s own design concerns and non-functional requirements.

4.2.1 IFC structural setting

Since IFC4Automation is an addendum concerning only the domain of BA, the most natural an coherent choice is to position it under the Building Control Domain sub-schema1, since it is the domain dedicated to the constructs concerning with automation. However, as stated before, the coverage regarding the logical aspects of BAS in IFC4 is limited, displaying a good coverage of physical elements, that contrasts with a lack of logical elements.

1IFC4 sub-schemas: http://www.buildingsmart- tech.org/ifc/IFC4/final/html/index.htm

44 IfcRel DefinesBy IfcPropertySet Properties

IfcObject IfcRel IfcRel DefinesBy IfcTypeObject DefinesBy Definition Type Properties

IfcRel IfcObject DefinesBy Object Definition

Figure 4.2: Illustration of the basic IFC typing mechanism. ObjectDefinitions can be defined through property sets (IfcRelDefinesByProperties), through a type object (IfcRelDefinesByType), and through another object, that serves as template (IfcRelDefinesByObject).

With respect to the inheritance and hierarchy of constructs, IFC4Automation has two root entities, IfcAutomationObject and IfcAutomationObjectType. IfcAutomationObject is positioned at the same level as the rest of the abstract object representations, such as IfcActor, IfcControl, IfcGroup, IfcProcess, IfcProduct, and IfcResource. As such, it inherits directly from IfcObject, which represents any physical or logical concept that has a proper semantic. Moreover, inheriting from IfcObject provides IfcAutoma- tionObject with the ObjectType attribute, used to connect a given instance of an object to its abstract type. Name and Description attributes are also present, inherited indirectly from IfcRoot. This derivation also provides a set of relevant built-in associations such as IsDeclaredBy, IsTypedBy and IsDefinedBy, which characterize the object recurring to another object, an object type, or a set of properties, respec- tively. These relationships, depicted in Figure 4.2, are major in the IFC specification, since they are the basis for defining objects. Other associations are also provided such as aggregation, assignment or nesting. For IfcAutomationObjectType the same approach was followed. It is placed under IfcType- Object, as well as with all the abstract type definitions such as IfcTypeProcess, IfcTypeProduct, and IfcTypeResource. IfcTypeObject defines an abstraction over the elements that typify other objects. If- cAutomationObjectType inherits the attributes ApplicableOccurence and HasPropertySets directly from its parent. The first defines the typed object class, for example an IfcAutomationDatapoint of IfcAutoma- tionGroup. The second represents a set of property sets that are associated with the type, and therefore to all the occurrences of that type. It also inherits a relationship, Types, which contain the objects that represent the occurrences of that type. Since IfcTypeObject inherits from IfcObjectDefinition, all the attributes and relationships derived from it are also included.

Placing IFC4Automation root elements under IfcObject and IfcTypeObject is the most practical ap-

45 proach, having in mind that this extension addresses a new set of concepts on the IFC ecosystem. Therefore, it should be placed at the same level of abstraction as the remaining high level concepts, namely IfcProduct, IfcProcess, or IfcTypeProduct, above which abstract elements such as IfcObject can be found. The hierarchy below IfcAutomationObjectType follows the same general principles and structure than IfcAutomationObject, since the type objects that exist for characterizing the occurrence objects are the same. For example, an IfcAutomationDatapoint is typed by IfcAutomationDatapointType.

4.2.2 Element Realms

Beneath IfcAutomationObject, IFC4Automation is arranged into three main realms, that address the three most general concerns of this work, which are the device topology, the structural configuration and the behavioral configuration. This division corresponds to the three main functions that BAS models cover, namely topology, structure, and behavior. The entities that are contained in each of these realms are detailed below.

Device topology realm contains the elements aiming at specifying control devices in terms of their physical and logical structure. The elements that belong to this realm define which datapoints are part of a given control device, how the datapoints are bound to each other, or which physical elements (IfcActuator or IfcController, for example) are related to which control devices. Entities such as IfcAutomationDatapoint and IfcAutomationControlDevice are contained in this area.

Structural Configuration realm organizes the constructs that capture the way datapoints can be or- ganized to form a more complex structure. Its elements enable the composition of datapoints in free groups, such as all the HVAC-related datapoints, as well as zoned groups, which have a cor- respondence with a given physical space. Inside the Structural Configuration realm are contained entities such as IfcAutomationGroup and IfcAutomationZone.

Behavioral Configuration realm encloses the elements that address the logical behavior of datapoints. These elements enable the definition of configuration setpoints (IfcAutomationSetpoint), as well as action sets (IfcAutomationScenario), which are predefined actuations that can be triggered by human users, environment constraints or even other datapoints.

4.2.3 Non-functional Requirements

The development of IFC4Automation encompasses the satisfaction of three main non-functional re- quirements which are (i) flexibility, in order to render the model less sensitive to change and evolution, (ii) complexity, since a simpler model is more easily readable, therefore, more easily used, and finally (iii) interoperability, which is of extreme importance, since this extension aims at being a common rep- resentation between several automation technologies. The design decisions that fulfill the requirements above are detailed as follows.

46 Flexibility is addressed through the organization of the model in realms, which are represented by ab- stract entities (such as IfcDatapointSet or IfcDevicePreset). This separation of concepts makes the development of new entities inside each realm easier, since part of their definition is reused. For example, a new kind of datapoint set can be defined by inheriting from the IfcAutomationData- pointSet, which already defines the core attributes and relationships. Moreover, the IFC structure itself makes possible the manipulation, without modifying its specification, of data about a given object through the definition of property sets. As explained above, every object inherits a relation- ship that binds it to a series of property sets that are defined upon the creation of an instance of the model. Therefore, device vendors can define their products through one or more property sets, without having to bind this definitions to the object structure.

Complexity is addressed by circumscribing the inherent complexity of IFC through the organization of the model extension in a way that makes it more comprehensible. Firstly, entities are organized in small hierarchies. This means the extension aims at having a shallow inheritance tree. Another aspect is the definition of a small, but cohesive set of entities to express all the information require- ments. Reducing the depth of the inheritance tree and increasing the cohesiveness of the entity specification reduces the effort required by the final user to discern the structure of the model. However, the IFC specification is still complex due to the wide range of concepts that it covers, and to its level of built-in abstraction.

Interoperability is achieved in the first place by extending the IFC specification per se. Since one of the main drivers for BIM is achieving interoperability, it is natural to assume that an extension to one of its main standard exchange formats favors interoperability. Moreover, each IFC4Automation element is designed to contain the attributes that are relevant for describing each aspect without depending on any technology. This abstract characterization will be concreted when the process of code generation occurs. At that time, abstract objects will be transformed into platform-specific objects.

4.3 Domain Model

IFC4Automation defines a set of elements that enables to capture the information requirements of BA presented on Section 2.4. This subsection intends to describe the domain model of IFC4Automation, detailing each construct in terms not only of its internal structure and but also the relationships with other constructs. The entities described in this section are summarized in Table 4.1. The semantic structure of IFC4Automation follows the one exposed in detail in Sections 2.2 and 2.3, where IfcAutomationDatapoint is the central element in the model structure. IfcAutomationDatapoints bind to each other through logical connections, and have a reference to their control devices. Datapoints can also be aggregated in groups or zones. Groups compose datapoints in a free way, while zones are used to associate set of datapoints with a given IfcSpace. Logical actions can be defined through device presets, which encapsulate a series of datapoint actuations, or setpoints. These actions, in turn, can be

47 IfcObject Definition

IfcObject IfcTypeObject

IFC4Automation Realm IfcAutomation IfcAutomation Object ObjectType

IfcAutomation IfcAutomation DefinesByType InputDatapoint InputDatapoint Type

IfcAutomation IfcAutomation DefinesByType ControlDevice ControlDevice Type

IfcAutomation DefinesByType IfcAutomation Setpoint SetpointType

Figure 4.3: Relationship between objects and their respective TypeObject definitions. Both objects and type objects inherit from IfcObjectDefinition, an are at the same level, though they have separate roles on the information model. triggered by a given event, as in the case of IfcAutomationEvents and IfcAutomationAlarms, by a user, as happens with IfcAutomationScenarios, or through a timely event such as IfcAutomationSchedule. In detail, the domain model of IFC4Automation is depicted in Figure 4.4, and the constraints that apply to the elements are described in Table 4.2. It is composed of the following elements.

4.3.1 Base Elements

The first elements to have in account when describing the IFC4Automation domain model are the ones at the higher level, namely IfcAutomationObject and IfcAutomationObjectType.

IfcAutomationObject is the root entity of IFC4Automation extension and parents the classes defined in the model. It inherits from IfcObject and serves as an abstraction for future work to add properties that are common to the entire model.

IfcAutomationObjectType is the most abstract type entity. As explained earlier, IFC defines type ele- ments in its structure, that act as predefined objects, to be referenced by the concrete objects — type objects help defining concrete objects. IFC4Automation follows this structural guideline and also defines type entities for every entity of the model, as detailed in Figure 4.3.

48 Component Entity IfcAutomationObject (none) IfcAutomationObjectType IfcAutomationDatapoint IfcAutomationInputDatapoint Device Topology IfcAutomationOutputDatapoint IfcAutomationControlDevice IfcAutomationDatapointSet Structural Configuration IfcAutomationGroup IfcAutomationZone IfcAutomationDatapointWrite IfcAutomationActuation IfcAutomationSetpoint IfcAutomationDevicePreset Behavioral Configuration IfcAutomationEvent IfcAutomationAlarm IfcAutomationScenario IfcAutomationSchedule IfcRelBelongsToDevice IfcRelBelongsToControlElement IfcRelGroupsDatapoint IfcRelTriggersEvent IfcRelInfluencesSpace Relationships IfcRelBindsToDatapoint IfcRelBindsByDatapoint IfcRelBindsByDatapointWrite IfcRelLocatesInSpace IfcRelDefinesSchedule IfcRelDefinesDatapointWrite

Table 4.1: Summary of the elements defined in IFC4Automation organized by type of element and with references for the component in which they are contained.

4.3.2 Device topology

The Device topology realm is responsible for capturing the concerns related to datapoints and their log- ical connections, using the classes IfcAutomationDatapoint, extended by IfcAutomationInputDatapoint and IfcAutomationOutputDatapoint, and IfcAutomationControlDevice, which are described below. In this realm, input and output datapoints bind to each other, enabling information to flow from the output data- points to the bound input datapoints.

49 IfcAutomationDatapoint is an abstract entity that represents a datapoint, capturing the common con- cepts of all types of datapoint, and enabling concrete datapoint implementations to inherit these properties. IfcAutomationDatapoint is defined by three attributes: A Unit, which is an optional text field for specifying the unit in which the datapoint value is measured, a DataType, which is an enumerate value for expressing the carrier type of the datapoint value such as Integer, Boolean, or String. This enumerate is still limited to the base data types. Other data types should be considered in the future. Finally, an Address attribute that contains the physical address of the datapoint. This address is optional, since it can be generated automatically by code generation facilities, when the implementation is generated. Moreover, IfcAutomationDatapoint participates in three relationships. The first relationship, HasDatapointSets, is a many-to-many relationship with IfcAutomationDatapointSet, which means that one datapoint can be contained in several datapoint sets, such as groups or zones. The second, HasControlDevice, encodes the many-to-one relation with IfcAutomationControlDevice, meaning that one datapoint belongs to one and only one control device. Finally, the HasSpace relationship exposes a many-to-one relationship with IfcSpace. This represents the influence that a given datapoint exerts in the specified space.

IfcAutomationInputDatapoint extends IfcAutomationDatapoint and represents an input datapoint, i.e., a datapoint that receives information from the network. In addition to the inherited relationships, IfcAutomationInputDatapoint defines HasDatapointWrites, a many-to-many relationship with IfcAu- tomationDatapointWrite, that represents the predefined actuations and the setpoints associated with the input datapoint, and also HasOutputDatapoints, a many-to-many relationship with IfcAu- tomationOutputDatapoint, that expresses the binding between the input datapoint and the output datapoints that provide it with information.

IfcAutomationOutputDatapoint is an output datapoint, that sends information to the network. IfcAu- tomationOutputDatapoint inherits from IfcAutomationDatapoint, defining additional relationships. The first, TriggersEvents, is a many-to-many relationship with a set of IfcAutomationEvent objects. This means that an output datapoint has a set of event conditions watching it, with the objective of triggering a given action depending of its value. Similarly to input datapoint, it defines Has- InputDatapoints, a many-to-many relationship with IfcAutomationInputDatapoint, that contain the IfcInputDatapoints that are bound to a given output datapoint, in other words, the datapoints to which an output datapoint provides data.

IfcAutomationControlDevice represents a device as a functional arrangement of datapoints. A de- vice has logical correspondence to the physical equipment, exposing a number of datapoints. IfcControlDevice has no attributes apart from the ones inherited from its parents. It defines two re- lationships. The first is HasDatapoints, a one-to-many relationship that contains all the datapoints that belong the control device. The second is the relationship HasDistributionControlElement, a one-to-many mapping to the set of physical control elements (such as IfcSensor of IfcActuator) which the control device represents.

50 Elements Constraint

When binding an output data- IfcAutomationInputDatapoint point or a datapoint write to an IfcAutomationOutputDatapoint input datapoint, the DataType IfcAutomationDatapointWrite and Unit attributes must be the same.

It is necessary to assert if there IfcAutomationDatapoint are no duplicate addresses.

The heterogeinity of interfaces IfcAutomationDatapointSet of the contained datapoints must be dealt with when converting to a more strict domain.

The trigger value must be vali- dated according to the DataType IfcRelTriggersEvent and Unit attributes of the target output datapoint.

Table 4.2: Systematization of the constraints that apply to the model the IFC4Automation.

4.3.3 Structural Configuration

The Structural Configuration realm, that handles the composition of datapoints in higher level structures, encloses IfcAutomationDatapointSet, IfcAutomaitonGroup and IfcAutomationZone. The elements that belong to this realm act as a unique reference to a group of datapoints, in the sense that interactions with a given datapoint set represent interactions with each datapoint that belongs to the set. A more detailed view on these elements is presented in next description.

IfcAutomationDatapointSet is an abstract class for defining the common features that represent ag- gregations of datapoints, such as groups or zones. It has no attributes apart from the ones inherited from the parent classes, and defines a many-to-many relationship with IfcAutomationDatapoint, called Datapoints, that represents the datapoints that compose the set.

IfcAutomationGroup is a base implementation of IfcAutomationDatapointSet. It is used to define data- point groups with a free taxonomy. Despite some concrete technologies enforce datapoint groups to share the same interface (e.g. all the datapoint must be inputs of the same data type), there is no need for doing so at this level of abstraction, since model transformations can deal with these kinds of restrictions depending on the target technology. IfcAutomationGroup does not define any special attributes or relationships, and it exists as a concrete implementation of IfcAutomationDe- vicePreset, used for conceptual organization.

IfcAutomationZone describes a group of datapoints that is associated with or contained in a given space (of the building). IfcAutomationZone enables the management of the BAS as a composite

51 of zones. Similarly to IfcAutomationGroup, not all datapoints need to share the same interface. IfcAutomationZone defines no additional attributes, and has a many- to-many relationship with IfcSpace (to represent which building spaces are associated with a given zone object).

4.3.4 Behavioral Configuration

The Behavioral Configuration realm consists of the elements that address the behavioral aspects of BAS, in a sense these objects coordinate the information flow between datapoints. The new behavioral elements added are IfcAutomationDevicePreset, IfcAutomationEvent, IfcAutomationAlarm, IfcAutoma- tionSchedule, IfcAutomationDatapointWrite, IfcAutomationActuation and IfcAutomationSetpoint. The el- ements of this realm bind to input datapoints and write a set of values to these datapoints, depending on several situations such as events or schedules. The following description summarizes each one of these elements.

IfcAutomationDatapointWrite is an abstract class that encapsulates the assignment of a value to a datapoint. It defines three attributes which are: (i) writeValue, a String containing the target value to write, (ii) dataType, that specifies the carrier type of the value, and (iii) one unit, that specifies the unit in which the value is expressed. Model transformations must ensure that the data type of the write is consistent with the one of the datapoint. It relates with IfcAutomaionDevicePreset in a many-to-many basis (HasDevicePresets), meaning that a datapoint write can be contained in multiple device presets. It also has a many-to-many relationship with IfcAutomationInputDatapoint, called HasInputDatapoints, that encodes the set of input datapoints to which the write action is bound.

IfcAutomationActuation is a specialization of IfcAutomationDatapointWrite that represents writes as interactions between datapoints. This class contains no additional attributes nor relationships, but is justified due to the need of structural specialization, i.e., for separating between two different concepts.

IfcAutomationSetpoint also derives from IfcAutomationDatapointWrite, and represents assignments to configuration input datapoints such as a thermostat setpoint value. As in the case of IfcAutoma- tionActuation, this class exists with the intent of distinguishing between the attribution configuration values (setpoints), and the actuations on an input datapoint.

IfcAutomationDevicePreset is an abstract entity that represents an action preset through a set of dat- apoint writes and centralizes the shared properties of the classes that represent a set of actions over a set of datapoints. It has no attributes, but defines a many-to-many relationship (HasData- pointWrites) with IfcAutomationDatapointWrite, that specifies the datapoint writes which it contains.

IfcAutomationEvent is an implementation of IfcAutomationDevicePreset. This element triggers a set of actions on a set of datapoints, depending on a target value on another datapoint. It contains no additional attributes besides the ones inherited, and defines a many-to-many relationship (Has-

52 TriggerDatapoints) with IfcAutomationOutputDatapoint that represents the datapoints on which the trigger condition is dependent. Each relation class (IfcRelTriggersEvent) defines a trigger value.

IfcAutomationAlarm represents a particular kind of IfcAutomationEvent, when the action to trigger is due to an exceptional event, like an error on a device, or a emergency situation on the building. It defines no additional attributes nor relationships.

IfcAutomationScenario implements a human-triggerable preset for devices. It inherits from IfcAutoma- tionDevicePreset, but does not define any additional attributes or relationships. It was created with the objective of separating the concept of scenario from the abstract device preset.

IfcAutomationSchedule also inherits from IfcAutomationDevicePreset and triggers a given set of ac- tions depending on a timely event. Therefore, it is composed of a one-to-one relationship with IfcTaskTimeRecurring, that associated it with a target timer trigger.

53 IfcRel GroupsDatapoint

IfcRel * InfluencesSpace * 1 Control 1 IfcDistribution Datapoint * * Device ControlElement IfcRelBelongs IfcRelBelongsTo ToDevice ControlElement * Datapoint Set IfcRelBinds 1 ByDatapointWrite Output * * Input * IfcSpace Datapoint Datapoint IfcRelBinds * ByDatapoint Device * Topology Group Zone * IfcRel

54 LocatesInSpace * Device * * Datapoint Preset Write Structural IfcRelDefines Configuration DatapointWrite

* Event Scenario Schedule Setpoint Actuation

IfcRelTriggersEvent 1

IfcRelDefines 1 Schedule Alarm IfcTaskTime Behavioral Recurring Configuration

Figure 4.4: Information model of IFC4Automation, arranged according to three realms. 4.3.5 Relationships

In addition to the realms described earlier, IFC4Automation also defines constructs that represent re- lationships between the objects. These relationship entities define the objects that must be associated with both ends of the relation, and their multiplicity. It is also possible to define constraints over the elements as well as relation attributes. The relationships created to support the model extension are the following.

• IfcRelBelongsToDevice, for composing the datapoints that belong to a device.

• IfcRelBelongsToControlElement associates a control device with the physical devices it represents.

• IfcRelGroupsDatapoint, associates one or more datapoints with a given group.

• IfcRelTriggersEvent specifies the datapoints that trigger an action on an event. This relationship has a textual attribute called TriggerValue, which specifies the value on which the event will trigger the device preset. Further evolutions of this relationship must deal with the multiplicity of forms this TriggerValue can take, namely supporting value intervals and complex types and conditions.

• IfcRelInfluencesSpace, captures which datapoints influence a given space of the building. This relation defines an enumerated attribute named InfluenceType, that specifies the type of influence exerted on the target space. A deeper study of the influence types is needed on future develop- ments.

• IfcRelBindsToDatapoint is an abstract relationship that binds multiple input datapoints to a con- forming entity specified by the children, providing input datapoints with data.

• IfcRelBindsByDatapoint inherits from IfcRelBindsToDatapoint, binding a set of input datapoints to an output datapoint.

• IfcRelBindsByDatapointWrite that inherits from IfcRelBindsToDatapoint, to bind a set of input dat- apoints to a datapoint write (actuation or setpoint).

• IfcRelLocatesInSpace captures which physical space corresponds to a zone object.

• IfcRelDefinesSchedule relates a schedule object with the a task object that describe the time intervals in which the schedule occurs.

• IfcRelDefinesDatapointWrite connects a given device preset with the datapoint writes that com- pose it.

4.4 Model Transformation

For proving IFC4Automation can be mapped into another automation model, this work encloses the development of a model transformation that converts IFC4Automation models into EIB/KNX models, re- curring to the Epsilon platform, introduced earlier 3.2.1.The objective of this transformation is to generate

55 KNX installation descriptions from IFC4Automation models. The converted models are supposed to be fed into code a generation tool for converting them into code that can be deployed into a KNX bus. The code generation step is out of the scope of this work. For achieving this purpose, it is necessary to define the mapping between these two information models, using the ETL. Since the specification of KNX is not modeled under ecore, it is also necessary to develop such representation. This section details these artifacts in terms of the their structure and the motivations behind each decision.

4.4.1 The Epsilon Transformation Language

As described in Section 3.4.2, ETL is a rule-based model-to-model transformation language. Mappings are defined in ETL in form of rules that declare the input constructs and output constructs and enable to specify which attributes of the source model constructs are to be converted to which attributes in the target models. Rule definitions have an inheritance mechanism for dealing with construct inheritance. Rules can be marked abstract, meaning that they cannot be instantiated, lazy, meaning they have low priority in case of rule collision, primary, raising the priority of the rule, and greedy, which means that the rule will evaluate for the instances of the construct, as well as for the instances of its sub-types. It is also possible to define pre- and post-conditions that precede and follow the execution of each rule. ETL also provides for function definitions, for executing auxiliary tasks on the model transformation, such as id generation.

4.4.2 The KNX Ecore model

It is well-known in the BA community that the information model of EIB/KNX is not officially modeled conforming to a metamodeling language such as UML or Ecore. Hence, to enable the construction of the M2M transformation between IFC4Automation and KNX, this work developed a reduced ecore model of KNX, using the EMF and the Ecore format, according with the description of the model specification detailed in the Section 3.2.1. The resulting model, depicted in Figure A.1, covers basic constructs of KNX, namely Datapoint, Group Object, Group Address, and Functional Block. As explained in Section 3.2.1, a Datapoint is the central piece of the model. Each datapoint is com- posed of a sequential integer ID, a textual name and description, a unit in which the value is measured in, the top and bottom limits that the value can take and also the data type of the value. Datapoints also have a Setpoint attribute for storing a predefined configuration, although this does not explicitly map to the KNX information model. Datapoint has a many-to-one relationship with FunctionalBlock, which denotes the KNX functional block to which it belongs, and a one-to-one relationship with group object, that specifies its group object. Functional blocks are logical aggregates of datapoints that represent a device. Each functional block is characterized by an integer ID, a name and a description, both strings. Analogously to datapoints, functional blocks have a one-to-many relation with datapoints. There is also a one-to-many relationship with the group objects that it contains. Group objects are the entity that ag- gregates the group- related information of a datapoint such a information flows or listeners to network

56 addresses. Each group object is composed of an ID, a name and a description. Group objects relate to datapoints through a one-to-one relationship, as explained earlier. There are also two relationships with group address, a many-to-many relationship that specifies the listening group addresses, and a one-to-one that specifies the writing group address of the group object. Finally, this model defines group addresses which represent binding addresses. These are used to create all sorts of datapoint binding in KNX, such as simple one-to-one binding, grouping or zoning. Each group address has an Id and an address. Typically, the format of the address determines the kind of binding the group address en- codes. The first part encodes the zone, the second a given group and the third the device. For example, the fourth device of the HVAC system located in the third room may have a group address like ’3.2.4’. Group addresses have a one- to- many relationship with group object, that represents the objects that are spanned by the group address.

4.4.3 IFC to KNX mapping

The model transformation that maps IFC4Automation to KNX is defined by a set of specific rules and auxiliary methods. This section describes these elements, detailing each equivalence between the properties from the source and the target model. Please refer to Appendix B.1 for the code of the rules. A summary of the rules is presented in Table 4.3. Firstly, the transformation defines a set of global variables that represent the seeds for the group, zone and device parts of a group address. Each time a mapping involving one of these constructs is trig- gered, the seed increments and a new group address is generated. There are also generateNewGAId, generateNewGOId, and generateNewGroupAddress, which are the operations that are responsible for generating the IDs and the group addresses, respectively. The rules that compose the transformation are the following.

IFC4Automation Construct KNX Construct Transformation Rule DatapointToDatapoint IfcAutomationDatapoint Datapoint InputDatapointToInputDatapoint IfcAutomationInputDatapoint Datapoint OutputDatapointToOutputDatapoint IfcAutomationOuputDatapoint Datapoint SetpointToSetpointAttribution IfcAutomationSetpoint Setpoint ControlDeviceToFunctionalBlock IfcAutomationControlDevice FunctionalBlock BindingToGroupAddress IfcRelBindsByDatapoint GroupAddress DatapointSetToGroupAddress IfcAutomationDatapointSet GroupAddress GroupToGroupAddress IfcAutomationGroup GroupAddress ZoneToGroupAddress IfcAutomationZone GroupAddress

Table 4.3: Summary of the transformation rules in terms of the source and target constructs.

DatapointToDatapoint transforms IFCAutomationDatapoints into KNX Datapoints. It is an abstract rule that contains the steps that are common for translating all kinds of datapoints. This rule consists

57 of directly mapping the ID, Name, Description and Unit attributes, since they are present in both source and target models. It also implies the creation of a group object for storing the network information of each datapoint. The data type of the IFC4AutomationDatapoint is converted (using the toKNXDatatype operation) into the group object data type.

InputDatapointToInputDatapoint descends from the rule DatapointToDatapoint and converts IFCAu- tomationInputDatapoints into KNX datapoints of type input. Apart from the parent rule steps, it also sets the flow type of the datapoint to “INPUT”.

OutputDatapointToOutputDatapoint descends from DatapointToDatapoint. This rule transforms IF- CAutomationOutputDatapoints into datapoints of type output by setting the flow type to “OUTPUT”.

SetpointToSetpointAssignment assigns the value of a IfcAutomationSetpoint to a KNX datapoint by checking the compatibility between the data types and units of both IfcAutomationSetpoint and the KNX Datapoint. If they are equal, the IfcAutomationSetpoint writeValue is assigned to the Setpoint property of the KNX Datapoint. This rule does not strictly transform a IfcAutomationSetpoint into another object, hence the rule target is null. Further work must ensure that this validation is carried in a more detailed way, parallel to the enrichment of the data types, and that the Setpoint value is correctly assigned to the target datapoint.

ControlDeviceToFunctionalBlock maps IfcAutomationControlDevices to functional blocks. Although functional blocks can represent not only devices but also other functional aggregates of datapoint, this mapping addresses only functional blocks which map to control devices. This rule maps directly the source ID, Name and Description attributes into the same attributes on the target. It also triggers the rules that convert the datapoints that belong to the control device, and assigns them to the functional block.

BindingToGroupAddress transforms a IfcRelBindsByDatapoint relationship into a KNX group address with a single binding. In other words, with an output datapoint writing to it and an one or more input datapoints reading from it. In our implementation, the same group address is reused for binding a single output to several inputs. Hence, this rule starts by setting the ID and the address of the group address. The address is generated recurring to the generateNewGroupAddress operation, that increments the device seed and then returns a new address. The address is then assigned to the output datapoint as main address and added to the listening group address list of each input datapoint.

DatapointSetToGroupAddress is an abstract rule for transforming all kinds of IfcAutoamtionData- pointSet objects into multiple binding group addresses, where multiple output and input datapoints read and write, or multiple input datapoints form a logical aggregation of functionality. Firstly, the rule directly maps the source ID into the target. Then, the group address is added to the group address listener list of each input datapoint. The address of the group address is determined by the children rules, depending on the kind of datapoint set. Further research must ensure that

58 the datapoints contained in the group follow the same interface, in other words, have the same datatype, unit and format.

ZoneToGroupAddress extends DatapointSetToGroupAddress to map an IfcAutomationZone into a group address by assigning a zone address to the group. Apart from the logic executed on the par- ent, this rule attributes the group address by calling generateNewGroupAddress, that increments the zone seed and resets the base seed, returning the new address.

GroupToGroupAddress also extends DatapointSetToGroupAddress to map IfcAutomationGroups into group addresses by the assignment of an address that represents a datapoint group. For doing so, it bases on the generateNewGroupAddress operation.

4.5 Modeling Methodology and Tools

The development of the transformation was organized in two major phases, the modeling phase, where the BIM extension is constructed, compiled and generated, and the transformation phase, that consists of the actual execution of the M2M transformations. This section describes the methodology followed.

4.5.1 Modeling Pipeline

In order to obtain a syntactically correct, complete and functional model (in terms of enabling its instan- tiation), this work followed the below steps.

1. The extension of IFC was coded using JSDAI for the Eclipse platform, that enables to edit and han- dle EXPRESS model files. JSDAI provides a set of tools for developing EXPRESS and EXPRESS- G files, such as an editor with syntax highlighting and error correction, compiler, early-binding class generator and EXPRESS-G viewer. The JSDAI API enabled the development to be more fast and easily validated, since the resulting models were compiled using the EXPRESS compiler.

2. After compiling a correct version of the model extension, the next step consists of generating the equivalent ecore model for the EXPRESS file. This is done using a utility class from BIMserver called Express2EMF, that takes as constructor the EXPRESS file of the model, the target package name and the target ecore file and writes an ecore model equivalent to the inputted EXPRESS.

3. With an Ecore model in hand, the next stage is to generate the early- binding Java classes that represent the model. For achieving this goal it is necessary firstly to create the generator model, an intermediate model that contains properties for specifying the details of the generation, such as target directories, inheritance strategies and other variables required for the generation. Since this work presents an extension to IFC and uses BIMserver as tool for handling EMF, the properties used were based on those of the IFC4 generator model, that is built in BIMserver.

4. Finally, the early-binding classes were generated from the Ifc4Automation.genmodel file, and stored together with the remaining IFC versions, on BIMserver.

59 Modeling <> Phase

ExpressToEMF IFC4 Ifc4Automation. Automation.exp (BIMserver) ecore

<> <>

Ifc4Automation. ecore EMF Ifc4Automation Package.java

Transformation <> Phase

Ifc4Automation Ifc4Automation. Package.java ecore KNX.ecore

CaseStudyScript Building Building Building.ifc .model IfcToKNX.etl .model

Figure 4.5: Solution pipeline. The modeling phase consists of the steps taken to create and gener- ate the model of IFC4Automation extension. The transformation phase entails the steps taken for the specification and execution of the transformation from IFC4Automation to another model.

60 At this point is possible to create, either by parsing or programmatically, an IFC4Automation model, and storing it using the serializers from BIMserver. The next section details the steps taken to transform IFC4Automation instances into KNX (or instances of other models).

4.5.2 Transformation Pipeline

Once the extension is developed and the classes generated, it becomes possible to create or read instances of buildings, manipulate them, and transform them other model instances. To this end, the following steps must be followed.

1. Create or read the model. In this work, since there is no other way for editing IFC4Automation instances besides writing directly into the file, which is an extremely complex task, an IFC4 in- stance file is read and modified by a Java class called PopulateTagusIFC. To this end, the building instance must be parsed using a BIMserver class (Ifc4StepDeserializer). Since BIMserver does not generate the object UIDs automatically, it is necessary to set them manually, by calling the method setObjectOids(). Once the model used as example is still conforming to IFC4, it must be converted into an instance of IFC4Automation using Ifc4ToIfc4AutomationConverter, a plug-in created for converting IFC4 models to IFC4Automation models. This class takes a IFC4 and a IFC4Automation model instance and converts one into another. After the conversion, the object ID seed needs to be fixed since the converter adds existing objects that do not increment this counter.

2. The next step consists of filling the model with an automation scenario, by adding the desired objects (such as datapoints, bindings, or groups), and serializing it into the standard XML-based format of EMF. This is done since the ETL engine cannot parse EXPRESS files, although there is a serializer for IFC4 and IFC4Automation.

3. Once the building model is populated with the automation domain and serialized, the next phase consists of feeding this file to the ETL engine, in conjunction with the TransformToKNX.etl file, which specifies the transformation. The process is triggered by an Ant buildfile called launch.xml file, that contains a set of properties for the transformation execution, such as, for example, the models and the instances location. Once the transformation is completed, the resulting model is serialized in the EMF standard format.

61 Chapter 5

Evaluation

In order to guarantee that our approach meets the requirements that were elicited in Section2, both IFC4Automation and the M2M transformation must be evaluated. In order to validate the IFC4Automation by itself as a model, the most appropriate and coherent approach is to use to the same model evaluation methodology applied to the models described in Sec- tion3, that consists of evaluating models with respect to the dimensions of completeness, complexity, flexibility and domain applicability. This evaluation methodology is introduced in detail in Section 1.3.2. IFC4Automation aims at creating representations of automation systems for use in several tools BA deployment and commissioning tools, EMS that use the BAS for taking energy efficient measures and many others. Currently there are no such tools, that can work with the developed extension. Hence, this work develops a prototype model transformation for verifying the model functionality. This M2M transfor- mation will be validated by means of a case study on the room 1.58 of Instituto Superior Tecnico´ Tagus- park (IST-T) campus. The KNX-based BAS installed in this room was modeled using IFC4Automation. Then, the resulting model was fed into the IFC to KNX transformation and the resulting KNX model was compared to the actual room deployment. The next sections describe the aspects of validation greater detail.

5.1 Model Evaluation

For evaluating IFC4Automation as a model for handling BAS information, the methodology described back in Section 1.3.2 will be used. In the following, each subsection addresses one dimension from the methodology, visiting each one of the concerns that is evaluated in each dimension. The completeness section traces the constructs of the model into the BAS aspects that were exposed in Section2. Com- plexity asserts the score of the model in what concerns to the ”Model/Metamodel”, ”Number of Entities” and the ”Depth of th Inheritance Tree” metrics. Flexibility evaluates the model in terms of the metrics ”Open Specification”, ”User-defined Entities” and ”Extendable Model”. Applicability determines the BAS levels to which the extension is most suited. Finally, this section discusses the evaluation obtained for IFC4Automation in contrast with the other information models analyzed in Section3.

62 5.1.1 Completeness Assessment

With respect to model completeness, IFC4Automation defines constructs that aim at covering of the automation and management levels of the BAS pyramid. Since the solution extends the informa- tion model of IFC, it is assumed that all the aspects covered by the IFC specification are included in IFC4Automation. Firstly, Influence Zones is addressed by the entity IfcRelInfluenceSpace, which repre- sents the influence relation between a datapoint and a building space. The type of relation is encoded in the InfluenceType attribute. Bindings are covered by the IfcRelBindsToDatapoint, IfcRelBindsByDat- apoint and IfcRelBindsByDatapointWrite relationships. The first is an abstract entity that defines the input datapoint that is bound to the relation. The second binds an output datapoint to the input datapoint and the last one binds the input datapoint to a datapoint write (an actuation or a setpoint). The Data- point List aspect is addressed by the existence of entities to capture the concept of datapoint, such as IfcAutomationDatapoint, IfcAutomationInputDatapoint and IfcAutomationOutputDatapoint. IfcAutoma- tionDatapoints represents the abstract characteristics of a datapoint. The remaining constructs capture the specialization of input and output datapoints, respectively. In what concerns to Datapoint/Equipment Relation, IFC4Automation defines two entities called IfcRelBelongsToDevice and IfcRelBelongsToCon- trolElement. The first relates a datapoint with its control device and the second relates the control device with the physical equipment (such as IfcSensor or IfcActuator). Groups and Zones aspect is addressed by the three main classes of the structural configuration realm, IfcAutomationDatapointSet, IfcAutomationGroup and IfcAutomationZone, and the relationship IfcRelLocatesInSpace. IfcAutomation- DatapointSet is an abstract entity for representing a set of datapoints, IfcAutomationGroup represents a concrete datapoint group and IfcAutomationZone represents a group that relates with an IfcSpace through IfcRelLocatesInSpace. Schedule requirement is met through the IfcAutomationSchedule en- tity, that contains a set of datapoint writes and relates them with a given timely schedule. The Sce- nario aspect is met by the IfcAutomationScenario construct, that contains a set of datapoint writes. Alarms/Events concern is addressed by two entities, IfcAutomationAlarm and IfcAutomationEvent, that are connected to the trigger datapoints through IfcRelTriggersEvent, and contain a set of datapoint writes that represent the actions to take on trigger. Finally, the concept of Setpoint is addressed by IfcAutomationSetpoint, that associates a datapoint write to a given input datapoint.

5.1.2 Complexity Assessment

In terms of complexity, IFC4Automation follows the same evaluation of the rest of the IFC specification, since the base model, which is very complex, is maintained. However, the model extension tries to hinder the complexity in the extension classes. In terms of the Model/Metamodel metric, IFC4Automation is considered a model, since it captures the BAS aspects through concrete classes, at the M1 level of MDE. As for the number of entities, and since it is an extension to IFC, IFC4Automation counts 822 entities (766 from standard IFC and 55 from the extension itself). Since IFC already defines a very high number of constructs, the extension tried to limit the number of new classes in order to circumscribe the complexity of the model while fulfilling the flexibility requirement.

63 5.1.3 Flexibility Assessment

As explained in Section 1.3, the evaluation of flexibility consists of three aspects. In what concerns to the first one, “Open Specification”, IFC4Automation follows the openness of IFC, having its source open to modifications from the community. For rendering it capable of fulfilling the second metric, “User-defined Entities”, IFC4Automation remains compatible with the property set mechanism. Through property sets, users can define specific object types for characterizing building objects, hence defining their own ob- jects. Finally, IFC4Automation remains compliant with the third flexibility metric, of being an “Extendable Model”, since it provides a set of abstractions that enable model modification, namely entities such as “If- cAutomationDatapointSet”, or “IfcAutomationDevicePreset”, that centralize the main features of abstract concepts, for facilitating the creation of new entities.

5.1.4 Applicability Assessment

With respect to applicability, the field level aspects are already covered mainly by standard IFC4, except for Influence Zones, that are spanned by IFC4Automation. The remaining aspects of BAS levels not covered by IFC, like the automation and management ones, are integrally covered by IFC4Automation. Although the IFC standard partially covers some aspects on the management level, IFC4Automation defines new concepts that entirely cover these without relating with the native IFC entities. Therefore, in terms of applicability, IFC4Automation stands as the only model considered by this work that is capable of modeling every level of BASs. This stands as an expected outcome, since the main driver of this work was to develop a model that extends BIM coverage span on the entire BA domain aspects.

5.1.5 Discussion

Facing the remaining studied models, IFC4Automation stands as the second most complex, following OPC UA and followed by the standard IFC4. Since IFC4Automation extends IFC standard specification, it includes the complexity inherent to IFC. Despite is necessary to slightly increase the complexity of the IFC4 by adding 55 new classes, IFC4Automation remains with the same inheritance tree depth. It is also worth noting that this new 55 classes cover the remaining 9 BAS aspects.

Regarding flexibility, as we have seen in Section 5.1.3, IFC4Automation stands as the second most flexible, behind OPC UA. In spite of directing efforts to make IFC4Automation a flexible model, this work had also to cope with complexity concerns, which would be greatly impacted if a trade-off would not be considered.

Finally, as mentioned earlier, IFC4Automation is the only model that covers all the aspects of BASs, and therefore, is the only model that is suited for modeling BA scenarios on field, automation and man- agement level. Therefore, it can be said that IFC4Automartion covers the whole set of aspects of BAS.

64 5.2 Case Study: Sustainability Systems Room

In order to further validate that IFC4Automation is adequate to express automation scenarios that are convertible to BAS installation descriptions (conforming to information models of particular automation systems), this work encompasses the realization of a case study that consists of modeling an automation scenario installed in room 1.58 at IST-T and comparing it with the real installation. This case study evaluates whether the model generated from an IFC4Automation description is able to express the same logic as the currently deployed KNX configuration. This case study uses the Room 1.58, on the first floor

3 ofEQUIPAMENTOS$DOMÓ IST-T to test the model. This roomTICOS is equipped$ with a KNX installation, and exposes datapoints for controlling mostly lighting, HVAC and blind control. We will now turn to describing with detail the automation scenario that is used in this case study, as !ApresentamGse! seguidamente! os! esquemas! da! sala! e! dos! quadros! interior! e! well as the steps taken to realize it. exterior,!onde!estão!representados!e!identificados!os!diferentes!equipamentos.! ! 5.2.1Esquema!dos!equipamentos!no!interior!da!Sala!1 The Room 1.58 G58:! !

! ! Figure$ 5.1: IllustrationEquipamento of the automation$ equipment installed inDescrição Room 1.58.$ (1-8) fluorescent electronic ballasts; (9) humidity sensor; (10)electric board; (11-12) touch screen; (13) switch; (14-16) Door lock Armadura!1!!2x35W! G! controls;1$ (18-19) sound speakers; (20-22) blind controls; (23)weather station; (24) TV; (25) LEDs Philips!refª!5999236! Balastro!electrónico!regulável! The room 1.58Armadura!2!!2x35W! is equipped with a KNX! bus, which controls the followingG! services: 2$ Philips!refª!5999236! Balastro!electrónico!regulável! Lighting with eightArmadura!3!!2x35W! fluorescent luminaries! installed in the ceiling are controlledG! in pairs by three control 3$ units. Philips!refª!5999236! Balastro!electrónico!regulável! Armadura!4!!2x35W!! G! Access4$ Control with a magnetic lock that opens with an RFID card reader. Philips!refª!5999236! Balastro!electrónico!regulável! Sound SystemArmadura!5!!2x35W!controlled by the BAS, through! an amplifier. G! 5$ Philips!refª!5999236! Balastro!electrónico!regulável! Blind Control through a set of blinds covering every window controlled by the BAS. Armadura!6!!2x35W!! G! 6$ Environment sensingPhilips!5999236with a weather! station. Balastro!electrónico!regulável! Armadura!7!!2x35W!! G! TV7equipment$ controlled by the BAS.

Philips!refª!5999236! Balastro!electrónico!regulável! ! Armadura!8!!2x35W!! G! Power8$ Outlets can be enabled or disabled by the system. Philips!refª!5999236! Balastro!electrónico!regulável! 9$ Berker!75900056! 65 Sensor!de!humidade! 10$ Quadro!eléctrico! G! 11$ Touch!Screen!com!moldura! G! 12$ Zennio!Z38! Touch!screen! 13$ Linksys!srw208G! Switch! Network!Concept,!Lda. ! 14$ IBA80! Trinco!da!porta! – 15$ Digiprox!CDVIDGM1! Controlador!de!porta!RFID! NWC! 7!!!

! HVAC Unit also controllable by the system.

Since the BAS installed in this room is used for testing purposes, the datapoints that control these services are not bound to each other, since they are exposed on the network and controlled by the tools that connect through an IP gateway. Datapoints in this room are also grouped by functionality using group addresses.

5.2.2 Base installation

This section presents the KNX configuration of the automation scenario used for this evaluation in terms of the devices installed, the datapoints exposed by each device and their group addresses (whether they represent groups or not). The devices that equip the test room are detailed in Table C.1, as well as the datapoints that they expose and their group addresses. Each device typically exposes one input and one output datapoint per parameter, although some exceptions can be found such as in the case of the lighting ballasts. Another series of group addresses enables writing to all the datapoints that each group address contains. Table 5.1 lists the group addresses that are configured in the room 1-58 automation scenario. KNX imposes that all the datapoints belonging to a group address must listen to the same address.

Group Datapoints Group Address Power Sockets 0/0/1 - 0/0/12 0/0/13 Lights Board 0/7/0 - 0/7/1 0/1/0 Lights Middle 1 0/7/2 - 0/7/3 0/1/2 Lights Middle 2 0/7/4 - 0/7/5 0/1/4 Lights TV 0/7/6 - 0/7/7 0/1/6 All Lights 0/7/0 - 0/7/8 0/1/8 Move All Blinds 0/2/1, 0/2/4, 0/2/7 0/2/10 Stop All Blinds 0/2/2, 0/2/5, 0/2/8 0/2/11 Set Position All Blinds 0/2/3, 0/2/6, 0/2/9 0/2/12

Table 5.1: List of group addresses available in room 1.58, organized by name. Each group has a set of datapoints it contains and a group address.

It is important to note that the installation schema is somewhat uncommon, since the datapoints are not bound to each other, as is commonplace in the KNX configuration philosophy—however, that is how the technicians installed it. The datapoints are all exposed to the bus, being controlled by external commands through a gateway. Also, the installation documentation mentions addresses that take action on, or measure several datapoints, which may be seen as groups. However, some of these do not refer to datapoints that actually exist (for example Lights Board Status@0/1/3 or Power Sockets Status@0/0/14), which indicates that these represent hardware groups, in other words, datapoints that represent physical aggregation of devices themselves. Though they represent several devices or datapoints, these are modeled as datapoints and not groups. Moreover, there is nothing in the installation documentation that mentions the existence of functional blocks. Despite this fact, it is assumed that each device represents

66 a functional block, containing a set of datapoints. There is a total of 121 objects in the input model, where 92 represent BAS aspects such as devices, datapoints and groups, and 29 represent relation objects.

5.2.3 Room 1.58 IFC4A model

For creating the IFC4Automation model of the room 1.58, it was necessary to modify an already ex- istent IFC model of IST-T, by means of a created Java script named PopulateTagusIFC. Firstly, this model was loaded and converted to the IFC4Automation schema, which is no different of IFC4 except for the added classes. This is done recurring to the Ifc4ToIfc4AutomationConverter class. Secondly, the model is populated with the elements from Table C.1 and Table 5.1, through the instantiation of Java early-binding classes that represent each construct. Details regarding the modeling are described below in this section. Finally, the modified in-memory model needs to be serialized. As depicted by Figure 5.3 and Figure 5.2, the script serializes the model to both a XML-based EMF representation and IFC4Automation. The former serialization, done recurring to a EMF base serializer, serves as input for the TransformToKNX transformation, since it does not recognize the ”.ifc” format. The latter is done implementing a BimServer STEP serializer named Ifc4AutomationStepSerializer, and proves that the existent in-memory model is capable of being serialized to a IFC format.

Figure 5.2: Excerpt of the resulting IFC4Automation model for Room 1.58. The first line depicts the definition of a IfcAutomationControlDevice.

With respect to the modeling of the automation scenario, the following approach was followed. Each device listed in Table C.1 was modeled as an IfcAutomationControlDevice. The name, description and OID were set according with each one of the devices, as Figure 5.3 depicts. Each datapoint exposed by the each device was modeled, according to the type of datapoint, as an IfcAutomationInputDatapoint or an IfcAutomationOutputDatapoint, where the attributes OID, name, description, dataType, unit and address were set according to the datapoints characteristics. The dataType attribute is always set to USERDEFINED since the list of available datatypes is still an open topic for future work. The individual group addresses for each datapoint were specified in modeling time, since the the installation documen- tation already specified them. Otherwise they could be generated upon transformation, however, in this case this would led to discrepancy between the addresses from the documentation, which are specified in Table C.1, and the ones generated by the transformation. The containment relation between each device and its exposed datapoints was modeled recurring to an IfcRelBelongsToDatapoint per device. The device was inserted in the device end of the relation and the set of datapoints it exposed were in- serted in the set of relating datapoints. For modeling each group of datapoints, such as stopAllBlinds, an

67 IfcAutomationGroup was instantiated with the name and description attributes set. Similarly to device, each group is related with the datapoints it groups through one relation object, this time IfcRelGroups- Datapoint. The group was inserted in the one end of the relation, and the datapoints that compose it were added to the set that figures on the other end of the relation.

Figure 5.3: Excerpt of the resulting EMF model for room 1.58. The highlighted construct represents a IfcRelBelongsToDevice, which properties are detailed in the properties tab on the lower section.

It is worth noting that none of these elements were connected to the physical component of the building. This is due to the fact that the 1st floor of the IST-T building, where the room 1.58 is located is not included in the model. Moreover, the IFC model only specifies the structural elements (walls, floor, pillars) that compose the building, lacking the modeling of each room as a space, hence, the configuration could not be linked to any element. However, for realizing this linkage, one simply has to relate the control devices with the respective IfcDistributionControlElement, that has a well defined geographical location. An illustrative example for the blind control mechanism is depicted in Figure 5.4, where the each blind exposes four datapoints (position, positionSet, move, and stop), and these are grouped by function (stopAll, positionAll, setPositionAll, and moveAll).

5.2.4 Generated Installation

As mentioned in the previous section, one of the room 1.58 IFC4Automation representations serialized by the populate script intends to be fed into the TransformToKNX transformation. Basically, this file keeps representing the constructs conforming to the IFC4Automation schema, however, following a XML-based representation, as depicted in Figure 5.3, where each construct is represented as an element, and each relation as a reference attribute. For taming the complexity of reading and parsing all the constructive elements already represented in the IST-T model, the EMF representation only contains the BA-related elements, that are the ones that are relevant in the following steps. After executing the transformation, the inputted elements were converted to the following constructs

68 Blind1

IfcRelBelongs ToDevice1

Blind2 Blind1PositionSet Blind1Move Blind1Position Blind1Stop

Blind2Position

IfcRelGroups StopAllBlinds Blind2Stop Datapoint IfcRelBelongs ToDevice2 Blind2Move

Blind2PositionSet Blind2Move Blind2Position Blind2Stop Blind2PositionSet

IfcRelBelongs ToDevice2

Blind2

Figure 5.4: Decomposition of the three blind controller devices in datapoints. Each BlindStop datapoint is aggregated into the StopAllBlinds group.

of the KNX domain, as illustrated by Figure 5.5. Each IfcAutomationControlDevice was transformed into a KNX FunctionalBlock. The name attribute of each device is mapped into the name of the functional block. Though the documentation of the base installation did not mention their existence, the gener- ated model includes functional blocks as logical aggregations of datapoints, that compose one device. Therefore, each functional block has a reference to each datapoint that it contains. Each IfcAutoma- tionDatapoint, whether input or output, generated a KNX Datapoint and the respective GroupObject. The group object contains relevant network information regarding datapoints, hence, they are created at the same time. The OID, name, description, dataType and unit attributes were directly mapped form each IFC datapoint into each KNX datapoint. IFC input and output datapoints were converted to KNX datapoints with the FlowType attribute set to ”INPUT” and ”OUTPUT”, respectively. Each datapoint has a reference attribute to its respective group object and functional block. Each IfcAutomationGroup was converted into a KNX GroupAddress. The IFC group name and description were not mapped, since group addresses do not define these attributes. The group address was generated by the transforma- tion, according to an algorithm that increments the group identifier each time a group is converted. Each group address have references to the group objects that represent the datapoints contained in it. It is also worth noting that each group object contains a reference to its main group address, the one that it uses when is necessary to send a package, and a reference to a list of group addresses from which the datapoint listens. In terms of generated objects, the transformation produced a total of 218, where 92 represent BAS aspects such as datapoints, group addresses and functional blocks, and 126 represent auxiliary objects such as group objects and datapoint group addresses.

69 Figure 5.5: Excerpt of the resulting KNX model for room 1.58. The highlighted construct represents a FunctionalBlock for blind 3, which properties are detailed in the properties tab on the lower section. This object is equivalent to a device.

5.2.5 Discussion

The analysis of this case study makes possible to draw a set of conclusions regarding the transformation performance. In what concerns to converted constructs, the transformation succeeded in converting all the 92 aspects (devices, datapoints and groups) from the input model into constructs from the output model, hence, it can be concluded that, for this case study, the IFC4Automation extension can cover 100% of the automation scenario of the room 1.58. Besides, the transformation was able to convert all the constructs from the input model into equivalent constructs from the output model, which states that no ambiguities were found in rule execution. It is worth noting that all the possible test cases could not be executed, since the KNX information model does not cover the whole spectrum of BAS aspects, and that the automation scenario from room 1.58 is also unable to exercise all the use cases of the KNX information model. However, evaluating the whole set of use cases that cover the entire KNX or IFC4A information models implies an unpractical effort, out of the scope of this work. In addition, the aspects concerning data type testing and data type validation were not regarded since they are part of a future work, also out of the scope of this research.

70 Chapter 6

Conclusions

The emergence of BIM as a central repository for all the building-related data makes possible to manage most aspects of buildings in a more efficient, consistent, and coherent way. However, the coverage of IFC, the standard model specification for BIM, regarding the logical aspects of BA is almost inexistent. Also, there is no model that covers the full spectrum of BAS concepts natively, accounting for platform heterogeneity and vendor independence. This work explores the connection amid the BIM and BA realms, and proposes IFC4Automation, an extension to IFC that (i) covers the logical components of BAS configurations, abstracting from tech- nological specificities, (ii) enables the definition of interoperable BAS models, that can be refined to installations conforming to specific automation platforms, and (iii) provides a centralized repository for the BAS-related data of facilities. The proposed extension is evaluated towards completeness, complexity, flexibility, and interoperabil- ity, and its practical applicability is stated through a model transformation. The impact of this work is far-reaching as it draws a path for solving the problems of (i) consistency and coherence of BAS-related data, (ii) interoperability between different BA tools and protocols, and (iii) vendor dependency of the BAS configuration. Interoperability between BA models has been stated as a solution for preventing customer lock-in, and for enabling the development of a multitude of applications that make use of the BAS information for improving, among other FM software.

6.1 Retrospective

The analysis of literature regarding the topic of BIM clearly states the advantages and potential of this approach for managing all the building related information in a centralized and coherent way. Moreover, BIM is becoming a popular research topic throughout the scientific community, that motivates a series of works regarding interaction between BIMs and other tools. There is an obvious need for extending the model in order to span a series of other domains, such as BA. On the other hand, literature related to BAS posits that there is a clear need for taming the heterogeneity between the several BA protocols in order to enable interoperability among different BAS installations.

71 The assessment conducted in this work concludes that there is no model capable of addressing all the conceptual aspects related to BASs. Though there is a multitude of BA technologies and protocols, typically they are only capable of addressing aspects related to specific levels of the BAS pyramid (in- stead of spanning it all). Other models are capable of enabling such spanning, however, their level of abstraction makes it difficult to model automation scenarios easily. This heterogeneity frequently leads to a situation where multiple technologies are necessary in order to fulfill an automation scenario. In order to overcome these issues, this work proposes an extension to BIM, named IFC4Automation. IFC4Automation is an extended version of IFC4, the BIM standard format, that captures the informa- tion requirements of the entire BAS aspects. The extension is developed following to MDE techniques, which, amongst other advantages, enables its instances to be transformed into instances of other pro- tocols of tools, favoring interoperability. This model consists of a set of new abstractions over the BA domains, divided in three main realms. Device topology realm, that addresses the device and datapoint arrangement and linkage, structural configuration realm, that concerns with the composition of data- points in groups of higher abstractions such as zones, and finally behavioral configuration realm that handles the specification of the logical behavior of datapoints, such as the creation of scenarios and schedules. This solution is designed to, by one hand, accommodate future changes in the model, favor- ing its evolution, and by the other hand, tame some of the complexity associated with the IFC format. The proposed extension was submitted to a evaluation process that consisted of a formal analysis at its information model in terms of coverage of BAS aspects, model complexity and model flexibility, follow- ing the methodology described in this work. Also, the practical modeling capability was demonstrated employing a case study, where a concrete automation scenario, implemented in KNX, was modeled recurring to IFC4Automation and then transformed into a KNX implementation recurring to a M2M trans- formation. Finally, both the installed and the generated implementation were compared. The results show that first, the model is capable of covering the entire set of BAS aspects as it was the initial intention, relying on a flexible but still relatively complex information model. Second, the model is capable of expressing automation scenarios that can be transformed into equivalent KNX implementations. From the above, this solution has the capability of addressing the problem of heterogeneity when modeling automation scenarios, providing a common approach for designing BAS. Moreover, it will enable to maintain BAS configuration in a more consistent and coherent way, since models are included in the BIM framework and therefore, all the data is centralized in a common repository. Finally, we expect this solution represents a major advancement in BIM technology, favoring its establishment as standard framework for the building industry.

6.2 Lessons Learned

BIMserver came out as a great advantage for accelerating the development and skipping the creation of repetitive, but necessary code. It provides a framework that includes tools for automating the ecore generation of newly created IFC specifications (as in case of IFC4Automation), such as an EXPRESS

72 parser and and EXPRESStoEMF converter tool. Also, BIMserver contains a set of built-in serializers, parsers and converters for the actual IFC specifications. Besides enabling the reading and writing of IFC files, these components were designed following a plug-in philosophy, which makes possible the development of additional components. This made it much easier to develop a component for parsing and serializing IFC4Automation. However, the practical research regarding BIM is still short, and the EXPRESS modeling language has a narrow user base, restricting its usage to a very specific domain, which makes search for this kind of tools especially difficult. It is of major importance to measure the time spent on searching for this kind of tools in contrast with the time spent on developing auxiliary code. In the case of this work, the former revealed to be the better option. Choosing a modular architecture for structuring the model code proved to be the most correct way to address the flexibility requirements proposed by this work, easing the addition of new constructs and the modification of the current ones. By decoupling different concerns in different classes, the impact of the changes will be much less, favoring future refactoring.

6.3 Future Work

Extending the model of IFC to a domain as complex as the BA comprehends a multitude of tasks, some of them out of the scope of this initial research effort. The following text points out the main issues that future work must address for improving the IFC4Automation extension.

Data types is by itself a highly complex scope. Currently there are attributes for carrying the data type of each construct. However, these data types are neither created nor validated, being passed as text strings just for informational purposes. Providing a set of available data types and correspondent validation to a model that abstracts a series of other technologies entails a prospection of a com- mon denominator between all the data types that are specified in these technologies. Therefore, future work must focus on compiling the whole set of possible data types for the IFC4Automation model and make it available in the enumerates that specify the data type of each construct. These data types must at least express the same information than the ones utilized by target technolo- gies, in order to make possible converting from one to another. For example, a boolean attribute on a datapoint in IFC4Automation must be compatible with the data type used for switches in KNX, even if their implementation differs. Also, a mechanism for validating these data types in the vari- ous steps of the modeling must be created. Data type coherence must be enforced in operations such as datapoint binding, where both output and input datapoints must conform to the same data type, group creation, where all the containing datapoints must fulfill the same interface, or model transformation, where the data types must be correctly converted, amongst other.

Transformations are another major topic in what concerns future work. Since this work only targets the creation of a transformation targeting the KNX information model, future developments must feature the creation of the remaining transformations, as well as the maintenance of the current one. One of the main intents of IFC4Automation is to provide a common framework for modeling

73 automation scenarios regardless of the target platform in which they will be installed. For achieving this purpose, it is necessary to enable created models to be expressed in as many automation technologies as possible. Therefore, the development of additional transformations for supporting this objective is of primary importance. It is also necessary to develop mechanisms that take the generated models and convert it to deployments into the real automation scenarios. For instance, taking the case study of Section 5.2.3, the model produced for room 1.58 must be converted into a KNX configuration schema and deployed in the devices of the room. The same must happen to all the developed transformations. It is also worth noting that the current transformation must be enhanced in order to reflect the development taken on IFC4Automation, such as the above mentioned data type development.

GUI tools for handling IFC4Automation models is also an important step for achieving evolution on this research, mostly in what concerns to its usage by the end user. The objective of this work is to enable users to specify BAS configuration graphically, using BIM applications, and generate all the artifacts that take part on the deployment of the system automatically, otherwise, there is no practical way of specifying BAS using FC4Automation, since coding using EXPRESS directly is an extremely complex task, even using auxiliary tools. The graphical tool must have the necessary knowledge to read and write models conforming to the IFC4Automation specification, abstracting the user of the complexity of these models.

Tools that interact with IFC4Automation as data source. The solution was designed for extending BIM. Similarly, it is supposed to serve as a common data source for BAS configuration, used by several tools for entailing a multitude of tasks such as energy simulation or configuration analysis. These tools must understand the information model of IFC4Automation and make use of the data that it provides for conducting these tasks.

74 Bibliography

[1] A. Akcamete, B. Akinci, and J. H. Garrett. Potential utilization of building information models for planning maintenance activities. 2010.

[2] M. Alahmad, W. Nader, J. Neal, J. Shi, C. Berryman, Y. Cho, S.-K. Lau, H. Li, A. Schwer, Z. Shen, J. Stansbury, and T. Zhang. Real Time Power Monitoring & integration with BIM. IECON 2010 - 36th Annual Conference on IEEE Industrial Electronics Society, pages 2454–2458, Nov. 2010. doi: 10. 1109/IECON.2010.5675385. URL http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm? arnumber=5675385.

[3] M. Alahmad, W. Nader, A. Brumbaugh, Y. Cho, S. Ci, H. Sharif, J. Shi, and J. Neal. The “BIM’s 4D+” dimension: Real time energy monitoring. 2011 IEEE GCC Conference and Exhibition (GCC), pages 589–592, Feb. 2011. doi: 10.1109/IEEEGCC.2011.5752603. URL http://ieeexplore. ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5752603.

[4] B. alliance. National BIM Standard - United States TM Version 2. 2012.

[5] ASHRAE. ASHRAE STANDARD BACnet — A Data Communication Protocol for Building Automa- tion and Control Networks. 2010.

[6] S. Azhar, M. Hein, and B. Sketo. Building Information Modeling ( BIM ): Benefits , Risks and Challenges. 2007.

[7] K. M. . D. F. B. Cahill. BIM as a centre piece for optimised building operation. eWork and eBusiness in Architecture, Engineering and Construction, (2), 2012. doi: doi:10.1201/b12516-88.

[8] V. Bazjanac. IFC BIM-based methodology for semi-automated building energy performance simu- lation. 2008.

[9] V. Bazjanac and T. Maile. IFC HVAC interface to EnergyPlus - A case of expanded interoperability for energy simulation. 2004.

[10] J. Beetz and L. V. Berlo. BIMSERVER.ORG – An open source IFC model schema. (Weise 2006): 16–18, 2010.

[11] E. Biermann, K. Ehrig, and C. Kohler.¨ Graphical definition of in-place transformations in the eclipse modeling framework. . . . Languages and Systems, 4199:425–439, 2006. ISSN 0302-9743. doi: 10.1007/11880240\ 30. URL http://link.springer.com/chapter/10.1007/11880240_30.

75 [12] C. Bogen, D. Ph, M. Rashid, E. W. East, and F. Asce. A framework for building information fusion. pages 26–28, 2011.

[13] P. Bos. Collaborative engineering with IFC : new insights and technology. eWork and eBusiness in Architecture, Engineering and Construction, 9th ECPPM Conference Proceedings, pages 811–818, 2012.

[14] M. Brambilla, J. Cabot, and M. Wimmer. Model-Driven Software Engineering in Practice, volume 1. 2012. ISBN 9781608458820. doi: 10.2200/S00441ED1V01Y201208SWE001. URL http://dx. doi.org/10.2200/S00441ED1V01Y201208SWE001.

[15] B. S. T. Bushby, M. Ashrae, N. S. I. A. Standard, and B. A. D. Communica. New Tools for Specifying BACnet. (March):33–37, 2002.

[16] S. T. Bushby. BACnet: a standard communication infrastructure for intelligent buildings. 6:529–540, 1997.

[17] T. Cerovsek. A review and outlook for a ‘Building Information Model’ (BIM): A multi-standpoint framework for technological development. Advanced Engineering Informatics, 25(2):224–244, Apr. 2011. ISSN 14740346. doi: 10.1016/j.aei.2010.06.003. URL http://linkinghub.elsevier.com/ retrieve/pii/S1474034610000479.

[18] C. Corporation, U. T. Corporation, and C. No. BACnet Basics User’s Guide. (11), 2013.

[19] E. Curry, J. O’Donnell, E. Corry, S. Hasan, M. Keane, and S. O’Riain. Linking building data in the cloud: Integrating cross-domain building data using linked data. Advanced Engineering In- formatics, 27(2):206–219, Apr. 2013. ISSN 14740346. doi: 10.1016/j.aei.2012.10.003. URL http://linkinghub.elsevier.com/retrieve/pii/S1474034612000961.

[20] V. Devedzic, D. Djuric, and D. Gasevic. Model Driven Engineering and Ontology Development. 2009. ISBN 9783642002816. doi: 10.1007/978-3-642-00282-3. URL http://www.mendeley.com/ research/model-driven-engineering-and-ontology-development-2/.

[21] E. W. East. Construction Operations Building Information Exchange (COBIE): Requirements Defi- nition and Pilot Implementation Standard. (June), 2007.

[22] C. Eastman, P. Teicholz, R. Sacks, and K. Liston. BIM handbook: A guide to building information modeling for owners, managers, designers, engineers and contractors. Wiley. com, 2011.

[23] Echelon Corporation. LONMARK R Device Interface File Reference Guide. (May), 2009.

[24] Echelon Corporation. Introduction to the LonWorks R Platform. pages 1–98, 2009.

[25] European Comission. Energy 2020: A strategy for competitive, sustainable and secure energy. 2010.

76 [26] J. Favre. Foundations of Model (Driven) (Reverse) Engineering : Models. Sem- inar on Language Engineering for Model-Driven. Dagstuhl Seminar Proceedings., pages 1–31, 2004. URL http://www.megaplanet.org/jean-marie-favre/papers/ FoundationsOfModelDrivenReverseEngineeringModelsEpisodeIStoriesOfTheFidusPapyrusAndOfTheSolarus. pdf.

[27] A. Fernbach, W. Granzer, and W. Kastner. Interoperability at the management level of build- ing automation systems: A case study for BACnet and OPC UA. Etfa2011, pages 1–8, Sept. 2011. doi: 10.1109/ETFA.2011.6059106. URL http://ieeexplore.ieee.org/lpdocs/epic03/ wrapper.htm?arnumber=6059106.

[28] W. Granzer and W. Kastner. Information modeling in heterogeneous Building Automation Systems. 2012 9th IEEE International Workshop on Factory Communication Systems, pages 291–300, May 2012. doi: 10.1109/WFCS.2012.6242577. URL http://ieeexplore.ieee.org/lpdocs/epic03/ wrapper.htm?arnumber=6242577.

[29] W. Granzer, W. Kastner, G. Neugschwandtner, and F. Praus. A modular architecture for building au- tomation systems. 2006 IEEE International Workshop on Factory Communication Systems, pages 99–102, 2006. doi: 10.1109/WFCS.2006.1704133. URL http://ieeexplore.ieee.org/lpdocs/ epic03/wrapper.htm?arnumber=1704133.

[30] a. Grilo. Shifting the construction interoperability paradigm, in the advent of Service Oriented and Model Driven Architectures. Conference on Information Technology in Construction, 304:6, 2005. URL http://itc.scix.net/data/works/att/w78-2005-D5-3-Grilo.pdf.

[31] A. Grilo and R. Jardim-Goncalves. Challenging electronic procurement in the AEC sector: A BIM- based integrated perspective. Automation in Construction, 20(2):107–114, 2011. ISSN 09265805. doi: 10.1016/j.autcon.2010.09.008. URL http://dx.doi.org/10.1016/j.autcon.2010.09.008.

[32] J. Hietanen. IAI Official IFC Model View Definition Format. 2006.

[33] R. Howard and B.-C. Bjork.¨ Building information modelling – Experts’ views on standardisation and industry deployment. Advanced Engineering Informatics, 22(2):271–280, Apr. 2008. ISSN 14740346. doi: 10.1016/j.aei.2007.03.001. URL http://linkinghub.elsevier.com/retrieve/ pii/S1474034607000201.

[34] J. Hutchinson, M. Rouncefield, and J. Whittle. Model-driven engineering practices in industry. Proceeding of the 33rd international conference on Software engineering - ICSE ’11, pages 633– 642, 2011. ISSN 0270-5257. doi: 10.1145/1985793.1985882. URL http://portal.acm.org/ citation.cfm?doid=1985793.1985882.

[35] Iconics. OPC-UA Defined and How It Impacts Automation. 2009.

[36] International Alliance for Interoperability. IFC Object Model Architecture Guide. 1999.

77 [37] U. Isikdag and J. Underwood. Two design patterns for facilitating Building Information Model-based synchronous collaboration. Automation in Construction, 19(5):544–553, 2010. ISSN 09265805. doi: 10.1016/j.autcon.2009.11.006. URL http://dx.doi.org/10.1016/j.autcon.2009.11.006.

[38] U. Isikdag, G. Aouad, J. Underwood, and S. Wu. Building Information Models: A Review on Storage and Echange Mechanisms. 1999.

[39] M. Jung, J. Weidinger, C. Reinisch, W. Kastner, C. Crettaz, A. Olivieri, and Y. Bocchi. A Trans- parent IPv6 Multi-protocol Gateway to Integrate Building Automation Systems in the Internet of Things. 2012 IEEE International Conference on Green Computing and Communications, pages 225–233, Nov. 2012. doi: 10.1109/GreenCom.2012.42. URL http://ieeexplore.ieee.org/ lpdocs/epic03/wrapper.htm?arnumber=6468317.

[40] M. Jung, J. Weidinger, W. Kastner, and A. Olivieri. Heterogeneous device interaction using an IPv6 enabled service-oriented architecture for building automation systems Categories and Subject Descriptors. pages 1939–1941, 2013.

[41] A. Karavan and K. Kabitzsch. Merging Building Automation Network Design and IFC 2x Construc- tion Projects. 2005.

[42] W. Kastner and S. Szucsich. Accessing KNX networks via BACnet/WS. 2011 IEEE International Symposium on Industrial Electronics, pages 1315–1320, June 2011. doi: 10.1109/ISIE.2011. 5984349. URL http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5984349.

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

[44] P. Katranuschkov and S. Researcher. BIM-Based Generation of Multi Model Views. (1):16–18, 2010.

[45] S. Kent. Model Driven Engineering. Integrated Formal Methods, Third International Conference, {IFM}, 2335:286–298, 2002.

[46] A. G. Kleppe, J. Warmer, and W. Bast. MDA Explained: The Model Driven Architecture: Practice and Promise. 2003.

[47] KNX Association. KNX System Specifications 3 1. pages 1–26, 2009.

[48] D. Kolovos, L. Rose, A. Garc´ıa-dom´ınguez, and R. Paige. The Epsilon Book. 2013.

[49] D. S. Kolovos, R. F. Paige, and F. a. C. Polack. Eclipse Development Tools for Epsilon. EclipseCon, 2006.

[50] D. S. Kolovos, R. F. Paige, and F. a. C. Polack. The epsilon transformation language. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 5063 LNCS:46–60, 2008. ISSN 03029743. doi: 10.1007/978-3-540-69927-9\ 4.

78 [51] Konnex Association. KNX System Specifications: Datapoint Types. 2012.

[52] H. Lai, C. Zhou, and X. Deng. RESEARCH ON BUILDING INFORMATION DELIVERY OF STRUC- TURAL ENGINEERING FOR COLLABORATIVE DESIGNS. In 30th CIB W78 International Confer- ence, 2013.

[53] J. Lee, Y. Jeong, Y.-S. Oh, J.-C. Lee, N. Ahn, J. Lee, and S.-H. Yoon. An integrated approach to intelligent urban facilities management for real-time emergency response. Automation in Con- struction, 30:256–264, Mar. 2013. ISSN 09265805. doi: 10.1016/j.autcon.2012.11.008. URL http://linkinghub.elsevier.com/retrieve/pii/S0926580512002038.

[54] T. Liebich and M. Weise. ifcXML4 Specification Methodology. (July):1–29, 2013.

[55] LonMark International. Functional Profile : Constant Light Controller. pages 1–11, 1997.

[56] LonMark International. Functional Profile : Light Sensor. pages 1–9, 1997.

[57] LonMark International. Application-Layer Interoperability Guidelines. (September), 2005.

[58] LonMark International. LonMark SNVT Master List. (December), 2012.

[59] W. Mahnke, S.-H. Leitner, and M. Damm. OPC Unified Architecture. 2009.

[60] A. Maka, R. Cupek, and J. Rosner. OPC UA Object Oriented Model for Public Transportation System. 2011 UKSim 5th European Symposium on Computer Modeling and Simulation, pages 311–316, Nov. 2011. doi: 10.1109/EMS.2011.84. URL http://ieeexplore.ieee.org/lpdocs/ epic03/wrapper.htm?arnumber=6131253.

[61] V. Marinakis, H. Doukas, C. Karakosta, and J. Psarras. An integrated system for buildings’ energy- efficient automation: Application in the tertiary sector. Applied Energy, 101:6–14, Jan. 2013. ISSN 03062619. doi: 10.1016/j.apenergy.2012.05.032. URL http://linkinghub.elsevier.com/ retrieve/pii/S0306261912004059.

[62] W. Mazairac and J. Beetz. Towards a Framework for a Domain Specific Open Query Language for Building Information Models. International Workshop: Intelligent Computing in Engineering, pages 1–8, 2010.

[63] P. Meadati. BIM Extension into Later Stages of Project Life Cycle. 2009.

[64] S. J. Mellor, A. N. Clark, and T. Futagami. Model-Driven Development. IEEE Software, 20(5): 14–18, 2003. ISSN 07407459. doi: 10.1145/1753846.1754166.

[65] B. Moore, D. Dean, and a. Gerber. Eclipse Development using the Graphical Editing Framework and the Eclipse Modeling Framework. IBM Redbooks, 1:1–256, 2004. doi: 10.1147/JRD.2010.2041693.

[66] I. Motawa and K. Carter. Sustainable BIM-based Evaluation of Buildings. Procedia - Social and Behavioral Sciences, 74:419–428, Mar. 2013. ISSN 18770428. doi: 10.1016/j.sbspro.2013.03.015. URL http://linkinghub.elsevier.com/retrieve/pii/S1877042813004448.

79 [67] National Institute of Building Sciences. National Building Information Modeling Standard. Technical report, 2007.

[68] M. Neugschwandtner, G. Neugschwandtner, and W. Kastner. Web Services in Building Automation: Mapping KNX to oBIX. 2007 5th IEEE International Conference on Industrial Informatics, pages 87–92, July 2007. ISSN 1935-4576. doi: 10.1109/INDIN.2007.4384736. URL http://ieeexplore. ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4384736.

[69] OASIS. oBIX Version 1.1. (July):1–63, 2013.

[70] OMG. Object Management Group, Model Driven Architecture (MDA). (June):1–15, 2003. URL http://www.omg.org/cgi-bin/doc?omg/03-06-01.

[71] OPC Foundation. OPC Unified Architecture Specification Part 4: Servic¸es. 2009.

[72] OPC Foundation. OPC Unified Architecture Specification Part 5: Information Model. 2009.

[73] OPC Foundation. OPC Unified Architecture Specification Part 1: Overview and Concepts. 2009.

[74] OPC Foundation. OPC Unified Architecture Specification Part 9: Alarms & Conditions. 2010.

[75] OPC Foundation. [1] O. P. C. Unified, A. Specification, and C. Release, “OP,” 2012. 2012.

[76] S. Rohjans, M. Uslar, and H. Appelrath. OPC UA and CIM : Semantics for the Smart Grid. pages 1–8, 2010.

[77] P. Rub. KNX for OPC UA. pages 1–31, 2011.

[78] S. Runde and A. Fay. A data exchange format for the engineering of building automation systems. 2008 IEEE International Conference on Emerging Technologies and Factory Automation, pages 303–310, Sept. 2008. doi: 10.1109/ETFA.2008.4638411. URL http://ieeexplore.ieee.org/ lpdocs/epic03/wrapper.htm?arnumber=4638411.

[79] J. Schein. An information model for building automation systems. Automation in Construction, 16(2):125–139, Mar. 2007. ISSN 09265805. doi: 10.1016/j.autcon.2006.07.006. URL http:// linkinghub.elsevier.com/retrieve/pii/S0926580506000586.

[80] A. Schlueter and F. Thesseling. Building information model based energy/exergy performance assessment in early design stages. Automation in Construction, 18(2):153–163, Mar. 2009. ISSN 09265805. doi: 10.1016/j.autcon.2008.07.003. URL http://linkinghub.elsevier.com/ retrieve/pii/S0926580508001064.

[81] D. C. Schmidt. Model-Driven Engineering. Computer, 39(February):25–31, 2006. ISSN 00189162. doi: 10.1109/MC.2006.58. URL http://dx.doi.org/10.1109/MC.2006.58.

[82] E. Seidewitz. What models mean. IEEE Software, 20(5):26–32, 2003. ISSN 07407459. doi: 10.1109/MS.2003.1231147.

80 [83] B. Selic. The pragmatics of model-driven development. IEEE Software, 20(5):19–25, 2003. ISSN 07407459. doi: 10.1109/MS.2003.1231146.

[84] W. Shen, Q. Hao, H. Mak, J. Neelamkavil, H. Xie, J. Dickinson, R. Thomas, A. Pardasani, and H. Xue. Systems integration and collaboration in architecture, engineering, construction, and facil- ities management: A review. Advanced Engineering Informatics, 24(2):196–207, Apr. 2010. ISSN 14740346. doi: 10.1016/j.aei.2009.09.001. URL http://linkinghub.elsevier.com/retrieve/ pii/S1474034609000664.

[85] D. Steinberg, F. Budinsky, E. Merks, and M. Paternostro. EMF: Eclipse Modeling Framework. Pear- son Education, 2008.

[86] J. P. Thomesse. Fieldbuses and interoperability. 7(December 1997), 1999.

[87] J. P. Thomesse and F. Vandwvre. A Review of the Fieldbuses. Annual Reviews in, 22:35–45, 1998.

[88] S. T. Tom. BACnet Operator Workstations. ASHRAE Journal, (November), 2011.

[89] R. Vanlande, C. Nicolle, and C. Cruz. IFC and building lifecycle management. Automation in Construction, 18(1):70–78, Dec. 2008. ISSN 09265805. doi: 10.1016/j.autcon.2008.05.001. URL http://linkinghub.elsevier.com/retrieve/pii/S0926580508000800.

[90] M. Venugopal, C. Eastman, R. Sacks, and J. Teizer. Semantics of model views for information exchanges using the industry foundation class schema. Advanced Engineering Informatics, 26(2): 411–428, Apr. 2012. ISSN 14740346. doi: 10.1016/j.aei.2012.01.005. URL http://linkinghub. elsevier.com/retrieve/pii/S1474034612000067.

[91] J. Virta, I. Seilonen, A. Tuomi, K. Koskinen, P. O. Box, and F. Aalto. SOA-Based Integration for Batch Process Management with OPC UA and ISA-88 / 95. 2010.

[92] Wago Kontakttechnik GmbH. BACnet - Objects, Properties, Services. 27(03), 2010.

[93] M. Weise, P. Katranuschkov, and R. J. Scherer. A Proposed Extension of the IFC Project Model for Structural Systems. In Product and Process Modelling in Building and Construction, pages 229–238, 2000.

[94] M. Wijayakumar and H. S. Jayasena. AUTOMATION OF BIM QUANTITY TAKE-OFF TO SUIT QS’S REQUIREMENTS. In The Second World Construction Symposium 2013: Socio-Economic Sustainability in Construction, number June, pages 70–80, 2013.

[95] W. Yan, M. Clayton, J. Haberl, W. Jeong, J. B. Kim, A. Texas, and C. Station. Interfacing BIM with Building Thermal and Daylighting Modelling. (Bazjanac 2001), 2007.

[96] C. Zhang, J. Beetz, and M. Weise. Model view checking: automated validation for IFC building models. eWork and eBusiness in Architecture, Engineering and Construction: ECPPM 2014, 2014.

81 82 Appendix A

Information Models

A.1 KNX Ecore Information Model

Group 0..* 1 Group Object Address * *

* Datapoint 0..*

* Functional Block 1

Figure A.1: Illustration of the reduced KNX information model, modeled recurring to the Ecore meta- modeling language.

83 84 Appendix B

Transformation Rules

B.1 IFC4Automation to KNX Transformation Rules

85 pre { var groupAddressSeed : Integer = 1; var groupObjectSeed : Integer = 1;

var zoneSeed : Integer = 0; var groupSeed : Integer = 0; var baseSeed : Integer = 0;

"Running ETL".println(); }

post { // Store traceability links in custom model var trace : new Trace!Trace; for (t in transTrace.transformations) { var link : new Trace!TraceLink; link.sources.add(t.source); //link.targets = t.targets; link.description = "Transformed by " + t.getRule().name; trace.links.add(link); } }

@abstract rule DatapointToDatapoint transform ifcdp : IFC4Automation!IfcAutomationDatapoint to knxdp : KNX!Datapoint, knxgroupaddr : KNX!GroupAddress {

// create a group address and set it as main group address knxgroupaddr.ID = generateNewGAId(); knxgroupaddr.address = ifcdp.Address.ifUndefined(ifcdp.generateNewGroupAddress());

var go = new KNX!GroupObject;

knxdp.datapointGroupObject = go; go.ID = generateNewGOId(); knxdp.DataType = ifcdp.toKnxDatatype();

knxdp.ID = ifcdp.GlobalId; knxdp.Description = ifcdp.Description; knxdp.Name = ifcdp.Name; knxdp.Unit = ifcdp.Unit.toString();

Figure B.1: List of rules that compose the model transformation from IFC4Automation to KNX.

86 }

rule InputDatapointToInputDatapoint transform ifcdp : IFC4Automation!IfcAutomationInputDatapoint to knxdp : KNX!Datapoint, knxgroupaddr : KNX!GroupAddress extends DatapointToDatapoint {

// mark as input knxdp.FlowType = KNX!FlowType#INPUT;

knxgroupaddr.groupAddressGroupObjects.add(knxdp.datapointGroupObject);

("Detected: " + ifcdp).println(); }

rule OutputDatapointToOutputDatapoint transform ifcdp : IFC4Automation!IfcAutomationOutputDatapoint to knxdp : KNX!Datapoint, knxgroupaddr : KNX!GroupAddress extends DatapointToDatapoint{

//mark as output knxdp.datapointGroupObject.mainGroupAddress = knxgroupaddr;

knxgroupaddr.groupAddressGroupObjects.add(knxdp.datapointGroupObject); knxdp.FlowType = KNX!FlowType#OUTPUT;

("Detected: " + ifcdp).println(); }

rule BindingToGroupAddress transform ifcbinding : IFC4Automation!IfcRelBindsByDatapoint to null {

// put the GA on the listening datapoint lsit of both datapoints ("GROUP OBJECT: " + ifcbinding.OutputDatapoint.equivalent().datapointGroupObject).println( );

for(dp in ifcbinding.InputDatapoint){ ("GROUP OBJECT: " + dp.equivalent().datapointGroupObject).println();

dp.equivalent().datapointGroupObject.groupObjectGroupAddresses.add(ifc binding.OutputDatapoint.equivalent().datapointGroupObject.mainGroupAdd ress);

Figure B.2: List of rules that compose the model transformation from IFC4Automation to KNX. (cont.)

87 dp.equivalent().datapointGroupObject.groupObjectGroupAddresses.add(ifc binding.OutputDatapoint.equivalent().datapointGroupObject.mainGroupAdd ress); }

"Detected: " + ifcbinding.println(); }

rule SetpointToSetpointAttribute transform ifcsp : IFC4Automation!IfcAutomationSetpoint to null {

for(dp in ifcsp.HasInputDatapoints[0].InputDatapoint){ if(ifcsp.unit == dp.equivalent().Unit){ "UNITS DO NOT DIFFER!".println(); dp.equivalent().Setpoint = ifcsp.writeValue; } else{ "UNITS DIFFER!".println(); } } }

rule ControlDeviceToFunctionalBlock transform ifccd : IFC4Automation!IfcAutomationControlDevice to knxfb : KNX!FunctionalBlock {

knxfb.ID = ifccd.GlobalId; knxfb.Description = ifccd.Description; knxfb.Name = ifccd.Name;

for(dp in ifccd.HasDatapoints.RelatingDatapoint[0]){ ("Functional Block Datapoints: " + dp).println(); knxfb.functionalBlockDatapoints.add(dp.equivalent()); }

"Detected: " + ifccd.println(); }

rule DatapointSetToGroupAddress transform ifcdpset : IFC4Automation!IfcAutomationDatapointSet to knxgroupaddr : KNX!GroupAddress {

Figure B.3: List of rules that compose the model transformation from IFC4Automation to KNX. (cont.)

88 knxgroupaddr.ID = ifcdpset.GlobalId; for(dp in ifcdpset.Datapoints[0].RelatingDatapoint){

knxgroupaddr.groupAddressGroupObjects.add(dp.equivalent().datapointGro upObject); } "Detected: " + ifcdpset.println(); }

@primary rule ZoneToGroupAddress transform ifczone : IFC4Automation!IfcAutomationZone to knxgroupaddr : KNX!GroupAddress extends DatapointSetToGroupAddress {

// generate group address considering zone knxgroupaddr.address = ifczone.generateNewGroupAddress();

"Detected: " + ifczone.println(); }

@primary rule GroupToGroupAddress transform ifcgrp : IFC4Automation!IfcAutomationGroup to knxgroupaddr : KNX!GroupAddress extends DatapointSetToGroupAddress {

// generate group address considering group knxgroupaddr.address = ifcgrp.generateNewGroupAddress(); "Detected: " + ifcgrp.println(); }

operation IFC4Automation!IfcAutomationDatapoint toKnxDatatype() : KNX! EEnumLiteral { var ifcdatatype = self.DataType; switch(ifcdatatype){ case IFC4Automation!IfcAutomationDataTypeEnum#USERDEFINED: return KNX!DataType#USERDEFINED; case IFC4Automation!IfcAutomationDataTypeEnum#NOTDEFINED: return KNX!DataType#NOTDEFINED; default: return KNX!DataType#NOTDEFINED; }

Figure B.4: List of rules that compose the model transformation from IFC4Automation to KNX. (cont.)

89 }

operation IFC4Automation!IfcAutomationSetpoint toKnxDatatype() : KNX! EEnumLiteral { var ifcdatatype = self.DataType; switch(ifcdatatype){ case IFC4Automation!IfcAutomationDataTypeEnum#USERDEFINED: return KNX!DataType#USERDEFINED; case IFC4Automation!IfcAutomationDataTypeEnum#NOTDEFINED: return KNX!DataType#NOTDEFINED; default: return KNX!DataType#NOTDEFINED; } }

operation Any generateNewGAId() : Integer { var currentId = groupAddressSeed; groupAddressSeed = groupAddressSeed + 1; return currentId; }

operation Any generateNewGOId() : Integer { var currentId = groupObjectSeed; groupObjectSeed = groupObjectSeed + 1; return currentId; }

operation Any generateNewGroupAddress() : String { var receiverType = self.eClass.name; ("ReceiverType: " + receiverType).println(); switch(receiverType){ // If zone, increment top case "IfcAutomationZone": zoneSeed = zoneSeed+1; baseSeed = 0; break; // If group, increment middle case "IfcAutomationGroup": groupSeed = groupSeed+1; baseSeed = 0; break; // If binding, increment bottom case "IfcAutomationDatapoint": baseSeed = baseSeed+1; break;

Figure B.5: List of rules that compose the model transformation from IFC4Automation to KNX. (cont.)

90 default : baseSeed = baseSeed+1; } var address = zoneSeed+ "/" +groupSeed + "/" + baseSeed; return address; }

Figure B.6: List of rules that compose the model transformation from IFC4Automation to KNX. (cont.)

91 92 Appendix C

Tables

C.1 List of Datapoints on Room 1.58

Device Datapoint Flow Group Address Electronic Ballast 1 Light Board 1 Input 0/7/0 Electronic Ballast 2 Light Board 2 Input 0/7/1 Electronic Ballast 3 Light Middle 1 Input 0/7/2 Electronic Ballast 4 Light Middle 2 Input 0/7/3 Electronic Ballast 5 Light Middle 3 Input 0/7/4 Electronic Ballast 6 Light Middle 4 Input 0/7/5 Electronic Ballast 7 Light TV 1 Input 0/7/6 Electronic Ballast 8 Light TV 2 Input 0/7/7 All Lights ON/OFF Switch Input 0/1/1 Lights Board Status Output 0/1/3 Lighting Controller Lights Middle 1 Status Output 0/1/5 Lights Middle 2 Status Output 0/1/7 Lights TV Status Output 0/1/9 LED light TV Input 0/7/8 LEDs TV LED light TV status Output 0/7/9 Humidity Sensor Relative Humidity Output 0/4/1 Door Lock Door Lock Control Input 0/3/0 RFID Door Controller Door Lock RFID Sensor Output 0/3 Sound Speakers 1 and 2 Amplifier Switch Input 2/0/0 Blind 1 Position Output 0/2/0 Blind 1 Move Set Input 0/2/1 Blind 1 Blind 1 Stop Set Input 0/2/2 Blind 1 Position Set Input 0/2/3

93 Blind 2 Position Output 0/2/13 Blind 2 Move Set Input 0/2/4 Blind 2 Blind 2 Stop Set Input 0/2/5 Blind 2 Position Set Input 0/2/6 Blind 3 Position Output 0/2/14 Blind 3 Move Set Input 0/2/7 Blind 3 Blind 3 Stop Set Input 0/2/8 Blind 3 Position Set Input 0/2/9 Temperature Sensor Output 0/6/0 Wind Sensor Output 0/6/1 Weather Station Rain Sensor Output 0/6/2 Light Sensor Output 0/6/3 Power Switch Input 0/6/4 Socket 1 Input 0/0/1 Socket 2 Input 0/0/2 Socket 3 Input 0/0/3 Socket 4 Input 0/0/4 Socket 5 Input 0/0/5 Socket 6 Input 0/0/6 Socket Controller Socket 7 Input 0/0/7 Socket 8 Input 0/0/8 Socket 9 Input 0/0/9 Socket 10 Input 0/0/10 Socket 11 Input 0/0/11 Socket 12 Input 0/0/12 Socket Status Output 0/0/14 ON/OFF Switch Input 1/0/0 Mode Switch Input 1/0/1 Fan Speed Input 1/0/2 Auto Fan Switch Input 1/0/3 Temperature Setpoint Input 1/0/4 Temperature Status Output 1/0/5 Heat Controller Input 1/0/6 HVAC Controller Cold Controller Input 1/0/7 ON/OFF Switch Status Output 1/0/8 Mode Switch Status Output 1/0/9 Fan Speed Status Output 1/0/10 Auto Fan Status Output 1/0/11

94 Heat Controller Status Output 1/0/12 Cold Controller Status Output 1/0/13

Table C.1: List of datapoints exposed in the room 158, organized by device they belong. Each datapoint has a flow type that can be input or output and a group address.

95