ISO 16757-4:2025
(Main)Data structures for electronic product catalogues for building services — Part 4: Data dictionary structures for product catalogues
Data structures for electronic product catalogues for building services — Part 4: Data dictionary structures for product catalogues
This document specifies requirements for data dictionaries that are used by product catalogues for building services to provide the semantics of their definitions and data modelling. For this purpose, it defines an overall model that contains: — subject kinds that allow to distinguish: — product subjects representing products in product catalogues; — catalogue subjects comprising meta data of product catalogues; — various kinds of blocks that collect properties of complex product features, including ports and in/outlets; — relationship types that allow to distinguish between different kinds of relationships like isSubtypeOf, hasPart, or hasBlock; — property kinds to distinguish between: — static properties describing products by providing property values in product catalogues; — dynamic properties that describe the behaviour of products; — external properties that represent external conditions that influence the behaviour of the product by influencing the values of dynamic properties. This document also describes a mapping of the overall model to the data dictionary model of ISO 12006-3 by introducing a dictionary meta level. Finally, to overcome deficiencies of the standards underlying ISO 16757-5 in capturing all aspects of product catalogues, this document provides some rules and recommendations for required data dictionary elements. This document does not describe how product catalogues have to be organized, and it does not describe any formats for the exchange of product catalogues. Product catalogues are described in ISO 16757-5.
Structures de données pour catalogues électroniques de produits pour les services du bâtiment — Partie 4: Structures des dictionnaires de données pour les catalogues de produits
Le présent document spécifie des exigences relatives aux dictionnaires de données qui sont utilisés par les catalogues de produits pour les services du bâtiment afin de fournir la sémantique de leurs définitions et de permettre la modélisation des données. À cet effet, il définit un modèle global qui contient: — des catégories de sujets permettant de distinguer: — les sujets de produits représentant des produits dans les catalogues de produits; — les sujets de catalogues comprenant des métadonnées des catalogues de produits; — différentes catégories de blocs qui rassemblent les propriétés des caractéristiques complexes des produits, y compris des interfaces et des entrées/sorties; — des types de relation qui permettent de distinguer différentes catégories de relations telles que isSubtypeOf, hasPart ou hasBlock; — des catégories de propriétés pour distinguer: — les propriétés statiques décrivant des produits en fournissant des valeurs de propriétés dans les catalogues de produits; — les propriétés dynamiques qui décrivent le comportement des produits; — les propriétés externes qui représentent les conditions externes qui ont un impact sur le comportement du produit en ayant une influence sur les valeurs des propriétés dynamiques. Le présent document décrit également une mise en correspondance du modèle global avec le modèle de dictionnaire de données de l’ISO 12006-3 en introduisant un méta-niveau de dictionnaire. Enfin, pour pallier les déficiences des normes sous-jacentes à l’ISO 16757-5 dans la capture de tous les aspects des catalogues de produits, le présent document fournit plusieurs règles et recommandations relatives aux éléments requis des dictionnaires de données. Le présent document ne décrit ni la façon dont les catalogues de produits doivent être organisés, ni les formats d’échange des catalogues de produits. Les catalogues de produits sont décrits dans l’ISO 16757-5.
General Information
Relations
Standards Content (Sample)
International
Standard
ISO 16757-4
First edition
Data structures for electronic
2025-10
product catalogues for building
services —
Part 4:
Data dictionary structures for
product catalogues
Structures de données pour catalogues électroniques de produits
pour les services du bâtiment —
Partie 4: Structures des dictionnaires de données pour les
catalogues de produits
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 . 2
4 Modelling of required kinds of data . 3
4.1 General .3
4.2 Overall model .3
4.3 Subject kinds of the overall model .4
4.3.1 Product .4
4.3.2 Catalogue . .5
4.3.3 Block .6
4.3.4 Ports and in/outlets .7
4.4 Relationship types .9
4.4.1 isSubtypeOf .9
4.4.2 hasPart .10
4.4.3 hasBlock .11
4.4.4 isDependentOn .11
4.4.5 isSubkindOf .11
4.5 Property kinds and their representation in the overall model . 12
4.5.1 General . 12
4.5.2 What does a property describe . 12
4.5.3 Representation of the property kinds using the overall model . 13
4.6 Relationship to data templates . 15
5 Representation of the overall model by means of ISO 12006-3 .15
5.1 General . 15
5.2 Relationships in ISO 12006-3 .16
5.2.1 Overview .16
5.2.2 Property relationships .16
5.2.3 Subject relationships .16
5.3 Dictionary meta level to define subject kinds and relationship types .17
5.4 Kinds of subjects at the dictionary meta level . 20
5.5 Subject relationship types at the dictionary meta level . 20
5.6 Property relationships . 22
6 Specific rules and recommendations .22
6.1 General . 22
6.2 Rules for specific situations . 22
6.2.1 Cardinality properties for hasPart and hasBlock relationships . 22
6.2.2 References to literature . 22
6.2.3 Positioning in space . 23
6.2.4 Predefined calculation functions for dynamic properties . 23
6.2.5 Relationships to classifications or other dictionaries . 23
6.3 Recommendations for dealing with controlled value lists .24
6.3.1 Problem description .24
6.3.2 Property value list with subject contextual filtering .24
Bibliography .25
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 document 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).
A list of all parts in the ISO 16757 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
Building information modelling (BIM) provides a means for describing and displaying information required
throughout the asset life cycle. Increasingly this modelling approach is expanding to encompass all aspects
of the built environment, including civil infrastructure, utilities and public space.
The ISO 16757 series provides the structure of a product catalogue model for data sharing and data exchange
of product models in product catalogues. It contains specifications for:
— selection of products from different product classes and product variants;
— combining product components and accessories to products;
— geometrical representation in technical systems;
— connectivity to other products in models of technical systems;
— calculation of dynamic property values in accordance with the product behaviour in technical systems.
This document outlines the requirements for data dictionaries to support both semantic definitions and
data modelling in product catalogues. ISO 12006-3 defines the underlying data model for related data
dictionaries and serves as the foundation of this document.
Tools are used to define, simulate and operate building services systems (including e.g. HVAC systems and
building automation systems). To build such a system basically means to interconnect different products
in a way that the resulting system fits into the building and works in accordance with the functional
requirements. The products are selected from product catalogues of manufacturers or distributors.
Important aspects of these products are their connection points and information on their behaviour in
different situations.
The goal of this document is to support the engineering tools by enabling them to identify the relevant
information easily in different data dictionaries. In the area of building services, a few generic concepts are
widely used:
— dynamic properties describing the behaviour of products in different situations and load cases that are
dependent on external properties describing external conditions;
— a distinction of data dictionary entries representing products, meta data of catalogues, and specific
features of products like subfunctions or ports.
This document defines common kinds of data dictionary elements that provide a way to identify the basic
structures across data dictionaries.
Besides this document, the ISO 16757 series contains the following documents:
— ISO 16757-1 describes the fundamental concepts and assumptions about the creation of manufacturer-
related product catalogues as BIM data exchange models. It describes the content of product catalogues
and the mapping of the content to a data format.
This data format provides the opportunity to search and select product data together with accessory
data which can be read into software applications for planning, designing, calculating and simulating as
well as for facility management.
— ISO 16757-2 describes the concept of geometry of the building services product data of a product
catalogue in form of 2D symbols and 3D shape models and specifies the required spaces and ports.
It contains the fundamental concepts and assumptions about the parametric geometry of special
products, used in planning software applications e.g. for air condition systems such as ducts and
transitions between different forms. It also contains a concept for representing products as 3D solid
models, which are made from thin sheet metal.
v
— ISO 16757-5 specifies the organization of product catalogues on the basis of ISO 16739-1 (Industry
Foundation Classes, IFC) and EN 17549-2. These product catalogues get the semantics of their properties
from data dictionaries that are described in this document.
It contains an overview about the representation of important elements of product catalogues and gives
detailed specifications of the usage of IFC structures in the product catalogues.
vi
International Standard ISO 16757-4:2025(en)
Data structures for electronic product catalogues for building
services —
Part 4:
Data dictionary structures for product catalogues
1 Scope
This document specifies requirements for data dictionaries that are used by product catalogues for building
services to provide the semantics of their definitions and data modelling. For this purpose, it defines an
overall model that contains:
— subject kinds that allow to distinguish:
— product subjects representing products in product catalogues;
— catalogue subjects comprising meta data of product catalogues;
— various kinds of blocks that collect properties of complex product features, including ports and in/
outlets;
— relationship types that allow to distinguish between different kinds of relationships like isSubtypeOf,
hasPart, or hasBlock;
— property kinds to distinguish between:
— static properties describing products by providing property values in product catalogues;
— dynamic properties that describe the behaviour of products;
— external properties that represent external conditions that influence the behaviour of the product
by influencing the values of dynamic properties.
This document also describes a mapping of the overall model to the data dictionary model of ISO 12006-3 by
introducing a dictionary meta level.
Finally, to overcome deficiencies of the standards underlying ISO 16757-5 in capturing all aspects of product
catalogues, this document provides some rules and recommendations for required data dictionary elements.
This document does not describe how product catalogues have to be organized, and it does not describe any
formats for the exchange of product catalogues. Product catalogues are described in ISO 16757-5.
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 12006-3, Building construction — Organization of information about construction works — Part 3:
Framework for object-oriented information
ISO 23386, Building information modelling and other digital processes used in construction — Methodology to
describe, author and maintain properties in interconnected data dictionaries
ISO 23387:2025, Building information modelling (BIM) – Data templates for objects used in the life cycle of assets
3 Terms and definitions
For the purposes of this document, the following terms and definitions 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
property
defined characteristic suitable for the description and differentiation of the objects in a class
[SOURCE: ISO 22274:2013, 3.25, modified — Example has been removed.]
3.2
product property
property (3.1) that describes a product in a product catalogue
EXAMPLE In case of a radiator, examples of product properties are length, width and depth.
3.3
external property
property (3.1) that describes an aspect that is external to a product but influences the behaviour of the product
EXAMPLE In case of a radiator, examples of external properties are the temperature of the incoming medium and
the room temperature.
Note 1 to entry: External properties do not describe the product itself.
3.4
static property
product property (3.2) that is not influenced by external conditions
EXAMPLE In case of a radiator, examples of static properties are length, width and depth that do not depend on
other properties and volume that depends on length, width and depth.
3.5
dynamic property
product property (3.2) that depends on at least one external property (3.3)
EXAMPLE In case of a radiator, an example of a dynamic property is the temperature of the outgoing medium that
depends, among others, on the temperature of the incoming medium and the room temperature.
3.6
in/outlet
interface of a technical unit to its environment for the transfer of substances, energy or signals
3.7
port
interface of a technical unit that can be connected to such an interface of another technical unit for the
transfer of substances, signals, energy or forces
3.8
block
composed property
group of properties (3.1) corresponding to a feature needing multiple properties to be defined
[SOURCE: ISO 23386:2020, 3.8, modified — The preferred term "block" has been added; "category of" has
been removed from the beginning of the definition; note 1 to entry and example have been removed.]
4 Modelling of required kinds of data
4.1 General
For data exchange, both the provider and the recipient should have the same understanding of the data; the
data should be provided on a common basis. The goal is to create this common basis in an open, online data
dictionary. In this clause the necessary kinds of data for that purpose are examined. A data dictionary that
conforms to this document shall provide the necessary structures to support these kinds of data.
The focus of this document is the description of products in a product catalogue. This is in some aspects a
view different from that of a designed building where the products are installed in systems in the building.
The manufacturer does not know how and where the products will be installed within a specific system.
Nevertheless, to describe the behaviour of a product, the manufacturer must provide information on
how the product reacts on different external conditions and how dynamic properties are influenced by
environmental and system-specific factors.
4.2 Overall model
The overall model shows the kinds of data that are required for the description of building services products
in manufacturer’s product catalogues (see Figure 1). It contains a number of subject kinds, a number of
relationship types, and it describes a number of property kinds. In a data dictionary, the subjects shall be
related to their subject kind (see 5.3).
Figure 1 — Overall model
The overall model contains the following subject kinds:
— product: subjects that represent the products in a product catalogue;
— catalogue: subjects that represent the meta data of product catalogues;
— block: subjects representing a feature of an object that is described by more than one property;
— port: specialization of block, representing connection points where ports of other products can
connect to;
— in/outlet: specialization of block, representing interfaces of a product to its environment;
— external: specialization of block, collecting external properties (see 4.5.3.2).
The following relationship types have been defined in the overall model, and the following kinds of line
types and arrow shapes have been used to represent the relationship types in graphical representations:
isSubtypeOf relationship, relating a subject to a more general subject of the same kind;
hasPart relationship, relating a subject to its parts;
hasBlock relationship, relating a product or a catalogue to their blocks;
hasProperty, relating a subject to its properties;
isDependentOn, relating a dependent property to the properties that determine its value;
isSubkindOf, relating subkinds to their more general subject kind.
A data dictionary that conforms to this document shall contain subjects of these subject kinds and
relationships of these relationship types. In the following, subjects will be called in accordance with their
kind and relationships will be called in accordance with their type.
EXAMPLE A subject of kind block is called block subject, a subject of kind product is called product subject, and a
relationship of type hasPart is called hasPart relationship.
NOTE The subject kind external is described in 4.5.3.2.
4.3 Subject kinds of the overall model
4.3.1 Product
Properties are used to describe products. The data dictionary, however, does not contain concrete products.
Products are contained in product catalogues (and databases) that assign the products to product subjects
in a data dictionary. A product subject shall define the properties that can be used to describe products.
These properties are related to that product subject by means of the hasProperty relationship.
A product subject P can be involved in various types of relationships:
— isSubtypeOf: relating it to another product subject that provides a more abstract view of P (see 4.4.1);
— hasPart: relating it to other product subjects that represent the parts or components of P (see 4.4.2);
— hasBlock: relating it to block subjects that represent complex features of P (see 4.4.3).
Product subjects can be independently instantiated, that means, in a product catalogue a product can exist
independently of any other objects. That is different to blocks (see 4.3.3): Blocks shall only exist in a product
catalogue in the context of another object (a product, a block or a catalogue).
EXAMPLE 1 In Figure 2, two product subjects, called “convector” and “radiator”, are specializations of a more
generic product subject “heater”. They are related to it by isSubtypeOf relationships. That means that both convector
and radiator have implicitly also the properties length and height because they inherit them from heater. This is shown
in Figure 2 by the grey repetition of the inherited properties.
Figure 2 — Product subjects related by isSubtypeOf relationships
EXAMPLE 2 A central heating system can be defined as a system that consists of some components: for instance,
it can contain a burner, a boiler and a pump. In a data dictionary, such a central heating system is represented by a
product subject. In the same way, the burner, the boiler and the pump are represented by product subjects. Then the
product subject “central heating system” is related to its components by means of hasPart relationships (see Figure 3).
Figure 3 — System “central heating system” with hasPart relationships
4.3.2 Catalogue
Properties are also used to add meta data to product catalogues. The data about product catalogues
comprise, for instance, the name, version and date of creation of a product catalogue, the validity time, the
software by which the product catalogue has been generated. It can also contain data about the product
catalogue provider, the manufacturer, and in some cases also of the recipient of the product catalogue. To
distinguish product catalogue meta data from product data, a specific subject kind “catalogue” shall be used
to define properties specifying the meta data for product catalogues.
A catalogue subject C can be involved in the following types of relationships:
— isSubtypeOf: relating it to catalogue subjects that provide a more abstract view of C;
— hasPart: relating it to other catalogue subjects that represent the parts or components of C (see 4.4.2);
— hasBlock: relating it to block subjects that represent complex features of C.
Similar to product subjects, catalogue subjects can be independently instantiated.
EXAMPLE 3 The meta data of a product catalogue can consist of a name, a creation date and the name and the
phone number of the provider of the product catalogue. This can be represented in a data dictionary by a catalogue
subject with the properties “name” and “creation_date” and a block containing the data about the product catalogue
provider (see Figure 4).
Figure 4 — Example of a catalogue subject with hasBlock relationship
4.3.3 Block
Properties are often collected in groups.
EXAMPLE 1 Often, sets of properties are combined because they are describing different aspects of one topic. For
instance, length, width, height, etc. can be grouped under the topic dimension.
Often, several properties describe a feature of a product. For understanding a data dictionary, this feature
should be represented by a subject that collects all properties of that feature.
EXAMPLE 2 Connections and ports are inherent parts of a product but each of them is described by a number of
properties.
EXAMPLE 3 In ISO 16739-1, properties are grouped in property sets.
To support such a grouping, the subject kind block is used. A block subject B can be involved in various types
of relationships:
— isSubtypeOf: relating it to a block subject that provides a more abstract view of B (see 4.4.1);
— hasPart: relating it to block subjects that build the parts or components of B (see 4.4.2).
Different to product subjects and catalogue subjects, a block subject shall only be instantiated in relationship
to a product or catalogue subject. It shall always be part of a product or catalogue subject, represented by a
hasBlock or a hasPart relationship.
EXAMPLE 4 Figure 5 extends Figure 2: The product subject “heater” gets a block subject “performance”, and this
block subject comprises performance related properties of a heater. The block subject is related to the product subject
“heater” by means of a hasBlock relationship.
Figure 5 — Product subject “heater” with the block subject “performance” that collects performance
related properties
The following rules apply for blocks:
— any block subject in a data dictionary is part of another block subject, of a catalogue subject or of a
product subject, that means, any block shall be the target of a hasBlock relationship or it shall be the
target of a hasPart relationship;
— block subjects can belong to more than one block subject or product subject; that means, a block subject
can be the target of several hasBlock and hasPart relationships;
— block subjects in a data dictionary can be instantiated several times in a product catalogue.
EXAMPLE 5 A block subject “pin connector” can appear in a chip several times, describing each pin with a number
of properties.
4.3.4 Ports and in/outlets
4.3.4.1 Overview
Two features are important for any engineering system in the area of building services systems and are
used in practically any product in that area:
— ports are the interfaces of building services products to other building services products; any connection
of products in a system is made by means of the connection of ports of the two products;
— in/outlets are the interfaces of building services products that allow an interaction with the environment.
It is not the intention to describe ports and in/outlets with all its semantics in this document, but because
these features play such an important role for engineering tools, two special kinds of blocks have been
defined for them.
4.3.4.2 Ports
In the system model, product ports can be connected to ports of other products. They are used from and to
the product for the transfer of:
— Substances (media)
— Solid (e.g. dust, fibres)
— Viscous (e.g. fire extinguishing foam)
— Liquid (e.g. potable water)
— Gaseous (e.g. natural gas)
— Energy
— Electrical (e.g. at power socket)
— Media bound (e.g. heat, compressed air, any enthalpy)
— Forces
— Fastening (e.g. for connection with wall mounting units)
— Power transmission (e.g. for connection with a joint lever)
— Signals
— Electrical (e.g. through alarm cable)
— Acoustic (e.g. through speaking tube)
— Optical (e.g. through glass fibre optics)
— Media bound (e.g. by pressure surge)
— Operation and control (e.g. by switch, by control panel)
In product catalogues, only the connectable ports of the product to ports of other products are relevant.
Internally connected ports are not of interest. This also applies to ports that have been connected by
combination with components or accessories.
For automated system planning, it is important to specify for each product port the possible matching
mating ports. This avoids incorrect connections or triggers warnings. Product ports that have no connection
to matching mating ports in the system model are to be assumed to have no function.
4.3.4.3 In/outlets
In the building services system model, there are products that have in/outlets to the rooms or the building
environment.
The in/outlets are used to transmit substances, energy or signals.
Unlike ports, which must each be connected to mating ports, the in/outlets are usually free. While ports
do not have calculatable dynamic properties, in/outlets have a direct influence on technical and geometric
properties of the media and signals due to their shape and dimensions. Figure 6 shows an example of a
device with several different in/outlets.
Figure 6 — Example: different in/outlets at a single product
Openings are used for the transfer of:
— Substances (media)
— Solid (e.g. dust, fibres)
— Viscous (e.g. fire extinguishing foam)
— Liquid (e.g. potable water)
— Gaseous (e.g. ventilation air)
— Energy
— Media bound (e.g. heated air or water)
— Electromagnetic radiation (e.g. heat, UV-light)
— Signals
— Operation and control (e.g. by switch, by control panel)
— Acoustic (e.g. alarm siren)
— Optical (e.g. warning light)
4.4 Relationship types
4.4.1 isSubtypeOf
Relationships of type isSubtypeOf relate a subject to a more generic subject of the same kind.
isSubtypeOf relationships build tree structures: A subject can be the root of a tree (it is not a subtype) or it
is a node in the tree (it is subtype of exactly one other subject). The cardinality of this relationship type is
therefore n : (0.1).
The isSubtypeOf relationship type includes property inheritance: If a subject S has a property P, then its
subtypes have also this property P.
EXAMPLE In Figure 2, two product subjects, called “convector” and “radiator”, are subtypes of a more generic
product subject “heater”. They are related to it by “is subtype of” relationships. That means that both convector and
radiator have implicitly also the properties length and height because they inherit them from heater. This is shown in
Figure 2 by the grey repetition of the inherited properties.
NOTE A relationship of type isSubtypeOf is normally not instantiated in a product catalogue. Subjects are normally
instantiated on the lowest level of the isSubtypeOf hierarchy, but their relationship to their more general subjects is
not instatiated. Thus, the isSubtypeOf relationship type is mostly relevant for the data dictionary level itself.
4.4.2 hasPart
Relationships of the type hasPart relate subjects to their parts or components. They can only be used
between subjects of the same kind.
The cardinality is n:m. A subject can have 0 parts, 1 part or several parts. It can be part of 0 or many other
subjects.
EXAMPLE 1 A central heating system can be defined as a system that consists of some components: for instance, it
can contain a burner, a boiler and a pump. In a data dictionary, such a central heating system is defined as a product
subject. In the same way, the burner, the boiler and the pump are product subjects. Then the subject “central heating
system” is related to its components by means of the hasPart relationship (see Figure 3).
EXAMPLE 2 Another example for a hasPart relationship is illustrated in Figure 7: The block subject “dimensions”
has two parts, the “inner dimensions” and the “outer dimensions”.
Figure 7 — hasPart relationship to relate a block to its parts
EXAMPLE 3 Many manufacturers provide cascades as products. A cascade consists of a number of products
of the same type (e.g. a set of burners) that are or can be connected in different ways in accordance with specific
requirements. In the data dictionary, the cascade of burners is represented by a subject “cascade of burners” that has
the subject “burner” as its part [see Figure 8 a)]. In a product catalogue, several burners are related to the instance of
the “cascade of burners” [see Figure 8 b)], and the way how these burners are connected can be defined by values of
respective properties of the “cascade of burners”.
a) In the data dictionary b) In the product catalogue
Figure 8 — Cascades
NOTE It is important to understand the difference between the isSubtypeOf relationship and the hasPart
relationship. In an instance of the data dictionary, for example, in a product catalogue, the hasPart relationship must
be instantiated to connect the instances of the composite object with instances of the components (see Figure 8). The
isSubtypeOf relationship is never instantiated; normally only the leaves of the isSubtypeOf hierarchy are instantiated.
4.4.3 hasBlock
The hasBlock relationship relates a product subject or a catalogue subject to a block subject. It follows the
same rules as the hasPart relationship, the only difference is that it relates other subject kinds (product,
catalogue) to blocks. The cardinality is n:m. A block can belong to several other products or catalogues, and
a product or catalogue can have several blocks.
EXAMPLE An example of the hasBlock relationship is shown in Figure 5. In that example, the product subject
"heater" is connected by means of the hasBlock relationship to the block subject "performance".
4.4.4 isDependentOn
Different to the other relationship types, the isDependentOn relationship is a relationship between
properties. If a property P is dependent on another property D, then the value of P is dependent on the value
of D, and P might change with a change of the value of property D.
EXAMPLE In Figure 9, the property volume is dependent on three other properties: length, width and height.
Figure 9 — isDependentOn relationship
4.4.5 isSubkindOf
This relationship relates subject kinds to each other. It is similar to an isSubtypeOf relationship in the sense
that the characteristics of the upper subject kind are inherited by the lower subject kind. In the overall
model, the subkinds of block can have the same relationships as have been defined for block. And because
they are a subkinds of block, in a product catalogue they can only be instantiated as part of another block
subject, product subject, or catalogue subject.
4.5 Property kinds and their representation in the overall model
4.5.1 General
The purpose of this subclause is to identify the important property kinds that need to be described and the
way how they are represented by use of the overall model.
4.5.2 What does a property describe
The purpose of a manufacturer’s product catalogue is the provision of information about products which
can be ordered and delivered by the manufacturer. The products are described by properties, called product
properties.
Product properties often describe static aspects of the product like length, width, nominal input voltage, etc.
These are static properties.
But it is also necessary to define the behaviour of a product. The behaviour of a product is its reaction on
changing conditions coming from outside of the product. It can be represented by means of properties that
change their values in dependency of these external conditions.
EXAMPLE 1 External conditions can be given by the system into which the product is installed (e.g. the temperature
of an incoming medium) or by the environment in which the product operates (e.g. the temperature of the room in
which a radiator is installed). An example of a property describing a behavioural aspect of a product is the temperature
of the outgoing medium of a radiator that depends, amongst others, on the temperature of the incoming medium and
of the temperature of the room.
Thus, it shall be possible to distinguish between the following property kinds:
— static product properties (static properties for short): properties with values that are given in the product
catalogue (e.g. length, width and depth) or can be determined from given product properties (e.g. volume
that can be derived from length, width and depth);
— dynamic product properties (dynamic properties for short): properties that depend on external
conditions and describe the behaviour of a product under changing external conditions;
— external properties: properties that describe external conditions that influences the behaviour of a
product by influencing the values of dynamic properties.
Often, performance definitions of products must be provided for specifically given external conditions.
EXAMPLE 2 EN 200 defines the minimum flow rate of a washbasin faucet on a type 1 installation as 12 l/min at a
1)
reference pressure of 3 bar .
Even if in such cases for the property (minimum flow rate of a washbasin faucet in the example) an external
property is defined (pressure), this is not a dynamic property. There is no dynamics involved, because
the property is not defined for different conditions. Rather, such a property describes the value for a fixed
external situation, therefore it is a static property. A dynamic property describes the reaction of a product on
different external conditions. Therefore, the minimum flow rate can be defined as an independent property;
and the fixed condition is just mentioned in the definition of the property.
A product catalogue can only contain property values for static properties. Both external properties and
dynamic properties shall not have a value. The value of the external properties can only be given at runtime
which can be a simulation or the operation of the real system with the real products. During a simulation
the simulation software computes various states of the system which can be related to values of the external
properties of a product. By providing them as input to a function the value of the dynamic property is
computed. Because both dynamic properties and external properties can only get a value at runtime, they
are called runtime properties.
A categorization of the various property kinds is depicted in Figure 10.
5 2
1) 1 bar = 0,1 MPa = 10 Pa; 1 MPa = 1 N/mm .
Figure 10 — Categorization of property kinds
4.5.3 Representation of the property kinds using the overall model
4.5.3.1 Modelling elements provided by the overall model
To represent property kinds, the overall model provides basically:
a) dependency relationships between properties; and
b) the subject kind external.
If a property D is dependent on a property P then D is called a dependent property and P
...
Norme
internationale
ISO 16757-4
Première édition
Structures de données pour
2025-10
catalogues électroniques de
produits pour les services du
bâtiment —
Partie 4:
Structures des dictionnaires de
données pour les catalogues de
produits
Data structures for electronic product catalogues for building
services —
Part 4: Data dictionary structures for product catalogues
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 .iv
Introduction .v
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 2
4 Modélisation des catégories de données requises . 3
4.1 Généralités .3
4.2 Modèle global .3
4.3 Catégories de sujets du modèle global . .5
4.3.1 Produit .5
4.3.2 Catalogue . .6
4.3.3 Bloc .6
4.3.4 Interfaces et entrées/sorties .7
4.4 Types de relations .9
4.4.1 isSubtypeOf .9
4.4.2 hasPart .10
4.4.3 hasBlock .11
4.4.4 isDependentOn .11
4.4.5 isSubkindOf .11
4.5 Catégories de propriétés et leur représentation dans le modèle global . 12
4.5.1 Généralités . 12
4.5.2 Ce que décrit une propriété . 12
4.5.3 Représentation des catégories de propriétés à l’aide du modèle global . 13
4.6 Relation avec les modèles de données . 15
5 Représentation du modèle global au moyen de l’ISO 12006-3 .16
5.1 Généralités .16
5.2 Relations de l’ISO 12006-3 .16
5.2.1 Vue d’ensemble .16
5.2.2 Relations entre propriétés .16
5.2.3 Relations entre sujets . . .16
5.3 Méta-niveau de dictionnaire pour définir des catégories de sujets et des types de
relations .17
5.4 Catégories de sujets au méta-niveau du dictionnaire . 20
5.5 Types de relations entre sujets au méta-niveau du dictionnaire.21
5.6 Relations entre propriétés . 22
6 Règles spécifiques et recommandations .22
6.1 Généralités . 22
6.2 Règles applicables à des situations particulières . 22
6.2.1 Propriétés de cardinalité pour les relations hasPart et hasBlock . 22
6.2.2 Références à la littérature. 23
6.2.3 Positionnement dans l’espace . 23
6.2.4 Fonctions de calcul prédéfinies pour les propriétés dynamiques .24
6.2.5 Relations avec les classifications ou d’autres dictionnaires .24
6.3 Recommandations pour le traitement des listes de valeurs contrôlées .24
6.3.1 Description du problème .24
6.3.2 Liste de valeurs de propriétés avec filtrage contextuel du sujet .24
Bibliographie .26
iii
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/patents. L’ISO ne saurait être tenue pour responsable de ne pas avoir identifié de tels
droits de propriété.
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).
Une liste de toutes les parties de la série ISO 16757 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.
iv
Introduction
La modélisation des informations de la construction (BIM) fournit un moyen pour décrire et afficher les
informations requises tout au long du cycle de vie des actifs. Cette approche de modélisation tend à s’étendre
de plus en plus pour englober tous les aspects de l’environnement bâti, y compris les infrastructures civiles,
les services publics et l’espace public.
La série ISO 16757 fournit la structure d’un modèle de catalogue de produits pour le partage de données et
l’échange de données de modèles de produits dans les catalogues de produits. Elle contient des spécifications
relatives:
— à la sélection de produits à partir de différentes classes de produits et variantes de produits;
— à la combinaison de composants et d’accessoires d’un produit pour former des produits;
— à la représentation géométrique dans les systèmes techniques;
— à la connectivité à d’autres produits dans les modèles de systèmes techniques;
— au calcul des valeurs des propriétés dynamiques en fonction du comportement du produit dans les
systèmes techniques.
Le présent document décrit les exigences relatives aux dictionnaires de données pour prendre en charge
à la fois les définitions sémantiques et la modélisation des données dans les catalogues de produits.
L’ISO 12006-3 définit le modèle de données sous-jacent pour les dictionnaires de données associés et sert de
base au présent document.
Des outils sont utilisés pour définir, simuler et exploiter les systèmes de services du bâtiment (y compris,
par exemple, les systèmes de CVC et les systèmes d’automatisation des bâtiments). Construire un système
de ce type implique essentiellement d’interconnecter différents produits, de sorte que le système ainsi
obtenu s’intègre dans le bâtiment et fonctionne conformément aux exigences fonctionnelles. Les produits
sont sélectionnés dans des catalogues de produits de fabricants ou de distributeurs. Les points de connexion
des produits et les informations sur leur comportement dans différentes situations constituent des aspects
importants de ces produits.
L’objectif du présent document est de venir à l’appui des outils d’ingénierie en leur permettant d’identifier
facilement les informations pertinentes dans différents dictionnaires de données. Dans le domaine des
services du bâtiment, quelques concepts génériques sont couramment utilisés:
— les propriétés dynamiques, qui décrivent le comportement des produits dans différentes situations et
différents cas de charge, et qui dépendent de propriétés externes décrivant les conditions extérieures;
— la distinction entre les entrées des dictionnaires de données, qui représentent des produits,
les métadonnées des catalogues et les caractéristiques spécifiques des produits, telles que les sous-
fonctions ou les interfaces.
Le présent document définit les types courants d’éléments des dictionnaires de données qui permettent
d’identifier les structures de base dans les dictionnaires de données.
En plus du présent document, la série ISO 16757 contient les documents suivants:
— l’ISO 16757-1 décrit les concepts fondamentaux et les hypothèses concernant la création de catalogues
de produits liés à un fabricant sous la forme de modèles d’échange de données BIM. Elle décrit le contenu
des catalogues de produits et la mise en correspondance du contenu avec un format de données.
Ce format de données offre la possibilité de rechercher et de sélectionner des données sur les produits,
avec des données sur les accessoires, qui peuvent être lues dans des applications logicielles pour la
planification, la conception, le calcul et la simulation, de même que pour la gestion des installations;
v
— l’ISO 16757-2 décrit le concept de géométrie des données des produits pour les services du bâtiment d’un
catalogue de produits, sous la forme de symboles en 2D et de modèles de formes en 3D, et spécifie les
espaces et les interfaces requis.
Elle comprend les concepts fondamentaux et les hypothèses concernant la géométrie paramétrique
des produits spéciaux, utilisés dans les applications logicielles de planification, notamment pour
les systèmes de climatisation, par exemple les conduits et les transitions entre différentes formes.
Elle fournit également un concept de représentation des produits sous forme de modèles solides en 3D,
qui sont fabriqués à partir de tôle fine;
— l’ISO 16757-5 spécifie l’organisation des catalogues de produits sur la base de l’ISO 16739-1 (classes de
fondation d’industrie, IFC) et de l’EN 17549-2. Ces catalogues de produits tirent la sémantique de leurs
propriétés des dictionnaires de données qui sont décrits dans le présent document.
Elle donne une vue d’ensemble de la représentation des éléments importants des catalogues de produits
et fournit des spécifications particulières sur l’utilisation des structures IFC dans les catalogues de
produits.
vi
Norme internationale ISO 16757-4:2025(fr)
Structures de données pour catalogues électroniques de
produits pour les services du bâtiment —
Partie 4:
Structures des dictionnaires de données pour les catalogues
de produits
1 Domaine d’application
Le présent document spécifie des exigences relatives aux dictionnaires de données qui sont utilisés par les
catalogues de produits pour les services du bâtiment afin de fournir la sémantique de leurs définitions et de
permettre la modélisation des données. À cet effet, il définit un modèle global qui contient:
— des catégories de sujets permettant de distinguer:
— les sujets de produits représentant des produits dans les catalogues de produits;
— les sujets de catalogues comprenant des métadonnées des catalogues de produits;
— différentes catégories de blocs qui rassemblent les propriétés des caractéristiques complexes des
produits, y compris des interfaces et des entrées/sorties;
— des types de relation qui permettent de distinguer différentes catégories de relations telles que
isSubtypeOf, hasPart ou hasBlock;
— des catégories de propriétés pour distinguer:
— les propriétés statiques décrivant des produits en fournissant des valeurs de propriétés dans les
catalogues de produits;
— les propriétés dynamiques qui décrivent le comportement des produits;
— les propriétés externes qui représentent les conditions externes qui ont un impact sur le comportement
du produit en ayant une influence sur les valeurs des propriétés dynamiques.
Le présent document décrit également une mise en correspondance du modèle global avec le modèle de
dictionnaire de données de l’ISO 12006-3 en introduisant un méta-niveau de dictionnaire.
Enfin, pour pallier les déficiences des normes sous-jacentes à l’ISO 16757-5 dans la capture de tous les aspects
des catalogues de produits, le présent document fournit plusieurs règles et recommandations relatives aux
éléments requis des dictionnaires de données.
Le présent document ne décrit ni la façon dont les catalogues de produits doivent être organisés, ni les
formats d’échange des catalogues de produits. Les catalogues de produits sont décrits dans l’ISO 16757-5.
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 12006-3, Construction immobilière — Organisation de l'information des travaux de construction — Partie
3: Schéma pour l'information basée sur l'objet
ISO 23386, Modélisation des informations de la construction et autres processus numériques utilisés en
construction — Méthodologie de description, de création et de gestion des propriétés dans les dictionnaires de
données interconnectés
ISO 23387:2025, Modélisation des informations de la construction (BIM) — Modèles de données pour les objets
de construction utilisés durant le cycle de vie des biens construits
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions 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
propriété
caractéristique définie adaptée à la description et à la différentiation des objets d’une classe
[SOURCE: ISO 22274:2013, 3.25, modifié — L’exemple a été supprimé.]
3.2
propriété de produit
propriété (3.1) qui décrit un produit dans un catalogue de produits
EXEMPLE Dans le cas d’un radiateur, des exemples de propriétés du produit sont la longueur, la largeur et la
profondeur.
3.3
propriété externe
propriété (3.1) qui décrit un aspect qui est extérieur à un produit, mais qui influe sur le comportement du produit
EXEMPLE Dans le cas d’un radiateur, des exemples de propriétés externes sont la température du fluide entrant
et la température ambiante.
Note 1 à l'article: Les propriétés externes ne décrivent pas le produit à proprement parler.
3.4
propriété statique
propriété de produit (3.2) qui n’est pas influencée par des conditions externes
EXEMPLE Dans le cas d’un radiateur, des exemples de propriétés statiques sont la longueur, la largeur et la
profondeur qui ne dépendent pas d’autres propriétés, ainsi que le volume qui dépend de la longueur, de la largeur et de
la profondeur.
3.5
propriété dynamique
propriété de produit (3.2) qui dépend d’au moins une propriété externe (3.3)
EXEMPLE Dans le cas d’un radiateur, un exemple de propriété dynamique est la température du fluide sortant qui
dépend, entre autres, de la température du fluide entrant et de la température ambiante.
3.6
entrée/sortie
point de raccordement/fixation/communication d’une unité technique avec son environnement pour le
transfert de substances, d’énergie ou de signaux
3.7
interface
point de raccordement/fixation/communication d’une unité technique, qui peut être connectée à un point
de raccordement/fixation/communication d’une autre unité technique pour le transfert de substances,
de signaux, d’énergie ou de forces
3.8
bloc
propriété composée
groupe de propriétés (3.1) correspondant à une caractéristique nécessitant plusieurs propriétés pour être définie
[SOURCE: ISO 23386:2020, 3.8, modifié — Le terme recommandé «bloc» a été ajouté; «catégorie» a été
supprimé du début de la définition; la Note 1 à l’article et l’exemple ont été supprimés.]
4 Modélisation des catégories de données requises
4.1 Généralités
Pour l’échange de données, il convient que le fournisseur et le destinataire aient la même compréhension
des données et que les données soient fournies sur une base commune. L’objectif est de créer cette base
commune dans un dictionnaire de données ouvert, en ligne. La présent article étudie les catégories de
données nécessaires à cette fin. Un dictionnaire de données conforme au présent document doit fournir les
structures nécessaires pour prendre en charge ces catégories de données.
Le présent document se concentre sur la description de produits dans un catalogue de produits. À certains
égards, il s’agit d’un point de vue différent de celui d’un bâtiment conçu, où les produits sont installés dans
des systèmes du bâtiment. Le fabricant ne sait pas où et de quelle manière les produits seront installés dans
un système spécifique. Néanmoins, pour décrire le comportement d’un produit, le fabricant doit fournir des
informations sur la manière dont le produit réagit face à différentes conditions extérieures, et sur la façon
dont les propriétés dynamiques sont influencées par des facteurs environnementaux et des facteurs propres
au système.
4.2 Modèle global
Le modèle global indique les catégories de données requises pour la description des produits des services
du bâtiment dans les catalogues de produits du fabricant (voir Figure 1). Il contient un certain nombre de
catégories de sujets, un certain nombre de types de relations, et il décrit un certain nombre de catégories de
propriétés. Dans un dictionnaire de données, les sujets doivent être liés à leur catégorie de sujet (voir 5.3).
Figure 1 — Modèle global
Le modèle global contient les catégories de sujets suivantes:
— produit: sujets représentant les produits dans un catalogue de produits;
— catalogue: sujets représentant les métadonnées des catalogues de produits;
— bloc: sujets représentant une caractéristique d’un objet qui est décrite par plusieurs propriétés;
— interface: spécialisation du bloc, représentant les points de connexion auxquels les interfaces d’autres
produits peuvent se connecter;
— entrée/sortie: spécialisation du bloc, représentant les interfaces d’un produit avec son environnement;
— externe: spécialisation du bloc, rassemblement des propriétés externes (voir 4.5.3.2).
Les types de relations suivants ont été définis dans le modèle global, et les catégories suivantes de
types de lignes et de formes de flèches ont été utilisées pour représenter les types de relations dans les
représentations graphiques:
relation isSubtypeOf, liant un sujet à un sujet plus général de la même catégorie;
relation hasPart, liant un sujet à ses parties;
relation hasBlock, liant un produit ou un catalogue à ses blocs;
hasProperty, liant à un sujet à ses propriétés;
isDependentOn, liant une propriété dépendante aux propriétés qui déterminent sa valeur;
isSubkindOf, liant les sous-catégories à leur catégorie de sujet plus générale.
Un dictionnaire de données conforme au présent document doit contenir des sujets de ces catégories de
sujets et des relations de ces types de relations. Dans les paragraphes suivants, les sujets seront appelés en
fonction de leur catégorie et les relations seront appelées en fonction de leur type.
EXEMPLE Un sujet de la catégorie bloc est appelé «sujet de bloc», un sujet de la catégorie produit est appelé «sujet
de produit», et une relation de type hasPart est appelée «relation hasPart».
NOTE La catégorie de sujet externe est décrite en 4.5.3.2.
4.3 Catégories de sujets du modèle global
4.3.1 Produit
Les propriétés sont utilisées pour décrire les produits. Le dictionnaire de données ne contient toutefois
pas de produits concrets. Les produits figurent dans des catalogues de produits (et des bases de données)
qui affectent les produits à des sujets de produits dans un dictionnaire de données. Un sujet de produit doit
définir les propriétés qui peuvent être utilisées pour décrire des produits. Ces propriétés sont liées à ce sujet
de produit au moyen de la relation hasProperty.
Un sujet de produit P peut être impliqué dans différents types de relations:
— isSubtypeOf: le liant à un autre sujet de produit qui donne une vue plus abstraite de P (voir 4.4.1);
— hasPart: le liant à d’autres sujets de produits qui représentent les parties ou composants de P (voir 4.4.2);
— hasBlock: le liant à des sujets de blocs qui représentent des caractéristiques complexes de P (voir 4.4.3).
Les sujets de produits peuvent être instanciés indépendamment, c’est-à-dire que dans un catalogue
de produits, un produit peut exister indépendamment de tout autre objet. Cela est différent des blocs
(voir 4.3.3): Les blocs ne doivent exister dans un catalogue de produits que dans le contexte d’un autre objet
(un produit, un bloc ou un catalogue).
EXEMPLE 1 Sur la Figure 2, deux sujets de produits, appelés «convecteur» et «radiateur», sont des spécialisations
d’un sujet de produit plus générique «appareil de chauffage». Ils sont liés à celui-ci par des relations isSubtypeOf.
Cela signifie qu’un convecteur et un radiateur ont également implicitement les propriétés de longueur et de hauteur
qu’ils héritent de l’appareil de chauffage. Cette situation est représentée à la Figure 2 par la répétition grisée des
propriétés héritées.
Figure 2 — Sujets de produits liés par des relations isSubtypeOf
EXEMPLE 2 Un système de chauffage central peut être défini comme un système constitué de plusieurs composants:
il peut par exemple comprendre un brûleur, une chaudière et une pompe. Dans un dictionnaire de données, un tel
système de chauffage central est représenté par un sujet de produit. De la même manière, le brûleur, la chaudière et la
pompe sont représentés par des sujets de produits. Ensuite, le sujet de produit «système de chauffage central» est lié à
ses composants au moyen de relations hasPart (voir Figure 3).
Figure 3 — Système «système de chauffage central» avec relations hasPart
4.3.2 Catalogue
Les propriétés sont également utilisées pour ajouter des métadonnées aux catalogues de produits.
Ces données sur les catalogues de produits comprennent, par exemple, le nom, la version et la date de
création d’un catalogue de produits, la durée de validité, le logiciel par lequel le catalogue de produits a été
généré. Il peut également contenir des données sur le fournisseur du catalogue de produits, le fabricant et,
dans certains cas, également sur le destinataire du catalogue de produits. Pour distinguer les métadonnées
du catalogue de produits des données de produits, une catégorie de sujet spécifique «catalogue» doit être
utilisée pour définir les propriétés spécifiant les métadonnées pour les catalogues de produits.
Un sujet de catalogue C peut être impliqué dans les types de relations suivants:
— isSubtypeOf: le liant à des sujets du catalogue qui fournissent une vue plus abstraite de C;
— hasPart: le liant à d’autres sujets du catalogue qui représentent les pièces ou composants de C (voir 4.4.2);
— hasBlock: le liant à des sujets de blocs qui représentent des caractéristiques complexes de C.
Comme pour les sujets de produits, les sujets de catalogues peuvent être instanciés de façon indépendante.
EXEMPLE 3 Les métadonnées d’un catalogue de produits peuvent consister en un nom, une date de création et le
nom et le numéro de téléphone du fournisseur du catalogue de produits. Cela peut être représenté dans un dictionnaire
de données par un sujet de catalogue avec les propriétés «nom» et «date de création» et un bloc contenant les données
du fournisseur du catalogue de produits (voir Figure 4).
Figure 4 — Exemple de sujet de catalogue avec relation hasBlock
4.3.3 Bloc
Les propriétés sont souvent rassemblées en groupes.
EXEMPLE 1 Souvent, des ensembles de propriétés sont combinés parce qu’ils décrivent différents aspects d’un
même sujet. Par exemple, la longueur, la largeur, la hauteur, etc. peuvent être regroupées sous le thème dimension.
Souvent, plusieurs propriétés décrivent une caractéristique d’un produit. Pour comprendre un dictionnaire
de données, il convient de représenter cette caractéristique par un sujet qui rassemble toutes les propriétés
de cette caractéristique.
EXEMPLE 2 Les connexions et les interfaces font partie intégrante d’un produit, mais chacune d’elles est décrite
par un certain nombre de propriétés.
EXEMPLE 3 Dans l’ISO 16739-1, les propriétés sont regroupées en ensembles de propriétés.
Pour prendre en charge un tel regroupement, la catégorie de sujet «bloc» est utilisée. Un sujet de bloc B peut
être impliqué dans différents types de relations:
— isSubtypeOf: le liant à un sujet de bloc qui fournit une vue plus abstraite de B (voir 4.4.1);
— hasPart: le liant à des sujets de blocs qui forment les parties ou composants de B (voir 4.4.2).
Contrairement aux sujets de produits et aux sujets de catalogues, un sujet de bloc ne doit être instancié
qu’en lien avec un sujet de produit ou de catalogue. Il doit toujours faire partie d’un sujet de produit ou de
catalogue, représenté par une relation hasBlock ou hasPart.
EXEMPLE 4 La Figure 5 prolonge la Figure 2: Le sujet de produit «appareil de chauffage» obtient un sujet de bloc
«performances», et ce sujet de bloc comprend les propriétés liées aux performances d’un appareil de chauffage.
Le sujet de bloc est lié au sujet de produit «appareil de chauffage» au moyen d’une relation hasBlock.
Figure 5 — Sujet de produit «appareil de chauffage» avec le sujet de bloc «performances»
qui rassemble les propriétés liées aux performances
Les règles suivantes s’appliquent aux blocs:
— tout sujet de bloc dans un dictionnaire de données fait partie d’un autre sujet de bloc, d’un sujet de
catalogue ou d’un sujet de produit, ce qui signifie que tout bloc doit être la cible d’une relation hasBlock
ou qu’il doit être la cible d’une relation hasPart;
— les sujets de blocs peuvent appartenir à plusieurs sujets de blocs ou de produits; cela implique qu’un sujet
de bloc peut être la cible de plusieurs relations hasBlock et hasPart;
— les sujets de blocs dans un dictionnaire de données peuvent être instanciés plusieurs fois dans un
catalogue de produits.
EXEMPLE 5 Un sujet de bloc «connecteur à broches» peut apparaître plusieurs fois dans une puce, décrivant chaque
broche avec un certain nombre de propriétés.
4.3.4 Interfaces et entrées/sorties
4.3.4.1 Vue d’ensemble
Deux caractéristiques sont importantes pour tout système d’ingénierie dans le domaine des systèmes de
services du bâtiment et sont utilisées dans pratiquement tous les produits de ce domaine:
— les interfaces désignent les points de raccordement/fixation/communication des produits de services
du bâtiment avec d’autres produits de services du bâtiment; toute connexion de produits au sein d’un
système est réalisée au moyen de la connexion des interfaces des deux produits;
— les entrées/sorties désignent les points de raccordement/fixation/communication des produits pour les
services du bâtiment qui permettent une interaction avec l’environnement.
Le présent document n’est pas destiné à décrire les interfaces et les entrées/sorties avec toute leur
sémantique, mais de définir deux catégories de blocs particulières qui leur sont associées, car ces
caractéristiques jouent un rôle très important pour les outils d’ingénierie.
4.3.4.2 Interfaces
Dans le modèle du système, les interfaces des produits peuvent être connectées aux interfaces d’autres
produits. Partant du produit ou allant vers le produit, elles sont utilisées pour le transfert:
— de substances (fluides);
— de solides (poussière, fibres, par exemple);
— de matières visqueuses (mousse extinctrice d’incendie, par exemple);
— de liquides (eau potable, par exemple);
— de substances gazeuses (gaz naturel, par exemple);
— d’énergie;
— électrique (au niveau de la prise de courant, par exemple);
— lié aux fluides (chaleur, air comprimé, enthalpie, par exemple);
— de forces;
— de fixation (pour le raccordement à des éléments de montage mural,
par exemple);
— de transmission de (pour la connexion avec un levier articulé, par exemple)
puissance
— de signaux;
— électrique (par un câble d’alarme, par exemple);
— acoustique (par un porte-voix, par exemple);
— optique (par fibre de verre, par exemple);
— lié aux fluides (par pic de pression, par exemple);
— de fonctionnement et de (par interrupteur ou panneau de commande, par exemple).
commande
Dans les catalogues de produits, seules les interfaces du produit qui peuvent être connectées aux interfaces
d’autres produits sont pertinentes. Les interfaces connectées en interne ne présentent pas d’intérêt.
Cela s’applique également aux interfaces qui ont été connectées par combinaison avec des composants ou
des accessoires.
Pour la planification de systèmes automatisés, il est important de spécifier, pour chaque interface de
produit, les interfaces correspondantes possibles. Cela évite les erreurs de connexion ou le déclenchement
d’avertissements. Pour les interfaces de produit qui n’ont pas de connexion à des interfaces correspondantes
dans le modèle de système, il doit être supposé que ces interfaces n’ont aucune fonction.
4.3.4.3 Entrées/sorties
Dans le modèle du système de services du bâtiment, certains produits ont des entrées/sorties vers les pièces
ou l’environnement du bâtiment.
Les entrées/sorties sont utilisées pour transférer des substances, de l’énergie ou des signaux.
Contrairement aux interfaces, qui doivent chacune être raccordées à des interfaces correspondantes,
ces entrées/sorties sont généralement laissées libres. Alors que les interfaces n’ont pas de propriétés
dynamiques calculables, les entrées/sorties ont une influence directe sur les propriétés techniques et
géométriques des fluides et des signaux en raison de leur forme et de leurs dimensions. La Figure 6 montre
un exemple de dispositif ayant plusieurs entrées/sorties différentes.
Figure 6 — Exemple d’entrées/sorties différentes sur un même produit
Les ouvertures sont utilisées pour le transfert:
— de substances (fluides);
— de solides (poussière, fibres, par exemple);
— de matières visqueuses (mousse extinctrice d’incendie, par exemple);
— de liquides (eau potable, par exemple);
— de substances gazeuses (air de ventilation, par exemple);
— d’énergie;
— lié aux fluides (air ou eau chauffé, par exemple);
— de rayonnement électromagnétique (chaleur, lumière UV, par exemple);
— de signaux;
— de fonctionnement et de commande (par interrupteur ou panneau de commande, par exemple).
— acoustique (sirène d’alarme, par exemple);
— optique (témoin d’avertissement, (par exemple).
4.4 Types de relations
4.4.1 isSubtypeOf
Les relations de type isSubtypeOf lient un sujet à un sujet plus générique de la même catégorie.
Les relations isSubtypeOf construisent des arborescences: un sujet peut être la racine d’une arborescence
(il ne s’agit pas d’un sous-type) ou un nœud dans l’arborescence (il s’agit d’un sous-type d’exactement un
autre sujet). La cardinalité de ce type de relation est donc n: (0.1).
Le type de relation isSubtypeOf implique l’héritage de propriétés: si un sujet S possède une propriété P, alors
ses sous-types possèdent également cette propriété P.
EXEMPLE Sur la Figure 2, deux sujets de produits, appelés «convecteur» et «radiateur», sont des sous-types d’un
sujet de produit plus générique «appareil de chauffage». Ils y sont liés par des relations «est sous-type de». Cela signifie
qu’un convecteur et un radiateur ont également implicitement les propriétés de longueur et de hauteur qu’ils héritent
de l’appareil de chauffage. Cette situation est représentée à la Figure 2 par la répétition grisée des propriétés héritées.
NOTE Une relation de type isSubtypeOf n’est normalement pas instanciée dans un catalogue de produits. Les
sujets sont normalement instanciés au niveau le plus bas de la hiérarchie isSubtypeOf, mais leur relation avec leurs
sujets plus généraux n’est pas instanciée. De ce fait, le type de relation isSubtypeOf est principalement pertinente au
niveau du dictionnaire de données lui-même.
4.4.2 hasPart
Les relations du type hasPart lient des sujets à leurs parties ou composants. Elles ne peuvent être utilisées
qu’entre sujets de la même catégorie.
La cardinalité est n:m. Un sujet peut comporter 0 partie, 1 partie ou plusieurs parties. Il peut faire partie de
0 sujet ou de nombreux autres sujets.
EXEMPLE 1 Un système de chauffage central peut être défini comme un système constitué de plusieurs composants:
il peut par exemple comprendre un brûleur, une chaudière et une pompe. Dans un dictionnaire de données, un tel
système de chauffage central est défini comme un sujet de produit. De la même manière, le brûleur, la chaudière et
la pompe sont des sujets de produits. Le sujet «système de chauffage central» est alors lié à ses composants par la
relation hasPart (voir Figure 3).
EXEMPLE 2 Un autre exemple de relation hasPart est représenté à la Figure 7: Le sujet de bloc «dimensions»
comporte deux parties, les «dimensions intérieures» et les «dimensions extérieures».
Figure 7 — Relation hasPart pour lier un bloc à ses parties
EXEMPLE 3 De nombreux fabricants proposent des produits sous forme de cascades. Une cascade est constituée
d’un certain nombre de produits du même type (par exemple un ensemble de brûleurs) qui sont ou peuvent être
raccordés de différentes manières selon des exigences spécifiques. Dans le dictionnaire de données, la cascade de
brûleurs est représentée par un sujet «cascade de brûleurs» dont le sujet «brûleur» fait partie [voir Figure 8 a)].
Dans un catalogue de produits, plusieurs brûleurs sont liés à l’instance de la «cascade de brûleurs» [voir Figure 8
b)], et la manière dont ces brûleurs sont raccordés peut être définie par les valeurs des propriétés respectives de la
«cascade de brûleurs».
a) Dans le dictionnaire de données b) Dans le catalogue de produits
Figure 8 — Cascades
NOTE Il est important de comprendre la différence entre la relation isSubtypeOf et la relation hasPart. Dans
une instance du dictionnaire de données, par exemple dans un catalogue de produits, la relation hasPart doit être
instanciée pour relier les instances de l’objet composite aux instances des composants (voir Figure 8). La relation
isSubtypeOf n’est jamais instanciée; normalement seules les feuilles de la hiérarchie isSubtypeOf sont instanciées.
4.4.3 hasBlock
La relation hasBlock lie un sujet de produit ou un sujet de catalogue à un sujet de bloc. Elle suit les
mêmes règles que la relation hasPart, la seule différence étant qu’elle lie d’autres catégories de sujets
(produit, catalogue) à des blocs. La cardinalité est n:m. Un bloc peut appartenir à plusieurs autres produits
ou catalogues, et un produit ou catalogue peut avoir plusieurs blocs.
EXEMPLE Un exemple de relation hasBlock est représenté à la Figure 5. Dans cet exemple, le sujet de produit
«appareil de chauffage» est relié par la relation hasBlock au sujet de bloc «performances».
4.4.4 isDependentOn
À la différence des autres types de relations, la relation isDependentOn est une relation entre propriétés.
Si une propriété P dépend d’une autre propriété D, alors la valeur de P dépend de la val
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...