eeembedded d8.1 soa platform...

This project has received funding from the European Union Seventh Framework Programme

under grant agreement n° 609349.

OPTIMISED DESIGN METHODOLOGIES FOR ENERGY-EFFICIENT

BUILDINGS INTEGRATED IN THE NEIGHBOURHOOD ENERGY SYSTEMS

eeEmbedded – D8.1

SOA Platform Architecture

Responsible Authors:

Amrita Sukumar (RIB), Arne Tøn (EPM), Klaus Linhard (IAB),

Eduard Mrazek (NEM), Marc Mosch (TUD-CIB), Peter Katranuschkov (TUD-CIB)

Co-Authors:

Georg Dangl (IAB), Wolfgang Müller (RIB), Ken Baumgärtel (TUD-CIB),

Mathias Kadolsky (TUD-CIB), Raimund Zellner (NEM)

Due date: 30.06.2015

Issue date: 15.11.2015

Nature: Other

Coordinator: R. J. Scherer, Institute for Construction Informatics, Technische Universität Dresden, Germany

D8.1 SOA Platform Architecture

/72

© eeEmbedded Consortium www.eeEmbedded.eu

Start date of project: 01.10.2013 Duration: 48 months

Organisation name of lead contractor for this deliverable: RIB Software

History

Version Description Author Date

0.1 Initial Deliverable Structuring Amrita Sukumar (RIB) 30/01/2015

0.2 Extended Work Structure

Amrita Sukumar (RIB), Klaus Linhard (IAB), Georg Dangl (IAB),

Arne Tøn (EPM)

18/02/2015

0.3 Partner Contributions All Partners 29/04/2015

0.4 Discussion/ Restructuring/ Revised version with comments

Peter Katranuschkov (CIB), Marc Mosch (CIB)

14/05/2015

0.5 Refining the Data & Module Structure Peter Katranuschkov (CIB), Marc Mosch (CIB)

04/06/2015

0.6 Report structure and initial contributions to the document

Amrita Sukumar (RIB), Klaus Linhard (IAB), Georg Dangl (IAB)

22/07/2015

0.7 Fully reworked report structure aligned with all developments and findings

Peter Katranuschkov (CIB), Marc Mosch (CIB)

11/09/2015

0.8 Extended & Updated Partner Contributions

All Partners 20/10/2015

0.9 Consolidated pre-final version Arne Tøn (EPM), Peter Katranuschkov (CIB)

23/10/2015

0.91 Final partner contributions

All partners 30/10/2015

0.92 Final Revision Amrita Sukumar (RIB)

Marc Mosch (CIB) Peter Katranuschkov (CIB)

14/11/2015

1.0 Final Version

Amrita Sukumar (RIB) Peter Katranuschkov (CIB)

15/11/2015

Copyright

This report is © eeEmbedded Consortium 2015. Its duplication is restricted to the personal use within

the consortium, the funding agency and the project reviewers. Its duplication is allowed in its integral

form only for anyone's personal use for the purposes of research or education.

Citation

Sukumar, A., Tøn, A., Linhard, K., Mrazek, E., Mosch, M. & Katranuschkov P. (2015): eeEmbedded

Deliverable D8.1: SOA Platform Architecture, © eeEmbedded Consortium, Brussels.


/72


Acknowledgements

The work presented in this document has been conducted in the context of the seventh framework

programme of the European community project eeEmbedded (n° 609349). eeEmbedded is a 48

month project that started in October 2013 and is funded by the European Commission as well as by

the industrial partners. Their support is gratefully appreciated. The partners in the project are

Technische Universität Dresden (Germany), Fraunhofer-Gesellschaft zur Förderung der angewandten

Forschung E.V (Germany), NEMETSCHEK Slovensko, S.R.O. (Slovakia), Data Design System ASA

(Norway), RIB Information Technologies AG (Germany), Jotne EPM Technology AS (Norway),

Granlund OY (Finland), SOFISTIK HELLAS AE (Greece), Institute for applied Building Informatics IABI

(Germany), FR. SAUTER AG (Switzerland), , Obermeyer Planen + Beraten (Germany), Centro de

Estudios Materiales y Control de Obras S.A. (Spain), STRABAG AG (Austria) and Koninklijke BAM

Group NV (The Netherlands). This report owes to a collaborative effort of the above organizations.

Project of SEVENTH FRAMEWORK PROGRAMME OF THE EUROPEAN COMMUNITY

Dissemination Level

PU Public X

PP Restricted to other programme participants (including the Commission Services)

RE Restricted to a group specified by the consortium (including the Commission Services)

CO Confidential, only for members of the consortium (including the Commission Services)


/72


TABLE OF CONTENTS

Abbreviations and Acronyms ________________________________________________________ 6

Acronyms of the Tools and Services in the eeEmbedded Platform ___________________________ 7

Executive Summary ________________________________________________________________ 8

1 Introduction _________________________________________________________________ 9

2 The eeEmbedded Platform _____________________________________________________ 10

3 Software Components ________________________________________________________ 12

3.1 Authoring Tools ____________________________________________________________ 14

3.2 Collaboration and Decision Support Tools _______________________________________ 15

3.3 Multi-Model Management Services ____________________________________________ 16

3.4 Simulation and Analysis Management Services ___________________________________ 17

3.5 Simulation and Analysis Computational Services __________________________________ 18

3.6 Collaboration and Resource Access Management Services __________________________ 19

3.7 Information Repositories_____________________________________________________ 20

3.8 BIM Support ______________________________________________________________ 21

4 Scenario Workflows __________________________________________________________ 22

4.1 Overview _________________________________________________________________ 22

4.2 Generic Set Up Scenario _____________________________________________________ 23

4.3 Generic Scenario for the Design Domain ________________________________________ 24

4.4 Generic Scenario for Analysis / Simulation _______________________________________ 25

4.5 Generic Scenario for Decision Making __________________________________________ 26

5 Usage Scenario #1: Urban Design________________________________________________ 27

5.1 Tasks 0 / 1 “Project Set Up” / “Consistency Checking” ______________________________ 27

5.2 Task 2 “Create Design Cubature Options” _______________________________________ 28

5.3 Task 3 “CFD Simulation (3D Wind)”_____________________________________________ 29

5.4 Task 4 “Create Energy Supply Options” _________________________________________ 30

5.5 Task 5 “Energy Simulation” ___________________________________________________ 31

5.6 Task 6a “Life Cycle Costing (without consideration of stochastic variables)” _____________ 32

5.7 Task 6b “Life Cycle Costing (including consideration of stochastic variables)”____________ 33

5.8 Task 7 “Decision Making” ____________________________________________________ 34

6 Usage Scenario #2: Early Design _________________________________________________ 35

6.1 Tasks 0 / 1 “Project Set Up” / “Consistency Checking” ______________________________ 35

6.2 Task 2 “Create Construction Type Alternatives” ___________________________________ 36


/72


6.3 Task 3 “Create HVAC Type Alternatives” _________________________________________ 37

6.4 Task 4 “Create Control Strategy Alternatives” ____________________________________ 38

6.5 Task 5 “Enrich Alternatives with O&M Information” _______________________________ 39

6.6 Task 6 “Energy Simulation” ___________________________________________________ 40

6.7 Task 7a “Life Cycle Assessment (w/o consideration of stochastic variables)” ____________ 41

6.8 Task 7b “Life Cycle Assessment (incl. consideration of stochastic variables)” ____________ 42




7 Usage Scenario #3: Detailed Design ______________________________________________ 46

7.1 Tasks 0 / 1 “Project Set Up” and “Consistency Checking”____________________________ 46

7.2 Task 2 “Create Architectural Product Alternatives” ________________________________ 47

7.3 Task 3 “Create HVAC Type Alternatives” _________________________________________ 48

7.4 Task 4 “Design Sensor and Actuator Network” ____________________________________ 49

7.5 Task 5 “Enrich Product Alternatives with Operational Information” ___________________ 50

7.6 Task6a “Thermal Energy Simulation” ___________________________________________ 51

7.7 Task 6b “CFD Simulation (3D Wind)” ___________________________________________ 52

7.8 Task 7a “Life Cycle Assessment (w/o consideration of stochastic variables)” ____________ 53

7.9 Task 7b “Life Cycle Assessment (incl. consideration of stochastic variables)” ____________ 54




8 Further Detailing _____________________________________________________________ 58

8.1 Principal Approach _________________________________________________________ 58

8.2 Usage Example: Part of Use Case #1, Task 1.7 “Decision Making” _____________________ 58

9 Platform APIs _______________________________________________________________ 63

9.1 Collaboration API ___________________________________________________________ 63

9.2 Repository API _____________________________________________________________ 65

9.3 BIM+ API _________________________________________________________________ 67

9.4 Simulation API _____________________________________________________________ 68

9.5 Ontology Management Services API ____________________________________________ 70

10 Conclusions _________________________________________________________________ 71

11 References__________________________________________________________________ 72


/72


Abbreviations and Acronyms

ARCH Architecture / Architect (as project role)

API Application Programming Interface

BACS Building Automation and Control Systems

BAS Building Automation System

BCF BIM Collaboration Format

BIM Building Information Model / Building Information Modelling

eeeBIM Energy Enhanced BIM Embedded in the Energy System Environment

BM BIM Manager

CAD Computer-Aided Design

CE Cost Estimator

CRUD Create, Read, Update and Delete

DM Decision Maker

DV Decision Value

EE Energy Expert

eeE eeEmbedded Project / eeEmbedded Platform

ESIM Energy System Information Model

FM Facility Management

HTTP Hyper Text Transfer Protocol

HVAC Heating Ventilation and Air Conditioning

IFC Industry Foundation Classes

iTWO RIB iTWO Enterprise Solution

KDR Key Design Requirement

KPI Key Performance Indicator

O&M Operation and Maintenance

ONTO.REP Ontology Repository

OWL Ontology Web language

RDF Resource Description Framework

REST Representational State Transfer

REST-API Representational State Transfer API

SOA Service Oriented Architecture

SPARQL SPARQL Protocol And RDF Query Language

URI Uniform Resource Identifier

XML Extensible Markup Language

XSD XML Schema Definition

http://en.wikipedia.org/wiki/Create,_read,_update_and_delete


/72


Acronyms of the Tools and Services in the eeEmbedded Platform

ALLPLAN The Architectural CAD system of Nemetschek Allplan used and extended within the eeEmbedded project

BIM-IT BCF Collaboration Service / BCF Collaboration Server

BIMFit BIM Filtering Service

BIM+ The Open BIM Cloud Repository of Nemetschek supporting both Nemetschek BIM+ and IFC based building modelling

DDS-CAD The M.E.P. CAD System of the Nemetschek Company DDS used and extended within the eeEmbedded project

EDM Jotne’s IFC (ISO 16739) and STEP (ISO 10303) Complient Cloud Repository

eeBACSWiz The eeBACSWizard Prototype Tool of SAUTER AG enabling BACS designer to find the correct set of BACS templates based on key design requirements already in the early design phase

ESD Energy System Designer

GD GRANLUND Designer (MEP / FM)

KPA Key Point Analysis Tool

LCC Life Cycle Costing Service integrated with RIB’s iTWO System

LCA Life Cycle Assessment Service integrated with RIB’s iTWO System

MAS Model Access Service

MCS Model Combiner Service

MMC Multi Model Container

MMNav Multi Model Navigator

MMS Model Manipulation Services

MVS Model Versioning Service

OAS Ontology Access Service

OMS Ontology Management Service

OVS Model Validator Service (Ontology-Based)

RAS Risk Analysis Service

SAS Stochastic Sampling Service

ScM Scenario Manager

SMM Simulation Model Mapper

SRM Simulation Results Manager

TMS Template Management Service

UMS User Management Service

3DTherm 3D Thermal CFD Analysis

3DWind 3D Wind CFD Analysis


/72


Executive Summary

The objective of Deliverable 8.1 “SOA Platform Architecture” is to ensure the required flexibility of

services and tools in order to address the challenges of the eeEmbedded multi-model and multi-

services paltform. The outcome is the developed Service Oriented Architecture (SOA) based on and

extending the previous outcome from D1.5, which provides the principal architecture of the virtual

design lab and office and the definition of the overall interoperability requirements and scenario

workflows. In the course of the work for this deliverable the relevant schemata from D1.5 and D2.3

were significantly further developed and detailed. They cover the complex integration of multiple tools

into one system as well as their collaboration. All components and services are further examined to

enable reusability and configurability of the presented approach. Built around a core of collaboration

and management services and based on the ontology frameworks developed in WP5 (T5.1), WP6

(T6.1), and WP7 (T7.1), a common ICT structure is established, binding together (1) local off-the-shelve

applications such as CAD and FM systems, (2) distributed cloud-enabled computational tools, and (3) a

set of Multi Model and multi physics management web services via direct SOAP or REST interfaces.

Deliverable D8.1 is structured into ten chapters as follows:

The first chapter introduces the developed distributed SOA based on the conceptual plat-

form design presented in D1.5. The general principles of the architecture are explained

including a diagramatic representation of the communication between the different services

and tools via a common BCF-based service bus.

The second chapter outlines the eeEmbedded platform structure, emphasising the layer-

oriented approach defined in D1.5.

In the third chapter the different software components are discussed, providing the detailed

and updated ready-to-integrate modules of the platform, i.e. Authoring Tools, Collaboration

and Decision Support Tools, Multi Model Management Services, Simulation and Analysis

Services, Collaboration and Resource Management, Information Repositories and BIM Support.

The fourth chapter presents the refined scenario workflows from D1.5. They are extended to

include technical collaboration and information exchange challenges and allocated platform

modules with their specific tasks/subtasks into the generic scenarios.

The fifth, sixth and seventh chapter present reworked and extended sequence diagrams for

the urban, early and detailed design phase respectively based on the results from D2.3. As in

chapter four, the extended diagrams now include technical collaboration and information

exchange challenges and allocated platform modules with their specific tasks/subtasks.

The eighth chapter outlines the further detailing steps of the architecture with a usage

example from the Decision Making process (Use case 1, Task 1.7).

The ninth chapter describes the different platform APIs and the last tenth chapter presents

the conclusions drawn from the work done so far.

The work was led by RIB with great support from CIB, EPM, IABI and NEM. The content of the

deliverable was elaborated and discussed in frequent web conferences between all project partners.

In particular, the partners were involved in the R&D work as follows:

RIB: Work package leader, Task leader, Chapters 1-3, 9-11, report structure, overall editing

CIB: Contributions to chapters 2-9, 11 and report structuring

EPM: Contributions to chapters 1-4, 8 and 9

IAB: Contributions to chapters 3, 8, 9, 11

NEM: Contributions to chapters 3, 8, 9.


/72


1 Introduction

In Deliverable D8.1 a distributed SOA platform is developed based on the conceptual architecture

outlined in D1.5 (Zellner et al. 2015). It supports the overall eeeBIM approach in terms of collabo-

ration and communication. The developed architecture separates services and tools into four distinct

categories: (1) Authoring and Decision Support Tools module, (2) Collaboration and Resource

Management module, (2) Simulation and Analysis Management module, and (4) Platform Core

module. These services and tools can be configured and adapted for various specialized virtual lab

realizations, whereby the core services provide the kernel for all such configurations. Communication

between the services and tools on the platform is realized strictly using the REST API (Richardson et

al. 2013), albeit a direct link from an authoring or decision support tools to a local simulation/analysis

tool is also possible. However, regardless of the underlying communication protocols used, a

coherent high level semantic BCF-API based on the buildingSmart collaboration format (Linhard et al.

2015) is uniformly defined and supported by all services. Thus, all services can be installed as

separate components, embedded in other end user tools or centrally used as web services.

In principle, the Service Oriented Architecture (SOA) for eeEmbedded is implemented with all consu-

mers (clients) and providers (servers) connected to a single service bus as shown in

Figure 1. Thus, service calls go via bus directly from the client to the server(s) as marked with (1) in

Figure 1. Since the service providers themselves may know other providers, the consumer may use the

“first” provider as a gateway (1) to composite services as indicated with (1) and (2). This is a quite

common use of the service bus, as the repository services in many cases will provide data for

application services like energy and LCC analyses and simulations. When a service like for example data

storage is available on multiple servers, the data packages themselves will contain sufficient

information so the clients will know where to invoke the service. Within the eeEmbedded use cases,

this information will directly or indirectly reside in BCF messages which are controlled/handled by a

single instance BCF server. Hence, this BCF server implicitly plays the role of “bus controller” to the

extent this is required.

Service bus

Service X

Consumer X

Service X

Consumer XConsumer X

Service X

Consumer X

Service X

Consumer X

1 2

Figure 1: eeE service bus, with (1) direct usage or (1+2) composite service via gateway (1)


/72


2 The eeEmbedded Platform

Figure 2 provides a layer-oriented overview of the eeEmbedded platform as defined in Deliverable

D1.5 (Zellner et al. 2015). It defines the following six layers:

Repository Layer at the bottom, which represents the common project-wide information

storage, computational and hardware basis for all other layers

Service Component Layer which encompasses the basic services that enable the unified access

to the repository layer

Shared Services Layer which combines those basic services into more complex, higher level

services offering extended and specialized information functionality

Communication Layer providing a BCF-based Service Bus which connects the three lower

layers located on the Internet with the following two layers in the users’ Intranet thereby

enabling the communication between the different actors in the project team

Virtual Lab Layer which covers the virtual lab functionalities on user side which are individual

for each domain

User Layer which incorporates the actual value-add expert applications of the end users (CAD

systems, decision making tools etc.)

Figure 2: Conceptual Platform View on the eeEmbedded Architecture (from D1.5, Zellner et al. 2015)


/72


Within these layers, the following service types have been identified:

Local Apps, short for local applications, are executed and presented on the client’s hardware

Web Apps, short for Web applications, run partially or totally on a server while they are

displayed on the client’s hardware; They are typically accessed via a web browser but can also

be called by other web enabled tools or services such as the multi-model Navigator (mmNav)

or the platform’s Scenario Manager (ScM)

Services offer a set of functionalities or resources which can be included in other applications.;

Depending on their location or intention they can be further divided into:

o Libraries that can offer basic or even specialised functionalities like the model filtering

services BIMFit

o Cloud Services that are locate on distant servers (in the cloud) or offer access to them

o Collaboration Services offering collaboration functionalities

o Repository Services enabling the access to storage and management repositories

o Subservices which are addressed by other Services (e.g. the BIM--it User Management

Subservice UMS)


/72


3 Software Components

As already briefly mentioned, the principal eeE platform architecture presented in D1.5 (Zellner et al.

2015) comprises the following modules (see Figure 3):

Authoring and Decision Support Module comprising CAD systems and related tools for the

development of the design solution, resulting in BIM and associated modelling data. As end-

user tools they are local desktop applications or are embedded in the Web Browser.

Simulation and Analysis Services Module providing the energy related computational services

and tools. These desktop applications or cloud-enabled batch services allow the project team

members to prepare the data and use the computational services themselves without the

need for simulation experts in this phase.

Core Module binding together the components of the other two modules and acting as

middleware that provides the required data and functional interoperability of the Virtual Lab.

The Core Module itself comprises four sub-modules:

Collaboration Management for the overall execution and coordination of the project processes,

Multi-Model Management for the interoperability of the information distributed among multiple heterogeneous models,

Simulation Management for the needed pre- and post-processing facilities for parallel simulations, each of which consists of a set of services supporting the applications, services and tools of the other two modules.

Resource Access Management for information storage, search and retrieval on multiple model servers, and

Information Repositories – comprising the all storage and computing resources. This covered

intra as well as internet storage resources like model servers.

Figure 3: Principal eeE Architecture of the Virtual Holistic Design Lab from D1.5 reduced to modules

The extensions of this initial architecture, shown in Figure 4 below, are manifold. They address the

detailing, the integration and the harmonization of the information regarding the platform

components.

The Information Repositories module (discussed in section 3.7 below) was detailed by covering the

BIM-It repository as well as the EDM and the BIM servers and an Ontology Repository. Consequently,


/72


the Module Resource Access Management was separated from the central block of modules and

combined with the collaboration layer. The resulting Collaboration & Resource Access Management

Services module (section 3.6 below) has been reified and now covers the BIM-It Service, the User

Management Service embedded in it, as well as the Model Access Services for EDM and BIM+

(EDM/MAS, BIM+/MAS) and the Ontology Access Service (OAS).

For better differentiation, the Authoring Tools (section 3.1) on the one hand and the Collaboration

and Decision Support Tools (section 3.2) on the other hand were also separated into two blocks. The

components which are also covered in section 3.1 are assigned to those two blocks as well as to the

Multi Model Management Services module (section 3.3), the Simulation/Analysis Management

Services (section 3.4) and the Simulation and Analysis Computational Services (section 3.5).

These updated modules of the platform are described separately in the following sections, whereby

for each software component the type (local application, web application, service), the actors

involved in its use and a short description are provided.

Figure 4: Extended and updated eeE Architecture “Virtual Holistic Design Lab”

End-User Authoring Tools

ALLPLAN

DDS-CAD

Multi-Model Management Services Simulation/Analysis Management Services

Simulation and Analysis Computational Services (Compute Cloud)

Collaboration & Resource Access Management Services

Information Repositories (Data Cloud)

3DTherm

3DWind

EDM/MAS

BIM+

BIMFit

BIM-It

EDM

BIM+/MAS

iTWO

ESD

GD

KPA

MCS

MMNav

MMS

MVS

OMS OVS

RAS

SaS SMM

SRM

UMS

ScM

TRNSYS

iTWO/LCA

iTWO/LCC

TMS

Ontology Rep.

End-User Collaboration & Decision Support Tools

OAS

BIM-It Rep.

eeBACSWiz


/72


3.1 Authoring Tools

The authoring tools in the eeEmbedded platform comprise CAD systems and related tools for the

development of the design solution in the form of BIM and associated modelling data. These are the

primary tools in the hands of the end user and they are typically local desktop applications, albeit it is

also possible to embed them in web browsers and use them as web applications. Table 1 below lists

the authoring tools in the scope of the eeEmbedded prototype system. In a productive environment

they will be typically used in scenarios derived from the generic design scenario, but iTWO may also

be used to trigger the LCA/LCC services within simulation scenarios derived from the generic

simulation scenario described in deliverable D1.5. More specifically, ALLPLAN and iTWO will be

applied in support of all envisaged usage scenarios (urban design, early design, detailed design),

DDS-CAD, eeBACSWiz and GD in the early design and detail design scenarios, and ESD (related to the

development of the energy system information model) only in the urban design scenario.

Table 1: Authoring Tools on the eeEmbedded Platform

Acronym Full Name Component

Type Short Component Description

Actors involved*

ALLPLAN Architectural CAD (ALLPLAN)

Local app.

Comprehensive 3D design system for architects and engineers efficiently supporting the design process from the initial draft to application and construction cost planning right through to working and detailed drawings. It comprises a full range of tools for design, layout and visualization as well as the estimation of quantities and costs.

ARCH

DDS-CAD MEP-CAD System (DDS-CAD)

Local app.

3D design system for Mechanical, Electrical and Plum-bing systems - from 2D design to 3D modelling through to the virtual building space model. DDS-CAD MEP pro-vides the MEP Model design part for eeE which can be further used for cost estimation.

MEP, FM

eeBACSWiz eeBACS Wizard Web app.

Prototype eeE application that allows the BACS planner to find the correct set of templates based on KDRs in the Early Design Phase. Based on the resulting templates, simulation, LCA and LCC analysis can be performed in later stages of a project.

BACS

ESD Energy System Designer

Local app.

Prototype eeE application developed from scratch to enable specification of an Energy System Information Model (ESIM) covering neighbourhood related, loca-tion linked and BIM related information.

EE

GD Granlund Designer Web app.

Prototype application for FM that can be used to read main HVAC components from HVAC BIM models, add missing information by utilizing HVAC templates and define HVAC system service areas. The main task of GD is to link HVAC components to FM templates to define LC service life and maintenance needs.

MEP, FM

iTWO

5D End-to-End Enterprise Solution (RIB iTWO)

Web app.

New generation software system that unifies state-of-the-art construction management with innovative 5D planning, providing for the integration of design and process planning data, BIM based quantity and cost estimation and BIM based construction process simulation.

CE, DM

Actor abbreviations: ARCH = Architect, BACS = Building Automation and Control System Designer, BM = BIM Manager, CE = Cost Estimator,

DM = Decision Maker, EE = Energy Expert, FM = Facilities Manager, MEP = MEP Designer


/72


3.2 Collaboration and Decision Support Tools

The collaboration and decision support tools are specialized eeEmbedded applications developed

from scratch that provide the primary user access to the energy related services of the virtual energy

lab platform. Featuring comprehensive user interface and visualization capabilities, they enable the

users to monitor and control the overall design process, collaborate efficiently within the design

team and use various platform services to perform their tasks. Three such services will be

implemented on the eeEmbedded platform as shown below in Table 2.

Table 2: Collaboration and Decision Support Tools on the eeEmbedded Platform



Actors involved*

KPA Key Point Analysis Tool

Web app.

Prototype eeE application which purpose is to support the decision making process that aims to meet intended target values and deter-mine the different alternatives on the basis of the best possible solu-tion(s). The visualisation (embedded in the MMNav) will enable intu-itive reasoning to analyse the simulation results, investigate the eff-ects of design variables taking into account different KPIs and assess the impact on different alternatives. The graphical representation will use advanced visualisation techniques to provide for fast over-view and comparison of simulation results.

ARCH, EE, DM

MMNav Multi Model Navigator

Web app.

Prototype eeE application developed from scratch to provide, toge-ther with the eeE Scenario Manager, the main user interfaces to the eeE virtual lab platform for all disciplines involved in the energy-optimised design, building and FM processes. MMNav will be conn-ected to the BIM+ Platform to allow for flexible navigation in the nD information space thus enabling visual design control of project vari-ants and the presentation of simulation results in detailed and in simplified (aggregate) form. In addition, support for decision makers will be provided by embedding the Key Point Analysis Services in the GUI.

ALL

ScM Scenario Manager

Local app.

Prototype eeE application developed from scratch to provide, toge-ther with the MMNav the main user interface to the eeE virtual lab platform for all disciplines involved in the energy-optimised design, building and FM processes. It will support the collaborative project process by dynamically assigning and monitoring project tasks and attaching the required data and actions to them. In this way, project work can proceed in coordinated manner with clearly allocated responsibilities, work items, deadlines and interdependencies for each member of the project team.

ALL




/72


3.3 Multi-Model Management Services

The Multi-Model management services (Table 3) are part of the eeE platform core module. They

provide various functions needed for appropriate generation and handling of the multi-models

integrated in the eeE modelling framework. Such functions include: (1) Filtering on model and multi-

model level, (2) Combining data of multiple independent modelling resources into an interoperable

ontology-based eeeBIM model using the developed Link Model approach as well as pre-defined

parameterized templates, (3) Various model manipulations such as grouping / splitting of objects,

editing object attributes directly or transitively etc., (4) Model versioning, and (5) Model validation

on the basis of pre-defined rule sets, including also risk analysis.

Table 3: Multi-Model Management Services on the eeEmbedded Platform



Actors involved*

BIMFit BIM Filtering Service

Library / Service

Software framework enabling search, filtering and retrieval of BIM/IFC model data on four levels: 1) schema, 2) class, 3) object, and (4) reasoning level. Functionality on class level (view definition) is complemented by a set of semantic and geometry-oriented algorithms such as zoning, enclosure etc. Filtering of other, comparatively simpler data models based on XML will be provided as part of the Model Manipulator Services (MMS).

ALL

MCS Model Combiner Service

Service

Prototype eeE service developed from scratch that will offer the framework for working with Multi Models. It will enable the creation of Multi Models comprised of elementary (domain) models and the generation of links be-tween their elements. Hence, it will provide a plug-in mechanism for the generation of specific task-oriented Multi Model views (e.g. filtered, inter-connected BIM-BAS data for a set of rooms, corresponding to some pre-defined criteria such as temperature or humidity threshold).

ALL

MMS

Model Manipu-lation Services

Library / Service

Prototype eeE service developed from scratch with the following purpose: 1) to enable filtering of non-BIM data in XML or CSV format (such as GAEB data, climate data, occupancy data etc.), 2) to support the transformation of all elementary models to eeBIM , and 3) to enable changing parameters of non-geometric eeBIM data.

BIM Manager

(ALL)

MVS Model Versioning Service

Service

Prototype service to store models in a repository and enable comparisons of different versions. This is especially important in the decision making process where simulation of energy performance for different model ver-sions or different design alternatives are examined.

ALL

OMS Ontology Mgmnt Service

Service

Prototype eeE service developed from scratch comprising various functions enabling the management of the data in the eeE platform ontology such as CRUD functionality with regard to ontology individuals, dynamic definition of new concepts / groups etc.

BM (ALL)

OVS

Model Validator Service (ontology-based)

Service

Prototype eeE service developed from scratch to check the correctness of the required level of development (LOD) and level of detailing (LoD) of an eeBIM model on the basis of pre-defined rule sets. The service will enable fast validation of key point values on the basis of formulae and rules taken from existing regulations before starting a comprehensive simulation, in order to identify potentially weak points in a suggested design solution and enable focusing on specific parameters for in-depth sensitivity analyses.

ARCH, MEP,

BACS, FM

RAS Risk Analysis Service

Service

Prototype eeE service to perform sensitivity and uncertainty analyses. The service produces sensitivity indices and Key Risk Indicators (KRIs) that are used as basis for building design optimisation and risk-aware decision making. For that purpose those outputs are integrated into the KPA. The service relies on the outputs of the different simulations (energy simulation, reliability analysis, cost calculation...) and on the stochastic sampling.

EE, FM

TMS Template Mgmnt Service

Service

Prototype eeE service developed from scratch which will support the management of process and information templates, other than the ones defined on the level of the end-user CAD systems (ALLPLAN, DDS-CAD). Such templates will enable definition of alternative sub-processes to the pre-defined via BPMN high-level scenarios as well as the input of ee data for needed energy and LCA/LCC simulations in early design phases.

ALL




/72


3.4 Simulation and Analysis Management Services

The simulation and analysis management services, which are also part of the eeE platform core

module, have the task to map the eeeBIM data to produce appropriate simulation input data sets,

and vice versa – map simulation output results to KPIs and link them to the eeeBIM data.

Additionally, a stochastic sampling service is provided to tackle the stochastic nature of certain

design variables whenever necessary. These services are considered in Table 4.

Table 4: Simulation Management Services on the eeEmbedded Platform



Actors involved*

SaS Stochastic Sampling Service

Service

Prototype eeE service that generates several samples of stochastic vari-ables on the basis of their probability distributions. The service relies on a random number generator and applies to all eeE regressors (stochastic variables). Different sub modules can compose the service according to the kind of variables to be sampled (occupancy, climate, reliability, prices, etc.). The samples are exported into the job matrix and further processed by the different simulation engines on the eeE cloud.

EE

SMM Simulation Model Mapper

Service

Prototype eeE service enabling the pre-processing of the input data for various simulations. The service will provide for configuring the overall simulation process by defining and storing multiple energy-related design alternatives including stochastic parameter variations in one single XML-based data structure. These can then be used to run analyses/simulations in parallel in the eeE cloud environment.

ALL

SRM Simulation Results Manager

(Cloud) Service

Prototype eeE service which will provide the bridge between the cloud-based post-processing of results from performed simulations and the multi-model Navigator where such results will be visually presented as well as the KPA tool which will be responsible for KPI-based decision making regarding various design variations or alternatives. Broadly speaking, this service will provide the counterpart to the Simulation Model Mapper (SMM) on the eeE platform.

EE




/72


3.5 Simulation and Analysis Computational Services

Simulation and analysis services, shown in Table 5 below, are run in a computational cloud environ-

ment. They receive a set of input data, run the requested energy/cost simulations and produce a set of

output results. Depending on the specific scenario tasks and the forecasted time needed for the

execution of a simulation, such services may be run individually or in parallel using synchronous or

asynchronous service calls and applying specifically designed for that purpose cloud based workflow

manamgent.

Table 5: Simulation and Analysis Computational Services on the eeEmbedded Platform



Actors involved*

3DTherm 3D Thermal CFD Analysis

Cloud service

End user application providing comprehensive CFD simulation capabilities for detailed analysis of the indoor climate in buildings. It provides for evaluation of the performance of the HVAC systems, prediction of thermal comfort conditions and the design of special purpose ventilation, heating and cooling systems according to the geometrical design of the building.

EE, MEP, BACS

3DWind 3D Wind CFD Analysis

Cloud service

End user application for the aerodynamic analysis of a building embedded in its urban environment to obtain the best buil-ding cubature (shape and orientation) regarding energy con-sumption indices, local wind potential for renewable energy use and natural ventilation design (as a result of the combi-nation of solar radiation and wind flow). 3DWind can be used as complementary tool to energy simulation applications in urban design.

EE, ARCH

iTWO/LCA Life Cycle Assess-ment Service (as plug-in for iTWO)

Local app.

Prototype eeE service embedded in the iTWO system that will be used together with the iTWO/LCC service to determine the most cost and energy efficient building alternative, fully regarding environmental impacts such as energy or CO2 consumption.

CE, DM

iTWO/LCC Life Cycle Costs Service (as plug-in for iTWO)

Local app.

Prototype eeE service embedded in the iTWO System that will be used in all identified use cases for the eeE platform to perform life cycle cost estimation and identify the design alternative with the best cost-quality ratio.

CE

TRNSYS Energy Simulation Services (TRNSYS-TUD)

Cloud service

Multi-purpose energy simulation which will be used in all eeE use cases for analysing the thermal behaviour of the building including the operation of internal and external energy systems and main HVAC components. TRNSYS-TUD will be re-engineered for the use as cloud service and due to its modular design and comprehensive set of built-in analysis algorithms it will enable execution of a broad variety of analysis tasks.

EE




/72


3.6 Collaboration and Resource Access Management Services

Project collaboration on user and service level on the eeE platform is consistently managed via a

platform service bus, implementing the BuildingSmart BCF v2.0 API (see Chapter 10). For that purpose

the BIM-It collaboration service is developed. It manages all BCF messages, including Link Model based

Multi Model references to the relevant data, and provides access to the BCF Repository of the eeE

platform. Similarly, data access to all model repositories is provided by specific harmonized middleware

services using a common BIM API developed for the eeE platform. Access rights to all information

repositories are managed and resolved via a central User Management Service embedded in BIM--it.

The corresponding services are shown in Table 6.

Table 6: Collaboration and Resource Access Management Services on the eeEmbedded Platform



Actors involved*

BIM--it BCF Collaboration Service

Collaboration Service

Central eeE platform service offering a collaborative envi-ronment to integrate multiple project participants into a single workspace in which they organize, coordinate, plan and review their work effort. It fully supports BCFv2 over BCF REST API v1 (s. https://github.com/BuildingSMART/BCF and [..] /BCF-API). The service enables role based communication via BCF topics with enhanced functionalities and a project timeline to track the overall project progress.

ALL

BIM+/MAS Model Access Service to BIM+

Repository Service

Model access service to BIM+ fully supporting the BIM+ as well as the eeE unified BIM API that will be forwarded to BuildingSmart for standardisation.

ALL

EDM/MAS Model Access Service to EDM

Repository Service

Model access service to EDM fully supporting STEP/EXPRESS as well as the eeE unified BIM API that will be forwarded to BuildingSmart for standardisation. The service will support exporting and importing models from the EDM repository in their entirety as a file but also the import/export of sub models.

ALL

OAS Ontology Access Service

Service Prototype eeE service developed from scratch to access the data stored in the eeE platform ontologies using a SPARQL based API.

BM (ALL)

UMS User Management Service

BIM-It subservice

This service, embedded in BIM-It provides for creating or deleting users/actors, storing and checking their creden-tials and building user repositories, where each user can store files in. The latter will be done with the help of the cloud-based model repositories (BIM+, EDM) on the eeEmbedded platform. In the eeEmbedded project a Single-Sign-On approach (Oauth2) is suggested by provi-ding an authentication token to each repository by the BIM-it server.

ALL




/72


3.7 Information Repositories

For eeEmbedded, the service bus will provide access to the service providers for data storage and

repository functions as described in Table 7 and shown in Figure 5.

Table 7: Information Repositories on the eeEmbedded Platform



Actors involved*

BIM-It Rep.

BCF Repository

Server

BCF server offering the BCF REST API v1 for all clients to connect to. For that purpose it stores all BCF content, such as Topics, Comments, View-points as well as the “Extension.xsd” which contains project related definitions such as TopicType, TopicStatus, Labels and also user accounts which means that the BIM-it server is the central hub for authentication.

ALL

BIM+ BIM+ Repository

Cloud Repository

Open BIM compliant cloud repository for connecting people, building project information and BIM models, supporting both Nemetschek's BIM+ and IFC-based building modelling.

ALL

EDM EDM Repository

Cloud Repository

IFC (ISO 16739) and ISO STEP (ISO 10303) compliant cloud repository providing intelligent model-based storage of any data defined by the ISO 10303 Part11 EXPRESS language, IFC 2x3, IFC4, IFD and more. In addition any data can be stored in file/BLOB format which are logically linkable into the structured STEP/IFC based data.

ALL

Onto. Rep.

Ontology Repository

Server Repository for all data managed by the eeE platform repository, including key BIM data extracted and dynamically derived from the full BIM models, KDRs, KDPs and KPIs as well as process templates.

ALL



Figure 5: Service bus and providers

To access data in the repositories, the servers offer one or more sets of services used via common

APIs as outlined in Chapter 9. These APIs are supported as shown in Table 8.

Table 8: APIs and their use for the information repositories on the eeEmbedded Platform

API Used in / Supported by Comment

BIM-It Rep.

BIM+ EDM Onto. Rep.

BIM API

X X X (X) Provides general access to files and models. The eeE unified BIM API is a new development that will be forwarded for standardisation to BuildingSmart (see https://github.com/BIMit/ModelAPI)

BCF API

X (X) (X) X BuildingSmart BCF (BIM Collaboration Format V. 2) (see https://github.com/BuildingSMART/BCF

BIM+ API

X Nemetschek’s BIM+ open access API (see https://doc.bimplus.net/pages/viewpage.action?pageId=4459171)

Onto API

X New eeE development that will provide SPARQL-based queries to the ontology repository (see http://www.w3.org/TR/rdf-sparql-query/)

SIM API

X New eeE development building upon prior findings from the EU project ISES that will provide a XML-based API to define design parameter variations and execute parallel analysis or simulations for various combinations of these parameter variations

Note: A (X) mark indicates that the service is available, but not used in the current platform scenarios.

Service bus

BIM+ BIM-It RepositoryEDMmodelServer Onto. Repository

https://github.com/BIMit/ModelAPI

http://www.w3.org/TR/rdf-sparql-query/


/72


3.8 BIM Support

Standard BIM based on IFC is a prerequisite for the software interoperability on the eeEmbedded platform. However, currently the IFC standard is still actively developed and extended. The latest version of the model schema, IFC4 (2013) is the current officially recognized and future-oriented standard which is significantly broader than the preceding IFC2x3 version of the standard (ISO 16739, 2013), especially with regard to the BACS and HVAC domains. However, IFC2x3 is still the most broadly and most comprehensively vendor-supported version whereas support for IFC4 is yet rudimentary. Therefore, the status and the feasible perspectives in the eeEmbedded timeframe had to be examined and assessed for each module in the SOA system architecture. The result of that survey is presented in Table 9 below.

Table 9: IFC support by the different software components on the eeEmbedded Platform

Acronym Full Name IFC Support

IFC2x3 IFC4

3DTherm 3D Thermal CFD Analysis Import Import

3DWind 3D Wind CFD Analysis Import Import

ALLPLAN Architectural CAD (NEM ALLPLAN) Import/Export --

BIM-It BCF Collaboration Service N/A N/A

BIM-It Rep. BCF Repository N/A N/A

BIM+ BIM+ Repository Import/Export --

BIMFit BIM Filtering Service Import/Export Import/Export

DDS-CAD MEP-CAD System (DDS-CAD) Export (no BACS) Export

EDM EDM Repository Import/Export Import/Export

eeBACSWiz eeBACS Wizard -- Import/Export

ESD Energy System Designer N/A N/A

GD Granlund Designer Import Import

iTWO RIB iTWO Enterprise Solution Import/Export (Import)

iTWO/LCA Life Cycle Assessment Service for iTWO Import/Export (Import)

iTWO/LCC Life Cycle Costs Service for iTWO Import/Export (Import)

KPA Key Point Analysis Tool N/A N/A

MCS Model Combiner Service (Import/Export) (Import/Export)

MMNav Multi Model Navigator Import/Export --

MMS Model Manipulation Services Import/Export (Import/Export)

MVS Model Versioning Service N/A N/A

OMS Ontology Management Service Import Import

OVS Model Validator Service (ontology-based) N/A N/A

Onto. Rep. Ontology Repository Import Import

RAS Risk Analysis Service (Import) (Import)

SaS Stochastic Sampling Service (Import) (Import)

ScM Scenario Manager Import/Export Import/Export

SMM Simulation Model Mapper (Import) Import

SRM Simulation Results Manager N/A N/A

TMS Template Management Service N/A N/A

TRNSYS Energy Simulation Services (TRNSYS-TUD) (Import) Import

UMS User Management Service N/A N/A

As the table shows, for some tools/services the use of IFC4 is mandatory whereas for others it is highly questionable due to larger implementation scope, complex internal procedures, dependence on external resources etc. Due to that, the parallel use of both IFC versions is seen as an issue requiring the development of an Y-approach for the supported scenarios where some services/tools will use the newer and some the current (older) IFC version. Additional mapping services and/or Link Model(s) may have to be developed to handle that issue successful.


/72


4 Scenario Workflows

4.1 Overview

Using both a conceptual top-down and a practice-related bottom-up approach four generic scenarios

covering

the platform set up,

the design domain,

the simulation and analysis domain, and

a generalized decision making process have been defined in D1.5 (Zellner et al. 2015).

On that basis, over thirty concretely detailed scenario workflows were defined in D2.3 (Guruz et al.

2015), presenting the specific processes related to Urban Design, Early Design and Detailed Design

that will be supported by the eeE platform. What was yet missing in these specifications were:

(1) Technical refinements and adjustments regarding the specific implementation considerations of

the SOA approach,

(2) Extensions regarding the technical collaboration and information exchange issues related to the

use of BCF as primary collaboration format,

(3) Appropriate consideration of the adopted Link Model / Multi-Model Container approach,

(4) the use of Ontologies and related ontology management and validation services, and

(5) the allocation of specific software components to each specific task and information exchange

within the scenarios.

These extensions and refinements of the original UML sequence diagrams from D1.5 and D2.3 are

presented in this and the following three chapters. In order to leave the overall appearance of the

diagrams unchanged (for easier comparison and recognition of the original diagram layout) no new

swimlanes for each of the defined platform services and tools have been introduced. Hence, only the

original categorisation in Design tools, Decision Support tools, Management services and Simulation

and Analysis services is shown. To indicate which component is used at which specific task and

information transfer, for each such task (shown with a respective arrow in the UML sequence

diagrams) beside the task subject the tool/service acronym is provided in brackets*). Loops or jumps

back are shown with dashed lines to distinguish them clearly from the normal top-to-bottom

procedure. Additionally, at several places text boxes explaining certain specific issues or constraints

that cannot be formally represented on the diagrams are also included. At last, a difference to the

diagrams from D2.3 is also that all swim lanes (lifelines) are always shown in the same colour, i.e.

Design Modules in blue, Decision Support tools in green, Management services in grey, and Simlution

and Analysis services in orange. Key Points (KDRs, KPIs etc.) as well as information exchanges are not

directly related to the SOA of the platform and are therefore not further elaborated compared to

D2.3 and consequently omitted in the following diagramatic representations.

*) An exception to that is the case when a service only returns an acknowledgement that the requested task has been

successfully executed, but no other data is sent back to the calling service/tall. This is denoted by ‘Ack’.


/72


4.2 Generic Set Up Scenario

The first developed generic scenario covers the setting up of the eeE platform environment including

the allocation of repositories, the initial information space and the specification of the design Key Points,

the Levels of Detail (LoD) and Levels of Development (LOD) for the particular building project contract.

To do that efficiently, templates based on the experience will be used as much as possible.

The scenario is repeated in the elaborated specific usage scenarios in the following Chapters 5-7 but

with partially diverging content and considerably different information background in each case. The

latter is not directly visible in the UML sequence diagrams but is of vital importance for the actual

software implementations. How this is further done is shown on an example in Chapter 8.

As already mentioned, in this and all subsequent diagrams the service/tool responsible for a specific task

is shown by its acronym in brackets after the description of each shown action*).

Design ModulesSimulation/ Analysis

Modules

DECISION SUPPORT

BIM SERVER

Ontology Services

Management ServicesUser incl. Navigator& Scenario Manager

Project setup/ settings [ScM]

Setup KEY POINT framework [ScM]

LOD, LoD, ER specification [ScM]

Save project data [BIM--it]

Save workflow data [OMS/BIM--it]

Save KEY POINT data [OMS]

Save requirements and specs. [OMS]

Save template data [OMS]

Open GUI Decision Maker View [ScM]

Hand over to architecture domain (BCF) [ScM]

Status update [BIM--it]

Based on reference process templates

Adapt/setup based on predefined specs.



Workflow setup [ScM]

Provide message to architecture domain (BCF)

Set up and manage templates [ScM]

*) All service/tool acronyms are shown at the beginning of the report.


/72


4.3 Generic Scenario for the Design Domain

This scenario covers the tasks of the designers, generalised for all three specific usage scenarios in Ch. 5-7.

DECISION SUPPORT

BIM SERVERS

Ontology Services


Modules

Ok, KEY POINT check KDP [MMNav]

ALLPLAN

DDS-CAD

eeBACSWiz

GD

ESD

Open GUI Designer View [ScM]

Ok, initiate KEY POINT Verification with KDP [MMNav]

Ok, initiate link and save KPR and KDP [MMNav]


not ok

Return KPR in LOD and LoD/ Return required model data [OMS]

KEY POINT Verification with KDP [OVS]

Ok, request for Templates? [MMNav]

Return results [TMS] Deliver Templates [TMS / OMS]

Modify Templates [MMNav/TMS]

Select Process Pattern incl. KPR [OMS]

Initiate Check LOD and LoD [MMNav]

OK or not ok [OVS]


Check LOD and LoD [OVS]

not ok

Check LOD and LoD [OVS]Ok or not ok (OVS)



Link and save KPR and KDP [OMS]Ack

Create or Update Link Model (LM) [MMNav/MCS]

Return Link Model ID [BIM--it]

Upload model data [MMNav]Upload model data (BIM-API)

Upload model data (BIM-API)

Return results [OVS]

Request user decision [MMNav]

Present results [MMNav]

OR to SIM/ANA [ScM]


Request Selection of process pattern incl. KPR [ScM]

Present process steps [ScM]

Ask user to choose process step [ScM]

Create Design in specified LoD&LOD

Initiate linking of resulting model with process step [ScM]

Return URL(s) [MAS]

Upload Link Model [MMNav]

Save Link Model [OMS/BIM--it]


Save model data [BIM--it > ((BIM+/EDM) > MAS)]


Return URL(s) [MAS]



Make variance design

message to SIM/ANA domain




Hand over KDP and model to next design domain


iTWO

{ONEOF}

Save model data [BIM--it > ((BIM+/EDM) > MAS)]


/72


4.4 Generic Scenario for Analysis / Simulation

This scenario covers the tasks of the energy and LCC/LCA analysts, generalised here for all three specific usage scenarios in Ch. 5-7.

BIM SERVERS

Ontology ServicesDECISION SUPPORT

Management ServicesUser incl. Navigator& Scenario ManagerDesign Modules

Simulation/ AnalysisModules

Template Management [TMS]

Prepare for evaluation [MMNav]

TRNSYS

3D Wind

3DTherm

iTWO/LCA

Request Preprocessing [MMNav]

Upload all results [each analysis module]

Open GUI SIM/Analysist View [ScM]

Request Template configuration [MMNav]

Request Parameter Definition [MMNav]

Preprocessing [SMM]

Preprocessing [each analysis module]

Parameter Definition [SMM]

Processing [each analysis module]

Postprocessing [each analysis module]

Save variants and alternatives [(BIM+/EDM)/MAS]

Version Management [(BIM+/EDM)/MVS]Ack

[BIM--it]

Different Views needed for analysis: beginner, architect, expert

Ack

Jobmatrix (simulation variants)

Ack

Should include stochastic!

Save all results [(BIM+/EDM)/MAS]

KEY POINT check KPI (prepared results) [OVS]

Request Key Point Check [MMNav]

KPI check results

Link and save KPR, KDP and KPI [OMS]Ack

Message to decision maker domain

Hand over to design domain (BCF)

[SRM]


Repeat simulation with other LoD or start a different simulation

- Simulation cycle -

Initiate link and save KRI, KDP and KPI [MMNav]

Prepare results based on predefined KPIs [MMNav]

Present results [ask user if results ok) [MMNav]

Ok, select suitable variants/alternatives

Upload variants and alternatives [MMNav]

Hand over KDP and model to desicion maker domain [ScM]

Run simulation variants [MMNav]

Return KPI/ Return required model data [OMS] Select Process Pattern incl. KPI [OMS]

Request Selection of process pattern incl. KPI [ScM]

Ack



Link (model) data [MCS]

Prepare for simulation [MMNav]

Ack

Key Point Analysis

NOTE:Each analysis tool can use its own compute cloud environment(configuration via BIM—it in setup phase)

Stochastic Preprocessing/Sampling [SaS]

Jobmatrix Population [SMM]

Ack

Request Stochastic Preprocessing [MMNav]

Risk Analysis [RAS]

Initiate Risk Analysis

Return results (sensitivity indices/KRI)

Return results (KPI) [SRM]

Not ok, design change necessary, back to Design Domain(s) [MMNav > ScM]

iTWO/LCCNot ok or not complete - parameter refinement

necessary based on sensitivity indices/KRI


/72


4.5 Generic Scenario for Decision Making

The final generic scenario shows the decision makers tasks. As in the setup scenario above, the process

is very similar for all usage scenarios detailed in the next three chapters but the context and the

underlying information background are considerably different.

DECISION SUPPORT

BIM SERVERS

Ontology ServicesUser incl. Navigator& Scenario ManagerDesign Module Management Services


Key Point Analysis

Select charts [KPA]

Return results (charts) [SRM]


Request Selection of process pattern incl. DVs [ScM]

Return DVs Select Process Pattern incl. DVs [OMS]

Collecting data for weighted evaluation [SRM]

Generate Charts [SRM]

Ok, save Variants and Alternatives [MMNav]

Next LOD or repeat process [MMNav]

Select best variant/alternative(s) based on DVs [KPA]

Send information to consistency check all following requirements [MMNav]

Ok or not ok

Not ok, back to Design Domain(s) [MMNav > ScM]

Prepare for decision making [ScM > MMNav/KPA]

Initiate link and save KPR, KDP and KPI [MMNav]


[BIM--it]

Ack

Consistency check [OVS]

Back to Design Domain(s) [MMNav > ScM]

Status update [BIM--it]Hand over to design domain (BCF)

Results presentation [MMNav]

- Decision Maker cycle -


KEY POINT check DVs (prepared results) [KPA]


Version Management [(BIM+/EDM)/MVS]



/72


5 Usage Scenario #1: Urban Design

This usage scenario describes how design and energy concepts are created holistically considering the

existing energetic environment. Therefore, information about topography, neighbouring buildings and

available energy systems is taken into account. A central issue is the Energy System Information Model

(ESIM) that will be established within this scenario. At the end of the scenario at Level of Development

(LOD) 100, decisions about the orientation and form of the building, the thermal standard of the shell,

the windo-to-wall area ratio, the zones and the energy systems have to be taken.

5.1 Tasks 0 / 1 “Project Set Up” / “Consistency Checking”

DECISION SUPPORT

User incl. Navigator& Scenario Manager

BIM SERVER

Ontology Services

Management ServicesDesign Modules


1 Project setup/ settings [ScM]

2 Setup KEY POINT framework [ScM]

3 Workflow setup [ScM]

4 LOD, LoD, ER specification [ScM]


save KEY POINT data [OMS]


5 Set up and manage templates [ScM]

Save requirements [OMS]




Status update [BIM--it]Send message to architecture domain (BCF)





/72


5.2 Task 2 “Create Design Cubature Options”

DECISION SUPPORT

BIM SERVER

Ontology Services


ModulesUser incl. Navigator& Scenario Manager Management Services


ALLPLAN





not ok



Ok, request for Templates [MMNav]

Return results [TMS] Deliver Templates [TMS/OMS]




OK or not ok [OVS]



not ok






Save IFC model data [BIM--it > ((BIM+/EDM) > MAS)]


Upload IFC model [MMNav]Upload IFC model (BIM-API)

Upload IFC model (BIM-API)



Present results. [MMNav]




Create Design in specified LoD&LOD

Initiate linking of IFC model with process step [SCM]

Return URL(s) [MAS]






Return URL(s) [MAS]







ALLPLAN

Hand over KDP and model to SIM/ANA [ScM]

Send message to SIM/ANA domain



/72


5.3 Task 3 “CFD Simulation (3D Wind)”

BIM SERVER





3D Wind





Preprocessing [SMM]

Preprocessing [3D Wind]


Processing [3D Wind]

Postprocessing [3D Wind]

Ack

[BIM--it]



Ack





KPI check results



[SRM]













Ack



Link (model) data [MMC]


Ack

Key Point Analysis




Ack


Risk Analysis [RAS]




Process user decision based on presented results


Send message to ESIM



Not ok or not complete - parameter refinement



/72


5.4 Task 4 “Create Energy Supply Options”

DECISION SUPPORT

BIM SERVER

Ontology Services


ModulesManagement ServicesUser incl. Navigator& Scenario Manager


ESD





not ok





Modify Templates [MMNav]



OK or not ok [OVS]



not ok






Save ESIM [BIM--it > ((BIM+/EDM) > MAS)]


Upload ESIM model data [MMNav]Upload ESIM (BIM-API)

Upload ESIM (BIM-API)




Hand over KDP and model to SIM/ANA [ScM]





Create ESIM Design in specified LoD&LOD

Initiate linking of IFC model with process step [ScM]

Return URL(s) [MAS]




Save ESIM [BIM--it > ((BIM+/EDM) > MAS)]


Return URL(s) [MAS]




Send message to SIM/ANA




ESD


/72


5.5 Task 5 “Energy Simulation”

DECISION SUPPORT

User incl. Navigator& Scenario ManagerDesign Modules



BIM SERVER

Ontology Services

Management Services


TRNSYS





Preprocessing [SMM]


Ack

[BIM--it]


Ack





KPI check results



[SRM]












Ack





Ack

Key Point Analysis

NOTE:Each analysis tool can use ts own compute cloud environment(configuration via BIM—it in setup phase)



Ack


Risk Analysis [RAS]






Hand over KDP and model for LCA check [ScM]

Send message to LCA domain Status update [BIM--it]



Preprocessing [TRNSYS]

Processing [TRNSYS]

Postprocessing [TRNSYS]




/72


5.6 Task 6a “Life Cycle Costing (without consideration of stochastic variables)”


Modules

Hand over to decision maker domain


BIM SERVER


User incl. Navigator& Scenario Manager Management Services



iTWO/LCC


Upload all results [iTWO]




Preprocessing [SMM]

Preprocessing [iTWO]

Parameter Definition [SMM (Jobmatrix)]

Processing [iTWO]

Postprocessing [iTWO]

Ack


[BIM--it]


Ack


Ack




Ok or not ok



[SRM]




Ok, initiate link and save KPR, KDP and KPI [MMNav]









Ack



Link (model) data [MCS]


Ack

Key Point Analysis


[BIM--it]Hand over to design domain (BCF)



return results (KPI) [SRM]


necessary


/72


5.7 Task 6b “Life Cycle Costing (including consideration of stochastic variables)”

BIM SERVER






iTWO/LCC






Preprocessing [SMM]


Ack

[BIM--it]


Ack


Ack





KPI check results




[SRM]













Ack





Ack

Key Point Analysis




Ack


Risk Analysis [RAS]








Processing [iTWO]


LCC, incl. stochastic Risk Analysis




/72


5.8 Task 7 “Decision Making”

DECISION SUPPORT

BIM SERVER

Ontology ServicesUser incl. Navigator& Scenario ManagerDesign Module Management Services Simulation/ Analysis

Key Point Analysis

Select charts [KPA]





Simulation & Analysis Mgmt. Services [SRM]







Ok or not ok





[BIM--it]

Ack








Next Set up decision making domain (BCF)




/72


6 Usage Scenario #2: Early Design

The scenario focuses on the early design phase where concepts are created based on the outcome of

the urban design phase. This is done largely by detailing the room structure and principal geometry as

well as by creating the initial HVAC layout. With the help of detailing templates the construction type,

HVAC type, BACS alternatives and their influences on energy, emissions, thermal comfort and LCC

performance indicators (KPIs) are analysed. The Level of Detail (LoD) and the Level of Approximation

(LoA) are 200, which means medium accuracy. At the end of the scenario at LOD 200 informed decisions

about the space layout, the major building element characteristics (thickness, main materials used), the

HVAC system and the BACS strategy have to be taken in correspondence with the client requirements.

6.1 Tasks 0 / 1 “Project Set Up” / “Consistency Checking”



Modules








Status Update [BIM--it]




DECISION SUPPORT


BIM SERVER

Ontology Services

Management Services

2 Workflow setup [ScM]

Send message to architecture domain (BCF)

4 Set up and manage templates [ScM]


/72


6.2 Task 2 “Create Construction Type Alternatives”

DECISION SUPPORT

BIM SERVER

Ontology Services




ALLPLAN





not ok








OK or not ok [OVS]



not ok








Upload IFC model data [MMNav]Upload IFC model data (BIM-API)

Upload IFC model data (BIM-API)




Hand over KDP and model to HVAC domain [ScM]





Create construction type alternatives


Return URL(s) [MAS]






Return URL(s) [MAS]







Send message to HVAC domain

ALLPLAN


/72


6.3 Task 3 “Create HVAC Type Alternatives”

DECISION SUPPORT

BIM SERVER

Ontology Services


Modules

DDS-CAD + templates

DDS-CAD + templates







not ok








OK or not ok [OVS]



not ok













Hand over KDP and model to BACS domain [ScM]





Create HVAC type alternatives


Return URL(s) [MAS]






Return URL(s) [MAS]



Make HVAC variance design




Send message to BACS domain


/72


6.4 Task 4 “Create Control Strategy Alternatives”

DECISION SUPPORT

BIM SERVER

Ontology Services




eeBACSWiz





not ok







OK or not ok [OVS]



not ok














Create control strategy alternatives

Return URL(s) [MAS]





Return URL(s) [MAS]







Hand over KDP and model to FM domain [ScM]

Status update [BIM--it]Send message to FM domain

eeBACSWiz







/72


6.5 Task 5 “Enrich Alternatives with O&M Information”

DECISION SUPPORT

BIM SERVER

Ontology Services




GRA Designer




not ok








OK or not ok [OVS]



not ok





Return Link Model ID [BIM--it?]


Upload enrichted IFC model data (BIM-API)




OR to SIM/ANA [ScM]





Enrich alternatives with O&M information


Return URL(s) [MAS]





Return Link Model ID [BIM--it?]

Return URL(s) [MAS]






GRA Designer

by making different O&M strategies

Note:No Key Point check needed in O&M


/72


6.6 Task 6 “Energy Simulation”

BIM SERVER





TRNSYS





Preprocessing [SMM]


Ack

[BIM--it]



Ack





KPI check results



[SRM]













Ack





Ack

Key Point Analysis




Ack


Risk Analysis [RAS]





Send message to LCA domain




Processing [TRNSYS]





/72


6.7 Task 7a “Life Cycle Assessment (w/o consideration of stochastic variables)”


Modules

BIM SERVER




iTWO/LCARequest Preprocessing [MMNav]



Preprocessing [SMM]


Processing [iTWO]


Ack


[BIM--it]


Ack





Ok or not ok



[SRM]return results (KPI) [SRM]











Ack





Ack

Key Point Analysis




Hand over KDP and model to LCC domain [ScM]

Send message to LCC domain





necessary


/72


6.8 Task 7b “Life Cycle Assessment (incl. consideration of stochastic variables)”

BIM SERVER






iTWO/LCA






Preprocessing [SMM]


Ack

[BIM--it]


Ack


Ack





KPI check results



[SRM]













Ack





Ack

Key Point Analysis




Ack


Risk Analysis [RAS]









Processing [iTWO]


LCA, incl stochasticRisk Analysis (?)




/72




Modules


BIM SERVER





iTWO/LCC






Preprocessing [SMM]



Processing [iTWO]


Ack


[BIM--it]

Ack


Ack





Ok or not ok


Hand over to decision maker domain


[SRM]

[BIM--it]













Ack





Ack

Key Point Analysis


[BIM--it]Hand over to design domain (BCF)NOTE:Each analysis tool can use its own compute cloud environment(configuration via BIM—it in setup phase)




necessary


/72



BIM SERVER






iTWO/LCC






Preprocessing [SMM]


Ack

[BIM--it]


Ack


Ack





KPI check results




[SRM]













Ack





Ack

Key Point Analysis




Ack


Risk Analysis [RAS]








Processing [iTWO]


LCC, incl. Risk Analysis




/72



DECISION SUPPORT

BIM SERVER

Ontology ServicesUser incl. Navigator& Scenario ManagerDesign Module Management Services Simulation/ Analysis

Key Point Analysis

Select charts [KPA]










KEY POINT check KPI & DVs (prepared results) [KPA]


Ok or not ok





[BIM--it]

Ack








Next Set up decision making domain (BCF)




/72


7 Usage Scenario #3: Detailed Design

This scenario focuses on the detailed design phase where the building and HVAC design concept are

detailed with regard to specific product qualities and the operational concept is detailed to an O&M

plan. The level of detail (LoD) and level of approximation (LoA) are 300 which means high design and

analysis accuracy. At the end of the scenario at Level of Development (LOD) 300 informed solutions

about all product components and the geometry are worked out and decisions about the optimal

position of all equipment are taken.

7.1 Tasks 0 / 1 “Project Set Up” and “Consistency Checking”



Modules


4 LOD, LoD, ER specification [ScM]




Save requirements [OMS]









DECISION SUPPORT


BIM SERVER

Ontology Services

Management Services

2 Workflow check/setup [ScM]

Provide message to architecture domain (BCF)

5 Check, set up and manage templates [ScM]


/72


7.2 Task 2 “Create Architectural Product Alternatives”

DECISION SUPPORTBIM SERVER

Ontology Services




ALLPLAN





not ok








OK or not ok [OVS]



not ok













Hand over KDP and model to HVAC domain [ScM]





Create architecture product alternatives


Return URL(s) [MAS]






Return URL(s) [MAS]



Make variance construction design




Send message to HVAC domain

ALLPLAN


/72


7.3 Task 3 “Create HVAC Type Alternatives”

DECISION SUPPORT

BIM SERVER

Ontology Services


Modules



DDS-CAD + templates





not ok





Modify Templates [MMNav]



OK or not ok [OVS]



not ok












Hand over KDP and model to BACS domain [ScM]





Create HVAC type alternatives


Return URL(s) [MAS]




Link Model ID [OMS/BIM--it]

Return URL(s) [MAS]



Make variance HVAC design




DDS-CAD + templates

Send message to BACS domain




/72


7.4 Task 4 “Design Sensor and Actuator Network”


Ontology Services




eeBACSWiz





not ok








OK or not ok [OVS]



not ok
















Design sensor and actuator network


Return URL(s) [MAS]






Return URL(s) [MAS]







Hand over KDP and model to FM domain [ScM]

Status update [BIM--it]Send message to FM domain

eeBACSWiz


/72


7.5 Task 5 “Enrich Product Alternatives with Operational Information”

Management Services


Ontology Services


ModulesUser incl. Navigator& Scenario Manager







OK or not ok [OVS]



not ok




Upload enriched IFC model data (BIM-API)




OR to SIM/ANA [ScM]





Enrich product alternatives with operational information

Return URL(s) [MAS]





GRA Designer




Note:Design variants are not generated here, because the focus Is on component level. (GRA)


/72


7.6 Task6a “Thermal Energy Simulation”

BIM SERVER





TRNSYS





Preprocessing [SMM]



Processing [TRNSYS]


Ack

[BIM--it]



Ack





KPI check results



[SRM]













Ack





Ack

Key Point Analysis




Ack


Risk Analysis [RAS]





Send message to LCA domain






/72


7.7 Task 6b “CFD Simulation (3D Wind)”

BIM SERVER









Preprocessing [SMM]





Ack

[BIM--it]



Ack





KPI check results



[SRM]













Ack





Ack

Key Point Analysis




Ack


Risk Analysis [RAS]





Send message to ESIM



3DThermNot ok or not complete -

parameter refinement necessary based on

sensitivity indices/KRI


/72


7.8 Task 7a “Life Cycle Assessment (w/o consideration of stochastic variables)”


Modules


BIM SERVER




iTWO/LCARequest Preprocessing [MMNav]



Preprocessing [SMM]


Processing [iTWO]


Ack


[BIM--it]

Ack





Ok or not ok



[SRM]return results (KPI) [SRM]











Ack





Ack

Key Point Analysis




Hand over KDP and model to LCC domain [ScM]






necessary


/72


7.9 Task 7b “Life Cycle Assessment (incl. consideration of stochastic variables)”

BIM SERVER






iTWO/LCA






Preprocessing [SMM]





Ack

[BIM--it]


Ack


Ack





KPI check results



[SRM]













Ack





Ack

Key Point Analysis




Ack


Risk Analysis [RAS]








LCA, incl stochasticRisk Analysis (?)




/72




Modules


BIM SERVER





iTWO/LCC






Preprocessing [SMM]



Processing [iTWO]


Ack


[BIM--it]

Ack


Ack





Ok or not ok


Send message to decision maker domain


[SRM]

[BIM--it]













Ack





Ack

Key Point Analysis







necessary


/72



BIM SERVER






iTWO/LCC






Preprocessing [SMM]





Ack

[BIM--it]


Ack


Ack





KPI check results




[SRM]













Ack





Ack

Key Point Analysis




Ack


Risk Analysis [RAS]








LCC, incl. Risk Analysis




/72




Ontology ServicesUser incl. Navigator& Scenario ManagerDesign Module Management Services


Key Point Analysis

Select charts [KPA]












Ok or not ok





[BIM--it]

Ack








Send final alternative




/72


8 Further Detailing

8.1 Principal Approach

Through the eeEmbedded platform architecture shown in Chapter 2, the elaborated software compo-

nents detailed in Chapter 3 and the usage scenarios presented in Chapters 4-7, allocating clearly the

function of each tool and service in the overall process, a sound basis for the realisation of the

envisaged SOA approach was established. However, this is still not sufficiently covering the needs

regarding the sought service interoperability because the actual technical information exchanges in the

substeps of each process task and the related APIs are not shown in these representations. Therefore,

further detailing of the developed SOA was necessary. This is done by:

Examining each sequence diagram and identifying information exchange blocks that can be

treated as consistent self-contained steps from end user point of view

Defining for each such step how it is triggered and what are its inputs and outputs with regard

to the overall process and the Scenario Manager and Multi-Model Navigator in particular

Elaborating the detailed substeps required to ensure seamless interoperability and information

exchange between the involved services and tools

Identifying the specific API functionality that has to be covered by the middleware layers of the

architecture, i.e. the Communication Layer and the Shared Service Layer of the platform

(see Figure 2).

With this approach (1) the usage scenarios are further elaborated to implementable specifications

for the software developers, and (2) the platform APIs are defined in detail based on the general top-

down concepts of the architecture and the specific bottom-up requirements derived from the

examination of the usage scenarios. However, as the related specifications are highly verbose and

still in the process of refinement (in parallel to the work regarding the new services and tools

developed in eeEmbedded) in the next section only one comprehensively described example is

shown to illustrate and prove the concept. This selected example is part of the decision making

process in Use Case #1. It was selected to show the detailing of the technical eeEmbeeded workflows

as simple as possible. The success of the overall approach will be best visible when the full realisation

of the services and tools of the eeE Virtual Lab prototype are available.

8.2 Usage Example: Part of Use Case #1, Task 1.7 “Decision Making”

This example assumes that the involved user applications handle BCF directly, without using emails

or a dedicated BCF application like a webpage script or similar. However, such application usage

would not alter the main workflow extracted from the respective UML sequence diagram (Section

5.8) and depicted in Figure 6 below. The implied technical steps are discussed in the following

Figure 7 to Figure 12.


/72


Trigger: BCF message – Ready for Decision Making

– Information carrier as MMC in BIM snippet

Input – Simulation Results: IFC

– Other KPI’s in Ontology Server

– Additional information in file(s) like Spreadsheets and Documents in Repository Server

– URLs in BIM snippet (MMC)

Output – Decision values: KDP’s and

additional information in files

– URLs in BIM snippet (MMC)

Figure 6: UC #1, T1.7 - Focused subtasks

The involved components/tools in these subtasks are:

Client components:

MMNav – Multi Model Navigator

KPA – Key Point Analysis tool

ScM - Scenario Manager

Service providers:

BIM--it - BCF server

BIM+ - IFC server

EDM model Server

Ontology server

KPA service

Service APIs:

BCF-API – Collaboration API used to transport messages and task requests on the collab. bus

BIM-API – The API regarding the standard BIM / IFC data

BIM+-API – The API regarding the specific functionality of the BIM+ environment

OMS-API – The API regarding the functionality offered by the ontology management services

KPA-API – The API to the key point analysis tool

To avoid getting entangled in details upon which end user tool is doing what, the clients are

subsumed in a single box in the following figures. The main workflow is not affected by exactly which

client(s) is active in each step.

Drill-In


/72


The initial trigger is to handle the BCF message indicating that a decision is ready to be made. The

BCF message will in its BIM snippet contain a Multi-Model container (MMC) providing links to all

relevant data.

Figure 7: UC #1, T1.7 - Interpret BCF

To be able to perform the required Key Point Analyses (KPA), the involved client tools must first

retrieve the input data. Information on where the data is available is found in the MMC, but the

client may on its own accord identify more data out of user interaction.

Figure 8: UC #1, T1.7 - Identified data for KPA

The Multi-Model Navigator acting as BCF-Client

looks if there is a new BCF-Topic and if so he will

download (GET) the new topic.

In parallel an email can be sent whenever a new

topic is raised.

BCF Server

BCF-API(JSON)

BCF Message

BCF* ”Decision ready” *

BIM Snippet (MMC)

KPIs <URL>

SIM results <URL>

Files <URL>

BCF Message

MMNav

KPA

ScM

The MMC (multi-model container)

comprises the necessary links to data,

the user picks relevant parts like KPI’s etc.

File Server

Sim Charts

Other Files

Ontology Server

KPI, KDR, ..

MMC

MMNav

KPA

ScM

IFC model server

IFC objects..


/72


Data is retrieved using the server APIs.

Figure 9: UC #1, T1.7 - Retrieving Identified data for KPA

When all data is made available, the decision maker envokes the KPA service. Depending on the

displayed results, the user may have to adjust the input data set (identify-retrieve) and run analyses

again until satisfied.

Figure 10: UC #1, T1.7 - Running analysis service

In general, results can be of quite different type and formats depending on to what degree we want

to record the reason for our decisions. Hence, Figure 11 below shows all options for storing results,

even if only one or a few will be used in a specific practice case.

Get data using API’s

File Server

Ontology Server

KPI, KDR, ..

IFC model server

IFC objects..

BIM+ API(JSON)

BIM-API(JSON)

OMS-API(JSON/SPARQL)

MMC

MMNav

KPA

ScM

KPA Input

Sim Charts

Other Files

«Result» is symbolized as «KPA Output»

inside the client box (MM Navigator)

Steps 2-4 can be repeated until the user

is satisfied

MMC

MMNav

KPA

ScM

KPI API(JSON)

Key Point Analysis Service (KPA)

KPA Output


/72


Figure 11: UC1 T1.7 - Storing key point analysis results

After analysis is complete and decision taken, the MMC is used to record and store references to the

decision value(s). The updated MMC is conveyed to BCF server in a BCF message:

Figure 12: UC #1, T1.7 - Updating the BCF server

The outlined example illustrates how and to what extent the presented SOA and the related

scenarios are further elaborated to provide the blueprints for the implementation and the

subsequent validation and verification of the developed platform. In the next chapter, the supporting

APIs, which are essential part of the approach are outlined.

File Server

Files,Charts

Ontology Server

KPI, KDR, ..

IFC model server

IFC objects..

BIM+ API(XML)

BIM-API(XML)

OMS-API(XML/SPARQL)

MMC

MMNav

KPA

ScM

Stored results update the MMC

Not all types of results are necessary,

but all are possible

File/Object URI received in response

KPA Output

The BCF MMC should contain the new or updated URLs

(to be precise URL + ID in the link model) to the updated

or new values respectively.

The MMC is extended, but nothing is removed.

BCF Server

BCF Message

BCF-API

BCF ”Decision made”

BIM Snippet (MMC)

KPIs <URL>

SIM results <URL>

Files <URL>

KDRs <URL>

KDVs <URL>

BCF Message

MMNav

KPA

ScM


/72


9 Platform APIs

Interoperability of all services and tools on the SOA based eeEmbedded platform is grounded on:

1) The use of standardised data

2) The use of harmonised software interfaces (APIs)

Five APIs are defined for the interaction of the eeEmbedded components, each having specific goals and purpose. These APIs are:

Collaboration API, based on and extending the buildingSMART BCF specification and enabling the allocation and delegation of tasks to users and software tools, as well as the exchange of messages and related data on the platform’s service bus in uniform manner

Repository API with its essential BIM-API subpart enabling uniform access to the multi-model resources on the platform’s storage clouds

BIM+ API enabling the use of extended bim+ functionality in conjunction with the platform’s Multi-Model Navigator (MMNav)

Simulation API enabling the harmonised, ordered generation of computational simulation/analysis models from available eeeBIM data and the guided, parallel execution of simulation services on the platform’s compute cloud

Ontology Management Services API enabling uniform use of the knowledge-based ontology services by all other platform components.

All these APIs are developed in harmonised manner, featuring a formal XML-based specification and a JSON/REST based functional implementation. They are individually presented in the following sections.

9.1 Collaboration API

As already mentioned, the purpose of the Collaboration API is to enable uniform allocation of tasks and exchange of related messages and data on the platform’s service bus (see Figure 1 and Figure 2).

Before 2010, users who wanted to exchange issues, proposals and change requests in BIM data models always had to exchange the whole BIM model as bulk data. The receiver had to compare different releases of the BIM model in order to fulfill the requests from the sender.

As a much more efficient way to support this effort, the idea of developing an open standard to enable BIM-based workflow communication between different software tools has been proposed to buildingSMART. In 2010, Tekla and Solibri came up with an initial XML schema, called BCF XML, to encode messages containing BIM topics (such as issues, proposals, change requests) addressed in BIM models. The implication was to boost the degree of collaboration in BIM workflows by only exchanging the lean topics and not the entire bulk BIM data between software applications. Subsequently, BCF XML was implemented by several software packages and valuable experiences could be gained by using it in BIM-based projects.

In 2013, building upon the gathered experience a task force, led by Solibri, was established in buildingSMART's ISG (Implementer Support Group) to enhance the BCF specification in certain focal points like flexibility related to project specific aspects, the possibility to exchange computer interpretable BCF topics with attached BIM Snippets (small components of a BIM model), attached multiple viewpoints, etc. In October 2014 after intense public review, buildingSMART released a new version of BCF XML.


/72


In the same year, as a second major objective of the BCF task force, a web service based on a BCF API was introduced by eeE partner IAB (the Institute of applied Building Informatics in Munich, Germany). The idea behind this is to exchange BCF topics not only manually or by e-mail attachments, but automated via a standardized RESTful API. This API was released in February 2015.

The BCF API, extended with additional energy-related concepts in the foreseen “extension” section of the API schema is now used as the Collaboration REST API in the eeEmbedded platform. Detailed information regarding the formal API specification is available at the project’s web site and at https://github.com/BuildingSMART/BCF-API.

A BCF topic is the main unit of work in a collaborative process. It represents a single issue within a project context. Topics are mainly composed of descriptive elements such as error descriptions or user comments, BIM data such as viewpoints and geometry information as well as file attachments like BIM snippets or document reference.

BCF Snippets, introduced to transport model parts/components related to a specific BIM topic, are used in eeEmbedded in highly structured manner. They contain computer interpretable Link Models providing references to (parts of) one or more models related to the BCF topic and described formally in a so called Multi-Model Container (MMC). Such containers may encapsulate the actual model data but would typically only hold references to the data which are then accessed using the Repository API described in the next section. This facilitates greatly the efficiency of user and service communication.

Issue tracking is made possible via references, allowing users to track topics throughout the project from the first occurrence to their finalization.

EXAMPLE: Downloading a single BCF topic via the BCF REST API

REQUEST: https://bim--it.net/bcf/1.0/topics/095d901a-6e5b-4f73-9693-ae805a4a9b7c

RESPONSE:

{

"guid": "095d901a-6e5b-4f73-9693-ae805a4a9b7c",

"title": "Handover Architectural Model",

"creation_date": "2015-05-13T16:52:47",

"creation_author": "[email protected]",

"topic_type": "eeE - Handover",

"topic_status": "Key Point complete",

"reference_link": "https://bim--it.net/i/iab/Files/Arch_Variant_01.ifc",

"priority": "Medium",

"labels": [

"Architectural",

"Simulation",

"BIM-Manager",

"Decision Making",

"LCC",

"LCA",

"FM",

"BACS",

"HVAC",

"eSIM"

],

"bim_snippet": {

"snippet_type": "JSON_Provision_Model",

"is_external": true,

"reference": "https://bim--it.net/i/iab/Files/Arch_Variant_01.ifc",

"reference_schema": “https://bim--it.net/i/iab/Files/Request.json”

}

}

https://github.com/BuildingSMART/BCF-API


/72


9.2 Repository API

The purpose of the Repository API us to enable harmonized and efficient access to all common

information resources (BIM, ESIM and other model and document data) in the storage clouds of the

eeEmbedded platform.

A repository is a place in which an aggregation of data is kept and maintained in an organized way. A

repository may be directly accessible to users or may be a place from which specific databases, files,

or documents are obtained for further relocation or distribution in a network. It may be just the

aggregation of data itself into some accessible place of storage or it may also imply some ability to

selectively extract data.

The goal of the eeE Repository API specification is to provide a transparent interface that supports

the unified access to version controlled repository resources in the cloud, but is independent from

the underlying technologies and data storage. Relying on a RESTful architecture it allows to query

resources individually using their unique URI or together as a collection of resources based on their

common type, also referenced by a URI. A closely related concept of a persistent storage

management, as is the case with the eeEmbedded repository, is formed by the functions create,

read, update and delete (CRUD). Therefore, the only required information for a client to interact with

a repository/server is the location of the resource and the intended action. This allows ubiquitous

access to the eeEmbedded repository assets .

CRUD functions are available for the following main resources:

Project - contains domains and models.

Domain - generalized concept of discipline or usage area like "Architect" "HVAC", "LCC Data"

and similar.

Model - part of project that can be represented as a single file. A model is assigned to a

domain. Each model can exist in several versions, usually representing evolvement over time -

that is, versions are not representing variants of the same model.

Specifically for the access to Model data a subpart of the Repository API called BIM-API has been

developed to provide common vendor and server independent access to BIM data. It includes the

following basic functions that can be used regardless of the accessed repository or BIM server:

Create Model

Delete Model

Download Model

List Models

Update Model

Upload Model

Detailed descriptions of the Repository API can be found at https://github.com/BIMit/ModelAPI,

which represents also the reference documentation to be used for the implementation of the API.

It is important to mention that the eeE Repository API does not specify queries on object level or in

other words, it does not provide defined model filters because repository vendors use their own

proprietary storage models. For that, a CRUD operation is always handling the whole resource (e.g.

file) and never a partial resource. The latter is accomplished by generalized model management

services (MMS) which are developed in WP4 and described in deliverable D4.4.




/72


EXAMPLE: Querying a server for available models.

REQUEST: https://bim--it.net/repos/1.0/projects/f80c6016-311b-4eb1-b414-5a309ca28903/models

RESPONSE:

[{

"model_url ": "http://bim--it.net/repos/1.0/models/CFCA23AA59BEEE444222CC",

"model_meta_data ":

{

"model_guid": "CFCA23AA59BEEE444222CC",

"project_id": "ABCD",

"project_name": "muenchen-parkhaus",

"domain_id": "fdfd",

"domain_name": "HVAC",

"model_type": "IFC4",

"model_name": "HVAC_alt_1",


"model_version": "V1",

"description": "Alternative 1 for the HVAC solution of Use Case 2",

}

},

{

"model_url ": "http://bim--it.net/repos/1.0/models/CFCA23AA59BEEE444FFFFF",

"model_meta_data ":

{

"model_guid": "CFCA23AA59BEEE444FFFFF",










}

},

{

"model_url ": "http://bim--it.net/repos/1.0/models/ADFE23AA11BCFF444122BB",

"model_meta_data ":

{










}

}]


/72


9.3 BIM+ API

The BIM+ API provides RESTful services for accessing, creating, modifying and deleting different

levels of information in a building model on the bim+ platform. It can connect the building project

information to a large number of developers providing innovative Apps/applications that can operate

on the building models and related information.Similar to the BIM-API there are four types of

database operations defined for manipulating the building content, i.e Create, Read, Update, Delete

(CRUD). They can be performed against the resources (URIs to asccess building information) which

are essentially the building blocks of REST.

The following HTTP methods implement these operations on persistent level:

Operation SQL HTTP

Create a resource on the server INSERT POST

Retrieve the resource from the server SELECT GET

Update the resource on the server UPDATE PUT

Delete the resource from the server DELETE DELETE

All necessary information for resource manipulation is sent within a HTTP request. Such requests

include:

Resource identificator (URL)

Data type/format (HTTP header)

Authentication information (HTTP header)

Operation, which will be performed against the resource (HTTP method)

The JSON objects which will be used as the bim+ data exchange format are based on the IFC standard

in terms of structure and naming - see http://www.buildingsmart-tech.org/specifications/ifc-

releases/summary. The resource paths contain the team name and the project name to support multi-

tenancy. The project slug (which should be provided during the creation of a project) has to be

provided as part of the URL for accessing all the project relevant resources. This is also necessary to

verify the user’s access rights on the project in an early stage of processing the API call (before any

business data will be touched and any business logic will be executed).

Figure 13 shows the relation between the bim+ portal and the API.

Figure 13: Relation between the bim+ portal and the BIM+ API.


/72


Further details about the BIM+ API are provided in the reference documentation which can be found

at https://doc.bimplus.net/pages/viewpage.action?pageId=4459171.

9.4 Simulation API

The purpose of the Simulation API is threefold:

1) It enables assignment of different tempaltes and/or design variables to the BIM data to

provide for easy to generate simulations/analyses of different design alternatives

2) It defines the method for combining such tempaltes and variables to different simulation input

sets

3) It established the mode of execution of parallel simulations on the compute cloud of the

eeEmbedded platform thereby providing possibilities to perform analyses on stochastic input

values as well as certain sensitivity analyses.

As all other APIs, the Simulation API is also formally defined in XML and can be used via JSON by any

RESTful services of the platform. It is structured in four main sections (Figure):

Figure 14: Top-level structure of the Simulation API

The Variables section provides various possibilities to address and variate different

parameters relevant for energy and LCA/LCC analyses, such as building orientation,

room occupancy, material construction and cost of the building elements as well as the

material properties themselves etc. Currently it contains 6 subsections as shown on

Figure below.

The AssignmentGroups section is used to define the groups of BIM data to which the

same template / design variable is to be assigned and linked.

The Targets section provides the link between BIM objects and the simulation goals,

i.e. it defines on what objects will a simulation be performed. This can be the whole

project, one or more buildings, a building storey, a space zone, a separate room/space,

the building envelope or one specific envelope side (façade).

At last, the Combinations sections determines the method by which all assgnments are

to be treated to create input data sets for the parallel execution of multiple simulation

runs.

<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:complexType name="T_SimulationMatrix"><xs:sequence>

<xs:element ref="Variables"/><xs:element ref="Targets" minOccurs="0"/><xs:element ref="AssignmentGroups" minOccurs="0"/><xs:element ref="Combinations" minOccurs="0"/>

</xs:sequence><xs:attribute name="type" type=“xs:string" use="optional"/><xs:attribute name="id" type="xs:string" use="required"/>

</xs:complexType>

https://doc.bimplus.net/pages/viewpage.action?pageId=4459171


/72


Figure 15: Structure of the variables section of the Simulation API

EXAMPLE: Thermal simulation for a building storey with two combinations of two occupancy

(schedule) alternatives

XML SPECIFICATION:

At the time of this report the Simulation API is still under development to reflect the requirements of

the various simulation and analysis services that are being developed in the project (3DTherm,

3DWind, TRNSYS, iTWO/LCA, iTWO/LCC as defined in sect. 3.5 above). It is available at the project

SharePoint site at https://sharepoint.tu-dresden.de/sites/cib/eeEmbedded. Its final reference

specification will be publicly available under the eeEmbedded web site http://www.eeEmbedded.eu

and forwarded to buildingSMART for consideration.

o Project variables define variations common for the whole project

o Usage type variables define variations in occupancy / schedules

o Construction type variables define variations in element layout

o Window type and door type variables – as above for windows and doors

o Material type variables – material variations

https://sharepoint.tu-dresden.de/sites/cib/eeEmbedded

http://www.eeembedded.eu/


/72


9.5 Ontology Management Services API

The Ontology Management Services API (short: OMS-API) provides the access to the platform’s

ontology which defines on high level the overall modelling framework and IT infrastructure and

enables knowledge-based model and KDR / KDP / KPI validation.

This API is also formally defined in XML and can be used via JSON by all RESTful services of the eeE

platform. However, unlike the other APIs it is not based on XML Schema but on the OWL

specification and uses embedded SPARQL queries to access the elements of the ontology and

execute specific knowledge-based requests such as e.g. the validation of thermal requirements of

specific room types against a certain building regulation like the German EnEV 2014.

The OMS-API is developed in parallel to other ontology-related tasks within WP5 and will be

presented in more detail in the related WP5 deliverables. Its final reference specification will be

available under the project’s web site http://www.eeEmbedded.eu.

Figure 16: Example of ontology-based validation of thermal requirements according to EnEV 2014 using the OMS-API

TU Dresden, 22.11.2015

Wall(x) Outer wallsGTuV0.35(x) thermal transmittance greater than 0.35 W(m²*K)Critical(x) Critical thermal element

http://www.eeembedded.eu/


/72


10 Conclusions

This deliverable presented an approach for the creation of a flexible service-oriented architecture for

the eeEmbedded virtual energy lab and office. The developed Service Oriented Architecture (SOA)

supports multiple data storage technologies such as local servers and cloud solutions and enables

unified integration of various applications. As baseline, the conceptual architecture presented in

deliverable D1.5 was used and extended, updated and restructured.

The platform modules and their components were strictly categorized in functional groups and

presented in compact tabular form. For each component the type (local application, web application,

service etc.), the actors involved in its use and a description are provided. The generic scenario

workflows from D1.5 were reworked, detailed and adapted to current findings. Particular extensions

were made with regard to technical collaboration and information exchange challenges. The specific

detailed workflows from D2.3 were refined for all usage scenarios to ensure that the software

architecture meets all the requirements defined by the scenario workflows.

A hybrid strategy was defined, where the Scenario Manager (ScM) covers the communication for all

high-level tasks specified in BPMN, whereas the BIM Collaboration Format (BCF) will be used both on

the high level by the Scenario Manager and on the subtask level, to deal directly with various data

exchange issues. An example illustrating the further detailing is provided as proof of concept for a

selected subpart of Usage Scenario #1. Hence, it can be concluded that the proposed approach offers

a technical solution that guarantees efficient adaptation and smooth data exchange between user

applications handled by the eeE BCF Service Bus.

The eeE SOA is flexible, modern and could be easily extended. Based on this deliverable result,

a structured design methodology is developed for covering the gaps in the detailed use cases. Using

the presented service-oriented architecture the collaboration methods for the efficient realisation of

the envisaged collaborative holistic design lab and office will be developed in Task T8.2. The

deliverable at hand is also the basis for the prototype of the context-aware Scenario Manager that

will be presented in D8.3 to automate the design and BIM processes and the simulation services.

Finally the planned services, tools and data models will be evaluated in a test bed, which will be

reported in deliverable D8.4.


/72


11 References

Baumgärtel, K., Katranuschkov, P., Hollmann, A., Laine, T., Protopsaltis, B., Dolenc, M., Klinc, R.,

Guðnason, G., Balaras, C. (2013): ISES Deliverable D2.2: Architecture and Components of the

Virtual Lab Platform, © ISES Consortium, Brussels.

Bell, M. (2008): Service-Oriented Modeling (SOA): Service Analysis, Design, and Architecture, Wiley &

Sons, ISBN: 978-0-470-14111-3, 384 p.

Calleja Rodriguez, G., Guruz, R., (2014): eeEmbedded Deliverable D1.3: Interoperability and Collabo-

ration Requirements, © eeEmbedded Consortium, Brussels.

Geißler, M.C., Guruz, R., van Woudenberg, W. (2014): eeEmbedded Deliverable D1.2: Use Case

Scenarios and Requirements Specification, © eeEmbedded Consortium, Brussels.

Guruz, R., Calleja Rodriguez, G., Geißler, M.-C. (2015): eeEmbedded Deliverable D2.3: Holistic KPI

Based Design Methodology, © eeEmbedded Consortium, Brussels.

IFC4 (1996-2013): Industry Foundation Classes Release 4, http://www.buildingsmart-

tech.org/ifc/IFC4/final/html/, © buildingSMART International Ltd 1996-2013

ISO 16739 (2013): Industry Foundation Classes (IFC) for data sharing in the construction and facility

management industries, Interantional Organisation for Standardization, Geneva, Switzerland.

Linhard, K., Dangle, G. (2015): BCF REST API, Web service specification for BIM Collaboration Format,

https://github.com/BuildingSMART/BCF-API, © BuildingSmart

Linhard, K., Dangle, G., Tøn, A. et. al. (2015): Energy Efficient Buildings Repository Services,


OASIS (2012): Reference Architecture Foundation for Service Oriented Architecture Version 1.0,

Committee Specification 01, 04 December 2012, http://docs.oasis-open.org/soa-rm/soa-

ra/v1.0/cs01/soa-ra-v1.0-cs01.pdf, 118 p., © OASIS Open 2012.

OMG (1997-2015): Unified Modelling Language (UML) v 2.5, http://www.omg.org/spec/UML

/2.5/PDF, © Object Management Group 1997-2015.

Richardson L., Ruby S. (2008): RESTful Web Services, O’Reilly Media Inc., ISBN 0596554605, 454 p.

Richardson L., Amundsen M., Ruby S. (2013): RESTful Web APIs, O’Reilly, ISBN 1449358063, 406 p.

Solvik, K., Kaiser, J. (2014): eeEmbedded Deliverable D1.4: Requirements for Knowledge-Based

Design Support and Templates, © eeEmbedded Consortium, Brussels.

W3C (2004): XML Schema – Pt. 0: Primer, Pt. 1: Structures, Pt. 2: Datatypes,

[http://www.w3.org/TR/]xmlschema-0/, 2004/REC-xmlschema-1-20041028/structures.html,

2004/REC-xmlschema-1-20041028/datatypes.html

W3C (2012): OWL 2 Web Ontology Language (Second Edition), W3C Recommendation 11 Dec. 2012,

http://www.w3.org/TR/owl2-overview/

W3C (2013): SPARQL 1.1 Overview, W3C Rec. 21 Mar. 2013, http://www.w3.org/TR/sparql11-

overview/

Zellner R., Guruz R., Mosch M., Katranuschkov P., Tøn A. & Kaiser J. (2015); eeEmbedded Deliverable

D1.5: System Architecture of the Virtual Holistic Design Lab and Office, © eeEmbedded

Consortium, Brussels.

http://www.buildingsmart-tech.org/ifc/IFC4/final/html/

http://www.buildingsmart-tech.org/ifc/IFC4/final/html/




http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/cs01/soa-ra-v1.0-cs01.pdf

http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/cs01/soa-ra-v1.0-cs01.pdf

http://www.omg.org/spec/UML/2.5/PDF

http://www.omg.org/spec/UML/2.5/PDF

http://www.w3.org/TR/%5dxmlschema-0/

http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/datatypes.html

http://www.w3.org/TR/owl2-overview/