OPTEEMAL data requirements experiences

@OptEEmAL_EUwww.opteemal.eucontact@opteemal.euThis project has received funding from the European Union’s Horizon 2020
research and innovation programme under Grant Agreement No 680676
Workshop on Interoperable data models for
Building's Life Cycle Energy Management Processes
OptEEmAL-SWIMing Vocamp
13–14 October 2016, University College London, England
OPTEEMAL Data requirement experiences
Gonçal Costa, gcosta@salleurl.edu, FUNITEC (ARC Engineering and Architecture La Salle)
Álvaro Sicilia, ascilia@salleurl.edu, FUNITEC (ARC Engineering and Architecture La Salle)
Leandro Madrazo, madrazo@salleurl.edu, FUNITEC (ARC Engineering and Architecture La Salle)
Dimitrios Rovas, rovas@dpem.tuc.gr, UCL (University College London) / TUC

OptEEmAL GA no. 680676 | District Data Model
OPTIMUS – SWIMing Vocamp | London, 13–14 October 2016
Work programme
HORIZON 2020-WORK PROGRAMME 2014-2015
5. Leadership in enabling and industrial technologies
Call identifier
H2020-EeB-2014-2015 / H2020-EeB-2015
Topic
EeB-05-2015 Innovative design tools for refurbishment at building and district level
Title of the Proposal
Optimised Energy Efficient Design Platform for Refurbishment at District Level
GA no. 680676, Contact: contact@opteemal.eu
List of participants
13 Partners – 4 RTO, 2 Universities, 2 IND, 3 SME and 2 Cities
Project Overview

IFC models
CityGML
Socio-economic
data
Weather
data
Energy prices Monitoring
data
Users’
objectives
CSV, SQL…
- BIMs data
- GIS data
- Contextual Data
Project Overview
A web-based platform
for district energy-
efficient retrofitting
design
District
Retrofitting
design
1
2
3
OptEEmAL
Platform

- BIMs data
- GIS data
- Contextual Data
Addressing the district scale in modelling and
simulation
1
2
3
Multiple data models,
domains, formats…
ENERGY
DPI’s
COMFORT
DPI’s
ENVIRONMENTAL
DPI’s
ECONOMIC
DPI’s
SOCIAL
DPI’s
URBAN
DPI’s
GLOBAL
DPI’s
District
Retrofitting
design
…
IFC models
CityGML
CSV, SQL…
District Data ModelInput Data
?
Multiple tools,
input formats…
Energy
Plus
CitySim
NEST

- BIMs data
- GIS data
- Contextual Data
simulation
1
2
3
ENERGY
DPI’s
COMFORT
DPI’s
ENVIRONMENTAL
DPI’s
ECONOMIC
DPI’s
SOCIAL
DPI’s
URBAN
DPI’s
GLOBAL
DPI’s
District
Retrofitting
design
…
IFC models
CityGML
CSV, SQL…
CSV, SQL, ….
Socio-economic data
Weather data
Energy prices
Monitoring data
IFC model
CityGML
Users’
objectives
domains, formats…
Multiple tools,
input formats…
Energy
Plus
CitySim
NEST

ENERGY
DPI’s
COMFORT
DPI’s
ENVIRONMENTAL
DPI’s
ECONOMIC
DPI’s
SOCIAL
DPI’s
URBAN
DPI’s
GLOBAL
DPI’s
District
Retrofitting
design
…
Energy Data
Model
Economic
Data Model
n Data Model
Simulation Data models
2. Data
Interoperability
domains, formats…
Multiple tools,
input formats…
Semantic Web Technologies
Energy
Plus
CitySim
NEST
simulation
- BIMs data
- GIS data
- Contextual Data
1
2
3
IFC models
CityGML
CSV, SQL…
1. Data
Integration

District
Retrofitting
design
simulation
CityGML
File
CityGML
OWL
IFC OWL
IFC
File
Contextual Data
CityGML
RDF
IFC
RDF
Energy
Data
Model
SIMULATION
DATA MODELS
SEMANTIC DATA
MODELS
DATA
MODELS
SimModel
OWL
District
extension
Energy
Plus
CitySim
NEST
SIMULATION
MODELS
…
IDF
XML
Proprietary
Format1. Data
Integration
2. Data
Interoperability

District
Retrofitting
design
CityGML
File
CityGML
OWL
IFC OWL
IFC
File
Contextual Data
CityGML
RDF
IFC
RDF
Energy
Data
Model
SEMANTIC DATA
MODELS
DATA
MODELS
1. Data
Integration
SimModel
OWL
District
extension
A) Finding relations (alignments)
between CityGML OWL, ifcOWL and
SimModelOWL
Ontology matching: LogMap, AML…
B) Transforming RDF data according
to the ontologies and their
alignments. RDF-To-RDF via SPARQL
constructs: Alignment API, R2R, …
SIMULATION
DATA MODELS
simulation

District
Retrofitting
design
Energy
Data
Model
SIMULATION
DATA MODELS
SimModel
OWL
District
extension
Energy
Plus
CitySim
NEST
SIMULATION
MODELS
…
IDF
XML
Proprietary
Format
Ad hoc connectors between
Energy Data Models and
particular simulation models.
All particular data needed by
Simulation models have been
integrated in the Simulation
Data Models. 2. Data
Interoperability
simulation

Ontologies
ifcOWL (Pauwels & Terkaj) - http://www.buildingsmart-tech.org/future/linked-data/ifcowl
- Is an ontology for IFC supported by BuildingSMART.
- Exploit the benefits of semantic web technologies in terms of data distribution,
extensibility of the data model, querying, and reasoning,
CityGML Owl (Knowledge Engineering @ ISS UoG) - http://cui.unige.ch/isi/icle-
wiki/ontologies
- A direct translation of the CityGML XMLSchema to OWL, manually tuned
SimModel OWL (Pauwels, Corry & O’Donnell, 2014) -
http://www.lbl.gov/namespaces/Sim/
- It is a data model with a domain that covers the domain of energy simulation of the
entire building.
- This is implemented as a data model (.XSD) that is interoperable through XML.
- Is “geometrically compatible” with IFC among other formats.
simulation

Data requirements
Data requirements for the OptEEmAL processes
• We have used ReqCap tool and Word/Excel documents to collect data
requirements
• Each WP (OptEEmAL processes) have collected their own
requirements (e.g., data integration, scenario generation, simulation,
model visualisation, data exportation…)
• Detailed simulations require particular data requirements: Second
level space boundary topology.
• We have started from the end of the process  DPIS and we are
coming back defining the requirements.

Data requirements
BIM level

Data requirements
District
level

Data requirements
Excel ReqCap tool

Data requirements
Excel ReqCap tool
Some OptEEmAL processes have templates
(data integration, scenario generation,
simulation…).
• There are overlaps between templates
• Each one with its own data structure

Data requirements
Excel ReqCap tool
Global requirements
• They are the unification of the
different templates
• They have an unique structure for all
the stages of the project
X
Some OptEEmAL processes have templates
(data integration, scenario generation,
simulation…).
• There are overlaps between templates
• Each one with its own data structure

Data requirements
Global
requirements
OptEEmAL processes
(Stages)
Current Data Models
Each of them (global requirements, data models, processes) have its own data structure. ReqCap tool
helps to identify which requirement are needed for each stage and the mappings between the
requirements and the data models. However, it is needed more details for the implementation of the
processes:
- Identification of all data items needed: Geometry, properties of materials…
- Relations between the data models: IfcBuilding  SimBuilding…

Data requirements: Mapping data models
IFC RDF data
inst:IfcBuildingStorey_941 rdf:type ifc:IfcBuildingStorey .
inst:IfcBuildingStorey_941 ifc:elevation_IfcBuildingStorey inst:IfcLengthMeasure_919 .
inst:IfcLengthMeasure_919 rdf:type ifc:IfcLengthMeasure ;
inst:IfcLengthMeasure_919 express:hasDouble "2.69999999999993".
SIMMODEL IFC RDF data
inst:IfcBuildingStorey_941 rdf:type sim:SimBuildingStory_BuildingStory_Default.
inst:ifcBuildingStorey_941 sim:BuildingStoryHeight "2699.99999999993" .
Structural and conceptual
mismatches between models:
- Different Units
- Different structures
ifc:IfcBuildingStorey ifc:IfcLengthMeasure literal
sim:SimBuildingStory_BuildingStory_Default literal

IFC RDF data
SIMMODEL IFC RDF data
ifc:IfcBuildingStorey ifc:IfcLengthMeasure literal
sim:SimBuildingStory_BuildingStory_Default literal
Translation into R2R mapping format:
mp:BuildingStoryHeight rdf:type r2r:PropertyMapping ;
r2r:classMappingRef mp:Storey ;
r2r:prefixDefinitions "ifc: <http://www.buildingsmart-tech.org/ifcOWL/IFC2X3_TC1#> …. " ;
r2r:sourcePattern "?SUBJ ifc:elevation_IfcBuildingStorey [ express:hasDouble ?num]." ;
r2r:targetPattern "?SUBJ simbldg:BuildingStoryHeight ?num_mil" ;
r2r:transformation "?num_mil = ?num * 1000" .

A methodology is needed to address the problem of overcome the structural
differences between data models. It is important to maintain the data transformation
process in the future.
Steps:
1. Find direct mappings between the concepts of the two ontologies (ifcBuilding 
simBuilding) Using semi-automatic processes (Ontology alignment tools)
2. Find the structural differences between the two ontologies and extract the
patterns. A manual process.
3. Find the particular aspects that need to be dealt in each pattern.

Data requirements
Domain: Specific requirements:
District Site  Information about the site, including location, placement of buildings in
OptEEmAL’s definition of district
District Performance  Information about the performance of the district,
District Performance Indicators
Product Building  Geometric properties, location, building envelope
Building Elements  Walls, Windows, Slabs
Materials  Layering, Material Properties
Actor User  Information about IPD users involved in the project
Energy SecondLevelSpaceBoundary  Second-level space boundaries inside the building,
building outside shading surfaces, inter-building second-level boundaries, shading
groups
District-level interactions  Generation and distribution of energy
along the district
Original source: D1.2 “Business Use Cases for the use of BIM-LOD in BLCEM – Phase II”, SWIMING project

Data requirements
Cross Domain: Specific requirements:
Identification Properties for uniquely identifying objects (i.e name and category)
Location Basic description of the placement of spatially-located
things/building services/devices, etc.
Space Data regarding volumes of spaces, numbering (in case of rooms and
whether a space is interior or exterior, whether the space contains
other spaces, or is contained by a space).
Representation A method for visually representing an object, e.g. a geometric
representation.
Project Information relevant to the entire project, e.g. units of measurement
OwnerHistory Provenance data
Original source: D1.2 “Business Use Cases for the use of BIM-LOD in BLCEM – Phase II”, SWIMING project

Conclusions
• Data requirement capture is an iterative process.
- When the data integration process is carried out then you may need to modify
initial requirements.
• The requirements of the simulations tools are not easy to model in ReqCap tool (BIM*Q
tool):
- Not all data requirements (particularly the detailed ones) can be represented.
- The geometry of the elements of the building cannot be fully represented.
• Mappings between data models (IFC, SIMMODEL…) are needed
- How a data model is transformed/translated into another one is a challenge.

Conclusions
Semantic Web Journal. Impact Factor 1.7 Q1
Special issue: AEC/FM + Semantic Web
Deadline: March 2017

THANK YOU FOR YOUR ATTENTION!
@OptEEmAL_EUwww.opteemal.eucontact@opteemal.euThis project has received funding from the European Union’s Horizon 2020
research and innovation programme under Grant Agreement No 680676
Gonçal Costa, gcosta@salleurl.edu, FUNITEC (ARC Engineering and Architecture La Salle)
Álvaro Sicilia, ascilia@salleurl.edu, FUNITEC (ARC Engineering and Architecture La Salle)
Leandro Madrazo, madrazo@salleurl.edu, FUNITEC (ARC Engineering and Architecture La Salle)
Dimitrios Rovas, rovas@dpem.tuc.gr, UCL (University College London) / TUC

OPTEEMAL data requirements experiences

More Related Content

Similar to OPTEEMAL data requirements experiences (20)

More from Álvaro Sicilia (6)

Recently uploaded (20)

OPTEEMAL data requirements experiences