ISO 16484-6:2009

Building automation and control systems (BACS) - Part 6: Data communication conformance testing

ISO 16484-6:2009 defines a standard method for verifying that an implementation of the BACnet protocol provides each capability claimed in its Protocol Implementation Conformance Statement (PICS) in conformance with the BACnet standard. ISO 16484-6:2009 provides a comprehensive set of procedures for verifying the correct implementation of each capability claimed on a BACnet PICS, including upport of each claimed BACnet service, either as an initiator, executor, or both, support of each claimed BACnet object-type, including both required properties and each claimed optional property, support of the BACnet network layer protocol, support of each claimed data link option, and support of all claimed special functionality.

Systèmes d'automatisation et de gestion technique du bâtiment — Partie 6: Essais de conformité de la communication de données

L'ISO 16484-6:2009 définit une méthode normalisée permettant de vérifier qu'une mise en œuvre du protocole BACnet fournit l'ensemble des fonctionnalités citées dans la Déclaration de conformité d'une mise en œuvre de protocole (PICS) correspondante, conformément à la norme BACnet. L'ISO 16484-6:2009 fournit un ensemble complet de modes opératoires permettant de vérifier la bonne mise en œuvre de chaque fonctionnalité citée dans une déclaration PICS BACnet, notamment la prise en charge de chaque service BACnet déclaré, qu'il s'agisse d'un initiateur, d'un exécutant ou des deux, la prise en charge de chaque type d'objet BACnet déclaré, y compris les propriétés requises et chaque propriété facultative déclarée, la prise en charge du protocole de couche réseau BACnet, la prise en charge de chaque option de liaison de données déclarée, et la prise en charge de toutes les fonctionnalités spéciales déclarées.

General Information

• Status: Withdrawn
• Publication Date: 08-Mar-2009
• Withdrawal Date: 08-Mar-2009
• ICS: 35.240.67 - IT applications in building and construction industry
• ICS: 91.040.01 - Buildings in general
• Technical Committee: ISO/TC 205 - Building environment design
• Drafting Committee: ISO/TC 205/WG 3 - Building Automation and Control System (BACS) Design
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 14-May-2014
• Completion Date: 13-Dec-2025

Relations

• Consolidates: ISO/IEC 16500-3:1999 - Information technology - Generic digital audio-visual systems - Part 3: Contours: Technology domain
• Effective Date: 06-Jun-2022
• Revises: ISO 16484-6:2005 - Building automation and control systems (BACS) - Part 6: Data communication conformance testing
• Effective Date: 06-Jun-2022
• Revised: ISO 16484-6:2014 - Building automation and control systems (BACS) - Part 6: Data communication conformance testing
• Effective Date: 23-Mar-2013

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 16484-6
Second edition
2009-03-15
Building automation and control systems
(BACS) —
Part 6:
Data communication conformance testing
Systèmes d'automatisation et de gestion technique du bâtiment —
Partie 6: Essais de conformité de la communication de données

Reference number
©
ISO 2009
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 [e-mail]
Web www.iso.org
Published in Switzerland
ii
Contents
CLAUSE PAGE
1 Scope . 1
2 Relationship between this part of ISO 16484 and ANSI/ASHRE 135.1-2007 . 1
3 Terms, definitions and abbreviated terms . 1
4 ELECTRONIC PICS FILE FORMAT . 3
4.1 Character Encoding. 3
4.2 Structure of EPICS Files. 4
4.3 Character Strings. 4
4.4 Notational Rules for Parameter Values. 4
4.5 Sections of the EPICS File. 6
5 EPICS CONSISTENCY TESTS . 22
6 CONVENTIONS FOR SPECIFYING BACnet CONFORMANCE TESTS . 23
6.1 TCSL Components. 24
6.2 TCSL Statements . 25
6.3 Time Dependencies. 29
6.4 BACnet References. 29
7 OBJECT SUPPORT TESTS. 30
7.1 Read Support for Properties in the Test Database. 30
7.2 Write Support for Properties in the Test Database. 30
7.3 Object Functionality Tests . 31
8 APPLICATION SERVICE INITIATION TESTS . 99
8.1 AcknowledgeAlarm Service Initiation Tests . 99
8.2 ConfirmedCOVNotification Service Initiation Tests. 100
8.3 UnconfirmedCOVNotification Service Initiation Tests. 109
8.4 ConfirmedEventNotification Service Initiation Tests. 111
8.5 UnconfirmedEventNotification Service Initiation Tests. 141
8.6 GetAlarmSummary Service Initiation Tests . 147
8.7 GetEnrollmentSummary Service Initiation Tests . 147
8.8 GetEventInformation Service Initiation Tests. 149
8.9 LifeSafetyOperation Service Initiation Tests. 149
8.10 SubscribeCOV Service Initiation Tests . 150
8.11 SubscribeCOVProperty Service Initiation Tests. 151
8.12 AtomicReadFile Service Initiation Tests . 152
8.13 AtomicWriteFile Service Initiation Tests . 152
8.14 AddListElement Service Initiation Tests . 153
8.15 RemoveListElement Service Initiation Tests. 153
8.16 CreateObject Service Initiation Tests. 154
8.17 DeleteObject Service Initiation Tests. 155
8.18 ReadProperty Service Initiation Tests. 155
8.19 ReadPropertyConditional Service Initiation Tests. 156
8.20 ReadPropertyMultiple Service Initiation Tests . 156
8.21 ReadRange Service Initiation Tests . 157
8.22 WriteProperty Service Initiation Tests. 159
8.23 WritePropertyMultiple Service Initiation Tests . 159
8.24 DeviceCommunicationControl Service Initiation Tests. 161
8.25 ConfirmedPrivateTransfer Service Initiation Test . 162
8.26 UnconfirmedPrivateTransfer Service Initiation Test . 163
8.27 ReinitializeDevice Service Initiation Tests. 163
8.28 ConfirmedTextMessage Service Initiation Tests . 164
8.29 UnconfirmedTextMessage Service Initiation Tests . 165
8.30 TimeSynchronization Service Initiation Tests . 166
8.31 UTCTimeSynchronization Service Initiation Tests . 166
8.32 Who-Has Service Initiation Tests . 166
8.33 I-Have Service Initiation Tests . 167
iii
8.34 Who-Is Service Initiation Tests.167
8.35 I-Am Service Initiation Tests .168
8.36 VT-Open Service Initiation Tests.168
8.37 VT-Close Service Initiation Tests .169
8.38 VT-Data Service Initiation Tests.170
8.39 RequestKey Service Initiation Tests .172
8.40 Authenticate Service Initiation Tests .173
9 APPLICATION SERVICE EXECUTION TESTS.176
9.1 AcknowledgeAlarm Service Execution Tests .177
9.2 ConfirmedCOVNotification Service Execution Tests .189
9.3 UnconfirmedCOVNotification Service Execution Tests .193
9.4 ConfirmedEventNotification Service Execution Tests.193
9.5 UnconfirmedEventNotification Service Execution Tests.194
9.6 GetAlarmSummary Service Execution Tests.194
9.7 GetEnrollmentSummary Service Execution Tests .195
9.8 GetEventInformation Service Execution Tests .199
9.9 LifeSafetyOperation Service Execution Test .201
9.10 SubscribeCOV Service Execution Tests .202
9.11 SubscribeCOVProperty Service Execution Tests.207
9.12 AtomicReadFile Service Execution Tests.214
9.13 AtomicWriteFile Service Execution Tests .220
9.14 AddListElement Service Execution Tests.230
9.15 RemoveListElement Service Execution Tests.232
9.16 CreateObject Service Execution Tests .234
9.17 DeleteObject Service Execution Tests .238
9.18 ReadProperty Service Execution Tests .239
9.19 ReadPropertyConditional Service Execution Tests.241
9.20 ReadPropertyMultiple Service Execution Tests.242
9.21 ReadRange Service Execution Tests.249
9.22 WriteProperty Service Execution Tests .251
9.23 WritePropertyMultiple Service Execution Tests.256
9.24 DeviceCommunicationControl Service Execution Test.264
9.25 ConfirmedPrivateTransfer Service Execution Tests .268
9.26 UnconfirmedPrivateTransfer Service Execution Tests .269
9.27 ReinitializeDevice Service Execution Tests.269
9.28 ConfirmedTextMessage Service Execution Tests.271
9.29 UnconfirmedTextMessage Service Execution Tests.273
9.30 TimeSynchronization Service Execution Tests.273
9.31 UTCTimeSynchronization Service Execution Tests.274
9.32 Who-Has Service Execution Tests.275
9.33 Who-Is Service Execution Tests .280
9.34 VT-Open Service Execution Tests.283
9.35 VT-Close Service Execution Tests.284
9.36 VT-Data Service Execution Tests .285
9.37 RequestKey Service Execution Test .286
9.38 Authenticate Service Execution Tests.288
9.39 General Testing of Service Execution.292
10 NETWORK LAYER PROTOCOL TESTS.293
10.1 Processing Application Layer Messages Originating from Remote Networks .293
10.2 Router Functionality Tests .293
10.3 Half-Router Functionality Tests.317
10.4 B/IP PAD Tests.323
10.5 Initiating Network Layer Messages .325
11 LOGICAL LINK LAYER PROTOCOL TESTS.327
11.1 UI Command and Response.327
11.2 XID Command and Response .327
11.3 TEST Command and Response.328
12 DATA LINK LAYER PROTOCOLS TESTS.329
12.1 MS/TP State Machine Tests.329
12.2 PTP State Machine Tests.381
iv
13 SPECIAL FUNCTIONALITY TESTS. 417
13.1 Segmentation . 417
13.2 Time Master. 426
13.3 Character Sets . 427
13.4 Malformed PDUs. 427
13.5 Slave Proxy Tests. 428
14 BACnet/IP Functionality Tests . 431
14.1 Non-BBMD B/IP Device. 431
14.2 Non-BBMD B/IP device Device with a Server Application. 433
14.3 Broadcast Distribution Table Operations. 433
14.4 Foreign Device Table Operations (Negative Tests). 436
14.5 BACnet Broadcast Management (No Foreign Device Table, No Applications). 437
14.6 Foreign Device Management . 438
14.7 Broadcast Management (BBMD, Foreign Devices, Local Application). 440
15 Reporting Test Results. 443
ANNEX A - Example EPICS (INFORMATIVE) . 444

v
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.
ISO 16484-6 was prepared by Technical Committee ISO/TC 205, Building environment design.
This second edition cancels and replaces the first edition (ISO 16484-6:2005), of which it constitutes a minor
revision.
ISO 16484 consists of the following parts, under the general title Building automation and control systems
(BACS):
⎯ Part 2: Hardware
⎯ Part 3: Functions
⎯ Part 5: Data communication protocol
⎯ Part 6: Data communication conformance testing
A Part 1, dealing with project implementation, and a Part 4, dealing with applications, are under development.

vi
INTERNATIONAL STANDARD ISO 16484-6:2009(E)

Building automation and control systems (BACS) —
Part 6:
Data communication conformance testing
1 Scope
This part of ISO 16484 defines a standard method for verifying that an implementation of the BACnet protocol
provides each capability claimed in its Protocol Implementation Conformance Statement (PICS) in
conformance with the BACnet standard.
This part of ISO 16484 provides a comprehensive set of procedures for verifying the correct implementation of
each capability claimed on a BACnet PICS, including
a) support of each claimed BACnet service, either as an initiator, executor, or both,
b) support of each claimed BACnet object-type, including both required properties and each claimed optional
property,
c) support of the BACnet network layer protocol,
d) support of each claimed data link option, and
e) support of all claimed special functionality.
2 Relationship between this part of ISO 16484 and ANSI/ASHRE 135.1-2007
This part of ISO 16484 comprises, from Clause 4 onwards, the US standard ANSI/ASHRE 135.1-2007,
Method of Test for Conformance to BACnet, published by the American National Standards Institute and the
American Society of Heating, Refrigerating and Air-Conditioning Engineers.
3 Terms, definitions and abbreviated terms
For the purposes of this document, the following terms, definitions and abbreviated terms apply.
3.1
local network
network to which a BACnet device is directly connected
3.2
remote network
network that is accessible from a BACnet device only by passing through one or more routers
3.3
test database
database of BACnet functionality and objects created by reading the contents of an EPICS
BNF Backus-Naur Form syntax
EPICS electronic protocol implementation conformance statement
IUT implementation under test
TCSL testing and conformance scripting language
TD testing device
TPI text protocol information
4 ELECTRONIC PICS FILE FORMAT
An electronic protocol implementation conformance statement (EPICS) file contains a BACnet protocol implementation
conformance statement expressed in a standardized text form. EPICS files are machine and human readable
representations of the implementation of BACnet objects and services within a given device. EPICS files shall use the
extension ".TPI" (text protocol information) and contain normal editable text lines consisting of text character codes
ending in carriage return/linefeed pairs (X'0D', X'0A').

EPICS files are used by software testing tools to conduct and interpret the results of tests defined in this standard. An
EPICS file shall accompany any device tested according to the procedures of this standard.
4.1 Character Encoding
BACnet provides for a variety of possible character encodings. The character encodings in BACnet fall into three groups:
octet streams, double octet streams and quad octet streams. Octet streams represent characters as single octet values. In
some cases, such as Microsoft DBCS and JIS C 6226, certain octet values signal that the second octet which follows
should be viewed along with the leading octet as a single value, thus extending the range to greater than 256 possible
characters. In contrast, double octet streams view pairs of octets as representing single characters. The ISO 10646 UCS-2
encoding is an example. The first or leading octet of the pair is the most significant part of the value. Quad octet streams,
such as ISO 10646 UCS-4, treat tuples of four octets at a time as single characters with the first or leading octet being the
most significant.
To accommodate the various encodings that may be used with BACnet device descriptions, EPICS files begin with a
header that serves both to identify the file as an EPICS file, and to identify the particular encoding used. The header
begins with the string "PICS #" where # is replaced by a numeral representing the character set as shown in Table 4-1.

Table 4-1. Character Set Codes
code character set
0 ANSI X3.4
1 Microsoft DBCS
2 JIS C 6226
3 ISO 10646 (UCS-4)
4 ISO 10646 (UCS-2)
5 ISO 8859-1
An octet stream format can be recognized by examining the first eight octets of the EPICS file. Using ANSI X3.4
encoding as an example these eight octets will contain: X'50' X'49' X'43' X'53' X'20' X'30' X'0D' X'0A'. This represents
the text "PICS 0" followed by carriage return and linefeed.

A double octet stream format can be recognized by examining the first 16 octets of the EPICS file. Using ISO 10646
UCS-2 encoding as an example these 16 octets will contain:

X'00' X'50' X'00' X'49' X'00' X'43' X'00' X'53'
X'00' X'20' X'00' X'34' X'00' X'0D' X'00' X'0A'

This represents the text "PICS 4" followed by carriage return and linefeed.

A quad octet stream format can be recognized by examining the first 32 octets of the EPICS file. Using ISO 10646 UCS-
4 as an example these 32 octets will contain:

X'00' X'00' X'00' X'50' X'00' X'00' X'00' X'49'
X'00' X'00' X'00' X'43' X'00' X'00' X'00' X'53'
X'00' X'00' X'00' X'20' X'00' X'00' X'00' X'33'
X'00' X'00' X'00' X'0D' X'00' X'00' X'00' X'0A'

This represents the text "PICS 3" followed by carriage return and linefeed.
4.2 Structure of EPICS Files
EPICS files consist of text lines ending in carriage return/linefeed pairs (X'0D', X'0A') encoded as octet, double octet or
quad octet streams as defined in 4.1. In the rest of this standard, the term "character" will be used to mean one symbol
encoded as one, two, or four octets based on the character encoding used in the EPICS file header. For example, the
character space may be encoded as X'20' or X'0020' or X'00000020'. In this standard all characters will be shown in their
single octet form.
The special symbol ↵ is used in this Clause to signify the presence of a carriage return/linefeed pair (X'0D0A'). Except
within character strings, the character codes tab (X'09'), space (X'20'), carriage return (X'0D') and linefeed (X'0A') shall
be considered to be white space. Any sequence of 1 or more white space characters shall be equivalent to a single white
space character. Except within a character string, a sequence of two dashes (X'2D') shall signify the beginning of a
comment which shall end with the next carriage return/linefeed pair, i.e., the end of the line upon which the -- appears.
Comments shall be considered to be white space, and may thus be inserted freely.

EPICS files shall have, as their first line following the header, the literal text:
BACnet Protocol Implementation Conformance Statement ↵
This text serves as a signature identifying the EPICS file format.

Lines that define the sections of the EPICS (see 4.5) and the particular implementation data for a given device follow the
signature line.
The EPICS file ends with a line containing the following literal text:
End of BACnet Protocol Implementation Conformance Statement ↵
4.3 Character Strings
The occurrence of a double quote (X'22'), single quote (X'27') or accent grave (X'60') shall signify character strings. For
double quotes, the end of the string shall be signified by the next occurrence of a double quote, or the end of the line. For
single quote or accent grave, the end of the string shall be signified by the next occurrence of a single quote (X'27'), or
the end of the line. Thus strings which need to include a single quote or accent grave as a literal character in the string
shall use the double quote quoting method, while strings which need to include double quote shall use the single quote or
accent grave quoting method.
4.4 Notational Rules for Parameter Values
Within each section, parameters may need to be expressed in one of several forms. The following rules govern the format
for parameters:
(a) key words are case insensitive so that X'41' through X'5A' are equivalent to X'61' through X'7A';
(b) null values are shown by the string "NULL";
(c) Boolean values are shown by the strings "T" or "TRUE" if the value is true, or "F" or "FALSE" if the value is
false;
(d) integer values are shown as strings of digits, possibly with a leading minus (-): 12345 or -111;
(e) real values are shown with a decimal point, which may not be the first or last character: 1.23, 0.02, 1.0 but not
.02;
(f) octet strings are shown as pairs of hex digits enclosed in either single quotes (X'2D') or accent graves (X'60'),
and preceded by the letter "X": X'001122';
(g) character strings are represented as one or more characters enclosed in double, single or accent grave quotes as
defined in 4.3: 'text' or 'text' or "text";
(h) bitstrings are shown as a list, enclosed by curly brackets ({ } or X'7B' and X'7D'), of true and false values:
{T,T,F} or {TRUE, TRUE, FALSE}. When the actual value of a bit does not matter, a question mark is used:
{T,T,?};
(i) enumerated values are represented as named, rather than numeric, values. Enumeration names are case
insensitive so that X'41' through X'5A' are equivalent to X'61' through X'7A'. The underscore (X'5F') and dash
(X'2D') are considered equivalent in enumeration names. Proprietary values are shown as a named text with no
whitespace and ending in a non-negative decimal numeric. Each must start with the word "proprietary":
Object_Type, proprietary-object-type-653;
(j) dates are represented enclosed in parenthesis: (Monday, 24-January-1998). Any "wild card" or unspecified field
is shown by an asterisk (X'2A'): (Monday, *-January-1998). The omission of day of week implies that the day is
unspecified: (24-January-1998);
(k) times are represented as hours, minutes, seconds, hundredths in the format hh:mm:ss.xx: 2:05:44.00,
16:54:59.99. Any "wild card" field is shown by an asterisk (X'2A'): 16:54:*.*;
(l) object identifiers are shown enclosed by parentheses, with commas separating the object type and the instance
number: (analog-input, 56). Proprietary object types replace the object type enumeration with the word
"proprietary" followed by the numeric value of the object type: (proprietary 700,1);
(m) constructed data items are represented enclosed by curly brackets ({ } or X'7B' and X'7D'), with elements
separated by commas. If an element is itself a constructed value, then that element shall be enclosed in curly
brackets.
4.4.1 Complex Parameter Values
Some parameter values, notably property values for constructed or CHOICE types of encoded values, need to use a more
complex notation to represent their values. This notation is tied to the ASN.1 encoding for those property values and may
appear obscure out of context. These additional rules govern the presentation of those types of parameter values:

(a) values which are a CHOICE of application-tagged values are represented by the value of the chosen item
encoded as described in 4.4;
(b) values which are a CHOICE of context-tagged values are represented by the context tag number enclosed in
square brackets, followed by the representation of the value of the chosen item;
(c) list values (ASN.1 "SEQUENCE OF") are represented enclosed in parenthsis, with the elements of the list
separated by commas. If an element is itself a constructed value, then that element shall be enclosed in curly
brackets;
(d) array values are represented enclosed in curly brackets, with the elements of the array separated by commas. If
an element is itself a constructed value, then that element shall be enclosed in curly brackets.
4.4.2 Specifying Limits on Parameter Values
Some properties may have restrictions on the range or resolution of their values. In order to correctly interpret the results
of tests in which the value of a property is changed using WriteProperty, WritePropertyMultiple, or AddListElement then
read back using ReadProperty or ReadPropertyMultiple, it is necessary to know what these restrictions are. The test
database may contain restriction statements that define these constraints. The permissible restrictions and the datatypes
they apply to are:
(a) minimum - the minimum value for Unsigned, Integer, Real, or Double datatypes. The earliest date for the Date
datatype;
(b) maximum - the maximum value for Unsigned, Integer, Real, or Double datatypes. The latest date for the Date
datatype;
(c) resolution - the minimum guaranteed resolution for Real and Double datatypes. The minimum time resolution
in seconds for the Time datatype;
(d) maximum length string - the maximum length of a CharacterString or OctetString;
(e) maximum length list - the maximum number of elements guaranteed to fit in a list;
(f) maximum length array - the maximum number of elements in an array;
(g) allowed values - a comma-delimited list of supported enumerations for an Enumerated datatype. A comma-
delimited list of object types for properties that reference an external object identifier.

Restriction statements shall be listed within pointed brackets (< and >) following the default value. If there are multiple
restrictions within a single set of angle brackets, then the restrictions shall be separated by a semicolon (;). A restriction
statement consists of the restriction name followed by a colon (:) followed by the restriction value or, where appropriate,
a comma-delimited list of possible values.

Here are some examples of property values with restriction statements as they could appear in the test database.

present-value: 13.4
description: "this is a description"
units: milliamperes
object-property-reference: (analog input, 12)

The Units property is a special case, because changing the units can change the value of the Present_Value property as
well as any restrictions on its value. Therefore, minimum, maximum, and resolution restrictions are only valid for the
default value of the Units property.

It is possible to specify default restrictions for most datatypes as described in 4.5.8. Restriction statements in the test
database override the default restrictions for the individual property that contains the restriction statement.
4.5 Sections of the EPICS File
Each section of the EPICS file begins with a section name followed by a colon ( : or X'3A'). After the colon is a set of
one or more parameters delimited by a set of curly braces ({ } or X'7B' X'7D').

The following symbols are used as placeholders to indicate the presence of parameter information:
(a) the open box symbol inside quotation marks, "‰", is used to indicate that a character string parameter shall be
present;
(b) the open box symbol with no quotation marks, ‰, is used to indicate that a parameter with a datatype other than
a character string shall be present;
(c) a question mark, ?, is used in the test database to indicate that the property is present but the value is unknown
because it depends on hardware input or is being changed by an internal algorithm.

An example EPICS file may be found in Annex A.
4.5.1 General Information Sections
These sections provide general information about the BACnet device. The syntax for these sections is shown below.

Vendor Name: "‰"↵
Product Name: "‰"↵
Product Model Number: "‰"↵
Product Description: "‰"↵
4.5.2 Conformance Sections
These sections provide information about the BACnet functionality that the device claims to support.
4.5.2.1 BIBBs Supported
This section indicates which BIBBs are supported. The syntax is shown below. Each BIBB shall be listed, one per line
between the curly braces. An empty list indicates that no BIBBs are supported.

BIBBs Supported: ↵
{↵
‰↵
}↵
The BIBBs may be any of:
DS-RP-A DS-RP-B
DS-RPM-A DS-RPM-B
DS-RPC-A DS-RPC-B
DS-WP-A DS-WP-B
DS-WPM-A DS-WPM-B
DS-COV-A DS-COV-B
DS-COVP-A DS-COVP-B
DS-COVU-A DS-COVU-B
AE-N-A AE-N-I-B AE-N-E-B
AE-ACK-A AE-ACK-B
AE-ASUM-A AE-ASUM-B
AE-ESUM-A AE-ESUM-B
AE-INFO-A AE-INFO-B
AE-LS-A AE-LS-B
SCHED-A SCHED-I-B SCHED-E-B
T-VMT-A T-VMT-I-B T-VMT-E-B
T-ATR-A T-ATR-B
DM-DDB-A DM-DDB-B
DM-DOB-A DM-DOB-B
DM-DCC-A DM-DCC-B
DM-PT-A DM-PT-B
DM-TM-A DM-TM-B
DM-TS-A DM-TS-B
DM-UTC-A DM-UTC-B
DM-RD-A DM-RD-B
DM-BR-A DM-BR-B
DM-R-A DM-R-B
DM-LM-A DM-LM-B
DM-OCD-A DM-OCD-B
DM-VT-A DM-VT-B
NM-CE-A NM-CE-B
NM-RC-A NM-RC-B
4.5.3 Application Services Supported
This section indicates which standard application services are supported. The syntax is shown below. Each supported
service shall be listed between curly braces one service per line, followed by the words "Initiate" or "Execute" to indicate
whether the service can be initiated, executed, or both.

BACnet Standard Application Services Supported: ↵
{↵
‰ Initiate↵
‰ Execute↵
‰ Initiate Execute↵
}
The standard services may be any of:

AcknowledgeAlarm  RemoveListElement  ConfirmedTextMessage
ConfirmedCOVNotification  CreateObject   UnconfirmedTextMessage
UnconfirmedCOVNotification  DeleteObject  TimeSynchronization
ConfirmedEventNotification  ReadProperty   UTCTimeSynchronization
UnconfirmedEventNotification ReadPropertyConditional  Who-Has
GetAlarmSummary  ReadPropertyMultiple  I-Have
GetEnrollmentSummary  ReadRange   Who-Is
GetEventInformation  WriteProperty  I-Am
LifeSafetyOperation  WritePropertyMultiple  VT-Open
SubscribeCOV  DeviceCommunicationControl  VT-Close
SubscribeCOVProperty  ConfirmedPrivateTransfer  VT-Data
AtomicReadFile  UnconfirmedPrivateTransfer RequestKey
AtomicWriteFile  ReinitializeDevice  Authenticate
AddListElement
4.5.4 Object Types Supported
This section indicates which standard object types are supported. The syntax is shown below. Each supported object type
shall be listed between curly braces one object type per line, optionally followed by the words "Createable",
"Deleteable", or both to indicate that dynamic creation or deletion is supported.

Standard Object Types Supported: ↵
{↵
‰↵
‰ Createable↵
‰ Deleteable↵
‰ Createable Deleteable↵
}↵
The standard objects may be any of:

Access Door Binary Output Group Multi-state Value
Accumulator Binary Value Life Safety Point Notification Class
Analog Input Calendar Life Safety Zone Program
Analog Output Command Load Control Pulse Converter
Analog Value Device Loop Schedule
Averaging Event Enrollment Multi-state Input Structured View
Binary Input File Multi-state Output Trend Log

4.5.5 Data Link Layer Options
This section indicates which standard data link layer options are supported. The syntax is shown below. Each supported
data link layer type shall be listed between the curly braces one per line. MS/TP and Point-To-Point data links shall also
specify supported baud rate(s).

Data Link Layer Option: ↵
{↵
ISO 8802-3, 10BASE5↵
ISO 8802-3, 10BASE2↵
ISO 8802-3, 10BASET↵
ISO 8802-3, fiber↵
ARCNET, coax star↵
ARCNET, coax bus↵
ARCNET, twisted pair star↵
ARCNET, twisted pair bus↵
ARCNET, fiber star↵
ARCNET, twisted pair, EIA-485, Baud rate(s): ‰↵
MS/TP master. Baud rate(s): 9600, ‰↵
MS/TP slave. Baud rate(s): 9600, ‰↵
Point-To-Point. EIA 232, Baud rate(s): ‰↵
Point-To-Point. Modem, Baud rate(s): ‰↵
Point-To-Point. Modem, Autobaud range: ‰to ‰↵
BACnet/IP, 'DIX' Ethernet↵
BACnet/IP, Other↵
Other↵
}↵
4.5.6 Character Sets
This section indicates which BACnet character sets are supported. The syntax is shown below. Each supported character
set shall be listed one per line between the curly braces.

Character Sets Supported: ↵
{↵
ANSI X3.4↵
IBM/Microsoft DBCS↵
JIS C 6226↵
ISO 8859-1 ↵
ISO 10646 (UCS-4) ↵
ISO 10646 (UCS2) ↵
}↵
4.5.7 Special Functionality
This section indicates which BACnet special functionalities are supported. The syntax is shown below. Each special
functionality su
...

INTERNATIONAL ISO
STANDARD 16484-6
Second edition
2009-03-15
Building automation and control systems
(BACS) —
Part 6:
Data communication conformance testing
Systèmes d'automatisation et de gestion technique du bâtiment —
Partie 6: Essais de conformité de la communication de données

Reference number
©
ISO 2009
PDF disclaimer
PDF files may contain embedded typefaces. In accordance with Adobe's licensing policy, such files 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 a PDF 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 the PDF file(s) constituting this document can be found in the General Info relative to
the file(s); the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the files are suitable for
use by ISO member bodies. In the unlikely event that a problem relating to them is found, please inform the Central Secretariat at the
address given below.
This CD-ROM contains the publication ISO 16484-6:2009 in portable document format (PDF), which can be
viewed using Adobe® Acrobat® Reader.
Adobe and Acrobat are trademarks of Adobe Systems Incorporated.
This second edition cancels and replaces the first edition (ISO 16484-6:2005), of which it constitutes a minor
revision.
©  ISO 2009
All rights reserved. Unless required for installation or otherwise specified, no part of this CD-ROM may be reproduced, stored in a retrieval
system or transmitted in any form or by any means without prior permission from ISO. Requests for permission to reproduce this product
should be addressed to
ISO copyright
...

FINAL
INTERNATIONAL ISO/FDIS
DRAFT
STANDARD 16484-6
ISO/TC 205
Building automation and control systems
Secretariat: ANSI
(BACS) —
Voting begins on:
2008-11-20
Part 6:
Data communication conformance testing
Voting terminates on:
2009-01-20
Systèmes d'automatisation et de gestion technique du bâtiment —

Partie 6: Essais de conformité de la communication de données

Please see the administrative notes on page iii

RECIPIENTS OF THIS DRAFT ARE INVITED TO
SUBMIT, WITH THEIR COMMENTS, NOTIFICATION
OF ANY RELEVANT PATENT RIGHTS OF WHICH
THEY ARE AWARE AND TO PROVIDE SUPPORT-
ING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
Reference number
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/FDIS 16484-6:2008(E)
LOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON
OCCASION HAVE TO BE CONSIDERED IN THE
LIGHT OF THEIR POTENTIAL TO BECOME STAN-
DARDS TO WHICH REFERENCE MAY BE MADE IN
NATIONAL REGULATIONS. ©
ISO 2008
ISO/FDIS 16484-6:2008(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 notice
This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as permitted
under the applicable laws of the user's country, neither this ISO draft nor any extract from it may be
reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic,
photocopying, recording or otherwise, without prior written permission being secured.
Requests for permission to reproduce should be addressed to 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 [e-mail]
Web www.iso.org
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
ii
ISO/FDIS 16484-6:2008(E)
ISO/CEN PARALLEL PROCESSING
The CEN Secretary-General has advised the ISO Secretary-General that this final draft International
Standard covers a subject of interest to European standardization. In accordance with the ISO-lead mode
of collaboration as defined in the Vienna Agreement, this final draft is hereby submitted to a parallel
two-month FDIS vote in ISO and a three-month UAP vote in CEN.
Positive votes shall not be accompanied by comments.
Negative votes shall be accompanied by the relevant technical reasons.

In accordance with the provisions of Council Resolution 15/1993, this document is circulated in the
English language only.
iii
ISO/FDIS 16484-6:2008(E)
Contents
CLAUSE PAGE
1 Scope.1
2 Relationship between this part of ISO 16484 and ANSI/ASHRE 135.1-2007 .1
3 Terms, definitions and abbreviated terms .1
4 ELECTRONIC PICS FILE FORMAT .3
4.1 Character Encoding.3
4.2 Structure of EPICS Files .4
4.3 Character Strings.4
4.4 Notational Rules for Parameter Values .4
4.5 Sections of the EPICS File.6
5 EPICS CONSISTENCY TESTS.22
6 CONVENTIONS FOR SPECIFYING BACnet CONFORMANCE TESTS .23
6.1 TCSL Components.24
6.2 TCSL Statements .25
6.3 Time Dependencies.29
6.4 BACnet References.29
7 OBJECT SUPPORT TESTS.30
7.1 Read Support for Properties in the Test Database.30
7.2 Write Support for Properties in the Test Database.30
7.3 Object Functionality Tests .31
8 APPLICATION SERVICE INITIATION TESTS.99
8.1 AcknowledgeAlarm Service Initiation Tests.100
8.2 ConfirmedCOVNotification Service Initiation Tests.100
8.3 UnconfirmedCOVNotification Service Initiation Tests .109
8.4 ConfirmedEventNotification Service Initiation Tests .111
8.5 UnconfirmedEventNotification Service Initiation Tests .141
8.6 GetAlarmSummary Service Initiation Tests .147
8.7 GetEnrollmentSummary Service Initiation Tests.147
8.8 GetEventInformation Service Initiation Tests.149
8.9 LifeSafetyOperation Service Initiation Tests .149
8.10 SubscribeCOV Service Initiation Tests.150
8.11 SubscribeCOVProperty Service Initiation Tests .151
8.12 AtomicReadFile Service Initiation Tests.152
8.13 AtomicWriteFile Service Initiation Tests.152
8.14 AddListElement Service Initiation Tests.153
8.15 RemoveListElement Service Initiation Tests .153
8.16 CreateObject Service Initiation Tests.154
8.17 DeleteObject Service Initiation Tests.155
8.18 ReadProperty Service Initiation Tests.155
8.19 ReadPropertyConditional Service Initiation Tests .156
8.20 ReadPropertyMultiple Service Initiation Tests .156
8.21 ReadRange Service Initiation Tests .157
8.22 WriteProperty Service Initiation Tests .159
8.23 WritePropertyMultiple Service Initiation Tests .159
8.24 DeviceCommunicationControl Service Initiation Tests.161
8.25 ConfirmedPrivateTransfer Service Initiation Test .162
8.26 UnconfirmedPrivateTransfer Service Initiation Test .163
8.27 ReinitializeDevice Service Initiation Tests .163
8.28 ConfirmedTextMessage Service Initiation Tests .164
8.29 UnconfirmedTextMessage Service Initiation Tests .165
8.30 TimeSynchronization Service Initiation Tests .166
8.31 UTCTimeSynchronization Service Initiation Tests .166
8.32 Who-Has Service Initiation Tests.166
8.33 I-Have Service Initiation Tests.167
iv
ISO/FDIS 16484-6:2008(E)
8.34 Who-Is Service Initiation Tests. 167
8.35 I-Am Service Initiation Tests. 168
8.36 VT-Open Service Initiation Tests . 168
8.37 VT-Close Service Initiation Tests. 169
8.38 VT-Data Service Initiation Tests . 170
8.39 RequestKey Service Initiation Tests . 172
8.40 Authenticate Service Initiation Tests . 173
9 APPLICATION SERVICE EXECUTION TESTS . 176
9.1 AcknowledgeAlarm Service Execution Tests. 177
9.2 ConfirmedCOVNotification Service Execution Tests . 189
9.3 UnconfirmedCOVNotification Service Execution Tests . 192
9.4 ConfirmedEventNotification Service Execution Tests . 192
9.5 UnconfirmedEventNotification Service Execution Tests . 194
9.6 GetAlarmSummary Service Execution Tests. 194
9.7 GetEnrollmentSummary Service Execution Tests. 195
9.8 GetEventInformation Service Execution Tests . 199
9.9 LifeSafetyOperation Service Execution Test. 201
9.10 SubscribeCOV Service Execution Tests. 202
9.11 SubscribeCOVProperty Service Execution Tests . 207
9.12 AtomicReadFile Service Execution Tests. 214
9.13 AtomicWriteFile Service Execution Tests. 220
9.14 AddListElement Service Execution Tests. 230
9.15 RemoveListElement Service Execution Tests . 232
9.16 CreateObject Service Execution Tests. 234
9.17 DeleteObject Service Execution Tests. 238
9.18 ReadProperty Service Execution Tests . 239
9.19 ReadPropertyConditional Service Execution Tests . 241
9.20 ReadPropertyMultiple Service Execution Tests . 242
9.21 ReadRange Service Execution Tests. 249
9.22 WriteProperty Service Execution Tests . 251
9.23 WritePropertyMultiple Service Execution Tests. 256
9.24 DeviceCommunicationControl Service Execution Test. 264
9.25 ConfirmedPrivateTransfer Service Execution Tests . 268
9.26 UnconfirmedPrivateTransfer Service Execution Tests . 269
9.27 ReinitializeDevice Service Execution Tests . 269
9.28 ConfirmedTextMessage Service Execution Tests. 271
9.29 UnconfirmedTextMessage Service Execution Tests. 273
9.30 TimeSynchronization Service Execution Tests. 273
9.31 UTCTimeSynchronization Service Execution Tests. 274
9.32 Who-Has Service Execution Tests. 274
9.33 Who-Is Service Execution Tests . 280
9.34 VT-Open Service Execution Tests. 283
9.35 VT-Close Service Execution Tests . 284
9.36 VT-Data Service Execution Tests. 285
9.37 RequestKey Service Execution Test . 286
9.38 Authenticate Service Execution Tests. 288
9.39 General Testing of Service Execution. 292
10 NETWORK LAYER PROTOCOL TESTS. 293
10.1 Processing Application Layer Messages Originating from Remote Networks. 293
10.2 Router Functionality Tests. 293
10.3 Half-Router Functionality Tests. 317
10.4 B/IP PAD Tests. 323
10.5 Initiating Network Layer Messages . 325
11 LOGICAL LINK LAYER PROTOCOL TESTS. 327
11.1 UI Command and Response. 327
11.2 XID Command and Response. 327
11.3 TEST Command and Response . 328
12 DATA LINK LAYER PROTOCOLS TESTS. 329
12.1 MS/TP State Machine Tests. 329
12.2 PTP State Machine Tests . 381
v
ISO/FDIS 16484-6:2008(E)
13 SPECIAL FUNCTIONALITY TESTS.417
13.1 Segmentation.417
13.2 Time Master .426
13.3 Character Sets .427
13.4 Malformed PDUs .427
13.5 Slave Proxy Tests.428
14 BACnet/IP Functionality Tests .431
14.1 Non-BBMD B/IP Device .431
14.2 Non-BBMD B/IP device Device with a Server Application.433
14.3 Broadcast Distribution Table Operations .433
14.4 Foreign Device Table Operations (Negative Tests) .436
14.5 BACnet Broadcast Management (No Foreign Device Table, No Applications).437
14.6 Foreign Device Management .438
14.7 Broadcast Management (BBMD, Foreign Devices, Local Application).440
15 Reporting Test Results .443
ANNEX A - Example EPICS (INFORMATIVE) .444

vi
ISO/FDIS 16484-6:2008(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.
ISO 16484-6 was prepared by Technical Committee ISO/TC 205, Building environment design.
This second edition cancels and replaces the first edition (ISO 16484-6:2005), of which it constitutes a minor
revision.
ISO 16484 consists of the following parts, under the general title Building automation and control systems
(BACS):
⎯ Part 2: Hardware
⎯ Part 3: Functions
⎯ Part 5: Data communication protocol
⎯ Part 6: Data communication conformance testing
A Part 1, dealing with project implementation, and a Part 4, dealing with applications, are under development.

vii
FINAL DRAFT INTERNATIONAL STANDARD ISO/FDIS 16484-6:2008(E)

Building automation and control systems (BACS) —
Part 6:
Data communication conformance testing
1 Scope
This part of ISO 16484 defines a standard method for verifying that an implementation of the BACnet protocol
provides each capability claimed in its Protocol Implementation Conformance Statement (PICS) in
conformance with the BACnet standard.
This part of ISO 16484 provides a comprehensive set of procedures for verifying the correct implementation of
each capability claimed on a BACnet PICS, including
a) support of each claimed BACnet service, either as an initiator, executor, or both,
b) support of each claimed BACnet object-type, including both required properties and each claimed optional
property,
c) support of the BACnet network layer protocol,
d) support of each claimed data link option, and
e) support of all claimed special functionality.
2 Relationship between this part of ISO 16484 and ANSI/ASHRE 135.1-2007
This part of ISO 16484 comprises, from Clause 4 onwards, the US standard ANSI/ASHRE 135.1-2007,
Method of Test for Conformance to BACnet, published by the American National Standards Institute and the
American Society of Heating, Refrigerating and Air-Conditioning Engineers.
3 Terms, definitions and abbreviated terms
For the purposes of this document, the following terms, definitions and abbreviated terms apply.
3.1
local network
network to which a BACnet device is directly connected
3.2
remote network
network that is accessible from a BACnet device only by passing through one or more routers
3.3
test database
database of BACnet functionality and objects created by reading the contents of an EPICS
ISO/FDIS 16484-6:2008(E)
BNF Backus-Naur Form syntax
EPICS electronic protocol implementation conformance statement
IUT implementation under test
TCSL testing and conformance scripting language
TD testing device
TPI text protocol information
ISO/FDIS 16484-6:2008(E)
4 ELECTRONIC PICS FILE FORMAT
An electronic protocol implementation conformance statement (EPICS) file contains a BACnet protocol implementation
conformance statement expressed in a standardized text form. EPICS files are machine and human readable
representations of the implementation of BACnet objects and services within a given device. EPICS files shall use the
extension ".TPI" (text protocol information) and contain normal editable text lines consisting of text character codes
ending in carriage return/linefeed pairs (X'0D', X'0A').

EPICS files are used by software testing tools to conduct and interpret the results of tests defined in this standard. An
EPICS file shall accompany any device tested according to the procedures of this standard.
4.1 Character Encoding
BACnet provides for a variety of possible character encodings. The character encodings in BACnet fall into three groups:
octet streams, double octet streams and quad octet streams. Octet streams represent characters as single octet values. In
some cases, such as Microsoft DBCS and JIS C 6226, certain octet values signal that the second octet which follows
should be viewed along with the leading octet as a single value, thus extending the range to greater than 256 possible
characters. In contrast, double octet streams view pairs of octets as representing single characters. The ISO 10646 UCS-2
encoding is an example. The first or leading octet of the pair is the most significant part of the value. Quad octet streams,
such as ISO 10646 UCS-4, treat tuples of four octets at a time as single characters with the first or leading octet being the
most significant.
To accommodate the various encodings that may be used with BACnet device descriptions, EPICS files begin with a
header that serves both to identify the file as an EPICS file, and to identify the particular encoding used. The header
begins with the string "PICS #" where # is replaced by a numeral representing the character set as shown in Table 4-1.

Table 4-1. Character Set Codes
code character set
0 ANSI X3.4
1 Microsoft DBCS
2 JIS C 6226
3 ISO 10646 (UCS-4)
4 ISO 10646 (UCS-2)
5 ISO 8859-1
An octet stream format can be recognized by examining the first eight octets of the EPICS file. Using ANSI X3.4
encoding as an example these eight octets will contain: X'50' X'49' X'43' X'53' X'20' X'30' X'0D' X'0A'. This represents
the text "PICS 0" followed by carriage return and linefeed.

A double octet stream format can be recognized by examining the first 16 octets of the EPICS file. Using ISO 10646
UCS-2 encoding as an example these 16 octets will contain:

X'00' X'50' X'00' X'49' X'00' X'43' X'00' X'53'
X'00' X'20' X'00' X'34' X'00' X'0D' X'00' X'0A'

This represents the text "PICS 4" followed by carriage return and linefeed.

A quad octet stream format can be recognized by examining the first 32 octets of the EPICS file. Using ISO 10646 UCS-
4 as an example these 32 octets will contain:

X'00' X'00' X'00' X'50' X'00' X'00' X'00' X'49'
X'00' X'00' X'00' X'43' X'00' X'00' X'00' X'53'
X'00' X'00' X'00' X'20' X'00' X'00' X'00' X'33'
X'00' X'00' X'00' X'0D' X'00' X'00' X'00' X'0A'

This represents the text "PICS 3" followed by carriage return and linefeed.
ISO/FDIS 16484-6:2008(E)
4.2 Structure of EPICS Files
EPICS files consist of text lines ending in carriage return/linefeed pairs (X'0D', X'0A') encoded as octet, double octet or
quad octet streams as defined in 4.1. In the rest of this standard, the term "character" will be used to mean one symbol
encoded as one, two, or four octets based on the character encoding used in the EPICS file header. For example, the
character space may be encoded as X'20' or X'0020' or X'00000020'. In this standard all characters will be shown in their
single octet form.
The special symbol ↵ is used in this Clause to signify the presence of a carriage return/linefeed pair (X'0D0A'). Except
within character strings, the character codes tab (X'09'), space (X'20'), carriage return (X'0D') and linefeed (X'0A') shall
be considered to be white space. Any sequence of 1 or more white space characters shall be equivalent to a single white
space character. Except within a character string, a sequence of two dashes (X'2D') shall signify the beginning of a
comment which shall end with the next carriage return/linefeed pair, i.e., the end of the line upon which the -- appears.
Comments shall be considered to be white space, and may thus be inserted freely.

EPICS files shall have, as their first line following the header, the literal text:
BACnet Protocol Implementation Conformance Statement ↵
This text serves as a signature identifying the EPICS file format.

Lines that define the sections of the EPICS (see 4.5) and the particular implementation data for a given device follow the
signature line.
The EPICS file ends with a line containing the following literal text:
End of BACnet Protocol Implementation Conformance Statement ↵
4.3 Character Strings
The occurrence of a double quote (X'22'), single quote (X'27') or accent grave (X'60') shall signify character strings. For
double quotes, the end of the string shall be signified by the next occurrence of a double quote, or the end of the line. For
single quote or accent grave, the end of the string shall be signified by the next occurrence of a single quote (X'27'), or
the end of the line. Thus strings which need to include a single quote or accent grave as a literal character in the string
shall use the double quote quoting method, while strings which need to include double quote shall use the single quote or
accent grave quoting method.
4.4 Notational Rules for Parameter Values
Within each section, parameters may need to be expressed in one of several forms. The following rules govern the format
for parameters:
(a) key words are case insensitive so that X'41' through X'5A' are equivalent to X'61' through X'7A';
(b) null values are shown by the string "NULL";
(c) Boolean values are shown by the strings "T" or "TRUE" if the value is true, or "F" or "FALSE" if the value is
false;
(d) integer values are shown as strings of digits, possibly with a leading minus (-): 12345 or -111;
(e) real values are shown with a decimal point, which may not be the first or last character: 1.23, 0.02, 1.0 but not
.02;
(f) octet strings are shown as pairs of hex digits enclosed in either single quotes (X'2D') or accent graves (X'60'),
and preceded by the letter "X": X'001122';
(g) character strings are represented as one or more characters enclosed in double, single or accent grave quotes as
defined in 4.3: 'text' or 'text' or "text";
(h) bitstrings are shown as a list, enclosed by curly brackets ({ } or X'7B' and X'7D'), of true and false values:
{T,T,F} or {TRUE, TRUE, FALSE}. When the actual value of a bit does not matter, a question mark is used:
{T,T,?};
(i) enumerated values are represented as named, rather than numeric, values. Enumeration names are case
insensitive so that X'41' through X'5A' are equivalent to X'61' through X'7A'. The underscore (X'5F') and dash
(X'2D') are considered equivalent in enumeration names. Proprietary values are shown as a named text with no
whitespace and ending in a non-negative decimal numeric. Each must start with the word "proprietary":
Object_Type, proprietary-object-type-653;
(j) dates are represented enclosed in parenthesis: (Monday, 24-January-1998). Any "wild card" or unspecified field
is shown by an asterisk (X'2A'): (Monday, *-January-1998). The omission of day of week implies that the day is
unspecified: (24-January-1998);
ISO/FDIS 16484-6:2008(E)
(k) times are represented as hours, minutes, seconds, hundredths in the format hh:mm:ss.xx: 2:05:44.00,
16:54:59.99. Any "wild card" field is shown by an asterisk (X'2A'): 16:54:*.*;
(l) object identifiers are shown enclosed by parentheses, with commas separating the object type and the instance
number: (analog-input, 56). Proprietary object types replace the object type enumeration with the word
"proprietary" followed by the numeric value of the object type: (proprietary 700,1);
(m) constructed data items are represented enclosed by curly brackets ({ } or X'7B' and X'7D'), with elements
separated by commas. If an element is itself a constructed value, then that element shall be enclosed in curly
brackets.
4.4.1 Complex Parameter Values
Some parameter values, notably property values for constructed or CHOICE types of encoded values, need to use a more
complex notation to represent their values. This notation is tied to the ASN.1 encoding for those property values and may
appear obscure out of context. These additional rules govern the presentation of those types of parameter values:

(a) values which are a CHOICE of application-tagged values are represented by the value of the chosen item
encoded as described in 4.4;
(b) values which are a CHOICE of context-tagged values are represented by the context tag number enclosed in
square brackets, followed by the representation of the value of the chosen item;
(c) list values (ASN.1 "SEQUENCE OF") are represented enclosed in parenthsis, with the elements of the list
separated by commas. If an element is itself a constructed value, then that element shall be enclosed in curly
brackets;
(d) array values are represented enclosed in curly brackets, with the elements of the array separated by commas. If
an element is itself a constructed value, then that element shall be enclosed in curly brackets.
4.4.2 Specifying Limits on Parameter Values
Some properties may have restrictions on the range or resolution of their values. In order to correctly interpret the results
of tests in which the value of a property is changed using WriteProperty, WritePropertyMultiple, or AddListElement then
read back using ReadProperty or ReadPropertyMultiple, it is necessary to know what these restrictions are. The test
database may contain restriction statements that define these constraints. The permissible restrictions and the datatypes
they apply to are:
(a) minimum - the minimum value for Unsigned, Integer, Real, or Double datatypes. The earliest date for the Date
datatype;
(b) maximum - the maximum value for Unsigned, Integer, Real, or Double datatypes. The latest date for the Date
datatype;
(c) resolution - the minimum guaranteed resolution for Real and Double datatypes. The minimum time resolution
in seconds for the Time datatype;
(d) maximum length string - the maximum length of a CharacterString or OctetString;
(e) maximum length list - the maximum number of elements guaranteed to fit in a list;
(f) maximum length array - the maximum number of elements in an array;
(g) allowed values - a comma-delimited list of supported enumerations for an Enumerated datatype. A comma-
delimited list of object types for properties that reference an external object identifier.

Restriction statements shall be listed within pointed brackets (< and >) following the default value. If there are multiple
restrictions within a single set of angle brackets, then the restrictions shall be separated by a semicolon (;). A restriction
statement consists of the restriction name followed by a colon (:) followed by the restriction value or, where appropriate,
a comma-delimited list of possible values.

Here are some examples of property values with restriction statements as they could appear in the test database.

present-value: 13.4
description: "this is a description"
units: milliamperes
object-property-reference: (analog input, 12)

The Units property is a special case, because changing the units can change the value of the Present_Value property as
well as any restrictions on its value. Therefore, minimum, maximum, and resolution restrictions are only valid for the
default value of the Units property.

ISO/FDIS 16484-6:2008(E)
It is possible to specify default restrictions for most datatypes as described in 4.5.8. Restriction statements in the test
database override the default restrictions for the individual property that contains the restriction statement.
4.5 Sections of the EPICS File
Each section of the EPICS file begins with a section name followed by a colon ( : or X'3A'). After the colon is a set of
one or more parameters delimited by a set of curly braces ({ } or X'7B' X'7D').

The following symbols are used as placeholders to indicate the presence of parameter information:
(a) the open box symbol inside quotation marks, "‰", is used to indicate that a character string parameter shall be
present;
(b) the open box symbol with no quotation marks, ‰, is used to indicate that a parameter with a datatype other than
a character string shall be present;
(c) a question mark, ?, is used in the test database to indicate that the property is present but the value is unknown
because it depends on hardware input or is being changed by an internal algorithm.

An example EPICS file may be found in Annex A.
4.5.1 General Information Sections
These sections provide general information about the BACnet device. The syntax for these sections is shown below.

Vendor Name: "‰"↵
Product Name: "‰"↵
Product Model Number: "‰"↵
Product Description: "‰"↵
4.5.2 Conformance Sections
These sections provide information about the BACnet functionality that the device claims to support.
4.5.2.1 BIBBs Supported
This section indicates which BIBBs are supported. The syntax is shown below. Each BIBB shall be listed, one per line
between the curly braces. An empty list indicates that no BIBBs are supported.

BIBBs Supported: ↵
{↵
‰↵
}↵
The BIBBs may be any of:
DS-RP-A DS-RP-B
DS-RPM-A DS-RPM-B
DS-RPC-A DS-RPC-B
DS-WP-A DS-WP-B
DS-WPM-A DS-WPM-B
DS-COV-A DS-COV-B
DS-COVP-A DS-COVP-B
DS-COVU-A DS-COVU-B
AE-N-A AE-N-I-B AE-N-E-B
AE-ACK-A AE-ACK-B
AE-ASUM-A AE-ASUM-B
AE-ESUM-A AE-ESUM-B
AE-INFO-A AE-INFO-B
AE-LS-A AE-LS-B
SCHED-A SCHED-I-B SCHED-E-B
T-VMT-A T-VMT-I-B T-VMT-E-B
T-ATR-A T-ATR-B
DM-DDB-A DM-DDB-B
DM-DOB-A DM-DOB-B
DM-DCC-A DM-DCC-B
DM-PT-A DM-PT-B
ISO/FDIS 16484-6:2008(E)
DM-TM-A DM-TM-B
DM-TS-A DM-TS-B
DM-UTC-A DM-UTC-B
DM-RD-A DM-RD-B
DM-BR-A DM-BR-B
DM-R-A DM-R-B
DM-LM-A DM-LM-B
DM-OCD-A DM-OCD-B
DM-VT-A DM-VT-B
NM-CE-A NM-CE-B
NM-RC-A NM-RC-B
4.5.3 Application Services Supported
This section indicates which standard application services are supported. The syntax is shown below. Each supported
service shall be listed between curly braces one service per line, followed by the words "Initiate" or "Execute" to indicate
whether the service can be initiated, executed, or both.

BACnet Standard Application Services Supported: ↵
{↵
‰ Initiate↵
‰ Execute↵
‰ Initiate Execute↵
}
The standard services may be any of:

AcknowledgeAlarm  RemoveListElement  ConfirmedTextMessage
ConfirmedCOVNotification  CreateObject   UnconfirmedTextMessage
UnconfirmedCOVNotification  DeleteObject  TimeSynchronization
ConfirmedEventNotification  ReadProperty   UTCTimeSynchronization
UnconfirmedEventNotification ReadPropertyConditional  Who-Has
GetAlarmSummary  ReadPropertyMultiple  I-Have
GetEnrollmentSummary  ReadRange   Who-Is
GetEventInformation  WriteProperty  I-Am
LifeSafetyOperation  WritePropertyMultiple  VT-Open
SubscribeCOV  DeviceCommunicationControl  VT-Close
SubscribeCOVProperty  ConfirmedPrivateTransfer  VT-Data
AtomicReadFile  UnconfirmedPrivateTransfer RequestKey
AtomicWriteFile  ReinitializeDevice  Authenticate
AddListElement
4.5.4 Object Types Supported
This section indicates which standard object types are supported. The syntax is shown below. Each supported object type
shall be listed between curly braces one object type per line, optionally followed by the words "Createable",
"Deleteable", or both to indicate that dynamic creation or deletion is supported.

Standard Object Types Supported: ↵
{↵
‰↵
‰ Createable↵
‰ Deleteable↵
‰ Createable Deleteable↵
}↵
The standard objects may be any of:

Access Door Binary Output Group Multi-state Value
Accumulator Binary Value Life Safety Point No
...

NORME ISO
INTERNATIONALE 16484-6
Deuxième édition
2009-03-15
Systèmes d'automatisation et de gestion
technique du bâtiment —
Partie 6:
Essais de conformité de la
communication de données
Building automation and control systems (BACS) —
Part 6: Data communication conformance testing

Numéro de référence
©
ISO 2009
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 [e-mail]
Web www.iso.org
Publié en Suisse
ii © ISO 2009 – Tous droits réservés

Sommaire Page
Avant-propos .vi
1 Domaine d'application .1
2 Relations entre la présente partie de l'ISO 16484 et la norme ANSI/ASHRAE 135.1-2007.1
3 Termes, définitions et termes abrégés.1
4 FORMAT DE FICHIER ÉLECTRONIQUE PICS.2
4.1 Codage des caractères .2
4.2 Structure des fichiers EPICS.3
4.3 Chaînes de caractères .4
4.4 Règles de notation pour les valeurs de paramètre.4
4.5 Sections du fichier EPICS.6
5 ESSAIS DE COHÉRENCE EPICS .37
6 CONVENTIONS RELATIVES À LA SPÉCIFICATION DES ESSAIS DE CONFORMITÉ
BACnet.38
6.1 Composants TCSL .39
6.2 Instructions TCSL.40
6.3 Dépendances temporelles.46
6.4 Références BACnet .47
7 ESSAIS DE PRISE EN CHARGE DE L'OBJET.47
7.1 Prise en charge de la lecture pour les propriétés dans la base de données d’essai.47
7.2 Prise en charge de l’écriture pour les propriétés dans la base de données d'essai .48
7.3 Essais des fonctionnalité des objets .49
8 ESSAIS DE LANCEMENT DES SERVICES D’APPLICATION.161
8.1 Essais de lancement du service AcknowledgeAlarm.161
8.2 Essais de lancement du service ConfirmedCOVNotification .162
8.3 Essais de lancement du service UnconfirmedCOVNotification .177
8.4 Essais de lancement du service ConfirmedEventNotification .180
8.5 Essais de lancement du service UnconfirmedEventNotification .231
8.6 Essais de lancement du service GetAlarmSummary .239
8.7 Essais de lancement du service GetEnrollmentSummary.240
8.8 Essais de lancement du service GetEventInformation .242
8.9 Essais de lancement du service LifeSafetyOperation.243
8.10 Essais de lancement du service SubscribeCOV.244
8.11 Essais de lancement du service SubscribeCOVProperty.245
8.12 Essais de lancement du service AtomicReadFile.246
8.13 Essais de lancement du service AtomicWriteFile.247
8.14 Essais de lancement du service AddListElement.248
8.15 Essais de lancement du service RemoveListElement.249
8.16 Essais de lancement du service CreateObject.250
8.17 Essais de lancement du service DeleteObject .251
8.18 Essais de lancement du service ReadProperty .251
8.19 Essais de lancement du service ReadPropertyConditional.252
8.20 Essais de lancement du service ReadPropertyMultiple.253
8.21 Essais de lancement du service ReadRange .254
8.22 Essais de lancement du service WriteProperty .256
8.23 Essais de lancement du service WritePropertyMultiple.257
8.24 Essais de lancement du service DeviceCommunicationControl .260
8.25 Essai de lancement du service ConfirmedPrivateTransfer.261
8.26 Essai de lancement du service UnconfirmedPrivateTransfer .262
8.27 Essais de lancement du service ReinitializeDevice.262
8.28 Essais de lancement du service ConfirmedTextMessage.263
8.29 Essais de lancement du service UnconfirmedTextMessage .265
8.30 Essais de lancement du service TimeSynchronization.266
8.31 Essais de lancement du service UTCTimeSynchronization .266
8.32 Essais de lancement du service Who-Has.267
8.33 Essais de lancement du service I-Have.268
8.34 Essais de lancement du service Who-Is .268
8.35 Essais de lancement du service I-Am.269
8.36 Essais de lancement du service VT-Open .269
8.37 Essais de lancement du service VT-Close.271
8.38 Essais de lancement du service VT-Data.273
8.39 Essais de lancement du service RequestKey.275
8.40 Essais de lancement du service Authenticate.276
9 ESSAIS D'EXÉCUTION DU SERVICE D'APPLICATION .281
9.1 Essais d'exécution du service AcknowledgeAlarm .282
9.2 Essais d'exécution du service ConfirmedCOVNotification.303
9.3 Essais d'exécution du service UnconfirmedCOVNotification.308
9.4 Essais d'exécution du service ConfirmedEventNotification.309
9.5 Essais d'exécution du service UnconfirmedEventNotification.311
9.6 Essais d'exécution du service GetAlarmSummary.311
9.7 Essais d'exécution du service GetEnrollmentSummary .312
9.8 Essais d'exécution du service EventInformation.319
9.9 Essai d'exécution du service SafetyOperation.322
9.10 Essais d'exécution du service SubscribeCOV .324
9.11 Essais d'exécution du service SubscribeCOVProperty .332
9.12 Essais d'exécution du service AtomicReadFile .344
9.13 Essais d'exécution du service AtomicWriteFile .353
9.14 Essais d'exécution du service AddListElement .369
9.15 Essais d'exécution du service RemoveListElement .373
9.16 Essais d'exécution du service CreateObject .376
9.17 Essais d'exécution du service DeleteObject.382
9.18 Essais d'exécution du service ReadProperty.384
9.19 Essais d'exécution du service ReadPropertyConditional .387
9.20 Essais d'exécution du service ReadPropertyMultiple .388
9.21 Essais d'exécution du service ReadRange.399
9.22 Essais d'exécution du service WriteProperty.403
9.23 Essais d'exécution du service WritePropertyMultiple .410
9.24 Essai d'exécution du service DeviceCommunicationControl.422
9.25 Essais d'exécution du service ConfirmedPrivateTransfer .430
9.26 Essais d'exécution du service UnconfirmedPrivateTransfer.431
9.27 Essais d'exécution du service ReinitializeDevice .431
9.28 Essais d'exécution du service ConfirmedTextMessage.434
9.29 Essais d'exécution du service UnconfirmedTextMessage.436
9.30 Essais d'exécution du service TimeSynchronization .436
9.31 Essais d'exécution du service UTCTimeSynchronization.438
9.32 Essais d'exécution du service Who-Has.439
9.33 Essais d'exécution du service Who-Is.447
9.34 Essais d'exécution du service VT-Open.452
9.35 Essais d'exécution du service VT-Close .454
9.36 Essais d'exécution du service VT-Data .456
9.37 Essai d'exécution du service RequestKey.456
9.38 Essais d'exécution du service Authenticate.459
9.39 Essai général de l'exécution d'un service.465
10 ESSAIS DE PROTOCOLE DE COUCHE RÉSEAU .467
10.1 Traitement des messages de couche application provenant de réseaux distants .467
10.2 Essais de fonctionnalité du routeur.467
10.3 Essais de fonctionnalité d'un semi-routeur .507
10.4 Essais B/IP PAD.518
iv © ISO 2009 – Tous droits réservés

10.5 Lancement des messages de couche réseau .520
11 ESSAIS DE PROTOCOLE DE COUCHE DE LIAISON LOGIQUE .522
11.1 Commande et réponse UI .523
11.2 Commande et réponse XID.523
11.3 Commande et réponse TEST.524
12 ESSAIS DES PROTOCOLES DE COUCHE DE LIAISON DE DONNÉES .525
12.1 Essais des états machineMS/TP.525
12.2 Essais états machine PTP .612
13 ESSAIS DE FONCTIONNALITE SPECIFIQUES .667
13.1 Segmentation.667
13.2 Time Master.680
13.3 Jeux de caractères .680
13.4 PDU malformées.681
13.5 Essais de proxy esclave .682
14 Essais de fonctionnalité BACnet/IP.686
14.1 Dispositif non-BBMD B/IP.687
14.2 Dispositif non-BBMD B/IP avec une application serveur.690
14.3 Broadcast Distribution Table .691
14.4 Foreign Device Table Operations (essais négatifs).695
14.5 BACnet Broadcast Management (sans tableau de dispositifs étrangers, ni Applications) .697
14.6 Foreign Device Management.698
14.7 Broadcast Management (BBMD, dispositifs étrangers, application locale).701
15 Rapport des résultats d’essai .707
ANNEXE A – EXEMPLE D’EPICS (INFORMATIVE).708

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'ISO 16484-6 a été élaborée par le comité technique ISO/TC 205, Conception de l'environnement intérieur
des bâtiments.
Cette deuxième édition annule et remplace la première édition (ISO 16484-6:2005), qui a fait l'objet d'une
révision technique.
L'ISO 16484 comprend les parties suivantes, présentées sous le titre général Systèmes d'automatisation et
de gestion technique du bâtiment:
⎯ Partie 2: Équipement
⎯ Partie 3: Fonctions
⎯ Partie 5: Protocole de communication de données
⎯ Partie 6: Essais de conformité de la communication de données
Une Partie 1, traitant de la spécification et mise en œuvre d'un projet, et une Partie 4, sur les applications,
sont en préparation.
vi © ISO 2009 – Tous droits réservés

NORME INTERNATIONALE ISO 16484-6:2009(F)

Systèmes d'automatisation et de gestion technique du
bâtiment —
Partie 6:
Essais de conformité de la communication de données
1 Domaine d'application
La présente partie de l'ISO 16484 définit une méthode normalisée permettant de vérifier qu’une mise en
œuvre du protocole BACnet fournit l’ensemble des fonctionnalités citées dans la Déclaration de conformité
d'une mise en œuvre de protocole (PICS) correspondante, conformément à la norme BACnet.
La présente partie de l'ISO 16484 fournit un ensemble complet de modes opératoires permettant de vérifier la
bonne mise en œuvre de chaque fonctionnalité citée dans une déclaration PICS BACnet, notamment
a) la prise en charge de chaque service BACnet déclaré, qu’il s’agisse d’un initiateur, d’un exécuteur ou des
deux,
b) la prise en charge de chaque type d’objet BACnet déclaré, y compris les propriétés requises et chaque
propriété facultative déclarée,
c) la prise en charge du protocole de couche réseau BACnet,
d) la prise en charge de chaque option de liaison de données déclarée, et
e) la prise en charge de toutes les fonctionnalités spéciales déclarées.
2 Relations entre la présente partie de l'ISO 16484
et la norme ANSI/ASHRAE 135.1-2007
La présente partie de l'ISO 16484 comprend, à partir de l’Article 4, la traduction en français de la norme
étasunienne ANSI/ASHRAE 135.1-2007, Method of Test for Conformance to BACnet, publiée par l’American
National Standards Institute et l’American Society of Heating, Refrigerating and Air-Conditioning Engineers.
3 Termes, définitions et termes abrégés
Pour les besoins du présent document, les termes, définitions et termes abrégés suivants s'appliquent.
3.1
réseau local
réseau auquel un dispositif BACnet est directement connecté
3.2
réseau distant
réseau accessible depuis un dispositif BACnet uniquement par l’intermédiaire d’au moins un routeur
3.3
base de données d’essai
base de données d'une fonctionnalité et d’objets BACnet créée en lisant le contenu d’une déclaration
électronique EPICS
BNF syntaxe de forme Backus-Naur (Backus-Naur Form syntax)
EPICS déclaration électronique de conformité d’une mise en œuvre de protocole (electronic protocol
implementation conformance statement)
IUT  mise en œuvre soumise à essai (implementation under test)
TCSL langage de script d’essai et de conformité (testing and conformance scripting language)
TD  dispositif d’essai (testing device)
TPI  informations de protocole textuelles (text protocol information)
4 FORMAT DE FICHIER ÉLECTRONIQUE PICS
Un fichier électronique de déclaration de conformité d’une mise en œuvre de protocole (EPICS) contient une
déclaration de conformité d’une mise en œuvre du protocole BACnet, exprimée sous la forme d’un texte
normalisé. Les fichiers EPICS sont des représentations lisibles par l’homme et par les machines de la mise en
œuvre d’objets et de services BACnet dans un dispositif donné. Les fichiers EPICS doivent utiliser l’extension
".TPI" (informations de protocole textuelles) et contenir des lignes de texte normal et éditable, composées de
codes de caractères de texte se terminant par des paires retour chariot/saut de ligne (X'0D', X'0A').
Les fichiers EPICS sont utilisés par des outils d’essai logiciel pour réaliser les essais définis dans la présente
norme et en interpréter les résultats. Un fichier EPICS doit accompagner tous les dispositifs soumis à essai
conformément aux procédures de la présente norme.
4.1 Codage des caractères
BACnet fournit toute une gamme de codages de caractères possibles. Les codages de caractères BACnet se
répartissent en trois groupes : les flux d’octets, de doubles octets et de quadruples octets. Les flux d’octets
représentent les caractères comme des valeurs d’octets simples. Dans certains cas, comme les caractères
DBCS de Microsoft et le code JIS C 6226, certaines valeurs d’octets indiquent qu’il convient que le deuxième
octet soit affiché avec l’octet de tête en tant que valeur simple, étendant ainsi la plage à plus de 256
caractères possibles. En revanche, les flux de doubles octets affichent des paires d’octets représentant des
caractères simples. Le codage ISO 10646 UCS-2 en constitue un exemple. Le premier octet, ou octet de tête,
de la paire est la partie de plus fort poids de cette valeur. Les flux de quadruples octets, comme les flux
ISO 10646 UCS-4, traitent simultanément les uplets de quatre octets, comme des caractères simples dont le
premier octet, ou octet de tête, est de plus fort poids.
Pour adapter les différents codages utilisables avec des descriptions de dispositif BACnet, les fichiers EPICS
commencent avec un en-tête qui permet à la fois d’identifier le fichier comme un fichier EPICS et d’identifier le
codage particulier utilisé. L’en-tête commence avec la chaîne "PICS #", où # est remplacé par un chiffre
représentant le jeu de caractères tel qu’indiqué au Tableau 4-1.
2 © ISO 2009 – Tous droits réservés

Tableau 4-1. Codes de jeux de caractères
code jeu de caractères
0 ANSI X3.4
1 Microsoft DBCS
2 JIS C 6226
3 ISO 10646 (UCS-4)
4 ISO 10646 (UCS-2)
5 ISO 8859-1
Un format de flux d'octets peut être reconnu en examinant les huit premiers octets du fichier EPICS. Selon le
codage ANSI X3.4 par exemple, ces huit octets contiennent : X'50' X'49' X'43' X'53' X'20' X'30' X'0D' X'0A'.
Ces octets représentent le texte "PICS 0" suivi d’un retour chariot et d’un saut de ligne.
Un format de flux de doubles octets peut être reconnu en examinant les 16 premiers octets du fichier EPICS.
Selon le codage ISO 10646 UCS-2, par exemple, ces 16 octets contiennent :
X'00' X'50' X'00' X'49' X'00' X'43' X'00' X'53'
X'00' X'20' X'00' X'34' X'00' X'0D' X'00' X'0A'
Ces octets représentent le texte "PICS 4" suivi d’un retour chariot et d’un saut de ligne.
Un format de flux de quadruples octets peut être reconnu en examinant les 32 premiers octets du fichier
EPICS. Selon l’ISO 10646 UCS-4, par exemple, ces 32 octets contiennent :
X'00' X'00' X'00' X'50' X'00' X'00' X'00' X'49'
X'00' X'00' X'00' X'43' X'00' X'00' X'00' X'53'
X'00' X'00' X'00' X'20' X'00' X'00' X'00' X'33'
X'00' X'00' X'00' X'0D' X'00' X'00' X'00' X'0A'
Ces octets représentent le texte "PICS 3" suivi d’un retour chariot et d’un saut de ligne.
4.2 Structure des fichiers EPICS
Les fichiers EPICS sont composés de lignes de texte se terminant par des paires retour chariot/saut de ligne
(X'0D', X'0A') encodées comme des flux de simples, doubles ou quadruples octets, comme défini en 4.1.
Dans l'ensemble de la présente norme, le terme "caractère" est utilisé pour désigner un symbole codé sous la
forme d’un, deux ou quatre octets, basé sur le codage de caractères utilisé dans l’en-tête du fichier EPICS.
Par exemple, le caractère d’espacement peut être codé comme suit : X'20' ou X'0020' ou X'00000020'. Dans
la présente norme, tous les caractères sont présentés sous leur forme d’octet simple.
Le caractère spécial ↵ est utilisé dans le présent paragraphe pour indiquer la présence d’une paire retour
chariot/saut de ligne (X'0D0A'). Excepté dans les chaînes de caractères, les codes de caractères pour la
tabulation (X'09'), l’espace (X'20'), le retour chariot (X'0D') et le saut de ligne (X'0A') doivent être considérés
comme un blanc. Toute séquence d’1 caractère blanc ou plus doit être équivalente à un caractère blanc
unique. Excepté dans une chaîne de caractères, une séquence de deux tirets (X'2D') doit indiquer le début
d’un commentaire qui doit se terminer par la paire retour chariot/saut de ligne suivante, c’est-à-dire, la fin de la
ligne sur laquelle figurent les deux tirets (--). Les commentaires doivent être considérés comme un blanc et
peuvent donc être insérés librement.
Les fichiers EPICS doivent présenter, dans la première ligne suivant l’en-tête, le texte littéral :
Déclaration de conformité d’une mise en œuvre du protocole BACnet ↵
Ce texte sert de signature permettant d’identifier le format de fichier EPICS.
Les lignes définissant les sections de l’EPICS (voir en 4.5) et les données de mise en œuvre particulières à
un dispositif donné suivent la ligne de signature.
Le fichier EPICS se termine par une ligne contenant le texte littéral suivant :
Fin de la déclaration de conformité d’une mise en œuvre du protocole BACnet ↵
4.3 Chaînes de caractères
La présence d’un guillemet double (X'22'), d’un guillemet simple (X'27') ou d’un accent grave (X'60') doit
indiquer des chaînes de caractères. Pour les guillemets doubles, la fin de la chaîne doit être indiquée par
l’occurrence suivante d’un guillemet double ou par la fin de la ligne. Pour le guillemet simple ou l’accent grave,
la fin de la chaîne doit être indiquée par l’occurrence suivante d’un guillemet simple (X'27') ou par la fin de la
ligne. Ainsi, les chaînes qui nécessitent l’intégration d’un guillemet simple ou d’un accent grave comme
caractère littéral dans la chaîne doivent utiliser le mode de notation par guillemet double, tandis que les
chaînes qui nécessitent l’intégration d’un guillemet double doivent utiliser le mode de notation par guillemet
simple ou accent grave.
4.4 Règles de notation pour les valeurs de paramètre
Dans chaque section, il peut s’avérer nécessaire d’exprimer des paramètres sous une forme particulière,
parmi de nombreuses formes possibles. Les règles suivantes régissent le format applicable aux paramètres :
(a) les mots clés sont insensibles à la casse, de telle sorte que les codes X'41' à X'5A' sont équivalents
aux codes X'61' à X'7A' ;
(b) les valeurs nulles sont indiquées par la chaîne "NULL" ;
(c) les valeurs booléennes sont indiquées par les chaînes "T" ou "TRUE" si la valeur est vraie, ou "F" ou
"FALSE" si la valeur est fausse ;
(d) les valeurs entières sont indiquées comme des chaînes de chiffres, éventuellement avec un moins (-)
en tête : 12345 ou -111 ;
(e) les valeurs réelles sont indiquées par un signe décimal, qui ne peut pas être le premier ni le dernier
caractère : 1.23, 0.02, 1.0, mais pas .02 ;
(f) les chaînes d’octets sont indiquées par des paires de chiffres hexadécimaux entourées soit par des
guillemets simples (X'2D') soit par des accents graves (X'60') et précédées de la lettre "X" :
X'001122' ;
(g) les chaînes de caractères sont représentées par au moins un caractère entouré par des guillemets
doubles ou simples ou des accents graves, comme défini en 4.3 : 'text' ou 'text' ou "text" ;
(h) les bitstrings (chaînes de bits) sont indiquées sous forme de liste, entourées d’accolades ({ } ou X'7B'
et X'7D'), de valeurs vraies et fausses : {T,T,F} ou {TRUE, TRUE, FALSE}. Lorsque la valeur réelle
d’un bit ne présente pas d’importance, un point d’interrogation est utilisé : {T,T,?} ;
(i) les valeurs d’énumération sont représentées comme des valeurs nommées, plutôt que numériques.
Les noms des énumérations sont insensibles à la casse de telle sorte que les codes X'41' à X'5A'
sont équivalents aux codes X'61' à X'7A'. Le trait de soulignement (X'5F') et le tiret (X'2D') sont
considérés comme équivalents dans les noms d’énumérations. Les valeurs propriétaires sont
4 © ISO 2009 – Tous droits réservés

indiquées par un texte nommé sans espace, se terminant par une valeur numérique décimale non
négative. Chaque valeur doit commencer par le mot "proprietary" : Object_Type, proprietary-object-
type-653 ;
(j) les dates sont représentées entre parenthèses : (Monday, 24-January-1998). Tous les "caractères
génériques" ou champs non spécifiés sont signalés par un astérisque (X'2A'): (Monday, *-January-
1998). L’omission du jour de la semaine signifie que le jour est non spécifié : (24-January-1998) ;
(k) les valeurs temporelles sont représentées en heures, minutes, secondes, centièmes de secondes,
sous le format hh:mm:ss.xx: 2:05:44.00, 16:54:59.99. Tous les champs de "caractères génériques"
sont signalés par un astérisque (X'2A'): 16:54:*.*;
(l) les identifiants d’objets sont représentés entre parenthèses, avec des virgules séparant le type d’objet
et le numéro d’instance : (analog-input, 56). Les types d’objets propriétaires remplacent l’énumération
du type d’objet par le mot "proprietary" suivi de la valeur numérique du type d’objet : (proprietary
700,1);
(m) les éléments de données calculés sont représentés entre accolades ({ } ou X'7B' et X'7D'), les
éléments étant séparés par des virgules. Si un élément est lui-même une valeur calculée, cet élément
doit être entre accolades.
4.4.1 Valeurs de paramètres complexes
Certaines valeurs de paramètres, notamment les valeurs de propriété pour les valeurs codées calculées ou
de type CHOICE, nécessitent une notation plus complexe pour représenter leurs valeurs. La notation est liée
au codage ASN.1 pour ces valeurs de propriété et peut sembler obscure hors contexte. Les règles
supplémentaires suivantes régissent la présentation de ces types de valeurs de paramètres :
(a) les valeurs correspondant à un CHOIX de valeurs étiquetées selon l’application sont représentées par
la valeur de l’élément choisi, codé comme décrit en 4.4 ;
(b) les valeurs correspondant à un CHOIX de valeurs étiquetées selon le contexte sont représentées par
le numéro de l’étiquette de contexte entre crochets, suivi de la représentation de la valeur de
l’élément choisi ;
(c) les valeurs de liste (ASN.1 "SEQUENCE OF") sont représentées entre parenthèses, les éléments de
la liste étant séparés par des virgules. Si un élément est lui-même une valeur calculée, cet élément
doit figurer entre accolades ;
(d) les valeurs de tableaux sont représentées entre accolades, les éléments du tableau étant séparés par
des virgules. Si un élément est lui-même une valeur calculée, cet élément doit figurer entre
accolades.
4.4.2 Limites de spécification applicables aux valeurs de paramètres
Certaines propriétés peuvent présenter des restrictions en termes de plage ou de résolution des valeurs. Afin
d’interpréter correctement les résultats des essais pour lesquels la valeur d’une propriété est modifiée à l’aide
de WriteProperty, WritePropertyMultiple ou AddListElement et d’analyser ensuite ces essais à l’aide de
ReadProperty ou ReadPropertyMultiple, il est nécessaire de connaître ces restrictions. La base de données
d’essai peut comporter des instructions de restriction qui définissent ces contraintes. Les restrictions
acceptables et les types de données auxquels elles s’appliquent sont :
(a) minimum - valeur minimale des types de données Unsigned (non signé), Integer (nombre entier),
Real (réel) ou Double. La date la plus éloignée dans le temps pour le type de données Date ;
(b) maximum - valeur maximale des types de données Unsigned, Integer, Real ou Double. La date la
plus proche dans le temps pour le type de données Date ;
(c) resolution - résolution minimale garantie pour les types de données Real et Double. Résolution
temporelle minimale en secondes pour le type de données Time (heure) ;
(d) maximum length string – longueur maximale d’un CharacterString ou OctetString ;
(e) maximum length list - nombre maximal d’éléments garantis dans une liste ;
(f) maximum length array - nombre maximal d’éléments dans un tableau ;
(g) allowed values - liste d’énumérations, séparées par une virgule, prises en charge pour un type de
données Enumerated (énumération). Liste de types d’objets, délimités par une virgule, pour les
propriétés qui font référence à un identificateur d’objet externe.
Les instructions de restriction doivent être énumérées entre crochets en chevron (< et >) à la suite de la
valeur par défaut. Si des restrictions multiples figurent dans un ensemble unique de crochets obliques, les
restrictions doivent être séparées par un point-virgule (;). Une instruction de restriction est composée du nom
de la restriction suivi du signe deux-points (:) suivi de la valeur de restriction ou, le cas échéant, d’une liste de
valeurs possibles délimitées par une virgule.
Voici des exemples de valeurs de propriété avec des instructions de restriction telles qu’elles pourraient
apparaître dans la base de données d’essai.
present-value: 13.4
description: "this is a description"
units: milliamperes
object-property-reference: (analog input, 12)
La propriété Units est un cas particulier, car la modification des unités peut entraîner une modification de la
valeur de la propriété Present_Value comme de toutes les restrictions de sa valeur. Ainsi, les restrictions
minimum, maximum et resolution sont uniquement valables pour la valeur par défaut de la propriété Units.
Il est possible de spécifier les restrictions par défaut pour la plupart des types de données tels que décrit en
4.5.8. Les instructions de restriction dans la base de données d’essai annulent les restrictions par défaut pour
la propriété individuelle qui contient l’instruction de restriction.
4.5 Sections du fichier EPICS
Chaque section du fichier EPICS commence par un nom de section suivi du signe deux-points ( : ou X'3A').
Après les deux-points figure un ensemble d’au moins un paramètre, délimité par un ensemble d’accolades ({ }
ou X'7B' X'7D').
Les symboles suivants sont utilisés comme des paramètres fictifs pour signaler la présence d’informations de
paramètre :
(a) le symbole représentant un cadre entre guillemets, "‰", est utilisé pour indiquer qu’un paramètre de
chaîne de caractères doit être présent ;
(b) le symbole représentant un cadre sans guillemets, ‰, est utilisé pour indiquer qu’un paramètre d’un
type de données différent d’une chaîne de caractère doit être présent ;
(c) un point d’interrogation, ?, est utilisé dans la base de données d’essai pour indiquer que la propriété
est présente mais que la valeur est inconnue car elle dépend d’une entrée matérielle ou est modifiée
par un algorithme interne.
Un exemple de fichier EPICS peut être consulté dans l’annexe A.
6 © ISO 2009 – Tous droits réservés

4.5.1 Sections d’informations générales
Ces sections fournissent des informations générales sur le dispositif BACnet. La syntaxe de ces sections est
indiquée ci-dessous.
Vendor Name: "‰"↵
Product Name: "‰"↵
Product Model Number: "‰"↵
Product Description: "‰"↵
4.5.2 Sections de conformité
Ces sections fournissent des informations sur la fonctionnalité BACnet que le dispositif est censé prendre en
charge.
4.5.2.1 BIBB pris en charge
Cette section présente les BIBB (blocs d'interopérabilité BACnet) pris en charge. La syntaxe est indiquée
ci-dessous. Chaque BIBB doit être répertorié, un BIBB par ligne et entre accolades. Une liste vide signifie
qu’aucun BIBB n’est pris en charge.
BIBB pris en charge : ↵
{↵
‰↵
}↵
Les BIBB peuvent être :
DS-RP-A DS-RP-B
DS-RPM-A DS-RPM-B
DS-RPC-A DS-RPC-B
DS-WP-A DS-WP-B
DS-WPM-A DS-WPM-B
DS-COV-A DS-COV-B
DS-COVP-A DS-COVP-B
DS-COVU-A DS-COVU-B
AE-N-A AE-N-I-B AE-N-E-B
AE-ACK-A AE-ACK-B
AE-ASUM-A AE-ASUM-B
AE-ESUM-A AE-ESUM-B
AE-INFO-A AE-INFO-B
AE-LS-A AE-LS-B
SCHED-A SCHED-I-B SCHED-E-B
T-VMT-A T-VMT-I-B T-VMT-E-B
T-ATR-A T-ATR-B
DM-DDB-A DM-DDB-B
DM-DOB-A DM-DOB-B
DM-DCC-A DM-DCC-B
DM-PT-A DM-PT-B
DM-TM-A DM-TM-B
DM-TS-A DM-TS-B
DM-UTC-A DM-UTC-B
DM-RD-A DM-RD-B
DM-BR-A DM-BR-B
DM-R-A DM-R-B
DM-LM-A DM-LM-B
DM-OCD-A DM-OCD-B
DM-VT-A DM-VT-B
NM-CE-A NM-CE-B
NM-RC-A NM-RC-B
4.5.3 Services d’application pris en charge
Cette section présente les services d’application standard pris en charge. La syntaxe est indiquée ci-dessous.
Chaque service pris en charge doit être répertorié entre accolades, un service par ligne, suivi des mots
"Initiate" ou "Execute" pour indiquer que le service peut être initié, exécuté ou les deux.
Services d’application standard BACnet pris en charge : ↵
{↵
‰ Initiate↵
‰ Execute↵
‰ Initiate Execute↵
}
Les services standards BIBB peuvent être :
AcknowledgeAlarm RemoveListElement ConfirmedTextMessage
ConfirmedCOVNotification CreateObject UnconfirmedTextMessage
UnconfirmedCOVNotification DeleteObject TimeSynchronization
ConfirmedEventNotification ReadProperty UTCTimeSynchronization
UnconfirmedEventNotification ReadPropertyConditional Who-Has
GetAlarmSummary ReadPropertyMultiple I-Have
GetEnrollmentSummary ReadRange Who-Is
8 © ISO 2009 – Tous droits réservés

GetEventInformation WriteProperty I-Am
LifeSafetyOperation WritePropertyMultiple VT-Open
SubscribeCOV DeviceCommunicationControl VT-Close
SubscribeCOVProperty ConfirmedPrivateTransfer VT-Data
AtomicReadFile UnconfirmedPrivateTransfer RequestKey
AtomicWriteFile ReinitializeDevice Authenticate
AddListElement
4.5.4 Types d’objets pris en charge
Cette section présente les types d’objets standards pris en charge. La syntaxe est indiquée ci-dessous.
Chaque type d’objet pris en charge doit être répertorié entre accolades, un type d’objet par ligne,
éventuellement suivi des mots "Createable" (créable), "Deleteable" (supprimable) ou les deux, pour indiquer
que la création ou la destruction dynamique sont prises en charge.
Types d’objet standard pris en charge : ↵
{↵
‰↵
‰ Createable↵
‰ Deleteable↵
‰ Createable Deleteable↵
}↵
Les objets standards peuvent être l’un des objets suivants :
Access Door Binary Output Group Multi-state Value
Accumulator Binary Value Life Safety Point Notification Class
Analog Input Calendar Life Safety Zone Program
Analog Output Command Load Control Pulse Converter
Analog Value Device Loop Schedule
Averaging Event Enrollment Multi-state Input Structured View
Binary Input File Multi-state Output Trend Log
4.5.5 Options de couche de liaison de données
Cette section présente les options de couche de liaison de données standard prises en charge. La syntaxe
est indiquée ci-dessous. Chaque type de couche de liaison de données pris en charge doit être répertorié
entre accolades, un type de couche par ligne. Les liaisons de données MS/TP et point-à-point doivent
également spécifier le(s) débit(s) en bauds pris en charge.
...

NORME ISO
INTERNATIONALE 16484-6
Deuxième édition
2009-03-15
Systèmes d'automatisation et de gestion
technique du bâtiment —
Partie 6:
Essais de conformité de la
communication de données
Building automation and control systems (BACS) —
Part 6: Data communication conformance testing

Numéro de référence
©
ISO 2009
PDF – Exonération de responsabilité
Les fichiers PDF peuvent contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ils peuvent
être imprimés ou visualisés, mais ne doivent pas être modifiés à 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 fichiers PDF, 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 ou des fichiers PDF qui constituent cette publication sont
disponibles dans la rubrique General Info des fichiers; 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 ces fichiers 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.

Le présent CD-ROM contient la publication ISO 16484-6:2009 au format PDF (portable document format), qui
peut être visualisée en utilisant Adobe® Acrobat® Reader.
Adobe et Acrobat sont des marques déposées de Adobe Systems Incorporated.
Cette deuxième édition annule et remplace la première édition (ISO 16484-6:2005), qui a fait l'objet d'une
révision technique.
DOCUMENT PROTÉGÉ PAR COPYRIGHT

©  ISO 2009
Tous droits réservés. Sauf exigence particulière d'installation et sauf stipulation contraire, aucune partie de ce CD-ROM ne peut être
reproduite, enregistrée dans un système d'extraction ou transmise, sous quelque forme que ce soit et par aucun procédé, sans l'accord
préalable de l'ISO. Les demandes d'autorisation de reproduc
...