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
Frequently Asked Questions
ISO 16484-5:2007/Amd 1:2009 is a standard published by the International Organization for Standardization (ISO). Its full title is "Building automation and control systems - Part 5: Data communication protocol - Amendment 1". This standard covers: Building automation and control systems - Part 5: Data communication protocol - Amendment 1
Building automation and control systems - Part 5: Data communication protocol - Amendment 1
ISO 16484-5:2007/Amd 1:2009 is classified under the following ICS (International Classification for Standards) categories: 35.240.99 - IT applications in other fields; 91.040.01 - Buildings in general. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 16484-5:2007/Amd 1:2009 has the following relationships with other standards: It is inter standard links to ISO/IEC 16500-2:1999, ISO 16484-5:2007, ISO 16484-5:2010; is excused to ISO 16484-5:2007. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 16484-5:2007/Amd 1:2009 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
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
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.
© 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
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 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.
iv
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
... ... ...
Present_Value BACnetLifeSafetyState R R
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 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
... ... ...
Present_Value BACnetLifeSafetyState R R
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 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 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 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 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 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 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
getArrayRange can therefore depend on this behavior to read the array an element at a time.
N.8.4 Attribute Summary
Some attributes are always required, and some are conditionally required, based on criteria outlined in the following
table. The datatype referred to in the table is an XML Schema datatype name. See Clause N.10 for more information
on encoding for Web services. Attributes that are not listed as Localizable are never affected by the "locale" service
option (see clause N.11.4) and are always encoded in their non-localized canonical form (see clause N.11.6).
ISO 16484-5:2007/Amd.1:2009(E)
Table N-1. Attribute Summary
Attribute Identifier Datatype Array Enum- Local- Presence
erated izable
"NodeType" string No Yes No Required
"NodeSubtype" string No No Yes Optional
"DisplayName" string No No Yes Optional
"Description" string No No Yes Optional
"ValueType" string No Yes No Required
"Value" (varies - see N.8.9) No No Yes Required if ValueType is not "None"
"Units" string No Yes Yes Required if ValueType is "Real" or
"Integer"
"Writable" boolean No No No Required if ValueType is not "None"
"InAlarm" boolean No No No Optional
"Minimum" (varies - see N.8.9) No No Yes Optional
"Maximum" (varies - see N.8.9) No No Yes Optional
"Resolution" (varies - see N.8.9) No No Yes Optional
"MinimumLength" nonNegativeInteger No No No Optional and only present if ValueType is
"String"
"MaximumLength" nonNegativeInteger No No No Optional and only present if ValueType is
"String"
"IsMultiLine" boolean No No No Optional
"Attributes" string Yes No No Required
"WritableValues" string Yes No Yes Required if ValueType is "Multistate" or
"Boolean" and Writable is true
"PossibleValues" string Yes No Yes Required if ValueType is "Multistate" or
"Boolean"
"Overridden" boolean No No No Optional
"ValueAge" double (seconds) No No Yes Optional
"Aliases" string Yes No No Required if there are reference nodes
referring to this node (see Clause N.4)
"Children" string Yes No No Optional
"Reference" string No No No Present if and only if the node is a
reference node (see Clause N.4)
"HasHistory" boolean No No No Required if ValueType is not "None"
"SinglyWritableLocales" string Yes No No Present if and only if ValueType is
"String" and Writable is true
"HasDynamicChildren" boolean No No No Optional
N.8.5 NodeType
This required attribute indicates the general classification of a node. It is intended as a hint to a client application
about the contents of a node, and is not intended to convey an exact definition. The list of values for this attribute is
not extensible. Further refinement of classification is provided by the NodeSubtype attribute. The allowable values
for this attribute are:
{"Unknown", "System", "Network", "Device", "Functional", "Organizational", "Area",
"Equipment", "Point", "Collection", "Property", "Other"}
The "Unknown" type may be used for data that originated in another source and for which no type information is
known. The "System" type may be used to designate an entire mechanical system. The "Network" type may be used
to represent a communications network, and the "Device" type could be used to represent a physical device on that
network. The "Functional" type can be used to represent a single system component such as a control module or a
logical component such as a function block. The "Organizational" type is intended to represent business concepts
such as departments or people. The "Area" type represents a geographical concept such as a campus, building, floor,
etc. A "Point" represents a single point of data, either a physical input or output of a control or monitoring device, or
a software calculation or configuration setting. An "Equipment" type may be used to represent a single piece of
equipment that may be a collection of "Points". A "Collection" is just a generic container used to group things
together such as a collection of references to all space temperatures in a building. The "Property" type is intended to
ISO 16484-5:2007/Amd.1:2009(E)
model data that is logically part of the parent node. The "Other" type is used for everything that does not fit into one
of these broad categories.
N.8.6 NodeSubtype
This optional attribute is a string of printable characters whose content is not restricted. It provides a more specific
classification of the node. For example, when the NodeType attribute has a value of "Area", the NodeSubtype
attribute could have a value such as "Campus", "Building", or "Floor". This attribute may be localized, possibly
returning different locale-appropriate values when a "locale" service option is specified.
N.8.7 DisplayName
This required attribute is a string of printable characters whose content is not restricted. It is used to provide a short
(10-30 character) descriptive name or title for display to humans in user interfaces. It should be localized if
localization is supported, returning possibly different locale-appropriate values when a "locale" service option is
specified. A client may retrieve this attribute in any locale the server supports for use in creating multilingual
displays. The values of the DisplayName attributes do not need to be unique among sibling nodes.
A DisplayName attribute may be different from the path identifier used to access the node. For example, for the node
identified by the path "/Building 12/Room 225", the DisplayName could be "Bob's Office" in one locale and "Bureau
de Bob" in another locale, or it could just be "Room 225" in all locales.
N.8.8 Description
This optional attribute is a string of printable characters whose content is not restricted. This attribute may be
localized, possibly returning different locale-appropriate values when a "locale" service option is specified.
N.8.9 ValueType
This required attribute indicates the datatype of the Value attribute and attributes restricting the Value attribute. If the
node has no value, then this attribute shall have the value "None". The list of values for this attribute is not
extensible. The allowable values for this attribute are:
{"None", "String", "OctetString", "Real", "Integer", "Multistate", "Boolean", "Date", "Time", "DateTime",
"Duration"}
The "None" type is used when the node does not have a value. The "String" type is used for nodes that have
character string values that are intended to be human readable. An "OctetString" is used to contain arbitrary binary
data that is typically not human readable. A "Real" is a floating point value, for example 75.6. An "Integer" is for
values that that are expressed in whole numbers, for example, 1234. A "Multistate" is a value that is a choice from a
set of named states, for example, {"high", "medium", "low"}. A "Boolean" is a choice between exactly two named
states, such as "on" and "off", one of which is considered true and the other false. A "Date" is used to represent
values that are calendar dates. A "Time" is used to represent a time of day. A "DateTime" is used to represent an
exact moment in time, specifying both a date and a time. A "Duration" represents a time span, such as "5 seconds."
The representation of all value types other than "None" and "OctetString" may be affected by the "locale" service
option if the server supports localization for a particular locale or locales. See clauses N.5 and N.11.4.
The effect of this attribute on the datatype of Value and related attributes is summarized in the following table. The
datatypes referred to in the table are XML Schema datatype names. See Clause N.10 for more information on
encoding of Web services. Attributes whose datatype is listed as n/a in the table shall not be present in the node.
ISO 16484-5:2007/Amd.1:2009(E)
Table N-2. Effect of ValueType Attribute
ValueType Value Attribute Minimum Maximum Resolution Attribute
Attribute Value Datatype Attribute Attribute Datatype
Datatype Datatype
"None" n/a n/a n/a n/a
"String" string n/a n/a n/a
"OctetString" base64Binary n/a n/a n/a
"Real" double double double double
"Integer" integer integer integer integer
"Multistate" string n/a n/a n/a
"Boolean" boolean n/a n/a n/a
"Date" date date date integer (days)
"Time" time time time double (seconds)
"DateTime" dateTime dateTime dateTime double (seconds)
"Duration" double (seconds) double (seconds) double (seconds) double (seconds)
N.8.10 Value
This optional attribute represents the value of the node. The datatype of this attribute is indicated by the ValueType
attribute. The Value attribute is present if and only if the value of the ValueType attribute is not "None". When the
ValueType attribute of the node is "String" or "Multistate", then the values of this attribute may be localized based
on the "locale" service option. See Clause N.11.4.
N.8.11 Units
This optional attribute defines the engineering units for the Value attribute of the node. If the ValueType attribute is
"Real" or "Integer", then this attribute is required to be present, but may have the value of "no-units". This attribute
may optionally be present for other values of the ValueType attribute.
This attribute's value is available in two forms. If the "canonical" service option is false, then the value of this
attribute is a string whose contents are not restricted and may be appropriate to the requested locale. If the
"canonical" service option is true, then the value of this attribute is restricted to be exactly equal to one of the
enumeration identifiers, such as "degrees-Celsius", "inches-of-water", etc., which are defined by the ASN.1
production for BACnetEngineeringUnits in Clause 21.
This attribute is extensible to support units other than those defined by this standard. In the case where the units of
the node's value does not match one of the units defined in this standard, the value returned for this attribute when
the "canonical" service option is true shall be "other", and the value returned when the "canonical" service option is
false shall be a string whose contents are not restricted and may be appropriate to the requested locale.
N.8.12 Writable
This optional attribute indicates whether the Value attribute is writable through Web services. This attribute shall be
present if and only if the Value attribute is present.
N.8.13 InAlarm
This optional attribute indicates whether this node is "in alarm" or not. The meaning of "in alarm" is a local matter. If
the concept of "in alarm" is not appropriate to this node, then this attribute shall not be present.
N.8.14 Minimum
This optional attribute indicates the minimum value of the Value attribute. The datatype of this attribute is defined in
Clause N.8.9.
N.8.15 Maximum
This optional attribute indicates the maximum value of the Value attribute. The datatype of this attribute is defined in
Clause N.8.9.
N.8.16 Resolution
This optional attribute indicates the smallest change that can be represented in the value of the Value attribute. The
datatype of this attribute is defined in Clause N.8.9.
ISO 16484-5:2007/Amd.1:2009(E)
N.8.17 MinimumLength
This optional attribute indicates the minimum length, in characters, for the value of the Value attribute when the
ValueType attribute is equal to "String".
N.8.18 MaximumLength
This optional attribute indicates the maximum length, in characters, for the value of the Value attribute when the
ValueType attribute is equal to "String".
N.8.19 IsMultiLine
This optional attribute indicates that the value of the Value attribute, when the ValueType attribute is equal to
"String", is intended to be capable of containing multiple lines of text. The value might not actually contain multiple
lines at any given time, and it is not intended that IsMultiLine change dynamically based on the contents of the
value. This attribute is primarily used as a hint to a user interface to display or edit the text in a manner capable of
supporting multiple lines.
If the value contains multiple lines, the lines are separated by the character equivalent to the ANSI X3.4 control
character known as "new line" or "line feed" (X'0A'). In all cases, the Value attribute is returned as a single string
since the Value attribute is not an array attribute.
If IsMultiLine is missing or false, the presence of, acceptance of, or rejection of "new line" characters is a local
matter.
N.8.20 Attributes
This required attribute is an array containing all of the names of the attributes present in this node.
N.8.21 WritableValues
This optional attribute is an array containing all of the string values that may be written to the Value attribute of a
node whose ValueType is equal to "Multistate" or "Boolean".
N.8.22 PossibleValues
This optional attribute is an array containing all of the possible string values for the Value attribute of a node whose
ValueType is equal to "Multistate" or "Boolean". For nodes that have a ValueType attribute equal to "Boolean", the
first entry in the array corresponds to "true", and the second entry corresponds to "false".
N.8.23 Overridden
This optional attribute indicates that the value of the Value attribute has been overridden by some means. For
physical inputs or outputs, this shall mean that the Value attribute is no longer tracking changes to the physical input
or that the physical output is no longer reflecting changes made to the Value attribute.
N.8.24 ValueAge
This optional attribute indicates the time, in seconds, since the time when the value of the Value attribute was last
successfully updated in the server. Caching is permitted in gateways; this attribute shall indicate the age of the
cached value.
N.8.25 Aliases
This optional attribute contains the collection of paths that identify reference nodes that refer to this node.
N.8.26 Children
This optional attribute is an array that contains the collection of identifiers for the children of this node on a given
path. Each of these identifiers can be used to construct a new path to a child node according to the rules set forth in
clause N.2. Note that the child identifiers specified by this attribute do not start with a '/' character, so when
constructing a new path to a child node, the '/' separator will need to be used between the original path and the child
identifier.
Absence of this attribute shall indicate that the node has no children. Therefore, if the node has children, this
attribute is required to be present. If the node has no children, this attribute shall either be absent o
...
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
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
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 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
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é
... ... ...
Present_Value BACnetLifeSafetyState R R
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 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é
... ... ...
R R
Present_Value BACnetLifeSafetyState
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
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 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
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 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
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ées est primitif, et ceux formant un tableau de types de données
primitifs. Seul l’attribut Value est inscriptible avec les services définis par la présente norme.
ISO 16484-5:2007/Amd.1:2009(F)
Alors que certains attributs sont spécifiés comme optionnels, la présence de ces attributs sur un nœud
donné n’est pas censée changer de manière dynamique. Les clients peuvent supposer que l’ensemble
d’attributs disponibles restera relativement stable lors du fonctionnement et ne sera amené à être modifié
qu’en cas de reconfiguration ou de reprogrammation du serveur et non au cours du fonctionnement
normal. Par exemple, même si la valeur par défaut de l’attribut InAlarm est « false », cet attribut n’est pas
censé être absent lorsque le nœud n’est pas en alarme et est censé être présent uniquement lorsque le
nœud est en alarme. En général, si un attribut peut avoir une valeur qui est différente de sa valeur par
défaut pendant le fonctionnement normal, il convient que l’attribut soit présent à tout moment.
Le serveur peut fournir des attributs propriétaires pour n’importe quel nœud ou attribut à n’importe quel
emplacement dans la hiérarchie du modèle de données. Les attributs propriétaires doivent commencer
par un point ('.') afin de pouvoir se distinguer des attributs standard. Le type de données et l’ensemble
des valeurs possibles de ces attributs ne sont pas définis par la présente norme.
N.8.1 Attributs primitifs
Le type de données d’un attribut primitif de la présente norme est défini à l’aide de son nom de type de
données XML Schema, tel que « boolean », « nonNegativeInteger » et « double ». Voir l’Article N.10 pour
des détails sur la manière dont ces attributs sont codés pour une utilisation dans les services Web.
Le type de données de certains attributs, tels que Value et Minimum, dépend de la valeur de l’attribut
ValueType. Le paragraphe N.8.9 fournit une description plus détaillée.
N.8.2 Attributs énumérés
Certains attributs primitifs sont des énumérations. Les attributs énumérés sont de type de données XML
Schema « string », mais l’ensemble des valeurs autorisées est défini par la présente norme. En outre,
certains attributs énumérés sont localisables (voir N.5). Dans ce cas, l’ensemble de valeurs non localisé
est défini par la présente norme, mais les chaînes de caractères localisées sont d’ordre local.
N.8.3 Attributs de tableau
Il s’agit d’attributs qui contiennent un tableau de valeurs primitives. Chaque élément du tableau a le même
type de données primitif. Le contenu d’un attribut de tableau est accessible en tant que tableau
d’éléments séparés ou en tant que concaténation de tous les éléments.
Le type de données d’un élément de tableau de la présente norme est défini à l’aide de son nom de type
de données XML Schema, tel que « boolean », « nonNegativeInteger » et « double ». Voir l’Article N.10
pour des détails sur la manière dont ces attributs sont codés pour une utilisation dans les services Web.
Lorsque les attributs de tableau sont accessibles avec un service retournant un tableau, tel que getArray,
les éléments de tableau sont retournés sous forme de chaînes de caractères individuelles. Toutefois,
lorsqu’ils sont accessibles avec un service retournant une seule chaîne, telle que getValue, les valeurs de
tableau sont concaténées en une seule chaîne en séparant les éléments par un point-virgule « ; », par
exemple, « high;medium;low ». Les valeurs des éléments de tableau individuels ne doivent pas contenir
de point-virgule.
Le serveur doit conserver l’ordre des éléments d’un attribut de tableau. Les clients de services tels que
getArrayRange peuvent, par conséquent, être dépendants de ce comportement pour lire le tableau,
élément après élément.
N.8.4 Récapitulatif sur les attributs
Certains attributs sont toujours requis, et d’autres sous certaines conditions, en fonction des critères mis
en évidence dans le tableau suivant. Le type de données auquel il est fait référence dans le tableau est
un nom de type de données XML Schema. Voir l’Article N.10 pour des informations sur le codage des
services Web. Les attributs non répertoriés comme Localisables ne sont jamais affectés par l’option de
service « locale » (voir paragraphe N.11.4) et sont toujours codés sous leur forme canonique non
localisée (voir paragraphe N.11.6).
8 © ISO 2009 – Tous droits réservés
ISO 16484-5:2007/Amd.1:2009(F)
Tableau N-1. Récapitulatif des attributs
Identifiant d’attribut Type de données Tablea Énu Local- Présence
u m- isable
éré
"NodeType" string Non Oui Non Obligatoire
"NodeSubtype" string Non Non Oui Facultative
"DisplayName" string Non Non Oui Facultative
"Description" string Non Non Oui Facultative
"ValueType" string Non Oui Non Obligatoire
"Value" (varie – voir Non Non Oui Obligatoire si ValueType n’est pas
N.8.9) « None »
"Units" string Non Oui Oui Obligatoire si ValueType est « Real »
ou « Integer »
"Writable" boolean Non Non Non Obligatoire si ValueType n’est pas
« None »
"InAlarm" boolean Non Non Non Facultative
"Minimum" (varie – voir Non Non Oui Facultative
N.8.9)
"Maximum" (varie – voir Non Non Oui Facultative
N.8.9)
"Resolution" (varie – voir Non Non Oui Facultative
N.8.9)
"MinimumLength" nonNegativeIntegNon Non Non Facultative et uniquement si
er ValueType est « String »
"MaximumLength" nonNegativeIntegNon Non Non Facultative et uniquement si
er ValueType est « String »
"IsMultiLine" boolean Non Non Non Facultative
"Attributes" string Oui Non Non Obligatoire
"WritableValues" string Oui Non Oui Obligatoire si ValueType est
« Multistate » ou « Boolean » et si
Writable est true
"PossibleValues" string Oui Non Oui Obligatoire si ValueType est
« Multistate » ou « Boolean »
"Overridden" boolean Non Non Non Facultative
"ValueAge" double Non Non Oui Facultative
(secondes)
"Aliases" string Oui Non Non Obligatoire si des nœuds de
référence font référence à ce nœud
(voir N.4)
"Children" string Oui Non Non Facultative
"Reference" string Non Non Non Présent si et seulement si le nœud
est un nœud de référence (voir
l’Article N.4)
"HasHistory" boolean Non Non Non Obligatoire si ValueType n’est pas
« None »
"SinglyWritableLocale string Oui Non Non Présent si et seulement si ValueType
s" est « String » et Writable est true
"HasDynamicChildren"boolean Non Non Non Facultative
N.8.5 NodeType
Cet attribut obligatoire indique la classification générale d’un nœud. Il sert d’indication à l’application client
sur le contenu d’un nœud et il n’est pas prévu pour acheminer une définition exacte. La liste des valeurs
de cet attribut n’est pas extensible. Une classification plus précise est fournie par l’attribut NodeSubtype.
Les valeurs admises pour cet attribut sont les suivantes :
{"Unknown", "System", "Network", "Device", "Functional", "Organizational", "Area",
"Equipment", "Point", "Collection", "Property", "Other"}
ISO 16484-5:2007/Amd.1:2009(F)
Le type « Unknown » peut être utilisé pour les données originaires d’une autre source et pour lesquelles
aucun type d’information n’est connu. Le type « System » peut être utilisé pour désigner un système
mécanique dans son intégralité. Le type « Network » peut servir à représenter un réseau de
communications, et le type « Device » pourrait être utilisé pour représenter un dispositif physique sur ce
réseau. Le type « Functional » peut être utilisé pour représenter un seul composant système tel qu’un
module de commande ou un composant logique tel qu’un bloc fonctionnel. Le type « Organizational » a
pour but de représenter les concepts d’entreprise tels que les départements ou le personnel. Le type
« Area » représente un concept géographique tel qu’un campus, un bâtiment, un étage, etc. Un « Point »
représente un seul point de données, une entrée ou une sortie physique d’un dispositif de commande ou
de surveillance, ou un paramètre de calcul logiciel ou de configuration. Un type « Equipment » peut servir
à représenter un seul élément d’un équipement pouvant être un ensemble de « Points ». Un type
« Collection » est un simple conteneur générique servant à regrouper des éléments tels qu’un ensemble
de références à toutes les valeurs de température ambiante relevées dans un bâtiment. Le type
« Property » a pour but de modéliser les données faisant logiquement partie d’un nœud parent. Le type
« Other » sert à tout ce qui ne rentre pas dans les catégories précédentes.
N.8.6 NodeSubtype
Cet attribut optionnel est une chaîne de caractères imprimables dont le contenu n’est pas limité. Il fournit
une classification plus spécifique du nœud. Par exemple, lorsque l’attribut NodeType a une valeur
« Area », le nœud NodeSubtype pourrait avoir une valeur telle que « Campus », « Building » ou « Floor ».
Cet attribut peut être localisé, éventuellement en retournant différentes valeurs appropriées aux
paramètres régionaux lorsqu’une option de service « locale » est spécifiée.
N.8.7 DisplayName
Cet attribut obligatoire est une chaîne de caractères imprimables dont le contenu n’est pas limité. Il sert à
fournir un nom ou un titre descriptif court (10-30 caractères) qui s’affiche dans les interfaces utilisateur
pour les humains. Il convient qu’il soit localisé, si la localisation est prise en charge, éventuellement en
retournant différentes valeurs appropriées aux paramètres régionaux lorsqu’une option de service
« locale » est spécifiée. Un client peut extraire cet attribut dans n’importe quel paramètre régional pris en
charge par le serveur pour la création d’affichages multilingues. Il n’est pas nécessaire que les valeurs
des attributs DisplayName soient uniques parmi les nœuds apparentés.
Un attribut DisplayName peut être différent de l’identifiant de chemin utilisé pour accéder au nœud. Par
exemple, pour le nœud identifié par le chemin « /Building 12/Room 225 », le DisplayName pourrait être
« Bob's Office » dans un paramètre régional et « Bureau de Bob » dans un autre, ou juste « Room 225 »
dans tous les paramètres régionaux.
N.8.8 Description
Cet attribut optionnel est une chaîne de caractères imprimables dont le contenu n’est pas limité. Cet
attribut peut être localisé, éventuellement en retournant différentes valeurs appropriées aux paramètres
régionaux lorsqu’une option de service « locale » est spécifiée.
N.8.9 ValueType
Cet attribut obligatoire indique le type de données de l’attribut Value et des attributs limitant l’attribut
Value. Si le nœud n’a pas de valeur, cet attribut doit toujours avoir la valeur « None ». La liste des valeurs
de cet attribut n’est pas extensible. Les valeurs admises pour cet attribut sont les suivantes :
{"None", "String", "OctetString", "Real", "Integer", "Multistate", "Boolean", "Date", "Time", "DateTime",
"Duration"}
Le type « None » est utilisé lorsque le nœud n’a pas de valeur. Le type « String » est utilisé pour les
nœuds dont les valeurs de chaîne de caractères ont pour but d’être lisibles par les humains. Un type
« OctetString » est utilisé pour contenir des données binaires arbitraires qui ne sont généralement pas
lisibles par les humains. Un type « Real » est une valeur à virgule flottante, par exemple 75,6. Un type
« Integer » concerne les valeurs exprimées sous forme de chiffres, par exemple 1234. Un type
« Multistate » est une valeur représentant un choix parmi un ensemble d’états nommés, par exemple,
10 © ISO 2009 – Tous droits réservés
ISO 16484-5:2007/Amd.1:2009(F)
{"high", "medium", "low"}. Un type « Boolean » est un choix entre deux états nommés exactement, tels
que « on » et « off », l’un étant considéré comme true et l’autre comme false. Un type « Date » sert à
représenter les valeurs correspondant à des dates calendaires. Un type « Time » est utilisé pour
représenter une heure du jour. Un type « DateTime » est utilisé pour représenter un moment exact dans
le temps, avec spécification d’une date et d’une heure. Un type « Duration » représente une durée, telle
que « 5 secondes ».
La représentation de tous les types de valeur autres que « None » et « OctetString » peut être affectée
par l’option de service « locale » si le serveur prend en charge la localisation d’un ou de plusieurs
paramètres régionaux. Voir l’Article N.5 et le paragraphe N.11.4.
L’effet de cet attribut sur le type de données Value et des attributs apparentés est récapitulé dans le
tableau suivant. Les types de données référencés dans le tableau sont des noms de type de données
XML Schema. Voir l’Article N.10 pour des informations sur le codage des services Web. Les attributs dont
le type de données est répertorié sous la forme n/a dans le tableau ne doivent pas être présents dans le
nœud.
Tableau N-2. Effet de l’attribut ValueType
Valeur de Type de données Type de Type de Type de données de
l’attribut de l’attribut Value données de données de l’attribut Resolution
ValueType l’attribut l’attribut
Minimum Maximum
"None" n/a n/a n/a n/a
"String" string n/a n/a n/a
"OctetString" base64Binary n/a n/a n/a
"Real" double double double double
"Integer" integer integer integer integer
"Multistate" string n/a n/a n/a
"Boolean" boolean n/a n/a n/a
"Date" date date date integer (jours)
"Time" time time time double (secondes)
"DateTime" dateTime dateTime dateTime double (secondes)
"Duration" double (secondes)double double double (secondes)
(secondes) (secondes)
N.8.10 Value
Cet attribut optionnel représente la valeur du nœud. Le type de données de cet attribut est indiqué par
l’attribut ValueType. L’attribut Value est présent si et seulement si la valeur de l’attribut ValueType n’est
pas « None ». Lorsque l’attribut ValueType du nœud est « String » ou « Multistate », les valeurs de cet
attribut peut être localisé en fonction de l’option de service « locale ». Voir N.11.4.
N.8.11 Units
Cet attribut optionnel définit les unités d’ingénierie de l’attribut Value du nœud. Si l’attribut ValueType est
« Real » ou « Integer », cet attribut doit être présent mais peut avoir la valeur « no-units ». Cet attribut
peut en option être présent pour d’autres valeurs de l'attribut ValueType.
La valeur de cet attribut est disponible sous deux formes. Si l'option de service « canonical » est false, la
valeur de cet attribut est une chaîne dont le contenu n’est pas limité et peut être approprié au paramètre
régional demandé. Si l’option de service « canonical » est true, la valeur de cet attribut se limite à être
exactement égale à l'un des identifiants d'énumération, tels que « degrees-Celsius », « inches-of-water »,
etc., qui sont définis par la production ASN.
...
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...