PRIVATE CIRCULATION

B/555_19_0339
For comment - Action Due Date: 2020/01/12

CEN/TC 442
Date: 2019-12-02

TC 442 WI 00442024
CEN/TC 442

Secretariat: SN

Guideline for the implementation of BIM Execution Plans (BEP) and

Exchange Information Requirements (EIR) on European level based on EN
ISO 19650-1 and -2 — — —
Leitfaden für die Implementierung von BIM Abwicklungsplänen (BIM Execution Plans BEP) und Austausch-
Informationsanforderungen (Exchange information requirements EIR) auf europäischer Ebene basierend auf
EN ISO 19650-1 und -2 — — —

Guide pour la mise en œuvre des plans d’exécution BIM (BIM Execution Plans BEP) et des exigences en matière
d’échange (Exchange information requirements EIR) au niveau européen sur la base des normes EN ISO 19650-
1 et -2 — —

ICS:

Descriptors:

Document type: Technical Report

Document subtype:
Document stage: Working Document
Document language: E

STD Version 2.9a

TC 442 WI 00442024:2019 (E)

Contents
Page

European foreword....................................................................................................................................................... 4
1 Scope .................................................................................................................................................................... 4
1.1 The tendering process of Information Requirement ......................................................................... 4
1.2 The Information Requirement Appointment........................................................................................ 4
2 Normative references .................................................................................................................................... 5
3 Terms and definitions ................................................................................................................................... 6
4 Exchange Information Requirement (EIR) ............................................................................................ 6
4.1 Information Requirement Schedule......................................................................................................... 6
4.2 Exchange Information Requirements Schedule (EIRS) ..................................................................... 7
4.3 Level of Information Need............................................................................................................................ 7
4.4 Establish the acceptance criteria for each information requirement.......................................... 7
4.4.1 Acceptance criteria ......................................................................................................................................... 7
4.4.2 Project's Information Standard ................................................................................................................. 8
4.4.3 Project’s Information Production Methods and Procedures .......................................................... 8
4.4.4 Project's Reference Information and Shared Resources .................................................................. 8
4.5 Supporting Information ................................................................................................................................ 8
4.6 Project’s information delivery milestones ............................................................................................ 8
5 Pre-appointment BIM Execution Plan ..................................................................................................... 9
5.1 Information Management Functions........................................................................................................ 9
5.2 Information Delivery Strategy................................................................................................................. 10
5.3 Federation Strategy ..................................................................................................................................... 10
5.4 High-level Responsibility Matrix ............................................................................................................ 10
5.5 Project’s information production methods and procedures........................................................ 11
5.6 Project’s information standard ............................................................................................................... 11
5.7 Schedule of software ................................................................................................................................... 11
6 Information Management Process - Appointment ........................................................................... 11
6.1 BIM execution plan ...................................................................................................................................... 11
6.2 Detailed Responsibility Matrix................................................................................................................ 11
6.3 Task Information Delivery plan(s) ........................................................................................................ 12
6.4 Master Information Delivery Plan ......................................................................................................... 12
(informative) Templates supporting EN/ISO 19650-2 .............................................................. 13
(informative) Acceptance criteria examples (recommended best practice) ..................... 14
B.1 General ............................................................................................................................................................. 14
B.2 Model geometry ............................................................................................................................................ 14
B.3 General model breakdown structure – naming and coding ......................................................... 15
B.4 Object identification.................................................................................................................................... 15
B.4.1 Object Naming ............................................................................................................................................... 15
B.4.2 Object Type Code .......................................................................................................................................... 15
B.4.3 Descriptive Name ......................................................................................................................................... 15
B.4.4 Object Naming in IFC ................................................................................................................................... 15
B.4.5 Methods for Object Type Code ................................................................................................................. 15
B.5 Rules for establishing new IFC property sets..................................................................................... 16

2
 TC 442 WI 00442024:2019 (E)

B.6 Rules for establishing new IFC property sets ..................................................................................... 16

B.6.1 User-defined property set prefix ............................................................................................................ 16
B.6.2 User-defined property sets ....................................................................................................................... 16
B.6.3 User-defined properties ............................................................................................................................. 16
B.7 Rules for how to differ between properties for design requirement and object type
performance ................................................................................................................................................... 16
B.8 Process Status Codes ................................................................................................................................... 17
(informative) Application of methodology and templates ........................................................ 19
Bibliography ................................................................................................................................................................. 20

3
TC 442 WI 00442024:2019 (E)

European foreword

This document (TC 442 WI 00442024) has been prepared by Technical Committee CEN/TC 442
“Building Information Modelling (BIM)”, the secretariat of which is held by SN.

This document is a working document.

Due to the content of Annex A also contains many templates that can´t be shown in the current output
format, an xlsx-file has been embedded in the pdf-document. This xlsx-file is also part of the current
Technical Report.

1 Scope
This Technical Report operationalises the tendering and appointment process of information deliveries
as specified in EN/ISO 19650-2. This report does not cover all clauses of EN/ISO 291650-2, it's main goal
is to provide templates and guidance for all activities conditioning specification of requirements and
deliveries in the production of Exchange Information Requirements and BIM Execution Plan as described
in EN/ISO 19650-2:2018, chapter 5.2.1, 5.3.2, and 5.4 (see Annex A for which part of EN/ISO 19650-2 is
supported by templates). The workflow for appointing information deliveries as described in EN/ISO
19650-2 is as follows, see figure 1:

1.1 The tendering process of Information Requirement

— The appointing party establish an Exchange Information Requirement (EIR) based on the
Organisational Information requirement (OIR), Asset Information Requirement (AIR) and Project
Information Requirement (PIR), see EN/ISO 19650-1:2018, clause 5.1, chapter 2. The requirements
for the EIR are specified in EN/ISO 19650-2:2018, chapter 5.2.1.

— The potential lead appointing parties respond to the EIR with a BIM Execution Plan (pre-
appointment). The minimal requirements to the pre-appointment BIM Execution Plan are specified
in EN/ISO 19650-2:2018, chapter 5.3.2.

1.2 The Information Requirement Appointment

— When the lead appointed party is selected the Lead Appointed Party confirms the BIM Execution Plan
and provides a defined set of information about the execution of the deliveries within his perimeter
of responsibility. The minimal requirements to the appointment BIM Execution Plan are specified in
EN/ISO 19650-2:2018, chapter 5.4. The detailing of the (pre-apppointment) BIM Execution Plan
depends on the project specific tendering process. If more than one lead appointed party is appointed
the collaborative aspects of the BIM Execution Plan can´t be specified prior to appointment and will
be amended during appointment or defined (post-appointment) in the Master Information Delivery
Plan (MIDP) and the Task Information Delivery Plan (TIDP).

4
 TC 442 WI 00442024:2019 (E)

Figure 1 — Explanation and context of the colors used for the two responsible parties in the pre-
appointment process and one responsible party in the appointment process in the templates of
Annex A

The colors of the parties in figure 1 are used in the template heading to signal whether the information
shall be provided by the Appointing Party or the Lead Appointed Party. The tasks supported by templates
and guidance in this Technical Report is written in light and dark blue while the tasks not supported by
this report is written in red.

This Technical Report provides recommended templates supporting each set of information to be
established by both the Appointing Party, Lead Appointed Party and Appointed Parties. For examples on
how to use this document, refer to Annex C.

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 19650-1, Organization of information about construction works — Information management

using building information modelling — Part 1: Concepts and Principles

EN ISO 19650-2, Organization of information about construction works — Information management

using building information modelling — Part 2: Delivery phase of the assets

5
TC 442 WI 00442024:2019 (E)

3 Terms and definitions

NOTE: it is possible to include additional terms and definitions necessary to explain the template and
guidance notes. For the purposes of this document, the following terms and definitions apply/the terms
and definitions given in EN ISO 19650-1, EN ISO 19650-2 and the following apply.

No terms and definitions are listed in this document.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

— IEC Electropedia: available at http://www.electropedia.org/

— ISO Online browsing platform: available at http://www.iso.org/obp

4 Exchange Information Requirement (EIR)

Guidance on how to use the template according to ISO 19650-2:2018, chapter 5.2.1.

Tabel 1 shows the Mapping table for requirement in EN/ISO 19650-2:2018, chapter 5.2.1 and recommended
template in this Technical Report.
Table 1 — Mapping table for requirement in EN/ISO 19650-2:2018, chapter 5.2.1 and
recommended template in this Technical Report
EN/ISO 19650-2:2018, chapter 5.2.1 Template Name

a) Information requirement Requirement/EIRS

b) Level of Information Need EIRS

c) Acceptance Criteria Acceptance Criteria

d) Supporting Information Supporting Info

e) Information delivery dates EIRS

4.1 Information Requirement Schedule

The Appointing Party establish the Information Requirement Schedule to list all applicable information
requirements and track their origin within the appointing party’s organisation.

The Appointing party is not obligated to share the Information Requirement Schedule with the
appointed parties at any time. However, it is recommended to share information requirements affecting
the delivery team’s approach.

Information Requirements are listed with the following information:

— Information reference(s):

— Provide a project specific reference for each information requirement for use in e.g. the
Information Requirement Schedule and the Information Delivery Plan.

— Optional, provide the Information Requirement’s organisation reference if existing. This makes
it easier to track the origin of the requirement.

6
 TC 442 WI 00442024:2019 (E)

— Type and owner of the requirement:

— Specify the type of the Information Requirement, either organisation (OIR), asset (AIR) or
project (PIR).

— Specify the owner of the Information Requirement. The owner is the person or part of the
organisation or project that need the information.

— Requirement summary and Description.

— Provide a summary or explanatory title and a brief description of the purpose, desired effect
and/or delivery.

4.2 Exchange Information Requirements Schedule (EIRS)

Appointing Party establish the Exchange Information Requirement Schedule to list all applicable
information requirements. The Exchange Information Requirement Schedule is provided to the potential
appointed parties.

An Information Requirements should include the following details:

— How the Information Requirement can be tracked in the Project Information Requirement (PIR)
(Optional - Not a specific ISO 19650 requirement)

— Why or what is the information needed? (Information Requirement Description)

— What is the minimum amount of information needed for the appointing party to accept the
requirement? (Level of information need)

— What conditions will be used to check the information deliverable in relation to quality,
format/presentation, etc? (Acceptance criteria)

— What supporting material is needed to produce the information? (Supporting information)

— When the information is needed? (Exchange date or frequency)

4.3 Level of Information Need

Level of Information Need is a framework which defines the extent and granularity of information.

It defines the level of information of the information deliveries being part of the information exchange
processes during the life cycle of built assets when using Building Information Modelling (BIM).

For more information on defining Level of Information Need see EN 17412.

4.4 Establish the acceptance criteria for each information requirement

4.4.1 Acceptance criteria

The ‘Acceptance criteria’ table defines the acceptance criteria documentation and their location on the
project’s common data environment. There may be accessed from the links in the table.

‘Information’ used in table ‘Acceptance criteria’ are examples and should be project specific.

7
TC 442 WI 00442024:2019 (E)

All documents shall be quality assured and delivered according to the project’s exchange information
requirements, acceptance criteria and Level of Information Need. For a document to change status from
Work In Progress to Shared, and from Shared to Published there are a quality assurance processes.

The acceptance criteria for the quality assurance process from Work in Progress to Shared is specified by
the Lead Appointed Party. The process is specified in EN ISO 19650-2:2018, chapter 5.6.4.

The acceptance criteria for the quality assurance process from Work in Progress to Shared is specified by
the Appointing Party. The process is specified in EN ISO 19650-2:2018, chapter 5.7.2.

4.4.2 Project's Information Standard

The Project’s Information Standard format is a project specific description of the exchange of information
required for the project, the means of structuring and classifying data that is most appropriate for the
project. The method to determine the level of information need most appropriate for the project and the
intended use of information during the operational phase of the asset.

Recommended best practice for model, object naming and user-defined properties as part of Appointing
Party's Project's Information Standard see Annex B.

4.4.3 Project’s Information Production Methods and Procedures

The appointing party will focus on the required information output needed. Project's Information
Production Methods and Procedures should be left to the appointed parties, but as much as possible be
developed in a collaborative manner. The appointed parties are required to describe their intended
methods and procedures.

All projects require information about existing conditions. Information on existing assets is important
background information for planning, designing and construction works and building operation. Capture
of information on existing assets may be required by the appointment. If not provided by the appointing
party, information on existing assets can be required from the appointed party as part of the information
delivery.

Other areas covered by Project’s Information Production Methods and Procedures are the generation,
review or approval of new information, the security or distribution of information, and the delivery of
information to the appointing party.

4.4.4 Project's Reference Information and Shared Resources

The appointing party refer to information and resources specified in other documents like regulations,
general design specifications etc.

4.5 Supporting Information

Predefined information specified by the Appointing Party. This is as detailed at appointment as available.
Supporting Information can be supplied by the appointing party or require the Delivery Team to supply
the information.

‘Information’ used in table ‘Supporting Info’ are examples and should be project specific.

4.6 Project’s information delivery milestones

Delivered Exchange date or frequency defines the time required to complete the appointing party’s
authorising process before delivery milestones

8
 TC 442 WI 00442024:2019 (E)

Each function is required to submit their deliverables at the date for Appointing Party Acceptance while
the date for the Information Delivery Milestone is the date of the accepted handover.

The date of the Appointing Party Acceptance is the date of the Information Delivery Milestone minus the
time required by the appointing party to quality assure the submitted Information Delivery.

This information is to populate the ‘Delivery’ table on appointment. Each accepted IR in the EIRS shall be
specified in the Information Delivery Plan (IDP).

5 Pre-appointment BIM Execution Plan

Guidance on how to use the template according to ISO 19650-2, point 5.3.2.

Tabel 2 shows the Mapping table for requirement in EN/ISO 19650-2:2018, chapter 5.3.2 and recommended
template in this Technical Report.
Table 2 — Mapping table for requirement in EN/ISO 19650-2:2018, chapter 5.3.2 and
recommended template in this Technical Report
EN/ISO 19650-2:2018, chapter 5.3.2 Template Name

a) Information Management Functions Functions

b) Information Delivery Strategy Strategy

c) Federation Strategy Federation

d) High-level Responsibility Matrix Strategy

e) Project’s information standards Acceptance Criteria

f) Acceptance Criteria Acceptance Criteria

g) Schedule of software IT Resources

5.1 Information Management Functions

Role and function of the appointed party to the Lead Appointed party is specified in the Function
schedule.

Organisational Chart

NOTE Requirement 5.3.2.b only applies to the pre-appointment BIM Execution Plan. Not all parties may be
specified yet.

— Identify all appointed parties

— Show the hierarchical structure of the delivery team’s commercial relationship.

— One lead appointed party

— Other appointed parties below.

— + an example

9
TC 442 WI 00442024:2019 (E)

5.2 Information Delivery Strategy

5.3 Federation Strategy

Federation is the aggregation of information models to describe the entire project and/or asset or part of
it. The federation strategy is an essential ingredient for the organization of the production of information
models: it relates to the tasks of the work teams within the delivery teams.

Federation strategies are important concepts in the management of federated information models. The
definition of the federation strategy is driven by the complexity of the project, the assets and the team
structure. The typology of markets is also an important input. One strategy could be to federate
information models according to, for example, disciplines, procurement, functions, systems, use cases,
geographical location, level of information need... planning. Technologies and their interoperability and
machine capabilities also influence this approach. In the context of a project or asset, it is in fact quite
common to use a combination of these approaches in a federation strategy to achieve the agreed
objectives.

It is often helpful if information models do not exceed a particular data size, otherwise they can be difficult
to open, update, export and import. The size for this varies according to computational power and
formats. Larger projects will often have to be split into two or more information models when they
become more detailed. This can be in addition to any discipline or functional reason for dividing the
project into multiple information models.

It is recommended for building disciplines (architect, structural, main contractor, …) to split the model in
vertical sections. Technical disciplines (plumbing, HVAC, electrical, ICT) are recommended to either split
vertically or into different complete systems. All disciplines contribute to and update a common list of
models.

The Federation template has 5 columns to describe the federation strategy and these should be used by
the lead appointed party as part of the pre-appointment BIM execution plan. The use of the columns is as
follows:

— Federation purpose/ Explanation: It is important to identify and explain the clear purpose of
federation. More than one purpose can be used on a project if needed.

— Information models in the selected Federation: Use this column to identify the separate
information models that are to be federated (combined).

— Name of authoring task team: Identify which task team is responsible for which information model.
It is possible for a task team to produce more than one information model in the federation - this
could depend on the scopes of the appointments made by the appointing party. It is also important
to understand that task teams are not just the design disciplines.

— Information containers in the information model (information container breakdown

structure): Provide more detail to describe the information containers that are being produced to
form each task team information model. An information model can (if required) consist of several
information containers.

5.4 High-level Responsibility Matrix

The high-level responsibility matrix communicates the first iteration of the responsibilities for the overall
task team deliveries. As a minimum the Responsible shall be assigned. The High-level Responsibility
Matrix to be developed into the Detailed Responsibility Matrix.

10
 TC 442 WI 00442024:2019 (E)

5.5 Project’s information production methods and procedures

The delivery team accept the use of the Project’s Information Production Methods and Procedures.

Exceptions, proposed alternatives and/or extensions to the Project’s Information Production Methods
and Procedures are detailed in chapter 6.3.

5.6 Project’s information standard

In this chapter the delivery team specify whether information delivery will follow the Project's
Information Standard Format as provided in the EIR

The delivery team accept the use of the Project’s Information Standard.

Exceptions, proposed alternatives and/or extensions to the Project’s Information are detailed in chapter
6.1.

Recommended best practice for model, object naming and user-defined properties as part of Lead
Appointed Party's Project's Information Standard see Annex B.

5.7 Schedule of software

The delivery team shall specific the digital technology they and associated supports will be producing the
Project information with.

6 Information Management Process - Appointment

Guidance on how to use the template according to ISO 19650-2:2018, chapter 5.4.

Tabel 3 shows the Mapping table for requirement in EN/ISO 19650-2:2018, chapter 5.4 and recommended template
in this Technical Report.
Table 3 — Mapping table for requirement in EN/ISO 19650-2:2018, chapter 5.4 and
recommended template in this Technical Report
EN/ISO 19650-2:2018, chapter 5.4 Template Name

5.4.1 BIM execution plan see chapter 5

5.4.3 Detailed Responsibility Matrix Delivery

5.4.4 Task Information Delivery plan(s) Delivery

5.4.5 Master Information Delivery Plan Delivery

6.1 BIM execution plan

BIM Execution Plan template documents are updated by the lead appointed party in agreement with
appointing party and appointed parties under the lead appointed party.

6.2 Detailed Responsibility Matrix

This matrix shall identify what task team does what element on the Breakdown Structure. This
information can be captured in the ‘Delivery’ table - Information Delivery Plan.

11
TC 442 WI 00442024:2019 (E)

Responsibility for the information requirements can be specified for functions responsible for whether
they are accountable, consulted or informed.

6.3 Task Information Delivery plan(s)

The task teams shall prepare a resource requirement schedule for each element of the Breakdown
Structure. This information can be captured in the ‘Delivery’ table - Information Delivery Plan.

Task Teams are required to identify the information elements and the development that is required to
achieve the project milestones. This information shall include dependencies and the duration that will be
required to achieve the required level of information need. This program shall include a quality
Management process.

6.4 Master Information Delivery Plan

The Lead appointed party shall prepare an overall information production programme that merges all
the TIDPs. This programme can be captured in the ‘Delivery’ table - Information Delivery Plan or on a
Gantt chart.

The example provided below;

— Small and simple structure; This example shows how information from the information
requirements and BIM execution plan can be expanded into the ‘Delivery’ table - Information
Delivery Plan. The information requirements are referred to as specific information containers
according to an agreed federation strategy.

— Large and complex structure; This example of the Information Delivery Plan (Delivery) covers all
that is required in ISO 19650 in one schedule for object information as it develops in the BIM through
design, construction to handover. It should be a holistic approach to managing the production of
information, defining what is needed, who is responsible for its delivery, how is it presented and how
defined it should be at each delivery milestone.

The Information Delivery Plan should be developed in conjunction with other documents as applications
such as the Detailed Responsibility Matrix, Task Information Delivery Plan (TIDP), and Master
Information Delivery Plan (MIDP). The Lead Appointed Party shall lead a collaborative pull planning
session with the Task Teams to determine the optimal program to achieve the project milestones

As this ‘Delivery’ table contains a large amount of detail, it would be recommended that this would not
be managed in a spreadsheet, a Gantt chart would be a more suitable form to manage the information.
Elements for Chapters 7 is also included in the Large and complex structure example.

12
 TC 442 WI 00442024:2019 (E)

(informative)

Templates supporting EN/ISO 19650-2

Due to the content of Annex A also contains many templates that can´t be shown in the current output
format, an xlsx-file has been embedded in the pdf-document. This xlsx-file is also part of the current
Technical Report.

Annex A shows, which part of EN/ISO 19650-2 is supported by templates (see "TC442-
WI00442024_BEP-EIR-Template_1WD_ws.xlsx").

13
TC 442 WI 00442024:2019 (E)

(informative)

Acceptance criteria examples (recommended best practice)

B.1 General
This Annex is in addition to requirements from EN/ISO 19650-2. It recommends best practice for model
exchange and collaboration. The best practice is based on experience with hundreds of BIM projects. The
best practice is recommended as part of the Project’s Information Standard.

B.2 Model geometry

The following recommended general, common requirements applies to the exchange model:

a) All objects shall be located according to the same common point of origin,

b) All discipline’s models shall use the same common point of origin,

c) All georeferenced models shall use the same map and height reference,

d) All models shall be oriented according the construction’s physical North-South orientation. Model
views can be rotated to fit perpendicular workspace, but not the model orientation,

e) All models shall use the same building storey structure,

f) The project team shall agree how to handle if software is incompatible with the building storey
structure,

g) All object instances shall have the correct floor property attribute according to the floor of which
they are located,

h) Objects that exist on more than one storey shall, as a default, be attached to the lowest storey where
the object originates,

i) Object instances with different properties, e.g. external/internal, loadbearing/not loadbearing

properties, shall be divided into different instances. For example, a wall passing from internal to
external shall be divided at the building envelope,

j) All objects taking up volume shall be represented in the model. Objects shall have the correct
geometrical representation of their outer boundaries,

k) Some physical objects require an assembly or maintenance space. It shall be agreed if the assembly
or maintenance space shall be modelled as part of the object or whether the extra volume is
represented visually by the discipline that creates the object,

l) All main domains (building and MEP) should deliver models on the same agreed level of maturity
for each work stage.

14
 TC 442 WI 00442024:2019 (E)

B.3 General model breakdown structure – naming and coding

Arrangements should be made about the naming and coding of the project, the building site, building(s),
storeys, zones, rooms and objects.

B.4 Object identification

Objects are packets of information describing entities such as construction products or components.

Consistent naming of objects is important for unambiguous identification of and communication about
object types and their individual properties.

B.4.1 Object Naming

There are several needs that are important to address when naming object types and object instances.
The most important are:

— names of object types and object instances that can be printed on drawings: Object type code,

— names of object types and object instances to be understood by humans: Descriptive names.

Names of object types and object instances should serve multiple purposes. They must be suitable for
printing on drawings, they must be logical so that they can be understood by humans, and they must be
unambiguous, so that it is possible to distinguish different types of objects from each other.

B.4.2 Object Type Code

Object Type Code is a logical, short name that can identify the object type. It is suitable as identification
in e.g. object libraries, type identification in cost estimation and on 2D drawings.

B.4.3 Descriptive Name

Descriptive Name is a human-readable name that describes identifying parameters of the object type
such as material, functional performance, composition etc.

B.4.4 Object Naming in IFC

The object type code and descriptive name are exchanged with IFC by the software exporting the
respective names as follows:

— Object type code in IfcRoot.Name.

— Since some modelling software use the IfcRoot.Name on object type level. The Object type code
shall be put on the objects instance level.

— Descriptive name in IfcRoot.Description.

B.4.5 Methods for Object Type Code

There are two different methods for handling properties and property sets in combination with objects:

— Method 1: one-to-one relationship between object properties and object type. Often used in later
stages of the project when all object parameters are known. Or used in value chains when designing
with predetermined products.

15
TC 442 WI 00442024:2019 (E)

— Method 2: properties can vary within object type. Often used at the start of a project when not all
object parameters are known yet.

B.5 Rules for establishing new IFC property sets

Property sets specified in the IFC model shall be used to the extend they describe the property of the
object, system or model. When the IFC standard does not provide all the information necessary in the
project, it is possible to establish new properties.

It is not allowed to establish new properties within the existing IFC property sets (Pset_ and Qto_). A new
user defined property shall only be established in a user-defined property set.

A user-defined property contains three components: A property set prefix, a property set name and a
property name. The Syntax follows the IFC model.

EXAMPLE Syntax: PREFIX_PropertySetName.PropertyName

B.6 Rules for establishing new IFC property sets

B.6.1 User-defined property set prefix

New property sets shall have an individual alphanumeric prefix of up to five digits instead of Pset_ or Qto_

It is not allowed to use ePset unless you have a formal agreement with buildingSMART International for
an IFC extension project.

It is advised that the prefix express the country and name of the organisation or the reference system (e.g.
a classification table) who has established the prefix and who maintains it.

EXAMPLE NONS_PropertySet.Property (NONS is an abbreviation of the country and the organisations

maintaining the property set. NO = Norway, NS = Standards Norway).

B.6.2 User-defined property sets

Property sets name shall clearly express the function of the set of properties.

It is possible to use established property set names as long as the prefix is not Pset_ or Qto_.

EXAMPLE NONS_Acoustic.Property (“Acoustic” is the name of the property set containing all additional
properties relevant to, in this example, Acoustic).

B.6.3 User-defined properties

The name of user-defined properties is advised to logically communicate the nature of the property.

EXAMPLE NOSSB_Acoustic.AcousticAbsorption (AcousticAbsorption is the property name for the acoustical

absorption performance of the object).

B.7 Rules for how to differ between properties for design requirement and object
type performance
It may be required to communicate both the designed requirement of an object and the actual
performance of chosen object. The IFC model only allows to communicate one property for a parameter.

Use IFC standard Pset_ to specify the performance of chosen object in the BIM:

16
 TC 442 WI 00442024:2019 (E)

EXAMPLE Pset_WallCommon.FireRating:EI30 (specifies that the wall object in BIM has fire resistance value of
EI30).

Define your own properties to specify designed requirements for the objects. User defined properties for
expressing design requirement have a user-defined property set. The name of the user defined
requirement property matches the name of the property expressing the performance of the chosen
object. In addition, it is advised, that requirement property end with a suffix clearly communicating the
difference between the property for the object performance and the property of the design requirement.
The suffix is then “Req” as an abbreviation of Requirement.

EXAMPLE NONS_Fire.FireRatingReq express the designed fire resistance requirement of the object.
Pset_XxxCommon.FireRating express the performance of the chose object. The property FireRating of the object can
be checked manually if it has the same or better value as the FireRatingReq property.

B.8 Process Status Codes

As BIM objects rarely change geometrical level of detail between the first draft and the final design
approved for construction, it is difficult for other stakeholders to understand the object’s level of maturity
at any given point in decision and quality assurance processes. It is thus advised to communicate the
objects level of maturity in the quality assurance and decision processes according to the given
requirements. The process status code is a property added and maintained by the modelling task team.

Figure B.1 — Example of a process status code system, Model Maturity Index with an agreed set
of maturity definitions

EXAMPLE A door object (see figure B.1). The geometry may change during the design process, but the
level of detail does not clearly communicate the suitability of the object's maturity level. The process
status uses a user defined property, e.g. NONS_Process.ProcessStatus. The value can be according to a
national, organisational or project specific process status definition. If objects can be procured as part of
a subcontractors quote before it is multi-disciplinary approved the design status and constructed status
can be allocated to two or more separate user-defined properties, e.g. NONS_Process.DesignedStatus
(containing codes in this example from MMI100 to MMI399), NONS_Process.ConstructedStatus

17
TC 442 WI 00442024:2019 (E)

(containing codes in this example from MMI400 to MMI499) and NONS_Process_OperationalStatus

(containing codes in this example from MMI500 and up).

18
 TC 442 WI 00442024:2019 (E)

(informative)

Application of methodology and templates

Annex C will provide examples on how to use EN ISO 19650-2 according to this TR. The examples will
expand on the project examples in CEN/TR 17439:2019.

XXXX

19
TC 442 WI 00442024:2019 (E)

Bibliography

XXXXXXXXX

20