ISO 29481-2:2012
(Main)Building information models — Information delivery manual — Part 2: Interaction framework
Building information models — Information delivery manual — Part 2: Interaction framework
ISO 29481-2:2012 specifies a methodology and format for describing ?coordination acts' between actors in a building construction project during all life cycle stages. It therefore specifies a methodology that describes an interaction framework, an appropriate way to map responsibilities and interactions that provides a process context for information flow, a format in which the interaction framework should be specified. ISO 29481-2:2012 is intended to facilitate interoperability between software applications used in the construction process, to promote digital collaboration between actors in the building construction process, and to provide a basis for accurate, reliable, repeatable, and high-quality information exchange.
Modèles des informations de la construction — Protocole d’échange d’informations — Partie 2: Cadre d'interaction
L'ISO 29481-2:2012 spécifie une méthodologie et un format de description des «actions de coordination» entre les acteurs d'un projet de construction à toutes les étapes du cycle de vie. Par conséquent, elle spécifie: - une méthodologie qui décrit un cadre d'interaction; - une manière adaptée d'identifier les responsabilités et les interactions, qui donne un contexte aux flux d'informations du processus; - un format dans lequel il est recommandé de spécifier le cadre d'interaction. L'ISO 29481-2:2012 est destinée à faciliter l'interopérabilité entre les logiciels utilisés dans le processus de construction, afin de promouvoir la collaboration numérique entre les acteurs du processus de construction et de fournir une base pour un échange d'informations précis, fiable, répétable et de haute qualité.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 29481-2
First edition
2012-12-15
Building information models —
Information delivery manual —
Part 2:
Interaction framework
Modèles des informations de la construction — Contrat
d’interchange —
Partie 2: Cadre d’interaction
Reference number
©
ISO 2012
© ISO 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any
means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the
address below or ISO’s member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2012 – All rights reserved
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Standard principles . 2
4.1 General . 2
4.2 BIM and IDM . 2
4.3 Components of IDM . 2
4.4 Basic principles of business communication . 3
4.5 Interaction map . 4
4.6 Messages in transaction . 6
4.7 Interaction framework . 6
4.8 Supporting the software solutions . 7
5 Format of an interaction framework . 9
5.1 Introduction . 9
5.2 Information types in the interaction framework schema . 9
Annex A (normative) Interaction framework schema definition .12
Annex B (normative) Templates definition .43
Annex C (informative) Example interaction map of a simplified design office .61
Annex D (informative) Principles for Promotor algorithm .73
Bibliography .74
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International
Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies
casting a vote.
Attention is drawn to the possibility that some of the elements of this part of ISO 29481 may be the
subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 29481-2 was prepared by Technical Committee ISO/TC 59, Buildings and civil engineering works,
Subcommittee SC 13, Organization of information about construction works.
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
The following parts are under preparation:
— Part 3: Model view definitions
iv © ISO 2012 – All rights reserved
Introduction
Building information modelling provides a concept for describing and displaying information required
in the design, construction, and operation of constructed facilities. It can bring together the diverse sets
of information used in construction into a common information environment — reducing, and often
eliminating, the need for the many types of paper documentation currently in use.
An information delivery manual (IDM) provides significant help in getting the full benefit from a building
construction information model (BIM). If the information required is available when it is needed and the
quality of information is satisfactory, the construction process itself will be greatly improved. For this to
happen, there should be a common understanding of the building processes and of the information that
is needed for and results from their execution.
This part of ISO 29481 focuses on aspects of the construction process that refer to management and
coordination of the involved parties. Coordination is dependent on communication, which should be well
structured, unambiguous, explicit, and prompt. Due to a sharp focus on coordination and interaction,
this part of ISO 29481 provides a natural complement to standards that focus on building modelling like
ISO 10303-239 and ISO 16739.
This part of ISO 29481 sets out a methodology and format for describing coordination acts between
actors in a construction project. It describes how to identify and define the coordination processes
undertaken and the information required for their execution. The resulting interaction frameworks
enable standardization of interaction in building processes on national, local, and project level. It also
gives a format to support solutions provided by ICT-solution providers. Support of this part of ISO 29481
in different ICT-solutions means that this joins together different process management systems. In doing
so, it provides a basis for reliable information exchange/sharing for users, so that they can be confident
that the information they are sending or receiving is accurate and sufficient for the coordination
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. It is mainly based on the Dutch VISI standard developed in 2003.
INTERNATIONAL STANDARD ISO 29481-2:2012(E)
Building information models — Information delivery
manual —
Part 2:
Interaction framework
1 Scope
This part of ISO 29481 specifies a methodology and format for describing ‘coordination acts’ between
actors in a building construction project during all life cycle stages.
It therefore specifies
— a methodology that describes an interaction framework,
— an appropriate way to map responsibilities and interactions that provides a process context for
information flow,
— a format in which the interaction framework should be specified.
This part of ISO 29481 is intended to facilitate interoperability between software applications used in
the construction process, to promote digital collaboration between actors in the building construction
process, and to provide 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 29481-1, Building information modelling — Information delivery manual — Part 1: Methodology and format
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
IDM
Information Delivery Manual
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
3.2
interaction framework
formal description of the elements of interaction, including definition of roles, transactions, messages in
transaction, and data elements in messages
3.3
interaction framework schema
formal description of the rules with which an interaction framework must comply
3.4
interaction schema
formal description of the rules with which sent and received messages must comply
3.5
promotor
algorithm that generates an interaction schema from an interaction framework, interaction framework
schema, and templates file as input
3.6
templates file
file containing a number of templates, independent of the interaction framework, for generating an
interaction schema
3.7
VISI
acronym for Dutch standard for communication between partners in construction projects
Note 1 to entry: VISI stands for “Voorwaarden scheppen voor Invoeren Standaardisatie ICT in de Infrastructuur-
sector” which translates as “Creating conditions for the implementation of ICT standardization for the
construction industry”)
4 Standard principles
4.1 General
This clause is included to highlight and help explain essential concepts on which this part of
ISO 29481 is based.
4.2 BIM and IDM
Building information modelling brings together the diverse sets of information used in construction
into a common information environment. For this to happen, there should be a common understanding
of the building processes and the information that is needed for and from their execution.
ISO 29481 is a standard that sets out a method for the development of an Information Delivery Manual.
The IDM methodology given in ISO 29481-1 shall be used for all references to development and use of IDM.
4.3 Components of IDM
The methodology and components of IDM are described in ISO 29481-1. In that part, an illustration is
given that diagrammatically shows what the different components of IDM are and how they are related.
Within IDM, there are two perspectives. These are seen as user requirements and technical solutions.
Within the two perspectives, there are a number of zones that characterize the various components of
IDM (see Figure 1).
2 © ISO 2012 – All rights reserved
Figure 1 — IDM zones
Within the user-requirements perspective, these zones are
— interaction maps, describing the roles and interactions between them,
— process maps, describing the overall process in which information exchange occurs,
— information delivery, describing the information exchange needs,
— reference processes (stored exchange descriptions),
— the project schedule (occurrences of processes in the context of a project).
The technical-solution perspective includes
— the business objects comprising the exchange requirement model,
— the information specification, describing the schema on which the information exchange is based,
— the building information model.
This part of ISO 29481 focuses on the interaction map and is based on general principles of business
communication.
4.4 Basic principles of business communication
Once a client or customer has asked to deliver a product or provide a service, there will be a chain
of activities in operation, whose combined effect is to provide the product or service. Such a chain of
activities is called a business process. More specifically, we speak here of a primary business process
because it is initiated externally.
Part of the business process is the communication between the involved parties. This part of
ISO 29481 concentrates on the communication that relates to the delivery of an outcome (performative
communication). The initiation and execution of a request is through communicative actions. In a
communicative action, two parties are always involved: the person who performed the action and the
person to whom the action is directed. The handling of a request appears to occur in a particular pattern
called the transaction.
Figure 2 — A transaction pattern (Dietz, 2006)
In Figure 2, the simplest form of this transaction pattern is presented. It shows that bringing about
of a new production result (for example, the ‘desired result’ is the delivery of a document) starts with
requesting of this result by someone in the role of customer from someone in the role of producer. This
brings the process to the state “result requested”. The producer responds to the request by promising
to produce the desired result, which brings the process to the state “result promised”. This presents a
to-do item for the producer: he has to comply with the promise by actually preparing the document and
deciding to deliver the document. In the act of handing over the document to the customer, he states
that he has complied with his promise. The customer responds to this state by accepting the result as
produced. This act completes the transaction.
In the execution of the business process, often many actors are involved. Their behaviour is dependent
on their role in the process. Roles/actors do business with other roles/actors by executing transactions.
A useful representation of the interaction between roles/actors is called the interaction map.
4.5 Interaction map
An interaction map shall identify the relevant role types and transaction types for a certain process.
IDM draws a distinction between a role that makes a request, the initiator, and the role that gives effect
to that request, the executor. A transaction shall have only one initiating role and only one executing
role. Figure 3 shows the components of the interaction map.
NOTE The notation of the interaction map is based on the construction model as described in the publication
of Prof. Jan L.G. Dietz. This notation differs from BPMN and is used to prepare maps that are as simple as possible.
Also, it provides the concept of ‘transaction’, which is not available in BPMN.
4 © ISO 2012 – All rights reserved
R CR
j j
Role type R Composite Boundary, scope of
j
Role type CR interac on
j
T
j
Transac on type T Ini ator link Executor link
j
Figure 3 — Components of the interaction map
The advantage of the interaction map is that it focuses attention on the interfaces between roles
while hiding the complexity of the process within the domain of the roles and hiding the details of
the interaction between the roles. The use of abstract roles makes the interaction map valid for many
different situations. The interaction map is a valuable tool for analysing and defining essential elements
of a business process. Figure 4 shows a simplified example of an interaction map of a design office.
Design office
CR R
1 2
T T
Project System
Client leading engineering
R R
1 3
T
3D
engineering
R
T
Cost
engineering
Figure 4 — Example of an interaction map
In an interaction map, all transactions needed for the handling of required contributions of relevant
roles to the BIM shall be included. All roles and transactions within the interaction map shall have a
unique identity and name. The numbering is arbitrary. The name of the role is derived from the main
activity undertaken by the role; this brings focus on the contribution of the role to the BIM. A composite
role is a role which may consist of multiple roles but whose composition is unknown or not relevant.
The interactions can be summarized in a transaction table.
Table 1 — Transaction table of a simplified design office
Transaction result Transaction type
Design is delivered T , Deliver design
System specification is delivered T , Deliver system specification
3D model is delivered T , Deliver 3D model
Cost calculation is delivered T , Deliver cost calculation
4.6 Messages in transaction
A transaction shall contain a set of messages that are exchanged for a particular purpose. The transaction
also stipulates the participating roles, point in the life cycle, and the sequence in which messages should
be delivered (if appropriate).
An example of a transaction is the handling of a request for a 3D model. See Figure 5, which shows the
messages in a transaction as a sequence diagram in UML notation. The transaction can only be initiated
by R1 Project leading with the message ‘Request for 3D model’. The 3D engineer (role R3) can respond
with a message ‘Work done and request for approval’. After a message ‘Work approved’ or ‘Work not
approved’, the transaction is completed.
R : Project leading R : 3D Engineering
1 3
Request for3D model
Work done and request approval
Request adjustments
Work approved
Work notapproved
Transac on: T₃ –Request for3D model
Figure 5 — Example of messages in a transaction
A message is a populated information model and contains data. Attachments may be linked to messages.
As an attachment, an exchange requirement can be transferred to the executing role, and the result
(contribution to the BIM) is delivered to the initiating role. By using transactions, the information
transfer is brought in a process context.
4.7 Interaction framework
In order to give guidance to a process and information transfer, the elements of interaction need to
be described in a coherent manner. This coherent description is called an interaction framework. An
interaction framework shall include
— definition of relevant roles,
— transactions,
6 © ISO 2012 – All rights reserved
— messages in transaction,
— the order of messages in transaction,
— data elements in messages.
An interaction framework can be prepared for a defined application area and used as a standard on
(inter-)national level, organization level, or project level. For example, in the Netherlands, an interaction
framework is developed at the national level for the completion of all contractual procedures during the
execution of a construction project. This part of ISO 29481 is used as a template by organizations and
projects and adjusted to specific needs.
EXAMPLE An interaction framework may include the attribute CostEstimation as an instance of
SimpleElementType to be used as a mandatory element for a certain message. It also may include a restriction on
the format of the attribute CostEstimation (e.g. only euros with two decimals).
4.8 Supporting the software solutions
4.8.1 Overview
The next step is to support the interaction framework with software solutions. The aim is
— to support the editing of an interaction framework,
— to guarantee the completeness and validity of an interaction framework,
— to support the portability of an interaction framework,
— to support the operation of information systems,
— to support the interoperability of communication.
In the support of software solutions, two levels can be identified. The first level concerns the interaction
framework. The second level concerns the actual communication which is based on the interaction
framework. This part of ISO 29481 applies to both levels.
An overview on how the software solutions are supported is given in Figure 6. The following sections
provide an explanation.
4.8.2 Supporting the interaction framework
In order to support the portability of an interaction framework, it should be clear with which rules an
interaction framework must comply. These rules shall be included in an interaction framework schema,
which is recorded as an XSD schema file. An interaction framework comprises instances of classes
defined in the schema and shall be recorded as an XML file.
EXAMPLE The interaction framework schema defines that you may include the definition of attributes
(SimpleElementType) and restrictions to attributes (UserdefinedType) in an interaction framework.
Chapter 5 describes the interaction framework schema and the available classes.
Every interaction framework should comply with the interaction framework schema.
An interaction framework editor should use the interaction framework schema to validate the
produced frameworks.
4.8.3 Promotor
Once a valid interaction framework is available, it can be interpreted by a suitable information system.
Then this system can support the communications in accordance with the options set out in the
interaction framework. Finally, it is desirable to be able to validate the received and sent messages; this
is done with the interaction schema.
The interaction schema is generated with a generic algorithm called Promotor. The Promotor ‘promotes’
XML instances tot XSD classes. The input is
— interaction framework (XML),
— interaction framework schema (XSD),
— templates file (XSD), containing a number of templates not described in an interaction framework
but are valid for every interaction schema, for example the message header.
The output is an interaction schema recorded as an XSD file.
EXAMPLE The ‘Promotor’ takes information from the interaction framework to include the attribute
CostEstimation to be used as a mandatory element for a certain message and creates an interaction schema which
defines the message with the CostEstimation attribute.
Annex B describes the templates XSD file.
Annex D gives the principles of the Promotor.
Interaction framework
Schema(XSD)
Create interaction
framework
Templates (XSD)
Interaction
framework(XML)
Promote XML
instances to XSD
classes
Create/send
message
Interaction
schema(XSD)
Message (XML)
Receive/read
message
Interaction
schema(XSD)
Figure 6 — How software solutions are supported
4.8.4 Supporting communication
Every information system that participates in the communication, as defined in the interaction
framework, should operate on the basis of the corresponding interaction framework and interaction
schema. Every message that is sent or received should be valid according to the interaction schema.
8 © ISO 2012 – All rights reserved
Transaction executor Transaction initiator Promoter Interaction framework designer
4.8.5 Technical implementation of communication
In order to ensure that messages with attachments in technical sense can be exchanged between
information systems, there is a need for implementation guidelines. Topics to be covered include
— communication protocol,
— communication architecture/servers,
— encryption,
— SOAP function calls.
Implementation guidelines are beyond the scope of this part of ISO 29481.
5 Format of an interaction framework
5.1 Introduction
Clause 4 explains that, in order to support software solutions, every interaction framework must comply
with the interaction framework schema. This clause is included to define the format of an interaction
framework through a description of the interaction framework schema.
5.2 provides an overview of the information classes that can occur in an interaction framework and are
defined in the interaction framework schema. Since an interaction framework is defined in XML, the
word ‘type’ is used rather than class. Annex A gives the full description of the interaction framework
schema. Annex C provides an example of an instance of an interaction framework.
5.2 Information types in the interaction framework schema
5.2.1 Introduction
A schema is populated by many classes or types. In this section, a short description is given of the
available types in the interaction framework schema. Annex A contains a full description in XML of the
interaction framework schema. An interaction framework shall be created from instances of these types
and shall have a header which points to the schema with the defined available types.
5.2.2 AppendixType
The AppendixType is a definition to define the structure of elements regarding metadata. An instance
of an AppendixType is used to define certain types of files or documents which can be part of the
send/received messages. The structure of the elements related to an instance of an AppendixType
represents the specific metadata which is required for a certain type of file or document.
5.2.3 ComplexElementType
A ComplexElementType is a collection of SimpleElementTypes. Every SimpleElementType occurs exactly
the number of times it is related to.
5.2.4 ElementCondition
An instance of an ElementCondition describes the behaviour of element values in successive messages.
For example, when an instance of the type ElementCondition is created with the value FIXED, it indicates
that elements in successive messages must be copied when the same element is available and the value
cannot be changed. An ElementCondition can refer to different levels in a framework. It can be directly
related to a SimpleElement but it is also possible to relate an ElementCondition to a ComplexElement or
a MessageInTransactionType. In this case, the ElementCondition is valid for all elements which are part
of the element structure/collection of the related types.
5.2.5 GroupType
A GroupType makes it possible to create multiple instances of a group with their own specific content.
The GroupType can be used to categorize messages within a transaction or documents related to
messages within a transaction.
5.2.6 MessageType
The MessageType is used to define the content of a message. The elements that are part of a message are,
in turn, grouped into one or more instances of a ComplexElementType.
5.2.7 MessageInTransactionType
The MessageInTransactionType (MITT) is a definition which is used to relate MessageType’s to
TransactionType’s. Or simply said: the same message type may occur more than once in a given
transaction type and vice versa. It is possible to relate more of the same instance of a MessageType
to one instance of a TransactionType and one instance of a MessageType to multiple instances of a
TransactionType. Besides, a MITT offers an option to reverse the direction from executor to initiator.
Another option controls if the message flow is blocked by open secondary transactions or not.
5.2.8 OrganisationType
Definition of a certain group of organizations. In common, at least one instance is available in the
framework with the particular reason to define the structure of elements of an organization.
5.2.9 PersonType
Definition of a type of person. In common, at least one instance is available in the framework with the
particular reason to define the structure of elements to define a person. The PersonType can be used to
categorize groups of persons who are related to a role.
5.2.10 ProjectType
Definition of a type of project. In common, at least one instance is available in the framework with the
particular reason to define the structure of elements to define the project.
5.2.11 RoleType
Definition of a role. Instances of a RoleType are prerequisites to create a TransactionType in a framework.
5.2.12 SimpleElementType
The SimpleElementType is a definition which describes properties which can occur within object
structures. The relation to an object is always via a ComplexElementType.
5.2.13 TransactionPhaseType
Definition which can be used to define an instance which describes the phase a transaction is in. For
example, an instance of a TransactionPhaseType can be “result requested” or “on hold”.
5.2.14 TransactionType
Definition of a transaction. In an instance of a Transaction, the roles of the initiator and executor are defined.
5.2.15 UserDefinedType
The UserDefinedType is used to set data types (for example, a string) and XSD restrictions. For example,
with an instance of a UserDefinedType, the minimal length of a string can be defined.
10 © ISO 2012 – All rights reserved
Figure 7 visualizes the model of the interaction framework schema, including all its references.
Figure 7 — Types and references of the interaction framework schema
Annex A
(normative)
Interaction framework schema definition
A.1 Introduction
An interaction framework must comply with the rules that are included in an interaction framework
schema. In this annex, the interaction framework schema definition is given in EXPRESS format and in
XSD format. Also, descriptions are given of Element types, attributes, elements, and references.
All objects in an interaction framework require a start date and end date. This requirement is to enable
time constraints to the validity of a certain object.
A.2 Interaction framework schema definition (EXPRESS format)
SCHEMA ISO 29481_Part_2A;
ENTITY ProjectType; — The definition of a specific group of projects. Generally, only
one instance will be present in an interaction framework defining the structure of elements that each
instance of project should expose.
namespace: STRING;
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
END_ENTITY;
ENTITY PersonType; — The definition of a specific group of persons. Generally, only
one instance will be present in an interaction framework defining the structure of elements that each
instance of person should expose.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
12 © ISO 2012 – All rights reserved
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
END_ENTITY;
ENTITY OrganisationType; — The definition of a specific group of organizations. Generally, only
one instance will be present in an interaction framework defining the structure of elements that each
instance of organization should expose.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
END_ENTITY;
ENTITY AppendixType; — An AppendixType contains the definition of an appendix. Which
data items should be recorded with an appendix can be specified in the complex element section.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
END_ENTITY;
ENTITY ComplexElementType; — A ComplexElementType contains a set of
SimpleElementTypes. Each stated SimpleElementType occurs exactly the number of times it is mentioned.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
simpleElements: OPTIONAL SET [0:?] OF SimpleElementType;
END_ENTITY;
ENTITY MessageType; — The definition of a type of message (MessageType), specifying the structure
of the message and which set of SimpleElementType’s (via ComplexElementType’s) may accompany.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
appendixTypes: OPTIONAL SET [1:?] OF AppendixType;
END_ENTITY;
14 © ISO 2012 – All rights reserved
ENTITY ElementCondition; — The condition of a SimpleElementType as used within a specific
MessageType.
description: STRING;
condition: STRING;
helpInfo: OPTIONAL STRING;
complexElement: OPTIONAL ComplexElementType;
simpleElement: OPTIONAL SimpleElementType;
messageInTransaction: OPTIONAL MessageInTransactionType;
END_ENTITY;
ENTITY SimpleElementType; — The definition of a simple element type (SimpleElementType).
This element type specifies a property which may occur within various object structures, for
example in MessageType (see also AppendixType, ProjectType, PersonType, and OrganisationType). A
SimpleElementType is always embedded in a ComplexElementType.
description: STRING;
interfaceType: STRING;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
valueList: OPTIONAL STRING;
userDefinedType: UserDefinedType;
END_ENTITY;
ENTITY UserDefinedType; — A specification of a data type (to be used in a SimpleElementType).
This data type encapsulates fill-in areas in the final message, for example a Dutch zip code starts always
with four digits and then two characters.
description: STRING;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
baseType: STRING;
xsdRestriction: OPTIONAL STRING;
language: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
END_ENTITY;
ENTITY MessageInTransactionType; — The occurrence of a MessageType within a TransactionType
related to a certain group type (GroupType).
requiredNotify: INTEGER;
dateLaMu: DATETIME;
userLaMu: STRING;
received: BOOLEAN;
send: BOOLEAN;
state: STRING;
initiatorToExecutor: OPTIONAL BOOLEAN;
openSecondaryTransactionsAllowed: OPTIONAL BOOLEAN;
firstMessage: OPTIONAL BOOLEAN;
message: MessageType;
previous: OPTIONAL SET [0:?] OF MessageInTransactionType;
transaction: TransactionType;
transactionPhase: OPTIONAL TransactionPhaseType;
group: GroupType;
appendixTypes: OPTIONAL SET [1:?] OF AppendixType;
END_ENTITY;
ENTITY TransactionPhaseType; — The definition of a phase related to a transaction.
Examples are ‘assignment accepted’ or ‘result part received’.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
END_ENTITY;
ENTITY TransactionType; — The definition of a type of transaction. A transaction type may
reference other transaction types. A transaction will be initiated by a person belonging to an organization
fulfilling a certain role. At this level, the role type of the initiator should be stated (the promoted schema
will enforce this). The same holds for the executor.
16 © ISO 2012 – All rights reserved
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
result: OPTIONAL STRING;
subTransactions: OPTIONAL SET [1:?] OF TransactionType;
initiator: RoleType;
executor: RoleType;
appendixTypes: OPTIONAL SET [1:?] OF AppendixType;
END_ENTITY;
ENTITY RoleType; — The definition of a specific role type.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
responsibilityScope: OPTIONAL STRING;
responsibilityTask: OPTIONAL STRING;
responsibilitySupportTask: OPTIONAL STRING;
responsibilityFeedback: OPTIONAL STRING;
END_ENTITY;
ENTITY GroupType; — The definition of a group to store appendices sent with a message within
a transaction.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
END_ENTITY;
END_SCHEMA;
A.3 Interaction framework schema definition (XSD format)
www.ISO 29481_Part_2A.com/schemas” xmlns:xsd = ”http://www.w3.org/2001/XMLSchema” elementFormDe-
fault = ”qualified” >
An AppendixType contains the definition of an appendix. Which
data items should be recorded with an appendix can be specified in the complex element section.
xsd:documentation>
A ComplexElementType contains a set of SimpleElementTypes.
Each stated SimpleElementType occurs exactly the number of times mentioned.
The condition of a SimpleElementType as used within a
specific MessageType.
The definition of a group to store appendices sent with a
message within a transaction.
18 © ISO 2012 – All rights reserved
ype” >
The occurrence of a MessageType within a TransactionType
related to a certain group type (GroupType).
The definition of a type of message (MessageType), specifying
the structure of the message and which set of SimpleElementType’s (via ComplexElementType’s) may
accompany.
The definition of a specific group of organisations. Generally
only one instance will be present in a interaction framework defining the structure of elements that
each instance of organisation should expose.
The definition of a specific group of persons. Generally only
one instance will be present in a interaction framework defining the structure of elements that each
instance of person should expose.
The definition of a specific group of projects. Generally only
one instance will be present in a interaction framework defining the structure of elements that each
instance of project should expose.
The definition of a specific role type.
...
NORME ISO
INTERNATIONALE 29481-2
Première édition
2012-12-15
Modèles des informations de la
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
©
ISO 2012
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2012, 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 2012 – 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 Principes de la norme . 2
4.1 Généralités . 2
4.2 BIM et IDM . 2
4.3 Composants de l’IDM . 2
4.4 Principes de base de la communication métier . 3
4.5 Carte d’interaction . 4
4.6 Messages de la transaction . 6
4.7 Cadre d’interaction . 6
4.8 Prise en charge des solutions logicielles . 7
4.8.1 Vue d’ensemble . 7
4.8.2 Prise en charge du cadre d’interaction . 7
4.8.3 Promotor (Convertisseur) . 8
4.8.4 Prise en charge de la communication . 9
4.8.5 Mise en œuvre technique de la communication . 9
5 Format d’un cadre d’interaction. 9
5.1 Introduction . 9
5.2 Types d’information dans le schéma de cadre d’interaction . 9
5.2.1 Introduction . 9
5.2.2 AppendixType . 9
5.2.3 ComplexElementType . 9
5.2.4 ElementCondition .10
5.2.5 GroupType .10
5.2.6 MessageType .10
5.2.7 MessageInTransactionType .10
5.2.8 OrganisationType .10
5.2.9 PersonType .10
5.2.10 ProjectType.10
5.2.11 RoleType .10
5.2.12 SimpleElementType .10
5.2.13 TransactionPhaseType .11
5.2.14 TransactionType .11
5.2.15 UserDefinedType .11
Annexe A (normative) Définition du schéma de cadre d’interaction .12
Annexe B (normative) Définition des modèles .46
Annexe C (informative) Exemple de carte d’interaction d’un bureau d’études simplifié .65
Annexe D (informative) Principes de l’algorithme Promotor (Convertisseur) .77
Bibliographie .78
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
L’ISO 29481-2 a été élaborée par le comité technique ISO/TC 59, Bâtiments et ouvrages de génie civil,
sous-comité SC 13, Organisation de l’information concernant les travaux de construction.
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
Les parties suivantes sont en préparation:
— Partie 3: Définitions de vues du modèle
iv © ISO 2012 – Tous droits réservés
Introduction
La modélisation d’informations de la construction propose un concept permettant de décrire et de
présenter les informations requises dans la conception, la réalisation et l’exploitation d’installations du
secteur de la construction. Elle permet de rassembler les divers éléments d’information utilisés dans la
construction 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.
Un Protocole d’échange d’informations (IDM, Information delivery manual) offre une aide significative à
l’obtention de tous les avantages découlant d’un modèle d’informations de la construction (BIM, building
information model). Si les informations requises sont disponibles lorsqu’elles sont nécessaires et que
leur qualité est satisfaisante, le processus de construction lui-même peut être grandement amélioré. Il
convient pour cela d’établir une compréhension commune des processus de construction ainsi que des
informations nécessaires à leur réalisation et des résultats fournis à l’issue de leur exécution.
La présente partie de l’ISO 29481 est consacrée aux aspects du processus de construction qui concernent
la gestion et la coordination des parties concernées. La coordination dépend de la communication:
il convient que celle-ci soit bien structurée, non ambiguë, explicite et rapide. Étant consacrée à la
coordination et aux interactions, la présente partie de l’ISO 29481 complète naturellement les normes
consacrées à la modélisation de construction, comme l’ISO 10303-239 et l’ISO 16739.
La présente partie de l’ISO 29481 définit une méthodologie et un format de description des actes de
coordination entre les acteurs d’un projet de construction. Elle décrit la manière d’identifier et de définir
les processus de coordination entrepris et les informations nécessaires à leur exécution. Les cadres
d’interaction résultants permettent la normalisation des interactions des processus de construction au
niveau national, au niveau local et au niveau du projet. Elle propose également un format permettant
la prise en charge des solutions offertes par les fournisseurs de solutions basées sur les Technologies
de l’Information et de la Communication (TIC). La prise en charge de la présente partie de l’ISO 29481
dans diverses solutions TIC signifie qu’elle est adaptée à différents systèmes de gestion de processus.
En cela, elle 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 envoient ou reçoivent et en leur
adéquation aux activités de coordination qu’ils doivent réaliser.
Le développement de la présente partie de l’ISO 29481 a été guidé par le besoin de fiabilité dans les
échanges d’informations nécessaire aux utilisateurs. Elle est basée principalement sur la norme
néerlandaise VISI développée en 2003.
NORME INTERNATIONALE ISO 29481-2:2012(F)
Modèles des informations de la construction — Protocole
d’échange d’informations —
Partie 2:
Cadre d’interaction
1 Domaine d’application
La présente partie de l’ISO 29481 spécifie une méthodologie et un format de description des «actions de
coordination» entre les acteurs d’un projet de construction à toutes les étapes du cycle de vie.
Par conséquent, elle spécifie:
— une méthodologie qui décrit un cadre d’interaction;
— une manière adaptée d’identifier les responsabilités et les interactions, qui donne un contexte aux
flux d’informations du processus;
— un format dans lequel il est recommandé de spécifier le cadre d’interaction.
La présente partie de l’ISO 29481 est destinée à faciliter l’interopérabilité entre les logiciels utilisés
dans le processus de construction, afin de promouvoir la collaboration numérique entre les acteurs
du processus de construction et de fournir 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 29481-1, Modèles des informations de la construction — Contrat d’interchange — Partie 1:
Méthodologie et format
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
3.1
IDM
Protocole d’échange d’informations (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
3.2
cadre d’interaction
description formelle des éléments de l’interaction, comprenant la définition des rôles, les transactions,
les messages des transactions et les éléments de données dans les messages
3.3
schéma de cadre d’interaction
description formelle des règles auxquelles un cadre d’interaction doit être conforme
3.4
schéma d’interaction
description formelle des règles auxquelles les messages envoyés et reçus doivent être conformes
3.5
convertisseur
algorithme qui génère un schéma d’interaction à partir d’un cadre d’interaction, d’un schéma de cadre
d’interaction et d’un fichier de modèles de schémas d’interaction
3.6
fichier de modèles
fichier contenant un certain nombre de modèles de schémas d’interaction, indépendants du cadre
d’interaction, destinés à générer un schéma d’interaction
3.7
VISI
acronyme de la norme néerlandaise pour la communication entre les partenaires de projets de
construction
Note 1 à l’article: VISI signifie «Voorwaarden scheppen voor Invoeren Standaardisatie ICT in de Infrastructuur-
sector» qui se traduit par «Création des conditions de mise en œuvre de la normalisation TIC (Technologies de
l’Information et de la Communication) pour l’industrie de la construction».
4 Principes de la norme
4.1 Généralités
Le présent article est destiné à souligner et expliquer les concepts essentiels sur lesquels est basée la
présente partie de l’ISO 29481.
4.2 BIM et IDM
La modélisation d’informations de construction (BIM ou Building Information Modeling) rassemble
les divers éléments d’information utilisés dans la construction en un environnement d’information
commun. Il convient pour cela d’établir une compréhension commune des processus de construction
ainsi que des informations nécessaires à leur réalisation et des résultats de leur exécution.
L’ISO 29481 est une norme qui définit une méthode de développement d’un Protocole d’échange
d’informations (IDM ou Information Delivery Manual).
La méthodologie IDM donnée dans l’ISO 29481-1 doit être utilisée pour toutes les références au
développement et à l’utilisation de l’IDM.
4.3 Composants de l’IDM
La méthodologie et les composants de l’IDM sont décrits dans l’ISO 29481-1. Cette partie décrit une
illustration qui représente de manière schématique les différents composants de l’IDM et la manière
dont ils sont reliés.
L’IDM offre deux points de vue. Ce sont d’une part des exigences de l’utilisateur et d’autre part des
solutions techniques. Dans les deux points de vue, il existe un certain nombre de zones qui caractérisent
les divers composants de l’IDM (voir la Figure 1).
2 © ISO 2012 – Tous droits réservés
Figure 1 — Zones de l’IDM
Du point de vue des exigences de l’utilisateur, ces zones sont les suivantes:
— cartes d’interaction, décrivant les rôles et les interactions entre ceux-ci;
— cartes de processus, décrivant le processus général dans lequel a lieu l’échange d’informations;
— fourniture d’informations, décrivant les besoins d’échange d’informations;
— processus de référence (descriptions d’échanges mémorisées);
— le programme du projet (occurrences de processus dans le contexte d’un projet).
Le point de vue des solutions techniques comprend:
— les objets métier comprenant le modèle d’exigences relatives à l’échange;
— la spécification des informations, décrivant le schéma sur lequel est basé l’échange d’informations;
— le modèle d’informations de la construction.
La présente partie de l’ISO 29481 est consacrée à la carte d’interaction et est basée sur les principes
généraux de la communication métier.
4.4 Principes de base de la communication métier
Lorsqu’un maître d’ouvrage ou un donneur d’ordres a demandé à livrer un produit ou fournir un service,
une chaîne d’activités se met en place, dont les effets combinés entrainent la fourniture du produit ou
du service. Cette chaîne d’activités est appelée un processus métier. Il s’agit ici plus spécifiquement d’un
processus métier principal car il est initié en externe.
Une partie du processus métier est constituée par la communication entre les parties concernées. La
présente partie de l’ISO 29481 se concentre sur la communication relative à la fourniture d’un résultat
(communication performative). L’initiation et l’exécution d’une demande se font par le biais d’actions de
communication. Dans une action de communication, deux parties sont toujours impliquées: la personne
qui a exécuté l’action et la personne qui est destinataire de l’action. La gestion d’une demande se produit
suivant un schéma particulier appelé la transaction.
Figure 2 — Schéma d’une transaction (Dietz, 2006)
La Figure 2 présente la forme la plus simple de ce schéma de transaction. Elle montre que l’obtention
d’un nouveau résultat de production (par exemple, le «résultat souhaité» est la livraison d’un document)
commence par la demande de ce résultat par une personne jouant le rôle de donneur d’ordres auprès
d’une personne jouant le rôle de producteur. Cela amène le processus au stade «résultat demandé».
Le producteur répond à la demande en promettant de produire le résultat souhaité, ce qui amène le
processus au stade «résultat promis». Cela représente une tâche à effectuer pour le producteur: il doit
respecter la promesse en préparant effectivement le document et en décidant de livrer le document.
Dans l’acte de transfert du document au donneur d’ordres, il déclare qu’il a respecté sa promesse.
Le donneur d’ordres répond à ce stade en acceptant le résultat tel que produit. Cet acte termine la
transaction.
De nombreux acteurs sont souvent impliqués dans l’exécution de processus métiers. Leur comportement
dépend de leur rôle dans le processus. Les rôles/acteurs traitent avec d’autres rôles/acteurs en
exécutant des transactions. Une représentation pratique de l’interaction entre les rôles/acteurs est
appelée la carte d’interaction.
4.5 Carte d’interaction
Une carte d’interaction doit identifier les types de rôles et les types de transactions pertinents pour un
processus donné. 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. Une transaction ne doit avoir qu’un seul rôle initiateur et un
seul rôle exécutant. La Figure 3 représente les composants de la carte d’interaction.
NOTE La notation de la carte d’interaction est basée sur le modèle de construction tel que décrit dans la
publication du Prof. Jan L.G. Dietz. Cette notation diffère de celle de BPMN (Business Process Modeling Notation)
et est utilisée pour préparer des cartes qui soient aussi simples que possible. Elle propose également le concept
de «transaction», qui n’est pas disponible dans BPMN.
4 © ISO 2012 – Tous droits réservés
Figure 3 — Composants de la carte d’interaction
L’avantage de la carte d’interaction est qu’elle focalise l’attention sur les interfaces entre les rôles tout
en masquant la complexité du processus au sein du domaine des rôles et les détails de l’interaction entre
les rôles. L’utilisation de rôles abstraits valide la carte d’interaction pour de nombreuses situations
différentes. La carte d’interaction est un outil précieux pour analyser et définir les éléments essentiels
d’un processus métier. La Figure 4 représente un exemple simplifié de la carte d’interaction d’un bureau
d’études.
Figure 4 — Exemple de carte d’interaction
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. Tous les rôles et transactions de la carte
d’interaction doivent avoir une identité et un nom uniques. La numérotation est arbitraire. Le nom du
rôle est dérivé de l’activité principale entreprise par le rôle; ceci attire l’attention sur la contribution
du rôle au BIM. Un rôle composite est un rôle qui peut être constitué de plusieurs rôles mais dont la
composition est inconnue ou non pertinente.
Les interactions peuvent être récapitulées dans une table de transaction.
Tableau 1 — Table de transaction d’un bureau d’études simplifié
Résultat de la transaction Type de transaction
L’étude est livrée T , Livrer l’étude
La spécification du système est livrée T , Livrer la spécification du système
Le modèle 3D est livré T , Livrer le modèle 3D
Le calcul des coûts est livré T , Livrer le calcul des coûts
4.6 Messages de la transaction
Une transaction doit contenir un ensemble de messages qui sont échangés dans un but particulier.
La transaction stipule également les rôles participants, l’étape du cycle de vie et l’ordre dans lequel il
convient de délivrer les messages (le cas échéant).
La gestion d’une demande de modèle 3D est un exemple de transaction. Voir la Figure 5, qui représente
les messages d’une transaction sous forme de diagramme en notation UML. La transaction peut être
initiée uniquement par la conduite de projet R1 au moyen du message «Demande de modèle 3D».
L’ingénieur 3D (rôle R3) peut répondre par un message «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.
Figure 5 — Exemples de messages d’une transaction
Un message est un modèle d’information rempli et contient des données. Des pièces jointes peuvent être
attachées aux messages. En tant que pièce jointe, une exigence d’échange peut être transférée au rôle
exécutant et le résultat (contribution au BIM) est livré au rôle initiateur. Au moyen des transactions, le
transfert d’informations est amené dans le contexte d’un processus.
4.7 Cadre d’interaction
Afin de guider un processus et un transfert d’informations, les éléments de l’interaction doivent être
décrits de manière cohérente. Cette description cohérente est appelée un cadre d’interaction. Un cadre
d’interaction doit comprendre les éléments suivants:
— définition des rôles concernés;
6 © ISO 2012 – Tous droits réservés
— transactions;
— messages de la transaction;
— ordre des messages de la transaction;
— éléments de données contenus dans les messages.
Un cadre d’interaction peut être préparé pour un domaine d’application défini et utilisé en tant que
norme aux niveaux international, national, de l’organisation ou du projet. Par exemple aux Pays-Bas,
un cadre d’interaction est développé au niveau national pour l’achèvement de toutes les procédures
contractuelles durant l’exécution d’un projet de construction. La présente partie de l’ISO 29481
est utilisée comme modèle par des organisations et des projets et adaptée en fonction des besoins
spécifiques.
EXEMPLE Un cadre d’interaction peut comprendre l’attribut CostEstimation (estimation de coûts) comme
instance d’un SimpleElementType (type d’élément simple) à utiliser comme élément obligatoire pour un certain
message. Il peut également comprendre une restriction sur le format de l’attribut CostEstimation (p. ex.
uniquement des euros, à deux chiffres après la virgule).
4.8 Prise en charge des solutions logicielles
4.8.1 Vue d’ensemble
L’étape suivante consiste à prendre en charge le cadre d’interaction avec des solutions logicielles.
L’objectif est:
— de prendre en charge l’édition d’un cadre d’interaction;
— de garantir l’exhaustivité et la validité d’un cadre d’interaction;
— de prendre en charge la portabilité d’un cadre d’interaction;
— de prendre en charge le fonctionnement des systèmes d’information;
— de prendre en charge l’interopérabilité des communications.
Dans le support des solutions logicielles, deux niveaux peuvent être identifiés. Le premier niveau
concerne le cadre d’interaction. Le second niveau concerne la communication effective qui est basée sur
le cadre d’interaction. La présente partie de l’ISO 29481 s’applique aux deux niveaux.
La Figure 6 présente une vue d’ensemble de la prise en charge des produits immatériels. Les sections
qui suivent donnent les explications.
4.8.2 Prise en charge du cadre d’interaction
Afin de prendre en charge la portabilité d’un cadre d’interaction, il convient de connaître clairement les
règles auxquelles le cadre d’interaction doit se conformer. Ces règles doivent être incluses dans un schéma
de cadre d’interaction qui est enregistré dans un fichier de schéma XSD. Un cadre d’interaction comprend
des instances de classes définies dans le schéma et doit être enregistré sous forme de fichier XML.
EXEMPLE Le schéma de cadre d’interaction définit la manière d’inclure la définition des attributs
(SimpleElementType) et les restrictions aux attributs (UserdefinedType, type défini par l’utilisateur) dans un
cadre d’interaction.
Le Chapitre 5 décrit le schéma de cadre d’interaction et les classes disponibles.
Il convient que chaque cadre d’interaction soit conforme au schéma de cadre d’interaction.
Il convient qu’un éditeur de cadre d’interaction utilise le schéma de cadre d’interaction pour valider les
cadres produits.
4.8.3 Promotor (Convertisseur)
Une fois qu’un cadre d’interaction valide est disponible, il peut être interprété par un système
d’information adapté. Ensuite, ce système peut prendre en charge les communications conformément
aux options définies dans le cadre d’interaction. Enfin, il est souhaitable d’être en mesure de valider les
messages reçus et envoyés; ceci se fait au moyen du schéma d’interaction.
Le schéma d’interaction est généré par un algorithme général appelé Promotor. Le Promotor «convertit»
les instances XML en classes XSD. Les données d’entrée sont les suivantes:
— cadre d’interaction (XML);
— schéma de cadre d’interaction (XSD);
— fichiers de modèles (XSD), contenant un certain nombre de modèles non décrits dans un cadre
d’interaction mais valables pour tous les schémas d’interaction, par exemple l’en-tête de message.
Les données de sortie sont constituées du schéma d’interaction enregistré sous forme de fichier XSD.
EXEMPLE Le Promotor prend des informations dans le cadre d’interaction pour inclure l’attribut
CostEstimation à utiliser comme élément obligatoire pour un certain message et crée un schéma d’interaction
qui définit le message à l’aide de l’attribut CostEstimation.
L’Annexe B décrit le fichier XSD de modèles.
L’Annexe D explique les principes du Promotor.
Figure 6 — La prise en charge des solutions logicielles
8 © ISO 2012 – Tous droits réservés
4.8.4 Prise en charge de la communication
Il convient que chaque système d’information qui participe à la communication, tel que définie
dans le cadre d’interaction, fonctionne sur la base du cadre d’interaction et du schéma d’interaction
correspondants. Il convient que chaque message envoyé ou reçu soit valable conformément au schéma
d’interaction.
4.8.5 Mise en œuvre technique de la communication
Afin de garantir que les messages avec pièces jointes techniques soient échangés entre les systèmes
d’information, des lignes directrices sont nécessaires pour la mise en œuvre. Les sujets à traiter
comprennent les suivants:
— protocole de communication;
— architecture/serveurs de communication;
— chiffrement;
— appels de fonction SOAP.
Les lignes directrices de mise en œuvre ne font pas partie du domaine d’application de la présente
partie de l’ISO 29481.
5 Format d’un cadre d’interaction
5.1 Introduction
L’Article 4 explique que, pour prendre en charge les solutions logicielles, il faut que chaque cadre
d’interaction soit conforme au schéma de cadre d’interaction. Cet article est inclus afin de définir le
format d’un cadre d’interaction par le biais d’une description du schéma de cadre d’interaction.
L’Article 5.2 présente une vue d’ensemble des classes d’information qui peuvent exister dans un cadre
d’interaction et sont définies dans le schéma de cadre d’interaction. Un cadre d’interaction étant défini
en XML, le mot «type» est utilisé, plutôt que «classe». L’Annexe A donne la description complète du
schéma de cadre d’interaction. L’Annexe C donne un exemple d’instance d’un cadre d’interaction.
5.2 Types d’information dans le schéma de cadre d’interaction
5.2.1 Introduction
Un schéma est rempli par de nombreux types ou classes. La présente section donne une brève description
des types disponibles dans le schéma de cadre d’interaction. L’Annexe A contient une description XML
complète du schéma de cadre d’interaction. Un cadre d’interaction doit être créé à partir d’instances de
ces types et doit posséder un en-tête qui pointe vers le schéma contenant les types disponibles définis.
5.2.2 AppendixType
Le type AppendixType (type Annexe) est une définition permettant de définir la structure d’éléments
relatifs à des métadonnées. Une instance d’un AppendixType est utilisée pour définir certains types de
fichiers ou documents qui peuvent faire partie des messages envoyés/reçus. La structure des éléments
relatifs à une instance d’un AppendixType représente les métadonnées spécifiques requises pour un
certain type de fichier ou document.
5.2.3 ComplexElementType
Un ComplexElementType (type Élément complexe) est un ensemble de SimpleElementTypes (type
Élément simple). Chaque SimpleElementType se produit exactement le nombre de fois mentionné.
5.2.4 ElementCondition
Une instance d’un ElementCondition (condition de l’élément) décrit le comportement de valeurs de
l’élément dans des messages successifs. Par exemple, lorsqu’une instance du type ElementCondition
est créée avec la valeur FIXED (fixe), cela indique que les éléments dans les messages successifs
doivent être copiés lorsque le même élément est disponible et que la valeur ne peut pas être modifiée.
Un ElementCondition peut se référer à des niveaux différents dans un cadre. Il peut être directement
associé à un SimpleElement mais il est possible également d’associer un ElementCondition à un
ComplexElement ou un MessageInTransactionType (type Message dans la transaction). Dans ce cas, le
ElementCondition est valable pour tous les éléments qui font partie de la structure ou de l’ensemble des
éléments des types associés.
5.2.5 GroupType
Un GroupType (type Groupe) permet de créer plusieurs instances d’un groupe avec leur propre contenu
spécifique. Le GroupType peut être utilisé pour catégoriser les messages au sein d’une transaction ou
les documents associés aux messages d’une transaction.
5.2.6 MessageType
Le MessageType (type Message) sert à définir le contenu d’un message. Les éléments qui font partie d’un
message sont à leur tour regroupés dans une ou plusieurs instances d’un ComplexElementType.
5.2.7 MessageInTransactionType
Le MessageInTransactionType (MITT) est une définition utilisée pour associer le MessageType au
TransactionType. Ou dit plus simplement: le même type de message peut se produire plusieurs fois
dans un type de transaction donné et vice-versa. Il est possible d’associer plusieurs mêmes instances
d’un MessageType à une instance d’un TransactionType et une instance d’un MessageType à plusieurs
instances d’un TransactionType. De plus, un MITT offre l’option d’inversion de la direction de l’exécutant
à l’initiateur. Une autre option contrôle si le flux de message est bloqué ou non par des transactions
secondaires ouvertes.
5.2.8 OrganisationType
Définition d’un certain groupe d’organisations. Au moins une instance commune est disponible dans le
cadre, avec pour raison particulière la définition de la structure des éléments d’une organisation.
5.2.9 PersonType
Définition d’un type de personne. Au moins une instance commune est disponible dans le cadre, avec
pour raison particulière la définition de la structure des éléments d’une personne. Le PersonType peut
être utilisé pour catégoriser les groupes de personnes associées à un rôle.
5.2.10 ProjectType
Définition d’un type de projet. Au moins une instance commune est disponible dans le cadre, avec pour
raison particulière la définition de la structure des éléments du projet.
5.2.11 RoleType
Définition d’un rôle. Les instances d’un RoleType sont des prérequis pour créer un TransactionType
dans un cadre.
5.2.12 SimpleElementType
Le SimpleElementType est une définition qui décrit des propriétés pouvant exister dans les structures
d’objets. La relation à un objet se fait toujours par le biais d’un ComplexElementType.
10 © ISO 2012 – Tous droits réservés
5.2.13 TransactionPhaseType
Définition pouvant être utilisée pour définir une instance qui décrit la phase dans laquelle se trouve
une transaction. Par exemple, une instance d’un TransactionPhaseType (type Phase de la transaction)
peut être «résultat demandé» ou «en attente».
5.2.14 TransactionType
Définition d’une transaction. Dans une instance d’une Transaction, les rôles de l’initiateur et de
l’exécutant sont définis.
5.2.15 UserDefinedType
Le UserDefinedType (Type Défini par l’utilisateur) sert à définir des types de données (par exemple
une chaîne) et des restrictions XSD. Par exemple, la longueur minimale d’une chaîne peut être définie à
l’aide d’une instance de UserDefinedType.
La Figure 7 illustre le modèle du schéma de cadre d’interaction avec toutes ses références.
Figure 7 — Types et références du schéma de cadre d’interaction
Annexe A
(normative)
Définition du schéma de cadre d’interaction
A.1 Introduction
Il est nécessaire qu’un cadre d’interaction soit conforme aux règles comprises dans un schéma de
cadre d’interaction. La présente annexe donne la définition du schéma de cadre d’interaction en format
EXPRESS et en format XSD. Des descriptions des types d’éléments, attributs, éléments et références
sont également données.
Tous les objets d’un cadre d’interaction nécessitent une date de début et une date de fin. Cette exigence
a pour but d’autoriser des contraintes de temps sur la validité d’un objet donné.
A.2 Définition du schéma de cadre d’interaction (format EXPRESS)
SCHEMA ISO 29481_Part_2A;
ENTITY ProjectType; — La définition d’un groupe de projets spécifique. Généralement, une seule
instance est présente dans un cadre d’interaction qui définit la structure des éléments que contient
chaque instance du projet.
namespace: STRING;
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
END_ENTITY;
ENTITY PersonType; — La définition d’un groupe de personnes spécifique. Généralement,
une seule instance est présente dans un cadre d’interaction qui définit la structure des éléments que
contient chaque instance de la personne.
description: STRING;
startDate: DATETIME;
12 © ISO 2012 – Tous droits réservés
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
END_ENTITY;
ENTITY OrganisationType; — La définition d’un groupe d’organisations spécifique.
Généralement, une seule instance est présente dans un cadre d’interaction qui définit la structure des
éléments que contient chaque instance de l’organisation.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
END_ENTITY;
ENTITY AppendixType; — Un AppendixType contient la définition d’une annexe. Les
éléments de données qu’il convient d’enregistrer avec une annexe peuvent être spécifiés dans la section
des éléments complexes.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
END_ENTITY;
ENTITY ComplexElementType; — Un ComplexElementType contient un ensemble de
SimpleElementTypes. Chaque SimpleElementType déclaré se produit exactement le nombre de fois qu’il
est mentionné.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
simpleElements: OPTIONAL SET [0:?] OF SimpleElementType;
END_ENTITY;
ENTITY MessageType; — La définition d’un type de message (MessageType), spécifiant la structure
du message et l’ensemble de SimpleElementTypes (via ComplexElementType) qui peut l’accompagner.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
appendixTypes: OPTIONAL SET [1:?] OF AppendixType;
14 © ISO 2012 – Tous droits réservés
END_ENTITY;
ENTITY ElementCondition; — La condition d’un SimpleElementType utilisé dans un
MessageType spécifique.
description: STRING;
condition: STRING;
helpInfo: OPTIONAL STRING;
complexElement: OPTIONAL ComplexElementType;
simpleElement: OPTIONAL SimpleElementType;
messageInTransaction: OPTIONAL MessageInTransactionType;
END_ENTITY;
ENTITY SimpleElementType; — La définition d’un type d’élément simple (SimpleElementType).
Ce type d’élément spécifie une propriété qui peut exister dans diverses structures d’objets, par exemple
dans MessageType (voir également AppendixType, ProjectType, PersonType et OrganisationType). Un
SimpleElementType est toujours intégré dans un ComplexElementType.
description: STRING;
interfaceType: STRING;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
valueList: OPTIONAL STRING;
userDefinedType: UserDefinedType;
END_ENTITY;
ENTITY UserDefinedType; — Une spécification d’un type de données (à utiliser dans un
SimpleElementType). Ce type de données encapsule des zones à remplir dans le message final, par
exemple, un code postal néerlandais commence toujours par quatre chiffres puis deux caractères.
description: STRING;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
baseType: STRING;
xsdRestriction: OPTIONAL STRING;
language: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
END_ENTITY;
ENTITY MessageInTransactionType; — L’occurrence d’un MessageType dans un TransactionType
associé à un certain type Groupe (GroupType).
requiredNotify: INTEGER;
dateLaMu: DATETIME;
userLaMu: STRING;
received: BOOLEAN;
send: BOOLEAN;
state: STRING;
initiatorToExecutor: OPTIONAL BOOLEAN;
openS
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.