ISO 29481-2:2025
(Main)Building information models — Information delivery manual — Part 2: Interaction framework
Building information models — Information delivery manual — Part 2: Interaction framework
This document specifies a methodology for describing and managing interactions and a format for digital communication between actors in any use case associated with the management of an asset during all life cycle stages. It provides: — a methodology that describes an interaction framework for a use case; — an appropriate way to map responsibilities and interactions that provides a process context for information flow; — a format in which the interaction framework is specified and executed. This document is intended to promote secure, verifiable, traceable and high-quality digital IDM communication between actors during all phases of the life cycle of assets, facilitate interoperability between software applications used, and to provide a basis for data- and process-driven information exchange and traceability of communication.
Modèles des informations de la construction — Protocole d’échange d’informations — Partie 2: Cadre d’interaction
Le présent document spécifie une méthodologie pour décrire et gérer les interactions ainsi qu’un format pour la communication numérique entre les acteurs dans tout cas d’usage associé à la gestion d’un actif au cours de toutes les phases de son cycle de vie. Il fournit: — une méthodologie qui décrit un cadre d’interaction pour un cas d’usage; — une manière adaptée de mettre en correspondance les responsabilités et les interactions, qui donne un contexte aux flux d’informations d’un processus; — un format dans lequel le cadre d’interaction est spécifié et mis en œuvre. Le présent document a pour objectif de promouvoir une communication IDM numérique sécurisée, vérifiable, traçable et de haute qualité entre les acteurs au cours de toutes les phases du cycle de vie des actifs, de faciliter l’interopérabilité entre les applications logicielles utilisées et de fournir une base pour les échanges d’informations axés sur les données et les processus ainsi que pour la traçabilité de la communication.
General Information
Relations
Standards Content (Sample)
International
Standard
ISO 29481-2
Second edition
Building information models —
2025-12
Information delivery manual —
Part 2:
Interaction framework
Modèles des informations de la construction — Protocole
d’échange d’informations —
Partie 2: Cadre d’interaction
Reference number
© ISO 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
3.1 General .2
3.2 Technical components.2
4 Notation . 2
5 Interaction framework . 3
5.1 General .3
5.2 Information management and the interaction framework .3
5.3 Purpose of an interaction framework .5
5.4 Hierarchical structure of an interaction framework .5
5.4.1 General .5
5.4.2 Roles .6
5.4.3 Transactions .7
5.4.4 Messages .8
5.4.5 Complex and simple elements .10
5.5 Establishing a digital IDM communication project .10
5.5.1 General .10
5.5.2 Modelling the interaction framework .11
5.5.3 Creating and using the interaction framework schema .11
5.5.4 Using a project specific message to link a person to roles . 12
5.5.5 Executing digital IDM communication . 12
5.5.6 Validating digital IDM communication . 13
5.5.7 Signing messages with advanced electronic signatures . 13
5.5.8 Changing the project during execution .14
5.5.9 Archiving digital IDM communication.14
6 Schemas for validating interaction frameworks and messages .15
6.1 Basic principles . 15
6.2 Types of elements .16
6.3 Element types in the interaction framework schema and _2 EXPRESS source file .17
6.3.1 General .17
6.3.2 Primary element types .18
6.3.3 Secondary element types . 28
6.3.4 References .31
6.4 Element types in the interaction message schema and the _5 EXPRESS source file .37
6.4.1 General .37
6.4.2 Primary element types . 38
6.4.3 Secondary element types .43
6.4.4 References .45
Annex A (normative) Interaction framework schema definition .51
Annex B (normative) Templates definition .52
Annex C (informative) Promotor algorithm .53
Annex D (informative) Example interaction framework XML of a simplified design office use
case .54
Annex E (informative) Example project specific message XML of a simplified design office use
case . 67
Annex F (informative) Example message XML of a simplified design office use case .72
iii
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).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 59, Buildings and civil engineering works,
Subcommittee SC 13, Organization and digitization of information about buildings and civil engineering
works, including building information modelling (BIM), in collaboration with the European Committee
for Standardization (CEN) Technical Committee CEN/TC 442, Building Information Modelling (BIM), in
accordance with the Agreement on technical cooperation between ISO and CEN (Vienna Agreement).
This second edition cancels and replaces the first edition (ISO 29481-2:2012), which has been technically
revised.
The main changes are as follows:
— introduced updates that better integrate the interaction framework within the concept of digital IDM
communication;
— aligned terminology and practices with other related standards.
A list of all parts in the ISO 29481 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iv
Introduction
Collaboration between the participants involved during the life cycle of assets is pivotal to the efficient
delivery and operation of assets. Organizations collaborate within specific use cases to achieve higher levels
of quality and greater re-use of existing knowledge, information experience and resources. A significant
condition of collaboration is the opportunity to communicate, re-use and share information efficiently, and
to reduce the risk of loss, contradiction or misinterpretation.
The ISO 29481 series on the information delivery manual (IDM) provides significant assistance in making
the most of information management. If the necessary information is available at the right time, the quality
of the information is satisfactory and the right person is involved at the right time, the collaboration and
outcome itself is greatly improved. Since management and coordination rely heavily on communication,
it benefits from being well structured, unambiguous, explicit and timely. This is supported by a common
understanding of the purpose, the processes, the actors involved and the information needed.
This document focuses on the foundations for and execution of digital communication in accordance with
the processes and information requirements of a use case. With a focus on communication, this document
offers a natural complement to standards that focus on information management such as the ISO 19650
series, information containers such as the ISO 21597 series and information modelling such as ISO 16739-1
and ISO 10303-239.
This document describes how to use various components of an IDM for verifiable and traceable execution
of digital communication. The resulting interaction framework enables standardization of digital
communication in construction processes within any collaboration within and between organizations.
As digital communication spans the entire life cycle of assets and occurs in projects of all sizes and
complexities, a standardized IT approach can benefit a wide range of stakeholders. Support for this standard
in various ICT solutions means that various information management systems are connected. By doing so, it
provides a basis for reliable information exchange and sharing for users, so that they can be confident that
the information they send or receive is accurate and sufficient for the coordination activities they need to
perform. This provides a basis for using common data environment (CDE) solutions and workflows.
v
International Standard ISO 29481-2:2025(en)
Building information models — Information delivery
manual —
Part 2:
Interaction framework
1 Scope
This document specifies a methodology for describing and managing interactions and a format for digital
communication between actors in any use case associated with the management of an asset during all life
cycle stages.
It provides:
— a methodology that describes an interaction framework for a use case;
— an appropriate way to map responsibilities and interactions that provides a process context for
information flow;
— a format in which the interaction framework is specified and executed.
This document is intended to promote secure, verifiable, traceable and high-quality digital IDM
communication between actors during all phases of the life cycle of assets, facilitate interoperability between
software applications used, and to provide a basis for data- and process-driven information exchange and
traceability of communication.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 29481-1, Building information modelling — Information delivery manual — Part 1: Methodology and format
ISO 14533-2, Processes, data elements and documents in commerce, industry and administration — Long term
signature — Part 2: Profiles for XML Advanced Electronic Signatures (XAdES)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 29481-1 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1 General
3.1.1
message
information prepared for communication purposes
[SOURCE: ISO 5127:2017, 3.1.8.02]
3.1.2
digital IDM communication
exchange of messages (3.1.1) within the confines of a use case enabled by an interaction framework and
project specific message (3.2.1)
3.2 Technical components
3.2.1
project specific message
PSM
structured file that places the interaction framework in the context of a specific project by linking roles to
persons and associated organizations
3.2.2
interaction framework schema
XML schema definition file used to validate an interaction framework
3.2.3
interaction message schema
XML schema definition file used to validate a message (3.1.1)
3.2.4
promotor
algorithm that generates an interaction framework schema (3.2.2) from an interaction framework, with the
support of a template definition (3.2.5) used as input
3.2.5
templates definition
file containing a number of templates, independent of the specific interaction framework, for generating an
interaction framework schema (3.2.2) and an interaction message schema (3.2.3)
4 Notation
The following notation conventions apply in this document:
— this document follows the notations used in ISO/IEC 23009-1 for describing elements in an XML document;
— primary element types are identified by an upper-case first letter as Element; if an element’s name
consists of two or more combined words, PascalCase is used, e.g. ImportantElement;
— secondary element types, attributes and references are identified by a lower-case first letter; if one of these
consists of two or more combined words, camelCase is used after the first word, e.g. importantAttribute;
— elements are graphically displayed as unified modelling language (UML) diagrams; this document
follows the graphic notations used in ISO 24156-1.
5 Interaction framework
5.1 General
This clause explains the core concepts and principles for the development and use of an interaction
framework for digital IDM communication. By following the methodology presented in this document,
users of software tools can model (in a machine interpretable XML file) the business context and exchange
requirements of a specified use case and subsequently start to digitally communicate with each other based
on that interaction framework.
5.2 Information management and the interaction framework
Information management involves defining, producing, checking, and delivering information. Every team
member in any business activity interacts with information management to some extent. The importance
of documented responsibility and accountability in information management is crucial, because focusing
on good information management leads to better project outcomes. To be effective, there shall be a shared
understanding of the processes and the necessary information required for each step of their execution.
An IDM captures the business context associated with a use case and defines a detailed specification of
the information that a user fulfilling a particular role would need to provide at a particular stage within a
business process to create a product or deliver a service.
Generally speaking, a use case involves delivering goods or providing services to customers or clients. As
soon as a customer or client requests the delivery of a batch of goods or the provision of a service, a chain of
activities is set in motion to fulfil that request. Such a chain of activities is called a business context.
This leads to the basic framework of an IDM as illustrated in Figure 1. Each use case has an associated
business context and required information.
Key
association
inheritance
aggregation
composition
Figure 1 — IDM Basic framework
The business context is usually represented in an IDM by any combination of interaction maps and process
maps, supported by textual representations or graphic information. The analysis of the business context
may be thought of as a discovery process using those two mapping approaches since their purpose is to
clearly show how the information exchange requirements for the use case are derived.
An exchange requirement provides a description of the information to be exchanged between roles in
natural language terms to support a particular business process in the relevant life cycle stage (within a
business context). An exchange requirement may support either (or both) the communication of information
essential to the design, construction, operation and deconstruction of an asset or it may support the
communication of management information with messages that control project execution in relation to the
life cycle management of the asset.
To deliver a service or produce a product within a use case, actors perform various activities. Taken in their
entirety, these form the business context. Often, within the business context there are chains of activities that
provide sub products or services, these are called business processes. At certain points in time, information
is needed by an actor to fulfil their task, or it is part of their responsibility to deliver specific information.
When this information is transferred from one actor to another, an interaction occurs. The receiving actor
determines if the information is complete and correct.
An information exchange therefore is never a single activity, it is a (digital) conversation between two actors
to satisfy a specific information requirement.
This document focuses on formally structuring, recording and supporting these interactions and their
requirements to achieve an outcome. This is known as performative communication.
5.3 Purpose of an interaction framework
The interaction framework is the core of digital IDM communication. It is a formal technical XML description
that includes all elements necessary for interactions within use cases, such as roles, transactions, messages
in transactions, and data elements in messages. The scope of an interaction framework aligns with the scope
of a use case in an IDM.
Creating an interaction framework not only allows the identification of detailed information exchange
requirements but also facilitates (through compatible software) verifiable and traceable digital IDM
communication between participants during all phases of the life cycle of assets. When properly set up, an
interaction framework forms the foundation for software tools to enable users to communicate digitally
and purposefully through messages based on the processes, roles, exchange requirements, and information
defined by the IDM. Digital IDM communication through an interaction framework enables better process
control, improved data management, increased transparency, enhanced verifiability of agreements, and a
higher quality of the final product. A software tool utilizing an interaction framework structures, monitors,
and stores communication by providing a shared digital communication archive. It clarifies responsibilities
and decisions promptly, keeps project archives up-to-date and complete, facilitates faster and more flexible
partnerships, and prevents miscommunication.
Since the process and content resides in the machine-readable interaction framework rather than being
embedded in a software tool, a software solution implementing this method can support and improve
collaboration of any use case without specialized software.
It also ensures interoperability between software tools that support this document, facilitating seamless
messaging between applications. Every organization may freely choose software tools that implement the
interaction framework, ensuring secure messaging between them. This guarantees each party complete
access to mutual communication through their own chosen software while shielding internal communication
from the collaborating partners.
The basic principles, terms and concepts of the modelling of interactions that this document prescribes are
1)
based on design and engineering methodology for organizations (DEMO) .
DEMO is a method for analysing and (re)designing organizations, in which human action is central. DEMO
describes the structure of an organization, abstracted from the implementation. It describes what happens
or should happen rather than how it happens. The focus is on the essence of an organization: what the
organization does, not how it does it. A DEMO model describes a partnership, either within an organization
and across organizations. A DEMO model forms a consistent set of products, responsibilities, processes,
information and business rules and gives an overview of, and insight into, organizations.
5.4 Hierarchical structure of an interaction framework
5.4.1 General
An interaction framework incorporates all necessary digital interactions and roles to realize the purpose of
a use case. Figure 2 illustrates the hierarchy of definitions within this document. Each transaction defines
1) The methodology of DEMO originated from science and was developed at Maastricht University and Delft University
of Technology by prof. dr. Jan Dietz (Reference [11]). It builds on various theories including systems theory (Reference
[17]), philosophy of language (References [10] and [16]), communicative action (Reference [14]), data modelling
(Reference [15]) and ontologies (Reference [13]). In collaboration with universities in Antwerp (Belgium), Duisburg
(Germany), Bolzano (Italy), Luxembourg, Vienna (Austria), Lisbon and Madeira (Portugal), Prague (Czech Republic), St.
Gallen (Switzerland), San Jose (USA) and Tokyo (Japan). The latest version of the methodology (DEMO-4) was released
in 2020. The further development of the DEMO methodology is supported by the international Enterprise Engineering
Institute.
a sequence of messages exchanged between two roles. A message is a digital form, including possible
attachments, comprising data elements, which are categorized as complex and simple elements. The
behaviour of simple elements is determined by its user defined type and element conditions.
Figure 2 — Interaction framework with the hierarchy of its components
5.4.2 Roles
When defining a use case, roles are assigned to responsibilities and tasks, not specific functions or positions
within an organization. This is because the same roles consistently appear in business contexts, but
individuals in different functions or positions may fulfil multiple roles or switch between them. For example,
actors may fulfil roles such as 'initiator', 'client', 'builder', or 'designer'. The name of the role is derived from
its primary activity, emphasizing the role's contribution within transactions.
A key principle is that actors with roles negotiate with authority and responsibility. Only actors can make
agreements, take decisions, pass judgments, and enter into contracts. Roles therefore have to fulfil certain
qualifications.
There is not always a one-to-one relationship between actors and roles. In some business processes, one
actor may assume multiple roles, while in others, several actors may share the same role. For instance, a
municipality can be both the initiator and the client, or a contractor for earthworks and an installation
company may both take on the role of builder. An actor may also fulfil different roles across different
business processes.
Every interaction framework includes defined roles to streamline responsibilities and tasks. This approach
ensures clear and effective collaboration, providing a structured method to manage various functions
efficiently within the business activity. Roles may also be reassigned if project members leave, and
authorizations may be granted so others may take over their work. The audit trail always remains intact,
allowing visibility about who did what and when.
5.4.3 Transactions
5.4.3.1 General
Each interaction framework consists of one or more transactions, defined by the use case and the associated
business context. In an interaction framework a transaction is a sequence of messages between two roles.
As shown in Figure 3, each transaction has an initiator (the role that starts the transaction) and an executor
(the role that carries out the transaction).
Figure 3 — A transaction always involves only two roles
Using transactions within information management brings information transfer into a process context. This
ensures that information is exchanged systematically and purposefully within a structured digital process.
Organizations using an interaction framework transition from document-driven to data-driven workflows
by digitally managed information and processes.
5.4.3.2 Business process scenarios and sub transactions
Depending on the business context and use case, an interaction framework may contain one or several
transactions. Within the business context, multiple transactions between roles are sometimes required in
sequence to achieve a goal. For example, when a role in transaction A prepares information that another role
in transaction B must review. In such cases, transactions shall be linked, forming a workflow known as a
business process scenario.
In a business process scenario, there is always a main transaction where the initial request is made linked to
one or more sub transactions. Sub transactions are designed to cascade from the main transaction. This is
detailed in 6.3.2.10.
5.4.3.3 Interaction map
2)
All necessary roles, transactions and sub transactions of a use case are described by the interaction map in
an IDM. This is an abstract representation that defines the boundary of a use case and highlights the essential
communication chain required to fulfil its purpose. The name is derived from the fact that it records the
interaction between the actors, i.e. their direct mutual influence. It leaves out all the activities and various
process steps. The use of abstract roles makes the interaction map applicable to various situations. Figure 4
shows a simplified example of an interaction map for a design office use case.
2) In DEMO terms the interaction map is called a coordination structure diagram.
Figure 4 — Example of an interaction map of a design office use case
All roles and transactions in the interaction map have a unique identity and name, with numbering being
arbitrary. Roles are named based on their primary activities, emphasizing their contributions to the use
case. A composite role consists of multiple roles, but its composition is not relevant to the use case's scope.
5.4.3.4 Transaction product table
Each transaction has an intended result, also referred to as the product of that transaction. Together with
the transactions and roles described by the interaction map, this can be summarized in a transaction
product table. This table records the transaction kind (the name and unique number of each transaction),
the product kind (the product of each transaction) and its initiating and executing roles. See Table 1 for an
example.
Table 1 — Transaction product table of a simplified design office use case
Product kind Transaction kind Initiator role Executor role
Design is delivered T , Deliver design CR Client R Project leading
1 1 1
System specification is deliv- T , Deliver system specifica- R Project leading R System engineering
2 1 2
ered tion
3D model is delivered T , Deliver 3D model R Project leading R 3D engineering
3 1 3
Cost calculation is delivered T , Deliver cost calculation R Project leading R Cost engineering
4 1 4
5.4.4 Messages
5.4.4.1 General
To realize the product of a transaction, interactions take place between two roles. In the digital world, these
interactions are performed by means of digital messages. A transaction contains a set of messages that are
exchanged for a specific purpose. The transaction also specifies the participating roles, the point in the life
cycle, and the sequence in which messages should be delivered (if applicable).
In terms of the IDM methodology, a message may carry information that satisfies the exchange requirement.
This information may consist of textual values entered directly into the message, or of attachments.
Attachments may be of any type, including structured information containers such as IFC files or information
container for linked document delivery (ICDD) and unstructured information containers such as documents,
spreadsheets, images, video files, and drawings. The interaction framework message also supports the
inclusion of metadata, such as version number, document date, and status. For certain message types, it may
be mandated that at least one attachment shall be added, and specific attachment types may be enforced by
the interaction framework.
5.4.4.2 Sequence of messages
Sets of messages in a transaction form a chain with a beginning and an end. Most process diagrams provide
an "ideal flow”, the best-case scenario of communicative actions where both actors fulfil their role without
dispute. However, in practice, processes rarely follow this ideal flow because humans can make mistakes, so
all possible outcomes should be considered, such as the need for adjustments or scenarios where a model is
not approved.
For example, a transaction involving a request for a 3D model (see Figure 5) illustrates a message sequence
in a transaction as a sequence diagram in UML notation. The transaction is initiated by R project leader
with the message 'Request for 3D model.' The 3D engineer (role R3) responds with 'Work done and request
for approval.' After a message 'Work approved' or 'Work not approved,' the transaction is completed.
The start message has no preceding message, being the only way to distinguish it from the other messages.
Similarly, the final message has no following message. Each message has a direction indicated by the labelled
arrow. A message may have several previous messages, e.g. a message approval may follow a delivery, but
also a renewed delivery. Similarly, the final message may contain both a reject and an approval. Therefore,
the chain of messages is not linear, but rather a mathematical graph.
Figure 5 — Example of messages in a transaction
5.4.5 Complex and simple elements
A message is essentially a 'form' with data fields and attachments where required. Each message has
a header with details of the involved roles and the date and time the message was sent. The body of the
message includes the information to be transferred, such as: text fields, dates, amounts, yes/no, list boxes,
and tables. During digital IDM communication the data in the fields is stored in the database of the software
that executes it.
Each data field in a message is called a “simple element”, which is always part of a group called a “complex
element”. Each complex element may contain one or more simple elements. Simple elements may be made
mandatory or optional for users to fill in within a message. Each message shall contain at least one complex
element with at least one simple element, although a simple element may be empty. To create a table a
complex element shall be nested within another complex element.
The behaviour, restrictions (e.g. minimum length) and validation of simple elements are determined by their
UserDefinedType. During digital IDM communication inheritance takes place. In principle, data entered in a
simple element in a previous message are sent in a subsequent message, unless a so-called element condition
has been included in the interaction framework.
See Figure 6 for an example of complex and simple elements in the message “Proposal request for change.”
Figure 6 — Example of complex and simple elements within a message
There is no rule about which data fields should be included in a message and which data should be in
attachments created with other software tools. Depending on the level of detail needed for communicative
decision-making, traceability and datamining purposes of the use case an interaction framework designer
can decide to include or exclude data elements.
5.5 Establishing a digital IDM communication project
5.5.1 General
After the use case and the associated business context and exchange requirements are analysed, a digital
IDM communication project can be set up. The scope of a digital IDM communication project equals the
scope of the associated use case. The term project is explicitly not seen here as a construction term (e.g. the
execution of a construction project), but as a generic term in which users can collaborate on a specific task.
A software tool that works according to this document can support multiple projects, each containing an
active interaction framework. Each project has a version history containing an active, as well as any possible
previous interaction frameworks that were added, for example when a transaction was added, or the content
of a message was changed. To avoid technical and legal problems, a transaction is always processed in the
version of the interaction framework in which it was started.
5.5.2 Modelling the interaction framework
An interaction framework is essentially an XML (Extensible Markup Language) file, which allows data to
be described in a specific computer interpretable structure. Since XML data is stored in plain text, XML is
software and hardware independent and may therefore be used to exchange data between incompatible
systems. To define how an interaction framework XML file should be set up an XML schema definition (XSD)
file is used. This XSD file is named the interaction framework schema. The interaction framework schema
determines the structure of an interaction framework XML file. It defines what elements and attributes may
or should be used, their relationship to each other and what types of data may be in them. The XSD may then
be used by validation software to validate or proactively help create an interaction framework XML file.
The interaction framework schema serves two primary functions:
— to define the structure of the interaction framework XML file;
— to specify the elements, attributes, conditions and relationships within the interaction framework.
EXAMPLE The interaction framework schema defines that an interaction framework includes the definition of
primary element types (e.g. SimpleElementType) and restrictions to primary element types (e.g. UserDefinedType) in
an interaction framework.
To model an interaction framework efficiently in XML, the components described in the interaction
framework schema such as TransactionTypes, MessageTypes, ComplexElementTypes, SimpleElementTypes
may be used multiple times, to allow the same content to be used in multiple places. Interaction frameworks
therefore often use references to the same components.
Each component contains a standard set of information, including ID and description. Transactions,
messages, complex and simple elements may also contain help information that a compatible software tool
can display to the user to help them better understand the purpose of the associated element.
There are specialized software tools that create and edit interaction frameworks. However, no specialized
software is necessary to create an interaction framework. An interaction framework may be created with
any tool that supports the creation of an XML file.
5.5.3 Creating and using the interaction framework schema
To determine if an interaction framework is correctly coded, it shall be validated. This validation is performed
by a software tool that checks the interaction framework against the interaction framework schema.
To generate XML schema definitions, such as the interaction framework schema, this document uses
EXPRESS source files (.EXP), as defined by ISO 10303-11.
The EXPRESS file serves as a foundational model due to its formal and precise language, which captures
complex relationships and constraints. It provides a clear, authoritative model that defines the data schema.
From this model, various schema formats, including XSD, may be derived, ensuring a future proof method.
A key advantage of using EXPRESS is its ability to handle complex data models more efficiently and with
fewer redundancies than XSD. In EXPRESS, data types and relationships are defined once and referenced
throughout the schema. XSD does not have the same level of abstraction or reusability, resulting in repeated
elements or data types, which makes an XSD schema challenging to maintain and prone to errors. When
changes to the underlying data model or rules are necessary, updating the EXPRESS schema ensures an
efficient approach and consistency across all other generated schemas, including the XSD.
To facilitate the conversion from EXPRESS to XSD, this document employs a generic algorithm, referred to as
promotor (see Annex C). This algorithm converts the EXPRESS schema into an XSD format that is compatible
with broader web-based systems, while preserving the accuracy and complexity of the original model. This
method ensures that the complex industry-specific rules are preserved during conversion, which would
be difficult to achieve with XSD alone. This structured approach minimizes human error and ensures
consistency across different data exchange scenarios.
Clause 6 describes in detail how the interaction framework schema is created and specifies all available
clas
...
Norme
internationale
ISO 29481-2
Deuxième édition
Modèles des informations de la
2025-12
construction — Protocole d’échange
d’informations —
Partie 2:
Cadre d’interaction
Building information models — Information delivery manual —
Part 2: Interaction framework
Numéro de référence
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2025
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, 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, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii
Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
3.1 Généralités .2
3.2 Composants techniques .2
4 Notation . 2
5 Cadre d’interaction . 3
5.1 Généralités .3
5.2 Gestion de l’information et cadre d’interaction .3
5.3 Objectif d’un cadre d’interaction .5
5.4 Structure hiérarchique d’un cadre d’interaction .6
5.4.1 Généralités .6
5.4.2 Rôles .6
5.4.3 Transactions .7
5.4.4 Messages .8
5.4.5 Éléments simples et complexes .10
5.5 Mise en place d’un projet de communication IDM numérique .11
5.5.1 Généralités .11
5.5.2 Modélisation du cadre d’interaction .11
5.5.3 Création et utilisation du schéma de cadre d’interaction . 12
5.5.4 Utilisation d’un message spécifique au projet pour relier une personne à des
rôles. 12
5.5.5 Exécution de la communication IDM numérique . 13
5.5.6 Validation de la communication IDM numérique .14
5.5.7 Signature des messages avec des signatures électroniques avancées .14
5.5.8 Modification du projet en cours d’exécution . 15
5.5.9 Archivage de la communication IDM numérique . 15
6 Schémas de validation des cadres d’interaction et des messages .16
6.1 Principes de base .16
6.2 Types d’éléments .17
6.3 Types d’éléments dans le schéma de cadre d’interaction et le fichier source EXPRESS _2 .18
6.3.1 Généralités .18
6.3.2 Types d’éléments primaires .19
6.3.3 Types d’éléments secondaires . 29
6.3.4 Références . 33
6.4 Types d’éléments dans le schéma de message d’interaction et le fichier source
EXPRESS _5 . 39
6.4.1 Généralités . 39
6.4.2 Types d’éléments primaires . . 40
6.4.3 Types d’éléments secondaires .45
6.4.4 Références .47
Annexe A (normative) Définition du schéma de cadre d’interaction .54
Annexe B (normative) Définition des modèles .55
Annexe C (informative) Algorithme convertisseur .56
Annexe D (informative) Exemple de cadre d’interaction XML d’un cas d’usage simplifiéd’un
bureau d’études .57
Annexe E (informative) Exemple de message spécifique au projet XML d’un cas d’usage simplifié
d’un bureau d’études .70
iii
Annexe F (informative) Exemple de message XML d’un cas d’usage simplifié d’un bureau
d’études .75
Bibliographie .85
iv
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’ISO attire l’attention sur le fait que la mise en application du présent document peut entraîner l’utilisation
d’un ou de plusieurs brevets. L’ISO ne prend pas position quant à la preuve, à la validité et à l’applicabilité
de tout droit de brevet revendiqué à cet égard. À la date de publication du présent document, l’ISO n’avait
pas reçu notification qu’un ou plusieurs brevets pouvaient être nécessaires à sa mise en application.
Toutefois, il y a lieu d’avertir les responsables de la mise en application du présent document que des
informations plus récentes sont susceptibles de figurer dans la base de données de brevets, disponible à
l’adresse www.iso.org/brevets. L’ISO ne saurait être tenue pour responsable de ne pas avoir identifié de tels
droits de brevet.
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 nature volontaire des normes, 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 www.iso.org/avant-propos.
Le présent document a été élaboré par le comité technique ISO/TC 59, Bâtiments et ouvrages de génie civil,
sous-comité SC 13, Organisation et numérisation des informations relatives aux bâtiments et ouvrages de
génie civil, y compris modélisation des informations de la construction (BIM), en collaboration avec le comité
technique CEN/TC 442, Modélisation des informations de la construction (BIM) du Comité européen de
normalisation (CEN), conformément à l’Accord de coopération technique entre l’ISO et le CEN (Accord de
Vienne).
Cette deuxième édition annule et remplace la première édition (ISO 29481-2:2012), qui a fait l’objet d’une
révision technique.
Les principales modifications sont les suivantes:
— introduction de mises à jour qui intègrent mieux le cadre d’interaction dans le concept de communication
IDM numérique;
— alignement de la terminologie et des pratiques avec les normes collatérales.
Une liste de toutes les parties de la série ISO 29481 se trouve sur le site web de l’ISO.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l’adresse www.iso.org/fr/members.html.
v
Introduction
La collaboration entre les personnes impliquées dans le cycle de vie des actifs est primordiale pour
l’efficacité de la réalisation et de l’exploitation de ces actifs. Les organisations collaborent dans le cadre de
cas d’usage spécifiques afin d’atteindre des niveaux de qualité plus élevés et une meilleure réutilisation
des connaissances, de l’expérience de l’information et des ressources existantes. Une condition importante
de cette collaboration est la possibilité de communiquer, de réutiliser et de partager efficacement les
informations ainsi que de réduire le risque de perte, de contradiction ou de mauvaise interprétation.
La série de normes ISO 29481 relative aux protocoles d’échange d’informations (IDM, de l’anglais
Information Delivery Manual) fournit une aide précieuse pour tirer le meilleur parti de la gestion de
l’information.
Si les informations nécessaires sont disponibles en temps utile, si leur qualité est satisfaisante et si la bonne
personne est impliquée au bon moment, la collaboration et son résultat en sont alors grandement améliorés.
La gestion et la coordination reposant largement sur la communication, celle-ci a tout intérêt à être bien
structurée, claire, explicite et opportune. Cela suppose une compréhension commune de l’objectif, des
processus, des acteurs impliqués et des informations nécessaires.
Le présent document porte principalement sur les fondements et la mise en œuvre de la communication
numérique conformément aux processus et aux exigences d’information d’un cas d’usage. En mettant l’accent
sur la communication, le présent document est un complément logique aux normes relatives à la gestion
de l’information (telles que la série ISO 19650), aux conteneurs d’informations (telles que la série ISO 21597)
et à la modélisation des informations (telles que l’ISO 16739-1 et l’ISO 10303-239).
Le présent document décrit la façon d’utiliser les différents composants d’un IDM pour la mise en œuvre
vérifiable et traçable de la communication numérique. Le cadre d’interaction qui en résulte permet de
normaliser la communication numérique dans les processus de construction pour toute collaboration au
sein des organisations et entre celles-ci. Dans la mesure où la communication numérique couvre l’ensemble
du cycle de vie des actifs et intervient dans des projets de toutes tailles et de tous niveaux de complexité,
une approche informatique normalisée peut être profitable à un grand nombre de parties prenantes.
La mise en œuvre de la présente norme dans diverses solutions de technologies de l’information et de
la communication (TIC) signifie que différents systèmes de gestion de l’information sont reliés. En cela,
elle fournit une base pour un échange et un partage d’informations fiable afin de donner aux utilisateurs
l’assurance que les informations qu’ils envoient ou reçoivent sont exactes et en adéquation avec les activités
de coordination qu’ils doivent réaliser. Cela constitue une base pour l’utilisation de solutions et de flux
de travaux de l’environnement de données commun (CDE, de l’anglais Common Data Environment).
vi
Norme internationale ISO 29481-2:2025(fr)
Modèles des informations de la construction — Protocole
d’échange d’informations —
Partie 2:
Cadre d’interaction
1 Domaine d’application
Le présent document spécifie une méthodologie pour décrire et gérer les interactions ainsi qu’un format
pour la communication numérique entre les acteurs dans tout cas d’usage associé à la gestion d’un actif au
cours de toutes les phases de son cycle de vie.
Il fournit:
— une méthodologie qui décrit un cadre d’interaction pour un cas d’usage;
— une manière adaptée de mettre en correspondance les responsabilités et les interactions, qui donne
un contexte aux flux d’informations d’un processus;
— un format dans lequel le cadre d’interaction est spécifié et mis en œuvre.
Le présent document a pour objectif de promouvoir une communication IDM numérique sécurisée, vérifiable,
traçable et de haute qualité entre les acteurs au cours de toutes les phases du cycle de vie des actifs, de
faciliter l’interopérabilité entre les applications logicielles utilisées et de fournir une base pour les échanges
d’informations axés sur les données et les processus ainsi que pour la traçabilité de la communication.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences 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 29481-1, Modèles des informations de la construction — Protocole d’échange d’informations — Partie 1:
Méthodologie et format
ISO 14533-2, Processus, éléments d'informations et documents dans le commerce, l'industrie et l'administration
— Signature à long terme — Partie 2: Profils pour les signatures électroniques avancées XML (XAdES)
3 Termes et définitions
Pour les besoins du présent document, les termes et les définitions de l’ISO 29481-1 ainsi que les suivants
s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en normalisation,
consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse https:// www .electropedia .org/
3.1 Généralités
3.1.1
message
informations préparées à des fins de communication
[SOURCE: ISO 5127:2017, 3.1.8.02]
3.1.2
communication IDM numérique
échange de messages (3.1.1) dans les limites d’un cas d’usage, facilité par un cadre d’interaction et un
message spécifique au projet (3.2.1)
3.2 Composants techniques
3.2.1
message spécifique au projet
PSM
fichier structuré qui place le cadre d’interaction dans le contexte d’un projet spécifique en reliant les rôles
aux personnes et aux organisations associées
Note 1 à l'article: L’abréviation PSM est dérivée du terme anglais développé correspondant project specific message.
3.2.2
schéma de cadre d’interaction
fichier de définition de schéma XML utilisé pour valider un cadre d’interaction
3.2.3
schéma de message d’interaction
fichier de définition de schéma XML utilisé pour valider un message (3.1.1)
3.2.4
convertisseur
algorithme qui génère un schéma de cadre d’interaction (3.2.2) à partir d’un cadre d’interaction, à l’aide
d’une définition de modèle (3.2.5) utilisée en entrée
3.2.5
définition de modèles
fichier contenant un certain nombre de modèles, indépendants du cadre d’interaction spécifique,
destinés à générer un schéma de cadre d’interaction (3.2.2) et un schéma de message d’interaction (3.2.3)
4 Notation
Dans le présent document, les conventions de notation suivantes s’appliquent:
— le présent document applique les notations utilisées dans l’ISO/IEC 23009-1 pour décrire les éléments
d’un document XML;
— les types d’éléments primaires sont identifiés par une première lettre majuscule, par exemple Element;
si le nom d’un élément est composé de deux mots ou plus, la notation PascalCase est utilisée, par exemple
ImportantElement;
— les types d’éléments secondaires, les attributs et les références sont identifiés par une première lettre
minuscule; si le nom de l’un d’eux est constitué de deux mots ou plus, la notation camelCase est utilisée
après le premier mot, par exemple importantAttribute;
— les éléments sont représentés graphiquement sous forme de diagrammes de langage de modélisation
unifié (UML); le présent document reprend les notations graphiques utilisées dans l’ISO 24156-1.
5 Cadre d’interaction
5.1 Généralités
Le présent article explique les concepts et principes fondamentaux régissant l’élaboration et l’utilisation
d’un cadre d’interaction pour la communication IDM numérique. En suivant la méthodologie présentée dans
le présent document, les utilisateurs d’outils logiciels peuvent modéliser (dans un fichier XML interprétable
par machine) le contexte métier et les exigences d’échange d’un cas d’usage spécifié, pour ensuite commencer
à communiquer numériquement les uns avec les autres sur la base de ce cadre d’interaction.
5.2 Gestion de l’information et cadre d’interaction
La gestion de l’information consiste à définir, produire, vérifier et fournir des informations. Chaque membre
d’équipe, quelle que soit l’activité de l’entreprise, interagit dans une certaine mesure avec la gestion de
l’information. L’importance de documenter les responsabilités et les obligations en matière de gestion
de l’information est primordiale, car la mise en place d’une bonne gestion de l’information permet d’obtenir
de meilleurs résultats pour les projets. Pour que cette dernière soit efficace, une compréhension commune
des processus et des informations requises à chaque étape de leur exécution doit être assurée.
Un IDM restitue le contexte métier associé à un cas d’usage et définit une spécification détaillée des
informations qu’un utilisateur assumant un rôle particulier aurait besoin de fournir à un stade particulier
d’un processus métier afin de créer un produit ou de fournir un service.
D’une manière générale, un cas d’usage implique la livraison de produits ou la fourniture de services à des
donneurs d’ordres ou à des clients. Dès lors qu’un donneur d’ordres ou un client demande la livraison d’un
lot de produits ou la fourniture d’un service, une chaîne d’activités se met en place pour répondre à cette
demande. Cette chaîne d’activités est appelée «contexte métier».
Celui-ci conduit au cadre de base d’un IDM, comme illustré à la Figure 1. Chaque cas d’usage est associé
à un contexte métier et à des informations requises.
Légende
association
héritage
agrégation
composition
Figure 1 — Cadre de base de l’IDM
Le contexte métier est généralement représenté dans un IDM par une combinaison de cartes d’interaction
et de cartes de processus, accompagnées de représentations textuelles ou d’informations graphiques.
L’analyse du contexte métier peut être considérée comme un processus de découverte utilisant ces deux
approches de mise en correspondance, car ces dernières ont pour objectif de montrer clairement la manière
dont les exigences d’échange d’informations pour le cas d’usage sont établies.
Une exigence d’échange fournit une description des informations à échanger entre les rôles dans un langage
naturel utilisant des termes clairs afin de faciliter un processus métier particulier dans la phase du cycle de vie
concernée (dans le cadre d’un contexte métier). Une exigence d’échange peut soutenir soit la communication
d’informations essentielles à la conception, à la construction, à l’exploitation et à la déconstruction d’un actif,
soit la communication d’informations de gestion avec des messages visant à contrôler l’exécution du projet
dans le cadre de la gestion du cycle de vie de l’actif, soit les deux.
Pour fournir un service ou produire un produit dans le cadre d’un cas d’usage, les acteurs effectuent diverses
activités. Prises dans leur intégralité, celles-ci constituent le contexte métier. Le contexte métier comporte
souvent des chaînes d’activités qui fournissent des sous-produits ou des services, appelées «processus
métier». À certains moments, un acteur a besoin d’informations pour exécuter sa tâche ou a la responsabilité
de fournir des informations spécifiques. Lorsque ces informations sont transférées d’un acteur à un autre,
une interaction se produit. L’acteur qui reçoit les informations détermine si celles-ci sont complètes et
correctes.
Un échange d’informations n’est donc jamais une activité unique, c’est une conversation (numérique) entre
deux acteurs en vue de satisfaire une exigence d’information spécifique.
Le présent document se concentre sur la structuration formelle, l’enregistrement et la prise en charge
de ces interactions et de leurs exigences pour parvenir à un résultat. Cette démarche est appelée
«communication performative».
5.3 Objectif d’un cadre d’interaction
Le cadre d’interaction est au cœur de la communication IDM numérique. Il s’agit d’une description technique
XML formelle qui comprend tous les éléments nécessaires aux interactions au sein des cas d’usage, tels que
les rôles, les transactions, les messages dans les transactions et les éléments de données dans les messages.
Dans un IDM, le domaine d’application d’un cadre d’interaction est aligné sur le domaine d’application d’un
cas d’usage.
La création d’un cadre d’interaction permet non seulement d’identifier les exigences d’échange d’informations
détaillées, mais aussi de faciliter (grâce à un logiciel compatible) une communication IDM numérique
vérifiable et traçable entre les participants au cours de toutes les phases du cycle de vie des actifs. Lorsqu’il
est correctement établi, un cadre d’interaction constitue la base des outils logiciels qui permettent aux
utilisateurs de communiquer numériquement et de manière ciblée par le biais de messages reposant sur les
processus, les rôles, les exigences d’échange et les informations définis par l’IDM. La communication IDM
numérique basée sur un cadre d’interaction permet un contrôle plus efficace des processus, une meilleure
gestion des données, une plus grande transparence, une meilleure vérifiabilité des accords et une plus
haute qualité du produit final. Un outil logiciel utilisant un cadre d’interaction permet de structurer, de
contrôler et de sauvegarder la communication en proposant des archives de communication numériques
partagées. Il permet également de clarifier rapidement les responsabilités et les décisions, d’assurer la mise
à jour et l’exhaustivité des archives de projets, de faciliter des partenariats plus rapides et plus flexibles, et
d’empêcher les erreurs de communication.
Comme le processus et le contenu se trouvent dans un cadre d’interaction lisible par ordinateur plutôt
qu’intégrés dans un outil logiciel, une solution logicielle mettant en œuvre cette méthode peut faciliter
et améliorer la collaboration dans n’importe quel cas d’usage sans avoir recours à un logiciel spécialisé.
Cela garantit également l’interopérabilité entre les outils logiciels en conformité avec le présent document,
ce qui permet une transmission de messages fluide entre les applications. Chaque organisation peut choisir
librement des outils logiciels pour mettre en œuvre le cadre d’interaction, garantissant ainsi une transmission
de messages sécurisée entre eux. Cela garantit à chaque partie un accès total à la communication mutuelle
par l’intermédiaire du logiciel qu’elle a choisi, tout en protégeant la communication interne des partenaires
collaborateurs.
Les principes, termes et concepts de base de la modélisation des interactions préconisés par le présent
document sont basés sur la méthodologie de conception et d’ingénierie pour les organisations (DEMO,
1)
de l’anglais Design and Engineering Methodology for Organizations).
DEMO est une méthode d’analyse et de (re)conception des organisations, dans laquelle l’action humaine
occupe une place centrale. DEMO décrit la structure d’une organisation, abstraction faite de son
fonctionnement. Elle décrit ce qui se passe ou ce qui devrait se passer plutôt que la manière dont cela se
passe. Elle se concentre sur l’essence même d’une organisation: ce que fait l’organisation et non comment
1) La méthodologie DEMO trouve son origine dans la science et a été développée à l’université de Maastricht et
à l’université de technologie de Delft par le professeur Jan Dietz (Référence [11]). Elle s’appuie sur diverses théories,
notamment la théorie des systèmes (Référence [17]), la philosophie du langage (Références [10] et [16]), la théorie de
l’agir communicationnel (Référence [14]), la modélisation des données (Référence [15]) et les ontologies (Référence [13]).
En collaboration avec les universités d’Anvers (Belgique), de Duisbourg (Allemagne), de Bolzano (Italie), du Luxembourg,
de Vienne (Autriche), de Lisbonne et de Madère (Portugal), de Prague (République tchèque), de Saint-Gall (Suisse),
de San Jose (États-Unis) et de Tokyo (Japon). la dernière version de la méthodologie (DEMO-4) a été publiée en 2020.
La poursuite du développement de la méthodologie DEMO est soutenue par l’Institut international d’ingénierie des
entreprises (Enterprise Engineering Institute).
elle le fait. Un modèle DEMO décrit un partenariat, que ce soit au sein d’une organisation ou entre
organisations. Un modèle DEMO est la synthèse d’un ensemble cohérent de produits, de responsabilités, de
processus, d’informations et de règles métier, qui donne une vue d’ensemble de l’organisation et permet sa
compréhension.
5.4 Structure hiérarchique d’un cadre d’interaction
5.4.1 Généralités
Un cadre d’interaction intègre toutes les interactions numériques et tous les rôles nécessaires pour réaliser
l’objectif d’un cas d’usage. La Figure 2 représente la hiérarchie des définitions dans le présent document.
Chaque transaction définit une séquence de messages échangés entre deux rôles. Un message est un
formulaire numérique, incluant d’éventuelles pièces jointes, qui comprend des éléments de données classés
en éléments complexes et simples. Le comportement des éléments simples est déterminé par son type défini
par l’utilisateur et ses conditions d’élément.
Figure 2 — Cadre d’interaction avec la hiérarchie de ses composants
5.4.2 Rôles
Lors de la définition d’un cas d’usage, les rôles sont attribués à des responsabilités et à des tâches, et non à
des fonctions ou à des postes spécifiques au sein d’une organisation. Cela est dû au fait que les mêmes rôles
apparaissent systématiquement dans les contextes métier, mais que les personnes occupant des fonctions ou
des postes différents peuvent assumer plusieurs rôles ou passer d’un rôle à un autre. Par exemple, les acteurs
peuvent assumer des rôles tels que «initiateur», «client», «constructeur» ou «concepteur». Le nom du rôle
est tiré de son activité principale, ce qui met en évidence la contribution du rôle au sein des transactions.
Selon un principe fondamental, les acteurs investis d’un rôle négocient en faisant preuve d’autorité et de
responsabilité. Seuls ces acteurs peuvent conclure des accords, prendre des décisions, émettre des jugements
et conclure des contrats. Les rôles doivent donc remplir certaines qualifications.
Il n’y a pas toujours de relation univoque entre les acteurs et les rôles. Dans certains processus métier,
un acteur peut assumer plusieurs rôles, tandis que dans d’autres, plusieurs acteurs peuvent partager le
même rôle. Par exemple, une municipalité peut être à la fois l’initiateur et le client, ou une entreprise de
terrassement et une entreprise d’installation peuvent toutes deux assumer le rôle de constructeur. Un acteur
peut également assumer différents rôles dans le cadre de différents processus métier.
Chaque cadre d’interaction comprend des rôles définis pour rationaliser les responsabilités et les tâches.
Cette approche garantit une collaboration claire et efficace, en fournissant une méthode structurée pour
gérer efficacement les différentes fonctions au sein de l’activité métier. Les rôles peuvent également être
réattribués en cas de départ de membres du projet et des autorisations peuvent être accordées pour que
d’autres personnes puissent reprendre leur travail. La trace d’audit reste toujours inchangée, ce qui permet
de savoir clairement qui a fait quoi et à quel moment.
5.4.3 Transactions
5.4.3.1 Généralités
Chaque cadre d’interaction est constitué d’une ou plusieurs transactions, définies par le cas d’usage et le
contexte métier associé. Dans un cadre d’interaction, une transaction est une séquence de messages entre
deux rôles. Comme illustré à la Figure 3, chaque transaction a un initiateur (le rôle qui débute la transaction)
et un exécutant (le rôle qui exécute la transaction).
Figure 3 — Une transaction n’implique toujours que deux rôles
L’utilisation de transactions dans le cadre de la gestion de l’information place le transfert d’informations
dans un contexte de processus. Cela permet de s’assurer que les informations sont échangées de manière
systématique et ciblée au sein d’un processus numérique structuré. Les organisations qui utilisent un cadre
d’interaction passent de flux de travaux basés sur des documents à des flux de travaux basés sur des données
grâce à des informations et des processus gérés numériquement.
5.4.3.2 Scénarios de processus métier et sous-transactions
Selon le contexte métier et le cas d’usage, un cadre d’interaction peut contenir une ou plusieurs transactions.
Au sein du contexte métier, plusieurs transactions entre les rôles sont parfois requises dans un certain ordre
afin d’atteindre un objectif. Par exemple, lorsqu’un rôle dans la transaction A prépare des informations
qu’un autre rôle dans la transaction B doit examiner. Dans de tels cas, les transactions doivent être reliées
pour former un flux de travaux appelé «scénario de processus métier».
Un scénario de processus métier comporte toujours une transaction principale, où la demande initiale est
faite, qui est associée à une ou plusieurs sous-transactions. Les sous-transactions sont conçues de sorte à
s’enchaîner en cascade à partir de la transaction principale. Cela est détaillé en 6.3.2.10.
5.4.3.3 Carte d’interaction
Tous les rôles, transactions et sous-transactions nécessaires d’un cas d’usage sont décrits dans la carte
2)
d’interaction d’un IDM. Il s’agit d’une représentation abstraite qui définit le périmètre d’un cas d’usage
et fait apparaître la chaîne de communication essentielle à la réalisation de son objectif. Son nom vient
du fait qu’elle consigne l’interaction entre les acteurs, c’est-à-dire leur influence mutuelle directe. Elle fait
abstraction de toutes les activités et des différentes étapes du processus. Le recours à des rôles abstraits
permet d’appliquer la carte d’interaction à diverses situations. La Figure 4 présente un exemple simplifié de
carte d’interaction pour un cas d’usage de bureau d’études.
2) Dans le langage DEMO, la carte d’interaction est appelée diagramme de structure de coordination.
Figure 4 — Exemple de carte d’interaction pour un cas d’usage de bureau d’études
Tous les rôles et toutes les transactions de la carte d’interaction ont une identité et un nom uniques,
avec une numérotation arbitraire. Les rôles sont nommés en fonction de leurs activités principales, en
insistant sur leurs contributions au cas d’usage. Un rôle composite est constitué de plusieurs rôles, mais sa
composition n’est pas pertinente pour le domaine d’application du cas d’usage.
5.4.3.4 Tableau des produits de transaction
Chaque transaction a un résultat prévu, également appelé «produit de la transaction». Associé aux
transactions et aux rôles décrits par la carte d’interaction, ce résultat peut être résumé dans un tableau de
produits de transaction. Ce tableau consigne le type de transaction (le nom et le numéro unique de chaque
transaction), le type de produit (le produit de chaque transaction) et ses rôles d’initiateur et d’exécutant.
Voir le Tableau 1 pour obtenir un exemple.
Tableau 1 — Tableau de produits de transaction d’un cas d’usage simplifié de bureau d’études
Type de produit Type de transaction Rôle d’initiateur Rôle d’exécutant
L’étude est livrée T , Livrer l’étude CR Client R Conduite de projet
1 1 1
La spécification du système T , Livrer la spécification du R Conduite de projet R Ingénierie système
2 1 2
est livrée système
Le modèle 3D est livré T , Livrer le modèle 3D R Conduite de projet R Ingénierie 3D
3 1 3
Le calcul des coûts est livré T , Livrer le calcul des coûts R Conduite de projet R Ingénierie des coûts
4 1 4
5.4.4 Messages
5.4.4.1 Généralités
Pour réaliser le produit d’une transaction, des interactions ont lieu entre deux rôles. Dans l’environnement
numérique, ces interactions sont mises en œuvre au moyen de messages numériques. Une transaction
contient un ensemble de messages qui sont échangés dans un but précis. La transaction spécifie également
les rôles participants, le stade du cycle de vie et la séquence selon laquelle il convient de délivrer les messages
(le cas échéant).
Dans la méthodologie IDM, un message peut contenir des informations qui satisfont aux exigences d’échange.
Ces informations peuvent prendre la forme de valeurs textuelles saisies directement dans le message
ou de pièces jointes. Les pièces jointes peuvent être de n’importe quel type, y compris des conteneurs
d’informations structurées, tels que des fichiers IFC ou des conteneurs d’informations pour la livraison
de documents liés (ICDD), et des conteneurs d’informations non structurées, tels que des documents, des
feuilles de calcul, des images, des fichiers vidéo et des plans. Le message du cadre d’interaction accepte
également l’inclusion de métadonnées, telles que le numéro de version, la date du document et l’état. Pour
certains types de messages, il peut être obligatoire d’ajouter au moins une pièce jointe et des types de pièces
jointes spécifiques peuvent être imposés par le cadre d’interaction.
5.4.4.2 Séquence de messages
Les ensembles de messages dans une transaction forment une chaîne avec un début et une fin. La plupart
des diagrammes de processus proposent un «flux idéal», à savoir le scénario d’actions de communication
le plus favorable dans lequel les deux acteurs remplissent leur rôle sans conflit. Cependant, dans la pratique,
les processus suivent rarement ce flux idéal, car les humains peuvent faire des erreurs; il convient donc
d’envisager toutes les issues possibles, comme la nécessité de procéder à des ajustements ou des scénarios
dans lesquels un modèle n’est pas approuvé.
Par exemple, une transaction impliquant une demande de modèle 3D (voir la Figure 5) est représentée
par une séquence de messages dans une transaction qui prend la forme d’un diagramme de séquence en
notation UML. La transaction est initiée par le chef de projet R avec le message «Demande de modèle 3D».
L’ingénieur 3D (rôle R3) répond par «Tâche effectuée et demande d’approbation». Après un message «Tâche
approuvée» ou «Tâche non approuvée», la transaction est terminée.
Le message de début n’est précédé d’aucun autre message, ce qui est le seul moyen de le distinguer des
autres messages. De même, le message de fin n’est suivi d’aucun autre message. Le sens de communication
de chaque message est indiqué par la flèche étiquetée. Un message peut être précédé de plusieurs messages
(par exemple, un message d’approbation peut suivre une livraison, mais aussi une nouvelle livraison). De
même, le message de fin peut contenir à la fois un refus et une approbation. Par conséquent, la chaîne de
messages n’est pas linéaire, mais plutôt une représentation graphique mathématique.
Figure 5 — Exemples de messages dans une transaction
5.4.5 Éléments simples et complexes
Par principe, un message est un «formulaire» comportant des champs de données et des pièces jointes,
lorsque nécessaire. Chaque message comprend un en-tête avec des détails sur les rôles impliqués et la date
et l’heure d’envoi du message. Le corps du message contient les informations à transférer, telles que des
champs de texte, des dates, des montants, des cases à cocher oui/non, des zones de liste et des tableaux. Lors
d’une communication IDM numérique, les données contenues dans les champs sont stockées dans la base de
données du logiciel qui l’exécute.
Chaque champ de données d’un message est appelé «élément simple» et fait toujours partie d’un groupe
appelé «élément complexe». Chaque élément complexe peut contenir un ou plusieurs éléments simples.
Dans un message, les éléments simples peuvent être obligatoires ou facultatifs à compléter par les
utilisateurs. Chaque message doit contenir au moins un élément complexe avec au moins un élément simple,
bien qu’un élément simple puisse rester vide. Pour créer un tableau, un élément complexe doit être imbriqué
dans un autre élément complexe.
Le comportement, les restrictions (par exemple, longueur minimale) et la validation des éléments simples
sont déterminés par leur UserDefinedType (type défini par l’utilisateur). Lors d’une communication IDM
numérique, un héritage se produit. En principe, les données saisies dans un élément simple d’un message
précédent sont envoyées dans un message ultérieur, à moins qu’une condition d’élément n’ait été incluse
dans le cadre d’interaction.
Voir la Figure 6 pour un exemple d’éléments complexes et simples dans le message «Proposition de demande
de changement».
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.