ISO 29481-1:2016

INTERNATIONAL ISO
STANDARD 29481-1
Second edition
2016-05-01
Building information models —
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 2016
© ISO 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2016 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Information delivery manual . 3
4.1 General . 3
4.2 Users of this part of ISO 29481 . 3
4.3 Business context . 4
4.4 Complete schema . 5
4.5 Breaking a complete schema to support requirements. 5
4.6 Supporting the building information modelling process . 5
4.7 Supporting the business process . 5
4.8 Supporting the software solution . 6
4.9 Content in the specific IDM . 6
5 IDM Framework . 6
5.1 General . 6
5.2 Basic framework . 8
5.2.1 General. 8
5.2.2 IDM component header information . . 8
5.2.3 IDM component overview. 9
5.3 Interaction map/transaction map . 9
5.4 Process maps . 9
5.5 Exchange requirements .10
5.5.1 General.10
5.5.2 Information units .10
5.5.3 Information constraints .10
5.6 Technical implementation .11
5.6.1 General.11
5.6.2 Implementation of metadata .11
5.6.3 Interaction framework .11
5.6.4 Model view definition (MVD) .11
Annex A (informative) IDM development process .13
Annex B (informative) Examples of simplified IDM components .17
Annex C (informative) Reference life cycle stages .22
Annex D (informative) IDM use of BPMN methods .24
Bibliography .29
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.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 59, Buildings and civil engineering works,
Subcommittee SC 13, Organization of information about construction works.
This second edition cancels and replaces the first edition (ISO 29481-1:2010), which has been technically
revised.
ISO 29481 consists of the following parts, under the general title Building information models —
Information delivery manual:
— Part 1: Methodology and format
— Part 2: Interaction framework
iv © ISO 2016 – All rights reserved

Introduction
This International Standard has undergone a major review in the light of refined approaches to the
development of information delivery manuals and their technical implementation in software readable
forms. It is important to note that these changes do not render existing information delivery manuals
(IDM) invalid.
Building information modelling provides a digital technology for describing and displaying information
required in the planning, design, construction and operation of constructed facilities. Increasingly,
this modelling approach is expanding to encompass all aspects of the built environment, including civil
infrastructure, utilities and public space. These are collectively referred to as construction processes.
This approach to managing information brings together the diverse sets of information used during
the life cycle of the built environment into a common information environment, reducing, and often
eliminating the need for the many types of paper documentation currently in use.
This approach is commonly referred to as building information modelling (BIM; reflecting its initial
application in the architectural domain), while the same acronym is used to refer to the product of the
process, the information model itself, or building information model (BIM).
Though the focus of construction processes described above is on the physical fabric of the built
environment, BIM technology can also benefit the processes associated with managing the use of
space within buildings, urban neighbourhoods and cities at the broader scale, as well as infrastructure
networks and facilities. These are referred to here as use cases.
An IDM provides help in getting the full benefit from a BIM. If the required information is available in
the BIM to support a construction process or use case, and the quality of information is satisfactory,
then the process itself will be greatly improved.
For this to happen, there needs to be a common understanding of the processes involved across the
entire life cycle development of a built environment project, including the information that is required
for and results from the execution of that process. This applies to any activity that results in an
exchange of information and may not relate directly to a BIM, e.g. the process to arrive at a work plan or
contractual agreement.
This part of ISO 29481 sets out a methodology for the provision of an integrated reference document
that describes the processes and data required in the development or management of a constructed
facility. It describes how to identify and describe the processes undertaken within that context, the
information required for their execution and the results. This part of ISO 29481 also describes in
general terms how this information can be further detailed to support solutions provided by software
developers, enabling its reuse, and configured to meet national, local and project needs.
In summary, 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.
INTERNATIONAL STANDARD ISO 29481-1:2016(E)
Building information models — Information delivery
manual —
Part 1:
Methodology and format
1 Scope
This part of ISO 29481 specifies
— a methodology that links the business processes undertaken during the construction of built
facilities with the specification of information that is required by these processes, and
— a way to map and describe the information processes across the life cycle of construction works.
This part of ISO 29481 is intended to facilitate interoperability between software applications used
during all stages of the life cycle of construction works, including briefing, design, documentation,
construction, operation and maintenance, and demolition. It promotes digital collaboration between
actors in the construction process and provides a basis for accurate, reliable, repeatable and high-
quality information exchange.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO 6707-1, Buildings and civil engineering works — Vocabulary — Part 1: General terms
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 6707-1 and the following apply.
3.1
actor
person, organization or organizational unit (such as a department, team, etc.) involved in a
construction process
3.2
building information modelling
BIM
use of a shared digital representation of a built object (including buildings, bridges, roads, process
plants, etc.) to facilitate design, construction and operation processes to form a reliable basis for
decisions
Note 1 to entry: The acronym BIM also stands for the shared digital representation of the physical and functional
characteristics of any construction works.
3.3
BIM software application
software application that is used to create, modify, analyze, manage, publish, share, expire, or otherwise
manipulate elements of a BIM
3.4
business requirement
requirement that describes in business terms what needs to be delivered or accomplished
3.5
information constraint
statement that formally defines or constrains the scope of a piece of information due to some aspect of
the business, a rule under which an organisation operates or a policy or decision that influences a process
3.6
class
type or collection of things that share common attributes
3.7
construction works
everything that is constructed or results from construction operations
[SOURCE: ISO 6707-1:2014, 3.1.1]
Note 1 to entry: This can refer to a building, piece of civil infrastructure (road, bridge, pipeline, etc.) or a
landscape element and is extended to include aggregations of those elements to form an urban precinct, campus,
or other institutional facility.
3.8
construction process
process that uses construction resources to achieve construction results
Note 1 to entry: Each construction process can be split up into its component processes.
3.9
exchange requirement
ER
defined set of information units that needs to be exchanged to support a particular business requirement
at a particular process phase (or phases)/stage (or stages)
3.10
information delivery manual
IDM
documentation which captures the business process and gives detailed specifications of the information
that a user fulfilling a particular role would need to provide at a particular point within a project
Note 1 to entry: This can be referred to as an information delivery specification (IDS).
3.11
IDM components
basic elements that form an IDM: interaction maps/transaction maps, process maps and exchange
requirements
3.12
information unit
individual information item, such as a window identifier or a room depth
3.13
interaction map
representation of the roles and transactions relevant for a defined purpose
3.14
interaction framework
formal description of the elements of interaction, including definition of roles, transactions, messages
in transaction, and data elements in messages
2 © ISO 2016 – All rights reserved

3.15
model
representation of a system that allows for investigation of the properties of the system
3.16
model view definition
MVD
computer-interpretable definition of an exchange requirement, specifically bound to one or more
particular standard information 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.
3.17
object
part of the perceivable or conceivable world
Note 1 to entry: An object is something mental or physical toward which thought, feeling, or action is directed.
3.18
process map
PM
representation of the relevant characteristics of a process associated with a defined business purpose
3.19
role
functions being performed by an actor at a point in time
Note 1 to entry: The role of an actor is determined by action and outcome and not necessarily by the profession
or trade followed by the actor.
3.20
transaction
communication event that fulfils a relationship between two roles
3.21
transaction map
representation of a set of messages that are exchanged between participating roles for a particular
purpose
4 Information delivery manual
4.1 General
This Clause describes a series of concepts and principles that inform the development of an IDM.
4.2 Users of this part of ISO 29481
The main users are expected to be the IDM developers who create interaction maps, process maps,
exchange requirements and information constraints using knowledge elicited from end users and
solution providers.
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 the following:
— professional IDM-developers and solution providers;
— information users, i.e. executive users and end users concerned with producing the content of the
IDMs and benefiting from the result.
Another group of users will be those who use the documentation that results from the use of the
standard, taking note of the business process and detailed specifications of the information that a
user fulfilling a particular role would need to provide at a particular point within a project. Such users
include the following:
— project manager, responsible for organizing the business process and ensuring that the information
exchange is appropriately managed;
— BIM manager, making the necessary arrangements to support an exchange requirement;
— client, who initiates (develops) and includes an IDM in the contract;
— contractor/consultant, using the IDM to make the necessary arrangements to comply with the
required business process and to comply with the required information delivery;
— business manager, using an IDM as a template or standard to be applied in many projects within its
organization;
— construction organization, using an IDM for a specific project type as a template or standard to be
applied in the sector.
4.3 Business context
Figure 1 shows an example of a business context that requires an IDM: a client (Role 1) engages
a consultant (Role 2) to deliver some service. In such a scenario, there is a need to understand and
formalize both the collaborative and contractual aspects of their relationship and how information will
be delivered within that context. The IDM describes the information requirements associated with all
the transactions (both ways) associated with that relationship. Some of that information will be held
within a BIM, while other may originate from either party or from an external source.
Figure 1 — Example of a simple business context requiring an IDM
The first step in developing an IDM is to consider the nature or context of the information exchange.
There are two ways of looking at that, each with an associated methodology.
— Process maps are most useful when the focus is on the business processes (defined by activities
executed by actors with roles) that need to be followed to deliver a service or produce an end
product (such as a design). In this case, the information that is the focus of the IDM is associated
with a business requirement.
4 © ISO 2016 – All rights reserved

— Interaction maps/transaction maps are most useful within a business process when the focus is on
the interactions between actors with roles who are to deliver a service or product and the concern
is to ensure that agreed communication protocols are in place to ensure that the project goals are
achieved. In this case, the information that is the focus of the IDM is associated with a transaction.
These are complementary approaches and are explained in further detail in later sections. Within a
given business context, it may be appropriate to use both methodologies: process mapping can be used
to clarify the details of a transaction identified in an interaction mapping exercise, while an interaction
map can be used to rigorously understand an information transaction defined in a process map.
4.4 Complete schema
Where the information requirements are satisfied by a BIM, 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
processes at all life cycle stages, but it is not the way that project information is usually delivered.
4.5 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. This may be a single business process at a specific point in the
project life cycle, but commonly consists of information units that may be relevant to more than one
life cycle stage or business processes. This is commonly referred to as a model view and is a matter of
deciding which components of the information schema should be used to meet requirements.
4.6 Supporting the building information modelling process
Elements of the overall information schema are used in a building information model (see Figure 2).
For a particular business process, 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
process form a unique and identifiable standard schema or model view.
Figure 2 — Supporting the BIM process
4.7 Supporting the business process
To do this means that the set of information required to be exchanged to support a particular business
process or interaction in the relevant life cycle stages (within a business process) shall 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.
4.8 Supporting the software solution
Moving from the defined exchange requirement to a software implementation provided by a solution
provider involves the development of a model view definition (MVD). This approach supersedes the
need to implement functional parts as defined in earlier versions of this International Standard.
4.9 Content in the specific IDM
The content in a specific IDM shall
— describe the need for information exchange within the business context,
— identify the actors sending and receiving information,
— define, specify and describe the information being exchanged to satisfy the requirements at each
point within the business context,
— 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 BIM software applications, and
— ensure that the information specifications can be made relevant to local working practices.
Guidance for development of content and the approach to follow is given in Annex A.
5 IDM Framework
5.1 General
An information delivery manual comprises (Figure 3) the following:
— an interaction map/transaction map and/or a process map;
— one or more exchange requirements.
The interaction map defines the roles involved and the transactions between roles. For each defined
transaction, one role is initiator while another is executor. The corresponding transaction map defines
the messages in a transaction and the rules that apply on the sequence of execution.
The process map shows a swim lane for each role and defines within the lane the relevant sequence of
activities to be executed by that role. Activities undertaken by different roles may have relations that
require an exchange of information in the form of a message. Such messages correspond to a message in
a transaction shown in a transaction map.
6 © ISO 2016 – All rights reserved

Figure 3 — IDM basic framework
Some messages can carry a package of BIM information, giving rise to the need to define an exchange
requirement.
An exchange requirement comprises a comprehensive description of the information that shall be
included in a BIM that is associated with a message passed between roles. It includes definitions of
the information requirements, including references to library objects where relevant, as well as a
description of need, guidance in its use and any information constraints that may apply.
The technical implementation of an exchange requirement is achieved through a model view definition.
The technical implementation of an interaction map/transaction map is delivered in an interaction
framework.
5.2 Basic framework
5.2.1 General
Each IDM component (process map, interaction/transaction map or exchange requirement) shall
include header information and overview as follows.
5.2.2 IDM component header information
Each IDM component shall include at least the following administrative information:
— name or title conforming to the naming rules given in Table 1;
— unique identifier;
— project stage supported by the component;
— change log that identifies both creation and any change made together with the author and date.
Table 1 — Naming rules
Nr. Naming rule
1 Each IDM component shall have a name.
The first part of the name is the prefix:
—  er_ for exchange requirement;
2   —  im_ for interaction map;
—  pm_ for process map;
—  tm_ for transaction map.
The name given to each IDM component is an imperative that has two parts:
—  the first part of the name is an action (or activity) required and is expressed as a verb;
—  the second part of the name is an object that receives the action and is expressed as a noun or
noun phrase. This may be a direct object (as in “model wall”) or an implied indirect object (as in
“associate material” which means associate {to wall} {the} material).
4 All identifiable words in a name are separated using an underscore character “_”.
IDM components may have parameters that enable further qualification. Parameters are expressed as a
list within parentheses, for example, (a,b,c,d).
A project stage shall be identified through a life cycle stage. A reference for life cycle stages is given in
Annex C.
With the delivery of each information unit, it may be expedient to make reference to the exchange
requirement that specified the content.
8 © ISO 2016 – All rights reserved

5.2.3 IDM component overview
Each IDM component shall start with a short plain language description of the contents, use case,
aims and scope that the component is intended to address or about which particular topic or business
requirement information shall be exchanged.
Examples of simplified IDM components are given in Annex B.
5.3 Interaction map/transaction map
The purpose of an interaction map is to identify the relevant roles and transactions for a specific
purpose, typically the completion of a team-based project task. IDM draws a distinction between a role
that makes a request (initiator) and the role that gives effect to that request (executor). If there is such a
required communication between two roles, then it is termed a transaction.
The approach recommended to prepare an interaction map is according to the CRISP Model (Dietz,
J.L.G.: Enterprise Ontology, Springer, 2006).
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.
A transaction map is a representation of the messages that can be exchanged between the participating
roles in a particular transaction, including constraints on the sequence. The approach recommended to
prepare a transaction map is UML (sequence diagram).
Messages are exchanged for a certain purpose (e.g. a request for change or the delivery of an information
package). A message is a populated information model and contains data relevant for the process. A
message can have one or more attachments.
Using transactions, the business cooperation and communication requirements are defined, allowing
the contributions of relevant roles to the BIM to be controlled. For that purpose, in specific transactions,
the following components can be added as attachments to specific messages:
— exchange requirement;
— information package (a set of object data which is the actual information delivery that satisfies an
exchange requirement);
— window of authorization: in the context of a transaction, an executive role (executor) can access
the BIM software applications. The window of authorization describes what information in this
transaction by the role may be read or changed.
5.4 Process maps
The purpose of a process map is to describe the flow of activities within the boundary of a particular
business process, the roles played by the actors involved together with the information required,
consumed and produced.
The approach recommended for representing process maps is the Business Process Modelling Notation
(BPMN). Further information on BPMN is given in Annex D.
Within an 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.
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. Diagrams may be
used to illustrate particular points within the overview.
5.5 Exchange requirements
5.5.1 General
An exchange requirement defines the information that shall be exchanged to support a particular
business process at a particular stage of a project. It is intended to provide a description of the
information in non-technical terms. An exchange requirement shall be understandable to end users
(architect, engineer, constructor, etc.). The exchange requirements are used to create an MVD, which is
a technical specification that is used in software development and specified in 5.6.3.
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. It should be defined with
a clear understanding of the information needs of the downstream actor.
5.5.2 Information units
The information required is provided in a set of information units. An information unit typically deals
with one type of information or concept of interest. An information unit may be composed of an entity
alone, such as project and wall or an entity (e.g. project) and its attribute (e.g. name), such as project
name and wall lengths.
Preconditions for the exchange requirement are identified first. A precondition is an exchange
requirement that should have been completed prior to the execution of the current exchange
requirement.
Information units should be specified further to provide the following:
— a description of the information unit: The description should be as explicit as possible and
unambiguous enough not to confuse MVD modellers with other concepts;
— the information which needs to be exchanged for the provisions of this information unit to be
satisfied. This should include any special provisions, propositions or rules related to the information.
5.5.3 Information constraints
Information constraints specify the data type of an information unit, and a context, rules, and the
restrictions on using the specified information unit. Here are some examples of the data type and rules.
— Data types
— text, integer, number, 2D graphic, 3D model, etc.
— Context, rules, and the limits of use
— a table shall have at least three legs,
— a precast concrete piece shall have at least three identifiers: a piece mark (a production serial
number), a mark number (a designed number), and an installation location identifier
— a room area cannot be smaller than 0 m , and
10 © ISO 2016 – All rights reserved

— the largest panel size should not exceed 14 m to be delivered by a normal truck.
5.6 Technical implementation
5.6.1 General
This part of ISO 29481 is specifically concerned with the preparation of a common language description
of the information requirements of business processes, particularly where those include the exchange of
BIM data. These information specifications can be used as the basis for automated processes involving
the use of software applications, referred to here as technical implementations.
This Clause describes the principles and scope of available technical implementations, each the subject
of a separate part in this standard series.
5.6.2 Implementation of metadata
An overriding intention behind all technical implementations is that the specification shall be converted
to a machine-readable form that includes key metadata (header, overview, classification) required for
the automated process.
5.6.3 Interaction framework
An interaction framework is a formal description of the elements of interaction, including definition of
roles, transactions, messages in transaction, the sequence of messages, and data elements in messages.
The methodology for the development of an interaction framework and its format is included in
ISO 29481-2.
5.6.4 Model view definition (MVD)
An MVD defines a data model or a subset of an existing data model that is necessary to support one or
many specific data exchange requirements (Figure 4). MVDs are used in software development and
should have a machine-readable representation. A MVD that is dedicated to a single IDM can be used
to filter information in software tools to a specific exchange requirement. If information constraints
are added to a MVD the combination can be used for data validation purposes. Software products
supporting a number of exchange requirements may implement a consolidated MVD that refers to
several IDMs. These MVDs are often used in certification of software products, but data validation
should always be done on individual MVDs.
Figure 4 — Relation between IDM and MVD
12 © ISO 2016 – All rights reserved

Annex A
(informative)
IDM development process
A.1 Propose an IDM development
A.1.1 General information
A proposal to undertake an IDM development is a preliminary stage that sets the scene for work to be
done. It is concerned with
— defining the scope,
— establish the development approach,
— identifying resources, and
— establishing a project plan.
A.1.2 Define scope
The scope should set the boundaries for the work that is to be done and provide a continuing reference
to ensure that the work boundaries do not grow beyond a point at which the planned or available
resource ceases to be sufficient.
The following questions should be answered in the preparation:
— What are the business needs for the information exchange?
— Who is able to describe these needs?
— Who are the actors and what are their roles and interests?
— How can the information exchange be prepared and handled?
— Will existing agreements, contractual conditions, standards, etc. support the information exchange?
The preparation ends up with an assessment of whether it is possible to reach the stated scope and
success criteria. If the assessment is positive, the actual IDM development can be initiated. If the
assessment turns out to be negative, you may choose to revise the use case or stop the development.
An overview of the existing resources should be provided, along with any prerequisite IT resources.
The overview may show that the goals can be reached, enabling IDM development.
The overview may demonstrate that the business goals cannot be achieved. In that instance, goals shall
be reviewed to fit available and possibly new IT resources specified. Conversely, the actors may choose
not to proceed with the IDM development.
The practical and legal information exchange issues shall be described to clarify who is doing what,
and who is responsible. Agreement and contractual conditions may prevent previously defined goals
and success criteria from being met. Possibly, the goals can be revised to conform to the agreement and
standard conditions.
A.1.3 Establish the development approach
The development approach selected will be determined by the extent of information, software or other
exchange requirements available. The approaches are described under A.2.1.
A.1.4 Identify resources
Resources are the people who need to participate in an IDM development. Resources need to be properly
balanced between project management, development of IDM components and industry knowledge
to guide both component development and provision of software solutions. The balance of resources
required will be affected by the development route that is selected.
A.1.5 Project plan
The project plan sets the period over which the development is to occur, determines the tasks to be
undertaken, assigns the available resources and sets the deliverables required.
A.2 Undertake an IDM development
A.2.1 General information
There are three approaches to IDM development:
— process discovery;
— information constraint customisation;
— reverse engineering.
A.2.2 Process discovery
A.2.2.1 General information
Process discovery is the conventional approach used in IDM development. It assumes that there is no
existing software from which requirements may be mined or other exchange requirements that may be
customised.
The development approach is described below as a linear sequence. In practice, feedback between
development stages and cyclic developments can be expected.
A.2.2.2 Discover process
There are two alternate methodologies proposed: process mapping and interaction mapping. A decision
needs to be made about the approach most applicable to the business context.
The discover process involves working primarily with industry experts and specialist building
information system providers to determine the defined scope, the process map or interaction
framework.
This process usually requires several cycles of development and review to achieve a satisfactory
conclusion. On completion, the process map or interaction framework may represent current practice
or it may represent a proposal for an improved business practice. Whether to create an “as-is” process
or a “to-be” process is a decision that needs to be taken as part of the development.
The process maps or interaction maps will identify the “packages” of data that need to be exchanged at
various points in the business process. These are the exchange requirements.
14 © ISO 2016 – All rights reserved

A.2.2.3 Create exchange requirement
Exchange requirements should then be created. Wherever possible, they should re-use the resources of
existing exchange requirements.
A.2.3 Information constraint customisation
A.2.3.1 Define information constraints
The set of information constraints that may need to be applied to further configure an existing (or
newly defined) exchange requirement should be defined. These may be used to control properties to be
asserted or values that can be assigned.
A.2.3.2 Information constraint localization
Information constraint localization assumes that an exchange requirement exists for the purpose
required but that it does not meet the needs for use within a particular location. Location may be a place
(country, region, etc.), a project or a framework of working agreed between members of a project team.
Information constraints are applied to individual units of information within the context of the
exchange requirement to make it applicable at a particular location. Note that the same in
...

NORME ISO
INTERNATIONALE 29481-1
Deuxième édition
2016-05-01
Modèles des informations de la
construction — Protocole d’échange
d’informations —
Partie 1:
Méthodologie et format
Building information models — Information delivery manual —
Part 1: Methodology and format
Numéro de référence
©
ISO 2016
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2016, Publié en Suisse
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni utilisée
sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2016 – Tous droits réservés

Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Protocole d’échange d’informations . 3
4.1 Généralités . 3
4.2 Utilisateurs de la présente partie de l’ISO 29481 . 3
4.3 Contexte professionnel . 4
4.4 Schéma complet . 5
4.5 Division du schéma complet pour prendre en charge des exigences . 5
4.6 Prise en charge du processus de modélisation d’informations de la construction . 5
4.7 Prise en charge du processus métier . 6
4.8 Prise en charge de la solution logicielle . 6
4.9 Contenu de l’IDM spécifique . . 6
5 Cadre de l’IDM . 7
5.1 Généralités . 7
5.2 Cadre de base . 9
5.2.1 Généralités . 9
5.2.2 Informations d’en-tête de composant d’IDM. 9
5.2.3 Description générale des composants d’IDM . 9
5.3 Carte d’interaction/carte de transaction .10
5.4 Cartes de processus .10
5.5 Exigences d’échange .11
5.5.1 Généralités .11
5.5.2 Unités d’information . .11
5.5.3 Contraintes d’information .11
5.6 Mise en œuvre technique .12
5.6.1 Généralités .12
5.6.2 Mise en œuvre des métadonnées .12
5.6.3 Cadre d’interaction .12
5.6.4 Définition de vue du modèle (MVD) .12
Annexe A (informative) Processus de développement de l’IDM .14
Annexe B (informative) Exemples de composants d’IDM simplifiés .18
Annexe C (informative) Étapes de référence du cycle de vie .23
Annexe D (informative) Utilisation par l’IDM des méthodes BPMN.25
Bibliographie .31
Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération mondiale d’organismes
nationaux de normalisation (comités membres de l’ISO). L’élaboration des Normes internationales est
en général confiée aux comités techniques de l’ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l’ISO participent également aux travaux.
L’ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d’approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www.
iso.org/directives).
L’attention est appelée sur le fait que certains des éléments du présent document peuvent faire l’objet de
droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l’élaboration du document sont indiqués dans l’Introduction et/ou dans la liste des déclarations de
brevets reçues par l’ISO (voir www.iso.org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la signification des termes et expressions spécifiques de l’ISO liés à l’évaluation
de la conformité, ou pour toute information au sujet de l’adhésion de l’ISO aux principes de l’Organisation
mondiale du commerce (OMC) concernant les obstacles techniques au commerce (OTC), voir le lien
suivant: www.iso.org/iso/fr/avant-propos.html
Le comité chargé de l’élaboration du présent document est l’ISO/TC 59, Bâtiments et ouvrages de génie
civil, Sous-comité SC 13, Organisation des informations relatives aux ouvrages de construction.
Cette deuxième édition annule et remplace la première édition (ISO 29481-1:2010), qui a fait l’objet
d’une révision technique.
L’ISO 29481 est constituée des deux parties suivantes, sous le titre général Modèles des informations de
la construction — Protocole d’échange d’informations:
— Partie 1: Méthodologie et format
— Partie 2: Cadre d’interaction
iv © ISO 2016 – Tous droits réservés

Introduction
La présente Norme internationale a subi une révision majeure à la lumière de la nouvelle définition
des approches de développement des protocoles d’échange d’informations et de leur mise en œuvre
technique sous forme lisible par des logiciels. Il est important de noter que ces modifications n’invalident
pas les protocoles d’échange d’informations (IDM, Information Delivery Manual) existants.
La modélisation d’informations de la construction propose une technologie numérique permettant de
décrire et de présenter les informations requises dans la planification, la conception, la réalisation et
l’exploitation d’installations du secteur de la construction. Cette approche de modélisation se développe
de plus en plus pour englober tous les aspects du milieu bâti, y compris les infrastructures civiles, les
installations d’intérêt public et l’espace public. Ceux-ci sont regroupés sous l’appellation processus de
construction. Cette approche de gestion des informations permet de rassembler les divers éléments
d’information utilisés durant le cycle de vie du milieu bâti en un environnement d’informations
commun, ce qui réduit, et souvent élimine, le besoin de disposer de nombreux types de documentation
papier utilisés aujourd’hui.
Cette approche est généralement appelée la modélisation des informations de la construction
(BIM, Building Information Modelling, terme reflétant son application initiale dans le domaine de
l’architecture), tandis que ce même acronyme est utilisé pour faire référence au produit du processus,
au modèle d’informations lui-même ou au modèle d’informations de la construction (BIM).
Les processus de construction décrits ci-dessus sont centrés sur la construction physique du milieu
bâti, cependant la technologie BIM peut également bénéficier aux processus associés à la gestion de
l’espace dans les bâtiments, les voisinages urbains et les villes à plus grande échelle, ainsi qu’aux réseaux
d’infrastructure et aux installations. Ils sont appelés ici cas d’usage.
Un IDM aide à obtenir le plus grand bénéfice d’un BIM. Si les informations requises sont disponibles
dans le BIM pour prendre en charge un processus de construction ou un cas d’usage, et si la qualité des
informations est satisfaisante, le processus en lui-même est alors grandement amélioré.
Pour cela, il doit exister une compréhension commune des processus impliqués dans tout le
développement du cycle de vie d’un projet de milieu bâti, y compris des informations requises et
des résultats de l’exécution de ce processus. Cela s’applique à toute activité qui entraîne un échange
d’informations et peut ne pas être directement associé à un BIM, par exemple dans un processus
d’élaboration d’un plan de travail ou d’un accord contractuel.
La présente partie de l’ISO 29481 définit une méthodologie permettant de produire un document de
référence intégré qui décrit les processus et les données nécessaires au développement ou à la gestion
d’une installation construite. Elle explique comment identifier et décrire les processus entrepris dans
ce contexte, les informations requises pour leur exécution, ainsi que les résultats. La présente partie de
l’ISO 29481 décrit également en termes généraux comment ces informations peuvent être détaillées en
vue de prendre en charge des solutions proposées par des développeurs de logiciels, permettant leur
réutilisation et conçues pour satisfaire des besoins nationaux, locaux ou de projets.
En bref, la présente partie de l’ISO 29481 donne une base pour un échange/partage d’informations
fiable entre les utilisateurs, afin qu’ils puissent avoir confiance en la précision des informations qu’ils
reçoivent et en leur adéquation aux activités qu’ils doivent réaliser. Le développement de la présente
partie de l’ISO 29481 a été guidé par le besoin des utilisateurs de disposer d’échanges d’informations
fiables.
NORME INTERNATIONALE ISO 29481-1:2016(F)
Modèles des informations de la construction — Protocole
d’échange d’informations —
Partie 1:
Méthodologie et format
1 Domaine d’application
La présente partie de l’ISO 29481 spécifie:
— une méthodologie qui relie les processus métier employés pendant la construction d’installations à
la spécification des informations requises par ces processus; et
— un moyen de cartographier et de décrire les processus d’information sur tout le cycle de vie des
travaux de construction.
La présente partie de l’ISO 29481 est destinée à faciliter l’interopérabilité entre les applications
logicielles utilisées à toutes les étapes du cycle de vie des travaux de construction, dont la préparation,
la conception, la documentation, la construction, l’exploitation et la maintenance, ainsi que la
déconstruction. Elle promeut la collaboration numérique entre les acteurs du processus de construction
et donne une base pour un échange d’informations précis, fiable, répétable et de haute qualité.
2 Références normatives
Les documents ci-après, dans leur intégralité ou non, sont des références normatives indispensables à
l’application du présent document. Pour les références datées, seule l’édition citée s’applique. Pour les
références non datées, la dernière édition du document de référence s’applique (y compris les éventuels
amendements).
ISO 6707-1, Bâtiments et ouvrages de génie civil — Vocabulaire — Partie 1: Termes généraux
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions de l’ISO 6707-1 ainsi que les suivants,
s’appliquent.
3.1
acteur
personne, organisation ou unité d’organisation (département, équipe, etc.) impliquée dans un processus
de construction
3.2
modélisation d’informations de la construction
BIM, bim information modeling
utilisation d’une représentation numérique partagée d’un objet construit (comprenant bâtiments,
ponts, routes, usines, etc.) pour faciliter les processus de conception, de construction et d’exploitation
et former une base fiable permettant les prises de décision
Note 1 à l’article: L’acronyme BIM signale également la représentation numérique partagée des caractéristiques
physiques et fonctionnelles de tout ouvrage de construction.
3.3
application logicielle de BIM
application logicielle utilisée pour créer, modifier, analyser, gérer, publier, partager, mettre fin ou
manipuler d’une quelconque manière les éléments d’un BIM
3.4
exigence professionnelle
exigence qui décrit en termes professionnels ce qu’il faut délivrer ou accomplir
3.5
contrainte d’information
déclaration qui définit formellement ou contraint le domaine d’application d’un élément d’information,
en raison d’un aspect du métier, d’une règle sous laquelle une organisation fonctionne ou d’une politique
ou décision influençant un processus
3.6
classe
type ou ensemble d’éléments partageant des attributs communs
3.7
ouvrage de construction
terme général désignant tout ce qui est construit ou qui est le résultat d’une opération de construction
[SOURCE: ISO 6707-1:2014, 3.1.1]
Note 1 à l’article: Ceci peut se référer à un bâtiment, un élément d’infrastructure civile (route, pont, canalisation,
etc.) ou à un élément de paysage et peut inclure les agrégations de ces éléments formant un quartier urbain, un
campus ou toute autre installation institutionnelle.
3.8
processus de construction
processus qui utilise des ressources de construction pour atteindre des résultats de construction
Note 1 à l’article: Chaque processus de construction peut être divisé en composants de processus.
3.9
exigence d’échange
ER, exchange requirement
ensemble défini d’unités d’informations devant être échangées pour prendre en charge une exigence
métier particulière lors d’une phase/une étape particulière, ou plusieurs, du processus
3.10
protocole d’échange d’informations
IDM, information delivery manual
documentation qui décrit le processus métier et donne des spécifications détaillées sur les informations
nécessaires qu’un utilisateur exerçant un rôle particulier doit fournir à une étape particulière d’un projet
Note 1 à l’article: Ceci peut être appelé une spécification d’échange d’informations (IDS).
3.11
composants IDM
éléments de base qui forment un IDM: cartes d’interaction/cartes de transaction, cartes de processus et
exigences d’échange
3.12
unité d’informations
élément d’information individuel, comme un identificateur de fenêtre ou la profondeur d’une pièce
3.13
carte d’interaction
représentation des rôles et des transactions relatifs à un objectif défini
2 © ISO 2016 – Tous droits réservés

3.14
cadre d’interaction
description formelle des éléments de l’interaction, comprenant la définition des rôles, des transactions,
des messages des transactions et des éléments de données dans les messages
3.15
modèle
représentation d’un système qui permet d’examiner les propriétés d’un système
3.16
définition de vue du modèle
MVD, model view definition
définition interprétable par ordinateur d’une exigence d’échange, spécifiquement associée à un ou
plusieurs schémas d’informations normalisés particuliers
Note 1 à l’article: Une définition de vue de modèle (MVD) est également appelée définition de vue, sous-ensemble
(d’un schéma) et classe de conformité (CC), en particulier dans l’ISO 10303.
3.17
objet
partie du monde qu’il est possible de percevoir ou de concevoir
Note 1 à l’article: Un objet est une chose mentale ou physique vers laquelle s’oriente une pensée, un sentiment ou
une action.
3.18
carte de processus
PM, process map
représentation des caractéristiques pertinentes d’un processus associé à un objectif professionnel défini
3.19
rôle
fonctions exécutées par un acteur à un moment
Note 1 à l’article: Le rôle d’un acteur est déterminé par l’action et le résultat et pas nécessairement par la
profession ou le métier exercé par l’acteur.
3.20
transaction
évènement de communication qui satisfait à une relation entre deux rôles
3.21
carte de transaction
représentation d’un ensemble de messages qui sont échangés entre des rôles dans un but particulier
4 Protocole d’échange d’informations
4.1 Généralités
Le présent article décrit une série de concepts et de principes qui renseignent le développement d’un IDM.
4.2 Utilisateurs de la présente partie de l’ISO 29481
Les principaux utilisateurs prévus sont les développeurs d’IDM qui créent des cartes d’interaction,
des cartes de processus, des exigences d’échange et des contraintes d’information basés sur leurs
connaissances acquises auprès des utilisateurs finaux et des fournisseurs de solutions.
De plus, certains utilisateurs d’IDM spécifiques peuvent identifier des besoins pour de nouveaux IDM et
devenir ainsi des utilisateurs de la présente partie de l’ISO 29481. Ces utilisateurs comprennent:
— les professionnels développeurs d’IDM et fournisseurs de solutions;
— les utilisateurs des informations, c’est-à-dire les utilisateurs exécutants et les utilisateurs finaux
concernés par la production de contenu des IDM et bénéficiant des résultats.
Un autre groupe d’utilisateurs est constitué des personnes qui utilisent la documentation qui résulte
de l’utilisation de la norme, prennent note des processus métier et des spécifications détaillées des
informations dont peut avoir besoin un utilisateur jouant un rôle particulier à un moment particulier
pendant un projet. Ces utilisateurs comprennent:
— le responsable de projet, chargé d’organiser le processus métier et de garantir que l’échange
d’informations est géré correctement;
— le responsable du BIM, qui prend les mesures nécessaires pour prendre en charge une exigence
d’échange;
— le client, qui initie (développe) et inclut un IDM dans le contrat;
— le sous-traitant/consultant, qui utilise l’IDM pour prendre les mesures nécessaires à la conformité
au processus métier requis et à l’échange d’informations requis;
— le responsable métier, qui utilise un IDM comme modèle ou norme à appliquer à de nombreux projets
au sein de son organisation;
— l’organisation de construction, qui utilise un IDM pour un type de projet spécifique comme modèle
ou norme à appliquer au secteur.
4.3 Contexte professionnel
La Figure 1 représente un exemple de contexte professionnel qui nécessite un IDM: un client
(rôle 1) engage un consultant (rôle 2) pour délivrer un service. Dans ce scénario, existe un besoin de
comprendre et de formaliser les aspects collaboratifs et contractuels de leur relation et la manière dont
les informations seront échangées dans ce contexte. L’IDM décrit les exigences d’information associées
à toutes les transactions (dans les deux sens) relatives à cette relation. Certaines de ces informations
sont contenues dans un BIM, tandis que d’autres peuvent provenir de l’une ou l’autre partie ou d’une
source externe.
Figure 1 — Exemple de contexte professionnel simple nécessitant un IDM
4 © ISO 2016 – Tous droits réservés

La première étape du développement d’un IDM consiste à tenir compte de la nature ou du contexte de
l’échange d’informations. Il existe deux moyens pour cela, chacun étant associé à une méthodologie.
— Les cartes de processus sont très utiles lorsque l’aspect principal est le processus métier (défini par
des activités exécutées par des acteurs dans des rôles) qui doit être suivi pour délivrer un service
ou produire un produit final (par exemple une conception). Dans ce cas, les informations qui sont
l’aspect principal de l’IDM sont associées à une exigence professionnelle.
— Les cartes d’interaction/cartes de transaction sont très utiles dans un processus métier lorsque
l’aspect principal est constitué par les interactions entre les acteurs dont le rôle est de délivrer un
service ou un produit et que le but est de garantir qu’il existe des protocoles de communication
agréés pour assurer que les objectifs du projet soient atteints. Dans ce cas, les informations qui sont
l’aspect principal de l’IDM sont associées à une transaction.
Ce sont des approches complémentaires, expliquées plus en détail dans les sections ultérieures. Dans
un contexte professionnel donné, il peut être approprié d’utiliser les deux méthodologies: la mise en
correspondance de processus peut être utilisée pour clarifier les détails d’une transaction identifiée
lors d’un exercice de mise en correspondance d’interactions, tandis qu’une carte d’interaction peut
être utilisée pour comprendre avec rigueur une transaction d’information définie dans une carte de
processus.
4.4 Schéma complet
Lorsque les exigences d’information sont satisfaites par un BIM, le schéma d’information complet qui
traite de toutes les informations requises pour tous les acteurs et pour toute la durée du processus de
construction est exhaustif et de grande dimension. Ce type de schéma est pertinent pour définir tous
les besoins d’information du projet pour tous les processus métier à toutes les étapes du cycle de vie,
mais ce n’est pas de cette manière que sont généralement délivrées les informations du projet.
4.5 Division du schéma complet pour prendre en charge des exigences
Il est plus habituel que les informations soient échangées sur un sujet particulier et que le niveau
de détails fourni dépende de l’étape du cycle de vie. Il peut s’agir d’un processus métier simple à un
moment spécifique du cycle de vie du projet, mais cela consiste couramment en unités d’informations
pouvant être pertinentes à plusieurs étapes du cycle de vie ou vis-à-vis de plusieurs processus métier.
Cela est couramment appelé une vue de modèle et consiste à déterminer les composants du schéma
d’information qu’il convient d’utiliser pour satisfaire aux exigences.
4.6 Prise en charge du processus de modélisation d’informations de la construction
Les éléments du schéma général d’information sont utilisés dans un modèle d’informations de
la construction (voir la Figure 2). Pour un processus métier particulier, seules certaines classes
d’information sont requises. De nombreux objets sont dérivés de chaque classe, chaque objet possédant
une identité (déterminée par un identifiant unique) et un état (déterminé par les valeurs données à
chaque attribut de l’objet). Les classes qui prennent en charge le processus métier forment un schéma
normalisé, ou vue de modèle, identifiable et unique.
Figure 2 — Prise en charge du processus BIM
4.7 Prise en charge du processus métier
Réaliser cela signifie que toutes les informations à échanger pour prendre en charge un processus
métier particulier ou une interaction lors d’étapes spécifiques du cycle de vie (dans un processus
métier) doivent être établies. Cela s’appelle une exigence d’échange.
Une exigence d’échange fournit une description des informations à échanger en termes non techniques.
Une exigence d’échange peut prendre en charge la communication d’informations d’objet qui
permet la construction et l’exploitation d’un projet ou elle peut prendre en charge la communication
d’informations de gestion qui contrôlent l’exécution du projet.
4.8 Prise en charge de la solution logicielle
Le passage de l’exigence d’échange définie à une mise en œuvre logicielle fournie par un fournisseur de
solutions implique le développement d’une définition de vue de modèle (MVD). Cette approche remplace
la nécessité de mise en œuvre de parties fonctionnelles comme défini dans les versions précédentes de
la présente Norme internationale.
4.9 Contenu de l’IDM spécifique
Le contenu d’un IDM spécifique doit:
— décrire le besoin d’échange d’informations dans le contexte métier;
— identifier les acteurs envoyant et recevant des informations;
— définir, spécifier et décrire les informations échangées pour satisfaire aux exigences à chaque
moment dans le contexte métier;
— garantir que les définitions, les spécifications et les descriptions sont fournies sous une forme utile
et facile à comprendre;
— créer des spécifications détaillées des informations capturées par les exigences d’échange pour
faciliter le développement d’applications logicielles de BIM; et
— garantir que les spécifications d’informations peuvent être adaptées aux pratiques de travail locales.
Les lignes directrices du développement de contenu ainsi que l’approche à suivre sont données à
l’Annexe A.
6 © ISO 2016 – Tous droits réservés

5 Cadre de l’IDM
5.1 Généralités
Un protocole d’échange d’informations comprend (Figure 3) les éléments suivants:
— une carte d’interaction/carte de transaction et/ou une carte de processus;
— une ou plusieurs exigences d’échange.
La carte d’interaction définit les rôles concernés et les transactions entre eux. Pour chaque transaction
définie, un rôle est l’initiateur et l’autre est l’exécutant. La carte de transaction correspondante définit
les messages d’une transaction et les règles qui s’appliquent à la séquence d’exécution.
La carte de processus représente un couloir d’activité pour chaque rôle et définit à l’intérieur du couloir
la séquence d’activités pertinentes que ce rôle doit exécuter. Les activités exécutées par différents rôles
peuvent présenter des relations qui nécessitent un échange d’informations sous forme de messages. Ces
messages correspondent à un message dans une transaction représentée dans une carte de transaction.
Figure 3 — Cadre de base de l’IDM
Certains messages peuvent transporter un paquet d’informations BIM, ce qui entraîne le besoin de
définition d’une exigence d’échange.
Une exigence d’échange comprend une description complète des informations qui doivent être incluses
dans un BIM associé à un message communiqué entre des rôles. Elle comprend des définitions des
exigences d’information, dont les références aux objets de la bibliographiethèque le cas échéant,
8 © ISO 2016 – Tous droits réservés

ainsi qu’une description des besoins, les lignes directrices pour son utilisation et toute contrainte
d’information pouvant s’appliquer.
La mise en œuvre technique d’une exigence d’échange est obtenue par le biais d’une définition de vue de
modèle. La mise en œuvre technique d’une carte d’interaction/carte de transaction est délivrée sous la
forme d’un cadre d’interaction.
5.2 Cadre de base
5.2.1 Généralités
Chaque composant d’IDM (carte de processus, carte d’interaction/de transaction ou exigence d’échange)
doit comprendre des informations d’en-tête et une description générale comme suit.
5.2.2 Informations d’en-tête de composant d’IDM
Chaque composant d’IDM doit inclure au moins les informations administratives suivantes:
— nom ou titre conformément aux règles de nommage données au Tableau 1;
— identifiant unique;
— étape du projet prise en charge par le composant;
— journal des changements qui identifie la création ainsi que tout changement apporté, avec l’auteur
et la date.
Tableau 1 — Règles de nommage
N° Règle de nommage
1 Chaque composant d’IDM doit porter un nom.
La première partie du nom est le préfixe:
—  er_ pour exigence d’échange;
2  —  im_ pour carte d’interaction;
—  pm_ pour carte de processus;
—  tm_ pour carte de transaction.
Le nom donné à chaque composant d’IDM comprend impérativement deux parties:
—  la première partie du nom est une action (ou une activité) requise et est exprimée par un verbe;
—  la seconde partie du nom est un objet qui reçoit l’action et est exprimée par un nom ou une phrase
nominale. Ce peut être un objet direct (comme dans «modèle de mur») ou un objet impliqué indirect
(comme dans «matériau associé» qui signifie associer {au mur} {le} matériau).
4 Tous les mots identifiables d’un nom sont séparés au moyen d’un caractère de soulignement «_».
Les composants d’IDM peuvent disposer de paramètres qui activent des qualifications supplémentaires.
Les paramètres sont exprimés sous forme de liste entre parenthèses, par exemple (a, b, c, d).
Une étape du projet doit être identifiée par une étape du cycle de vie. Une référence pour les étapes du
cycle de vie est donnée à l’Annexe C.
Lors de la livraison de chaque unité d’informations, il peut être utile de faire référence à l’exigence
d’échange qui spécifie le contenu.
5.2.3 Description générale des composants d’IDM
Chaque composant doit commencer par une description en langage clair du contenu, du cas d’usage,
des objectifs et du domaine d’application que le composant est destiné à traiter ou à propos duquel des
informations sur un sujet particulier ou une exigence professionnelle doivent être échangées.
Des exemples de composants d’IDM simplifiés sont donnés à l’Annexe B.
5.3 Carte d’interaction/carte de transaction
L’objet d’une carte de transaction est d’identifier les rôles et les transactions pertinents dans un but
spécifique, généralement l’achèvement d’une tâche d’équipe du projet. L’IDM effectue une distinction
entre le rôle qui fait une demande (l’initiateur) et le rôle qui exécute cette demande (l’exécutant).
S’il existe cette exigence de communication entre deux rôles, cette communication est appelée une
transaction.
L’approche recommandée pour préparer une carte d’interaction est celle du modèle CRISP (Dietz, J.L.G.:
Enterprise Ontology, Springer, 2006).
Dans une carte d’interaction, toutes les transactions nécessaires à la gestion des contributions requises
des rôles concernés par le BIM doivent être incluses. Toutes les transactions de la carte d’interaction
ont une identité et un nom uniques.
Une carte de transaction est une représentation des messages qui peuvent être échangés entre les
rôles participant à une transaction particulière, comprenant les contraintes sur la séquence. L’approche
recommandée pour préparer une carte de transaction est l’UML (diagramme de séquences).
Les messages sont échangés dans un certain but (p. ex. une demande de changement ou la livraison
d’un paquet d’informations). Un message est un modèle d’information rempli et contient des données
relatives au processus. Un message peut comprendre une ou plusieurs pièces jointes.
Au moyen des transactions, les exigences de coopération et de communication métier sont définies, ce
qui permet de contrôler les contributions au BIM des rôles pertinents. À cette fin, dans les transactions
spécifiques, les composants suivants peuvent être ajoutés en tant que pièces jointes aux messages
spécifiques:
— exigences d’échange;
— paquet d’informations (un ensemble de données d’objet qui est l’échange effectif d’informations qui
satisfait à une exigence d’échange);
— fenêtre d’autorisation: dans le contexte d’une transaction, un rôle exécutif (exécutant) peut accéder
aux applications logicielles de BIM. La fenêtre d’autorisation décrit les informations de cette
transaction qui peuvent être lues ou modifiées par le rôle.
5.4 Cartes de processus
L’objet d’une carte de processus est de décrire le flux d’activités dans les limites d’un processus métier
particulier, les rôles joués par les acteurs impliqués ainsi que les informations requises, consommées et
produites.
L’approche recommandée pour représenter les cartes de processus est la notation BPMN (Business
Process Modelling Notation). Des informations supplémentaires sur la notation BPMN sont données à
l’Annexe D.
Dans un IDM, la carte de processus:
— définit les limites d’extension des informations contenues dans le processus;
— établit les activités liées au processus; et
— représente la séquence logique des activités.
Les informations réelles qui se trouvent dans les limites du processus sont déterminées par le contenu
des exigences d’échange spécifiées dans le processus.
10 © ISO 2016 – Tous droits réservés

Une carte de processus comprend les informations administratives suivantes:
— les exigences d’échange qui se trouvent dans les limites du processus;
— une description générale complète du processus global. Des diagrammes peuvent être utilisés pour
illustrer des points particuliers de la description.
5.5 Exigences d’échange
5.5.1 Généralités
Une exigence d’échange définit les informations qui doivent être échangées pour prendre en charge
un processus métier particulier à une étape particulière du projet. Elle est destinée à fournir une
description des informations à échanger en termes non techniques. Une exigence d’échange doit être
compréhensible par les utilisateurs finaux (architecte, ingénieur, constructeur, etc.). Les exigences
d’échange sont utilisées pour créer une MVD, qui est une Spécification technique utilisée dans le
développement logiciel et spécifiée en 5.6.3.
Une exigence d’échange représente la connexion entre le processus et les données. Elle décrit un
ensemble d’informations d’un processus qui a été exécuté par un acteur dans le rôle de l’initiateur pour
permettre d’exécuter un processus en aval par un autre acteur dans le rôle de l’exécuteur. Il convient
qu’elle soit définie en ayant une bonne compréhension des besoins d’informations de l’acteur en aval.
5.5.2 Unités d’information
Les informations requises sont fournies sous forme d’unités d’information. Une unité d’information
traite généralement d’un type d’information ou concept d’intérêt. Une unité d’informations peut être
composée d’une entité unique, comme projet et mur ou d’une entité (p. ex. projet) et ses attributs (p. ex.
nom), comme nom du projet et dimensions du mur.
Les conditions préalables à l’exigence d’échange sont identifiées en premier lieu. Une condition préalable
est une exigence d’échange qu’il convient de réaliser avant l’exécution de l’exigence d’échange en cours.
Il convient de spécifier ensuite les unités d’informations pour donner les éléments suivants:
— une description de l’unité d’informations: Il convient que la description soit aussi explicite que
possible et non ambiguë, afin de ne pas confondre les modélisateurs MVD avec d’autres concepts;
— les informations à échanger pour que les dispositions de cette unité d’informations soient satisfaites.
Il convient que ceci inclue toutes dispositions, propositions ou règles spéciales relatives aux
informations.
5.5.3 Contraintes d’information
Les contraintes d’information spécifient le type de données d’une unité d’informations, ainsi qu’un
contexte, des règles et les restrictions d’utilisation quant à l’emploi de l’unité d’informations spécifiée.
Voici quelques exemples de type de données et de règles.
— Types de données:
— texte, nombre entier, nombre, graphique en 2D, modèle en 3D, etc.
— Contexte, règles et limites d’utilisation:
— une table doit posséder au moins trois pieds;
— une pièce en béton préfabriqué doit posséder au moins trois identifiants: une marque pour la
pièce (un numéro de série de production), un numéro de marquage (un numéro de conception)
et un identifiant de lieu d’installation;
— la surface d’une pièce ne peut pas être inférieure à 0 m ; et
— la taille maximale d’un panneau ne peut pas dépasser 14 m pour pouvoir être livré par un
camion normal.
5.6 Mise en œuvre technique
5.6.1 Généralités
La présente partie de l’ISO 29481 traite spécifiquement de la préparation d’une description en langage
commun des exigences d’information de processus métier, en particulier de ceux qui impliquent
l’échange de données de BIM. Ces spécifications d’information peuvent être utilisées comme base pour
les processus automatiques mettant en jeu l’utilisation d’applications logicielles, appelées ici mises en
œuvre techniques.
Le présent article décrit les principes et le domaine d’application de mises en œuvre techniques
disponibles, chacune étant traitée dans une partie distincte de la présente série de normes.
5.6.2 Mise en œuvre des métadonnées
L’intention première derrière toutes les mises en œuvre techniques est que la spécification doit
être convertie en une forme lisible par un ordinateur qui comprend des métadonnées clés (en-tête,
description, classification) requises pour le processus automatisé.
5.6.3 Cadre d’interaction
Un cadre d’interaction est une description formelle des éléments de l’interaction, comprenant la
définition des rôles, des transactions, des messages des transactions, de la séquence des messages et des
éléments de données dans les messages. La méthodologie du développement d’un cadre d’interaction et
de son format se trouve dans l’ISO 29481-2.
5.6.4 Définition de vue du modèle (MVD)
Une MVD définit un modèle de données ou un sous-ensemble d’un modèle de données existant qui est
nécessaire à la prise en charge d’une ou plusieurs exigences d’échange de données spécifiques (Figure 4).
Les MVD sont utilisées dans le développement logiciel et il convient qu’elles soient représentées sous
une forme lisible par machine. Une MVD qui est dédiée à un seul IDM peut être utilisée pour filtrer
les informations des outils logiciels pour une exigence d’échange spécifique. Si des contraintes
d’information sont ajoutées à une MVD, la combinaison peut être utilisée à des fins de validation de
données. Les produits logiciels prenant en charge un certain nombre d’exigences d’échange peuvent
mettre en œuvre une MVD consolidée qui se réfère à plusieurs IDM. Ces MVD sont souvent utilisées
dans la certification de produits logiciels, mais il convient que la validation des données soit toujours
effectuée sur les MVD individuelles.
12 © ISO 2016 – Tous droits réservés

Figure 4 — Relation entre IDM et MVD
Annexe A
(informative)
Processus de développement de l’IDM
A.1 Proposer le développement d’un IDM
A.1.1 Informations générales
La proposition d’entreprendre le développement d’un IDM est une étape préliminaire qui définit le
travail à effectuer. Elle traite les aspects suivants:
— définition du domaine d’application;
— établissement de l’approche de développement;
— identification des ressources; et
— établissement d’un plan de projet.
A.1.2 Définir le domaine d’application
Il convient que le domaine d’application définisse les limites du travail à effectuer et donne une référence
permanente pour garantir que les limites du travail ne s’étendent pas au-delà d’un point auquel les
ressources planifiées ou disponibles ne sont plus suffisantes.
Il convient que la préparation réponde aux questions suivantes:
— Quels sont les besoins professionnels d’échange d’informations?
— Qui est capable de décrire ces besoins?
— Quels sont les acteurs et quels sont leurs rôles et leurs intérêts?
— Comment préparer et gérer l’échange d’informations?
— Les accords, conditions contractuelles, normes, etc. existants prennent-ils en charge l’échange
d’informations?
La préparation se termine par une évaluation de la possibilité de satisfaire au domaine d’application
et aux critères de réussite déclarés. Si l’évaluation est positive, le développement effectif de l’IDM
peut être initié. Si l’évaluation se révèle négative, il est possible de revoir le cas d’usage
...