d4.2 multi-model specification and domain model filtering pu · 2018-01-11 · multi-model...

Design4Energy - Building life-cycle evolutionary Design methodology able to create Energy-efficient Buildings flexibly connected with the neighborhood energy system

Co-funded by the European Commission within the 7th Framework Programme. Grant Agreement no: 609380. 2013-10-01…2017-09-30 (48 months).

Report 4.2 Multi-model specification and domain model filtering

Revision ......................................... 1.0 Preparation date ............................ 2017-02-08 Due date ........................................ 2016-12-31 Lead contractor ............................. TU Dresden

Authors: Frank Noack .................................. TU Dresden Stephan Pirnbaum ......................... TU Dresden Mathias Kadolsky ......................... TU Dresden Peter Katranuschkov .................... TU Dresden Vanda Dimitriou ............................. Loughborough University Steven Firth ................................... Loughborough University Tarek Hassan ................................ Loughborough University Farid Fouchal ................................ Loughborough University FHR team ...................................... Fraunhofer IAO

Design4Energy ! D4.2 Page 3 of 77

2017-02-08

Disclaimer The information in this document is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability. The document reflects only the author’s views and the Community is not liable for any use that may be made of the information contained therein.


2017-02-08

Table of contents

1. Executive Summary ............................................................................................... 5

2. Introduction ............................................................................................................. 62.1 Purpose and Target Group ....................................................................................... 62.2 Contributions of Partners .......................................................................................... 62.3 Baseline .................................................................................................................... 72.4 Relations to Other Activities ...................................................................................... 9

3. Multi-Model Concept ............................................................................................ 103.1 Overview of the Multi-Model Approach ................................................................... 103.2 Exchange Requirements and Model View Definitions ............................................ 113.3 Link Model ............................................................................................................... 14

4. Model Categorisation ........................................................................................... 174.1 Architectural Model ................................................................................................. 174.2 Physical Data Models .............................................................................................. 174.3 Analytical Model ...................................................................................................... 184.4 EnergyPlus Data Model .......................................................................................... 20

5. Bim2Sim Workflows ............................................................................................. 215.1 Focusing on Early Design ....................................................................................... 215.2 Focusing on the retrofitting phase ........................................................................... 215.3 Focusing on the Use of the Open BIM Standard IFC .............................................. 235.4 Parameter variation ................................................................................................. 25

6. Domain model filtering ......................................................................................... 276.1 Overview ................................................................................................................. 276.2 Model View Definitions for Building Energy Analysis & Simulation ............................. 286.3 BIM filter specification ............................................................................................. 296.4 The Query Language ifcQL ..................................................................................... 316.5 FilterIFC .................................................................................................................. 336.6 Filtering and Validation Using FilterIFC and mvdXML ............................................ 376.7 XmlToFilterConverter .............................................................................................. 38

7. Conclusions .......................................................................................................... 39

8. Acronyms and terms ............................................................................................ 40

9. References ............................................................................................................ 41

10. Appendices ......................................................................................................... 4410.1 FIlterIFC Filter File Specification ........................................................................... 4410.2 Link Model XML Schema Specifications ............................................................... 69


2017-02-08

1. EXECUTIVE SUMMARY With the recent advance of Building Information Modelling in AEC practice a sound basis for collaboration using the same model data by all actors in the process is becoming possible. However, the enhancement of the model data with additional specific energy-related information and the subsequent mapping to the input of an energy analysis or simulation tool is yet an open issue. Whole building simulation requires the exact preparation of the needed input data. Similarly, definitions of construction materials defined in a CAD tool have to be extended with data that define their respective thermal properties. The Dynamic Energy Efficient oriented Building Information Platform (DEEBIP) developed in the Design4Energy project represents an open platform that will allow different stakeholders to integrate their energy related service modules to further enhance energy efficiency of future buildings. This report describes the combination of multiple related models from different domains which are in this context referred to as elementary models. The underlying idea is to combine those different models in a single information resource to achieve a closely linked cooperation between the different domains of the construction industry. The elementary models are interconnected via a link model using unique identifiers. The result is a consistent Multi-Model that represents a certain status of a project. The description of this approach includes the categorisation and the classification of the models to be included as well as a brief recapitulation of the Multi-Model approach for their exchange. Another objective of this report is the specification of an appropriate technology for Multi-Model filtering. A special filter tool involving energy-enhanced functionalities is specified based on the filter toolbox formerly initially developed in the German R&D project Mefisto. New ee-functionalities are developed as well as new ee-query modules and modules needed for the energy enhanced BIM. In the report the filtering of (Multi-) models is covered in detail. A comprehensive description of the filter file specification based on the functionality of the BIMfit toolbox presented in report D4.1 is provided in appendix.

The heterogeneity of the domains involved in the building industry, as well as the sheer size and complexity of most model data, lead to a high semantic and structural variety of potential involved models. Building geometry in a CAD file characterizes the architect’s view of the building, not its thermal view, so that it has to be transformed appropriately to represent the thermal view. In practice, different IT workflow approaches may be suitable regarding the BIM model in different design situations. While distinctly different, all developed approaches are grounded on a common overall Multi-Model concept. In this report the approaches investigated in the Design4Energy project are presented considering their envisaged use in practice. Significant effort is required to prepare the datasets needed to run analyses. This is solved with the appropriate filtering and transformation functions provided by the energy-enhanced BIM. The technical and semantical integration is explained. Data types, relationships between data, links between types, constraints on relationships, validation checks etc. are specified for the development of the complete workflow from the architectural design data model to the simulation.


2017-02-08

2. INTRODUCTION

2.1 Purpose and Target Group The development of a sophisticated energy enhanced Building Information Modeling (eeBIM) framework is significant advanced in WP4. The eeBIM framework represents a central point in open BIM platform services. The enhancement of BIM model data with additional specific energy-related information and the subsequent mapping to the input of an energy analysis or simulation tool is a crucial point in Design4 Energy.

The objective of Report D4.2 ”Multi-model specification and domain model filtering” is to specify the Multi-Model for the relevant domain models in the Design4Energy context as a baseline for the interoperability methods. The Multi-Model approach is outlined, followed by a definition of the according Link Model. The report shows how a conceptual information framework, which enables managing the information exchange between different aspects by an appropriate link model, model filtering and model transformations, can achieve consistent modelling. The target groups are mainly the D4E partners (involved in WPs 2–7) as well as any further ee-application developers. The underlying BIM model will allow different stakeholders (architects, civil engineers, utilities, technology providers, workers) to capture design information as well as operation and maintenance data in an integrated form and use it as the basis for considering energy issues at building life cycle level. The use of the BIM and the virtual workspace will support a stronger collaboration and design management between different building design domains. End-users and especially non energy experts (like architects) require the seamless integration of energy simulation tools and a decision making support in accordance to KPIs or user defined energy performance criteria concerning the operation lifecycle of buildings.

Therefore a system, which organizes the data flow in a unified model, enabling effective exchange of data is required. The final goal is to simplify and automate the information exchange processes among different tools, and develop enabling technologies and platforms to facilitate and establish an integrated system around a BIM in the centre with multiple tools and users. The eeBIM based on the Multi-Model approach provides an interoperable data model that facilitates: • Data exchange between existing simulation tools. • Bi-directional exchange of data within eeBIM thus enabling seamless workflow. • Use of templates as another key feature that empowers users and allows them to leverage

pre-configured data sets and configurations, thus expediting simulation model development.

• Easy generation of design alternatives for optimization purposes.

2.2 Contributions of Partners The general concept of the Multi-model and the filter specification was developed by TUD. The description of the Energy System Database is developed by FHR. This component database provides building components for three dimensional sketch-ups of building models as well as construction and material data for the integration in analytical models. The contained files are stored type neutral, which means that all kinds of files can be stored.


2017-02-08

The approach to perform retrofit analysis of existing buildings described in section 5.2 is provided by LU. An alternative workflow addressing early design scenarios is adapted from a conference presentation of UNIVA development in section 5.1.

The content of the report was discussed and elaborated in regular web conferences between the project partners.

2.3 Baseline Building Information Modelling (BIM) acts as a bridge between the industry and information technology [1], which makes the entire building lifecycle more efficient and effective. Energy modelling gives the designers an outlook of expected energy consumption regarding various designs prior to construction. To achieve energy-efficient building lifecycle performance it is important to consider the overall processes together with the information requirements and the ways these requirements can be efficiently dealt with whereby suitable decisions in the very early stage of the design process usually have the strongest influence on the energy consumption. Energy modelling gives the designers an outlook of expected energy consumption regarding various designs prior to construction.

With the recent advance of BIM in AEC practice a sound basis for collaboration using the same model data by all actors in the process is becoming possible. However, the enhancement of the model data with additional specific energy-related information and the subsequent mapping to the input of an energy analysis or simulation tool is yet an open issue.

Despite the existence of an increasing number of BIM models that are linked to energy performance simulation models and the existence of models that are linked to BIM authoring tools within proprietary environments, there are still limitations to the current BIM tools for energy analysis in terms of interoperability and quality of the results [2].

Whole building simulation requires the exact preparation of the needed input data. The original data about the building is not generated by the software tools for building energy performance like e.g. EnergyPlus [3] which is used in Design4Energy. This data represents a different view of the building using a different data structure. Typical energy simulation data models are stand-alone, usually in the form of plain text files with poor or non-existent interfaces for data exchange. In fact, there is no official standard for the simulation domain. Existing simulation tools (EnergyPlus, DOE-2, IES, etc.) fail to take advantage of standard data exchange tools that are available for data in the XML (Extensible Markup Language) or IFC (Industry Foundation Classes) format apart from third party front ends for gbXML and IFC input.

Design4Energy aims to develop an integrated information management framework for designing energy-efficient buildings. The Dynamic Energy Efficient oriented Building Information Platform developed in the Design4Energy project represents an open platform that will allow different stakeholders to integrate their energy related service modules to further enhance energy efficiency of future buildings. The complex data exchange between architectural design and building energy simulation constitutes the main challenge in the use of energy performance analyses in the early design stage. Physical data models are providing generic data schemas which cover different structural elements. This covers elements of architectural and structural data models as well as those of Heating, Ventilation and Air Conditioning (HVAC). Most of them are already considered in the standard BIM schema IFC [4] but external (non-BIM) data has to be included too. Such data encompass climate files, occupancy profiles, detailed material characteristics, detailed equipment performance specifications and so on. Consequently, in Design4Energy the model


2017-02-08

enrichment and model transformation to EnergyPlus is achieved via an additional energy-extended BIM data structure which is based on a Multi-Model approach and a set of model manipulation tools (model validator, model combiner, model filtering, eeBIM2SIM converter). A so-called Link Model connects elements of different elementary models via unique identifiers (IDs) but is held completely outside the elementary models offering possibilities for model querying, object selection and user defined constraint checking. To prevent information loss between building energy simulation tools a consistent modelling across aspects of the building simulation process and the building lifecycle is required. That contains the BIM itself, the energy system database, the linkage to external input data, the simulation model, the neighbourhood model and lastly the results and the visualisation models. Sharing of information between incorporated BIM-tools and applications should be secure and reliable. This can be reached by using the Information Delivery Manual, developed within buildingSMART International as the standard for processes and published as [5].

An IDM-based illustration of the general workflow, concretized and adapted for energy enhanced design tasks, is shown in Figure 1.

Figure 1: IDM-based development process – specifying eeBIM


2017-02-08

The overall use of the IDM methodology includes: • identify the actors and their roles, • identify the life-cycle phases, and the level of details imposed, where information flows

e. g. for energy or environmental related simulations are required, • identify the main software application types used by the actors during the various life-

cycle phases, • identify the exchange protocols used with these software application types, • identify the detailed information requirements for the exchanges (exchange requirements), • map these exchange requirements to the exchange protocols and document the gaps, and • identify the external databases and libraries to be used, e.g. for climate data and others.

2.4 Relations to Other Activities The Multi-Model approach as well as the domain model filtering is a fundamental part of the energy-enhanced BIM developed in WP4 and as such an essential part of the Dynamic Energy Efficient Building Information Platform (DEEBIP). The BIM processes in the different expert domains and their cross-domain interdependencies are worked out in D4.1. The different domain models which constitute the elements of the Multi-Model where also specified in D4.1. The requirements are derived from the developed D4E usage scenarios in D2-2b. Figure 2 shows the main connections of WP4 to the other work packages in Design4Energy.

Figure 2 WP4 in relation to other work packages in Design4Energy


2017-02-08

3. MULTI-MODEL CONCEPT

3.1 Overview of the Multi-Model Approach For the exchange of the domain models categorized and classified in the report D4.1 the Multi-Model approach presented by R. Scherer and S.-E. Schapke in [6] and further adapted for ee-Design in [7] was chosen. The term Multi-Model describes the combination of multiple related models from different domains, which are in this context referred to as elementary models. That way the Multi-Model consists of elementary models, which can be any kind of either engineering or management models involved in energy-enhanced BIM (Figure 3). The underlying idea is to combine different models in a single information resource to achieve a closely linked cooperation between the different domains of the construction industry. The result is a consistent Multi-Model that represents a certain status of a project.

Figure 3 Energy-enhanced BIM

The generic multi-model approach aims at exchanging linked domain models relevant to a particular task of the entire information process [8]. Producing these links is complex and expensive work. The results of this work represent high domain knowledge and should be accessible for further information processes. The metadata of the Multi-Model as well as that of elementary and link models facilitate substantive conclusions and offer information about the resources without the necessity to open all involved files. This enables high-level use of the data to manage numerous Multi-Models in a construction project. Within a collaboration management platform, it is possible to specialise a Multi-Model based on the current task, domain, as well as on the users role. The elementary models might be part of one or several existing Multi-Models. In the first case the Multi-Model can be reused. In the second case the Multi-models which come into question have to be decomposed, reorganized and merged for the given task. Assuming that not all requested elementary models can be found in existing Multi-Models the new Multi-Model will again contain only metadata describing the missing elementary model, which then has to be added in another way. This enables them to recombine the Multi-Models based on their demands as well as based on the requirements of the project itself.


2017-02-08

The energy enhanced BIM specification (eeBIM) is created by the construction of a link model of confederated data schemas with the IFC data schema as the main underlying schema (Figure 4).

Figure 4 IFC as central underlying scheme in the Multi-Model approach

3.2 Exchange Requirements and Model View Definitions

3.2.1 Model View Types The heterogeneity of the domains involved in the building industry as well as the sheer size and complexity of most model data lead to a high semantic and structural variety of potential model views [6]. An individual model view can correspondingly either be a valid full partial model or consist of a set of selected, reduced or transformed objects. It can even be composed of individually derived aggregated or calculated object data like features and relationships that describe the information demand in the context of a specific requirements situation. The model view types can be structured as follows:

Full model view

As the name suggests, the full model view represents the complete and unaltered model.

Static/domain model view

A static model view is an independent valid partial model whose content is defined before the filter process and is assigned to a specific partial model specification (e.g. HVAC view)

Dynamic/ad-hoc model view

A dynamic model view covers a task specific subset of a model (e.g. query for the volume of all components of a specific type to be found in a specific area).

Multi-Model view

A Multi-Model view is a static or dynamic model view created taking additional non-BIM data models of external (domain) information into account (e.g. determination of all rooms in a specific area that show an increased average temperature).


2017-02-08

3.2.2 Model View Definitions A Model View Definition (MVD) [9] is a subschema out of the whole IFC-based eeBIM Data Model Domain that is needed to satisfy one or many exchange requirements in the model design process. It provides a kind of guideline for software solution provider to implement their software interfaces.

Model View Definitions are either defined within buildingSMART International, or by other organizations and interest groups. MVDs are structured such, that different parties can focus on the information relevant to them. The main division is between technical and non-technical. The non-technical definitions called Exchange Requirements and Exchange Requirements Models (ERMs) are aimed at software users, the technical definitions called MVD Bindings (to a specific information model schema) are aimed at software developers.

Software applications use these MVDs to check if required information is provided in the building information model. For creating MVDs there exists a tool called ifcDoc [10] from buildingSMART which allows domain users to specify MVDs, to generate subsequent mvdXML documents and to validate a given IFC file based on that. Model View Definitions for building analysis and simulation are presented in section 6.1. For definition of IFC Model Views the goal must be to define an exchange of IFC data that will meet the end user’s needs. This Cross Organisational Business Process is developed and defined in the Information Delivery Manual (IDM). The development of the IDM can start after a relevant use case has been identified and the possibility for adoption of the digital support workflow among the relevant parties has been investigated (Figure 5)

Figure 5 Preparation and adjustment of BIM for energy analysis with IDM ([11]).

3.2.3 Exchange Requirements The Exchange Requirements (ERs) developed in D6.1 represent a set of information shared between parties and applications or required for a process identified in the IDM. They provide a description of the information in non-technical terms.

The principal audience for an exchange requirement is the end-user (architect, engineer, constructor, etc.). It is used to specify appropriate MVDs as it provides the key to the technical detail that enables the solution to be provided. ERs provide a complete schema that can be supported by a software application for the exchange of information for a particular purpose, at a particular point in time on a project, and at a particular location. Based on the target exchange format, the mapping of the data requirements to its representation in the exchange format specification, such as the IFC schema specification, is developed. The


2017-02-08

outcomes of this step are the Exchange Requirement Models (ERM) that are based on the Exchange Requirement (ER) tables with additional rows showing the mapping to the data exchange formats (Figure 6, Figure 7 [12] ).

Figure 6 Create Exchange Requirements, Sort and specify the exchanges (Content Target)

Figure 7 Extend to ER Model, Map to exchange format (Standardization Target)


2017-02-08

3.3 Link Model Information comes from different domains and has to be combined thereby creating an overall information basis and providing the input for the envisaged external simulation tools and their related simulation models. Besides the linking of elementary models as part of the Multi-Model, so-called Link Models connect elements of different elementary models via unique identifiers (IDs). A Link Model is defined as a serializable, transferable instance of a data model with an associated schema. The underlying general concept for the Link Model has been initially developed in the German R&D project Mefisto [13] and is further extended to a DIN specification (DIN SPEC 91350) and a proposal for international standardization via buildingSMART (current status: https://github.com/BuildingSMART/MMC). It is used as baseline for inter-linking the BIM domain models with other models, like climate and user behaviour. This approach allows to store and exchange references between elements of different elementary models (links) in a uniform way. The combined information stored in Link Models is task specific. Within the Link Model, appropriated link objects among the different elementary models have to be defined. Therefore different kinds of links are identified and elaborated. Figure 8 depicts the UML class diagram of the resulting schema. The initial class MultiModel is composed of Elementary Models (class ElementaryModel) and Link Models (class LinkModel). Elementary Models can either be embedded as a byte array (EmbeddedElementaryModel) or referenced via the URI (UriElementaryModel) to reduce the amount of data that has to be submitted.

Figure 8 Schema of the generic Multi Model, UML class diagram (based on [6])

Links are the explicit externalization of references between elementary models. As most of the existing construction information models have identifiers for their elements, in Design4Energy ID-based linking was chosen. Hence, that the links can be held outside of the domain models.


2017-02-08

Besides the linking of external data with the eeBIM framework, the possibilities of direct integration into the IFC model via appropriate IFC objects are also used (Figure 9).

Figure 9 Direct link integration in the IFC model within the Multi-Model Approach a) Linking of external data to IFC object properties via URL-Links, b) Linking of external data to IFC objects via Ifc PropertySets

A formal semantics definition provides the necessary taxonomy for identification, organisation and navigation of the data framework content according to well defined building semantics. The IFC 2x3 schema defines concepts that can automatically associate external data to specific objects within the BIM/IFC instance model. The following table summarizes the IFC2x3 concepts, showing how they map to external data sources.

Table 1 IFC object matching to external data

Ifc Object Description Parameters Data Source

IfcSite IfcSpatialStructureElements

The geometrical placement of the site, i.e. to the world coordinate system

Longitude Latitude Elevation

Weather data

IfcBuilding Pset_BuildingUse Pset_BuildingUseAdjacent IfcSpatialStructureElements

Representation of the spatial structure of the building

Building Use Type Building location on site and orientation

Templates by building use type repre-senting an aggregation of building floors, zone or space templates Weather data

ifcBuildingStorey

Represents the partial spatial structure of a building

Ground floor, intermediate floors, top floor

Template by building/floor type repre-senting aggre-gation of zone or space temp-lates


2017-02-08

Ifc Object Description Parameters Data Source

ifcZone Pset_SpaceOccupancyRequirements Pset_SpaceThermalRequirements Pset_SpaceLightingRequirements

A zone is an aggregation of spaces, partial spaces or other zones.

Zone activity type Templates by zone Occupancy, equipment and lighting profiles

ifcSpace Pset_SpaceOccupancyRequirements Pset_SpaceThermalRequirements Pset_SpaceLightingRequirements

A space represents an area or volume bounded actually or theoretically. Spaces are areas or volumes that provide for certain functions within a building.

Space activity type Templates by Space funct-ional use or user activity Occupancy, equipment and lighting profiles

ifcBuildingElement ifcMaterial IfcMaterialProperties sub-types ifcDistributionElement

When used for physical constructs incorporated into the building

Element, Product and material type / material layer type Property identification

Product and material pro-perties

IfcSpatialStructureElement IfcOccupant IfcRelAssignsToActor

The principal purpose is to determine the nature of occupancy of a property for a particular actor

Type of occupant in a building, story, zone or space

Occupant Profile

IfcSpaceProgram Architectural program for spaces in the building de-tailing client requirements for the space before the building is designed

Space program templates (optional)

The Link Model schema adopted in the German DIN standard (DIN SPEC 91350), currently under discussion for buildingSMART standardization, is presented in Appendix 2 of this report. Specific extensions for ee-Design developed in the Design4Energy proejct, especially with regard to the sub-methods presented in Figure 9 (a,b) are not part of the Link Model schema but will be considered for inclusion as part of the specific standardization proposal related to the modelling of the energy domain.


2017-02-08

4. MODEL CATEGORISATION The entire BIM contains several domain models. Some of them are already partially considered, for example the BIM-IFC data model. However, the consideration of energy-enhanced building design and in particular the energetic environment (neighbourhood building energetic infrastructure, climate data) introduce many data models that are up to now not captured by the IFC and should also not be deeply incorporated in the IFC model. Instead they should be handled as federative interoperable data models. As foundation for such a data model structure it is useful to firstly categorize the data models according to the information functionality. These categories are presented in the following.

4.1 Architectural Model Architectural models are virtual 3D volume models enhanced by alphanumeric data. They are created by architects, designers or planers via Computer Aided Design (CAD) software. All graphical elements of these models are representations of construction elements and spaces or zones. They are classified by construction types, like walls, doors, windows, ceilings and others, to enable controlled data handling, object recognition and object filtering. In order to obtain a complete architectural BIM Model, building geometry and object alphanumerical information are required. The architectural BIM Model represents the result of the architectural domain work. To better integrate it in the design workflow, all popular CAD manufacturers implemented standard interfaces like IFC, to exchange their BIM data with other applications. Nonetheless, it is important to mention at this point that the Level of Detail (LoD) and the architectural model completeness vary from CAD system to CAD system, but depend mainly on the user inputs and detailing work.

End-user requirements related to the Architectural Model cover basically (1) the geometrical model completeness including (2) the existence of appropriate alphanumerical object data, and (3) the BIM model data quality. In addition, data readiness and standard interfaces are demanded to enable smooth and loss-free data exchange between all domains defined in the whole use case scenarios. In the early design process, most of the construction details are unknown. Construction material selection and architectural details are usually elaborated iteratively, supported stepwise through the energy and cost analysis.

4.2 Physical Data Models Physical data models map construction elements, physical objects like equipment, sensors, energy system and construction machines, which can be further divided in building internal and building external objects. This covers elements of architectural and structural data models like BIM as well as those of Heating, Ventilation and Air Conditioning (HVAC). In general the physical data model covers physical objects (e.g. building services equipment) as well as their grouping to systems and sub-systems, e.g. sensor and actuator networks or air conditioning systems. Besides grouping concepts, composing and decomposing capabilities of physical objects are supported by the physical data model. A physical chiller object, the energy generating component of an air conditioning system, can for example be decomposed into the physical objects evaporator, compressor, condenser and throttle.


2017-02-08

Each physical object or system fulfils a specific task or functionality in the overall building or in its neighbourhood. Hence, the physical data model provides concepts to describe functionalities of physical objects. For instance, temperature measurement functionality can be assigned to a physical temperature sensor object or water storage functionality can be assigned to water storage tanks.

Beyond structural data describing principle system characteristics, the physical data model is providing capabilities to represent the interrelations between real physical objects and systems like they are and like they should be. To this end each physical object needs a physical interface description. Using port connection concepts the physical connections of physical objects can be described in detail. To connect for instance energy generating equipment (e.g. chiller and heat pump) and energy consuming equipment (e.g. radiator and fan-coil) the physical interface has to be compatible. Physical data models cover the following aspects: • System description and grouping of physical objects • Aggregation, composition and decomposition of physical components • Physical interface description using port connection concepts • Function description of physical components • Interrelation between physical objects across domains • Manufacturer information of physical objects

4.3 Analytical Model An effective interface between the architectural model in BIM and an analysis application requires the consideration of the following aspects [1]:

1. Assignment of specific attributes and relations in the BIM authoring tool consistent with those required for the analysis.

2. Methods for compiling an analytical data model that contains appropriate abstractions of building geometry for it to function as a valid and accurate representation of the building for the specified analysis software. The analytical model that is abstracted from the physical BIM model will be different for each type of analysis.

3. A mutually supported exchange format for data transfers. Such transfers must maintain associations between the abstracted analysis model and the physical BIM model and include ID information to support incremental updating on both sides of the exchange.

Significant effort is required to prepare the datasets needed to run analyses. But with appropriate BIM interfaces, a model representing the actual geometry can be used to derive both the analytical model and the drawing set. Energy simulation models essentially employ the same data as already contained in the eeBIM, but structured completely differently.

Thermal energy simulation of buildings and systems in the state-of-the-art level is taking into account a broad range of border conditions like outdoor weather/climate, topology, user behaviour, internal loads and constructions in the neighbourhood. Most of these main boundary conditions bring in a unique domain-specific data structure.

The geometry is made up of Spaces, Surfaces, and Zones, defined as follows:

• Spaces are discrete volumes (masses really) of air that experience heat loss or gain due to internal processes like occupancy, lighting, equipment and HVAC as well as exchange heat with other Spaces and the exterior environment.


2017-02-08

• Zones are groups of Spaces used to establish some commonality between those spaces - such as having the same orientation, the same function, or being served by the same HVAC system.

• Surfaces are the paths of heat transfer to or from each Space, including between interior spaces and the exterior environment.

Spaces do not always need to be divided by rooms in the building, but this often does make sense analytically. It often makes sense to further subdivide large rooms into multiple spaces when modelling large rooms like open-plan offices and atria. The shape of spaces does not matter (and is not accounted for). The orientation, adjacency, and type of surfaces is what dictates heat transfer behaviour. There can be a difference between Zones and “zoning” (creating simplified geometry that combines rooms). To get valid simulation results the Energy Analysis Model has to be “airtight”. Basically, the Energy Analysis Model is an abstraction of a building’s overall form and layout into a ‘computational network’ that can capture all of the key paths and processes of heat transfer throughout the building effectively. Currently, the Industry Foundation Classes, IFC [4] and Green Building XML [14] present the two most widely acknowledged information infrastructures used for Energy analysis Models in the AEC industry. They are both used for common data exchange between AEC applications such as CAD and building simulation tools. The goal of IFC is to provide a universal basis for process improvement and information sharing in the construction and facilities management industries. Compared to IFC, the gbXML schema is simpler and easier to understand but is also more restricted with regard to overall design collaboration. Both formats can be used to represent energy-related building information, such as geometry and material properties of building elements (floors, walls, windows, etc., Figure 10). The main purpose is to facilitate the transfer of the building information between current building design tools and a variety of engineering analysis software applications.

Figure 10 IFC and gbXML as basic formats for analytical models in BIM

To enable a smooth exchange of geometry and building information between IT tools and BIM servers in the entire design process the standardization of CAD data interfaces is striven. One critical point lies already in the use of the CAD software at the beginning of each process. In order to export usable models as gbXML or IFC the energy-relevant aspects have to be considered already in the CAD system itself and equally in its export functionalities (see Report D5.3). In the end, it is necessary to create the input files for the specific executing


2017-02-08

engine using the information included either in a gbXML or in an IFC file. To achieve that, appropriate transformations are indispensable. These transformations have to be automated as much as possible in terms of user-friendliness, time saving and error-free performance.

Components and Energy System Database The conceptual description of the Energy System Database is presented in D4.1. The tools of the Design4Energy platform are accessing the physical database via a web-service-based interface, whereas the user interaction is defined via a searchable, structured user interface, which provides systematic access to the physical database. The component database provides building components for three dimensional sketch-ups of building models as well as construction and material data for the integration in analytical models. The contained files are stored type neutral, which means that all kinds of files can be stored. Engineers are enabled to evaluate the components and make decision based on component attributes Within the Design4Enery workspace. These attributes are defined in Report D3.1. The components database architecture consists of REST-based service layer and a system capable of storing and managing files in context to the component attributes.

A detailed technical description of the database and the categorisation of its content can be found in report D3.2.

4.4 EnergyPlus Data Model EnergyPlus is used as the target energy application in the Design4Energy workflow [3]. It provides functionalities for energy analysis and thermal load simulation. The software takes into consideration the building geometry, user behaviour and energy related systems (Figure 11). For the description of systems, a proprietary data model is used known as IDD/IDF format [15].

Figure 11 Input model for simulation with EnergyPlus

EnergyPlus provides a huge amount of simulation options that require specific input including simulation control parameters (surface convection and heat balance algorithm options, equipment and system sizing options), daylighting analyses, room air and airflow analysis models, economics calculations, and an enormous array of output possibilities.


2017-02-08

5. BIM2SIM WORKFLOWS

5.1 Focusing on Early Design The first investigated approach addresses early design scenarios. It focuses on the supporting tools needed to achieve interoperability given a widely accepted proprietary BIM model (Autodesk Revit) and a dedicated pre-processing tool (DesignBuilder) for EnergyPlus. The general workflow is shown schematically in Figure 12 and described in greater detail in [16].

Figure 12 gbXML BIM2SIM workflow using widely accepted proprietary tools

The gbXML output file, that contains all of the heating and cooling information, is adopted in this approach. Several steps must be executed where the information has to be exchanged accordingly. In the first step, after obtaining the gbXML output file from Revit, a validation process is executed to guarantee that the extracted model includes all the necessary information to go through the energy simulation. If some information is missing, the checker procedure is capable to recover it from Revit. In a second step, DesignBuilder is used which provides interoperability with the BIM models through its gbXML import capability. This allows users to import 3-D architectural models created by all drawing systems that support gbXML data exchange, e.g. Revit. In this scenario, DesignBuilder is used as black box to translate the gbXML file to an IDF file, as this is the type of input that is supported by EnergyPlus.

5.2 Focusing on the retrofitting phase In order to perform retrofit analysis of existing buildings a calibrated whole-building base-case model needs to be developed and used to apply and assess alternative retrofit scenarios [15]. A transparent workflow is needed that provides sufficient control over the significant number of options need to be set by the user to perform energy analysis using EnergyPlus (Figure 13).


2017-02-08

Figure 13 gbXML BIM2SIM workflow with increased transparency and potential for

operational data feedback

In most cases the gbXML export from authoring tools needs to be edited to include additional information or to implement changes to the building’s thermal properties. To achieve that, the gbXML file is imported in the gbXML Editing Tool which is linked to the Design4Energy Component Database. The Editing Tool can be used to implement the required changes to the building characteristics and to embed additional information to the gbXML file when needed. The output of the Editing Tool is the edited gbXML file containing all the information describing the building’s thermal performance. The edited gbXML file is then imported into the developed gbXML to idf Conversion Tool. This Conversion Tool uses as much information as possible from the gbXML file and additional parameter values that are specified by the user to create the IDF file. Figure 14 shows a flowchart focusing on the conversion process.

Figure 14 gbXML to idf conversion process using the developed Editing and Conversion tools


2017-02-08

The Editing Tool is able to apply user defined XML instructions to the gbXML file to add to the gbXML file or modify it as required. The edited gbXML file is the input file to the conversion tool. A template idfXML file contains the mapping instructions of the idf objects to the relevant nodes of the gbXML file. The idfXML file is then converted into the native idf format. Throughout this conversion process multiple files can be handled at the same time. Further explanation of the process, with more detailed description of each step and verification using a case study is available in [17].

Multiple iterations of the calibration process using the gbXML Editing Tool might be required to achieve good agreement between the modelled and the actual building energy performance. The calibrated and verified model can then be used as a base-case to model alternatives for retrofit decision support. Again, the Editing Tool and the Component Database can be used to create gbXML files of retrofit alternatives.

5.3 Focusing on the Use of the Open BIM Standard IFC Figure 15 shows the scenario for the data transfer from 3D CAD applications to building performance simulations using the standard BIM schema IFC (ISO 16739) as basis for the BIM workflow.

Figure 15 Workflow using IFC as basis for the data exchange and simulation preparation

The specification of the eeBIM goes hand in hand with the development of operational methods bringing the original data into the required form as well as methods working on the eeBIM model and preparing it to serve as input for the envisaged applications. Central functions are: • to support the checking of the IFC model to ensure that it contains the necessary thermal

performance data, • to support mechanisms to add thermal performance data for various components if this

data is missing, • to complete the basic BIM model with different design components, not included in the

CAD output, • to support the interface to the simulation execution engine.


2017-02-08

For CAD/BIM and Energy System interoperability also the IFC model needs to be extensively pre-processed and appropriate energy specific model views have to be derived that need to be enriched with incomplete or missing domain specific information (e.g. thermal properties, occupancy and operational schedules) to comply with the building model used by the Building Energy Performance Simulation tools [18]. Since the input data format for EnergyPlus is IDF, the transformation from IFC data to IDF data constitutes the key point of directly using the IFC-based design result in the energy simulations with EnergyPlus. Its essence is to generate information from one model to another model by simplification, translation and interpretation [19], [2]. To establish the mapping between the IFC entities and the IDF entities in the corresponding models, the relationships between the IFC-based information model and the IDF-based information model for energy-efficient design must therefore be analysed. Based on these relationships, appropriate algorithms for the transformation from IFC data structures to appropriate definitions in the IDF files are established (Figure 16).

Figure 16 Transformation algorithm for the IfcSpace entity

The transformation of the geometry information is the most important and simultaneously the main challenge. In IFC data, the geometry information of the building elements and thermal zones can be expressed by various geometric modelling methods, e.g. solid model or surface model, whereas only surface model is used in the IDF data. At the same time the transformation methodology should avoid arbitrary and manual data definition to preserve the integrity of the original data, and assure their transformation by unambiguous rules embedded in the software. Most challenging in that regard is the space boundaries issue. For the thermal energy analysis, IFC provides concepts to define relations between rooms and building elements by using space boundaries represented through instances of the class IfcRelSpaceBoundary which connect instances of IfcElement and IfcSpace classes. Such space boundaries are needed to ensure water-proof space enclosure which is essential for a correct computational thermal model. They can be categorised in five levels as follows [20]: 1. Visible space boundaries are simply defined in BIM by using IfcSpace and IfcElement

classes Figure 17, left). 2. Space boundary pairs exist to define thermal bridges. For example, if a wall separates two

rooms than there are two boundaries of the same size Figure 17, right). This means that


2017-02-08

space boundaries are divided when there are transitions from rooms and elements behind the analysed object. This is important in case of thermal transmittance between rooms. Furthermore, the space boundaries are declared as physical if linked to a tangible building element or as virtual if there is no building element but only a functional separation of two rooms (e.g. office and kitchenette). If there is no room behind a wall, then the space boundary of the wall is declared as external. Otherwise it is an internal boundary.

3. The geometry behind the building element is analysed. If there is a non-collinear building element behind the considered building element than it is defined as third level space boundary Figure 17, right in red).

4. The profile of inner building elements is analysed and described in detail. 5. Space boundaries have no one-dimensional thermal transmittance. This concerns

especially building elements with angles.

For thermal energy analyses, at least second level space boundaries must be provided. Boundaries on higher level help to increase the accuracy of the simulation results but are not mandatory. If a building information model provides only first level space boundaries a transformation to second level can be done but if no space boundaries are available, the model is unusable for thermal simulation. Therefore in the last years many CAD vendors have implemented the space boundary concept in their IFC export. However, nearly all of these implementations are still in a very early development stage and geometry problems are very common.

Figure 17 Space Boundary conversion

5.4 Parameter variation For the parameter variation the jEPlus java library by Yi Zhang is used [21]. JEPlus has been developed to perform complex parametric analysis on multiple design parameters. The library enables to assign a sampling profile (probabilistic distribution function and sample size) to each parameter, then running a random sample of the project.

Various design options can be the thickness of an insulation layer, the size of a window, the construction of the walls, the selection of HVAC system and its operation strategy, or the


2017-02-08

building form. All design options can be defined using the “Parameter Tree”. A design solution is subsequently a combination of the alternative values of the parameters. JEPlus will then pick a set of values and put them in the right places in the building model and call EnergyPlus (Figure 18).

Figure 18 Generation of multiple jobs with varied parameters for EnergyPlus

Each simulation job is a path from the root node of the tree to a leaf of the tree. As a result, the total number of jobs encoded in the tree equals the total number of paths from the root to the leaves Figure 19.

Figure 19 Specification of simulation jobs


2017-02-08

6. DOMAIN MODEL FILTERING

6.1 Overview Appropriate filtering of the BIM data is an essential part of each BIM21SIM workflow. Especially with regard to IFC, the standard BIM collaboration format, development of efficient and reusable filtering approaches including domain model consideration are of upmost importance. Therefore, various possibilities for domain model filtering have been discussed and developed. They can be used in combination, forming a powerful multi-model filtering framework. For Design4Energy the filter framework is realised by using and extending the filter functionality of the JAVA-based filter toolbox BIMfit. It was initially developed for the German BMBF project Mefisto [13] and further extended in the European FP7 projects HESMOS [7] and ISES [22]. It supports the filtering of building model subsets as well as the filtering of certain elements which fulfil domain or task specific information requirements.

The overall structure of the developed filter framework including its definitional and implementation parts is shown on Figure 20, taken from [9].

Figure 20 Overview of the overall structuring of the filtering framework

Based on the concept of modular filter functions the BIMfit was developed as reference implementation for a set of base functions from the meta, core and the extended reasoning level. The toolbox enables fast and simple creation of higher order filter operations that fit certain domain or task specific information requirements. It offers a set of tools for model querying, object selection and user defined constraint checking that is readily extendable by new filter functions on core and reasoning level, or application filter operations in any complexity utilizing the existing base functions.

In D4.1 is present a detailed description of the currently prototyped BIMfit functions. For each function, a short synopsis of its purpose, the required input, the produced output, the

Process Analysisand ExchangeRequirement Specification(InformationDelivery Manual– IDM;ISO29481)

Definitionof SubSchemaSpecifications(ModelViewDefinition– MVD)

Definitionof SchemaLevelFilters(GMSDViewDefinition)

Definitionof Subschemas(IFC:EXPRESS;XML)

Context-specific (ad-hoc)interfacesDomainvalidation of partialmodels

Filtering onSchemaLevel(Filtersdescribe subschemas;Result:formally validpartialmodel(s))

Definition

Implementation

Filtering onClassLevel(Filtersaddress class definitions;Result:Partialmodel or dedicated object/attribute set)B

IMFiT

Filtering onInstanceLevel(Filteraddresses object selection set;Result:filtered object set)


2017-02-08

dependences or relationships to other functions, if any, and in most cases a short code example in Java are provided. The filter framework described in D4.1 was created with the intention to provide the elementary functionality needed for the generation of various BIM-based model views with regard to different domain and application contexts. It constitutes a consistent and formalized basis for the runtime application of model filtering and transformation operations and is built on the concept of modular base filter functions providing adaptable and reusable building blocks for the model view generation tasks. This includes especially filtering on class and object level and the related dynamic generation of ad-hoc and Multi-Model views. The filter framework is therefore complementary to the static filtering on schema level for domain model view generation.

6.2 Model View Definitions for Building Energy Analysis & Simulation

6.2.1 Coordination View The Coordination View was the first Model View Definition developed by buildingSMART International and is currently the most widely implemented view of the IFC scheme. The main purpose of the Coordination View is to allow sharing of building information models among the disciplines of architecture, structural engineering, and building services e.g. mechanical (Figure 21). It contains definitions of spatial structure, building, and building service elements that are needed for coordinating design information among these disciplines.

Figure 21 Structure of Coordination View MVD [23]

Coordination View Concepts: • List of concept templates (list of re-usable concepts) utilized by CV 2.0, • List of concept roots (list of all supported elements, like wall, furniture, fastener, or

distribution element) with applicable concepts, and • List of rules applied to the supported elements (Attribute list with rules assigned to each

attribute path definition)

An important direct extension of the Coordination View 2.0 is the space boundary add-on view [24]. This view defines the required additional IFC support to fulfil the exchange requirements between the architectural and building service modelling software and the


2017-02-08

thermal analysis software. Characteristic is the correct export of the architectural building information model with some pre-processing for energy consumption simulation (different level of space boundaries) besides other requirements for spaces, zones and thermal properties of building elements.

There are several other Model View Definitions (generally extended versions of the Coordination View) specified by organizations or development teams outside of buildingSMART International. These additional MVDs require programs to provide IFC data above and beyond those of the Coordination View standard – such extra data include Classification Reference, Space Occupant, Actor, System and Time Series Schedule Assignments, and specific property sets and properties.

6.2.2 Architectural Design to Building Energy Analysis MVD

Special attention should be given to the Architectural Design to Building Energy Analysis MVD [25]. According to that, the Architectural building information model can be used as basis for energy simulation. Only the relevant subset of the architectural model is exchanged. The high-level structure diagram of the Model View Definition is depicted in Figure 22.

Figure 22 Concept Design to Building Energy Analysis (BEA) ([26])

The central information in this view is:

• space geometry and identifiers, • space boundary geometry for walls, slabs, windows, doors, openings and also virtual space

boundaries, • construction types for walls and slabs, • window and door types, • materials and material layers of the walls and slabs and • building elements that will be used by middleware to generate second level space

boundaries.

6.3 BIM filter specification

The overall goal of model filtering is the reduction of the original model content to the subpart described by the MVD. Whilst model views can be developed and used on different levels and at different times, the filtering methods for the reduction of the model content to the required view can be classified independently as filtering on (1) schema, (2) class, (3) object, and (4) reasoning level as described in Figure 23.


2017-02-08

Figure 23 High level schema of the overall process of development, implementation and use of model views and related filtering types (adapted from [9])

Filtering on schema level refers to the reduction of a building model according to a predefined subschema that specifies the information content of the filtered partial model. Typically, this is done using the pure descriptive approach to define all necessary trans-formations in advance. The suggested Generalized Model Subset Definition Schema (GMSD) [27] provides this kind of functionality.

Filtering on class level serves the reduction of the model content on the basis of constraints regarding properties and relationships defined explicitly in the model schema. The difference to schema level filtering is that it is done at runtime, by applying the prescriptive filtering functions in a specific task context. Thus, unlike schema level filtering, class level filtering can be used together with the other two prescriptive filtering mechanisms below.

Object (or instance) level filtering enables examining the specific properties of individual objects, thereby additionally pruning the resulting model content. It requires more complex querying methods than class level filtering but provides also for higher flexibility and better consideration of the specific task context at hand.

Filtering on the level of reasoning involves algorithmic and knowledge-based functions that are associated with the overall model semantic but cannot be directly deduced from the model structure, as e.g. the derivation of space boundaries on various levels of detail from defined spaces and building elements in IFC, the extraction (and re-grouping) of shear walls from all wall elements, the definition of thermal zones and so on.

Regardless of the specific filtering methods used, the purpose of the overall process remains always the same. It is to support the generation of suitable model views for specific applications, tasks or engineering system contexts. In this regard, the term system is used to express a set of behavioural characteristics of the building via a meaningful configuration of the building parts that are relevant for the analysis of that behaviour, e.g. thermal system, ventilation system, lighting system and so on. The underlying system model is more general than an application model because it has to support, partially or as a whole, more than one application. Hence, a system model is most often created by appropriate transformation of a set of multiple models, where BIM plays the central, integrative role.


2017-02-08

6.4 The Query Language ifcQL

6.4.1 General Approach For the definitions of MVDs and their application on IFC files a relational algebra is used with an own syntax. It is similar to the Structured Query Language (SQL) and is named ifcQL. The primary purpose is (1) validation of building information data, but also (2) ex-traction of a specified building information set and the creation of a new version of the building in IFC. In this sense, a reduced building information model can be created which can be exchanged with one or more software applications. The ifcQL complies with the CRUD principle:

• Create - Creating a new data set,

• Read - Reading an existing data set,

• Update - Modifying an existing data set,

• Delete - Deleting an existing data set.

6.4.2 Structure of the ifcQL

An MVD defined with ifcQL can be specified in one or more files in which one command per line is stated and refers to one data set. It can be determined if one command is applied on the previous one or creates a new data set statement from the full building information. The ifcQL provides many functions to check, reduce, extend or modify a building information model. Basically, in ifcQL the following commands can be used:

• Filter - to reduce a building information model,

• Check - to validate a building information model,

• Add - to add new entities to a building information model,

• Insert - to add new properties to existing entities in a building information model,

• Update - to modify existing entities of a building information model,

• Delete - to delete entities or properties in a building information model and

• Load - to import existing MVDs as part of a new MVD.

The commands are defined in a custom syntax and each begins with the character “~”. The declaration of concrete entity types, attributes as well as constraints are each specified with a “-” on the line. The syntax diagram of the initial command declaration is presented in the following Figure 24.

In a similar manner to SQL, building information data sets can be queried using the commands SELECT, FROM and WHERE. The FROM command refers to the set of IFC entities by declaring types and identifiers. The SELECT command is one of the commands above and the WHERE command refers to object attribute values, for example the “GlobalId” of IfcRoot objects and the target value.


2017-02-08

Figure 24 ifcQL commands

The most important commands are check and filter. They are shown in Figure 25 and Figure 26. In the validation phase, objects and their specific conditions (object semantics) on the one hand and relations between objects (relation semantics) to the other hand can be checked. This allows not only the declaration of attribute values, but also the classification of Objects [28]. For example, with the relation check it is possible to check the assignment of rooms to a specific building storey. The outcome is a .log file which contains all checks and their results written in a report.

The result of the filtering task is a partial building information model whose information content correlates to the assigned sub schema defined in the MVD. Filtering on class level reduces, like the filtering on schema level, building information models on the basis of conditions defined in term of types and their relations. These conditions are applied during the filtering task on concrete models (e.g. filter all building elements of a specific type). The filter command can be followed by the declaration of a type (-type) to search and extract objects of that type, or by a specific GlobalId to search an exact object (-guid) or to exclude it from the partial set of the result. With the command “-recursive” it is additionally possible to include entities to the result set which are directly linked to the queried entity. The ifcQL provides more possibilities to work with building information, because it is based on the Java-based framework BIMfit which supports any STEP data format (any IFC version) and provides several functions to access BIM data [29].

Figure 25 Check command in ifcQL


2017-02-08

Figure 26 Filter command in ifcQL

6.5 FilterIFC

6.5.1 Basic functionality A set of basic filter functions (Appendices D4.1) is the foundation of the framework for the definition and realisation of more complex model filters and transformation operations. These basic functions can be used by software developers to create tailor-made extended filter operations for specific contexts in the targeted engineering tasks. The idea is to break down highly specialised filter functions into several more general sub functions, that take place on different layers of applications and can be reused for the creation of other complex filter functions.

The filtering functionality specified and implemented in the BIMfit library (see D4.1) can be applied using the FilterIFC batch processing tool and the ifcQL query language [30]. FilterIFC filters and manipulates IFC files referring to the basic functions defined in BIMfit. It offers the possibility to extract only the required information as well as creating new building elements including all extra information about it. Additionally, the tool is able to check IFC files and results of other commands of FilterIFC to ensure accordance to the expected content. FilterIFC has to be started from command line. Three obligatory input parameters have to be specified:

1. input file … must be a valid file with .IFC extension. The validity is checked while parsing the file. If it fails, the program will stop running.

2. filter file … contains all rules which shall be applied on the input file. The file must fulfil the required specification.

3. output file … contains all calculated results. Possible output formats are the standard IFC format or the JSON format.


2017-02-08

In addition to these obligatory arguments an optional geometry parameter can be specified and used in accordance with the description in Table 2.

Table 2: The geometry flag

Specifier Effect Output

on Default value. With geometry off, the resulting file only contains the entities satisfying the filters in the filter file without representation

.ifc

off With geometry on, the resulting file contains the entities satisfying the filters in the filter file and also the representation to them

.ifc

tri With geometry tri, the resulting file contains the entities satisfying the filters in the filter file in xyz-coordinates

.json

To increase the efficiency, the FilterIFC tool offers macros. Those code snippets are defined before usage and can store any text or operation even partly. When the macro is used later, the stored text is inserted at its position. It is possible to apply filters on a result of another filter, that way enabling sub-filtering or import complete filter files.

6.5.2 Importing filter files To have a better structure inside of filter files and to have the ability to reuse already existing filter files the tool offers the possibility to import filter files. This is possible with the following command: load file <file -path>

The obligatory parameter <file -path> determines where the filter file to import is located.

Example: Main filter file

Example: /home/username/external_filter

The resulting file will contain the window with the id "0ykyk" and a wall with the id "2KnXe". But not the element quantity with the id "6d809" since the guid filter works on the combined result of all operations.

01: #Filter all ifc root entities

02: ~filter -type "Ifcroot"

03: #Load external filter file

04: ~~load file "/home/username/external_filter"

05: #Filter guid for a wall, a window, an element quantity

06: _~~filter -guid "2KnXe" "0ykyk" "6d809"

01: #Filter all ifc wall entities

02: ~filter -type "Ifcwall"

03: #Filter all ifc window entities

04: ~filter -type "Ifcwindow"


2017-02-08

Filter specifications comply with the following syntax which is explained in Table 3: ~filter - <type | guid >

<< specifier (s) … >

| exclude < specifier (s) … >>

[ - recursive ]

[ - tuid ]

Table 3: Description of the filter syntax

Parameter Description Declaration

-< type | guid > Determines whether the entities shall be filtered by the type (based on the Ifc type) or by the global id

obligatory

< specifier (s) … > Specifiers for filter rule. If using as type filter, use the naming from (Model Support Goup of International Alliance for Interoperability 2007)/(buildingSmart 2015) (e.g. "Ifcwall"), otherwise use the global id. Several specifiers can be combined; the single specifiers are separated by one space.

either this or excluded specifiers obligatory

Exclude < specifier (s) …>

Specifiers for filter rule. When using the exclude key word, all entities determined by the specifiers are removed from the underlying data set in the result.

either this or included specifiers obligatory

[-recursive] Optional parameter. If used, the resulting file will contain not only the entities specified previously, but also all entities contained by these excluding the representation. (The representation will be added by the geometry flag on command line)

voluntary

[ -tuid <specifier>] A temporal user id for the filter. This gives the possibility to use the filter result in other operations where applicable

voluntary

The resulting filter file can contain many different filter queries and constitutes the result of all specified filter for a collected query. The following code snippet is a simple example of the filter usage.

01: #type filter to get all walls of an ifc file:


03: #instance filter to get entity with global id 3x94dj40kd8

04: ~filter -guid "3x94dj40kd8"

05: #getting entities of several types

06: ~filter -type "Ifcwall" "Ifcwindow" "Ifcspace"

07: #type filter including also sub entities

08: ~filter -type "Ifcwall" -recursive

09: #type filter excluding all walls

10: ~filter -type exclude "Ifcwall"

11: #type filter excluding entitiy with id "3k3jdkds"

12: ~filter -guid exclude "3k3jdkds"

13: #setting the tuid

14: ~filter -type "Ifcwall" -tuid "123abc"


2017-02-08

Conditions In Addition to the simple filtering procedure it is possible to further limit the result via conditions. Therefore, where is attached to the filter completed by the condition. For all entities, complying with the simple filter the specified condition is checked. Only those results that pass the check will be included in the resulting data set. The expanded syntax is: ~filter … [where < condition (s) … >]

The following filter conditions can be specified: • Attribute • Material • Path • Property • Quantity • Relation • Comparison.

The following code snippet is an example of filtering for material as part of a complete filter file.

The next code snippet shows the filtering syntax in the case of property filtering. A filter file can contain many different filter queries respectively.

Checking

In addition to the filter functionality the FilterIFC tool offers the possibility to check whether a data set contains entities with specific characteristics. Checks have no influence on the filter result, however if a check fails the program will exit without a result. An error message will then be shown in the terminal. Corresponding to the filter specification, several checks can be performed, as listed in the following: • Entity • Attribute • Material • Property • Path • Quantity • Relation • Aggregation functions.

01: #filter all walls made of concrete

02: ~filter -type "Ifcwall" -where material "concrete"

01: # get all internal Ifcwalls, internal is expressed by value 1

corresponding to jsdai documentation

02: ~filter -type "Ifcwall" -where property "Pset_WallCommon"

"IsExternal" EQUALS "1"

03: # filter all Ifcroot entities having the specified property set assigned

04: filter -type "Ifcroot" -where property "Pset_WallCommon"

05: # filtering with unknown proeprty set

06: filter -type "Ifcroot" -where property "*" "LoadBearing" EQUALS "1"


2017-02-08

6.6 Filtering and Validation Using FilterIFC and mvdXML

This can include pre-processing of the model data for advanced reasoning or analysis tasks like spatial reasoning [31] or structural analysis [32], as well as for model checking and data reduction, simplification, translation and interpretation issues to achieve appropriate data transformations in energy aware design [19]. The batch processing tool FilterIFC (presented in section 6.5) offers a descriptive method for generating model subschemas and a respective model views. Nevertheless an additional generic support for the proposed prescriptive filtering methods is required in order to provide flexibility and allow for a better consideration of the specific task or application context. The domain model view corresponds to the approach of buildingSMART by using Model View Definitions , which define the information requirements of a specific exchange scenario based on Information Delivery Manuals [5]. For such reasons, Zhang et al. developed the mvdXML Checker prototype to parse MVD on the basis of mvdXML and to check IFC models [33], [34]. When one or more checks fail, a report is generated and lists all potential problems.

Through a two-step process an mvdXML file can be used to extract partial building data from a BIM. Figure 27 shows the tool chain:

1. Usage of mvdXML converter to map an mvdXML file into the corresponding ifcQL syntax. During this step, it can be specified at application start-up if a validation or a filtering query should be made.

2. Executing the ifcQL processor with import of an IFC file and the created ifcQL file from step (1) that contains all the commands. The output is either a LOG file with the summary of checks (validation) or a reduced IFC file (filtering).

Figure 27 Mapping process

The second step is introduced in detail in section 6.7. Looking deeper in the first step, following tasksare performed:

1. Parsing of mvdXML - The mvdXML converter parses the XML content of the MVD. 2. Instantiation of MVD objects based on their content - The XML elements are evaluated,

mapped to corresponding Java classes and instantiated. The mvdXML structure version 1.1 [35] is used to create a Java object graph of exchange requirements.


2017-02-08

3. MVD objects are converted to ifcQL commands - After the initialisation of the object graph with exchange requirements, each node is transformed to a correct ifcQL command.

4. Export of ifcQL commands - Finally, the ifcQL commands are collected in the right order and exported to an ifcQL file which can be used to validate (check) or filter a building information model.

6.7 XmlToFilterConverter The checking functionality defines the basis for an efficient test of any IFC file against a given MVD. The XmlToFilterConverter tool [36] can be used to create the appropriate filter files. It enables the user to convert XML documents into the ifcQL language and supports the conversion of XML documents created according to the mvdXML schema. After the con-version, the resulting FilterIFC specifications can be executed using the FilterIFC tool. The parsing of all input mvdXML files is based on the official XSD schema [35]. As a first step, the input file is validated using the XSD schema. If the validation was successful, all elements are converted to the ifcQL language. The mapping process depends on the content of the input mvdXML file. If the file contains a <View> element the conversion will be controlled by that, if the file does not contain such an element, all elements will be converted directly. The mvdXML files are used to check IFC files on several aspects, e.g. if specific IFC elements are contained or if the values of attributes of these are correct. Hence, the basic tool functionality is checking. However, as the mvdXML specification does not limit the functionality to checking, the XmlToFilterConverter tool supports filtering as well. Essentially, XmlToFilterConverter is a command line tool which can be executed using the following syntax: $ java –jar XmlToFilterConverter.jar < input-file > < output-file > [ -filter ]

The parameters must be in the specified order. Their meaning is described in Table 4 below.

Table 4: Description of the syntax for XmlToFilterConverter


< input-file > The mvdXML or vpl file to convert. obligatory

< output-file > Path and name of resulting file (e.g. /path/to/out). obligatory

[ -filter ] In case of converting an mvdXML file it is possible to activate this flag to convert the rules to filter operations instead of checks.

voluntary

The following example represents a resulting FilterIFC file.

01: #Space_Properties_Thermal(mV1-c1)

02: _check entity -type "Ifcspace" having path

ONETOMANY "IsDefinedBy"("Ifcrelde_nesbyproperties")

.ONETOMANY "RelatingPropertyDefinition"("Ifcpropertyset")

.ONETOMANY "HasProperties"("Ifcpropertysinglevalue")

:("Name" EQUALS "SpaceTemperatureMax")

03: #Space_Properties_Thermal(mV1-c2)

04: _check entity -type "Ifcspace" having path

ONETOMANY "IsDefinedBy"("Ifcreldefinesbyproperties")

.ONETOMANY "RelatingPropertyDefinition"("Ifcpropertyset")

.ONETOMANY "HasProperties"("Ifcpropertysinglevalue")

:("Name" EQUALS "SpaceTemperatureMin")


2017-02-08

7. CONCLUSIONS

This report describes the combination of multiple related models from different domains in a consistent Multi-Model Framework. The underlying idea was to combine different models referred to as elementary models in a single information resource to achieve a closely linked cooperation between the different domains of the construction industry. Elementary models can be any kind of either engineering or management models involved in energy enhanced BIM. The elementary models are interconnected using a link model via unique identifiers. The expected elementary models might be part of one or several existing Multi-Models. In the first case the Multi-Model can be reused. In the second case, the Multi-models which come into question have to be decomposed, reorganized and merged for the given task.

Regarding the different design and construction domains involved in the holistic approach the workflow needs very specific data which are not relevant for every BIM participant. For this reason, filtering based on BIMfit and ifcQL provides an innovative concept which allows checking BIM data, but also filtering with model views on the basis of mvdXML. In this report the filtering of (Multi-) models is covered in detail. It is needed in nearly any kind of model management and information handling, for example to prepare the BIM for the Link Models. To link data with elements, the necessary and sufficient elements have to be filtered first from the BIM.

Chapter 6.5 covers the functionality of FilterIFC and chapter 6.7 the XmlToFilterConverter. Both tools are using the underlying technology of the BIMfit toolbox presented in detail in report D4.1.

Using BIM for energy simulation can hardly be a fully automatic or a single-click solution. However, for further improvement of energy efficiency, more work towards automating the process from BIM to simulation analyses is necessary. Currently, the extraction of geometrical information from the architectural models for energy simulations is considerably hampered by inconsistent geometrical and other related definitions in the planning phase which can be avoided in many cases. Up to now not all possibilities provided by IFC or gbXML are used in the export functionality of CAD tools. Here, especially, the development of usable standards for the verification of building models will be of vital importance for the acceptance of BIM in practice.

Based on the proposed methods architects, engineers and energy consultants are enabled to consider aspects of energy performance simulation that are not typically available from the design documents, but are critical in performing realistic energy simulations for design opti-misation. The developed solutions represent a crucial part in the whole workspace of Design4Energy, which enables multi-disciplinary to investigate distinct energy solutions already in the early design phase of energy-efficient buildings up to the later retrofitting phase of their life cycle.


2017-02-08

8. ACRONYMS AND TERMS BIM: Building Information Modelling

CAD: Computer Aided Design

CV Coordination View for the buildingSMART IFC model

DEEBIP: Dynamic Energy Efficient Building Information Platform

eeBIM: energy-efficient Building Information Modelling

ERM: Exchange Requirement Models

GMSD: Generalized Model Subset Definition Schema

HVAC: Heating, Ventilation and Air Conditioning

IDD Input Data Dictionary

IDF Input Data File

IDM: Information Delivery Manual

IFC: Industry Foundation Classes

LOD: Level Of Detail

MVD: Model View Definition

REST

SQL: Structured Query Language

OMG: Object Management Group

XML: Extensible Markup Language

XSD: XML Schema Definition


2017-02-08

9. REFERENCES [1] C. M. Eastman, P. Teicholz, R. Sacks, and K. Liston, BIM Handbook: A Guide to

Building Information Modeling for Owners, Managers, Designers, Engineers and Contractors. John Wiley & Sons, 2011.

[2] V. Bazjanac, “IFC BIM-Based Methodology for Semi-Automated Building Energy Performance Simulation,” Lawrence Berkeley Natl. Lab., Sep. 2008.

[3] U.S. Department of Energy (US-DOE), EnergyPlus. 2003.

[4] International Organization for Standardization, “ISO 16739:2013 - Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries,” ISO. [Online]. Available: http://www.iso.org/iso/catalogue_detail.htm?csnumber=51622. [Accessed: 31-Jan-2017].

[5] buildingSMART International, “Information Delivery Manuals,” 2016-2008. [Online]. Available: http://iug.buildingsmart.org/idms/. [Accessed: 01-Feb-2017].

[6] R. J. Scherer and S.-E. Schapke, Eds., Informationssysteme im Bauwesen 1. Berlin, Heidelberg: Springer, 2014.

[7] HESMOS, EU 7th Framework Programme, 2013-2007. [Online]. Available: http://hesmos.eu/. [Accessed: 03-Jan-2017].

[8] P. Stenzel, J. Haufe, and N. Jimenez-Redondo, “Using a multi-model for a BIM-based design and operation of building energy management systems,” in eWork and eBusiness in Architecture, Engineering and Construction, Ardeshir Mahdavi, Bob Martens, And Raimar Scherer., CRC Press, 2014, pp. 813–820.

[9] P. Katranuschkov, M. Weise, R. Windisch, S. Fuchs, and R. J. Scherer, “BIM-based Generation of Multi-Model Views,” in Proceedings of the CIB W78 2010: 27 th International Conference, Cairo, Egypt, 2010.

[10] buildingSMART International, “ifcDoc Tool.” [Online]. Available: http://www.buildingsmart-tech.org/specifications/specification-tools/ifcdoc-tool. [Accessed: 01-Feb-2017].

[11] Open Geospatial Consortium, “Building Performance and Energy Analysis (BPEA) Thread,” 2008. [Online]. Available: http://zeroemissiondesign.com/uploads/BPEA_Final_Demo_Presentation.pdf. [Accessed: 02-Nov-2016].

[12] T. Liebig, K. Stuhlmacher, and R. Guruz, “Information Delivery Manual Work within HESMOS.” [Online]. Available: http://iug.buildingsmart.org/idms/overview/IDM_Hesmos_overview_20120912.pdf. [Accessed: 02-Jan-2017].

[13] Mefisto, German BMBF Project, 2012-2009. [Online]. Available: http://mefisto-bau.de/. [Accessed: 03-Jan-2017].

[14] Green Building XML (gbXML) Schema, Inc., “gbXML Green Building - Current Schema,” Nov-2015. [Online]. Available: http://www.gbxml.org/Schema_Current_GreenBuildingXML_gbXML. [Accessed: 01-Feb-2017].


2017-02-08

[15] C. Miller et al., “BIM-extracted EnergyPlus model calibration for retrofit analysis of a historically listed building in Switzerland,” in Proceedings of SimBuild, 2014.

[16] F. Noack et al., “Technical challenges and approaches to transfer building information models to building energy,” in eWork and eBusiness in Architecture, Engineering and Construction: ECPPM 2016: Proceedings of the 11th European Conference on Product and Process Modelling (ECPPM 2016), Symeon Christodoulou, Raimar Scherer., Limassol, Cyprus: © CRC Press, Taylor & Francis, 2016.

[17] V. Dimitriou, T. M. Hassan, and F. Fouchal, “BIM enabled building energy modelling: development and verification of a gbxml to idf conversion method,” in Proceedings of BSO2016, 2016.

[18] G. Gudnason, P. Katranuschkov, R. Scherer, and C. Balaras, “Framework for sharing and re-use of domain data in whole building energy simulation,” in eWork and eBusiness in Architecture, Engineering and Construction, CRC Press, 2014, pp. 495–502.

[19] V. Bazjanac and A. Kiviniemi, “Reduction, simplification, translation and interpretation in the exchange of model data,” in CIB W78: 24th Conference, 2007.

[20] V. Bazjanac, “Space boundary requirements for modeling of building geometry for energy and other performance simulation,” in CIB W78: 27th International Conference, 2010.

[21] Y. Zhang and I. Korolija, “JEPlus – An EnergyPlus simulation manager for parametrics,” JEPlus – An EnergyPlus simulation manager for parametrics, 2013. [Online]. Available: http://www.jeplus.org. [Accessed: 03-Jan-2017].

[22] ISES, EU 7th Framework Programme, 2013-2007. [Online]. Available: http://ises.eu-project.info/. [Accessed: 03-Jan-2017].

[23] buildingSMART International, “IFC2x3 CV V2.0 Certification Summary,” 2016-2008. [Online]. Available: http://www.buildingsmart-tech.org/certification/ifc-certification-2.0/ifc2x3-cv-v2.0-certification. [Accessed: 22-Dec-2016].

[24] buildingSMART International, “Space Boundary Summary,” 2016-2008. [Online]. Available: http://www.buildingsmart-tech.org/specifications/ifc-view-definition/space-boundary-addon-view. [Accessed: 03-Jan-2017].

[25] BLIS Consortium and Digital Alchemy, “IFC Solutions Factory,” 2012-2000. [Online]. Available: http://www.blis-project.org/IAI-MVD/. [Accessed: 03-Jan-2017].

[26] R. See, “Design to Building Energy Analysis: IFC Release Specific AEC/FM View Description (IFC 2x3),” 2011. [Online]. Available: http://www.blis-project.org/IAI-MVD/MVDs/GSA-003/.

[27] M. Weise, P. Katranuschkov, and R. Scherer, “Generalised Model Subset Definition Schema.” Construction Informatics Digital Library, 2003.

[28] K. Baumgärtel, S. Pirnbaum, H. Provost, and R. J. Scherer, “Automatic BIM filtering using Model View Definitions,” presented at the CIB W78 conference, Brisbane, Australia, 2016.

[29] A. Wülfing, K. Baumgärtel, and R. Windisch, “BIMfit - A Modular Software Tool for Querying and Filtering of building Models (in German),” presented at the 24th Conference “Forum Bauinformatik,” Bochum, Germany, 2012.

[30] S. Pirnbaum, “Using the FilterIFC tool,” TU Dresden, Technical Report, 2015.


2017-02-08

[31] A. Borrmann and E. Rank, “Topological analysis of 3D building models using a spatial query language,” Adv. Eng. Inform., vol. 23, no. 4, pp. 370–385, Oct. 2009.

[32] R. Romberg, A. Niggl, and C. Van Treeck, “Structural Analysis based on the Product Model Standard IFC,” in International Conference on Computing in Civil and Building Engineering , ICCCBE , 10, Weimar, 2004.

[33] Y. Zhang, J. Beetz, and M. Weise, “Interoperable Validation for IFC Building Modles Using Open Standards,” www.itcon.org - J. Inf. Technol. Constr., vol. 20, 2014.

[34] C. Zhang, J. Beetz, and M. Weise, “Model view checking: automated validation for IFC building models,” in eWork and eBusiness in Architecture, Engineering and Construction: ECPPM 2014, Ardeshir Mahdavi, Bob Martens, Raimar Scherer., CRC Press, 2014.

[35] T. Chipman, T. Liebig, and M. Weise, “mvdXML,” 15-Feb-2016. [Online]. Available: http://www.buildingsmart-tech.org/downloads/mvdxml/mvdxml-1.1/final/mvdxml-1-1-documentation. [Accessed: 01-Feb-2017].

[36] S. Pirnbaum, “The XmlTofilterConverter Tool,” TU Dresden, Technical Report, 2015.

[37] Oracle Corporation, “Pattern (Java Platform SE 8 ),” 1993. [Online]. Available: http://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html. [Accessed: 30-Dec-2016].


2017-02-08

10. APPENDICES

10.1 FIlterIFC Filter File Specification

The filter file gives the possibility to specify filter rules. These filter rules will be applied by the FilterIFC program to reduce an IFC file to only the required entities.

10.1.1 Comments

A comment is initiated by a leading # on a new line. Everything afterwards on the same line is ignored by the program. Example: Comment lines

10.1.2 Macros

To avoid boilerplate, the tool offers the functionality of macros. Macros are code snippets that are defined before usage and can store any text or operation even partly. When the macro is used later, the stored text is inserted at this position. Macros are used and defined using following syntax: def $<identifier>$ = <value>

To use the created macro, simply place $<identifier>$ on the desired place. Note: Macros can only be used in operations and only on lines starting with _. This means, that the macro cannot replace all _.


<identifier> Gives the macro a new to reuse it. Obligatory <value> The value with which the macro should be replace. Obligatory

Example: Macro usage

10.1.3 Filters

A filter is used to reduce the number of entities of an ifc file. Only those entities are contained in the result which fulfill the filter. It has following syntax:

01:#This line will be ignored

01: #define a macro storing a global id

02: def $stream$ = "05hREyEmr2Q87RZGmjkknM"

03: #define a shortcut for a command

04: def $colorLime$ = add color lime -guid

05: #use the stored id

06: ~add color blue -guid $stream$

07: #use the stored command

08: ~~$colorLime$ "23TFxdxQnATwMxUze0pMMC"


2017-02-08

~ filter -<type|guid>

<<specifier(s)...>

|exclude <specifier(s)...>>

[-recursive]

[-tuid <specifier>]


-<type | guid> Determines whether the entites shall be filtered by the type (based on the Ifc type) or by the global id

Oblicatory

<specifier(s)...> Specifiers for filter rule. If using as type filter, use the naming from [Int07] (e.g. "Ifcwall"), otherwise use the global id. Several specifiers can be combined, the single specifiers are separated by one space.

Either this or excluded specifiers obligatory

Exclude<specifier(s)...> Specifiers for filter rule. When using the exclude key word, all entities determined by the specifiers are removed from the underlying data set in the result.

Either this or included specifiers obligatory

[-recursive] Optional parameter. If used, the resulting file will contain not only the entities specified previously, but also all entities contained by these excluding the representation. (The representation will be added by the geometry flag on command line)

Voluntary

[-tuid <specifier>] A temporal user id for the filter. This gives the possibility to use the filter result in other operation where applicable.

Voluntary

Example: Simple filter usage

01: #type filter to get all walls of an ifc file:


03: #instance filter to get entity with global id 3x94dj40kd8

04: ~filter -guid "3x94dj40kd8"

05: #getting entities of several types

06: ~filter -type "Ifcwall" "Ifcwindow" "Ifcspace"

07: #type filter including also sub entities

08: ~filter -type "Ifcwall" -recursive

09: #type filter excluding all walls

10: ~filter -type exclude "Ifcwall"

11: #type filter excluding entitiy with id "3k3jdkds"

12: ~filter -guid exclude "3k3jdkds"

13: #setting the tuid

14: ~filter -type "Ifcwall" -tuid "123abc"


2017-02-08

The resulting file will contain the combined result of all filters specified in the filter file.

10.1.4 Conditions Additionally to simple filtering it is possible to further limit the result with conditions. For all entities fulfilling the simple filter the fulfillment of the condition is checked. Only those who do will be included in the resulting data set. Therefore, -whereis added to the filter completed by the condition. The filter will now look like this: ~filter...[-where <condition(s)...>]

Note: The -where flag must be on the same line as the filter. Note: Several conditions are separated by &&

Note: The entities determined by conditions are not included in the resulting set of entities, only those who match the normal filter are. To include them, use the with notation.

There exist 6 types of conditions.

10.1.4.1 The attribute condition

The attribute condition checks for the resulting entities of a filter if they have an attribute satisfying the comparison to a specified value and returns these. It has following syntax: attribute <attribute-name> [<comparison-operation> <value>]


<attribute-name> For all entities in the underlying data set it is checked if they have an attribute matching the specified name.

Obligatory

<comparison-operation> The comparison is applied on the resulting entities fulfilling the previous parameter. If not used, then it is only checked for the existence of an attribute with the previous specified name.

Voluntary

<value> The value for which is checked if the value of the specified attribute of an entity fulfills the specified comparison.

Obligatory when using comparison

Example: Filtering for attributes

10.1.4.2 The material condition

The material condition checks for the resulting entities of a filter if they are of a specified material and if yes returns those. It has following syntax:

01: #filter all walls named Exterior

02: ~filter -type "Ifcwall" -where attribute "name" equals "Exterior"

03: #filter all walls named Interior and having the desciption "Interior Wall"

04: ~filter -type "Ifcwall" -where attribute "name" equals "Interior" && attribute

"description" equals "Interior Wall"

05: # usage of decimal numbers in filters

06: ~filter -type "Ifcbuildingstorey" –where attribute "elevation" greater "0.0"


2017-02-08

material <material-type>


<material-type> Determines of which ifc material an entity must be to satisfy the condition and with that being part of the filter result. This is the value of the name attribute of the material.

Obligatory

Example: Material condition

10.1.4.3 The path condition

Sometimes it is necessary to check a connection from one entity to another where the connection is more complex and is not covered by one of the standard conditions. Or furthermore to check the value of a so specified connection. Therefore it is possible to specify the path given by the attribute names manually with this syntax:

path [multiplicity] <attributename> [(<ifctype>)] [:<complexcondition>]

[<-> | <-|.> [multiplicity] <attributename> [(<ifctype>)][:<complexcondition>]]*

Where the <complexcondition> is of following form:

(<comparison-attribute><comparison-operation><value>)[<&& | || ><comparison-attribute> <comparison-operation><value>]~

Note: The conditions can be fully bracketed. The * allows the repetition of the argument.


[multiplicity] Determines how many entities specified by the follwing <attributename> and <ifctype> (if present) must fulfill the following path so that the previous specified entity (either a previous path element or the in the filter specified entity) is valid. Following are supported: ZERO, ZEROTOONE, ONE, ONETOMANY.

Voluntary

<attributename> Specifies the attribute to continue with from the entities of the filter result or if present the previous path element specified. This means that the previous entity must have an attribute, either direct or inverse linked by this name, to fulfill the condition (when used in first path element) or the path section (when used afterwards).

Obligatory

<ifctype> The type of which the specified entity must be so that it is further evaluated in the following path elements.

Voluntary

01: #filter all walls made of concrete

02: ~filter -type "Ifcwall" -where material "concrete"


2017-02-08

[< - > | < - | . > Determines the type of the relation between two entities, the one left of the type and the one right of it. For a direct relation use ->, in case of an inverse use <- and if the relation type is unknown use . . While -> and <- will only check for the given relation type, . will check both if necessary and therewith can be slower.

Voluntary, can be used several times in connection with attributename

<comparison-attribute> The attribute name of the attribute in the entity specified by the corresponding path element, which has to fulfill the following specified comparison so that the entity fulfills the path element.

Voluntary

<comparison-operation> The comparison is applied on attributes specified by the <comparison-attribute> parameter under the condition that it was found. for further information. If not used, then it is only checked for the existence of an attribute with the previous specified name.

Voluntary

<value> The value for which is checked if the value of the specified attribute of an entity fulfills the specified comparison.


Example: Path finding:

10.1.4.4 The property condition

The property condition checks for the resulting entities of a filter if they are linked to a property set and additionally if the property set has an property satisfying the comparison to a specified value and returns these. It has following syntax:

property <property-set-name> [<property name> [<comparison-operation><value>]]

Note: The complete condition must be on one line.

01: # get all Ifcrelspaceboundaries which are connected to the given buildingelement

02: ~filter -type "Ifcrelspaceboundary" -recursive -where PATH

"relatedbuildingelement":"GlobalId" == "0MGQzb2T"

03: # get all walls having an Ifcopeningelement assigned

04: ~filter -type "Ifcwall" -where PATH "hasopenings">

"relatedopeningelement"<"hasfillings"

05: # filter all projects which are assigned to exactly one building with the given

name and globalid through one relaggregates object

06: ~filter -type "Ifcproject" -where PATH ONE "isdecomposedby" ("Ifcrelaggregates")

->"relatedobjects"("Ifcbuilding") : ("name" LIKE "Geb.*de" && "globalid" ==

"0fj6JmRC91")


2017-02-08


<property-set-name>

All entities in the underlying data set gets checked if they are linked to a property set matching the specified name. If the property set name is unknown, an asterisk can be used.

Obligatory

<property-name>

For all entities fulfilling the previous parameter is checked if the specified property set has an property matching the specified name. So this is the value of the name attribute of the property.

Voluntary

<comparison-operation>

The comparison is applied on the resulting entities fulfilling the property-name parameter. If the com-parison is not used, it is only checked for the existence of properties with the previously specified name.

Voluntary, only allowed with property name

<value> The value for which is checked if the value of previously determined properties is fulfilled by those.


Example: Filtering with property condition

10.1.4.5 The quantity condition

The quantity condition checks for the resulting entities of a filter if they have an quantity satisfying the comparison to a specified value and returns these. It has following syntax:

quantity <quantity –set-name> [<quantity-name> [<comparison-operation> <value>]]

Note: Complex Quantities are not considered in the comparison. Though, if the name matches, it is added to the result set.


<quantity-set-name>

All entities in the underlying data set gets checked if they are linked to a quantity set (sometimes referred to as element quantity) matching the specified name. If the quantity set name is unknown, an asterisk can be used.

Obligatory

<quantity-name>

For all entities from the underlying data set which are linked to the specified quantity set it is checked if they have an quantity matching the specified name. So this is the value of the name attribute of the quantity.

Voluntary


The comparison is applied on the resulting entities fulfilling the previous parameter.

Voluntary

01: # get all internal Ifcwalls (internal is expressed by value 1)

02: ~filter -type "Ifcwall" -where property "Pset_WallCommon" "IsExternal" EQUALS "1"

03: # filter all Ifcroot entities having the specified property set assigned

04: filter -type "Ifcroot" -where property "Pset_WallCommon"

05: # filtering with unknown proeprty set

06: filter -type "Ifcroot" -where property "*" "LoadBearing" EQUALS "1"


2017-02-08

<value> The value for which is checked if the value attribute of the specified quantity of an entity fulfils the specified comparison.


Example: Filtering with quantity condition

10.1.4.6 The relation condition

Sometimes it is useful to filter for example walls out of an StepDataModel which surround an opening element, e.g. a window. Therefore the tool offers the possibility to filter by relations using the relation condition. Following syntax is used: relation <relating-entity> [<comparison-operation> <value>]

Note: The relation condition is applied transitive if necessary. This means it is looked for any connection between the entities.


<relating-entity> Description Declaration <relating-entity> For all entities in the underlying data set it is checked if they are connected to an entity determined by the ifc type given by this parameter.

Obligatory

<comparison-operation> The comparison is applied on the resulting entities fulfilling the previous parameter. In this case it is possible to determine the number of e.g. windows an entity must be connected to to fulfill the condition. See subsection 4.4.7 on page 24 for further information. If not used the entities gets only checked for the existence of a relation to the previously specified entities.

Voluntary

<value> The number of entities the entity specified by the filter must be linked to.


10.1.4.7 The comparison option

To compare the actual and the specified value, the comparison operation is required. Therefore, five types exist:

Operation Alternative Satisfiability equals == Satisfied if: actual value of entity == specified value greater > Satisfied if: actual value of entity > specified value lower < Satisfied if: actual value of entity < specified value greatereq >= Satisfied if: actual value of entity >= specified value lowereq <= Satisfied if: actual value of entity <= specified value noteq != Satisfied if: actual value of entity != specified value

01: # get all Ifcwalls with a gross side are of at least 23.6, the set value in the

input ifc file counts without regarding the unit

02: ~ filter -type "Ifcwall" -where quantity "*" "GrossSideArea" GREATER "23.6"


2017-02-08

Note: The value must be compliant to the specification at [Int07]. This means, if an value is a member of an enumeration, then the integer representation must be quoted. When it comes to string comparisons, another operation is applicable, namely the LIKE comparison. It gives the possibility to compare the actual value to a regular expression. Regular expressions are a character sequence defining a search pattern. With this the comparison is highly variable, e.g. matching for pre-, in- and suffix.

10.1.4.8 Condition combination

Conditions can be combined. Therefore, the single conditions must be separated by && (for logical and) or with ||(for logical or). Following forms are equivalent:

Example: Condition splitting over several lines

Note: If a line contains only conditions, then the line must start with the same count of _ as the filter line to which it belongs. Note: The ”AND” operator represented by && is stronger then the ”OR” operator which is represented by ||. To bypass this behaviour, for example having the ”OR” evaluated first and afterwards the ”AND”, parentheses must be used.

Example: Mixed condition operations

10.1.4.9 Including conditioned entities

Using a condition does not include the entities described by it. To include them it is only necessary to exchange the -where keyword at the beginning of the condition with -with. This will add entities determined by the condition (and in case of for example the material condition, the structure in between) on the base of the previously applied filter. For further filtering by normal conditions, the -where keyword can still be used. Therewith, following syntax is applicable: Note: The including condition will not remove entities from the data set. ~ filter... [-where <condition(s)...>] [-with <condition(s)...>]

01: #filter with condition:

02: ~filter -type "Ifcwall" -where condition1 && condition2 && ...

03: #is equivalent to:

04: ~filter -type "Ifcwall" -where condition1 &&

05: ~condition2 &&

06: ~...

07: #is equivalent to:

08: ~filter -type "Ifcwall" -where

09: ~condition1 &&

10: ~condition2 &&

11: ~...

01: #filter with condition, evaluated as ((c1 && c2) || c3):

02: ~filter -type "Ifcwall" -where c1 && c2 || c3

03: #filter with condition, clasped

04: ~filter -type "Ifcwall" -where c1 && (c2 || c3)


2017-02-08

Example: Impact of the with keyword

The example is basically the same as example 6 on page 20. Only -where is switched to -with. While using -where only Ifcwall entities are contained in the resulting IFC model (of course only those fulfilling the condition) we now get a bigger result. Additionally to Ifcwall we now get the Ifcrelvoidselement, Ifcrelfillselement and Ifcopeningelement whose are part of the condition fulfilling paths.

10.1.5 Sub filters Filters can also be applied on a result of another filter. Therefore, the ~ is needed. The ~ defines the level, on which the filter is working. To filter a result, the filter line must start with one ~ more than the filter line on whose results the filter shall be applied. The resulting file will contain the results of those filters, which do not have a sub filter. Note: In the following example, not specified filters are used to show the syntax.

Example: Filter combination

Note:The resulting file will contain the results of filter1.1.1, filter1.1.2, filter1.2 and filter2.

10.1.6 Checks The FilterIFC tool gives the possibility to check, whether a data set1

contains entities with a specific characteristic. Checks have no influence on the filter result, however if a check fails the program will exit without a result. Instead, an error message will be printed in the terminal. Every check in the filter file must stand exclusively on one line. To specify what data set it has to check, the level is determined by the number of leading _, as it is with the filter and condition level. #check the input file ~check <check-specification> ~filter <filter-specification>

#check filter result ~~check <check-specification>

1 A data set can be an ifc file as well as a filter result

01: #getting all walls having an Ifcopeningelement assigned 02: ~filter -type "Ifcwall" -with PATH "hasopenings"->"relatedopeningelement"<-"hasfillings"

01: #filter the input ifc file

02: ~filter1

03: #apply filter on result of superior filter 1

04: ~~filter1.1

05: #filter the result of the superior filter 1.1

06: ~~~filter1.1.1

07: #filter the result of superior filter 1.1

08: ~~~filter1.1.2

09: #filter the result of superior filter1

10: ~~filter1.2

11: #filter the input ifc file

12: ~filter2


2017-02-08

There are 7 types recognized by the tool.

10.1.6.1 The entity check

The entity check is used to check whether an underlying data set has entities of a specified ifc type. It has following syntax:

entity [<specifier>+ | <-type <ifctype>+ |-guid <global d>+ |-tuid <userid>+>+] [function] [(-where <condition(s)...>)] [<check-operation><count>]

Note: In the filter file, a check must be on one line.

Note: The left and right parenthesis around the condition block are obligatory to delimit it from the comparison.


<specifier>+ Deprecated The IFC type of the entities for which is checked if entities of this type exist. (e.g. "Ifcwall" if you want to check if walls exist). Multiple specifiers are separated by one space. Default are all entities in the underlying data set.

Voluntary

-type <ifctype>+ The IFC type of the entities for which is checked if entities of this type exist. (e.g. "Ifcwall" if you want to check if walls exist). Multiple specifiers are separated by one space. Default are all entities in the underlying data set.

Voluntary

-guid <globalid>+ The global id of those entities for whose the check is executed, in this case used for simple existence checking.

Voluntary

-tuid <userid>+ The temporal user id to specify entities to check. The entities are the result of the corresponding operation, in case of an Adder it is the created entity.

Voluntary

[function] A function can be specified to change the comparison value from the specified entities to a in the function specified quantity. Thereby it is looked for the quantity in every entity of the specified ones. If a comparison is specified, the comparison compares the expected value with the result of the function.

Voluntary

<condition(s)...> To further reducing the number of entities to check and to be more variable it is possible to use conditions. The usage is the same as in filters and described in section 10.1.4.

Voluntary

[<check-operation>

<count>]

The check operation determines if the check ends positive. Therefore, the number of all entities matching the specified type is compared to the specified count using this operation. Default operation is EQUALS and default count is the number of entities in the underlying data set.

Voluntary, count obligatory when used


2017-02-08

Example: Count checking for entities

10.1.6.2 The attribute check

The attribute check is used to check whether an underlying data set has entities containing a specified attribute. It has following syntax: entity [<specifier>+ | <-type <ifctype>+ |-guid <globalid>+ |-tuid <userid>+>+][function] having attribute <attribute-name> [( -where <condition(s)...>)] [<check-opertion><count>]

Note:In the filter file, a check must be on one line.

Note:The left and right parenthesis around the condition block is obligatory to delimit it from the comparison.


<attribute-name> The attribute name of the attribute, whose existence in the entities is checked.

Obligatory

[<check-operation>

<count>]

The check operation determines if the check ends positive. Therefore, the number of all entities matching the specified type and attribute is compared to the specified count using this operation. For further information see subsection 4.6.9 on page 37. Default operation is EQUALS and default count is the number of entities in the underlying data set.


10.1.6.3 The material check

The material check is used to check whether an underlying data set contains entities of a specified material. It has following syntax: Entity [<specifier>+ | <-type <ifctype>+ |-guid <globalid>+ |-tuid <userid>+>+] [function]

having material <material-type>[(-where <condition(s)...>)] [<check-operation> <count>]

Note: In the filter file, a check must be on one line. Note: The left and right parenthesis around the condition block is obligatory to delimit it from the comparison.

Parameter Description Declaration <material-type> Is the ifc type of the material and therewith

determines of which type the entities in the data set must be to fulfill the check.

Obligatory

[<check-operation> <count>]

The check operation determines if the check ends positive. Therefore, the number of all entities matching the specified type and material is compared to the specified count using this operation. For further information see subsection 4.6.9 on page 37. Default operation is EQUALS and default count is the number of entities in the underlying data set.


01: # check if more than 7 Ifcwalls with an area of at least 23.6 are in the filter

result (and therewidth in the input file)

02: ~filter -type "Ifcwall" -where quantity "GrossSideArea" GREATER "23.6"

03: ~~check entity "Ifcwall" > 7


2017-02-08

10.1.6.4 The path check

The path check is used to check whether a connection between two entities following a given path exists. It has following syntax: entity [<specifier>+ | <-type <ifctype>+ | -guid <globalid>+ |-tuid <userid>+>+][function] having path [multiplicity] <attributename> [(<ifctype>)][ : <complexcondition>][<-> | <-|.> [multiplicity]<attributename>[(<ifctype>)][:<complexcondition>]]_[(-where <condition(s)...>)][<check-operation> <count>]

Note: In the filter file, a check must be on one line. Note: The left and right parenthesis around the condition block is obligatory to delimit it from the comparison. Where the <complexcondition> is of following form:

(<comparison-attribute><comparison-operation><value>)[<&& | || ><comparison-attribute> <comparison-operation><value>]~

Note: The * allows the repetition of the argument.


[multiplicity] Determines how many entities specified by the follwing <attributename> and <ifctype> (if present) must fulfill the following path so that the previous specified entity (either a previous path element or the in the filter specified entity) is valid. Following are supported: ZERO, ZEROTOONE, ONE, ONETOMANY.

Voluntary

<attributename> Specifies the attribute to continue with from the entities of the filter result or if present the previous path element specified. This means that the previous entity must have an attribute, either direct or inverse linked by this name, to fulfill the condition (when used in first path element) or the path section (when used afterwards).

Obligatory

<ifctype> The type of which the specified entity must be so that it is further evaluated in the following path elements.

Voluntary

[< - > | < - | . > Determines the type of the relation between two entities, the one left of the type and the one right of it. For a direct relation use ->, in case of an inverse use <- and if the relation type is unknown use . . While -> and <- will only check for the given relation type, . will check both if necessary and therewith can be slower.

Voluntary, can be used several times in connection with attributename

<comparison-attribute>

The attribute name of the attribute in the entity specified by the corresponding path element, which has to fulfill the following specified comparison so that the entity fulfills the path element.

Voluntary


2017-02-08


The comparison is applied on attributes specified by the <comparison-attribute> parameter under the condition that it was found. If not used, then it is only checked for the existence of an attribute with the previous specified name.

Voluntary

<value> The value for which is checked if the value of the specified attribute of an entity fulfills the speci-fied comparison.


10.1.6.5 The property check

The property check is used to check whether an underlying data set has entities connected to aspecified property set and optionally if the property set has a specified property. It has following syntax: entity [<specifier>+ | <-type <ifctype>+ |-guid <globalid>+ |-tuid <userid>+>+][function]

having propertyset <property-set-name> [having property <property-name>][(-where <condition(s)...>)][<checkoperation><count>]


Note: The left and right parenthesis around the condition block is obligatory to delimit it from the comparison.


<property-setname> The name of the property set, for which is checked if the specified entities are connected with. If the property set name is unknown, the asterisk can be used instead.

Obligatory

<property-name> The name of the property whose existence is checked in the specified property set of the specified entities.

Voluntary

[<check-operation>

<count>]

The check operation determines if the check ends positive. Therefore, the number of all entities matching the specified type and property set (and if declared also the property) is compared to the specified count using this operation. For further information see subsection 4.6.9 on page 37. Default operation is EQUALS and default count is the number of entities in the underlying data set.


10.1.6.6 The quantity check

The quantity check is used to check whether an underlying data set has entities having a specified quantity. It has following syntax:

entity [<specifier>+ | <-type <ifctype>+ |-guid <globalid>+ |-tuid <userid>+>+][function] having quantityset <quantity-set-name> [having quantity <quantity-name>][(-where <condition(s)...>)][<checkoperation><count>]



2017-02-08

Note: The left and right parenthesis around the condition block is obligatory to delimit it from the comparison. Complex quantities are not considered in the comparison. Though, if the name matches, it is added to the result set.


<quantity-setname> The name of the quantity set, for which is checked if the specified entities are connected with. If the quantiy set name is unknown, the asterisk can be used instead.

Obligatory

<quantity-name> The quantity name of the quantity, whose existence in the entities matching the previous specified quantity set is checked.

Voluntary

[<check-operation>

<count>]

The check operation determines if the check ends positive. Therefore, the number of all entities matching the specified type and quantity is compared to the specified count using this operation. For further information see subsection 4.6.9 on page 37. Default operation is EQUALS and default count is the number of entities in the underlying data set.


10.1.6.7 The relation check

The relation check is used to check whether entities are connected. It has following syntax:

relation <<specifier1>+ | <-type <ifctype1>+ |-guid <globalid1>+ |-tuid <userid1>+>+> with <<specifier2>+ | <-type <ifctype2>+ |-guid <globalid2>+ |-tuid <userid2>+>+> [(-where <condition(s)...>)] [<check-operation> <count >]


Note: The left and right parenthesis around the condition block is obligatory to delimit it from the comparison.

Note: The specified entities one and two, be it by simple Deprecated specifier or by -type, guid or -tuid are those between which a relation is searched for. For description of the specification forms see subsection 4.6.1 on page 28.


[<check-operation> <count>]

The check operation determines if the check ends positive. Therefore, the number of entities specified by specifier1 whose have a relation to those specified by specifier2 is compared to the specified count using this operation. Default operation is EQUALS and default count is the number of possible relations, which results out of the multiplication of the number of entities matching the first specifiers with those matching the second specifiers.



2017-02-08

10.1.6.8 The aggregate functions

To offer the ability for calculations the tool has aggregate functions included. They have following syntax: fnc (<quantityname>)

The function looks for connected IfcPhysicalSimpleQuantity entities whose are assigned to those entities specified in the check operation matching the having clause and uses as calculation base the double value of them. Where fncis one of the following:

Function Description

AVG Computes the average over the value of the specified quantities MAX Computes the maximum over the value of the specified quantities

MIN Computes the minimum over the value of the specified quantities SUM Computes the sum over the value of the specified quantities

Example: Usage of aggregate functions

10.1.6.9 The check operation

The check operation is used to compare the number of entities satisfying the check specification with the specified count. Therefore, five types exist:

Operation Alternative Satisfiability

equals == Satisfied if: actual value of entity == specified value

greater > Satisfied if: actual value of entity > specified value lower < Satisfied if: actual value of entity < specified value

greatereq >= Satisfied if: actual value of entity >= specified value lowereq <= Satisfied if: actual value of entity <= specified value

noteq != Satisfied if: actual value of entity != specified value

10.1.7 Modifying the data set

In addition to querying it is also possible to manipulate the underlying data set. With FilterIFC it is possible to create new entities, update attributes of them and insert for example quantities into them.

01: # Compute the maximum gross side area of all walls in the ifc file, where

"GrossSideArea" is the name of the quantity

02: ~check entity "Ifcwall" MAX("GrossSideArea")

03: # ensure that no wall is smaller than 10 units of area

04: ~check entity "Ifcwall" MIN("GrossSideArea") > 10

05: # compute the total gross side area of all walls connected to a material

06: ~check entity "Ifcwall" SUM("GrossSideArea")(-where path "hasassociations"

>"relatingmaterial" ->"forlayerset"->"materiallayers"->"material")


2017-02-08

10.1.7.1 Create entities

The add command gives the possibility, to add a new entity to an existing data set. Therefore, following command is used: add entity <specifier><name> [-tuid <userid>]

Note: In the filter file, an add must be on one line. Parameter Description Declaration

<specifier> The IFC type of the entity, which shall be created. E.g. "Ifcwall"

Obligatory

<name> The value of the name attribute in the new created entity. Obligatory [-tuid <userid>] A temporal user id for the filter. This gives the possibility to

use the created entity in other operations where applicable. Voluntary

Example: Entity creation

10.1.7.2 Create properties

While the entity creation command can be used to create properties with assignment of the name, the command to create properties (in this case Ifcsimpleproperty) can assign the value, value type and description in addition to the name. Therefore, following syntax is applicable: add property -name<name> [-nominalvalue <nominalvalue> -type <type >] [-description <description>] [-tuid <userid>]

Note: In the filter file, an add must be on one line.


<name> The value of the name attribute in the new created property.

Obligatory

<nominalvalue> Specifies the nominal value of the new created property.

Voluntary

<type> Specifies the type of the value of the new created property. Use ”boolean” for IfcBoolean, ”number” for IfcReal or ”string” for IfcText.

Obligatory when using nominal value

<description> Sets the description of the new creatd property to the given text.

Voluntary

<userid> A temporal user id for the filter. This gives the possibility to use the the created entity in other operations where applicable.

Voluntary

01: #add a property set to the input ifc file

02: ~add entity "Ifcpropertyset" "Values1"

03: #add a wall to the resulting set of the previous operation

04: ~~add entity "Ifcwall" "Wall1"

05: #add a window to the input ifc file

06: ~add entity "Ifcwindow" "Window1"


2017-02-08

10.1.7.3 Colorizing entities

To be able to focus on special entities or marking them as e.g. thermal efficient the tool can be used to colorize entities. Therefore following command must be applied on the set to modify: add <rgb <rgb-code> | color <name>> [exclude] <-type <specifier(s)...> |-guid <globalid(s)...> |-tuid <userid(s)...>>+ [-where <condition(s)...>]

Note: Due to the specification it is only possible to colorize entities whose are instances of Ifcproduct. All other entities are not coloured when specified.

Parameter Description Declaration rgb <rgb-code> Determines the color to use for colorization as rgb

code. Must be in following format: rrrgggbbb. For example for red use: 255000000

This or color name obligatory

color <name> Determines the colour to use for colorization from the set of predefined colours. See the colour table on page 62 for existing colours.

This or rgb code obligatory

[exclude] Determines whether the following specified entities shall be colored (than don’t use the flag) or all entities except those specified shall be colored (than use the flag).

Voluntary

-type <specifier(s)...> Specifies the entities which shall be colored by the IFC type (e.g. "Ifcwall).

Either this, guid or tuid obligatory

-guid <globalid(s)...> Specifies the entities which shall be colored by the global id.

Either this, type or tuid obligatory

-tuid <userid(s)...> Specifies the entities which shall be colored by the temporal user id. The user id is defined at the definition of operations in the filter file, whose support a user id. In case of add, only the created entity will be coloured, otherwise the hole result set of the specified operation.

Either this, type or guid obligatory

-where <condition(s)...>

Further restricts the entities to colour by conditions. See section 10.1.4 for information on their usage.

Voluntary

The following colours are pre-defined:


2017-02-08

Example: Colorization of entities

10.1.7.4 Insert into entities It is also possible to manipulate an existing entity. To do this, the following 4 types of insert commands exist. Insert into <-type <specifier(s)...> |-guid <globalid(s)...> |-tuid <userid(s)...>>+

<property set <-refguid <referential globalid>+ |-tuid <userid>+>+>+

Note: In the filter file, an insert must be on one line.


-type <specifier(s)...> Specifies the entities to which the property set shall be mapped by the ifc type (e.g. "Ifcwall).


-guid <globalid(s)...> Specifies the entities to which the property set shall be mapped by the global id.


-tuid <userid(s)...> Specifies the entities to which the property set shall be mapped by the temporal user id. The user id is defined at the definition of operations in the filter file, whose support a user id. In case of add, only the created entity will be used, otherwise the hole result set of the specified operation.


-refguid <referential globalid>

Specifies the property set to insert by the global id. Either this or tuid obligatory

-tuid <userid> Specifies the property set to insert by the temporal user id. In case the id is defined for an add, only the new created entity is used. If not, then the hole result data set of the specified operation is used, therefore it is necessary to ensure, that the resulting data set contains only one entity.

Either this or guid obligatory

Quantity inserter With the quantity inserter an existing quantity can be connected to another also existing entity. Therefore, following command is used: Insert into <-type <specifier(s)...> |-guid <globalid(s)...> |-tuid <userid(s)...>>+

<quantity <-name <quanity-name>+ |-tuid <userid>+>+>+


Note: Quantities can be inserted directly into an existing property set but additionally into all other entities. In last case a new property set for this entity will be created.

01: #Color the first wall in red

02: ~add rgb 255000000 -guid "1xcz3Atln3mxVfsxfyH6Cn"

03: #Color the second wall in green. Work on the result set of the first operation

04: ~~add rgb 000255000 -guid "2poM5k1Zj5nPewghmb_Jpx"


2017-02-08

Parameter Description Declaration -type <specifier(s)...> Specifies the entities to which the property set shall

be mapped by the ifc type (e.g. "Ifcwall). Either this, guid or tuid obligatory

-guid <globalid(s)...> Specifies the entities to which the property set shall be mapped by the global id.


-tuid <userid(s)...> Specifies the entities to which the property set shall be mapped by the temporal user id. The user id is defined at the definition of operations in the filter file, whose support a user id. In case of add, only the created entity will be used, otherwise the hole result set of the specified operation.


-refguid <quantityname>

Specifies the quantity to insert by the global id. Either this or tuid obligatory

-tuid <userid> Specifies the quantity to insert by the temporal user id. In case the id is defined for an add, only the new created entity is used. If not, then the hole result data set of the specified operation is used, therefore it is necessary to ensure, that the resulting data set contains only one entity.


Property inserter Despite adding property sets to other entities, it is also possible to insert an existing property into an existing property set. Therefore, following command is used: Insert into <-type <specifier(s)...> |-guid <globalid(s)...> |-tuid <userid(s)...>>+ <property <-name <property-name>+ |-tuid <userid>+>+>+


Note: Properties can be inserted directly into an existing property set but additionally into all other entities. In last case a new property set for this entity will be created.

Parameter Description Declaration -type <specifier(s)...> Specifies the property sets to which the property set

shall be mapped by the ifc type (e.g. "Ifcwall). Either this, guid or tuid obligatory

-guid <globalid(s)...> Specifies the property sets to which the property set shall be mapped by the global id.


-tuid <userid(s)...> Specifies the property sets to which the property set shall be mapped by the temporal user id. The user id is defined at the definition of operations in the filter file, whose support a user id. In case of add, only the created entity will be used, otherwise the hole result set of the specified operation.


-refguid <quantityname>

Specifies the property to insert by the global id. Either this or tuid obligatory


2017-02-08

-tuid <userid> Specifies the property to insert by the temporal user id. In case the id is defined for an add, only the new created entity is used. If not, then the hole result data set of the specified operation is used, therefore it is necessary to ensure, that the resulting data set contains only one entity.


New property inserter

It might be easier in case of properties to create them directly while inserting because they are not re referenced in another statement. Therefore it is possible to create properties and insert them in one with following syntax: Insert into <-type <specifier(s)...> |-guid <globalid(s)...> |-tuid <userid(s)...>>+ new property <-name <property-name>> [-nominalvalue <nominalvalue> -type <ifc-type>] [-description <description>]

Note: In the filter file, an insert must be on one line. Note: Properties can be inserted directly into an existing property set but additionally into all other entities. In last case a new property set for this entity will be created.


-type <specifier(s)...> Specifies the property sets, into which the property shall be inserted, by the ifc type (e.g. Ifcwall).


-guid <globalid(s)...> Specifies the property sets, into which the property shall be inserted, by the global id.


-tuid <userid(s)...> Specifies the property sets, into which the property shall be inserted, by the temporal user id. The user id is defined at the definition of operations in the filter file, whose support a user id. In case of add, only the created entity will be used, otherwise the hole result set of the specified operation.


-name <propertyname> Specifies the value of the name-attribute for the newcreated property.

Obligatory

-nominalvalue <nominalvalue>

Specifies the nominal value of the new created property.

Voluntary

-type <ifc-type> Specifies the type of the value of the new created property. Use "boolean" for IfcBoolean, "number" for IfcReal or "string" for IfcText.

Obligatory when nominal value used

<-description <description>>

Sets the description of the new created entity to the given text.

Voluntary


2017-02-08

Example: Property creation and insertion

Note: Since the operations work on the data set specified by the level it is necessary to add one everytime to use the right dataset.

As an alternative it is possible to specify a file storing the property definitions. The file must be an CSV2 file of following schema:

<name>,<,|[<nominalvalue>,<type >]>,[description] <name>,<,|[<nominalvalue>,<type >]>,[description] ... <name>,<,|[<nominalvalue>,<type >]>,[description]

The file is used with following syntax:

insert into <-type <specifier(s)...> |-guid <globalid(s)...> |-tuid <userid(s)...>>+ new property file <file -path>



<file-path> Specifies the file to load by its path. Obligatory

Example: example CSV file

These are the same values as used in the previous example.

Note: All commas must be removed in the entries besides those separating the columns. For this example, the CSV file is stored as "/home/username/csv".

2 Comma-Separated-Value

01: #create a propertyset

02: ~add entity "Ifcpropertyset" "Produktvalues" -tuid "productval1"

03: #create a new property and insert it into the previously created propertyset

04: ~~insert into -tuid "productval1" new property -name "Costs" -nominalvalue "80" -

type "string"

-description "unit:e/ mˆ2 ,Comment:projectrelated"

05: #create another property and insert it into the created propertyset

06: ~~~insert into -tuid "productval1" new property -name "Thermal resistence" -

nominalvalue "0.26" -type "number" -description "unit:W/mˆ2,Comment:http://bla.html"

07: #insert the created and modified propertyset into the entities given by guid

08: ~~~~insert into -guid "1Ug64M4Wf8" "0ykykd6l5Euw" propertyset -tuid "productval1"

01: Costs,80,string,unit:e/ mˆ2 Comment:projectrelated

02: Thermal resistence,0.26,number, unit:W/mˆ2 Comment:http://bla.html


2017-02-08

Example: example CSV usage

10.1.7.5 Update entities

To update an attribute defined in IFC, the entity updater is applicable. Therefore, the following command is used: update entity <-type <specifier(s)...> |-guid <globalid(s)...> |-tuid <userid(s)...>>+

<attribute <attribute-name> <value>>+

Note: In the filter file, an update must be on one line.


-type <specifier(s)...> Specifies the entities of which the attribute shall be updated by the ifc type (e.g. "Ifcwall).


-guid <globalid(s)...> Specifies the entities of which the attribute shall be updated by the global id.


-tuid <userid(s)...> Specifies the entities of which the attribute shall be updated by the global id.


<attribute-name> The attribute name which shall be updated to the following specified value.

Obligatory

<value> The value to which the attribute shall be updated.

Obligatory

Note: The order of the operations is important.

Example: Entity update usage

In the case of the previous listing, the result will contain all walls, where the wall with the global id "1Ug64M4Wf8" has the new name "test". While the name of the updated wall in following listing will be overridden by the last statement, because the last filter works on the original data set. The window filter has no effect on the update.

01: #create a propertyset

02: _add entity "Ifcpropertyset" "Produktvalues" -tuid "productval1"

03: #create new properties from the csv file and insert them into the previously

created propertyset

04: ~~insert into -tuid "productval1" new property file "home/username/csv"

05: #insert the created and modified propertyset into the entities given by guid

06: ~~~~insert into -guid "1Ug64M4Wf8" "0ykykd6l5Euw" propertyset -tuid "productval1"

01: #get all walls from the input ifc file


03: #rename the wall with id "1Ug64M4Wf8" from the filter result

04: ~~update entity -guid "1Ug64M4Wf8" attribute "name" "RenamedWall"

05: #add all windows to the result



2017-02-08

Example: entity update usage

10.1.7.6 Delete Additionally to adding entities, the deletion of them is also possible. Therefore, following command is used: delete entity <-type <specifier(s)...> |-guid <globalid(s)...> |-tuid <userid(s)...> |-name <name ( s )...>>+

Parameter Description Declaration -type <specifier(s)...>

Specifies the entities which shall be deleted by the ifc type (e.g. "Ifcwall).

Either this, guid, tuid or name obligatory

-guid <globalid(s)...>

Specifies the entities which shall be deleted by the global id.

Either this, type, tuid or name obligatory

-tuid <userid(s)...> Specifies the entities which shall be deleted by the temporal user id. The user id is defined at the definition of operations in the filter file, whose support a user id. In case of add, only the created entity will be deleted, otherwise the hole result set of the specified operation.


-name <name(s)...> Specifies the entities which shall be deleted by the value of the name attribute (should be used for properties and quantities as they do not have id’s.


10.1.8 Regular Expressions

Regular Expressions are taken from the official Java 8 API documentatation [37]. There, all expressions, which can be used in Java with the java.util.regex.Pattern class are supported.

Summary of regular-expression constructs Construct Matches Characters x The character x \\ The backslash character \0n The character with octal value 0n (0 <= n <= 7) \0nn The character with octal value 0nn (0 <= n <= 7) \0mnn The character with octal value 0mnn (0 <= m <= 3, 0 <= n <= 7)

01: #get all walls from the input ifc file


03: #rename the wall with id "1Ug64M4Wf8" from the filter result

04: ~update entity -guid "1Ug64M4Wf8" attribute "name" "RenamedWall"

05: #add all walls from the input file to the result


07: #add all windows to the result



2017-02-08

\xhh The character with hexadecimal value 0xhh \uhhhh The character with hexadecimal value 0xhhhh \x{h...h} The character with hexadecimal value 0xh...h

(Character.MIN_CODE_POINT<=0xh...h <= Character.MAX_CODE_POINT)

\t The tab character ('\u0009') \n The newline (line feed) character ('\u000A') \r The carriage-return character ('\u000D') \f The form-feed character ('\u000C') \a The alert (bell) character ('\u0007') \e The escape character ('\u001B') \cx The control character corresponding to x Character classes [abc] a, b, or c (simple class) [^abc] Any character except a, b, or c (negation) [a-zA-Z] a through z or A through Z, inclusive (range) [a-d[m-p]] a through d, or m through p: [a-dm-p] (union) [a-z&&[def]] d, e, or f (intersection) [a-z&&[^bc]] a through z, except for b and c: [ad-z] (subtraction) [a-z&&[^m-p]] a through z, and not m through p: [a-lq-z](subtraction) Predefined character classes . Any character (may or may not match line terminators) \d A digit: [0-9] \D A non-digit: [^0-9] \h A horizontal whitespace character: [

\t\xA0\u1680\u180e\u2000-\u200a\u202f\u205f\u3000] \H A non-horizontal whitespace character: [^\h] \s A whitespace character: [ \t\n\x0B\f\r] \S A non-whitespace character: [^\s] \v A vertical whitespace character:

[\n\x0B\f\r\x85\u2028\u2029] \V A non-vertical whitespace character: [^\v] \w A word character: [a-zA-Z_0-9] POSIX character classes (US-ASCII only) \p{Lower} A lower-case alphabetic character: [a-z] \p{Upper} An upper-case alphabetic character:[A-Z] \p{ASCII} All ASCII:[\x00-\x7F] \p{Alpha} An alphabetic character:[\p{Lower}\p{Upper}] \p{Digit} A decimal digit: [0-9]


2017-02-08

\p{Alnum} An alphanumeric character:[\p{Alpha}\p{Digit}] \p{Punct} Punctuation: One of !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~ \p{Graph} A visible character: [\p{Alnum}\p{Punct}] \p{Print} A printable character: [\p{Graph}\x20] \p{Blank} A space or a tab: [ \t] \p{Cntrl} A control character: [\x00-\x1F\x7F] \p{XDigit} A hexadecimal digit: [0-9a-fA-F] \p{Space} A whitespace character: [ \t\n\x0B\f\r]

java.lang.Character classes (simple java character type) \p{javaLowerCase} Equivalent to java.lang.Character.isLowerCase() \p{javaUpperCase} Equivalent to java.lang.Character.isUpperCase() \p{javaWhitespace} Equivalent to java.lang.Character.isWhitespace() \p{javaMirrored} Equivalent to java.lang.Character.isMirrored()

Classes for Unicode scripts, blocks, categories and binary properties

\p{IsLatin} A Latin script character (script) \p{InGreek} A character in the Greek block (block) \p{Lu} An uppercase letter (category) \p{IsAlphabetic} An alphabetic character (binary property) \p{Sc} A currency symbol \P{InGreek} Any character except one in the Greek block (negation)

[\p{L}&&[^\p{Lu}]] Any letter except an uppercase letter (subtraction)

Boundary matchers ^ The beginning of a line $ The end of a line \b A word boundary \B A non-word boundary \A The beginning of the input \G The end of the previous match \Z The end of the input but for the final terminator, if any \z The end of the input Linebreak matcher \R Any Unicode linebreak sequence, is equivalent to \u000D\u000A|

[\u000A\u000B\u000C\u000D\u0085\u2028\u2029

2017-02-08

10.2 Link Model XML Schema Specifications

(see also: https://github.com/BuildingSMART/MMC) <?xml version="1.0" encoding="utf-8" ?> 

<schema elementFormDefault="qualified" targetNamespace="http://www.buildingsmart.org/multi-model/LinkModel/2.0.0" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:MML="http://www.buildingsmart.org/multi-model/LinkModel/2.0.0">

<complexType name="LinkModel_Type"> <complexContent> <extension base="MML:MetaData_Type"> <sequence> <element name="Link" type="MML:Link_Type" minOccurs="1" maxOccurs="unbounded" > <annotation> <documentation> A link interrelates minimum 2 elements from minimum 2 application models.</documentation> </annotation> </element> </sequence> <attribute name="formatVersion" use="required"> <annotation> <documentation> Version of this Schema. It must correspond to the version path segment of this target namespace. </documentation> </annotation> <simpleType> <restriction base="string"> <enumeration value="2.0.0"></enumeration> </restriction> </simpleType> </attribute> </extension> </complexContent> </complexType> <complexType abstract="true" name="MetaData_Type"> <sequence> <element name="MetaData" maxOccurs="1" minOccurs="0"> <annotation> <documentation> Optional collection of meta data for a certain element. </documentation> </annotation> <complexType> <sequence> <element name="Meta" type="MML:Meta_Type" maxOccurs="unbounded" minOccurs="1"> <annotation> <documentation>Meta data entry. The occurence and semantics of meta data are externally defined in an application area document (multi-model domain). </documentation>


2017-02-08

</annotation> </element> </sequence> </complexType></element> </sequence> </complexType> <complexType name="Link_Type"> <complexContent> <extension base="MML:MetaData_Type"> <sequence> <element name="Relatum" minOccurs="2" maxOccurs="unbounded" type="MML:Relatum_Type"> <annotation> <documentation> Relatum is the representation of one data element from an arbitrary application model, which is part of a multi valued relation: the link. </documentation> </annotation> </element> </sequence> </extension> </complexContent> </complexType> <complexType name="Meta_Type"> <attribute name="k" type="string" use="required" > <annotation> <documentation>Key of this meta data entry. To keep link document sizes as small as possible, this attribute name is just a single letter. If a category is defined for this entry, the key must be unique within those entries of this MetaData collection, which have the same category. Otherwise the entry belongs to the virtual **anonymous** category and the key must be unique within all the **anonymous** category entries of this MetaData collection. </documentation> </annotation> </attribute> <attribute name="v" type="string" use="required" > <annotation> <documentation>Data value of this meta data entry. </documentation> </annotation> </attribute> <attribute name="t" default="xs:string" type="string" use="optional" > <annotation> <documentation>The optional data type of this meta data entry. If no type is given, values shall be treated as Strings. If a type is defined for this entry, the value must be in a format which corresponds to the given type. Valid meta data types are externally defined in an application area document (multi-model domain). If no other agreement is made, type names, their semantics and the corresponding formats must conform to the XSD-built in types. See http://www.w3.org/TR/xmlschema-2/#built-in-datatypes </documentation> </annotation> </attribute>


2017-02-08

<attribute name="c" type="string" use="optional"> <annotation> <documentation> Optional category of this meta data entry. Categories group meta data entries. Their work as a namespace for their keys. If no category is given, the entry belongs to the virtual **anonymous** category. Meta data categories are externally defined in an application area document (multi-model domain). </documentation> </annotation></attribute> </complexType> <element name="LinkModel" type="MML:LinkModel_Type"> <annotation> <documentation>This is the root element of a link model document. </documentation> </annotation> </element> <complexType name="Relatum_Type"> <complexContent> <extension base="MML:MetaData_Type"> <sequence> <element name="Rate" maxOccurs="unbounded" minOccurs="0"> <annotation> <documentation> Optional rating, quantification or weighing of this relatum against others. The occurence and semantics of rates are externally defined in an appl. area document (multi-model domain). </documentation> </annotation> <complexType> <attribute name="t" type="string" use="required"> <annotation> <documentation>Type of this rate. The type identifies the kind of this rate, e. g. amount factor. Valid rate type identifiers are externally defined in an application area document (multi-model domain). </documentation> </annotation> </attribute> <attribute name="v" type="string" use="required"> <annotation> <documentation>Value of this rate. The value is the data - the qualitative or quantitative amount or specification - of this rate, e. g. a numeric factor, a boolean flag or a date. Valid values of a certain type are externally defined in an application area document (multi-model domain). </documentation> </annotation> </attribute> <attribute name="m" type="string" use="required"> <annotation> <documentation> Target application model of this rate.


2017-02-08

The reference to an ID of an application model which this rate refers to. Valid values of a certain type are externally defined in an application area document (multi-model domain). </documentation> </annotation> </attribute> </complexType> </element> </sequence> <attribute use="required" name="id" type="string"> <annotation> <documentation> Mandatory ID of the application model's data element. </documentation> </annotation> </attribute> <attribute use="required" name="m" type="string"> <annotation> <documentation> Mandatory reference to the application model ID of this relatum in the parent multi-model container document. </documentation> </annotation> </attribute> <attribute use="optional" name="f" type="string"> <annotation> <documentation> Reference to the data format ID of this relatum in the parent multi-model container document. If there are more than one data formats of the application model, then this information is mandatory, otherwise it is optional. To keep link document sizes as small as possible, this attribute name is just a single letter. </documentation> </annotation> </attribute> <attribute use="optional" name="r" type="string"> <annotation> <documentation> Reference to the data resource ID of this relatum in the parent multi-model container document. If there’re more than one data resources of the appl. model and the element IDs are not guaranteed to be unique over all these data resources (thus the IDs are only unique within each resource), then this information is mandatory, otherwise it is optional. To keep link document sizes as small as possible, this attribute name is just a single letter. </documentation> </annotation> </attribute> </extension> </complexContent> </complexType> </schema>

2017-02-08

<?xml version="1.0" encoding="utf-8"?> 

<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:MMC="http://www.buildingsmart.org/multi-model/MMContainer/2.0.0" targetNamespace="http://www.buildingsmart.org/multi-model/MMContainer/2.0.0" elementFormDefault="qualified">

<element name="MultiModel" type="MMC:MultiModel_Type"> <annotation> <documentation>The Root element of a multi-model container. </documentation> </annotation> </element> <complexType name="LinkModel_Type"> <complexContent> <extension base="MMC:MetaData_Type"> <sequence> <element name="LinkedModel" type="string" minOccurs="2" maxOccurs="unbounded"> <annotation> <documentation>The application models, whose elements are referenced in this link model, are listed here for convenience. Each application model is indicated by its ID. </documentation> </annotation> </element> </sequence> <attribute name="location" type="anyURI" use="required"> <annotation> <documentation> This URI specifies the location of this link model's external resource. An absolute URI specifies a container external resource, e.g. a remote server. A relative URI specifies a bundled resource inside the multi-model container relative to this document's location. </documentation> </annotation> </attribute> </extension> </complexContent> </complexType> <complexType name="ApplicationModel_Type"> <complexContent> <extension base="MMC:MetaData_Type"> <sequence> <element name="ModelData" type="MMC:ModelData_Type" minOccurs="1" maxOccurs="unbounded"> <annotation> <documentation> Each application model may be represented by different, alternative data formats which contain semantically identical data. </documentation> </annotation> <unique name="UniqueResourceID"> <selector xpath="MMC:DataRessource"/> <field xpath="@id"/> </unique>


2017-02-08

</element> </sequence> <attribute name="id" type="string" use="required"> <annotation> <documentation> ID of the overall application model; unique within the container. </documentation> </annotation> </attribute> <attribute name="modelType" type="string" use="required"> <annotation> <documentation> The model type identifies the domain of this appl. model, e. g. time schedule, product model or cost model. Valid model type identifiers are externally defined in an application area document (multi-model domain). </documentation> </annotation> </attribute> </extension> </complexContent> </complexType> <complexType name="DataRessource_Type"> <annotation> <documentation/> </annotation> <complexContent> <extension base="MMC:MetaData_Type"> <attribute name="id" type="string" use="required"> <annotation> <documentation> ID of this application model's data resource. The ID must be unique for all data resources of this data format representation. </documentation> </annotation> </attribute> <attribute name="location" type="anyURI" use="required"> <annotation> <documentation> URI specifying the location of this application model's external resource. An absolute URI specifies a container external resource, e.g. a remote server. A relative URI specifies a bundled resource inside the multi-model container relative to this document's location. </documentation> </annotation> </attribute> </extension> </complexContent> </complexType> <complexType name="MetaData_Type" abstract="true"> <sequence> <element name="MetaData" minOccurs="0" maxOccurs="1"> <annotation> <documentation> Optional collection of meta data for a certain element.</documentation>


2017-02-08

</annotation> <complexType> <sequence> <element name="Meta" type="MMC:Meta_Type" minOccurs="1" maxOccurs="unbounded"> <annotation> <documentation>A meta data entry. The occurence and semantics of meta data are externally defined in an application area document (multi-model domain). The management of application areas is not part of this standard. </documentation> </annotation> </element> </sequence> </complexType> </element> </sequence> </complexType> <complexType name="Meta_Type"> <attribute name="key" type="string" use="required"> <annotation> <documentation>Key of this meta data entry. If a category is defined for this entry, the key must be unique within those entries of this MetaData collection, which have the same category. Otherwise, the entry belongs to the virtual **anonymous** category and the key must be unique within all the **anonymous** category entries of this MetaData collection. </documentation> </annotation> </attribute> <attribute name="value" type="string" use="required"> <annotation> <documentation>Data value of this meta data entry. If a type is defined for this entry, the value must be in a format which corresponds to the given type. </documentation> </annotation> </attribute> <attribute name="type" type="string" use="optional" default="xs:string"> <annotation> <documentation>The optional data type of this meta data entry. If no type is given, values shall be treated as strings. If a type is defined for this entry, the value must be in a format which corresponds to the given type. Valid meta data types are externally defined in an application area document (multi-model domain). If no other agreement is made, type names, their semantics and the corresponding formats must conform to the XSD-built in types. See http://www.w3.org/TR/xmlschema-2/#built-in-datatypes </documentation> </annotation> </attribute> <attribute name="category" type="string" use="optional"> <annotation> <documentation>Optional category of this meta data entry. Categories group meta data entries. They work as a namespace for their keys. If no category is given, the entry belongs to


2017-02-08

the virtual **anonymous** category. Meta data categories are externally defined in an application area document (multi-model domain). </documentation> </annotation> </attribute> </complexType> <complexType name="MultiModel_Type"> <complexContent> <extension base="MMC:MetaData_Type"> <sequence> <element name="ApplicationModels" minOccurs="1" maxOccurs="1"> <annotation> <documentation> Collection of application models. Always present with minimum 1 entry. </documentation> </annotation> <complexType> <sequence> <element name="ApplicationModel" type="MMC:ApplicationModel_Type" minOccurs="1" maxOccurs="unbounded"> <annotation> <documentation> Specific Application Model with agreed data structure and semantics. In particular, application models consist of data elements which can be referenced by an element ID. An elemnt ID is guaranteed to be unique within one data resource. </documentation> </annotation> </element> </sequence> </complexType> </element> <element name="LinkModels" minOccurs="0" maxOccurs="1"> <annotation> <documentation>Optional collection of link models. </documentation> </annotation> <complexType> <sequence> <element name="LinkModel" type="MMC:LinkModel_Type" minOccurs="1" maxOccurs="unbounded"> <annotation> <documentation> A link model of this multi-model. The data is located in an external resource. </documentation> </annotation> </element> </sequence> </complexType> </element> </sequence> <attribute name="uuid" type="string" use="required">


2017-02-08

<annotation> <documentation> This is the Universal Unique Identifier of the Multi-Model Container. It conforms to the Internet Engineering Task Force (IETF) RFC 4122. See https://tools.ietf.org/html/rfc4122 </documentation> </annotation> </attribute> <attribute name="formatVersion" use="required"> <annotation> <documentation> Version of this Schema. It must correspond to the version path segment of this target namespace. </documentation> </annotation> <simpleType> <restriction base="string"> <enumeration value="2.0.0"></enumeration> </restriction> </simpleType> </attribute> <attribute name="mmDomain" type="anyURI" use="optional"> <annotation> <documentation> Application area of the multi-model, e. g. tender and bid. The provided URI should - but not have to - point to a public document that describes the application area in detail, especially the semantics and constraints of allowed application models, their data formats, the structure and location of the data element's IDs as well as the multiplicity and semantics of links and their rates. When a private aplication area is used, the provided URI must be distinct from other existing - notably public standards - application area URIs. </documentation> </annotation> </attribute> </extension> </complexContent> </complexType> <complexType name="ModelData_Type"> <annotation><documentation/></annotation> <complexContent> <extension base="MMC:MetaData_Type"> <sequence> <element name="DataRessource" type="MMC:DataRessource_Type" minOccurs="1" maxOccurs="unbounded"> <annotation> <documentation> The data of an application model may be distributed among several data resources. It must be guaranteed, that these data resources contain semantically disjunct data and in conjunction contain semantically complete data. An element ID is guaranteed to be unique only within each data resource. </documentation> </annotation> </element>


2017-02-08

</sequence> <attribute name="id" type="string" use="required"> <annotation> <documentation> ID of this application model's data format representation. The ID must be unique for all data format representations of this application model. </documentation> </annotation> </attribute> <attribute name="formatType" type="string" use="required"> <annotation> <documentation> The format type identifies the data format of this application model's representation. E. g. a construction product model may be represented by IFC (SPF), ifcXML, gbXML or others. Valid format type identifiers are externally defined in an application area document (multi-model domain). </documentation> </annotation> </attribute> <attribute name="formatVersion" type="string" use="optional"> <annotation> <documentation> The format version identifies the data formats version of this application model's representation. E. g. the construction product model data format IFC is available in versions 2x3 and 4 at the time of this standard definition. Valid format version identifiers are externally defined in an application area document (multi-model domain). </documentation> </annotation> </attribute> </extension> </complexContent> </complexType> </schema>

d4.2 multi-model specification and domain model filtering pu · 2018-01-11 · multi-model...

Documents