ISO 29481-1:2010

INTERNATIONAL ISO
STANDARD 29481-1
First edition
2010-05-15


Building information modelling —
Information delivery manual —
Part 1:
Methodology and format
Modèles des informations de la construction — Contrat d'interchange —
Partie 1: Méthodologie et format





Reference number
ISO 29481-1:2010(E)
©
ISO 2010

---------------------- Page: 1 ----------------------
ISO 29481-1:2010(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


COPYRIGHT PROTECTED DOCUMENT


©  ISO 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland

ii © ISO 2010 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 29481-1:2010(E)
Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Terms and definitions .1
3 IDM (Information delivery manual) .3
3.1 Complete schema.3
3.2 Breaking a complete schema to support requirements.3
3.3 Supporting the building information modelling.4
3.4 Supporting the business requirement .5
3.5 Supporting the software solution .5
3.6 Supporting the construction process .5
3.7 Defining the connection between IDM components.5
3.8 Content in the specific IDM .5
3.9 Users of this part of ISO 29481 .6
4 IDM framework.6
4.1 Overview.6
4.2 IDM component header information.7
4.3 Description of the use case.7
4.4 Interaction maps.7
4.5 Process maps .7
4.6 Exchange requirements.9
4.7 Functional parts.10
4.8 Units of functionality.11
5 Implementing and validating IDM components.12
5.1 Exchange requirement model .12
5.2 Business rules .13
5.3 Validation tests .15
6 General and application guidance.16
6.1 General guidance .16
6.2 Application specific guidance.16
7 IDM development process.16
7.1 Propose an IDM development .16
7.2 Undertake an IDM development.17
8 Compiling IDM components.19
8.1 General information .19
8.2 Adding functional parts .19
8.3 Adding exchange requirement models .21
8.4 Information model units.22
Annex A (informative) Reference section.23
Bibliography.34

© ISO 2010 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 29481-1:2010(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 29481-1 was prepared by Technical Committee ISO/TC 59, Building construction, Subcommittee SC 13,
Organization of information about construction works.
ISO 29481 consists of the following parts, under the general title Building information modelling — Information
delivery manual:
⎯ Part 1: Methodology and format
The following part is planned:
⎯ Part 2: Management communication
iv © ISO 2010 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 29481-1:2010(E)
Introduction
Building information modelling provides a concept for describing and displaying information required in the
design, construction and operation of constructed facilities. It can bring together the diverse sets of information
used in construction into a common information environment - reducing, and often eliminating, the need for
the many types of paper documentation currently in use.
An information delivery manual (IDM) provides significant help in getting the full benefit from a building
construction information model (BIM). If the information required is available when it is needed and the quality
of information is satisfactory, the construction process itself will be greatly improved.
For this to happen, there should be a common understanding of the building processes and of the information
that is needed for and results from their execution.
This part of ISO 29481 sets out a methodology and format for the provision of an integrated reference for the
processes and data required by a BIM. It describes how to identify and describe the processes undertaken
within construction, and the information required for their execution and the results. This part of ISO 29481
also describes how this information can be further detailed to support solutions provided by building-
information-system providers in a form that enables its reuse and how it can be configured to meet national,
local and project needs.
In doing so, this part of ISO 29481 provides a basis for reliable information exchange/sharing for users so that
they can be confident that the information they are receiving is accurate and sufficient for the activities they
need to perform. The development of this part of ISO 29481 has been driven by the need of users for
reliability in information exchange.
Examples and guidelines related to the development of IDMs will be published at:
. The site will developed and maintained by the ISO/TC 59/SC 13 secretariat.

© ISO 2010 – All rights reserved v

---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 29481-1:2010(E)

Building information modelling — Information delivery
manual —
Part 1:
Methodology and format
1 Scope
This part of ISO 29481 specifies a methodology and format for the development of an information delivery
manual (IDM).
This part of ISO 29481 specifies
⎯ a methodology that unites the flow of construction processes with the specification of the information
required by this flow,
⎯ a form in which the information should be specified, and
⎯ an appropriate way to map and describe the information processes within a construction life cycle.
This part of ISO 29481 is intended to facilitate interoperability between software applications used in the
construction process, to promote digital collaboration between actors in the construction process and to
provide a basis for accurate, reliable, repeatable and high-quality information exchange.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
2.1
actor
person, organization or organizational unit (such as a department, team, etc.) involved in a construction
process
2.2
building construction information model
BIM
shared digital representation of physical and functional characteristics of any built object (including buildings,
bridges, roads, etc.) which forms a reliable basis for decisions
NOTE “Building information model” is frequently used as a synonym for BIM.
2.3
building information system
system used to create, maintain, disclose or expire elements of a building information model
NOTE The components of the system can include actors, hardware (servers, clients, peers) and software solutions.
© ISO 2010 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO 29481-1:2010(E)
2.4
business process modelling notation
BPMN
notation for use in the development of business process diagrams that is designed to be readily
understandable by all business users
2.5
business requirement
requirement that describes in business terms what needs to be delivered or accomplished
2.6
business rule
statement that formally defines or constrains some aspect of the business, a rule under which an organization
operates or a policy or decision that influences a process
2.7
exchange requirement
ER
set of information that needs to be exchanged to support a particular business requirement at a particular
process phase (or phases) / stage (or stages)
NOTE Information delivery requirement can be used as a synonym for exchange requirement.
2.8
exchange requirement model
ERM
technical expression of an exchange requirement expressed as a schema
NOTE An exchange requirement model describes the binding of an exchange requirement to a particular standard
information schema and version.
2.9
functional part
FP
unit of information within an exchange requirement that may be fully specified in its own right
2.10
interaction map
representation of the roles and transactions relevant for a defined purpose
2.11
management communication
sharing information for a management purpose
2.12
model
representation of a system that allows for investigation of the properties of the system
NOTE “Representation” is defined in http://www.businessdictionary.com/definition/representation.html.
2.13
process map
PM
representation of the relevant characteristics of a process for a defined purpose
2 © ISO 2010 – All rights reserved

---------------------- Page: 7 ----------------------
ISO 29481-1:2010(E)
2.14
role
functions being performed by an actor at a point in time
NOTE The role of an actor is determined by action and outcome and not by the profession or trade followed by the
actor.
2.15
schema
schema is a description of the formal structure of a defined set of information
2.16
transaction
communication event that fulfils a relationship between two roles
3 IDM (Information delivery manual)
3.1 Complete schema
A complete information schema that covers all of the information required for all actors throughout the
construction process will be large and comprehensive. Such a schema is relevant in defining all of the project
information needs for all business requirements at all life-cycle stages (see Figure 1), but it is not the way that
project information is usually delivered.
Life-cycle stage
Information
schema

Figure 1 — The information schema supports all business requirements at all life-cycle stages
3.2 Breaking a complete schema to support requirements
It is more usual for information to be exchanged about a particular topic and the level of detail provided to be
driven by the life-cycle stage. The need is (generally) to support one business requirement over one or more
life-cycle stages (see Figure 2). This is a matter of deciding which components of the information schema
should be used to meet requirements.
© ISO 2010 – All rights reserved 3

Business requirement

---------------------- Page: 8 ----------------------
ISO 29481-1:2010(E)
Life-cycle stage
Information
schema

Figure 2 — Need to support a business requirement at a life-cycle stage
3.3 Supporting the building information modelling
Elements of the overall information schema are used in a building construction information model (BIM) (see
Figure 3). For a particular business requirement, only certain classes of information are required. Multiple
objects are derived from each class, each object having an identity (determined by a unique identifier) and a
state (determined by the values given to each attribute of the object). The classes that support the business
requirement form a unique and identifiable schema.
INFORMATION SCHEMA
a schema is defined
by many classes
Schema Class
A schema specifies A class provides the
many models pattern for many objects
Object
Model
a model is populated
by many objects
BUILDING INFORMATION MODEL

Figure 3 — Supporting the building information modelling
4 © ISO 2010 – All rights reserved

Business requirement

---------------------- Page: 9 ----------------------
ISO 29481-1:2010(E)
3.4 Supporting the business requirement
To do this means that the set of information that needs to be exchanged to support a particular business
requirement in the relevant life-cycle stages must be established. This is termed an exchange requirement.
An exchange requirement provides a description of the information to be exchanged in non technical terms.
An exchange requirement may support the communication of object information enabling the construction and
operation of a project or it may support the communication of management information that controls the
project execution.
3.5 Supporting the software solution
The technical content required by solution providers to support an exchange requirement is provided as a
series of units of information. A unit of information is termed a functional part.
A functional part provides the technical expression of information content as a subset of the complete
information schema.
3.6 Supporting the construction process
Software solutions typically support users across several exchange requirements. Exchange requirements are
used to support an overall construction process. The connection between exchange requirements and a
construction process is captured within a process map.
A process map typically deals with the development of information within the boundary of a particular topic or
software view. It shows the roles of actors engaged in the process and references the transactions between
them.
3.7 Defining the connection between IDM components
Functional parts are used together to create exchange requirement models. An exchange requirement model
provides a version of the exchange requirement that can be understood by a computer. It includes business
rules which are computer interpretable versions of the business propositions described in an exchange
requirement.
3.8 Content in the specific IDM
The content in a specific IDM will
⎯ describe the need for information exchange between processes,
⎯ specify how to capture the information needing to be exchanged between these processes,
⎯ identify the actors sending and receiving information,
⎯ define, specify and describe the information being exchanged to satisfy the requirements at each
point of the business process,
⎯ ensure that definitions, specifications and descriptions are provided in a form that is useful and easily
understood,
⎯ create detailed specifications of the information captured within exchange requirements to facilitate
the development of software building information systems,
⎯ ensure that the information specifications can be made relevant to local working practices.
© ISO 2010 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO 29481-1:2010(E)
3.9 Users of this part of ISO 29481
The main purpose of this part of ISO 29481 is to provide guidance for those who develop specific IDMs. Thus,
the main users are expected to be the IDM developers who create process maps, exchange requirements,
functional parts, exchange requirement models and business rules using knowledge elicited from end users
and solution providers.
Other actors will mainly be using the specific IDMs which are developed by using this part of ISO 29481. In
addition, some users of specific IDMs might identify needs for new IDMs and thus become users of this part of
ISO 29481. These users include
⎯ professional IDM-developers and solution providers — according to very technical specifications,
⎯ information users, i.e. executive users and end users concerned with producing the content of the
IDMs and benefiting from the result.
4 IDM framework
4.1 Overview
Figure 4 provides a generalized view of the main components used in an IDM and how they relate to each
other. The organization of the components within the framework is based on two ideas:
a) the components at the top layer of the framework relate to processes, progress through data
specifications in the middle layers and include application software elements at the bottom layer;
b) similarly, the components relate to industry practitioners at the top layer of the framework and to ICT
analysts and programmers at the bottom layers.
Process map / Interaction map
Exchange requirements
Functional parts

Figure 4 — IDM basic framework
6 © ISO 2010 – All rights reserved

---------------------- Page: 11 ----------------------
ISO 29481-1:2010(E)
4.2 IDM component header information
Each IDM component described below includes a set of administrative information that enables it, its current
author and its change history to be captured. Administrative information includes
⎯ a name or title conforming to the naming rules given in this International Standard,
⎯ a unique identifier,
⎯ a change log that identifies creation or change made together with the author and date.
4.3 Description of the use case
Each IDM component shall start with a short plain language description of the use case the IDM is intended to
solve or about which particular topic or business requirement information shall be exchanged.
4.4 Interaction maps
The purpose of an interaction map is to identify the relevant roles and transactions for a specific purpose. IDM
draws a distinction between the role “initiator” (makes a request) and the role “executor" (effectuates that
request). If there is such a relationship between two roles, it is termed a “transaction”.
An interaction map identifies the relevant roles, transactions and initiator – executor relations.
A transaction contains a set of exchange requirements that are exchanged for a particular purpose. The
transaction also stipulates the participating roles, point in the life cycle and the sequence in which exchange
requirements should be delivered (if appropriate). A message is a populated information model and contains
data. Attachments may be linked to messages.
In an interaction map, all transactions needed for the handling of required contributions of relevant roles to the
BIM shall be included. All transactions within the interaction map have a unique identity and name.
Using transactions, the business cooperation and communication requirements are defined. Use of exchange
requirements (ER) is optional in transactions.
Using transactions, the contributions of relevant roles to the BIM can be controlled. For that purpose, in
specific transactions, the following components can be added as attachments to specific messages
⎯ exchange requirement,
⎯ exchange requirement model,
⎯ window of authorization: in the context of a transaction an executive role (executor) can access the
building information system. The window of authorization describes what information in this
transaction by the role may be read or changed.
4.5 Process maps
4.5.1 General information
The purpose of a process map is to describe the flow of activities within the boundary of a particular topic, the
roles played by the actors involved, together with the information required, consumed and produced.
For representing process maps, the approach recommended is the BPMN. (Further information on BPMN is
given in A.4.)
© ISO 2010 – All rights reserved 7

---------------------- Page: 12 ----------------------
ISO 29481-1:2010(E)
Within IDM, a process map
⎯ sets the boundary for the extent of the information contained within the process,
⎯ establishes the activities within the process, and
⎯ shows the logical sequence of the activities.
The actual information that is within the process boundary is determined by the contents of the exchange
requirements specified in the process.
4.5.2 Content
All activities described within a process map should be related to the defined life-cycle stages as they appear
in exchange requirements' documentation.
A process map includes the following administrative information
⎯ the exchange requirements that are within the boundary of the process,
⎯ an overview that provides a comprehensive description of the overall process. Illustrations may be
used to illustrate particular points within the overview.
4.5.3 Specification of processes
In a process map, all of the diagrams and sub-diagrams created for describing the process shall be included.
Each process within the process map has a unique identity and name.
Each process within the process map is described in such detail as required. The aim is to describe the
purpose of the process to a reader.
4.5.4 Specification of data objects
A data object is a named collection of data. It may be a collection of data available from an external source
(e.g. library data) or it may be the data exported from an activity to enable other activities to occur (e.g. an
exchange requirement).
Data objects that are not exchange requirements shall have a name that is indicative of their purpose and a
description that outlines their purpose and content.
4.5.5 Specification of exchange requirements
An exchange requirement is a particular type of data object within a process map that is located within the
information model role.
Exchange requirements shall have the following
⎯ a name that is indicative of the purpose (naming rules are given in Clause A.3),
⎯ a description that outlines the purpose and content.
NOTE The description provided for an exchange requirement is expected to be more detailed than that given for a
general data object. The description can be reused as the overview description within the exchange requirement
documentation (described below).
8 © ISO 2010 – All rights reserved

---------------------- Page: 13 ----------------------
ISO 29481-1:2010(E)
4.5.6 Specification of coordination point gateways
A coordination point gateway is a named point within a process map at which the information from exchange
requirements is brought together to enable coordinated decision making to occur. Each coordination point
gateway shall have a name and its intended purpose should be described.
Decisions made at coordination point gateways may provide
⎯ a hard gateway at which all information shall be valid according to the exchange requirements and
without which further progress is not allowed,
⎯ a soft gateway at which information may not be fully valid according to the exchange requirements
but at which progress is allowed on the expectation that full validity will be provided later.
4.6 Exchange requirements
4.6.1 General information
An exchange requirement is a description of a set of information that needs to be exchanged to support a
particular business requirement at a particular stage of a project. It is intended to 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 should however also be used by the solution provider since it
provides the key to the technical detail that enables the solution to be provided.
An exchange requirement represents the connection between process and data. It describes a set of
information from a process that has been performed by an actor in the role of initiator to enable a downstream
process to be performed by another actor in the role of executor.
4.6.2 Content
An exchange requirement contains the following information:
⎯ the life-cycle stage(s) for which the exchange requirement is used; an exchange requirement may be
applicable to one or more life-cycle stages,
⎯ an overview that states the aims and content of the exchange requirement using terminology that is
familiar to the user. The aim is that it should be understood by a person who needs to be aware of
what the exchange requirement is intended to achieve but who does not need to know the detail of
how it is achieved. Illustrations may be used to amplify particular points within the overview.
4.6.3 Information units
The information required is provided in a set of information units. An informa
...