ISO 16484-5:2007/Amd 1:2009
(Amendment)Building automation and control systems — Part 5: Data communication protocol — Amendment 1
Building automation and control systems — Part 5: Data communication protocol — Amendment 1
Systèmes d'automatisation et de gestion technique du bâtiment — Partie 5: Protocole de communication de données — Amendement 1
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 16484-5
Second edition
2007-03-15
AMENDMENT 1
2009-05-15
Building automation and control
systems —
Part 5:
Data communication protocol
AMENDMENT 1
Systèmes d'automatisation et de gestion technique du bâtiment —
Partie 5: Protocole de communication de données
AMENDEMENT 1
Reference number
ISO 16484-5:2007/Amd.1:2009(E)
©
ISO 2009
---------------------- Page: 1 ----------------------
ISO 16484-5:2007/Amd.1:2009(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
COPYRIGHT PROTECTED DOCUMENT
© ISO 2009
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 2009 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 16484-5:2007/Amd.1:2009(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
Amendment 1 to ISO 16484-5:2007 was prepared by Technical Committee ISO/TC 205, Building environment
design.
© ISO 2009 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 16484-5:2007/Amd.1:2009(E)
Introduction
The purpose of this Addendum is to add a number of independent substantive changes to the BACnet
standard. The changes are summarized below.
135-2004a-1, p. 1: Revise Life Safety Point and Life Safety Zone object types to modify their behaviour when
placed out of service.
135-2004c-1, p. 4: Add BACnet/WS Web Services Interface.
135-2004d-1, p. 39: Add a new Structured View object type.
135-2004d-2, p. 45: Allow acknowledgement of unseen TO-OFFNORMAL event notifications.
135-2004d-3, p. 46: Relax the Private Transfer and Text Message BIBB requirements.
135-2004d-4, p. 47: Exclude LIFE_SAFETY and BUFFER_READY notifications from the Alarm Notifications
BIBBs.
135-2004d-5, p. 49: Establish the minimum requirements for a BACnet device with an application layer.
135-2004d-6, p. 51: Remove the requirement for the DM-DOB-A BIBB from the B-OWS and B-BC device
profiles.
135-2004d-7, p. 52: Relax mandated values for APDU timeouts and retries when configurable, and change
default values.
135-2004d-8, p. 53: Fix EventCount handling error in MS/TP Master Node State Machine.
135-2004d-9, p. 54: Permit routers to use a local network number in Device_Address_Binding.
135-2004d-10, p. 55: Identify conditionally writable properties.
135-2004d-11, p. 56: Specify Error returns for the AcknowledgeAlarm service.
135-2004e-1, p. 58: Add a new Load Control object type.
135-2004f-1, p. 71: Add new Access Door object type.
In this Amendment, text being added to existing clauses of ISO 16484-5 is indicated through the use of italics,
while deletions are indicated by strikethrough. Plain type is used throughout where entirely new subclauses
are added.
© ISO 2009 – All rights reserved
iv
---------------------- Page: 4 ----------------------
ISO 16484-5:2007/Amd.1:2009(E)
Building automation and control systems —
Part 5:
Data communication protocol
AMENDMENT 1
135-2004a-1. Revise Life Safety Point and Life Safety Zone object types for out-of-service operation.
Addendum 135-2004a-1
[Change Table 12-18, p. 194]
Table 12-18. Properties of the Life Safety Point Object Type
Property Identifier Property Datatype Conformance Code
... ... ...
1
Present_Value BACnetLifeSafetyState R R
1
Tracking_Value BACnetLifeSafetyState OR
... ... ...
[Change 12.15.4, p. 195]
12.15.4 Present_Value
This property, of type BACnetLifeSafetyState, reflects the state of the Life Safety Point object. The means of
deriving the Present_Value shall be a local matter. Present_Value may latch non-NORMAL state values until reset.
The Present_Value property shall be writable when Out_Of_Service is TRUE.
[Change 12.15.5, p. 195]
12.15.5 Tracking_Value
This optional property, of type BACnetLifeSafetyState, reflects the non-latched state of the Life Safety Point object.
The means of deriving the state shall be a local matter. Unlike Present_Value, which may latch non-NORMAL state
values until reset, Tracking_Value shall continuously track changes in the state. The Tracking_Value property shall
be writable when Out_Of_Service is TRUE.
© ISO 2009 – All rights reserved 1
---------------------- Page: 5 ----------------------
ISO 16484-5:2007/Amd.1:2009(E)
[Change 12.15.11, p. 196]
12.15.11 Out_Of_Service
The Out_Of_Service property, of type BOOLEAN, is an indication whether (TRUE) or not (FALSE) the input(s) or
process the object represents is not in service. This means that changes to the Present_Value Tracking_Value
property are decoupled from the input(s) or process when the value of Out_Of_Service is TRUE. In addition, the
Reliability property and the corresponding state of the FAULT flag of the Status_Flags property shall be decoupled
when Out_Of_Service is TRUE. While the Out_Of_Service property is TRUE, the Present_Value Tracking_Value
and Reliability properties may be changed to any value as a means of simulating specific fixed conditions or for
testing purposes. Other functions that depend on the state of the Present_Value Tracking_Value or Reliability
properties shall respond to changes made to these properties while Out_Of_Service is TRUE, as if those changes had
occurred to the input(s) or process.
[Change Table 12-19, p. 200]
Table 12-19. Properties of the Life Safety Zone Object Type
Property Identifier Property Datatype Conformance Code
... ... ...
1
Present_Value BACnetLifeSafetyState R R
1
Tracking_Value BACnetLifeSafetyState O R
... ... ...
[Change 12.16.4, p. 201]
12.16.4 Present_Value
This property, of type BACnetLifeSafetyState, reflects the state of the Life Safety Zone object. The means of
deriving the Present_Value shall be a local matter. Present_Value may latch non-NORMAL state values until reset.
The Present_Value property shall be writable when Out_Of_Service is TRUE.
[Change 12.16.5, p. 201]
12.16.5 Tracking_Value
This optional property, of type BACnetLifeSafetyState, reflects the non-latched state of the Life Safety Zone object.
The means of deriving the state shall be a local matter. Unlike Present_Value, which may latch non-NORMAL state
values until reset, Tracking_Value shall continuously track changes in the state. The Tracking_Value property shall
be writable when Out_Of_Service is TRUE.
[Change 12.16.11, p. 202]
12.16.11 Out_Of_Service
The Out_Of_Service property, of type BOOLEAN, is an indication whether (TRUE) or not (FALSE) the input(s) or
process the object represents is not in service. This means that changes to the Present_Value Tracking_Value
property are decoupled from the input(s) or process when the value of Out_Of_Service is TRUE. In addition, the
Reliability property and the corresponding state of the FAULT flag of the Status_Flags property shall be decoupled
when Out_Of_Service is TRUE. While the Out_Of_Service property is TRUE, the Present_Value Tracking_Value
and Reliability properties may be changed to any value as a means of simulating specific fixed conditions or for
testing purposes. Other functions that depend on the state of the Present_Value Tracking_Value or Reliability
properties shall respond to changes made to these properties while Out_Of_Service is TRUE, as if those changes had
occurred to the input(s) or process.
© ISO 2009 – All rights reserved
2
---------------------- Page: 6 ----------------------
ISO 16484-5:2007/Amd.1:2009(E)
[Change Annex C, p.459]
LIFE-SAFETY-POINT :: = SEQUENCE {
…
present-value [85] BACnetLifeSafetyState,
tracking-value [164] BACnetLifeSafetyState OPTIONAL,
description [28] CharacterString OPTIONAL,
…
}
[Change Annex C, p.460]
LIFE-SAFETY-ZONE :: = SEQUENCE {
…
present-value [85] BACnetLifeSafetyState,
tracking-value [164] BACnetLifeSafetyState OPTIONAL,
description [28] CharacterString OPTIONAL,
…
}
© ISO 2009 – All rights reserved
3
---------------------- Page: 7 ----------------------
ISO 16484-5:2007/Amd.1:2009(E)
135-2004c-1. Adding BACnet/WS Web Services Interface
Rationale
"Web services" is emerging as the predominant technology for the integration of a wide variety of enterprise information. This
addendum defines a standard means of using Web services to integrate facility data from disparate data sources, including BACnet
networks, with a variety of business enterprise applications.
Addendum 135-2004c-1
[Add new Annex N]
ANNEX N - BACnet/WS WEB SERVICES INTERFACE (NORMATIVE)
(This annex is part of this standard and is required for its use.)
This annex defines a data model and Web service interface for integrating facility data from disparate data sources
with a variety of business management applications. The data model and access services are generic and can be used
to model and access data from any source, whether the server owns the data locally or is acting as a gateway to other
standard or proprietary protocols.
Implementations of the services described in this standard shall conform to the Web Services Interoperability
Organization (WS-I) Basic Profile 1.0, which specifies the use of Simple Object Access Protocol (SOAP) 1.1 over
Hypertext Transfer Protocol -- HTTP/1.1 (RFC2616) and encodes the data for transport using Extensible Markup
Language (XML) 1.0 (Second Edition), which uses the datatypes and the lexical and canonical representations
defined by the World Wide Web Consortium XML Schema.
Clients may determine the version of the BACnet/WS standard that a server implements by querying a specific
numerical value as defined in clause N.9. The numerical value for the version described in this document is 1.
There are three distinct usages of datatype names in this standard. Datatype names beginning with a lowercase letter,
such as "string", and "nonNegativeInteger", refer to datatypes defined by the XML Schema standard. Datatype
names beginning with an uppercase letter, such as "Real" or "Multistate" refer to the value types defined in Clause
N.8.9. Datatype names used in a "typical language binding signature" are arbitrary and are for illustrative purposes
only.
N.1 Data Model
The data structures and methods used to store information internally in a BACnet/WS server are a local matter.
However, in order to exchange that information using Web services, this standard establishes a minimal set of
requirements for the structuring and association of data exchanged with a BACnet/WS server.
A node is the fundamental primitive data element in the BACnet/WS data model. Nodes are arranged into a
hierarchy in the data model. The topmost node in the hierarchy is known as the root node. A root node has children,
but no parent. Every other node has a single parent and may optionally have children. The network visible state of a
node is exposed as a collection of attributes.
Any node may have a value. The possible types for a node's value are limited to the primitive datatypes "String",
"OctetString", "Real", "Integer", "Multistate", "Boolean", "Date", "Time", "DateTime", and "Duration". Nodes that
have a value may also have other attributes related to that value, such as minimum, writable, etc.
An attribute is a single aspect or quality of a node, such as its value or its writability. Every node exposes a
collection of attributes. Some attributes are required for all nodes, and some are conditionally required based on the
value of other attributes. Some of the attributes are localizable and may return different values based on an option in
a service request. Attributes are described more fully in Clause N.8.
Attributes may themselves have attributes that define a single aspect or quality of the original attribute. This standard
supports this recursion syntactically, but does not define or require that any of the standardized attributes have
attributes themselves at this time. Servers may provide proprietary attributes for any node or attribute at any level in
the hierarchy.
© ISO 2009 – All rights reserved
4
---------------------- Page: 8 ----------------------
ISO 16484-5:2007/Amd.1:2009(E)
A path is a character string that is used to identify a node or an attribute of a node. The hierarchy of nodes is
reflected in a path as a hierarchy of identifiers arranged as a delimited series, similar to the arrangement of identifiers
in a Uniform Resource Locator (URL) for the World Wide Web. A path like "/East Wing/AHU #5/Discharge Temp"
identifies a node, and a path like "/East Wing/AHU #5/Discharge Temp:InAlarm" identifies the InAlarm attribute of
that node. Paths are described more fully in Clause N.2.
To allow for an arbitrary number of logical arrangements of nodes, a single node may logically appear to be in more
than one place in the hierarchy through the use of a reference node. Reference nodes may be used to build alternate
logical arrangements of nodes since the children of a reference node may differ from that of its referent node.
Reference nodes are described more fully in Clause N.4.
The arrangement of data nodes into hierarchies and the naming of those nodes is generally a local matter. However,
this standard also defines a number of standardized nodes with standardized names and locations that allow clients to
obtain basic information about the server itself. These standardized nodes are described more fully in clause N.9.
N.2 Paths
A path is a character string that is used to identify a node or a specific attribute. The hierarchy of nodes is reflected in
a path as a hierarchy of node identifiers arranged as a delimited series separated by forward slash ("/") characters.
Similarly, the hierarchy of attributes is reflected in a path as a hierarchy of attribute identifiers arranged as a
delimited series separated by colon (":") characters.
Certain services accept an optional attribute path on the end of a node path. If an attribute path is not specified to
those services, the Value attribute is assumed. The attribute path is separated from the node path with a colon.
The concatenated path form is:
[/node-identifier[/node-identifier]…][:attribute-identifier[:attribute-identifier]…]
where square brackets indicate optionality and “…” indicates repetition of the previous element.
Examples: "/aaa" "/aaa/bbb" "/aaa/bbb/ccc:Description" "/aaa/bbb/ccc:Description:.foo"
All identifiers are case sensitive and shall be of non-zero length. Identifiers are not localizable and are not affected
by the "locale" or "canonical" service options. A path with no node identifier ("") refers to the root of the hierarchy,
and ":attribute-identifier" is the syntax for accessing the attributes of the root node.
Only printable characters may be used to construct path identifiers, and, as an additional restriction, all characters
equivalent to the ANSI X3.4 "control characters" (those less than X'20') are not allowed, and neither are any
characters equivalent to the following ANSI X3.4 characters: / \ : ; | < > * ? " [ ] { }
Node identifiers beginning with a period (".") character and attribute identifiers not beginning with a period (".")
character are reserved for use by ASHRAE. This restriction separates node and attribute identifiers that are defined
by this standard from those that are defined by the server, perhaps based on user input. Server defined node
identifiers shall not start with a period, so that "/aaa/.first-floor" is invalid but "/aaa/first-floor" is valid. Conversely,
all server defined attribute identifiers shall start with a period, so that "/aaa:MyNewAttribute" is invalid but
"/aaa:.MyNewAttribute" is valid. This asymmetry is based on the expected common usage where most node
identifiers will be server defined and most attributes are standard, making the use of periods the exception rather than
the norm.
Space characters are allowed and are significant in identifiers; however, it is recommended that identifiers should not
begin or end with space characters.
N.3 Normalized Points
Most building automation protocols, both standard and proprietary, have the concept of organizing data into "points"
that have "values." In addition to their values, points often contain data such as "point description" or "point is in
alarm." But these data may be named, structured, and/or accessed differently in different protocols.
© ISO 2009 – All rights reserved
5
---------------------- Page: 9 ----------------------
ISO 16484-5:2007/Amd.1:2009(E)
To ensure that a Web service client can retrieve data without knowing these naming and access-method details, this
standard defines "normalized points." This means that the common attributes of points available in the majority of
building data models are exposed using a common set of names.
In this data model, nodes with a NodeType (see N.8.5) of "Point" are required to have a value and have a common
collection of attributes that may be used to map to these data from other protocols. Some data may not be available
in some protocols, in which case either the normalized attribute is absent, or it has a reasonable default value.
N.4 Reference Nodes
A node that refers to another node somewhere else in the hierarchy is termed a "reference node." The node to which
it refers is its "referent node". A reference node reflects most of the attributes of its "referent node", including its
type, so that for most purposes, the reference node is indistinguishable from its referent node. The use of reference
nodes allows a node's data to appear in more than one place in the hierarchy.
Multiple hierarchies may be supported on a server. Automated discovery of those hierarchies may be done by
starting at the root, or any other starting point, and using the Children attribute to enumerate the available nodes in a
structured fashion. Two or more paths in different hierarchies may express different relationships for a single object.
To denote this, and so that apparent duplicates of an object can be discerned, a node can refer to another node
somewhere else in the hierarchy. It is arbitrary and a local matter which node is the referent node and which is the
reference node. Multiple reference nodes can point to the same referent node, or alternately can daisy chain, one to
one another, ultimately leading to a referent they all have in common which is not a reference node. There shall be at
least one referent node which is not a reference node, as it is forbidden to create a loop of references.
One network-visible distinction between a reference node and its referent node is in the presence of a Reference
attribute in the reference node. This attribute contains a path to the referent node. The Reference attribute is present
in a node if and only if that node is a reference node.
In most cases, the distinction of whether a node is a reference node or not is unnecessary. But in those cases where
the client needs to make a distinction, it can check for the presence of a Reference and act accordingly. A client can
also determine, for any given node, if there are reference nodes that refer to it. This may be done with the Aliases
attribute.
Except for the attributes Children, Aliases, Attributes, and Reference, any attribute read from the reference node will
have the same value as when read from the referent node. The reason for this is that, when references are used to
create different relationships between nodes, the nodes are not fundamentally changed by that association.
Therefore, only the attributes involved in expressing the relationships between nodes, namely Children, Aliases,
Attributes, and Reference, are expected to be different depending on which path was used to access the node. The
Attributes node only changes as needed to reflect the changing presence or absence of the Children, Aliases or
Reference attributes. Otherwise, the contents of the Attributes attribute is unchanged.
A reference node may point to another reference node, but it is not allowed to refer to itself, nor is it allowed to
create a loop of references.
For example, the paths "/Geographic/East Wing/Air Handler 5/Discharge Temp" and "/Cooling/Chiller Manager/Air
Handler 5/Terminal Box 345-A" express two different relationships for Air Handler 5. If the geographic relationship
was modeled first, then for the cooling distribution relationship, the node identified by "/Cooling/Chiller
Manager/Air Handler 5" would be a reference node with its Reference Attribute containing the path
"/Geographic/East Wing/Air Handler 5".
N.5 Localization
BACnet/WS supports the creation of products that are specifically designed for particular regions of the world. The
designation of a natural language, paired with a set of notational customs, such as date and number formats, is
referred to as a "locale". A BACnet/WS server may support multiple locales simultaneously, and several of the
attributes of a node are accessible for different locales (see clauses N.11.4, N.11.5, and N.11.6). For example, in a
server that supports multiple locales, the DisplayName attribute can be used to get a user interface presentation name
for the node in more than one language. Specifying a locale in a service also allows the client to request dates, times
and numbers in a format appropriate to that locale.
© ISO 2009 – All rights reserved
6
---------------------- Page: 10 ----------------------
ISO 16484-5:2007/Amd.1:2009(E)
N.6 Security
BACnet/WS does not define its own authentication mechanism; rather, this standard specifies the use of lower level
Web service authentication methods defined by other standards. Some servers might not support or require any
authentication at all. Others might provide authentication by means of a simple username and password using HTTP
Basic authentication (defined by section 2 of HTTP Authentication: Basic and Digest Access Authentication)
secured through an SSL (Secure Sockets Layer, defined by SSL Protocol Version 3.0) or TLS (Transport Layer
Security, defined by TLS Protocol Version 1.0) connection. Some servers may be secured through public key
certificates or more advanced options that are currently in development or yet to be defined.
For specification simplicity and increased interoperability, servers shall claim support for one or both of the
following authentication and authorization mechanisms: “None”; “HTTP Basic through SSL or TLS”.
In addition to authentication, some forms of authorization can also occur before the Web services defined by this
standard are invoked. For example, some Web services host environments (e.g., Application Servers) can be
configured to limit users’ access to certain services based on HTTP path or SOAP method.
The content and format of errors returned from these lower level authentication and authorization methods varies and
is not specified by this standard since the services defined by this standard were never invoked.
When a Web service request successfully passes through the lower levels, and the services defined by this standard
are invoked, additional authentication and authorization operations may be performed by those services and the
content and format of errors resulting from such operations are fully defined by this standard. The configuration of
authentication and authorization policies, at any level, is a local matter.
N.7 Sessions
The Web services defined by this standard are stateless and establish no sessions between clients and servers. There
is no requirement for any information to be retained on the server from one service invocation to the next. Service
options such as "locale" that could be held in a session on the server are instead maintained by the client in a service
options string that is provided to the server for each service invocation.
N.8 Attributes
A node is exposed to Web services as a collection of named attributes. There are two forms of attributes: those that
are a primitive datatype, and those that are an array of primitive datatypes. Only the Value attribute is writable with
the services defined by this standard.
While some attributes are specified as optional, the presence of those attributes on a given node is not expected to
change dynamically. Clients can assume that the collection of available attributes will remain relatively stable in
operation and normally will be changed only by a reconfiguration or reprogramming of the server and not in the
normal course of operation. For example, even though the default value for the InAlarm attribute is "false", the
InAlarm attribute is not expected to be absent when the node is not in alarm and present only when the node is in
alarm. Generally, if an attribute can have a value that is different from its default during the normal course of
operation, then the attribute should be present at all times.
The server may provide proprietary attributes for any node or attribute anywhere in the hierarchy of the data model.
Proprietary attributes shall begin with a period ('.') character to distinguish them from standard attributes. The
datatype and set of possible values for these attributes are not defined by this standard.
N.8.1 Primitive Attributes
The datatype of a primitive attribute in this standard is defined using its XML Schema datatype name, such as
"boolean", "nonNegativeInteger", and "double". See Clause N.10 for details of how these are encoded for use in
Web services.
The datatype of some attributes, such as Value and Minimum, is dependent on the value of the ValueType attribute.
This is more fully described in Clause N.8.9.
© ISO 2009 – All rights reserved
7
---------------------- Page: 11 ----------------------
ISO 16484-5:2007/Amd.1:2009(E)
N.8.2 Enumerated Attributes
Some primitive attributes are enumerations. Enumerated attributes are of datatype XML Schema "string", but the set
of allowed values is defined by this standard. Additionally, some enumerated attributes are localizable (see N.5). In
that case, the non-localized set of values is defined by this standard, but the localized strings are a local matter.
N.8.3 Array Attributes
Array attributes are attributes that contain an array of primitive values. Each element in the array has the same
primitive datatype. The contents of an array attribute may be accessed either as an array of separate elements or as a
single concatenation of all the elements.
The datatype of an array element in this standard is defined using its XML Schema datatype name, such as
"boolean", "nonNegativeInteger", and "double". See Clause N.10 for details of how these are encoded for use in
Web services.
When array attributes are accessed with a service that returns an array, such as getArray, the array elements are
returned as individual strings. However, when accessed with a service that returns a single string, such as getValue,
the array values are concatenated into a single string by separating the array elements with a ';' (semicolon) character,
for example, "high;medium;low". The values of the individual array elements are not permitted to contain
semicolons.
The server shall retain a constant order for the elements of an array attribute. Clients of services such as
...
NORME ISO
INTERNATIONALE 16484-5
Deuxième édition
2007-03-15
AMENDEMENT 1
2009-05-15
Systèmes d'automatisation et de gestion
technique du bâtiment —
Partie 5:
Protocole de communication de données
AMENDEMENT 1
Building automation and control systems —
Part 5: Data communication protocol
AMENDMENT 1
Numéro de référence
ISO 16484-5:2007/Amd.1:2009(F)
©
ISO 2009
---------------------- Page: 1 ----------------------
ISO 16484-5:2007/Amd.1:2009(F)
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier
peut être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence
autorisant l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées
acceptent de fait la responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute
responsabilité en la matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info
du fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir
l'exploitation de ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation,
veuillez en informer le Secrétariat central à l'adresse donnée ci-dessous.
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2009
Droits de reproduction réservés. Sauf prescription différente, 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 et les microfilms, sans l'accord écrit
de l'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
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
Publié en Suisse
ii © ISO 2009 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO 16484-5:2007/Amd.1:2009(F)
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 (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 2.
La tâche principale des comités techniques est d'élaborer les Normes internationales. Les projets de Normes
internationales adoptés par les comités techniques sont soumis aux comités membres pour vote. Leur
publication comme Normes internationales requiert l'approbation de 75 % au moins des comités membres
votants.
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.
L’amendement à l'ISO 16484-5 a été élaboré par le comité technique ISO/TC 205, Conception de
l'environnement intérieur des bâtiments.
© ISO 2009 – Tous droits réservés iii
---------------------- Page: 3 ----------------------
ISO 16484-5:2007/Amd.1:2009(F)
Introduction
L’objectif du présent Addendum consiste à apporter un certain nombre de modifications indépendantes
importantes à la norme BACnet. Les modifications sont récapitulées ci-après.
135-2004a-1, p.1 : Revoir les types d’objet Life Safety Point et Life Safety Zone pour modifier leur
comportement lorsqu’ils sont hors service.
135-2004c-1, p.4 . Ajout de l’interface des services Web BACnet/WS.
135-2004d-1, p.39 : Ajouter un nouveau type d’objet Structured View.
135-2004d-2, p.45 : Autoriser l’accusé de réception de notifications d’événements TO-OFFNORMAL non
prévues.
135-2004d-3, p.46 : Atténuer les exigences des BIBB Private Transfer et Text Message.
135-2004d-4, p.47 : Exclure les notifications LIFE_SAFETY et BUFFER_READY des BIBB de notifications
d’alarme.
135-2004d-5, p.49 : Établir les exigences minimales d’un dispositif BACnet avec une couche application.
135-2004d-6, p.51 : Supprimer l’exigence du BIBB DM-DOB-A des profils de dispositif B-OWS et B-BC.
135-2004d-7, p.52 : Atténuer les valeurs obligatoires des limitations de délai et nouvelles tentatives des APDU
lorsque cela est possible, et modifier les valeurs par défaut.
135-2004d-8, p.53 : Corriger l’erreur de traitement EventCount de la machine à états Nœud maître MS/TP.
135-2004d-9, p.54 : Permettre aux routeurs d’utiliser un numéro de réseau local dans
Device_Address_Binding.
135-2004d-10, p.55 : Identifier les propriétés inscriptibles sous condition.
135-2004d-11, p.56 : Spécifier des retours d’erreur pour le service AcknowledgeAlarm.
135-2004e-1, p.58 : Ajouter un nouveau type d’objet Load Control.
135-2004f-1, p.71 : Ajouter un nouveau type d’objet Access Door.
Dans le présent Amendement, le texte ajouté aux articles existants de l’ISO 16484-5 est indiqué en italique,
tandis que les suppressions sont indiquées par du texte barré. Du texte en clair est utilisé tout du long lorsque
de nouveaux articles entiers sont ajoutés.
iv © ISO 2009 – Tous droits réservés
---------------------- Page: 4 ----------------------
ISO 16484-5:2007/Amd.1:2009(F)
Systèmes d'automatisation et de gestion technique du
bâtiment —
Partie 5:
Protocole de communication de données
AMENDEMENT 1
135-2004a-1. Revoir les types d’objet Life Safety Point et Life Safety Zone pour le fonctionnement
hors-service.
Addendum 135-2004a-1
[Modifier le Tableau 12-18, p. 194]
Tableau 12-18. Propriétés du type d’objet Life Safety Point
Identifiant de propriété Type de données de propriété Code de
conformité
... ... ...
1
Present_Value BACnetLifeSafetyState R R
1
Tracking_Value BACnetLifeSafetyState OR
... ... ...
[Modifier le paragraphe 12.15.4, p. 195]
12.15.4 Present_Value
Cette propriété, de type BACnetLifeSafetyState, reflète l’état de l’objet Life Safety Point. La méthode
permettant de dériver Present_Value doit être d’ordre local. Present_Value peut verrouiller des valeurs
d’état non-NORMAL jusqu’à la réinitialisation. La propriété Present_Value doit être inscriptible lorsque
Out_Of_Service est TRUE.
[Modifier le paragraphe 12.15.5, p. 195]
12.15.5 Tracking_Value
Cette propriété optionnelle, de type BACnetLifeSafetyState, reflète l’état non verrouillé de l’objet Life
Safety Point. La méthode permettant de dériver l’état doit être d’ordre local. Contrairement à
Present_Value, qui peut verrouiller des valeurs à l’état non-NORMAL jusqu’à la réinitialisation,
Tracking_Value doit continuer à suivre les changements d'état. La propriété Tracking_Value doit être
inscriptible lorsque Out_Of_Service est TRUE.
© ISO 2009 – Tous droits réservés 1
---------------------- Page: 5 ----------------------
ISO 16484-5:2007/Amd.1:2009(F)
[Modifier le paragraphe 12.15.11, p. 196]
12.15.11 Out_Of_Service
La propriété Out_Of_Service, de type BOOLEAN, indique si oui (TRUE) ou non (FALSE) l’entrée ou le
processus que représente l’objet n’est pas en service. Cela signifie que les modifications apportées à la
propriété Present_Value Tracking_Value sont découplées de l’entrée ou du processus lorsque la valeur
de Out_Of_Service est TRUE. En outre, la propriété Reliability et l’état correspondant de l’indicateur
FAULT de la propriété Status_Flags doivent être découplés lorsque Out_Of_Service est TRUE. Alors que
la propriété Out_Of_Service est TRUE, les propriétés Present_Value Tracking_Value et Reliability
peuvent être modifiées en valeurs quelconques afin de simuler des conditions fixes spécifiques ou à des
fins d’essai. D’autres fonctions dépendant de l’état des propriétés Present_Value Tracking_Value ou
Reliability doivent répondre aux modifications apportées à ces propriétés alors que Out_Of_Service est
TRUE, comme si ces changements s’étaient produits au niveau de l’entrée ou du processus.
[Modifier le Tableau 12-19, p. 200]
Tableau 12-19. Propriétés du type d’objet Life Safety Zone
Identifiant de propriété Type de données de propriété Code de
conformité
... ... ...
1
R R
Present_Value BACnetLifeSafetyState
1
O R
Tracking_Value BACnetLifeSafetyState
... ... ...
[Modifier le paragraphe 12.16.4, p. 201]
12.16.4 Present_Value
Cette propriété, de type BACnetLifeSafetyState, reflète l’état de l’objet Life Safety Zone. La méthode
permettant de dériver Present_Value doit être d’ordre local. Present_Value peut verrouiller des valeurs
d’état non-NORMAL jusqu’à la réinitialisation. La propriété Present_Value doit être inscriptible lorsque
Out_Of_Service est TRUE.
[Modifier le paragraphe 12.16.5, p. 201]
12.16.5 Tracking_Value
Cette propriété optionnelle, de type BACnetLifeSafetyState, reflète l’état non verrouillé de l’objet Life
Safety Zone. La méthode permettant de dériver l’état doit être d’ordre local. Contrairement à
Present_Value, qui peut verrouiller des valeurs à l’état non-NORMAL jusqu’à la réinitialisation,
Tracking_Value doit continuer à suivre les changements d'état. La propriété Tracking_Value doit être
inscriptible lorsque Out_Of_Service est TRUE.
[Modifier le paragraphe 12.16.11, p. 202]
12.16.11 Out_Of_Service
La propriété Out_Of_Service, de type BOOLEAN, indique si oui (TRUE) ou non (FALSE) l’entrée ou le
processus que représente l’objet n’est pas en service. Cela signifie que les modifications apportées à la
propriété Present_Value Tracking_Value sont découplées de l’entrée ou du processus lorsque la valeur
de Out_Of_Service est TRUE. En outre, la propriété Reliability et l’état correspondant de l’indicateur
FAULT de la propriété Status_Flags doivent être découplés lorsque Out_Of_Service est TRUE. Alors que
la propriété Out_Of_Service est TRUE, les propriétés Present_Value Tracking_Value et Reliability
2 © ISO 2009 – Tous droits réservés
---------------------- Page: 6 ----------------------
ISO 16484-5:2007/Amd.1:2009(F)
peuvent être modifiées en valeurs quelconques afin de simuler des conditions fixes spécifiques ou à des
fins d’essai. D’autres fonctions dépendant de l’état des propriétés Present_Value Tracking_Value ou
Reliability doivent répondre aux modifications apportées à ces propriétés alors que Out_Of_Service est
TRUE, comme si ces changements s’étaient produits au niveau de l’entrée ou du processus.
[Modifier l’Annexe C, p. 459]
LIFE-SAFETY-POINT :: = SEQUENCE {
…
present-value [85] BACnetLifeSafetyState,
tracking-value [164] BACnetLifeSafetyState OPTIONAL,
description [28] CharacterString OPTIONAL,
…
}
[Modifier l’Annexe C, p. 460]
LIFE-SAFETY-ZONE :: = SEQUENCE {
…
present-value [85] BACnetLifeSafetyState,
tracking-value [164] BACnetLifeSafetyState OPTIONAL,
description [28] CharacterString OPTIONAL,
…
}
135-2004c-1. Ajout de l’interface des services Web BACnet/WS
Argumentaire
Les « services Web » apparaissent comme la technologie prédominante pour l’intégration d’une grande variété
d’informations d’entreprise. Le présent addendum définit un moyen normalisé permettant d’utiliser les services Web de
manière à intégrer des données d’installation issues de sources diverses, y compris les réseaux BACnet, à une multitude
d’applications d’entreprise.
Addendum 135-2004c-1
[Ajouter la nouvelle Annexe N]
ANNEXE N – INTERFACE DES SERVICES WEB BACnet/WS (NORMATIVE)
(La présente annexe fait partie de la présente Norme et est requise pour son utilisation.)
La présente annexe définit un modèle de données et une interface de service Web permettant d’intégrer
des données d’installation de sources différentes à une variété d’applications de gestion d’entreprise. Le
modèle de données et les services d’accès sont génériques et peuvent être utilisés pour modéliser et
accéder aux données de source quelconque, que le serveur détienne les données en local ou qu’il agisse
en tant que passerelle vers d’autres protocoles normalisés ou propriétaires.
Les implémentations des services décrits dans la présente norme doivent être conformes à Web Services
Interoperability Organization (WS-I) Basic Profile 1.0, qui spécifie l’utilisation du protocole SOAP 1.1
(Simple Object Access Protocol sur Hypertext Transfer Protocol -- HTTP/1.1 (RFC2616) et code les
© ISO 2009 – Tous droits réservés 3
---------------------- Page: 7 ----------------------
ISO 16484-5:2007/Amd.1:2009(F)
données de transport à l’aide de Extensible Markup Language (XML) 1.0 (Second Edition), qui utilise les
types de données et les représentations lexicales et canoniques définies par le World Wide Web
Consortium XML Schema.
Les clients peuvent déterminer la version de la norme BACnet/WS implémentée par un serveur en
demandant une valeur numérique spécifique définie au paragraphe N.9. La valeur numérique de la
version décrite dans le présent document est 1.
La présente norme utilise trois noms de type de données différents. Les noms de type de données
commençant par une lettre minuscule, tels que « string » et « nonNegativeInteger », désignent des types
de données définis par la norme XML Schema. Les noms commençant par une lettre majuscule, tels que
« Real » ou « Multistate » font référence aux types de valeur définis au paragraphe N.8.9. Les noms de
type de données utilisés dans une « signature type reliant au langage » (typical language binding
signature) sont arbitraires et n’ont qu’une vocation illustrative.
N.1 Modèle de données
Les structures et méthodes de données servant à stocker les informations dans un serveur BACnet/WS
sont d’ordre local. Toutefois, pour échanger ces informations à l’aide des services Web, la présente
norme établit un ensemble minimal d’exigences pour la structuration et l’association des données
échangées avec un serveur BACnet/WS.
Le nœud est l’élément de données primitif fondamental du modèle de données BACnet/WS. Les nœuds
sont organisés en hiérarchie dans le modèle de données. Le nœud situé en haut de la hiérarchie est le
nœud racine. Un nœud racine a des enfants, mais pas de parent. Tous les autres nœuds ont un seul
parent et peuvent, en option, avoir des enfants. L’état visible du réseau d’un nœud est représenté comme
un ensemble d’attributs.
Tout nœud peut comporter une valeur. Les types possibles pour une valeur de nœud se limitent aux
types de données primitifs « String », « OctetString », « Real », « Integer », « Multistate », « Boolean »,
« Date », « Time », « DateTime » et « Duration ». Les nœuds comportant une valeur peuvent également
avoir d’autres attributs liés à cette valeur, tels que minimum, writable, etc.
Un attribut représente un seul aspect ou une seule qualité d’un nœud, telle que sa valeur ou son
inscriptibilité. Chaque nœud expose un ensemble d’attributs. Certains d’entre eux sont obligatoires pour
tous les nœuds, et d’autres sont requis sous condition en fonction de la valeur d’autres attributs. Certains
attributs sont localisables et peuvent retourner différentes valeurs en fonction d’une option d’une requête
de service. Les attributs sont décrits plus en détail à l’Article N.8.
Les attributs peuvent eux-mêmes avoir des attributs qui définissent un seul aspect ou une seule qualité
de l’attribut original. La présente norme prend en charge cette récurrence syntaxique mais ne définit pas
ni n’exige que les attributs normalisés aient eux-mêmes des attributs à ce moment-là. Les serveurs
peuvent fournir des attributs propriétaires pour tout nœud ou attribut à n’importe quel niveau de la
hiérarchie.
Un chemin est une chaîne de caractères permettant d’identifier un nœud ou un attribut d’un nœud. La
hiérarchie des nœuds se retrouve dans un chemin sous la forme d’une hiérarchie d’identifiants organisés
comme une série délimitée, semblable à l’organisation des identifiants d’une URL (Uniform Resource
Locator) pour le World Wide Web. Un chemin tel que « /East Wing/AHU #5/Discharge Temp » identifie un
nœud, et un chemin tel que « /East Wing/AHU #5/Discharge Temp:InAlarm » identifie l’attribut InAlarm de
ce nœud. Les chemins sont décrits plus en détail à l’Article N.2.
Pour permettre un nombre arbitraire d’arrangements logiques de nœuds, un seul nœud peut logiquement
apparaître à plusieurs endroits de la hiérarchie grâce à l'utilisation d'un nœud de référence. Les nœuds
de référence peuvent être utilisés pour créer d’autres arrangements logiques de nœuds dans la mesure
où les enfants d’un nœud de référence peuvent être différents de ceux de son nœud référent. Les nœuds
de référence sont décrits plus en détail à l’Article N.4.
4 © ISO 2009 – Tous droits réservés
---------------------- Page: 8 ----------------------
ISO 16484-5:2007/Amd.1:2009(F)
L’arrangement des nœuds de données en hiérarchies et la dénomination de ces nœuds sont
généralement d’ordre local. Toutefois, la présente norme définit également un certain nombre de nœuds
normalisés avec des noms et des emplacements normalisés permettant aux clients d’obtenir des
informations de base sur le serveur lui-même. Les nœuds normalisés sont décrits plus en détail
l’Article N.9.
N.2 Chemins
Un chemin est une chaîne de caractères permettant d’identifier un nœud ou un attribut spécifique. La
hiérarchie des nœuds apparaît dans un chemin sous la forme d’une hiérarchie d’identifiants de nœuds
disposés en une série délimitée séparée par des barres obliques (« / »). De même, la hiérarchie des
attributs apparaît dans un chemin sous la forme d’une hiérarchie d’identifiants d’attributs disposés en une
série délimitée séparée par des deux-points (« : »).
Certains services acceptent un chemin d’attribut optionnel à la fin d’un chemin de nœuds. Si un chemin
d’attribut n’est pas spécifié pour ces services, l’attribut Value est supposé. Le chemin d’attribut est séparé
du chemin de nœud par une virgule.
La forme concaténée du chemin est la suivante :
[/node-identifier[/node-identifier]…][:attribute-identifier[:attribute-identifier]…]
où les crochets indiquent le caractère optionnel et “…” indiquent la répétition de l’élément précédent.
Exemples : "/aaa" "/aaa/bbb" "/aaa/bbb/ccc:Description" "/aaa/bbb/ccc:Description:.foo"
Tous les identifiants sont sensibles à la casse et doivent être de longueur non zéro. Les identifiants ne
sont pas localisables et ne sont pas concernés par les options de service « locale » ou « canonical ». Un
chemin sans identifiant de nœud ("") désigne la racine de la hiérarchie, et « :attribute-identifier » est la
syntaxe permettant d’accéder aux attributs du nœud racine.
Seuls des caractères imprimables peuvent être utilisés pour construire des identifiants de chemin et,
restriction supplémentaire, tous les caractères équivalents aux caractères de contrôle ANSI X3.4
(inférieurs à X'20') ne sont pas autorisés, ni les caractères équivalents aux caractères ANSI X3.4
suivants :
/ \ : ; | < > * ? " [ ] { }
Les identifiants de nœud commençant par un point (« . ») et les identifiants d’attribut ne commençant pas
par un point (« . ») sont réservés par l’ASHRAE. Cette restriction sépare les identifiants de nœud et
d'attribut qui sont définis par la présente norme de ceux définis par le serveur, sans doute en fonction de
l'entrée de l'utilisateur. Les identifiants de nœud définis par le serveur ne doivent pas commencer par un
point, si bien que « /aaa/.first-floor » est incorrect tandis que « /aaa/first-floor » est correct. Inversement,
tous les identifiants définis par un serveur doivent commencer par un point, si bien que
« /aaa:MyNewAttribute » est incorrect alors que « /aaa:.MyNewAttribute » est correct. Cette asymétrie se
base sur l’usage courant escompté où la plupart des identifiants de nœuds sont définis par le serveur et la
plupart des attributs sont normalisés, l’utilisation des points faisant plutôt exception.
Les espaces sont autorisés et sont chargés de sens dans les identifiants ; il convient cependant que les
identifiants ne commencent pas ni ne se terminent par des espaces.
N.3 Points normalisés
La plupart des protocoles d’automatisation du bâtiment, normalisés et propriétaires, organisent les
données en « points » qui ont des « valeurs ». Outre leurs valeurs, les points contiennent souvent des
données telles que la « description de point » ou « le point est en alarme ». Mais ces données peuvent
être nommées, structurées et/ou accessibles de différentes manières dans divers protocoles.
Pour garantir qu’un client de service Web peut extraire des données sans connaître ces détails de
dénomination et de méthode d’accès, la présente norme définit des « points normalisés ». Cela signifie
© ISO 2009 – Tous droits réservés 5
---------------------- Page: 9 ----------------------
ISO 16484-5:2007/Amd.1:2009(F)
que les attributs courants des points disponibles dans la majorité des modèles de données du bâtiment
sont exposés à l’aide d’un ensemble de noms commun.
Dans ce modèle de données, les nœuds avec un NodeType (voir N.8.5) « Point » doivent avoir une
valeur et un ensemble commun d’attributs pouvant servir au mappage avec ces données issues d’autres
protocoles. Certaines données peuvent ne pas être disponibles dans certains protocoles, auquel cas
l’attribut normalisé est absent ou n’a pas de valeur par défaut raisonnable.
N.4 Nœuds de référence
Un nœud désignant un autre nœud de la hiérarchie est appelé « nœud de référence ». Le nœud auquel il
faire référence est son « nœud référent ». Un nœud de référence fait apparaître la plupart des attributs de
son « nœud référent », y compris son type, si bien que la plupart du temps, le nœud de référence est
indissociable de son nœud référent. L’utilisation des nœuds de référence permet aux données d’un nœud
d’apparaître à plusieurs emplacements d'une hiérarchie.
Plusieurs hiérarchies peuvent être prises en charge sur un serveur. La découverte automatisée de ces
hiérarchies peut s’opérer en commençant à la racine, ou à tout autre point de départ, et en utilisant
l’attribut Children pour énumérer les nœuds disponibles de manière structurée. La présence de deux ou
plusieurs chemins dans différentes hiérarchies peut signifier des relations différentes pour un seul objet.
Pour représenter cela et faire en sorte que les doubles apparents d’un objet puissent être distingués, un
nœud peut désigner un autre nœud de la hiérarchie. La question de savoir quel nœud est le nœud
référent et quel nœud est le nœud de référence est arbitraire et d’ordre local. Plusieurs nœuds de
référence peuvent désigner le même nœud référent, ou se connecter en guirlande pour aboutir à un
référent qu’ils ont tous en commun qui n’est pas un nœud de référence. Il doit y avoir au moins un nœud
référent qui n’est pas un nœud de référence, dans la mesure où il est interdit de créer une boucle de
références.
Une distinction visible du réseau entre un nœud de référence et son nœud référent se fait dans la
présence d’un attribut Reference dans le nœud de référence. Cet attribut contient un chemin vers le
nœud référent. L’attribut Reference est présent dans un nœud si et seulement si ce nœud est un nœud
de référence.
Dans la plupart des cas, la distinction entre un nœud et un nœud de référence n’est pas nécessaire.
Lorsque le client a besoin de faire la distinction, il peut vérifier la présence d’un attribut Reference et agir
en conséquence. Un client peut également déterminer, pour un nœud donné, si des nœuds de référence
le désignent. Cela peut se faire avec l’attribut Aliases.
À l’exception des attributs Children, Aliases, Attributes et Reference, tout attribut lu à partir du nœud de
référence aura la même valeur que s’il est lu à partir du nœud référent. Cela s’explique par le fait que
lorsque des références sont utilisées pour créer différentes relations entre des nœuds, ceux-ci ne sont
pas fondamentalement modifiés par cette association. Par conséquent, seuls les attributs participant à
l’expression des relations entre nœuds, à savoir Children, Aliases, Attributes et Reference, sont censés
être différents selon le chemin emprunté pour accéder au nœud. Le nœud Attributes ne change que pour
refléter la présence ou l’absence des attributs Children, Aliases ou Reference. Sinon, le contenu de
l'attribut Attributes est inchangé.
Un nœud de référence peut désigner un autre nœud de référence, sans pour autant être autorisé à se
désigner lui-même, ni à créer une boucle de références.
Par exemple, les chemins « /Geographic/East Wing/Air Handler 5/Discharge Temp » et « /Cooling/Chiller
Manager/Air Handler 5/Terminal Box 345-A » expriment deux relations différentes pour Air Handler 5. Si
la relation géographique a été modelée en premier, pour la relation de la distribution de refroidissement,
le nœud identifié par « /Cooling/Chiller Manager/Air Handler 5 » serait un nœud de référence avec
l’attribut Reference contenant le chemin « /Geographic/East Wing/Air Handler 5 ».
6 © ISO 2009 – Tous droits réservés
---------------------- Page: 10 ----------------------
ISO 16484-5:2007/Amd.1:2009(F)
N.5 Localisation
BACnet/WS prend en charge la création de produits spécifiquement conçus pour des régions particulières
du monde. La désignation d’une langue naturelle, associée à un ensemble de pratiques de notation, tels
que les formats de date et de nombre, est appelée « paramètre régional ». Un serveur BACnet/WS peut
prendre en charge plusieurs paramètres régionaux en même temps, et plusieurs attributs d’un nœud sont
accessibles pour différents paramètres régionaux (voir paragraphes N.11.4, N.11.5 et N.11.6). Par
exemple, dans un serveur prenant en charge plusieurs paramètres régionaux, l’attribut DisplayName peut
être utilisé pour obtenir le nom de présentation d’interface utilisateur du nœud dans plusieurs langues. La
spécification d’un paramètre régional dans un service permet également au client de demander des
dates, heures et nombres dans un format compatible avec ce paramètre.
N.6 Sécurité
BACnet/WS ne définit pas son propre mécanisme d’authentification ; la présente norme spécifie à la place
l’utilisation de méthodes d’authentification de services Web de niveau inférieur définies par d’autres
normes. Certains serveurs peuvent ne pas prendre en charge ni requérir l'authentification. D’autres
peuvent assurer l’authentification au moyen d’un nom d’utilisateur et d’un mot de passe simples en
utilisant l’authentification HTTP Basic (définie par la section 2 de HTTP Authentication : Basic and Digest
Access Authentication) sécurisée via une connexion SSL (Secure Sockets Layer, défini par SSL Protocol
Version 3.0) ou TLS (Transport Layer Security, défini par TLS Protocol Version 1.0). Certains serveurs
peuvent être sécurisés via des certificats de clé publique ou des options plus avancées actuellement en
cours de développement ou à définir.
Pour une spécification simple et une meilleure interopérabilité, les serveurs doivent revendiquer la prise
en charge d’un ou des deux mécanismes d’authentification et d’autorisation suivants : « None » ; « HTTP
Basic through SSL or TLS ».
Outre l’authentification, certaines formes d’autorisation peuvent également intervenir avant que les
services Web définis par la présente norme soient invoqués. Par exemple, certains environnements
d’hébergement de services Web(par exemple, les serveurs d’application) peuvent être configurés pour
limiter l’accès des utilisateurs à certains services en fonction du chemin HTTP ou de la méthode SOAP.
Le contenu et le format des erreurs retournées de la part de ces méthodes d’authentification et
d’autorisation de niveau inférieur varient et ne sont pas spécifiés par la présente norme dans la mesure
où les services qui y sont définis n’ont jamais été invoqués.
Lorsqu’une demande de service Web passe avec succès à travers les niveaux inférieurs, et que les
services définis par la présente norme sont invoqués, d’autres opérations d’authentification et
d’autorisation peuvent être réalisées par ces services et le contenu et le format résultant de ces
opérations sont définis de manière exhaustive par la présente norme. La configuration des règles
d’authentification et d’autorisation, à tout niveau, est d’ordre local.
N.7 Sessions
Les services Web définis par la présente norme sont sans état et n’établissent pas de session entre les
clients et les serveurs. Il n’est pas nécessaire que des informations soient conservées sur le serveur
d’une invocation de service à l’autre. Les options de service telles que « locale » pouvant être conservées
dans une session sur le serveur sont détenues par le client dans une chaîne d’options de service fournie
au serveur pour chaque invocation.
N.8 Attributs
Un nœud est exposé aux services Web comme un ensemble d’attributs nommés. Il existe deux formes
d’attributs : ceux dont le type de donné
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.