EN 17549-2:2023

SLOVENSKI STANDARD
01-julij-2023
Informacijsko modeliranje gradenj - Podatkovna struktura za izmenjavo
podatkovnih predlog in tehničnih listov gradnikov, ki temelji na EN ISO 16739-1 - 2.
del: Zahteve in prilagodljivi gradniki
Building information modelling - Information structure based on EN ISO 16739 1 to
exchange data templates and data sheets for construction objects - Part 2: Configurable
construction objects and requirements
Building Information Modeling - Datenstruktur für den Austausch von
Produktdatenvorlagen und Produktdatenblättern nach EN-ISO 16739-1 - Teil 2:
Anforderungen und konfigurierbare Produkte
Modélisation des informations de la construction (BIM) - Structure des informations
basée sur l’EN ISO 16739-1 pour l’échange de modèles de données et de feuilles de
données pour les objets de construction - Partie 2 : Objets de construction configurables
et exigences
Ta slovenski standard je istoveten z: EN 17549-2:2023
ICS:
35.240.67 Uporabniške rešitve IT v IT applications in building
gradbeništvu and construction industry
91.010.01 Gradbeništvo na splošno Construction industry in
general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 17549-2
EUROPEAN STANDARD
NORME EUROPÉENNE
May 2023
EUROPÄISCHE NORM
ICS 35.240.67
English Version
Building information modelling - Information structure
based on EN ISO 16739 1 to exchange data templates and
data sheets for construction objects - Part 2: Configurable
construction objects and requirements
Modélisation des informations de la construction (BIM) Building Information Modeling - Datenstruktur für den
- Structure des informations basée sur l'EN ISO 16739- Austausch von Produktdatenvorlagen und
1:2020 pour l'échange de modèles de données et de Produktdatenblättern nach EN-ISO 16739-1 - Teil 2:
feuilles de données pour les objets de construction - Anforderungen und konfigurierbare Produkte
Partie 2 : Objets de construction configurables et
exigences
This European Standard was approved by CEN on 27 February 2023.

This European Standard was corrected and reissued by the CEN-CENELEC Management Centre on 10 May 2023.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
C O M I T É E U R O P É E N D E N O R M A L I S A T I O N

E U R O P Ä I S C H E S K O M I T E E F Ü R N O R M U N G

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2023 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 17549-2:2023 E
worldwide for CEN national Members.

Contents Page
European foreword . 5
Introduction . 6
1 Scope . 9
2 Normative references . 9
3 Terms and definitions . 9
3.1 Terms and definitions . 9
3.2 Abbreviated terms . 11
4 Fundamental concepts and assumptions . 11
4.1 General. 11
4.2 Units . 18
4.2.1 General. 18
4.2.2 “IfcSIUnit definition” concept . 18
4.2.3 “IfcConversionBasedUnitWithOffset definition” concept . 18
4.2.4 “UnitsInContext prohibition” concept . 19
4.2.5 “Unit explicit definition” concept . 20
4.2.6 “IfcDerivedUnit definition” concept . 20
4.3 Data dictionaries . 20
4.3.1 General. 20
4.3.2 “IfcLibraryReference identification” concept . 21
4.3.3 “IfcLibraryReference attributes” concept . 21
4.4 Properties . 22
4.4.1 General. 22
4.4.2 “IfcSimpleProperty definition” concept . 23
4.4.3 “IfcSimpleProperty unique definition” concept. 23
4.4.4 “IfcSimpleProperty in property set” concept . 24
4.4.5 “IfcProperty single, table, reference, or complex” concept . 24
4.4.6 “IfcPropertySingleValue attributes” concept . 24
4.4.7 “IfcPropertyTableValue attributes” concept . 25
4.5 Dynamic properties . 26
4.5.1 General. 26
4.5.2 “IfcPropertyReferenceValue usage” concept . 26
4.5.3 “IfcProperty dependencies” concept . 26
4.6 Sets of properties . 29
4.6.1 General. 29
4.6.2 “IfcPropertySet definition” concept . 30
4.6.3 “IfcPropertySet unique definition” concept . 30
4.6.4 “IfcPropertySet allowed elements” concept . 31
4.6.5 “IfcPropertySet attributes” concept . 31
4.7 Objects . 32
4.7.1 General. 32
4.7.2 “IfcBuildingElementProxy definition” concept . 32
4.7.3 “IfcBuildingElementProxy unique definition” concept . 32
4.7.4 “IfcBuildingElementProxy as property sets” concept . 34
4.7.5 “IfcBuildingElementProxy as a system” concept . 34
4.7.6 “IfcBuildingElementProxy attributes” concept . 35
4.8 Object types . 36
4.8.1 General . 36
4.8.2 “IfcBuildingElementProxyType definition” concept . 37
4.8.3 “IfcBuildingElementProxyType unique definition” concept . 37
4.8.4 “IfcBuildingElementProxyType as property sets” concept . 38
4.8.5 “IfcBuildingElementProxyType as a system” concept . 38
4.8.6 “ApplicableOccurrence value” concept . 39
4.8.7 “IfcBuildingElementProxyType attributes” concept . 40
4.9 Semantic relationships . 40
4.9.1 General . 40
4.9.2 “IfcGroup definition” concept . 42
4.9.3 “IfcGroup unique definition” concept . 42
4.9.4 “IfcGroup as semantic relationship” concept . 43
4.10 Constraints . 45
4.10.1 General . 45
4.10.2 “ConstraintGrade value” concept . 46
4.10.3 “IfcConstraint target” concept . 47
4.10.4 “ObjectiveQualifier value” concept . 49
4.10.5 “DataValue value” concept . 50
4.10.6 “IfcConstraint definition” concept . 50
4.10.7 “IfcObjective attributes” concept . 51
4.10.8 “IfcMetric attributes” concept . 53
4.11 Context composition . 54
4.11.1 General . 54
4.11.2 “IfcProject allowed decompositions” concept . 54
4.11.3 “IfcBuilding allowed content” concept . 55
4.11.4 “IfcProject allowed declarations” concept . 56
4.11.5 “IfcProjectLibrary allowed declarations” concept. 56
4.12 Root . 57
4.12.1 “IfcRoot attributes” concept . 57
5 Core data schemas . 57
5.1 General . 57
5.2 IfcKernel . 58
5.2.1 General . 58
5.2.2 Types . 58
5.2.3 Entities . 59
5.2.4 Functions . 105
5.2.5 Rules – IfcSingleProjectInstance – Semantic definitions at the global rule . 106
5.3 IfcControlExtension – Entities – IfcRelAssociatesConstraint . 106
5.3.1 Semantic definitions at the entity . 106
5.3.2 Inherited definitions from supertypes . 106
5.3.3 Definitions applying to CODview2 . 107
5.4 IfcProductExtension . 108
5.4.1 Entities . 108
6 Shared element data schemas . 126
6.1 General . 126
6.2 IfcSharedBldgElements . 127
6.2.1 Types . 127
6.2.2 Entities . 127
7 Domain specific data schemas . 134
8 Resource definition data schemas . 134
8.1 General. 134
8.2 IfcActorResource . 134
8.2.1 Types . 134
8.2.2 Entities . 134
8.3 IfcConstraintResource . 138
8.3.1 Types . 138
8.3.2 Entities . 139
8.4 IfcCostResource . 146
8.4.1 General. 146
8.4.2 Types . 146
8.4.3 Entities . 147
8.5 IfcDateTimeResource . 148
8.5.1 Types . 148
8.6 IfcExternalReferenceResource . 148
8.6.1 Schema definition . 148
8.6.2 Types . 149
8.6.3 Entities . 149
8.7 IfcMeasureResource . 153
8.7.1 Types . 153
8.7.2 Entities . 156
8.7.3 Functions . 163
8.8 IfcPropertyResource . 163
8.8.1 Schema definition . 163
8.8.2 Types . 164
8.8.3 Entities . 164
8.9 IfcUtilityResource . 177
8.9.1 Schema definition . 177
8.9.2 Types . 177
8.9.3 Entities . 177
Annex A (normative) Computer interpretable listings – CODview2 long form schema . 181
Annex B (informative) Examples . 182
B.1 Preliminary examples . 182
B.1.1 Dimensions and units . 182
B.1.2 Data definition and data dictionaries: Properties and construction objects . 184
B.1.3 Dependencies between properties: IfcAppliedValue . 186
B.1.4 Dependencies between properties: JavaScript . 188
B.1.5 Constraints on values: IfcConstraint . 190
B.1.6 Semantic relationships: IfcGroup. 195
B.2 Use case examples . 197
B.2.1 Using requirements . 197
B.2.2 Check of the consistency between the objects included in a project and the
requirements defined in a previous phase . 199
B.2.3 Semantic, concurrent, and iterative definition of an object during design phases . 200
B.2.4 Product catalogue . 202
B.2.5 Search in a product catalogue . 207
B.2.6 Bills of quantities (pre-design programs, technical specifications, offers) . 208
B.2.7 Procurement and product purchase . 209
Bibliography . 212

European foreword
This document (EN 17549-2:2023) has been prepared by Technical Committee CEN/TC 442 “Building
Information Modelling (BIM)”, the secretariat of which is held by SN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by November 2023, and conflicting national standards shall
be withdrawn at the latest by November 2023.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in CEN
Internal Regulation 2019, Part 3, clause 7.
SHALL is the strongest expression (Requirement)
MAY is to permit something
MUST means something to apply for legal reasons
CAN expresses a possibility
SHOULD is a recommendation
Requirements – shall, shall not
Recommendations – should, should not
Permission – may, need not
Possibility and capability – can, cannot
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the United
Kingdom.
Introduction
This document describes and explains a subset of the schema provided by EN ISO 16739-1:2020; in
technical terms, this subset is a technical Model View Definition (MVD). It is given in Annex A of this
document. It aims to set a comprehensive structure to store and exchange construction object data. This
MVD is therefore called Construction Object Data View 2 or CODview2 for short.
It is intended for software vendors for the construction sector (planning, finance, legal, procurement,
construction management, design, construction process, commissioning and handover, after sales
service, maintenance, operation, repair and improvement, demolition) as well as professionals in this
sector using their software.
While “Building information modelling — Information structure based on EN ISO 16739-1:2020 to
exchange data templates and data sheets for construction objects — Part 1” focuses on data templates
and configured construction objects, this document includes the structures that will be used to:
• link the objects and properties to their semantic definitions through data dictionaries
• express requirements and describe configurable construction objects using declarative expressions
• organize the data exchanged during construction workflows
This document does not only support data sheets based on data template as defined by EN ISO 23387 but
goes beyond that and supports any construction object based on any construction object schema that can
be described using EN ISO 12006-3:2022.
It selects a few technical IFC classes to leverage the maximum potential from Building Information
Modelling (BIM):
• It aims to provide access to dynamic construction specific semantics. For this it uses the
complementarity between the underlying EN ISO 16739-1:2020 and the EN ISO 12006-3:2022 for
data dictionaries, thereby outsourcing construction specific semantics of the schema. The use of
EN ISO 12006-3:2022 is extended to the negotiation of construction object schemas to agree on a
common language prior to data exchanges. These data exchanges can concern construction projects
as well as catalogues of construction products, see B.2.4 “Product Catalogue” and B.2.7 “Procurement
and product purchase”.
• It aims to ease concurrent engineering by allowing the expression of requirements. For this it
highlights the use of constraints especially in the perspective of data exchanges related to
construction processes (EN ISO 29481-2) and the traceability of decisions in models. These
constraints make it possible to express requests relating to construction projects or product
catalogues. At last, they may also be used to describe configurable products.
• It aims to integrate into workflows as described in EN ISO 19650-1.
These three aspects make it possible to achieve interoperability of data used in software for the
construction sector.
Thanks to CODview2 several objectives of Building Information Modelling (BIM) can be achieved:
• Less complex implementations without reduction of functionality,
• Agile integration of construction specific semantics leading to more comprehensive interoperability
for the end user,
• Support concurrent engineering by using already existing EN ISO 16739-1:2020 mechanisms.
This document enables the users of the tools based on it to:
• Use their specific semantics thanks to the use of data dictionaries,
• Express their requirements and proposals related to construction objects,
• Describe parametric construction objects as well as configurable construction objects or products,
• Import and export construction object data in BIM at any stage of the project (inception, brief, design,
production, demolition) as well as during operation,
• Describe bills of quantities (pre-design programs, technical specifications, offers),
• Call for tender and purchase construction objects,
• Check that the construction objects included in a project meet previously described requirements,
• Describe product catalogues.
These scenarios fit in the construction object models of owners, designers, builders, manufacturers, and
facility managers.
Figure 1 shows the general workflow of exchanges between actors willing to agree on a construction
object. It involves several standards (EN ISO 12006-3:2022, EN ISO 29481-2, EN ISO 19650-1). The
exchanges using CODview2 appear as CODview2 payloads in this figure.
(*) Only two actors (actor A and Actor B) are represented in this schema. However, many more actors may be involved in such an exchange. Actor C, D, E . may
also have their own requirements and participate to the exchange. Actors can be any actor of the project: clients, architects, engineers, contractors, manufacturers
... or even machines like product catalogues.
(**) In this schema actor A validates the solution. Many alternatives may exist in a real process. For example, the validation could belong to an actor C that has not
been involved in the exchange.
See “B.2.3. Semantic, concurrent, and iterative definition of an object during design phases”.
Figure 1 — General workflow of exchanges between actors willing to agree on a construction object
1 Scope
This document defines a Model View Definition (MVD) of the IFC schema defined in EN ISO 16739-1:2020.
The MVD described by this document is designated as CODview2.
This document focuses on core and resource classes and relies on external data dictionaries to describe
construction specific semantics.
NOTE 1 Core classes are those defined in EN ISO 16739-1:2020, 5.
NOTE 2 Resource classes are those defined in EN ISO 16739-1:2020, 8.
This document does not provide any construction object schema as it considers that these are already
defined in data dictionaries compliant with EN ISO 12006-3:2022.
This document focuses only on the format of the exchanged data and not on the way to process them.
CODview2 does not support the geometrical representations of construction objects but allows the
exchange of geometrical properties. These properties may be used to define geometrical representations
of construction objects.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN ISO 12006-3:2022, Building construction — Organization of information about construction works —
Part 3: Framework for object-oriented information
EN ISO 16739-1:2020, Industry Foundation Classes (IFC) for data sharing in the construction and facility
management industries — Part 1: Data schema
ISO 6707-1:2017, Building and civil engineering words — Part 1: General terms
3 Terms and definitions
For the purpose of this document, the terms and definitions given in ISO 6707-1 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• ISO Online browsing platform: available at https://www.iso.org/obp
• IEC Electropedia: available at http://www.electropedia.org
3.1 Terms and definitions
3.1.1
attribute
data element for the computer-sensible description of a property, a relation, or a class
EXAMPLE: Creation date of a class object in a computer system.
[SOURCE: ISO 22274:2013, 3.2]
3.1.2
constraint
logical expression that restricts the possible values for one or several properties
3.1.3
construction object
object of importance to the construction industry
3.1.4
data dictionary
centralized repository of data about data or data elements
EXAMPLE: Such as meaning, relationships to other data, origin, usage and format.
[SOURCE: ISO 23386:2020, modified - The words "information about data" have been replaced with "data
about data or data elements". The words "such as meaning, relationships to other data, origin, usage and
format" have been used to form an example. Note 1 to entry has been omitted.]
3.1.5
construction object model
set of data complying to a construction object schema
3.1.6
construction object schema
schema providing a data structure used to describe construction objects based on xtdSubject structure
Note 1 to entry: the xtdSubject structure is defined in ISO 12006-3:2022.
3.1.7
entity
class of information defined by common attributes and constraints
Note 1 to entry: Similar to the term "class" in common programming languages but describing data structure only
(not behavior such as methods).
Note 2 to entry: These attributes and constraints are as defined in ISO 10303-11.
[SOURCE: EN ISO 16739-1:2020]
3.1.8
model view definition
computer-interpretable definition of an exchange requirement, bound to one or more schemas
Note 1 to entry: A model view definition (MVD) is also referred to as a view definition, a subset (of a schema) and a
conformance class (CC) especially in ISO 10303.
[SOURCE: ISO 29481-1:2016, 3.16, modified - The words "specifically", "particular", have been removed.
The words "standard information schema" was replaced with "schema"]
3.1.9
object
any part of the perceivable or conceivable world
Note 1 to entry: An object is something abstract or physical toward which thought, feeling, or action is directed.
[SOURCE: EN ISO 12006-2:2020, 3.1.1]
3.1.10
object type
representation of objects that share common properties
3.1.11
product
tangible outcome of a process
[SOURCE: ISO 6707-3:2017, 3.3.1]
3.1.12
property
defined characteristic suitable for the description and differentiation of an object
[SOURCE: ISO 22274:2013, 3.25, modified - The words "the objects in a class" have been replaced with
"an object". The Example has been removed.]
3.1.13
semantic relationship
relation between concepts and between class symbols and their meanings
[SOURCE: ISO 5127:2017, 3.1.7.01]
3.2 Abbreviated terms
GUID globally unique identifier
IFC industry foundation classes
IFD international framework for dictionaries
JSON JavaScript object notation
MVD model view definition
4 Fundamental concepts and assumptions
4.1 General
This document describes and explains a technical Model View Definition (MVD) of EN ISO 16739-1:2020
given at Annex A. As such, this MVD is a subset of the entities defined in EN ISO 16739-1:2020 (IFC). It
consists of a schema defining entities, along with common concepts specifying their use for particular
scenarios.
This clause defines common concepts, which are applied to entities having specific use. Each concept is
described by an instance diagram of entities and attributes, with constraints and parameters set for
particular attributes and entities. Various entities within this schema reference such concepts and adapt
them for particular use.
The entities defined in CODview2 shall be used to store and exchange data related to construction as a
process or as the result of this process. This includes data describing:
• construction objects, whether objects or object types,
• configurable construction objects,
• requirements relating to objects and object types.
The corresponding data shall be structured following a construction object schema defined in a data
dictionary conforming to EN ISO 12006-3:2022.
All data shall be defined in a data dictionary conforming to EN ISO 12006-3:2022.
CODview2 does not provide any entity with construction specific semantics and external data
dictionaries based on EN ISO 12006-3:2022 are unique sources of construction semantics.
EN ISO 12006-3:2022 data dictionaries are used to link to the construction specific definitions of:
• properties,
• property definition constraints,
• groups of properties,
• groups of groups,
• semantic relationships between groups.
Such links are defined using IfcLibraryReference which contain the GUIDs identifying the definitions.
This document selects this mechanism to refer to elements of data dictionaries. Hence, IFC template
classes, IfcPropertyTemplate and IfcPropertySetTemplate, are not part of CODview2 and shall not be used.
NOTE 1 If needed, it might be useful to make a copy of the definitions referenced in the CODview2 dataset using
the data schema defined in EN ISO 12006-3:2022. For example, when the exchanged data are parts of a contract this
copy can be included in the data exchange. In the same way, if the long-term existence of online data dictionaries is
a potential problem, this copy can be kept as a backup.
NOTE 2 For example, regulatory constraints are situation specific constraints. Currently it is not possible to
describe situation specific constraints in data dictionaries. On the other hand, it is possible to define restrictions on
the possible values of the properties by lists or intervals. Such restrictions are called “definition constraints” to
distinguish them from situation specific constraints.
The diagram below, see Figure 2, provides a high-level representation of the Construction Object Data
View 2 (CODview2) global schema. It presents the main concepts underlying this document. They are
described in more details in this clause.

Figure 2 — High-level representation of the CODview2 global schema
When addressing specific goals as descriptions and exchanges of catalogues of products, this schema may
be reduced.
For example, in the case of product catalogues, there are only object types because the actual objects
belong to the projects, see Figure 3.

Figure 3 — High level representation of the CODview2 schema for product catalogues
The relationships between the entities defined by EN ISO 12006-3:2022 and CODview2 entities are
described by the 5 following diagrams.
Figure 4 shows an example in which a small fraction of a heating system is modelled. In this example, the
heating system consists of two components, a radiator, and a controller. The radiator is driven by the
controller which is indicated in the model by the is-driven-by relationship. This relationship is bound to
the radiator, in other contexts it might be not useful. Only the radiator is further specified in the model.
There are two groups of properties, geometric and thermal properties, and two examples for the thermal
properties are given, the water input temperature, which is constraint to be in the range of 0 °C and 70 °C,
and the performance class with the allowed values A, B, and C. The constraint applied to the water input
temperature property is a specific situation constraint related to the project. It shall not be described in
a dictionary, but only in the project model. Conversely, the constraint applied to the performance class
property is a definition constraint. It shall be described in a dictionary.
Figure 4 — Simplified example of a system
This example is modelled in Figure 5 in a data dictionary according to EN ISO 12006-3:2022. The heating
system and its components are represented by entities of type xtdSubject which are connected by
relationship entities of type xtdRelationshipToSubject. The boxes with an italic text represent the
attributes of the elements that implement these connections. The connection of the radiator to the
controller is realized by a semantic relationship, which is related to a relationship object defining what
“is driven by” means and defines the contex
...