ISO/FDIS 16484-6
(Main)Building automation and control systems (BACS) — Part 6: Data communication conformance testing
Building automation and control systems (BACS) — Part 6: Data communication conformance testing
This standard 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.
Systèmes d'automatisation et de gestion technique du bâtiment (BACS) — Partie 6: Essais de conformité de la communication de données
Cette norme est configurée sur un ensemble complet de procédures permettant de vérifier la mise en œuvre correcte de chaque capacité revendiquée sur un PICS BACnet, y compris : (a) la prise en charge de chaque service BACnet revendiqué, soit en tant que lanceur, soit en tant qu'exécuteur, soit les deux, (b) la prise en charge de chaque type d'objet BACnet revendiqué, y compris les propriétés obligatoires et chaque propriété facultative revendiqué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 revendiquée, et (e) la prise en charge de toutes les fonctionnalités spéciales revendiquées.
General Information
- Status
- Not Published
- Technical Committee
- ISO/TC 205 - Building environment design
- Drafting Committee
- ISO/TC 205/WG 3 - Building Automation and Control System (BACS) Design
- Current Stage
- 5020 - FDIS ballot initiated: 2 months. Proof sent to secretariat
- Start Date
- 18-Nov-2025
- Completion Date
- 18-Nov-2025
Relations
- Effective Date
- 16-Oct-2025
Overview
ISO/FDIS 16484-6:2025 is an international standard developed by ISO Technical Committee 205, focused on Building Automation and Control Systems (BACS). Part 6 specifically addresses Data Communication Conformance Testing in BACS, providing a comprehensive framework to verify the correct implementation of BACnet communication capabilities. This standard ensures interoperability, reliability, and consistency in BACnet-enabled building automation systems by defining strict conformance testing procedures.
Key Topics
BACnet Protocol Capability Verification
The standard details methods for verifying every claimed BACnet capability as per the Protocol Implementation Conformance Statement (PICS). This includes:- Support for each BACnet service as an initiator or executor
- Verified handling of BACnet object types and their required and optional properties
- Proper operation of BACnet network layer protocols
- Validation of data link options to ensure compatibility
- Confirmation of claimed special functionalities within BACnet devices
Electronic PICS File Format
ISO/FDIS 16484-6 specifies the electronic format for PICS files, including character encoding, file structure, and notation rules. This supports automated testing and consistency checks.Comprehensive Test Coverage
The document includes exhaustive test cases covering:- Object support (read/write capabilities)
- Service initiation and execution tests for a broad spectrum of BACnet services like alarms, notifications, device communication, time synchronization, and file operations
- Consistency tests to ensure PICS accuracy
- Time dependency controls and BACnet-specific test conventions
Test Language and Tools
The standard adopts the Test Case Specification Language (TCSL) to define test components, statements, and execution considerations, streamlining automated test development and implementation.
Applications
Building Automation Device Manufacturers
Implement ISO/FDIS 16484-6 conformance testing to validate device BACnet functionality before market release, ensuring compliance and interoperability in smart buildings.System Integrators and Test Labs
Utilize the standard’s detailed test procedures to perform rigorous assessments of BACnet devices and systems, improving system reliability and reducing integration issues.Regulatory Bodies
Reference this standard when developing national or regional regulations for building automation systems to promote uniform communication protocols and standards compliance.Facility Managers
Gain assurance that BACnet-enabled devices within building automation networks comply with international communication standards, enhancing operational efficiency and system compatibility.
Related Standards
ISO 16484 Series
ISO/FDIS 16484-6 is part of the broader ISO 16484 family on Building Automation and Control Systems, providing a structured approach to design, communication, and control.BACnet Standard (ANSI/ASHRAE 135)
The BACnet standard defines the communication protocol for BACS, while ISO/FDIS 16484-6 focuses specifically on testing conformance against BACnet implementations.ISO/IEC 8802 Series
These standards cover data link layer protocols that may be referenced for network compatibility and conformance in BACnet communications.Testing and Certification Frameworks
Conformance testing as outlined in ISO/FDIS 16484-6 complements certification frameworks by providing repeatable and verifiable verification steps aligned with international practices.
Keywords: ISO 16484-6, BACS conformance, BACnet testing, building automation standards, data communication testing, BACnet PICS verification, BACnet service conformance, automated building control systems, BACnet interoperability, ISO building automation standards.
ISO/FDIS 16484-6 - Building automation and control systems (BACS) — Part 6: Data communication conformance testing Released:4. 11. 2025
ISO/FDIS 16484-6 - Systèmes d'automatisation et de gestion technique du bâtiment (BACS) — Partie 6: Essais de conformité de la communication de données Released:31. 12. 2025
Frequently Asked Questions
ISO/FDIS 16484-6 is a draft published by the International Organization for Standardization (ISO). Its full title is "Building automation and control systems (BACS) — Part 6: Data communication conformance testing". This standard covers: This standard 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.
This standard 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.
ISO/FDIS 16484-6 is classified under the following ICS (International Classification for Standards) categories: 35.240.67 - IT applications in building and construction industry; 91.040.01 - Buildings in general. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO/FDIS 16484-6 has the following relationships with other standards: It is inter standard links to ISO 16484-6:2024. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
ISO/FDIS 16484-6 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
FINAL DRAFT
International
Standard
ISO/TC 205
Building automation and control
Secretariat: ANSI
systems (BACS) —
Voting begins on:
2025-11-18
Part 6:
Data communication conformance
Voting terminates on:
2026-01-13
testing
Systèmes d'automatisation et de gestion technique du bâtiment
(BACS) —
Partie 6: Essais de conformité de la communication de données
This document is circulated as received from the committee secretariat.
FAST TRACK PROCEDURE
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 SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/CEN PARALLEL PROCESSING 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.
Reference number
FINAL DRAFT
International
Standard
ISO/TC 205
Building automation and control
Secretariat: ANSI
systems (BACS) —
Voting begins on:
Part 6:
Data communication
Voting terminates on:
conformance testing
Systèmes d'automatisation et de gestion technique du bâtiment
(BACS) —
Partie 6: Essais de conformité de la communication de données
This document is circulated as received from the committee secretariat.
FAST TRACK PROCEDURE
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 SUPPOR TING DOCUMENTATION.
© ISO 2025
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/CEN PARALLEL PROCESSING
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland Reference number
ii
CONTENTS
CLAUSE PAGE
FOREWORD . vi
1. PURPOSE . 1
2. SCOPE . 1
3. DEFINITIONS . 1
3.1 Terms Adopted from International Standardss . 1
3.2 Abbreviations and Acronyms Used in the Standard . 1
3.3 Common language used in tests . 1
4. ELECTRONIC PICS FILE FORMAT . 2
4.1 Character Encoding . 2
4.2 Structure of EPICS Files . 3
4.3 Character Strings . 3
4.4 Notational Rules for Parameter Values . 3
4.5 Sections of the EPICS File . 4
5. EPICS CONSISTENCY TESTS . 10
6. CONVENTIONS FOR SPECIFYING BACnet CONFORMANCE TESTS . 12
6.1 TCSL Components . 12
6.2 TCSL Statements . 13
6.3 Time Dependencies . 18
6.4 BACnet References . 19
6.5 TD Requirements . 19
6.6 Test Execution Considerations . 19
7. OBJECT SUPPORT TESTS . 21
7.1 Read Support for Properties in the Test Database . 21
7.2 Write Support for Properties in the Test Database . 23
7.3 Object Functionality Tests . 30
8. APPLICATION SERVICE INITIATION TESTS . 357
8.1 AcknowledgeAlarm Service Initiation Tests . 357
8.2 ConfirmedCOVNotification Service Initiation Tests . 359
8.3 UnconfirmedCOVNotification Service Initiation Tests . 374
8.4 ConfirmedEventNotification Service Initiation Tests . 379
8.5 UnconfirmedEventNotification Service Initiation Tests . 425
8.6 GetAlarmSummary Service Initiation Tests . 449
8.7 GetEnrollmentSummary Service Initiation Tests . 449
8.8 GetEventInformation Service Initiation Tests . 451
8.9 LifeSafetyOperation Service Initiation Tests . 452
8.10 SubscribeCOV Service Initiation Tests . 453
8.11 SubscribeCOVProperty Service Initiation Tests . 454
8.12 AtomicReadFile Service Initiation Tests . 459
8.13 AtomicWriteFile Service Initiation Tests . 459
8.14 AddListElement Service Initiation Tests . 460
8.15 RemoveListElement Service Initiation Tests . 460
8.16 CreateObject Service Initiation Tests . 461
8.17 DeleteObject Service Initiation Tests . 461
8.18 ReadProperty Service Initiation Tests . 462
8.19 ReadPropertyConditional Service Initiation Tests . 464
8.20 ReadPropertyMultiple Service Initiation Tests . 464
8.21 ReadRange Service Initiation Tests . 466
8.22 WriteProperty Service Initiation Tests . 470
8.23 WritePropertyMultiple Service Initiation Tests . 473
8.24 DeviceCommunicationControl Service Initiation Tests . 475
8.25 ConfirmedPrivateTransfer Service Initiation Test . 476
8.26 UnconfirmedPrivateTransfer Service Initiation Test . 476
8.27 ReinitializeDevice Service Initiation Tests . 477
8.28 ConfirmedTextMessage Service Initiation Tests . 477
8.29 UnconfirmedTextMessage Service Initiation Tests . 478
8.30 TimeSynchronization Service Initiation Tests . 479
8.31 UTCTimeSynchronization Service Initiation Tests . 479
8.32 Who-Has Service Initiation Tests . 479
iii
8.33 I-Have Service Initiation Tests . 481
8.34 Who-Is Service Initiation Tests . 481
8.35 I-Am Service Initiation Tests . 482
8.36 VT-Open Service Initiation Tests . 482
8.37 VT-Close Service Initiation Tests . 483
8.38 VT-Data Service Initiation Tests . 484
8.39 RequestKey Service Initiation Tests . 485
8.40 Authenticate Service Initiation Tests . 486
8.41 WriteGroup Service Initiation Tests . 489
8.42 SubscribeCOVPropertyMultiple Service Initiation Tests . 489
8.43 AuditLogQuery Initiation Tests. 493
8.44 Who-Am-I Service Initiation Tests . 494
8.45 You-Are Service Initiation Tests . 494
9. APPLICATION SERVICE EXECUTION TESTS . 497
9.1 AcknowledgeAlarm Service Execution Tests . 497
9.2 ConfirmedCOVNotification Service Execution Tests . 521
9.3 UnconfirmedCOVNotification Service Execution Tests . 526
9.4 ConfirmedEventNotification Service Execution Tests . 529
9.5 UnconfirmedEventNotification Service Execution Tests . 534
9.6 GetAlarmSummary Service Execution Tests . 535
9.7 GetEnrollmentSummary Service Execution Tests . 536
9.8 GetEventInformation Service Execution Tests . 539
9.9 LifeSafetyOperation Service Execution Test . 541
9.10 SubscribeCOV Service Execution Tests . 545
9.11 SubscribeCOVProperty Service Execution Tests . 555
9.12 AtomicReadFile Service Execution Tests . 566
9.13 AtomicWriteFile Service Execution Tests . 572
9.14 AddListElement Service Execution Tests . 581
9.15 RemoveListElement Service Execution Tests . 584
9.16 CreateObject Service Execution Tests . 585
9.17 DeleteObject Service Execution Tests . 590
9.18 ReadProperty Service Execution Tests . 591
9.19 ReadPropertyConditional Service Execution Tests . 595
9.20 ReadPropertyMultiple Service Execution Tests . 596
9.21 ReadRange Service Execution Tests . 605
9.22 WriteProperty Service Execution Tests . 618
9.23 WritePropertyMultiple Service Execution Tests . 626
9.24 DeviceCommunicationControl Service Execution Test . 641
9.25 ConfirmedPrivateTransfer Service Execution Tests . 648
9.26 UnconfirmedPrivateTransfer Service Execution Tests . 649
9.27 ReinitializeDevice Service Execution Tests . 649
9.28 ConfirmedTextMessage Service Execution Tests . 652
9.29 UnconfirmedTextMessage Service Execution Tests . 653
9.30 TimeSynchronization Service Execution Tests . 654
9.31 UTCTimeSynchronization Service Execution Tests . 655
9.32 Who-Has Service Execution Tests . 655
9.33 Who-Is Service Execution Tests . 662
9.34 VT-Open Service Execution Tests . 665
9.35 VT-Close Service Execution Tests . 666
9.36 VT-Data Service Execution Tests . 667
9.37 RequestKey Service Execution Test . 668
9.38 Authenticate Service Execution Tests . 669
9.39 General Testing of Service Execution . 673
9.40 AuditLogQuery Service Execution Tests . 674
9.41 WriteGroup Tests . 676
9.42 SubscribeCOVPropertyMultiple Service Execution Tests . 679
9.43 Who-Am-I Service Execution Tests . 693
9.44 You-Are Service Execution Tests . 695
10. NETWORK LAYER PROTOCOL TESTS . 702
10.1 General Network Layer Tests . 702
10.2 Router Functionality Tests . 703
iv
10.3 Half-Router Functionality Tests . 730
10.4 B/IP PAD Tests . 737
10.5 Initiating Network Layer Messages . 739
10.6 Non-Router Functionality Tests . 740
10.7 Route Binding Tests . 742
10.8 Virtual Routing Functionality Tests . 747
11. LOGICAL LINK LAYER PROTOCOL TESTS . 766
11.1 UI Command and Response . 766
11.2 XID Command and Response . 766
11.3 TEST Command and Response . 767
12. DATA LINK LAYER PROTOCOLS TESTS . 768
12.1 MS/TP State Machine Tests . 768
12.2 PTP State Machine Tests . 827
12.3 BACnet/IP Functionality Tests . 859
12.4 BACnet/IPv6 Functionality Tests . 890
12.5 Secure Connect Functionality Tests . 905
13. SPECIAL FUNCTIONALITY TESTS . 965
13.1 Segmentation . 965
13.2 Time Manager . 973
13.3 Character Sets . 977
13.4 Malformed PDUs . 978
13.5 Subordinate Proxy Tests . 979
13.6 Automatic Network Mapping . 981
13.7 Automatic Device Mapping . 981
13.8 Backup and Restore Procedure Tests . 982
13.9 Application State Machine Tests . 995
13.10 Workstation Scheduling Tests . 996
13.11 BACnet/SC Certificate Replacement Tests . 1013
14. Reporting Test Results . 1020
ANNEX A – EXAMPLE EPICS (INFORMATIVE) . 1021
HISTORY OF REVISIONS . 1039
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.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
ISO document should be noted (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent rights
in respect thereof. As of the date of publication of this document, ISO had not received notice of (a) patent(s)
which may be required to implement this document. However, implementers are cautioned that this may not
represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO’s adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 205, Building environmental design, in
collaboration with the European Committee for Standardization (CEN) Technical Committee CEN/TC 247,
Building Automation, Controls and Building Management, in accordance with the Agreement on technical
cooperation between ISO and CEN (Vienna Agreement) and with the American Society of Heating,
Refrigerating and Air-Conditioning Engineers, Inc. (ASHRAE).
This sixth edition cancels and replaces the fifth edition (ISO 16484-6:2024), which has been technically
revised.
The main changes are as follows:
— see the detailed list of changes on pages 1039 to 1043.
A list of all parts in the ISO 16484 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
vi
1. PURPOSE
1. PURPOSE
To define 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.
2. SCOPE
This standard 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.
3. DEFINITIONS
All definitions from ANSI/ASHRAE Standard 135-2020 also apply to this addendum.
3.1 Terms Adopted from International Standardss
local network: the network to which a BACnet device is directly connected.
remote network: a network that is accessible from a BACnet device only by passing through one or more routers.
test database: a database of BACnet functionality and objects created by reading the contents of an EPICS.
3.2 Abbreviations and Acronyms Used in the Standard
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
3.3 Common language used in tests
'any valid value': Any valid value refers to any value of the correct data type and within the vendor's range specified for the
property this is applied to.
'any appropriate password': Any password that meets the Configuration Requirements specified in the test or test section.
Passwords when required by the vendor are required to be no more than 20 characters.
'reset': Some tests require to reset the IUT. Reset includes power cycle via switch, power cycle via loss of power, and
reinitializeDevice WARMSTART. As defined by the BACnet standard, "WARMSTART shall mean to reboot the device and
start over, retaining all data and programs that would normally be retained during a brief power outage."
4. ELECTRONIC PICS FILE FORMAT
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 ISO 10646 (UTF-8)
1 IBM™/Microsoft™ DBCS
2 JIS X 0208
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. ELECTRONIC PICS FILE FORMAT
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. ELECTRONIC PICS FILE FORMAT
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 extern
...
PROJET FINAL
Norme
internationale
ISO/TC 205
Systèmes d'automatisation et de
Secrétariat: ANSI
gestion technique du bâtiment
Début de vote:
(BACS) —
2025-11-18
Partie 6:
Vote clos le:
2026-01-13
Essais de conformité de la
communication de données
Building automation and control systems (BACS) —
Part 6: Data communication conformance testing
Le présent document est distribué tel qu’il est parvenu du secrétariat
du comité.
LES DESTINATAIRES DU PRÉSENT PROJET SONT
INVITÉS À PRÉSENTER, AVEC LEURS OBSERVATIONS,
NOTIFICATION DES DROITS DE PROPRIÉTÉ DONT ILS
AURAIENT ÉVENTUELLEMENT CONNAISSANCE ET À
FAST TRACK PROCEDURE
FOURNIR UNE DOCUMENTATION EXPLICATIVE.
OUTRE LE FAIT D’ÊTRE EXAMINÉS POUR
ÉTABLIR S’ILS SONT ACCEPTABLES À DES FINS
INDUSTRIELLES, TECHNOLOGIQUES ET COM-MERCIALES,
AINSI QUE DU POINT DE VUE DES UTILISATEURS, LES
PROJETS DE NORMES
TRAITEMENT PARALLÈLE ISO/CEN
INTERNATIONALES DOIVENT PARFOIS ÊTRE CONSIDÉRÉS
DU POINT DE VUE DE LEUR POSSI BILITÉ DE DEVENIR DES
NORMES POUVANT
SERVIR DE RÉFÉRENCE DANS LA RÉGLEMENTATION
NATIONALE.
Numéro de référence
PROJET FINAL
Norme
internationale
ISO/TC 205
Systèmes d'automatisation et de
Secrétariat: ANSI
gestion technique du bâtiment
Début de vote:
(BACS) —
2025-11-18
Partie 6:
Vote clos le:
2026-01-13
Essais de conformité de la
communication de données
Building automation and control systems (BACS) —
Part 6: Data communication conformance testing
Le présent document est distribué tel qu’il est parvenu du secrétariat
du comité.
LES DESTINATAIRES DU PRÉSENT PROJET SONT
INVITÉS À PRÉSENTER, AVEC LEURS OBSERVATIONS,
NOTIFICATION DES DROITS DE PROPRIÉTÉ DONT ILS
AURAIENT ÉVENTUELLEMENT CONNAISSANCE ET À
FAST TRACK PROCEDURE
FOURNIR UNE DOCUMENTATION EXPLICATIVE.
DOCUMENT PROTÉGÉ PAR COPYRIGHT
OUTRE LE FAIT D’ÊTRE EXAMINÉS POUR
ÉTABLIR S’ILS SONT ACCEPTABLES À DES FINS
© ISO 2025 INDUSTRIELLES, TECHNOLOGIQUES ET COM-MERCIALES,
AINSI QUE DU POINT DE VUE DES UTILISATEURS, LES
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
PROJETS DE NORMES
TRAITEMENT PARALLÈLE ISO/CEN
INTERNATIONALES DOIVENT PARFOIS ÊTRE CONSIDÉRÉS
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
DU POINT DE VUE DE LEUR POSSI BILITÉ DE DEVENIR DES
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
NORMES POUVANT
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
SERVIR DE RÉFÉRENCE DANS LA RÉGLEMENTATION
NATIONALE.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse Numéro de référence
ii
TABLE DES MATIÈRES
article PAGE
AVANT-PROPOS . vii
1. OBJET . 1
2. domaine d'application . 1
3. DÉFINITIONS . 1
3.1 Termes adoptés à partir des normes internationales . 1
3.2 Abréviations et acronymes utilisés dans la norme . 1
3.3 Langage commun utilisé dans les essais . 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 . 3
4.4 Règles de notation pour les valeurs de paramètres . 3
4.5 Sections du fichier EPICS . 5
5. ESSAI DE COHÉRENCE EPICS . 12
6. CONVENTIONS POUR SPÉCIFIER LES ESSAIS DE CONFORMITÉ BACnet . 14
6.1 Composants TCSL . 14
6.2 Instructions TCSL . 15
6.3 Dépendances temporelles . 21
6.4 Références BACnet . 23
6.5 Exigences TD . 23
6.6 Considérations relatives à l'exécution des essais . 23
7. ESSAI DE PRISE EN CHARGE DES OBJETS . 25
7.1 Prise en charge de la lecture des propriétés dans la base de données soumise à l'essai . 25
7.2 Prise en charge de l'écriture pour les propriétés dans la base de données soumise à l'essai . 27
7.3 Essais de fonctionnalité des objets . 36
8. ESSAI DE LANCEMENT DU SERVICE D'APPLICATION . 445
8.1 Essais de lancement du service d'accusé de réception d'alarme . 445
8.2 Essais de lancement du service de notification COV confirmée . 448
8.3 Essais de lancement du service de notification COV non confirmée . 467
8.4 Essais de lancement du service de notification d'événements confirmés . 473
8.5 Essais de lancement du service Notification d'événement non confirmé . 533
8.6 Essais de lancement du service GetAlarmSummary. 566
8.7 Essais de lancement du service GetEnrollmentSummary . 566
8.8 Essais de lancement du service GetEventInformation . 568
8.9 Essais de lancement du service LifeSafetyOperation . 570
8.10 Abonnement Essais de lancement du service COV . 570
8.11 Essais de lancement du service SubscribeCOVProperty . 571
8.12 Essais de lancement du service AtomicReadFile . 577
8.13 Essais de lancement du service AtomicWriteFile . 578
8.14 Essais de lancement du service AddListElement . 578
8.15 Essais de lancement du service RemoveListElement . 579
8.16 Essais de lancement du service CreateObject . 579
8.17 Essais de lancement du service DeleteObject . 580
8.18 Essais de lancement du service ReadProperty . 581
8.19 Essais de lancement du service ReadPropertyConditional . 583
8.20 Essais d'initialisation du service ReadPropertyMultiple . 584
8.21 Essais de lancement du service ReadRange. 587
8.22 Essais de lancement du service WriteProperty . 591
8.23 Essais de lancement du service WritePropertyMultiple . 595
8.24 Essais de lancement du service DeviceCommunicationControl . 598
8.25 Essai de lancement du service ConfirmedPrivateTransfer . 599
8.26 Essai de lancement du service de transfert privé non confirmé . 599
8.27 Essais de lancement du service de ReinitializeDevice . 600
8.28 Essais de lancement du service ConfirmedTextMessage . 601
8.29 Essais de lancement du service UnconfirmedTextMessage . 602
8.30 Essais de lancement du service TimeSynchronization . 603
iii
8.31 Essais de lancement du service UTCTimeSynchronization . 603
8.32 Essais de lancement du service Who-Has . 603
8.33 Essais de lancement du service I-Have . 605
8.34 Essais de lancement du service Who-Is . 605
8.35 Essais de lancement du service I-Am . 606
8.36 Essais de lancement du service VT-Open . 606
8.37 Essais de lancement du service VT-Close . 607
8.38 VT-Essais de lancement du service de données . 609
8.39 Essais de lancement du service RequestKey . 610
8.40 Essais de lancement du service Authenticate . 611
8.41 Essais de lancement du service WriteGroup . 615
8.42 Essais de lancement du service SubscribeCOVPropertyMultiple . 615
8.43 Essais de lancement AuditLogQuery . 621
8.44 Essais de lancement du service Who-Am-I . 621
8.45 Essais de lancement du service You-Are . 622
9. ESSAI D'EXÉCUTION DU SERVICE D'APPLICATION . 625
9.1 Essais d'exécution du service AcknowledgeAlarm . 625
9.2 Essais d'exécution du service de notification confirmée COV . 656
9.3 Essais d'exécution du service UnconfirmedCOVNotification . 663
9.4 Essais d'exécution du service ConfirmedEventNotification . 667
9.5 Essais d'exécution du service UnconfirmedEventNotification . 672
9.6 Essais d'exécution du service GetAlarmSummary . 674
9.7 Essais d'exécution du service GetEnrollmentSummary . 675
9.8 Essais d'exécution du service GetEventInformation . 680
9.9 Soumettre à l'essai du service LifeSafetyOperation Service Execution . 682
9.10 Essais d'exécution du service SubscribeCOV . 687
9.11 Abonnez-vous aux essais d'exécution des services COVProperty . 699
9.12 Essais d'exécution du service AtomicReadFile . 713
9.13 Essais d'exécution du service AtomicWriteFile . 721
9.14 Essais d'exécution du service AddListElement . 735
9.15 Essais d'exécution du service RemoveListElement . 738
9.16 Essais d'exécution du service CreateObject . 741
9.17 Essais d'exécution du service DeleteObject . 747
9.18 Essais d'exécution du service ReadProperty . 748
9.19 Essais d'exécution du service ReadPropertyConditional . 753
9.20 Essais d'exécution du service ReadPropertyMultiple . 754
9.21 Essais d'exécution du service ReadRange . 767
9.22 Essais d'exécution du service WriteProperty . 784
9.23 Essais d'exécution du service WritePropertyMultiple . 793
9.24 Soumettre à l'essai d'exécution du service DeviceCommunicationControl . 813
9.25 Essais d'exécution du service ConfirmedPrivateTransfer . 822
9.26 Essais d'exécution du service de transfert privé non confirmé . 824
9.27 Essais d'exécution du service ReinitializeDevice . 824
9.28 Essais d'exécution du service ConfirmedTextMessage . 828
9.29 Essais d'exécution du service UnconfirmedTextMessage . 829
9.30 Essais d'exécution du service TimeSynchronization . 830
9.31 Essais d'exécution du service UTCTimeSynchronization . 831
9.32 Essais d'exécution du service Who-Has . 832
9.33 Essais d'exécution du service Who-Is . 840
9.34 Essais d'exécution du service VT-Open . 843
9.35 Essais d'exécution du service VT-Close . 845
9.36 Essais d'exécution du service VT-Data . 846
9.37 Soumettre à l'essai d'exécution du service RequestKey . 846
9.38 Soumettre à l'essai d'exécution du service Authenticate . 849
9.39 Soumettre à l'essai général de l'exécution du service. 853
9.40 Essais d'exécution du service AuditLogQuery . 854
9.41 Essais WriteGroup . 856
9.42 Essais d'exécution du service SubscribeCOVPropertyMultiple . 861
9.43 Essais d'exécution du service Who-Am-I . 879
iv
9.44 Essais d'exécution du service « You-Are » . 881
10. ESSAI DE PROTOCOLE DE COUCHE RÉSEAU . 889
10.1 Essais généraux de la couche réseau . 889
10.2 Essais de fonctionnalité des routeurs . 890
10.3 Essais de fonctionnalité des demi-routeurs . 925
10.4 B/IP PAD soumis à l'essai . 933
10.5 Lancer de messages de couche réseau . 934
10.6 Essais de fonctionnalité non routeur . 937
10.7 Essais de liaison d'itinéraire . 939
10.8 Essais de fonctionnalité de routage virtuel . 944
11. ESSAI DU PROTOCOLE DE COUCHE LOGIQUE DE LIAISON . 969
11.1 Commande et réponse UI . 969
11.2 Commande et réponse XID . 969
11.3 Commande et réponse à l'essai . 970
12. ESSAIER DES PROTOCOLES DE LA COUCHE LIEN DE DONNÉES . 972
12.1 Machine à états MS/TP soumise à l'essai . 972
12.2 Machine à états PTP soumises à l'essai . 1045
12.3 BACnet/IP Fonctionnalité Essais . 1087
12.4 Essais de fonctionnalité BACnet/IPv6 . 1125
12.5 Essais de fonctionnalité Secure Connect . 1143
13. ESSAI DE FONCTIONNALITÉ SPÉCIALES . 1219
13.1 Segmentation . 1219
13.2 Gestionnaire de temps . 1230
13.3 Jeux de caractères . 1235
13.4 PDU malformées . 1235
13.5 Essais de proxy subordonné. 1236
13.6 Mappage automatique du réseau . 1239
13.7 Mappage automatique des appareils . 1240
13.8 Soumettre à l'essai la procédure de sauvegarde et de restauration . 1240
13.9 Essais de la machine à états de l'application . 1256
13.10 Essais de programmateur de postes de travail . 1257
13.11 Essais de remplacement de certificats BACnet/SC . 1278
14. Consignation des résultats des essais . 1286
ANNEXE A – EXEMPLE D'EPICS (À TITRE INFORMATIF) . 1287
HISTORIQUE DES RÉVISIONS . 1316
v
Avant-propos
L'ISO (Organisation internationale de norme) est une fédération mondiale d'organismes nationaux de normes
(organismes membres de l'ISO). Le travail de préparation des normes internationales est normalement effectué par
les comités techniques de l'ISO. Chaque organisme membre intéressé par un sujet pour lequel un comité technique a
été créé a le droit d'être représenté au sein de ce comité. Des organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO, participent également à ce travail. L'ISO collabore étroitement avec la
Commission électrotechnique internationale (CEI) pour toutes les questions relatives à la normalisation
électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles prévues pour sa mise à jour sont décrites dans
les Directives ISO/CEI, Partie 1. Il convient notamment de noter les différents critères d'approbation requis pour les
différents types de documents ISO (voir www.iso.org/directives).
L'ISO attire l'attention sur la possibilité que la mise en œuvre du présent document implique l'utilisation d'un ou
plusieurs brevets. L'ISO ne se prononce pas sur la preuve, la validité ou l'applicabilité des droits de brevet
revendiqués à cet égard. À la date de publication du présent document, l'ISO n'avait reçu aucune notification
concernant un ou plusieurs brevets qui pourraient être nécessaires à la mise en œuvre du présent document. Toutefois,
les utilisateurs sont avertis que ces informations ne sont peut-être pas les plus récentes, lesquelles peuvent être
obtenues à partir de la base de données sur les brevets disponible à l'adresse www.iso.org/patents. L'ISO ne saurait
être tenue responsable de l'identification de tout ou partie de ces droits de brevet.
Tout nom commercial utilisé dans le présent document est fourni à titre d'information pour la commodité des
utilisateurs et ne constitue pas une recommandation.
Pour obtenir des explications sur la nature volontaire des normes, la signification des termes et expressions
spécifiques à l'ISO liés à l'évaluation de la conformité, ainsi que des informations sur le respect par l'ISO des
principes de l'Organisation mondiale du commerce (OMC) dans les obstacles techniques au commerce (OTC),
consultez le site www.iso.org/iso/foreword.html.
Le présent document a été préparé par le Comité technique ISO/TC 205, Concepteur d'environnement des
bâtiments, en collaboration avec le Comité technique CEN/TC 247, Automatisation, régulation et gestion
technique du bâtiment, du Comité européen de normalisation (CEN), conformément à l'accord de coopération
technique entre l'ISO et le CEN (accord de Vienne) et avec l'American Society of Heating, Refrigerating and Air-
Conditioning Engineers, Inc. (ASHRAE).
Cette sixième édition annule et remplace la cinquième édition (ISO 16484-6:2024), qui a été
révisée sur le plan technique. Les principales modifications sont les suivantes :
— voir le répertorier détaillé des modifications aux pages 1039 à 1043.
Le répertoire de toutes les parties de la série ISO 16484 est disponible sur le site web de l'ISO.
Toute remarque ou question concernant le présent document doit être adressée à l'organisme national de norme de
l'utilisateur. La liste complète de ces organismes est disponible à l'adressewww.iso.org/members.html .
vii
PROJET FINAL Norme internationale ISO/FDIS 16484-6:2025(fr)
1. OBJET
Définir une méthode norme permettant de vérifier qu'une implémentation du protocole BACnet offre toutes les
fonctionnalités revendiquées dans sa déclaration de conformité d'implémentation du protocole (PICS) dans la
conformité à la norme BACnet.
2. domaine d'application
Cette norme fournit un ensemble complet de procédures permettant de vérifier la mise en œuvre correcte de chaque
fonctionnalité revendiquée dans une PICS BACnet, notamment :
(a) prendre en charge chaque service BACnet revendiqué, en tant que lanceur, exécuteur ou les deux,
(b) prise en charge de chaque type d'objet BACnet revendiqué, y compris les propriétés requises et chaque propriété
optionnelle revendiquée,
(c) prise en charge du protocole de couche réseau BACnet,
(d) prise en charge de chaque option de liaison de données revendiquée, et
(e) prise en charge de toutes les fonctionnalités spéciales revendiquées.
3. DÉFINITIONS
Toutes les définitions de la norme ANSI/ASHRAE 135-2020 s'appliquent également à cet addendum.
3.1 Termes adoptés à partir des normes internationales
réseau local : réseau auquel un dispositif BACnet est directement connecté.
réseau distant : réseau accessible depuis un dispositif BACnet uniquement en passant par un ou plusieurs routeurs.
base de données soumise à l'essai : base de données des fonctionnalités et des objets BACnet créée en lisant le contenu d'un
EPICS.
3.2 Abréviations et acronymes utilisés dans la norme BNF
Syntaxe Backus-Naur Form
EPICS instruction de conformité à la mise en œuvre du protocole électronique
IUT mise en œuvre soumise à l'essai
TCSL langage de script d'essai et de conformité de l'
TD dispositif d'essai
TPI informations sur le protocole texte
3.3 Langage commun utilisé pour soumettre à l'essai
« toute valeur valide » : toute valeur valide voit toute valeur du type de données correct et comprise dans la plage spécifiée
par le fournisseur pour la propriété à laquelle elle s'applique.
« tout mot de passe approprié » : tout mot de passe qui répond aux exigences de configuration spécifiées dans le test ou la
section de test. Les mots de passe requis par le fournisseur ne doivent pas comporter plus de 20 caractères.
« Réinitialisation » : certains essais nécessitent la réinitialisation de l'IUT. La réinitialisation comprend la mise hors
tension puis sous tension via le commutateur, la mise hors tension puis sous tension via une coupure de courant et la
réinitialisation de l'appareil WARMSTART. Selon la définition de la norme BACnet, « WARMSTART signifie le
redémarrage de l'appareil et recommencer, en conservant toutes les données et tous les programmes qui seraient
normalement conservés pendant une brève coupure de courant ».
4. FORMAT DE FICHIER ELECTRONIQUE PICS
4. FORMAT DE FICHIER PICS ÉLECTRONIQUE
Un fichier EPICS (Electronic Protocol Implementation Conformity Statement) contient une instruction de conformité de
mise en œuvre du protocole BACnet exprimée sous forme de texte conforme à la norme. Les fichiers EPICS sont des
représentations lisibles par machine et par l'homme de la mise en œuvre des objets et services BACnet dans un appareil
donné. Les fichiers EPICS doivent utiliser l'extension «TPI » (text protocol information) et contenir des lignes de texte
normales modifiables composées de codes de caractères textuels se terminant par des paires de retours chariot/sauts de
ligne (X'0D', X'0A').
Les fichiers EPICS sont utilisés par les outils de test logiciel pour effectuer et interpréter les résultats des essais définis
dans la présente norme. Un fichier EPICS doit accompagner tout appareil soumis à l'essai conformément à la norme.
4.1 Codage des caractères
BACnet offre plusieurs possibilités d'encodage des caractères. Les encodages de caractères dans BACnet se répartissent
en trois groupes : flux d'octets, flux de double octets et flux de quadruple octets. Les flux d'octets représentent les
caractères sous forme de valeurs d'octets uniques. Dans certains cas, tels que Microsoft DBCS et JIS C 6226, certaines
valeurs d'octets indiquent que le deuxième octet qui suit doit être considéré avec l'octet de tête comme une seule valeur,
étendant ainsi la plage à plus de 256 caractères possibles. En revanche, les flux à double octet considèrent les paires
d'octets comme représentant des caractères uniques. Le codage ISO 10646 UCS-2 en est un exemple. Le premier octet ou
octet de tête de la paire est la partie la plus significative de la valeur. Les flux à quatre octets, tels que ISO 10646 UCS-4,
traitent les tuples de quatre octets à la fois comme des caractères uniques, le premier octet ou octet de tête étant le plus
significatif.
Afin de prendre en charge les différents encodages pouvant être utilisés avec les descriptions des dispositifs BACnet, les
fichiers EPICS commencent par un en-tête qui sert à la fois à identifier le fichier comme un fichier EPICS et à identifier
l'encodage particulier utilisé. L'en-tête commence par la chaîne « PICS # », où # est remplacé par un chiffre représentant
le jeu de caractères, comme indiqué dans le tableau 4-1.
Tableau 4-1. Codes des jeux de caractères
code jeu de caractères
0 ISO 10646 (UTF-8)
1 IBM™/Microsoft™ DBCS
2 JIS X 0208
3 ISO 10646 (UCS-4)
4 ISO 10646 (UCS-2)
5 ISO 8859-1
Un format de flux octet peut être reconnu en examinant les huit premiers octets du fichier EPICS. En utilisant le codage
ANSI X3.4 comme exemple, ces huit octets contiendront : X'50' X'49' X'43' X'53' X'20' X'30' X'0D' X'0A'. Cela
représente le texte « PICS 0 » suivi d'un retour chariot et d'un saut de ligne.
Un format de flux double octet peut être reconnu en examinant les 16 premiers octets du fichier EPICS. En utilisant
l'encodage ISO 10646 UCS-2 comme exemple, ces 16 octets contiendront :
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'
Cela correspond au texte « PICS 4 » suivi d'un retour chariot et d'un saut de ligne.
Un format de flux quad octet peut être reconnu en examinant les 32 premiers octets du fichier EPICS. En utilisant ISO
10646 UCS-4 comme exemple, ces 32 octets contiendront :
4. FORMAT DE FICHIER ELECTRONIQUE PICS
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'
Cela représente 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 constitués de lignes de texte se terminant par des paires de retours chariot/sauts de ligne (X'0D',
X'0A') codées sous forme de flux d'octets, de doubles octets ou de quadruples octets, comme défini au point 4.1. Dans la
suite de la présente norme, le terme « caractère » désignera un symbole codé sous forme d'un, deux ou quatre octets, en
fonction du codage des caractères utilisé dans l'en-tête du fichier EPICS. Par exemple, l'espace peut être codé sous la
forme X'20', X'0020' ou X'00000020'. Dans la présente norme, tous les caractères seront représentés sous leur forme octet
unique.
Le symbole spécial ↵ est utilisé dans cet article pour signifier la présence d'une paire retour chariot/saut de ligne
(X'0D0A'). À l'exception des chaînes de caractères, les codes de caractères tabulation (X'09'), espace (X'20'), retour
chariot (X'0D') et saut de ligne (X'0A') doivent être considérés
être un espace blanc. Toute séquence d'un ou plusieurs caractères d'espace blanc équivaut à un seul caractère d'espace
blanc. Sauf dans une chaîne de caractères, une séquence de deux tirets (X'2D') marque le début d'un commentaire qui se
termine par la paire retour chariot/saut de ligne suivante, c'est-à-dire la fin de la ligne sur laquelle apparaît le signe --. Les
commentaires sont considérés comme des espaces blancs et peuvent donc être insérés librement.
Les fichiers EPICS doivent comporter, comme première ligne après l'en-tête, le texte littéral :
Instruction de conformité de l'implémentation du protocole BACnet ↵
Ce texte sert de signature identifiant le format de fichier EPICS.
Les lignes qui définissent les sections de l'EPICS (voir 4.5) et les données d'implémentation particulières pour un appareil
donné suivent la ligne de signature.
Le fichier EPICS se termine par une ligne contenant le texte littéral suivant :
Fin de l'instruction de conformité de l'implémentation 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') signifie qu'il s'agit
d'une chaîne de caractères. Pour les guillemets doubles, la fin de la chaîne est indiquée par l'apparition suivante d'un
guillemet double ou par la fin de la ligne. Pour les guillemets simples ou l'accent grave, la fin de la chaîne est indiquée
par l'apparition suivante d'un guillemet simple (X'27') ou par la fin de la ligne. Ainsi, les chaînes qui doivent inclure un
guillemet simple ou un accent grave en tant que caractère littéral dans la chaîne doivent utiliser la méthode de citation
entre guillemets doubles, tandis que les chaînes qui doivent inclure des guillemets doubles doivent utiliser la méthode de
citation entre guillemets simples ou accents graves.
4.4 Règles de notation pour les valeurs de paramètres
Dans chaque section, les paramètres peuvent devoir être exprimés sous plusieurs formes. Les règles suivantes régissent le
format des paramètres :
(a) les mots clés ne sont pas sensibles à la casse, de manière à ce que X'41' à X'5A' soient équivalents à X'61' à X'7A';
(b) les valeurs nulles sont représentées par la chaîne « NULL » ;
(c) les valeurs booléennes sont représenté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 représentées par des chaînes de chiffres, éventuellement précédées d'un signe moins (-):
12345 ou -111 ;
4. FORMAT DE FICHIER ELECTRONIQUE PICS
(e) les valeurs réelles sont affichées avec une virgule décimale, qui ne peut être ni le premier ni le dernier caractère :
1,23, 0,02, 1,0 mais pas .02 ;
(f) les chaînes d 'octets sont représentées par des paires de chiffres hexadécimaux entre guillemets simples
(X'2D') ou accents graves (X'60'), précédées de la lettre « X » : X'001122' ;
(g) les chaînes de caractères sont représentées par un ou plusieurs caractères entre guillemets doubles, simples ou
accent graves, comme défini au point 4.3 : « texte » ou « texte » ou « texte » ;
(h) Les chaînes de bits sont répertoriées sous forme de liste, entre 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 n'a pas d'importance, un point d'interrogation est utilisé :
{T,T,?};
(i) les valeurs énumérées sont représentées sous forme de valeurs nommées plutôt que numériques. Les noms
d'énumération ne sont pas sensibles à la casse, de manière à ce que X'41' à X'5A' soient équivalents à 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ération. Les valeurs propriétaires sont représentées sous forme de texte nommé sans espace et se
terminant par un nombre décimal non négatif. Chacune doit commencer par le mot « propriétaire » :
Object_Type, propriétaire-type-d'objet-653 ;
(j) les dates sont représentées entre parenthèses : (lundi 24 janvier 1998). Tout champ « générique » ou non spécifié
est représenté par un astérisque (X'2A') : (lundi * janvier 1998). L'omission du jour de la semaine implique que
le jour n'est pas spécifié : (24 janvier 1998) ;
(k) Les heures sont représentées sous forme d'heures, de minutes, de secondes et de centièmes au format
hh:mm:ss.xx : 2:05:44.00, 16:54:59.99. Tout champ « joker » est indiqué par un astérisque (X'2A') : 16:54:*.* ;
(l) les identifiants d'objet sont indiqué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 des types d'objets par le
mot « propriétaire » suivi de la valeur numérique du type d'objet : (proprietary 700,1)
;
(m) les éléments de données construits 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 construite, cet élément doit être placé entre
accolades.
4.4.1 Valeurs de paramètres complexes
Certaines valeurs de paramètres, notamment les valeurs de propriété pour les types construits ou CHOICE de valeurs
encodées,
...














Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...