desolat / bacnet_interpretations

BACnet Interpretations

README.textile

A directory of interpretations to the BACnet standard ASHRAE 135.

Contributors

Last run completed successfully 2017-06-22.

Console output of last run

Injecting configuration and compiling... Injecting scraper and running... http://www.bacnet.org/Interpretations [<Element table at 0x17b9bf0>, <Element table at 0x17b9c50>, <Element table at 0x17b9cb0>] [<Element tr at 0x17b9d10>, <Element tr at 0x17b9d70>, <Element tr at 0x17b9dd0>, <Element tr at 0x17b9e30>] [<Element td at 0x17b9e90>] <td>  Occasionally the SSPC receives requests for official interpretations of Standards 135 and 135.1. An "Interpretation" is "The written explanation of the meaning of specific provisions of a standard or guideline, as determined by the IC [Interpretations Committee] or the PC [Project Committee, i.e., SSPC 135] in response to an inquiry." The following PDF files contain all such interpretations to date. To jump to the interpretations for a particular consolidated version of the standard, click below: <a href="#135-2001">135-2001</a> <a href="#135-2004">135-2004</a> <a href="#135-2008">135-2008</a> <a href="#135-2010">135-2010</a> <a href="#135-2012">135-2012</a> <a href="#135-2016">135-2016</a> <a name="135-2001">Interpretations of 135-2001 <a href="IC%20135-2001-1.pdf">Interpretation 135-2001-1 - June 26, 2004</a> (Refers to the requirements presented in ANSI/ASHRAE Addendum b to ANSI/ASHRAE Standard 135-2001, Section 15.8 ReadRange Service.) </a><a name="135-2004">Interpretations of 135-2004 <a href="IC%20135-2004-1.pdf">Interpretation 135-2004-1 - June 26, 2004</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 16.1 DeviceCommunicationControl Service, specifically Section 16.1.2 (page 326), relating to the canceling of DeviceCommunicationControl disabling of communication via a ReinitializeDevice request.) <a href="IC%20135-2004-2.pdf">Interpretation 135-2004-2 - June 26, 2004</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 13.11 GetEnrollmentSummary Service, specifically Section 13.11.1.2.1.4 (page 283), relating to the priority returned in a GetEnrollmentSummary response.) <a href="IC%20135-2004-3.pdf">Interpretation 135-2004-3 - June 26, 2004</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 12.25.5, Log_Enable, and Section 12.25.12, Stop_When_Full.) <a href="IC%20135-2004-4.pdf">Interpretation 135-2004-4 - June 26, 2004</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Sections 12.25.14, Log_Buffer, 12.25, and 15.7.2, Service Procedure.) <a href="IC%20135-2004-5.pdf">Interpretation 135-2004-5 - June 26, 2004</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 12.25.5, Log_Enable, and Section 12.25.12, Stop_When_Full.) <a href="IC%20135-2004-6.pdf">Interpretation 135-2004-6 - February 5, 2005</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 12.24.8, Exception_Schedule.) <a href="IC%20135-2004-7.pdf">Interpretation 135-2004-7 - February 5, 2005</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Sections K.5.15 and K.5.16.) <a href="IC%20135-2004-8.pdf">Interpretation 135-2004-8 - June 25, 2005</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004 in the following sections and tables relating to FLOATING_LIMIT and OUT_OF_RANGE transitions: Sections 12.2.19-12.2.21, Sections 12.3.20-12.3.22, Sections 12.4.16-12.4.18, Section 12.17.32, Sections 12.23.22-12.23.24, Section 13.3.5, Section 13.3.6, Table 13.2.) <a href="IC%20135-2004-9.pdf">Interpretation 135-2004-9 - June 25, 2005</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Sections 12.1-12.4, 12.6-12.8, 12.15-12.20, 12.23, 12.25, and the corresponding tables in these sections, relating to intrinsic reporting.) <a href="IC%20135-2004-10.pdf">Interpretation 135-2004-10 - June 25, 2005</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 6.6.1, Routing Tables, and Section 6.6.3.6, Router- Busy-To-Network.) <a href="IC%20135-2004-11.pdf">Interpretation 135-2004-11 - June 25, 2005</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 12.25.14, Log_Buffer, and Section 15.7.3.1.2, List of Property References.) <a href="IC%20135-2004-12.pdf">Interpretation 135-2004-12 - June 25, 2005</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 6.4.4, Reject-Message-To-Network, and Section 6.6.3.5, Reject-Message-To-Network.) <a href="IC%20135-2004-13.pdf">Interpretation 135-2004-13 - June 25, 2005</a> (Refers refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Sections 12.1.10, 12.2.10, 12.3.10, 12.4.9, 12.6.10, 12.7.10, 12.8.9, 12.15.11, 12.16.11, 12.17.9, 12.18.10, 12.19.10, 12.20.9, 12.23.10, relating to the Reliability and Out_Of_Service properties.) <a href="IC%20135-2004-14.pdf">Interpretation 135-2004-14 - September 28, 2005</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 6.3.2, relating to Network Layer routing.) <a href="IC%20135-2004-15.pdf">Interpretation 135-2004-15 - September 28, 2005</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Annex J - BACnet/IP, specifically Section J.2.6.1, Register-Foreign-Device: Format.) <a href="IC%20135-2004-16.pdf">Interpretation 135-2004-16 - June 24, 2006</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Sections 12.1.8, 12.2.8, 12.3.8, 12.4.7, 12.6.8, 12.7.8, 12.8.7, 12.17.7, 12.18.8, 12.20.7, and 12.23.8 related to Event_State and Relibility properties.) <a href="IC%20135-2004-17.pdf">Interpretation 135-2004-17 - April 24, 2006</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 12.25.14, related to Log_Buffer.) <a href="IC%20135-2004-18.pdf">Interpretation 135-2004-18 - January 21, 2006</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 12.25.9, related to Log_Interval.) <a href="IC%20135-2004-18.pdf">Interpretation 135-2004-18 - January 21, 2006</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 12.25.9, related to Log_Interval.) <a href="IC%20135-2004-19.pdf">Interpretation 135-2004-19 - January 27, 2007</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Sections.15.9.1.1.5, 15.10.3.2.4 and 19.2.1, related to writing properties with an out-of-range priority.) <a href="IC%20135-2004-20.pdf">Interpretation 135-2004-20 - January 27, 2007</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Sections 5.4, 5.4.1, 5.4.5.1, 5.4.5.3, and 12.11.27 related to the Device Object and the APDU_Timeout property.) <a href="IC%20135-2004-21.pdf">Interpretation 135-2004-21 - January 27, 2007</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 12.24.4, 12.24.7 and 12.24.8 regarding when the Present_Value of an object is evaluated within a selected Weekly_Schedule or Exception_Schedule.) <a href="IC%20135-2004-22.pdf">Interpretation 135-2004-22 - April 25, 2007</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Sections 6.5.3 and 9.5.6.4 regarding the methods for establishing the address of a BACnet router for a particular DNET.) <a href="IC%20135-2004-23.pdf">Interpretation 135-2004-23 - June 21, 2008</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 13.2 relating to intrinsic reporting.) <a href="IC%20135-2004-24.pdf">Interpretation 135-2004-24 - June 21, 2008</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Sections 19.2, 21 and 23.3, and Addendum f to ANSI/ASHRAE Standard 135-2004 regarding ENUMERATED values in BACnetPriorityValue.) <a href="IC%20135-2004-25.pdf">Interpretation 135-2004-25 - June 21, 2008</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Sections 13.2 and 13.3 relating to fault event reporting.) <a href="IC%20135-2004-26.pdf">Interpretation 135-2004-26 - September 17, 2008</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 13.11.1.1.5 regarding Priority Filter.) <a href="IC%20135-2004-27.pdf">Interpretation 135-2004-27 - September 17, 2008</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 21 relating to BACnetEventParameters 'buffer-ready' choice.) <a href="IC%20135-2004-28.pdf">Interpretation 135-2004-28 - September 17, 2008</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Sections 15.10.1.3.1 and 18.8.4 relating to WritePropertyMultiple with incorrect datatype.) <a href="IC%20135-2004-29.pdf">Interpretation 135-2004-29 - January 24, 2009</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 19.1.3.2, relating to creating configuration File objects in the restore process.) </a><a name="135-2008">Interpretations of 135-2008 <a href="IC%20135-2008-1.pdf">Interpretation 135-2008-1 - June 20, 2009</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2008, Sections 12.19.10 and 12.20.10, relating to Shrinking Number_of_States in Commandable Multi-state objects.) <a href="IC%20135-2008-2.pdf">Interpretation 135-2008-2 - June 20, 2009</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2008, Section 12.24.4, related to the calculation of the Present_Value property of a Schedule object.) <a href="IC%20135-2008-3.pdf">Interpretation 135-2008-3 - January 23, 2010</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2008, Section 12, relating to the data type of the number of elements of an array when accessing an array property with array index 0.) <a href="IC%20135-2008-4.pdf">Interpretation 135-2008-4 - January 23, 2010</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2008, Section 12.13.7, File Object Modification_Date property value.) <a href="IC%20135-2008-5.pdf">Interpretation 135-2008-5 - May 28, 2010</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2008 relating to Date and Time.) <a href="IC%20135-2008-6.pdf">Interpretation 135-2008-6 - October 28, 2010</a> (Refers to the change of requirements presented in ANSI/ASHRAE Addendum l to ANSI/ASHRAE Standard 135-2008, Section 1 and ANSI/ASHRAE Addendum v to ANSI/ASHRAE Standard 135-2008, Section 3, relating to the support of the BIBB NM-CE-A in the device profile B-AWS.) <a href="IC%20135-2008-7.pdf">Interpretation 135-2008-7 - October 28, 2010</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2008, Clauses 5.4 and 5.4.5.3, relating to the CannotSendSegmentedComplexACK for the AWAIT_RESPONSE.) <a href="IC%20135-2008-8.pdf">Interpretation 135-2008-8 - October 28, 2010</a> (Refers to the requirements presented in Addendum g to ANSI/ASHRAE Standard 135-2008, Section 24.5 and Figure 24-2 (page 32), relating to securing proprietary network messages.) <a href="IC%20135-2008-9.pdf">Interpretation 135-2008-9 - October 28, 2010</a> (Refers to the requirements presented in Addendum g to ANSI/ASHRAE Standard 135-2008, Sections 12.X.15 and 24.16.2, relating to the Do_Not_Hide property of the Network Security object.) <a href="IC%20135-2008-10.pdf">Interpretation 135-2008-10 - October 28, 2010</a> (Refers to the requirements presented in Addendum g to ANSI/ASHRAE Standard 135-2008, Section 24.16.1, relating to APDU and NPDU sizes.) <a href="IC%20135-2008-11.pdf">Interpretation 135-2008-11 - October 28, 2010</a> (Refers to the requirements presented in Addendum p to ANSI/ASHRAE Standard 135-2008, Section 13.3.X, relating to the CHANGE_OF_STATUS_FLAGS Algorithm.) <a href="IC%20135-2008-12.pdf">Interpretation 135-2008-12 - October 28, 2010</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2008, Sections 12.1 and 12.1.11, relating to Accumulator object's Scale property.) <a href="IC%20135-2008-13.pdf">Interpretation 135-2008-13 - January 29, 2011</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2008, Clauses 6.4.7 and 6.4.8 (pages 55 and 56), relating Initialize-Routing-Table and Initialize-Routing-Table-Ack.) <a href="IC%20135-2008-14.pdf">Interpretation 135-2008-14 - January 29, 2011</a> (Refers to the requirements presented in Addendum g to ANSI/ASHRAE Standard 135-2008, Clause 24.2.11 (page 13), relating to Authentication Data length encoding.) <a href="IC%20135-2008-15.pdf">Interpretation 135-2008-15 - January 29, 2011</a> (Refers to the requirements presented in Addendum g to ANSI/ASHRAE Standard 135-2008, Clauses 24.2.3 and 24.12.1 (pages 11 and 40), relating to Selecting General-Network-Access key for encryption when another key is used for signing.) <a href="IC%20135-2008-16.pdf">Interpretation 135-2008-16 - January 29, 2011</a> (Refers to the requirements presented in Addendum g to ANSI/ASHRAE Standard 135-2008, Clause 24.16.2 and Tables 24-8, 24-18, 24-22 and 24-24 (pages 47, 19, 22-23, 26-27, 28-29), relating to order of error checking in key messages.) <a href="IC%20135-2008-17.pdf">Interpretation 135-2008-17 - January 29, 2011</a> (Refers to the requirements presented in Addendum g to ANSI/ASHRAE Standard 135-2008, Clauses 24.15.2.1 (page 45), relating to methods for discovering time.) <a href="IC%20135-2008-18.pdf">Interpretation 135-2008-18 - January 29, 2011</a> (Refers to the requirements presented in Addendum g to ANSI/ASHRAE Standard 135-2008, Clauses 24.2.8, 24.2.9, 24.3.7, 24.12.1, S.1 (pages 12, 29, 39, 98), relating to Security Applied to Request-Master-Key message.) <a href="IC%20135-2008-19.pdf">Interpretation 135-2008-19 - January 29, 2011</a> (Refers to the requirements presented in Addendum g to ANSI/ASHRAE Standard 135-2008, Clause 24.3.3.3 and Table 24.11 (page 20), relating to What it means for a device to "know a key".) <a href="IC%20135-2008-20.pdf">Interpretation 135-2008-20 - May 25, 2011</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2008, Clauses J.2 (page 617), relating to BACnet Broadcast Management Device (BBMD) and BACnet Virtual Link Layer (BVLL) Services.) <a href="IC%20135-2008-21.pdf">Interpretation 135-2008-21 - May 25, 2011</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2008, Clauses 12.25 (pages 259 and 281), relating to Timestamping of Trend Log records.) </a><a name="135-2010">Interpretations of 135-2010 <a href="IC%20135-2010-1.pdf">Interpretation 135-2010-1 - May 25, 2011</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2010, Clause 12.24, relating to Schedule Object Type.) <a href="IC%20135-2010-2.pdf">Interpretation 135-2010-2 - October 27, 2011</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2010 clauses 12.25.5 (Trend Log Object Type, Enable property) and 12.25.14 (Trend Log Object Type, Log_Buffer property). This interpretation request also applies to the corresponding property clauses of the Event Log Object Type (12.27.8, 12.27.13) and the Trend Log Multiple Object Type (12.30.8, 12.30.19).) <a href="IC%20135-2010-3.pdf">Interpretation 135-2010-3 - October 27, 2011</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2010, Clause 12.11.50 (Device Object Type, Interval_Offset).) <a href="IC%20135-2010-4.pdf">Interpretation 135-2010-4 - July 16, 2012</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2010, Clauses 5.2.1.2, 6, 6.4.4 and 6.6.3.5, as well as Table 6.1, relating to router requirements.) <a href="IC%20135-2010-5.pdf">Interpretation 135-2010-5 - July 16, 2012</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2010, Clauses 12.25.9 and K.4.3, relating to T-VMT-E-B BIBB.) <a href="IC%20135-2010-6.pdf">Interpretation 135-2010-6 - June 13, 2012</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2010, Clause 15.7.2, relating to the special property OPTIONAL.) <a href="IC%20135-2010-7.pdf">Interpretation 135-2010-7 - June 13, 2012</a> (Refers to standard ANSI/ASHRAE 135-2010, Clause 13.1, "Change of Value Reporting" on page 412, Table 13-1 on page 413, and Table 13-1a on page 414.) <a href="IC%20135-2010-8.pdf">Interpretation 135-2010-8 - November 7, 2012</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2010, Clause 12.24.4 and 12.24.6, relating to the behavior of the property.) <a href="IC%20135-2010-9.pdf">Interpretation 135-2010-9 - November 7, 2012</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2010, Clauses 15.1.1.4.1.2, 15.1.1.4.2.2, 15.1.1.4.3.2, and 15.8.2, relating to the content of ReadRange-ACK when MORE_ITEMS is true, and the Count in the ReadRange-Request was negative.) <a href="IC%20135-2010-10.pdf">Interpretation 135-2010-10 - November 7, 2012</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2010, Clauses 12.25 Preamble and 12.27 Preamble and 12.30 Preamble, relating to the behavior of the property Total_Record_Count of logging objects.) <a href="IC%20135-2010-11.pdf">Interpretation 135-2010-11 - November 7, 2012</a> (Refers to standard ANSI/ASHRAE 135-2010, Clause 12.11.19, "Segmentation_Supported", and Clause 12.11.20, "Max_Segments_Accepted", both on page 199.) <a href="IC%20135-2010-12.pdf">Interpretation 135-2010-12 - January 26, 2013</a> (Refers to ANSI/ASHRAE Standard 135-2010, Clause 12, regarding the Object_Identifier property and the instance number 4194303.) <a href="IC%20135-2010-13.pdf">Interpretation 135-2010-13 - January 26, 2013</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2010af-31, Clause 12.X, relating to the behavior of the AckRequired Boolean in ConfirmedEventNotification and UnconfirmedEventNotification requests.) <a href="IC%20135-2010-14.pdf">Interpretation 135-2010-14 - May 9, 2013</a> (Refers to ANSI/ASHRAE Standard 135-2010, Clauses 12.4.9, 12.8.9 and 12.20.9, regarding the Out_Of_Service property.) </a><a name="135-2012">Interpretations of 135-2012 <a href="IC%20135-2012-1.pdf">Interpretation 135-2012-1 - May 9, 2013</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2012, Clause 12.25.14, relating to recording time-change events in trendlog logbuffer.) <a href="IC%20135-2012-2.pdf">Interpretation 135-2012-2 - June 22, 2013</a> (Refers to ANSI/ASHRAE Standard 135-2012, Clause 19, regarding the Command Prioritization.) <a href="IC%20135-2012-3.pdf">Interpretation 135-2012-3 - June 22, 2013</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2012, Clause K.5.23, relating to BBIB Device Management-Object Creation and Deletion-A (DM-OCD-A).) <a href="IC%20135-2012-4.pdf">Interpretation 135-2012-4 - June 22, 2013</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2012, Clause 12.25.10, relating to details on client behavior for retrieving external property values by COV or polling.) <a href="IC%20135-2012-5.pdf">Interpretation 135-2012-5 - June 22, 2013</a> (Refers to ANSI/ASHRAE Standard 135-2012, Clauses 12.4.9, 12.8.9 and 12.20.9, regarding the Out_Of_Service property.) <a href="IC135-2012-6.pdf">Interpretation 135-2012-6 - November 6, 2013</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2012, Clause 12.9.6, relating to the behavior of the Present_Value in a Calendar when the Date_List contains a specific day-of-week, and any of the special third octet values.) <a href="IC135-2012-7.pdf">Interpretation 135-2012-7 - November 6, 2013</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2012, Clause 15.10.1.3 and 15.10.2, relating to error handling of WritePropertyMultiple Service.) <a href="IC135-2012-8.pdf">Interpretation 135-2012-8 - November 6, 2013</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2012, Clauses 12.18.10 and 13.4.5, relating to the correct value of reliability when OutOfService.) <a href="IC135-2012-9.pdf">Interpretation 135-2012-9 - November 6, 2013</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2012, Clause 12, relating to the execution of alarming related messages containing timestamps with wildcards.) <a href="IC135-2012-10.pdf">Interpretation 135-2012-10 - January 18, 2014</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2012, Clause 15.8.2, relating to ReadRange executed with a Range parameter of 'byTime'.) <a href="IC135-2012-11.pdf">Interpretation 135-2012-11 - January 18, 2014</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clause 12.25.14, regarding all logging objects (TL, TLM, EL).) <a href="IC135-2012-12.pdf">Interpretation 135-2012-12 - April 9, 2014</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clause 5, regarding all Property MaxSegmentsAccepted, Client State Machine.) <a href="IC135-2012-13.pdf">Interpretation 135-2012-13 - January 24, 2015</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clause 19.1.3.3, regarding file objects using record-access.) <a href="IC135-2012-14.pdf">Interpretation 135-2012-14 - January 24, 2015</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clause 19.1.3.3, regarding restoring the configuration files.) <a href="IC135-2012-15.pdf">Interpretation 135-2012-15 - January 24, 2015</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clause 15.8, regarding ReadRange Service, by position with negative count.) <a href="IC135-2012-16.pdf">Interpretation 135-2012-16 - April 30, 2015</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clause 13.7, regarding UnconfirmedCOVNotification Service, K1-11 BIBB DS-COV-A.) <a href="IC135-2012-17.pdf">Interpretation 135-2012-17 - April 30, 2015</a> (Refers to the requirements presented in ANSI/ASHRAE 135-2012, Clauses 12.25.14, 12.30.19, and 21 (BACnetLogData and BACnetLogRecord) relating to trending.) <a href="IC135-2012-18.pdf">Interpretation 135-2012-18 - November 4, 2015</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clause 13.14, regarding SubscribeCOV service with indefinite lifetime.) <a href="IC135-2012-19.pdf">Interpretation 135-2012-19 - November 4, 2015</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clauses 12.12.8, 15.3.1.3.1, 15.9.1.3.1 and 15.10.1.3.1, regarding error returned to a CreateObject service.) <a href="IC135-2012-20.pdf">Interpretation 135-2012-20 - April 19, 2016</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clause 12.11.39, regarding Optionality of COV_Increment in Active_COV_Subscriptions.) </a><a name="135-2016">Interpretations of 135-2016 <a href="IC135-2016-1.pdf">Interpretation 135-2016-1 - July 21, 2016</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause 12.56, regarding the Network Port object.) <a href="IC135-2016-2.pdf">Interpretation 135-2016-2 - October 25, 2016</a> (Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause 13.3.6, regarding the direct transitions.) </a></td> Interpretation 135-2001-1 - June 26, 2004 2004-06-26 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2001-1.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="16" family="Times" color="#000000"/> <fontspec id="1" size="13" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="56" left="108" width="5" height="19" font="0"> </text> <text top="1140" left="432" width="4" height="16" font="1"> </text> <text top="1140" left="486" width="4" height="16" font="1"> </text> <text top="1140" left="540" width="237" height="16" font="1">©2004 ASHRAE. All Rights reserved. </text> <text top="88" left="306" width="311" height="19" font="2">INTERPRETATION IC 135-2001-1 OF </text> <text top="110" left="263" width="368" height="19" font="2">ANSI/ASHRAE STANDARD 135-2001 BACnet</text> <text top="107" left="630" width="29" height="23" font="2"> - </text> <text top="131" left="284" width="355" height="19" font="2">A Data Communication Protocol for Building </text> <text top="152" left="325" width="273" height="19" font="2">Automation and Control Networks </text> <text top="172" left="108" width="5" height="19" font="0"> </text> <text top="193" left="351" width="221" height="19" font="0">Approval Date: June 26, 2004 </text> <text top="214" left="108" width="5" height="19" font="0"> </text> <text top="234" left="108" width="217" height="19" font="2">Request from: Carl Neilson (</text> <text top="234" left="325" width="205" height="19" font="3"><a href="mailto:cneilson@deltacontrols.com">cneilson@deltacontrols.com</a></text> <text top="234" left="530" width="250" height="19" font="0"><a href="mailto:cneilson@deltacontrols.com">) Delta Controls, 61 Seagirt Road, </a></text> <text top="255" left="108" width="194" height="19" font="0">East Sooke, BC V0S 1N0 </text> <text top="276" left="108" width="5" height="19" font="0"> </text> <text top="297" left="108" width="589" height="19" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="317" left="108" width="692" height="19" font="0">ANSI/ASHRAE Addendum b to ANSI/ASHRAE Standard 135-2001, Section 15.8 ReadRange </text> <text top="338" left="108" width="68" height="19" font="0">Service. </text> <text top="359" left="108" width="5" height="19" font="0"> </text> <text top="379" left="108" width="701" height="19" font="2">Background: In Section 15.8 of Addendum 135b, second sentence of Section 15.8.1.1.4.3.1 and </text> <text top="400" left="108" width="673" height="19" font="0">third sentence of the fourth paragraph of Section 15.8.2 appear to contradict each other when </text> <text top="421" left="108" width="695" height="19" font="0">describing what values should be returned by the ReadRange service when the Count parameter </text> <text top="441" left="108" width="91" height="19" font="0">is negative. </text> <text top="462" left="108" width="5" height="19" font="0"> </text> <text top="483" left="122" width="228" height="19" font="0">15.8.1.1.4.3.1 Reference Time </text> <text top="504" left="122" width="687" height="19" font="0">If 'Count' is positive, the first record to be read shall be the first record with a timestamp newer </text> <text top="524" left="122" width="689" height="19" font="0">than the time specified by the 'Reference Time' parameter. If 'Count' is negative, the last record </text> <text top="545" left="122" width="654" height="19" font="0">to be read shall be the newest record with a timestamp older than the time specified by the </text> <text top="566" left="122" width="207" height="19" font="0">'Reference Time' parameter. </text> <text top="586" left="122" width="5" height="19" font="0"> </text> <text top="607" left="122" width="185" height="19" font="0">15.8.2 Service Procedure </text> <text top="628" left="122" width="5" height="19" font="0"> </text> <text top="648" left="122" width="676" height="19" font="0">If the 'Range' parameter is present and specifies the 'By Time' parameter, then the responding </text> <text top="669" left="122" width="692" height="19" font="0">BACnet-user shall read and attempt to return all of the items specified. If 'By Time’ parameters </text> <text top="690" left="122" width="685" height="19" font="0">are specified and the property values are not timestamped an error shall be returned. The items </text> <text top="710" left="122" width="638" height="19" font="0">specified include the first item with a timestamp newer than 'Reference Time' plus up to </text> <text top="731" left="122" width="683" height="19" font="0">'Count'-1 items following if 'Count' is positive, or up to -1-'Count' items preceding if 'Count' is </text> <text top="752" left="122" width="688" height="19" font="0">negative. Array index 0 shall not be returned by this service; lists shall begin with index 1. The </text> <text top="773" left="122" width="554" height="19" font="0">sequence number of the first item returned shall be included in the response. </text> <text top="793" left="108" width="5" height="19" font="0"> </text> <text top="814" left="108" width="664" height="19" font="0">The language in Section 15.8.1.1.4.3.1 was modified in Addendum 135b in order to resolve </text> <text top="835" left="108" width="698" height="19" font="0">issues in the original language, whereas the corresponding paragraph in 15.8.2 was not modified </text> <text top="855" left="108" width="129" height="19" font="0">in the addendum. </text> <text top="876" left="108" width="5" height="19" font="0"> </text> <text top="897" left="108" width="672" height="19" font="2">Interpretation: We have interpreted the standard as requiring the functionality described in </text> <text top="917" left="108" width="692" height="19" font="0">Section 15.8.1.1.4.3.1 and not the functionality described in sentence three of paragraph four of </text> <text top="938" left="108" width="122" height="19" font="0">Section 15.8.2. </text> <text top="959" left="108" width="5" height="19" font="0"> </text> <text top="980" left="108" width="292" height="19" font="2">Question: Is this interpretation correct? </text> <text top="1000" left="108" width="5" height="19" font="0"> </text> <text top="1021" left="108" width="106" height="19" font="2">Answer: Yes. </text> <text top="1042" left="108" width="5" height="19" font="0"> </text> <text top="1062" left="108" width="682" height="19" font="2">Comments: This was clarified by a language change in 15.8.2 for ANSI/ASHRAE 135-2004. </text> </page> </pdf2xml> Interpretation 135-2004-1 - June 26, 2004 2004-06-26 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-1.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="486" width="4" height="14" font="0"> </text> <text top="1099" left="540" width="238" height="14" font="0">©2004 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="306" width="311" height="16" font="2">INTERPRETATION IC 135-2004-1 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="351" width="221" height="16" font="1">Approval Date: June 26, 2004 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="217" height="16" font="2">Request from:<a href="mailto:cneilson@deltacontrols.com"> Carl Neilson (</a></text> <text top="239" left="325" width="205" height="16" font="3"><a href="mailto:cneilson@deltacontrols.com">cneilson@deltacontrols.com</a></text> <text top="239" left="531" width="250" height="16" font="1"><a href="mailto:cneilson@deltacontrols.com">) Delta Controls, 61 Seagirt Road, </a></text> <text top="260" left="108" width="194" height="16" font="1">East Sooke, BC V0S 1N0 </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="589" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="654" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Section 16.1 DeviceCommunicationControl Service, </text> <text top="345" left="108" width="480" height="16" font="1">specifically Section 16.1.2 (page 326), relating to the canceling of </text> <text top="366" left="108" width="672" height="16" font="1">DeviceCommunicationControl disabling of communication via a ReinitializeDevice request. </text> <text top="386" left="108" width="5" height="16" font="1"> </text> <text top="408" left="108" width="700" height="16" font="2">Background: The DeviceCommunicationControl service is used to stop a device from initiating </text> <text top="429" left="108" width="705" height="16" font="1">and responding to all APDUs with the exception of other DeviceCommunicationControl requests </text> <text top="450" left="108" width="689" height="16" font="1">and ReinitializeDevice requests. In Addenda c to 135-1995, the ReinitializeDevice service was </text> <text top="471" left="108" width="612" height="16" font="1">modified to allow for the backing up of, and restoring of BACnet devices. When the </text> <text top="492" left="108" width="494" height="16" font="1">backup/restore procedure was crafted and added to the standard, the </text> <text top="513" left="108" width="671" height="16" font="1">DeviceCommunicationControl service was not discussed nor the effect that starting a device </text> <text top="534" left="108" width="583" height="16" font="1">backup or restore would cancel the DeviceCommunicationControl's disabling of </text> <text top="555" left="108" width="684" height="16" font="1">communications. Should the starting of a backup or restore on a device cancel the disabling of </text> <text top="575" left="108" width="131" height="16" font="1">communications? </text> <text top="596" left="108" width="5" height="16" font="1"> </text> <text top="618" left="108" width="540" height="16" font="2">Interpretation: Devices that have had their communications disabled via </text> <text top="639" left="108" width="679" height="16" font="1">DeviceCommunicationControl should ignore, and not respond to, ReinitializeDevice requests </text> <text top="660" left="108" width="680" height="16" font="1">that contain a value other than COLDSTART or WARMSTART for the Reinitialized State of </text> <text top="681" left="108" width="137" height="16" font="1">Device parameter. </text> <text top="702" left="108" width="5" height="16" font="1"> </text> <text top="723" left="108" width="292" height="16" font="2">Question: Is this interpretation correct? </text> <text top="744" left="108" width="5" height="16" font="1"> </text> <text top="765" left="108" width="106" height="16" font="2">Answer: Yes. </text> <text top="786" left="108" width="5" height="16" font="1"> </text> </page> </pdf2xml> Interpretation 135-2004-2 - June 26, 2004 2004-06-26 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-2.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="486" width="4" height="14" font="0"> </text> <text top="1099" left="540" width="238" height="14" font="0">©2004 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="306" width="311" height="16" font="2">INTERPRETATION IC 135-2004-2 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="351" width="221" height="16" font="1">Approval Date: June 26, 2004 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="217" height="16" font="2">Request from:<a href="mailto:cneilson@deltacontrols.com"> Carl Neilson (</a></text> <text top="239" left="325" width="205" height="16" font="3"><a href="mailto:cneilson@deltacontrols.com">cneilson@deltacontrols.com</a></text> <text top="239" left="531" width="250" height="16" font="1"><a href="mailto:cneilson@deltacontrols.com">) Delta Controls, 61 Seagirt Road, </a></text> <text top="260" left="108" width="199" height="16" font="1">East Sooke, BC V0S 1N0 </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="589" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="706" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Section 13.11 GetEnrollmentSummary Service, specifically </text> <text top="345" left="108" width="685" height="16" font="1">Section 13.11.1.2.1.4 (page 283), relating to the priority returned in a GetEnrollmentSummary </text> <text top="366" left="108" width="72" height="16" font="1">response. </text> <text top="386" left="108" width="5" height="16" font="1"> </text> <text top="408" left="108" width="646" height="16" font="2">Background: The GetEnrollmentSummary service includes a parameter, Priority, which </text> <text top="429" left="108" width="648" height="16" font="1">"indicates the priority of notifications generated by the object." The problem is that event </text> <text top="450" left="108" width="705" height="16" font="1">generating objects in BACnet have three possibly different priorities: one for To-Normal, one for </text> <text top="471" left="108" width="692" height="16" font="1">To-OffNormal and one for To-Fault transitions. It is unclear which of these priorities should be </text> <text top="492" left="108" width="501" height="16" font="1">included in the GetEnrollmentSummary response Priority parameter. </text> <text top="513" left="108" width="5" height="16" font="1"> </text> <text top="534" left="108" width="683" height="16" font="2">Interpretation: Since the entry in the GetEnrollmentSummary response indicates the current </text> <text top="555" left="108" width="692" height="16" font="1">Event State of the event generating object, the Priority parameter should indicate the priority of </text> <text top="576" left="108" width="675" height="16" font="1">the corresponding transition. For example, if the Event State of the returned event generating </text> <text top="597" left="108" width="697" height="16" font="1">object is High_Limit, then the value of the Priority parameter will be the To-OffNormal priority </text> <text top="618" left="108" width="308" height="16" font="1">from the related Notification Class object. </text> <text top="639" left="108" width="5" height="16" font="1"> </text> <text top="660" left="108" width="292" height="16" font="2">Question: Is this interpretation correct? </text> <text top="681" left="108" width="5" height="16" font="1"> </text> <text top="702" left="108" width="102" height="16" font="2">Answer: Yes </text> <text top="723" left="108" width="5" height="16" font="1"> </text> </page> </pdf2xml> Interpretation 135-2004-3 - June 26, 2004 2004-06-26 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-3.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="14" family="Times" color="#000000"/> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="486" width="4" height="14" font="0"> </text> <text top="1099" left="540" width="238" height="14" font="0">©2004 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="306" width="311" height="16" font="2">INTERPRETATION IC 135-2004-3 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="351" width="221" height="16" font="1">Approval Date: June 26, 2004 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="218" height="16" font="2">Request from: David Wh<a href="mailto:whited@andovercontrols.com">ite (</a></text> <text top="239" left="326" width="217" height="16" font="3"><a href="mailto:whited@andovercontrols.com">whited@andovercontrols.com</a></text> <text top="239" left="543" width="230" height="16" font="1">) Andover Controls, Corp., 300 </text> <text top="260" left="108" width="266" height="16" font="1">Brickstone Sq., Andover, MA 01810</text> <text top="260" left="374" width="5" height="16" font="3"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="589" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="650" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Section 12.25.5, Log_Enable, and Section 12.25.12, </text> <text top="345" left="108" width="132" height="16" font="1">Stop_When_Full. </text> <text top="366" left="108" width="5" height="16" font="1"> </text> <text top="387" left="108" width="675" height="16" font="2">Background: The specification of the Stop_When_Full property (Section 12.25.12) requires </text> <text top="408" left="108" width="690" height="16" font="1">setting the Log_Enable property to FALSE when the log buffer becomes full. However, setting </text> <text top="429" left="108" width="642" height="16" font="1">Log_Enable to FALSE requires an entry in the log buffer (Section 12.25.5). Making this </text> <text top="450" left="108" width="683" height="16" font="1">required entry causes the oldest entry to be lost, which does not seem to be consistent with the </text> <text top="471" left="108" width="155" height="16" font="1">intent of this feature. </text> <text top="492" left="108" width="5" height="16" font="1"> </text> <text top="513" left="108" width="683" height="16" font="2">Interpretation: The specification requires deletion of the oldest record from the log as a side </text> <text top="534" left="108" width="496" height="16" font="1">effect of logging the automatic disabling when the log becomes full. </text> <text top="555" left="108" width="5" height="16" font="1"> </text> <text top="576" left="108" width="292" height="16" font="2">Question: Is this interpretation correct? </text> <text top="597" left="108" width="5" height="16" font="1"> </text> <text top="618" left="108" width="100" height="16" font="2">Answer: No. </text> <text top="639" left="108" width="5" height="16" font="1"> </text> <text top="660" left="108" width="681" height="16" font="2">Comments: Logging should cease when there is room for one final entry in the log, at which </text> <text top="681" left="108" width="680" height="16" font="1">point Log_Enabled shall be set to FALSE and a record of that change shall be recorded as the </text> <text top="702" left="108" width="673" height="16" font="1">final entry. It is intended that disabling of the log be recorded without affecting prior logged </text> <text top="723" left="108" width="57" height="16" font="1">entries. </text> <text top="744" left="108" width="4" height="15" font="4"> </text> <text top="763" left="108" width="4" height="15" font="4"> </text> </page> </pdf2xml> Interpretation 135-2004-4 - June 26, 2004 2004-06-26 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-4.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="486" width="4" height="14" font="0"> </text> <text top="1099" left="540" width="238" height="14" font="0">©2004 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="306" width="311" height="16" font="2">INTERPRETATION IC 135-2004-4 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="351" width="221" height="16" font="1">Approval Date: June 26, 2004 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="218" height="16" font="2">Request from: David Wh<a href="mailto:whited@andovercontrols.com">ite (</a></text> <text top="239" left="326" width="217" height="16" font="3"><a href="mailto:whited@andovercontrols.com">whited@andovercontrols.com</a></text> <text top="239" left="543" width="230" height="16" font="1">) Andover Controls, Corp., 300 </text> <text top="260" left="108" width="266" height="16" font="1">Brickstone Sq., Andover, MA 01810</text> <text top="260" left="374" width="5" height="16" font="3"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="589" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="694" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Sections 12.25.14, Log_Buffer, 12.25, and 15.7.2, Service </text> <text top="345" left="108" width="82" height="16" font="1">Procedure. </text> <text top="366" left="108" width="5" height="16" font="1"> </text> <text top="387" left="108" width="646" height="16" font="2">Background: A Trend Log’s log buffer includes Status Flags in its entries, under certain </text> <text top="408" left="108" width="701" height="16" font="1">conditions. However, the specification of those conditions is inconsistent. In Section 12.25.14, it </text> <text top="429" left="108" width="693" height="16" font="1">is specified that the flags are included only if they can be obtained atomically with the value, as </text> <text top="450" left="108" width="691" height="16" font="1">occurs with change of value (COV) notification. However, in Section 12.25 it specifies that the </text> <text top="471" left="108" width="625" height="16" font="1">flags are included if ReadPropertyMultiple (RPM) is used to obtain the values. This is </text> <text top="492" left="108" width="589" height="16" font="1">inconsistent because Section 15.7.2 specifies that RPM is not necessarily atomic. </text> <text top="513" left="108" width="5" height="16" font="1"> </text> <text top="534" left="108" width="704" height="16" font="2">Interpretation: The specification in Section 12.33 (that Status Flags should be included if Read </text> <text top="555" left="108" width="672" height="16" font="1">Property Multiple is used) is inconsistent and should be ignored. Status Flags should only be </text> <text top="576" left="108" width="647" height="16" font="1">included if they are obtained atomically with the associated value, as specified in Section </text> <text top="597" left="108" width="72" height="16" font="1">12.25.14. </text> <text top="618" left="108" width="5" height="16" font="1"> </text> <text top="639" left="108" width="292" height="16" font="2">Question: Is this interpretation correct? </text> <text top="660" left="108" width="5" height="16" font="1"> </text> <text top="681" left="108" width="100" height="16" font="2">Answer: No. </text> <text top="702" left="108" width="5" height="16" font="1"> </text> <text top="723" left="108" width="697" height="16" font="2">Comments: The Status_Flags shall be included if ReadPropertyMultiple or COV notification is </text> <text top="744" left="108" width="656" height="16" font="1">used. This issue of atomicity has previously been identified and the committee is currently </text> <text top="765" left="108" width="316" height="16" font="1">considering a proposal to address the issue. </text> </page> </pdf2xml> Interpretation 135-2004-5 - June 26, 2004 2004-06-26 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-5.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="486" width="4" height="14" font="0"> </text> <text top="1099" left="540" width="238" height="14" font="0">©2004 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="308" width="306" height="16" font="2">INTERPRETATION IC 135-2004-5OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="351" width="221" height="16" font="1">Approval Date: June 26, 2004 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="218" height="16" font="2">Request from: David Wh<a href="mailto:whited@andovercontrols.com">ite (</a></text> <text top="239" left="326" width="217" height="16" font="3"><a href="mailto:whited@andovercontrols.com">whited@andovercontrols.com</a></text> <text top="239" left="543" width="230" height="16" font="1">) Andover Controls, Corp., 300 </text> <text top="260" left="108" width="270" height="16" font="1">Brickstone Sq., Andover, MA 01810 </text> <text top="260" left="378" width="5" height="16" font="3"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="589" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="650" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Section 12.25.5, Log_Enable, and Section 12.25.12, </text> <text top="345" left="108" width="132" height="16" font="1">Stop_When_Full. </text> <text top="366" left="108" width="5" height="16" font="1"> </text> <text top="387" left="108" width="675" height="16" font="2">Background: If Stop_When_Full is TRUE, and the log buffer is full, it is required to disable </text> <text top="408" left="108" width="704" height="16" font="1">logging (Log_Enable = FALSE). Under these conditions, it is not totally clear what is the correct </text> <text top="429" left="108" width="601" height="16" font="1">response if a client tries to set Log_Enable to TRUE. Possible responses would be </text> <text top="450" left="108" width="457" height="16" font="1">a) allow the change, and subsequently ignore Stop_When_Full </text> <text top="471" left="108" width="483" height="16" font="1">b) accept the WriteProperty request, but leave the value at FALSE </text> <text top="492" left="108" width="294" height="16" font="1">c) give an error return (but which one?). </text> <text top="513" left="108" width="5" height="16" font="1"> </text> <text top="534" left="108" width="665" height="16" font="2">Interpretation: If Stop_When_Full is TRUE and Log_Enable is FALSE, a Write Property </text> <text top="555" left="108" width="638" height="16" font="1">[Multiple] request to set Log_Enable to TRUE will be accepted, but will have no effect. </text> <text top="576" left="108" width="5" height="16" font="1"> </text> <text top="597" left="108" width="292" height="16" font="2">Question: Is this interpretation correct? </text> <text top="618" left="108" width="5" height="16" font="1"> </text> <text top="639" left="108" width="100" height="16" font="2">Answer: No. </text> <text top="660" left="108" width="5" height="16" font="1"> </text> <text top="681" left="108" width="694" height="16" font="2">Comments: When this situation occurs, the write request shall fail and the device shall return a </text> <text top="702" left="108" width="601" height="16" font="1">Result(-). The error class returned shall be PROPERTY and the error code shall be </text> <text top="723" left="108" width="219" height="16" font="1">WRITE_ACCESS_DENIED. </text> <text top="744" left="108" width="5" height="16" font="1"> </text> <text top="765" left="108" width="687" height="16" font="1">The committee determined that although the language describing WRITE_ACCESS_DENIED </text> <text top="786" left="108" width="696" height="16" font="1">appears restrictive it is not the intent of the standard to restrict its use in such a manner. As such </text> <text top="807" left="108" width="701" height="16" font="1">the error code will be modified in a future revision to be "An attempt has been made to write to a </text> <text top="828" left="108" width="670" height="16" font="1">property that at the time of the write request is inaccessible through the BACnet protocol write </text> <text top="849" left="108" width="68" height="16" font="1">services."</text> <text top="851" left="176" width="4" height="14" font="0"> </text> </page> </pdf2xml> Interpretation 135-2004-6 - February 5, 2005 2005-02-05 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-6.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="486" width="4" height="14" font="0"> </text> <text top="1099" left="540" width="238" height="14" font="0">©2005 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="306" width="311" height="16" font="2">INTERPRETATION IC 135-2004-6 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="339" width="244" height="16" font="1">Approval Date: February 5, 2005 </text> <text top="218" left="459" width="5" height="16" font="1"> </text> <text top="239" left="108" width="218" height="16" font="2">Request from: David White (</text> <text top="239" left="326" width="217" height="16" font="3">whited@andovercontrols.com</text> <text top="239" left="543" width="230" height="16" font="1">) Andover Controls, Corp., 300 </text> <text top="260" left="108" width="275" height="16" font="1">Brickstone Sq., Andover, MA 01810 </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="589" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="553" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Section 12.24.8, Exception_Schedule. </text> <text top="345" left="108" width="5" height="16" font="1"> </text> <text top="366" left="108" width="698" height="16" font="2">Background: The standard defines BACnetDateRange as a sequence of StartDate and endDate, </text> <text top="387" left="108" width="691" height="16" font="1">both of which have type Date. A Date consists of the fields year, month, day-of-month and day-</text> <text top="408" left="108" width="395" height="16" font="1">of-week, any of which may be unspecified (wildcard). </text> <text top="429" left="108" width="5" height="16" font="1"> </text> <text top="450" left="108" width="588" height="16" font="1">An Exception_Schedule (Section 12.24.8) may include a BACnetDateRange in a </text> <text top="471" left="108" width="652" height="16" font="1">BACnetCalendarEntry, in which context the meaning is specified for a Date that is totally </text> <text top="492" left="108" width="697" height="16" font="1">unspecified. However no indication is given regarding the validity or meaning of other wildcard </text> <text top="513" left="108" width="701" height="16" font="1">combinations. A Schedule’s Effective_Period (Section 12.24.6) is also a BACnetDateRange, but </text> <text top="534" left="108" width="384" height="16" font="1">the standard is silent on the issue of wildcard values. </text> <text top="555" left="108" width="5" height="16" font="1"> </text> <text top="576" left="108" width="703" height="16" font="2">Interpretation: The BACnet standard [ANSI/ASHRAE Standard 135-2004] is open to multiple </text> <text top="597" left="108" width="701" height="16" font="1">interpretations regarding the meaning of wildcards in dates, especially when used to specify date </text> <text top="618" left="108" width="698" height="16" font="1">ranges. The following describes how wildcards are interpreted by the Andover Controls B-AAC </text> <text top="639" left="108" width="642" height="16" font="1">controllers, especially in the context of the Schedule properties Exception_Schedule and </text> <text top="660" left="108" width="389" height="16" font="1">Effective_Period, and the Calend property Date_List. </text> <text top="681" left="108" width="679" height="16" font="1">For purposes of comparing dates, the day-of-week fields are not used. That is, they are totally </text> <text top="702" left="108" width="669" height="16" font="1">redundant. When comparing dates, a wildcard field is considered equal to the corresponding </text> <text top="723" left="108" width="705" height="16" font="1">field in the date being compared. A date falls within the range if it is not before the StartDate and </text> <text top="744" left="108" width="161" height="16" font="1">not after the endDate. </text> <text top="764" left="108" width="677" height="16" font="1">Because the day-of-week field is redundant, its value must be either unspecified or consistent </text> <text top="785" left="108" width="699" height="16" font="1">with the other fields. Because it can be consistent with those fields only if they are specified, the </text> <text top="806" left="108" width="679" height="16" font="1">controllers allow the day-of-week to be specified only if the other three fields are specified as </text> <text top="827" left="108" width="40" height="16" font="1">well. </text> <text top="848" left="108" width="671" height="16" font="1">Accordingly, the following conditions in a date range are treated as errors and will prevent a </text> <text top="869" left="108" width="237" height="16" font="1">WriteProperty from completing: </text> <text top="890" left="108" width="657" height="16" font="1">1. A day-of-week is specified but two or fewer of the other fields in the Date are specified. </text> <text top="911" left="108" width="667" height="16" font="1">2. A day-of-week is specified, but is inconsistent with the Date specified by the other fields. </text> <text top="932" left="108" width="549" height="16" font="1">3. A year field is specified, which is outside the range limit of 1989 – 2105. </text> <text top="953" left="108" width="322" height="16" font="1">4. The endDate is earlier than the StartDate. </text> <text top="974" left="108" width="542" height="16" font="1">5. Any of the specified fields are out of range (e.g., 31st day of February). </text> <text top="995" left="108" width="5" height="16" font="1"> </text> <text top="1016" left="108" width="699" height="16" font="1">This interpretation has been implemented and was accepted by the BACnet Testing Laboratory. </text> <text top="1037" left="108" width="702" height="16" font="1">It is included in the PIC Statement for certified B-AAC devices. It needs to be formally accepted </text> <text top="1058" left="108" width="216" height="16" font="1">as the correct interpretation. </text> <text top="1079" left="108" width="5" height="16" font="1"> </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="486" width="4" height="14" font="0"> </text> <text top="1099" left="540" width="238" height="14" font="0">©2005 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="108" width="292" height="16" font="2">Question: Is this interpretation correct? </text> <text top="112" left="108" width="5" height="16" font="1"> </text> <text top="134" left="108" width="106" height="16" font="2">Answer: Yes. </text> <text top="154" left="108" width="5" height="16" font="1"> </text> <text top="176" left="108" width="685" height="16" font="2">Comments: The committee agrees that the standard is ambiguous with respect to wildcards in </text> <text top="197" left="108" width="618" height="16" font="1">BACnetDate values in numerous places in the standard. This is one of many possible </text> <text top="218" left="108" width="478" height="16" font="1">interpretations (excluding the incorrect year range specified in 3). </text> <text top="248" left="108" width="654" height="16" font="1">The committee is working on developing a comprehensive proposal to address all areas of </text> <text top="269" left="108" width="334" height="16" font="1">BACnetDate value ambiguity in the standard. </text> </page> </pdf2xml> Interpretation 135-2004-7 - February 5, 2005 2005-02-05 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-7.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="486" width="4" height="14" font="0"> </text> <text top="1099" left="540" width="238" height="14" font="0">©2005 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="306" width="311" height="16" font="2">INTERPRETATION IC 135-2004-7 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="339" width="244" height="16" font="1">Approval Date: February 5, 2005 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="678" height="16" font="2">Request from: Craig Gemmill (craig.gemmill@tridium.com), 3951 Westerre Parkway, Suite </text> <text top="260" left="108" width="204" height="16" font="1">350, Richmond, VA 23233 </text> <text top="281" left="108" width="9" height="16" font="1"> </text> <text top="303" left="108" width="589" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="477" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Sections K.5.15 and K.5.16. </text> <text top="345" left="108" width="5" height="16" font="1"> </text> <text top="366" left="108" width="663" height="16" font="2">Background: The ReinitializeDevice service is used to instruct a remote device to perform </text> <text top="387" left="108" width="685" height="16" font="1">restart or reset-type functionality. In Addendum c to 135-1995, the ReinitializeDevice service </text> <text top="408" left="108" width="679" height="16" font="1">was modified to allow for the backing up of, and restoring of BACnet devices. There are two </text> <text top="429" left="108" width="676" height="16" font="1">BIBBs for indicating support for the client and server sides of the ReinitializeDevice service, </text> <text top="450" left="108" width="687" height="16" font="1">Device Management-Reinitialize Device-A (DM-RD-A) and Device Management-Reinitialize </text> <text top="471" left="108" width="660" height="16" font="1">Device-B (DM-RD-B), respectively. Although I have been unable to find this requirement </text> <text top="492" left="108" width="620" height="16" font="1">explicitly mentioned in either 135-2004, or 135.1-2003, I understand from committee </text> <text top="513" left="108" width="697" height="16" font="1">discussions that the general contract for claiming support for a service is that a device be able to </text> <text top="534" left="108" width="679" height="16" font="1">execute all forms of the service in order to claim support for the service. If a device has to be </text> <text top="555" left="108" width="666" height="16" font="1">able to support all forms of the ReinitializeDevice service, including the backup and restore </text> <text top="575" left="108" width="651" height="16" font="1">options added later, then this does two things: (1) it retroactively invalidates the claims of </text> <text top="596" left="108" width="702" height="16" font="1">devices developed prior to 135c-2005 that do not support the backup and restore options, and (2) </text> <text top="617" left="108" width="698" height="16" font="1">it makes BIBBs DM-BR-A (K.5.17) and DM-BR-B (K.5.18) redundant, since a device claiming </text> <text top="638" left="108" width="697" height="16" font="1">DM-RD-A/B would already support DM-BR-A/B. Should a device be able to claim support for </text> <text top="659" left="108" width="664" height="16" font="1">a DM-RD-A/B BIBB without including support for the corresponding DM-BR-A/B BIBB? </text> <text top="680" left="108" width="5" height="16" font="1"> </text> <text top="702" left="108" width="685" height="16" font="2">Interpretation: Devices may claim DM-RD-A/B without supporting the Backup and Restore </text> <text top="723" left="108" width="704" height="16" font="1">procedures. A DM-RD-A device does not need to be able to initiate a ReinitializeDevice request </text> <text top="744" left="108" width="701" height="16" font="1">with any of the backup or restore parameters. Similarly, a DM-RD-B device does not need to be </text> <text top="764" left="108" width="570" height="16" font="1">able to carry out the Backup procedure, and may return an error if it receives a </text> <text top="785" left="108" width="526" height="16" font="1">ReinitializeDevice request with any of the backup or restore parameters. </text> <text top="806" left="108" width="5" height="16" font="1"> </text> <text top="828" left="108" width="292" height="16" font="2">Question: Is this interpretation correct? </text> <text top="849" left="108" width="5" height="16" font="1"> </text> <text top="870" left="108" width="106" height="16" font="2">Answer: Yes </text> <text top="891" left="108" width="5" height="16" font="1"> </text> <text top="912" left="108" width="695" height="16" font="2">Comments: The standard will be updated to indicate that a device is allowed support execution </text> <text top="933" left="108" width="660" height="16" font="1">of the ReinitializeDevice and not support execution of the forms of the service used for the </text> <text top="954" left="108" width="238" height="16" font="1">Backup and Restore procedures. </text> </page> </pdf2xml> Interpretation 135-2004-8 - June 25, 2005 2005-06-25 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-8.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="486" width="4" height="14" font="0"> </text> <text top="1099" left="540" width="238" height="14" font="0">©2005 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="306" width="311" height="16" font="2">INTERPRETATION IC 135-2004-8 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="351" width="221" height="16" font="1">Approval Date: June 25, 2005 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="217" height="16" font="2">Request from: Carl Neilson (</text> <text top="239" left="325" width="205" height="16" font="3">cneilson@deltacontrols.com</text> <text top="239" left="531" width="250" height="16" font="1">) Delta Controls, 61 Seagirt Road, </text> <text top="260" left="108" width="199" height="16" font="1">East Sooke, BC V0S 1N0 </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="589" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="603" height="16" font="1">ANSI/ASHRAE Standard 135-2004 in the following sections and tables relating to </text> <text top="345" left="108" width="413" height="16" font="1">FLOATING_LIMIT and OUT_OF_RANGE transitions: </text> <text top="366" left="108" width="5" height="16" font="1"> </text> <text top="382" left="135" width="445" height="22" font="1">• Sections 12.2.19-12.2.21 (Analog Input) (pages 140-141) </text> <text top="404" left="135" width="457" height="22" font="1">• Sections 12.3.20-12.3.22 (Analog Output) (pages 145-146) </text> <text top="426" left="135" width="450" height="22" font="1">• Sections 12.4.16-12.4.18 (Analog Value) (pages 150-151) </text> <text top="448" left="135" width="290" height="22" font="1">• Section 12.17.32 (Loop) (page 211) </text> <text top="470" left="135" width="484" height="22" font="1">• Sections 12.23.22-12.23.24 (Pulse Converter) (pages 238-239) </text> <text top="493" left="135" width="450" height="22" font="1">• Section 13.3.5 FLOATING_LIMIT Algorithm (page 262) </text> <text top="515" left="135" width="441" height="22" font="1">• Section 13.3.6 OUT_OF_RANGE Algorithm (page 263) </text> <text top="537" left="135" width="610" height="22" font="1">• Table 13.2, Standard Objects That May Supporty Intrinsic Reporting (page 256) </text> <text top="564" left="108" width="5" height="16" font="1"> </text> <text top="585" left="108" width="658" height="16" font="2">Background: It is not clear from the text and the state diagrams whether event transitions </text> <text top="606" left="108" width="675" height="16" font="1">directly from High_Limit to Low_Limit are expected, or whether an intervening transition to </text> <text top="627" left="108" width="691" height="16" font="1">Normal is expected. The state diagrams specifically do not have such a transition indicated, but </text> <text top="648" left="108" width="673" height="16" font="1">the text is not as clear. This issue has been raised a number of times within different BACnet </text> <text top="669" left="108" width="694" height="16" font="1">groups and there does not seem to be general concensus among those reading the standard what </text> <text top="690" left="108" width="179" height="16" font="1">the correct behaviour is. </text> <text top="711" left="108" width="5" height="16" font="1"> </text> <text top="732" left="108" width="693" height="16" font="2">Interpretation: An object that reports FLOATING_LIMIT or OUT_OF_RANGE events shall </text> <text top="753" left="108" width="629" height="16" font="1">not generate TO-OFFNORMAL transitions from an OFFNORMAL (LOW_LIMIT, or </text> <text top="774" left="108" width="157" height="16" font="1">HIGH_LIMIT) state. </text> <text top="795" left="108" width="5" height="16" font="1"> </text> <text top="816" left="108" width="292" height="16" font="2">Question: Is this interpretation correct? </text> <text top="837" left="108" width="5" height="16" font="1"> </text> <text top="858" left="108" width="111" height="16" font="2">Answer: Yes. </text> <text top="879" left="108" width="5" height="16" font="1"> </text> <text top="900" left="108" width="693" height="16" font="2">Comments: This interpretation is correct, but the committee wants to clarify the issue with the </text> <text top="921" left="108" width="691" height="16" font="1">broader interpretation that objects must follow the state machines as indicated in Clause 13 and </text> <text top="942" left="108" width="672" height="16" font="1">therefore may not transition directly from the High Limit state to the Low Limit state or vice </text> <text top="963" left="108" width="626" height="16" font="1">versa. It is also part of this interpretation that the delay timer is reset on each of these </text> <text top="984" left="108" width="703" height="16" font="1">transitions. As an example, if the object is in the High Limit state and the value drops directly to </text> <text top="1005" left="108" width="667" height="16" font="1">below the Low Limit, then, after one delay time, the object would transmit a TO-NORMAL </text> <text top="1026" left="108" width="675" height="16" font="1">event, if so enabled, and enter the Normal state, and then, after another time delay, the object </text> <text top="1047" left="108" width="630" height="16" font="1">would transmit an OFF-NORMAL event, if so enabled, and enter the Low Limit State. </text> </page> </pdf2xml> Interpretation 135-2004-9 - June 25, 2005 2005-06-25 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-9.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="486" width="4" height="14" font="0"> </text> <text top="1099" left="540" width="238" height="14" font="0">©2005 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="306" width="311" height="16" font="2">INTERPRETATION IC 135-2004-9 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="351" width="221" height="16" font="1">Approval Date: June 25, 2005 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="246" height="16" font="2">Request from: Rene Quirighetti (</text> <text top="239" left="354" width="221" height="16" font="3">rene.quirighetti@siemens.com</text> <text top="239" left="575" width="181" height="16" font="1">), Siemens Schweiz AG, </text> <text top="260" left="108" width="324" height="16" font="1">Gubelstrasse 22, Zug, Switzerland CH-6300 </text> <text top="260" left="432" width="5" height="16" font="3"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="589" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="687" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Sections 12.1-12.4, 12.6-12.8, 12.15-12.20, 12.23, 12.25, </text> <text top="345" left="108" width="556" height="16" font="1">and the corresponding tables in these sections, relating to intrinsic reporting. </text> <text top="366" left="108" width="5" height="16" font="1"> </text> <text top="387" left="108" width="687" height="16" font="2">Background: The BACnet Standard uses at numerous places the expression "object". For non-</text> <text top="408" left="108" width="668" height="16" font="1">native English speakers it is not obvious whether the term identifies an object instance or an </text> <text top="429" left="108" width="660" height="16" font="1">object type. This distinction is important in the mentioned sections (and crresponding table </text> <text top="450" left="108" width="644" height="16" font="1">footnotes), where the standard reads "These properties are required if the object supports </text> <text top="471" left="108" width="695" height="16" font="1">intrinsic reporting." If the term identifies an object instance, a device may contain objects of the </text> <text top="492" left="108" width="406" height="16" font="1">same type with and without intrinsic reporting support.. </text> <text top="513" left="108" width="5" height="16" font="1"> </text> <text top="534" left="108" width="706" height="16" font="2">Interpretation: The expression "object" identifies an object instance throughtout the standard. A </text> <text top="555" left="108" width="655" height="16" font="1">BACnet device may contain objects of the same type with and without support of intrinsic </text> <text top="576" left="108" width="75" height="16" font="1">reporting. </text> <text top="597" left="108" width="5" height="16" font="1"> </text> <text top="618" left="108" width="292" height="16" font="2">Question: Is this interpretation correct? </text> <text top="639" left="108" width="5" height="16" font="1"> </text> <text top="660" left="108" width="102" height="16" font="2">Answer: Yes </text> <text top="681" left="108" width="5" height="16" font="1"> </text> <text top="702" left="108" width="679" height="16" font="2">Comments: Throughout the standard, "object type" is used to refer to the data structures and </text> <text top="723" left="108" width="691" height="16" font="1">their characteristics defined in Clause 12 while the term "object" by itself has been consistently </text> <text top="744" left="108" width="688" height="16" font="1">used to refer to an instance of a particular object type. It is also intended that specific instances </text> <text top="765" left="108" width="685" height="16" font="1">of a particular object type may implement whichever optional properties are appropriate to the </text> <text top="786" left="108" width="697" height="16" font="1">application of that object instance so that, for example, not all object instances in a given device </text> <text top="807" left="108" width="601" height="16" font="1">are required to support intrinsic reporting although some instances optionally may. </text> </page> </pdf2xml> Interpretation 135-2004-10 - June 25, 2005 2005-06-25 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-10.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="486" width="4" height="14" font="0"> </text> <text top="1099" left="540" width="238" height="14" font="0">©2005 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2004-10 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="351" width="221" height="16" font="1">Approval Date: June 25, 2005 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="238" height="16" font="2">Request from: James F. Butler (</text> <text top="239" left="346" width="184" height="16" font="3">jimbutler@cimetrics.com</text> <text top="239" left="530" width="283" height="16" font="1">) Cimetrics, Inc., 125 Summer St., Ste. </text> <text top="260" left="108" width="184" height="16" font="1">2100, Boston, MA 02110</text> <text top="260" left="292" width="5" height="16" font="3"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="589" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="696" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Section 6.6.1, Routing Tables, and Section 6.6.3.6, Router-</text> <text top="345" left="108" width="141" height="16" font="1">Busy-To-Network. </text> <text top="366" left="108" width="5" height="16" font="1"> </text> <text top="387" left="108" width="682" height="16" font="2">Background: Section 6.6.3.6 specifies how a “busy” router may broadcast a Router-Busy-To-</text> <text top="408" left="108" width="702" height="16" font="1">Network message in order to temporarily curtail network traffic to that router. Other routers that </text> <text top="429" left="108" width="666" height="16" font="1">receive that message are required to update their routing tables to indicate that the networks </text> <text top="450" left="108" width="694" height="16" font="1">served by the busy router are temporarily unreachable. While a router is busy, it will transmit a </text> <text top="471" left="108" width="697" height="16" font="1">Reject-Message-To-Network message with reject reason 2 if it receives a message that it cannot </text> <text top="492" left="108" width="694" height="16" font="1">handle. There appears to be no clear statement in Standard 135-2004 about what another router </text> <text top="513" left="108" width="662" height="16" font="1">should do if it receives a message that should be forwarded to a network that is temporarily </text> <text top="534" left="108" width="695" height="16" font="1">unreachable, but Section 10.2.2.4.3 of ANSI/ASHRAE Standard 135.1-2003 contains a test that </text> <text top="555" left="108" width="696" height="16" font="1">requires that a Reject-Message-To-Network with reject reason 2 be transmitted in that situation. </text> <text top="575" left="108" width="5" height="16" font="1"> </text> <text top="597" left="108" width="679" height="16" font="2">Interpretation: If a router receives a message that is destined for a particular network that is </text> <text top="618" left="108" width="637" height="16" font="1">marked as temporarily unreachable in the routing table, then the router must respond by </text> <text top="639" left="108" width="535" height="16" font="1">transmitting a Reject-Message-To-Network message with reject reason 2. </text> <text top="660" left="108" width="5" height="16" font="1"> </text> <text top="681" left="108" width="292" height="16" font="2">Question: Is this interpretation correct? </text> <text top="702" left="108" width="5" height="16" font="1"> </text> <text top="723" left="108" width="106" height="16" font="2">Answer: Yes. </text> <text top="744" left="108" width="5" height="16" font="1"> </text> <text top="765" left="108" width="141" height="16" font="2">Comments: (none)</text> <text top="767" left="249" width="4" height="14" font="0"> </text> </page> </pdf2xml> Interpretation 135-2004-11 - June 25, 2005 2005-06-25 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-11.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="486" width="4" height="14" font="0"> </text> <text top="1099" left="540" width="238" height="14" font="0">©2005 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2004-11 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="351" width="221" height="16" font="1">Approval Date: June 25, 2005 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="238" height="16" font="2">Request from: James F. Butler (</text> <text top="239" left="346" width="184" height="16" font="3">jimbutler@cimetrics.com</text> <text top="239" left="530" width="283" height="16" font="1">) Cimetrics, Inc., 125 Summer St., Ste. </text> <text top="260" left="108" width="184" height="16" font="1">2100, Boston, MA 02110</text> <text top="260" left="292" width="9" height="16" font="3"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="589" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="697" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Section 12.25.14, Log_Buffer, and Section 15.7.3.1.2, List </text> <text top="345" left="108" width="175" height="16" font="1">of Property References. </text> <text top="366" left="108" width="5" height="16" font="1"> </text> <text top="387" left="108" width="703" height="16" font="2">Background: A ReadPropertyMultiple service request may include the property identifiers ALL </text> <text top="408" left="108" width="671" height="16" font="1">and REQUIRED (Section 15.7.3.1.2). The property identifier ALL means that all properties </text> <text top="429" left="108" width="697" height="16" font="1">from the specified object shall be included in the response. The property identifier REQUIRED </text> <text top="450" left="108" width="696" height="16" font="1">means that all properties of the specified object having a conformance code of “R” or “W” shall </text> <text top="471" left="108" width="703" height="16" font="1">be included in the response. However, the specification of the Log_Buffer property of the Trend </text> <text top="492" left="108" width="660" height="16" font="1">Log object (Section 12.25.14) states that the buffer is only accessible using the ReadRange </text> <text top="513" left="108" width="690" height="16" font="1">service. Note that the Log_Buffer property has conformance code “R” in the Trend Log object </text> <text top="534" left="108" width="136" height="16" font="1">(see Table 12-29). </text> <text top="555" left="108" width="5" height="16" font="1"> </text> <text top="576" left="108" width="666" height="16" font="2">Interpretation: The value of the Log_Buffer property of the Trend Log object shall not be </text> <text top="597" left="108" width="685" height="16" font="1">returned in the response to a ReadPropertyMultiple request. If the property identifiers ALL or </text> <text top="618" left="108" width="702" height="16" font="1">REQUIRED are present in the ReadPropertyMultiple request then the Log_Buffer property shall </text> <text top="639" left="108" width="383" height="16" font="1">not appear in the corresponding part of the response. </text> <text top="660" left="108" width="5" height="16" font="1"> </text> <text top="681" left="108" width="292" height="16" font="2">Question: Is this interpretation correct? </text> <text top="702" left="108" width="5" height="16" font="1"> </text> <text top="723" left="108" width="100" height="16" font="2">Answer: No. </text> <text top="744" left="108" width="5" height="16" font="1"> </text> <text top="765" left="108" width="684" height="16" font="2">Comments: When answering a request for the property ALL or REQUIRED, a device has the </text> <text top="786" left="108" width="633" height="16" font="1">option to either include the Log_Buffer property in the response with the error class of </text> <text top="807" left="108" width="671" height="16" font="1">PROPERTY and an error code READ_ACCESS_DENIED or the device may choose to not </text> <text top="828" left="108" width="397" height="16" font="1">include the Log_Buffer property in the response at all. </text> <text top="848" left="108" width="4" height="14" font="0"> </text> </page> </pdf2xml> Interpretation 135-2004-12 - June 25, 2005 2005-06-25 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-12.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="486" width="4" height="14" font="0"> </text> <text top="1099" left="540" width="238" height="14" font="0">©2005 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2004-12 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="351" width="221" height="16" font="1">Approval Date: June 25, 2005 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="238" height="16" font="2">Request from: James F. Butler (</text> <text top="239" left="346" width="184" height="16" font="3">jimbutler@cimetrics.com</text> <text top="239" left="530" width="283" height="16" font="1">) Cimetrics, Inc., 125 Summer St., Ste. </text> <text top="260" left="108" width="184" height="16" font="1">2100, Boston, MA 02110</text> <text top="260" left="292" width="9" height="16" font="3"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="589" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="682" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Section 6.4.4, Reject-Message-To-Network, and Section </text> <text top="345" left="108" width="278" height="16" font="1">6.6.3.5, Reject-Message-To-Network. </text> <text top="366" left="108" width="5" height="16" font="1"> </text> <text top="387" left="108" width="689" height="16" font="2">Background: The Reject-Message-To-Network message includes a 1-octet reject reason and a </text> <text top="408" left="108" width="705" height="16" font="1">2-octet network number. Reject reason 3 indicates that the device received a message containing </text> <text top="429" left="108" width="688" height="16" font="1">an unknown network layer message type. The standard provides no clear guidance about what </text> <text top="450" left="108" width="644" height="16" font="1">network number should be sent when the reject reason is 3. However, the test defined in </text> <text top="471" left="108" width="695" height="16" font="1">ANSI/ASHRAE Standard 135.1-2003 Section 10.2.2.7.2 requires that the network number field </text> <text top="492" left="108" width="179" height="16" font="1">contain a specific value. </text> <text top="513" left="108" width="5" height="16" font="1"> </text> <text top="534" left="108" width="665" height="16" font="2">Interpretation: In a Reject-Message-To-Network message, when the reject reason is 3, the </text> <text top="555" left="108" width="686" height="16" font="1">meaning of the value in the network number field is undefined and therefore this value may be </text> <text top="576" left="108" width="181" height="16" font="1">ignored by the recipient. </text> <text top="597" left="108" width="5" height="16" font="1"> </text> <text top="618" left="108" width="292" height="16" font="2">Question: Is this interpretation correct? </text> <text top="639" left="108" width="5" height="16" font="1"> </text> <text top="660" left="108" width="111" height="16" font="2">Answer: Yes. </text> <text top="681" left="108" width="5" height="16" font="1"> </text> <text top="702" left="108" width="641" height="16" font="2">Comments: The committee will change the test in question to reflect this interpretation. </text> </page> </pdf2xml> Interpretation 135-2004-13 - June 25, 2005 2005-06-25 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-13.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="14" family="Times" color="#000000"/> <fontspec id="4" size="14" family="Times" color="#000000"/> <fontspec id="5" size="14" family="Times" color="#0000ff"/> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="486" width="4" height="14" font="0"> </text> <text top="1099" left="540" width="238" height="14" font="0">©2005 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2004-13 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="351" width="221" height="16" font="1">Approval Date: June 25, 2005 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="199" height="15" font="3">Request from: Carl Neilson (</text> <text top="239" left="307" width="188" height="15" font="5">cneilson@deltacontrols.com</text> <text top="239" left="494" width="311" height="15" font="4">) Delta Controls, 61 Seagirt Road, East Sooke, </text> <text top="258" left="108" width="100" height="15" font="4">BC V0S 1N0. </text> <text top="277" left="108" width="8" height="15" font="4"> </text> <text top="297" left="108" width="652" height="15" font="3">Reference: This request for interpretation refers to the requirements presented in ANSI/ASHRAE </text> <text top="316" left="108" width="650" height="15" font="4">Standard 135-2004, Sections 12.1.10, 12.2.10, 12.3.10, 12.4.9, 12.6.10, 12.7.10, 12.8.9, 12.15.11, </text> <text top="335" left="108" width="691" height="15" font="4">12.16.11, 12.17.9, 12.18.10, 12.19.10, 12.20.9, 12.23.10, relating to the Reliability and Out_Of_Service </text> <text top="354" left="108" width="74" height="15" font="4">properties. </text> <text top="373" left="108" width="4" height="15" font="4"> </text> <text top="392" left="108" width="693" height="15" font="3">Background: The Reliability property exists as an optional property in numerous object types. In some </text> <text top="411" left="108" width="670" height="15" font="4">of those object types (Accumulator, Analog Input, Binary Input, Life Safety Point, Life Safety Zone, </text> <text top="431" left="108" width="688" height="15" font="4">Multi-state Input, Multi-state Output, Multi-state Value, Pulse Converter, ) the standard implies that the </text> <text top="450" left="108" width="436" height="15" font="4">property shall be made writable when Out_Of_Service is TRUE. </text> <text top="469" left="108" width="4" height="15" font="4"> </text> <text top="488" left="108" width="662" height="15" font="4">An example of this is in Section 12.1.10, the second last sentence reads "While the Out_Of_Service </text> <text top="507" left="108" width="702" height="15" font="4">property is TRUE, the Present_Value, Pulse_Rate and Reliability properties may be changed to any value </text> <text top="526" left="108" width="501" height="15" font="4">as a means of simulating specific fixed conditions or for testing purposes." </text> <text top="545" left="108" width="4" height="15" font="4"> </text> <text top="564" left="108" width="702" height="15" font="4">In the Analog Output, Binary Output object, the equivalent sentence reads slightly differently: "While the </text> <text top="583" left="108" width="693" height="15" font="4">Out_Of_Service property is TRUE, the Present_Value and Reliability properties may still be changed to </text> <text top="602" left="108" width="569" height="15" font="4">any value as a means of simulating specific fixed conditions or for testing purposes." </text> <text top="621" left="108" width="4" height="15" font="4"> </text> <text top="640" left="108" width="582" height="15" font="4">In other object types (Analog Value, Binary Value, Loop), there is no such implication. </text> <text top="660" left="108" width="4" height="15" font="4"> </text> <text top="679" left="108" width="688" height="15" font="3">Interpretation: The Reliability property shall be writable, in all object types, when Out_Of_Service is </text> <text top="698" left="108" width="676" height="15" font="4">TRUE and in the case of the Accumulator object, the Pusle_Rate property shall also be writable when </text> <text top="717" left="108" width="191" height="15" font="4">Out_Of_Service is TRUE. </text> <text top="736" left="108" width="4" height="15" font="4"> </text> <text top="756" left="108" width="267" height="15" font="3">Question: Is this interpretation correct? </text> <text top="775" left="108" width="4" height="15" font="4"> </text> <text top="794" left="108" width="88" height="15" font="3">Answer: No </text> <text top="813" left="108" width="4" height="15" font="4"> </text> <text top="833" left="108" width="701" height="15" font="3">Comments: Reliability is not required to be writable when Out_Of_Service is TRUE for any object type. </text> <text top="852" left="108" width="693" height="15" font="4">While the committee agreed that the concept outlined in the interpretation is desirable, the standard does </text> <text top="871" left="108" width="274" height="15" font="4">not currently mandate this functionality. </text> <text top="890" left="108" width="4" height="15" font="4"> </text> <text top="909" left="108" width="680" height="15" font="4">The committee originally drafted the language so as to describe a mechanism that allows the testing of </text> <text top="928" left="108" width="681" height="15" font="4">specific system conditions. It was not the intention of the committee to mandate support for the testing </text> <text top="947" left="108" width="659" height="15" font="4">mechanism. The committee also felt that it would be reasonable that the changing of the Reliability </text> <text top="966" left="108" width="421" height="15" font="4">property be supported through a proprietary configuration tool. </text> <text top="986" left="108" width="5" height="16" font="1"> </text> </page> </pdf2xml> Interpretation 135-2004-14 - September 28, 2005 2005-09-28 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-14.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="14" family="Times" color="#000000"/> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="486" width="4" height="14" font="0"> </text> <text top="1099" left="540" width="238" height="14" font="0">©2006 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2004-14 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="364" width="194" height="16" font="1">Approval Date: 9/28/2005 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="206" height="16" font="2">Request from: Steve Karg (</text> <text top="239" left="314" width="218" height="16" font="3">steve.karg@acuitybrands.com</text> <text top="239" left="532" width="274" height="16" font="1">), Lithonia Lighting, 1 Lithonia Way, </text> <text top="260" left="108" width="153" height="16" font="1">Conyers, GA 30112. </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="589" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="627" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Section 6.3.2, relating to Network Layer routing. </text> <text top="345" left="108" width="5" height="16" font="1"> </text> <text top="366" left="108" width="695" height="16" font="2">Background: When using a BACnet router between BACnet/IP and ARCNET behind a Belkin </text> <text top="387" left="108" width="699" height="16" font="1">Firewall/Router, the Belkin router would re-broadcast packets that were sent as broadcast on the </text> <text top="408" left="108" width="673" height="16" font="1">IP network. The BACnet router, following the wording in Section 6.3.2, would simply route </text> <text top="429" left="108" width="700" height="16" font="1">those messages to all the networks except the network of origin (the IP network). The broadcast </text> <text top="450" left="108" width="637" height="16" font="1">messages originated from the ARCNET network, but would then be re-broadcast on the </text> <text top="471" left="108" width="680" height="16" font="1">ARCNET network by the router after being received from the Belkin IP router. The SNET in </text> <text top="492" left="108" width="691" height="16" font="1">the message then reflects a remote network number for local device addresses on the ARCNET </text> <text top="513" left="108" width="265" height="16" font="1">network, and dynamic binding fails. </text> <text top="534" left="108" width="5" height="16" font="1"> </text> <text top="555" left="108" width="642" height="16" font="2">Interpretation: The "network of origin" in Section 6.3.2, Broadcast Messages, from the </text> <text top="576" left="108" width="683" height="16" font="1">sentence "the router shall broadcast the message on all directly connected networks except the </text> <text top="597" left="108" width="703" height="16" font="1">network of origin", includes not only the physical network where the message originated, but the </text> <text top="618" left="108" width="403" height="16" font="1">network specified by the SNET of the message as well. </text> <text top="639" left="108" width="5" height="16" font="1"> </text> <text top="660" left="108" width="292" height="16" font="2">Question: Is this interpretation correct? </text> <text top="681" left="108" width="5" height="16" font="1"> </text> <text top="702" left="108" width="100" height="16" font="2">Answer: No. </text> <text top="723" left="108" width="5" height="16" font="1"> </text> <text top="744" left="108" width="652" height="16" font="2">Comments: However, the standard will be changed to require the inspection of broadcast </text> <text top="765" left="108" width="429" height="16" font="1">packets before transmission to avoid situations such as this.</text> <text top="766" left="537" width="4" height="15" font="4"> </text> <text top="767" left="541" width="4" height="14" font="0"> </text> <text top="786" left="108" width="5" height="16" font="1"> </text> </page> </pdf2xml> Interpretation 135-2004-15 - September 28, 2005 2005-09-28 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-15.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="486" width="4" height="14" font="0"> </text> <text top="1099" left="540" width="238" height="14" font="0">©2006 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2004-15 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="364" width="194" height="16" font="1">Approval Date: 9/28/2005 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="243" height="16" font="2">Request from: James F. Butler (</text> <text top="239" left="351" width="184" height="16" font="3">jimbutler@cimetrics.com</text> <text top="239" left="535" width="251" height="16" font="1">) Cimetrics, Inc., 125 Summer St., </text> <text top="260" left="108" width="216" height="16" font="1">Ste. 2100, Boston, MA 02110</text> <text top="260" left="324" width="5" height="16" font="3"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="594" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="639" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Annex J – BACnet/IP, specifically Section J.2.6.1, </text> <text top="345" left="108" width="250" height="16" font="1">Register-Foreign-Device: Format. </text> <text top="366" left="108" width="5" height="16" font="1"> </text> <text top="387" left="108" width="646" height="16" font="2">Background: My recollection is that a draft of Annex J (BACnet/IP) contained text that </text> <text top="408" left="108" width="704" height="16" font="1">allowed foreign devices to register for an indefinite period by sending a Register-Foreign-Device </text> <text top="429" left="108" width="670" height="16" font="1">message to a BBMD with the Time-to-Live parameter value of zero. Indefinite (permanent) </text> <text top="450" left="108" width="640" height="16" font="1">foreign device registration is not mentioned in the version of Annex J that was officially </text> <text top="471" left="108" width="668" height="16" font="1">published, but some tests in ASHRAE Standard 135.1-2003 (such as Section 14.6.2) rely on </text> <text top="492" left="108" width="691" height="16" font="1">indefinite foreign device registration. I believe that SSPC 135 intentionally removed indefinite </text> <text top="513" left="108" width="659" height="16" font="1">foreign device registration from Annex J before publication, and that the tests in ASHRAE </text> <text top="534" left="108" width="701" height="16" font="1">Standard 135.1 that rely on indefinite foreign device registration should be changed accordingly. </text> <text top="555" left="108" width="5" height="16" font="1"> </text> <text top="576" left="108" width="688" height="16" font="2">Interpretation: There is no provision for indefinite (permanent) foreign device registration in </text> <text top="597" left="108" width="237" height="16" font="1">the BACnet Standard 135-2004. </text> <text top="618" left="108" width="5" height="16" font="1"> </text> <text top="639" left="108" width="297" height="16" font="2">Question: Is this interpretation correct? </text> <text top="660" left="108" width="5" height="16" font="1"> </text> <text top="681" left="108" width="106" height="16" font="2">Answer: Yes. </text> <text top="702" left="108" width="5" height="16" font="1"> </text> <text top="723" left="108" width="510" height="16" font="2">Comments: The incorrect tests will be removed from Standard 135.1. </text> </page> </pdf2xml> Interpretation 135-2004-16 - June 24, 2006 2006-06-24 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-16.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="9" family="Times" color="#000000"/> <text top="1099" left="115" width="72" height="14" font="0">Page 1 of 2 </text> <text top="1099" left="216" width="582" height="14" font="0"> ©2006 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2004-16 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="351" width="221" height="16" font="1">Approval Date: June 24, 2006 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="235" height="16" font="2">Request from: David Hudson (</text> <text top="239" left="343" width="206" height="16" font="3">dhudson@deltacontrols.com</text> <text top="239" left="549" width="193" height="16" font="1">) Delta Controls, 17850 56</text> <text top="235" left="742" width="9" height="11" font="4">th</text> <text top="239" left="751" width="5" height="16" font="1"> </text> <text top="260" left="108" width="223" height="16" font="1">Avenue, Surrey, BC V3S-1C7.</text> <text top="260" left="331" width="5" height="16" font="3"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="594" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="659" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Sections 12.1.8, 12.2.8, 12.3.8, 12.4.7, 12.6.8, 12.7.8, </text> <text top="345" left="108" width="680" height="16" font="1">12.8.7, 12.17.7, 12.18.8, 12.20.7, and 12.23.8 related to Event_State and Relibility properties. </text> <text top="366" left="108" width="5" height="16" font="1"> </text> <text top="387" left="108" width="631" height="16" font="2">Background: There appear to be two different relationships between Event_State and </text> <text top="408" left="108" width="689" height="16" font="1">Reliability when intrinsic reporting is not supported in an object, depending on the object type. </text> <text top="429" left="108" width="5" height="16" font="1"> </text> <text top="450" left="108" width="685" height="16" font="1">For Analog Input, Analog Output, Analog Value, Brinary Input, Binary Output, Binary Value, </text> <text top="471" left="108" width="608" height="16" font="1">and Loop object types, Event_State (example, Section 12.2.8) is defined defined as: </text> <text top="492" left="108" width="683" height="16" font="1">The Event_State property, of type BACnetEventState, is included in order to provide a way to </text> <text top="513" left="108" width="705" height="16" font="1">determine if this object has an active event state associated with it. If the object supports intrinsic </text> <text top="534" left="108" width="693" height="16" font="1">reporting, then the Event_State property shall indicate the event state of the object. If the object </text> <text top="555" left="108" width="674" height="16" font="1">does not support intrinsic reporting, then the value of this property shall be NORMAL. If the </text> <text top="575" left="108" width="695" height="16" font="1">Reliability property is present and does not have a value of NO_FAULT_DETECTED, then the </text> <text top="596" left="108" width="688" height="16" font="1">value of the Event_State property shall be FAULT. Changes in the Event_State property to the </text> <text top="617" left="108" width="367" height="16" font="1">value FAULT are considered to be "fault" events. </text> <text top="638" left="108" width="5" height="16" font="1"> </text> <text top="659" left="108" width="579" height="16" font="1">The sentence "If the Reliability property is present and does not have a value of </text> <text top="680" left="108" width="642" height="16" font="1">NO_FAULT_DETECTED, then the value of the Event_State property shall be FAULT" </text> <text top="701" left="108" width="694" height="16" font="1">contradicts the sentence "If the object does not support intrinsic reporting, then the value of this </text> <text top="722" left="108" width="220" height="16" font="1">property shall be NORMAL." </text> <text top="743" left="108" width="5" height="16" font="1"> </text> <text top="764" left="108" width="650" height="16" font="1">The Accumulator, Mulistate Input, Multistate Value and Pulse Convertor object types, all </text> <text top="785" left="108" width="682" height="16" font="1">indicate that if the object does not support intrinsic reporting, and if the Reliability property is </text> <text top="806" left="108" width="682" height="16" font="1">present and does not have a value of NO_FAULT_DETECTED, then the value of Event State </text> <text top="827" left="108" width="127" height="16" font="1">shall be FAULT. </text> <text top="848" left="108" width="5" height="16" font="1"> </text> <text top="869" left="108" width="694" height="16" font="2">Interpretation: Our interpretation is there are two different relationships between Event_State </text> <text top="890" left="108" width="568" height="16" font="1">and Reliability when intrinsic reporting is not supported in an object. Namely: </text> <text top="911" left="108" width="705" height="16" font="1">For Analog Input, Analog Output, Analog Value, Binary Input, Binary Output, Binary Value and </text> <text top="932" left="108" width="699" height="16" font="1">Loop object types: if an object does not support intrinsic reporting then the value of Event_State </text> <text top="953" left="108" width="632" height="16" font="1">will always be NORMAL regardless of the value of Reliability if Reliability is present. </text> <text top="974" left="108" width="685" height="16" font="1">And, for Accumulator, Multistate Input, Multistate Value, and Pulse Converter object types: if </text> <text top="995" left="108" width="693" height="16" font="1">an object does not support intrinsic reporting, and if the Reliability property is present and does </text> <text top="1016" left="108" width="639" height="16" font="1">not have a value of NO_FAULT_DETECTED, then the of Event_State will be FAULT. </text> <text top="1037" left="108" width="5" height="16" font="1"> </text> <text top="1058" left="108" width="297" height="16" font="2">Question: Is this interpretation correct? </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <text top="1099" left="115" width="72" height="14" font="0">Page 2 of 2 </text> <text top="1099" left="216" width="582" height="14" font="0"> ©2006 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="108" width="5" height="16" font="1"> </text> <text top="112" left="108" width="105" height="16" font="2">Answer: No. </text> <text top="133" left="108" width="5" height="16" font="1"> </text> <text top="154" left="108" width="662" height="16" font="2">Comments: The committee agrees that the language across objects is different and that the </text> <text top="175" left="108" width="701" height="16" font="1">standard should be revised to use the same language. Until the language in the standard has been </text> <text top="196" left="108" width="673" height="16" font="1">unified, for those object types where the behavior of Event_State is inconsistently mandated, </text> <text top="217" left="108" width="477" height="16" font="1">either interpretation for Event_State behavior shall be acceptable. </text> </page> </pdf2xml> Interpretation 135-2004-17 - April 24, 2006 2006-04-24 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-17.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="115" width="688" height="14" font="0">Page 1 of 1 ©2006 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2004-17 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="348" width="226" height="16" font="1">Approval Date: April 24, 2006 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="224" height="16" font="2">Request from: Scott Lurvey (</text> <text top="239" left="332" width="158" height="16" font="3">scott.lurvey@tac.com</text> <text top="239" left="489" width="290" height="16" font="1">) TAC, 1 High St., North Andover, MA </text> <text top="260" left="108" width="50" height="16" font="1">01845.</text> <text top="260" left="157" width="5" height="16" font="3"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="594" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="564" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Section 12.25.14 regarding Log_Buffer. </text> <text top="345" left="108" width="5" height="16" font="1"> </text> <text top="366" left="108" width="654" height="16" font="2">Background: The 2004 BACnet Standard does not explicitly state whether a value in the </text> <text top="387" left="108" width="695" height="16" font="1">LogDatum portion of a BACnetLogRecord must be encoded to match the datatype of the object </text> <text top="408" left="108" width="704" height="16" font="1">and property that the TrendLog monitors. When describing the meaning of monitored data value </text> <text top="429" left="108" width="635" height="16" font="1">choices, Section 12.25.14 states that, "these choices represent data values read from the </text> <text top="450" left="108" width="673" height="16" font="1">monitored object and property". Because the word "represent" is ambiguous, this description </text> <text top="471" left="108" width="668" height="16" font="1">might allow an implementation that has a TrendLog object that monitors and collects values </text> <text top="492" left="108" width="683" height="16" font="1">about the Present_Value property of a BinaryValue object to encode these values using a Real </text> <text top="513" left="108" width="335" height="16" font="1">datatype, rather than an Enumerated datatype. </text> <text top="534" left="108" width="5" height="16" font="1"> </text> <text top="555" left="108" width="664" height="16" font="1">There are two occurrences of the current description in the LogDatum description. The first </text> <text top="575" left="108" width="672" height="16" font="1">occurrence appears in the description for the set of choices (boolean-value, real-value, enum-</text> <text top="596" left="108" width="662" height="16" font="1">value, unsigned-value, signed-value, bitstring-value, null-value) and the second occurrence </text> <text top="617" left="108" width="387" height="16" font="1">appears in the description for the any-value choice. </text> <text top="638" left="108" width="5" height="16" font="1"> </text> <text top="660" left="108" width="699" height="16" font="2">Interpretation: The encoding of a data value in the LogDatum portion of a BACnetLogRecord </text> <text top="681" left="108" width="454" height="16" font="1">must match the datatype of the monitored object and property. </text> <text top="702" left="108" width="5" height="16" font="1"> </text> <text top="723" left="108" width="297" height="16" font="2">Question: Is this interpretation correct? </text> <text top="744" left="108" width="5" height="16" font="1"> </text> <text top="765" left="108" width="102" height="16" font="2">Answer: Yes </text> <text top="786" left="108" width="5" height="16" font="1"> </text> <text top="807" left="108" width="623" height="16" font="2">Comments: If the alternate functionality is desired, a Trend Log that does not have a </text> <text top="828" left="108" width="678" height="16" font="1">Log_DeviceObjectProperty property is allowed to monitor a BACnet property and coerce the </text> <text top="849" left="108" width="202" height="16" font="1">data into any form required.</text> <text top="851" left="310" width="4" height="14" font="0"> </text> <text top="879" left="108" width="5" height="16" font="1"> </text> </page> </pdf2xml> Interpretation 135-2004-18 - January 21, 2006 2006-01-21 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-18.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="115" width="72" height="14" font="0">Page 1 of 1 </text> <text top="1099" left="216" width="4" height="14" font="0"> </text> <text top="1099" left="270" width="536" height="14" font="0"> ©2006 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2004-18 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="339" width="244" height="16" font="1">Approval Date: January 21, 2006 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="246" height="16" font="2">Request from: Rene Quirighetti (</text> <text top="239" left="354" width="221" height="16" font="3">rene.quirighetti@siemens.com</text> <text top="239" left="575" width="181" height="16" font="1">), Siemens Schweiz AG, </text> <text top="260" left="108" width="328" height="16" font="1">Gubelstrasse 22, Zug, Switzerland CH-6300. </text> <text top="260" left="436" width="5" height="16" font="3"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="589" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="398" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Sections.12.25.9. </text> <text top="345" left="108" width="5" height="16" font="1"> </text> <text top="366" left="108" width="624" height="16" font="2">Background: Section 12.25.9 in BACnet standard 135-2004 defines that the property </text> <text top="387" left="108" width="669" height="16" font="1">Log_Interval must be writable if present. The same clause also defines, that Trend Log shall </text> <text top="408" left="108" width="644" height="16" font="1">issue COV subscriptions for the referenced property, if Log_Interval has a value of zero. </text> <text top="429" left="108" width="694" height="16" font="1">The standard is not specific about changing Log_Interval between any non-zero value and zero. </text> <text top="450" left="108" width="702" height="16" font="1">This however would result in toggling between polling the referenced property and issuing COV </text> <text top="471" left="108" width="302" height="16" font="1">subscriptions for the referenced property. </text> <text top="492" left="108" width="5" height="16" font="1"> </text> <text top="513" left="108" width="666" height="16" font="2">Interpretation: We do not assume that it is the intention of the standard to change between </text> <text top="534" left="108" width="653" height="16" font="1">polling and COV subscribed logging during one logging session, i.e. while Log_Enable is </text> <text top="555" left="108" width="616" height="16" font="1">TRUE. Therefore our interpretation is, that while Log_Enable is true, writing zero to </text> <text top="576" left="108" width="652" height="16" font="1">Log_Interval that was non-zero prior to the write attempt or writing any non zero value to </text> <text top="597" left="108" width="686" height="16" font="1">Log_Interval that had a value of zero prior to the write attempt may be refused with a negative </text> <text top="618" left="108" width="613" height="16" font="1">response with Error class PROPERTY and Error code VALUE_OUT_OF_RANGE. </text> <text top="639" left="108" width="5" height="16" font="1"> </text> <text top="660" left="108" width="292" height="16" font="2">Question: Is this interpretation correct? </text> <text top="681" left="108" width="5" height="16" font="1"> </text> <text top="702" left="108" width="96" height="16" font="2">Answer: No </text> <text top="723" left="108" width="5" height="16" font="1"> </text> <text top="744" left="108" width="687" height="16" font="2">Comments: It was never the intent of the committee to restrict the switching between poll and </text> <text top="765" left="108" width="646" height="16" font="1">COV data acquisition while Log_Enable is TRUE for Trend Logs that support COV data </text> <text top="786" left="108" width="84" height="16" font="1">acquisition.</text> <text top="788" left="192" width="4" height="14" font="0"> </text> <text top="816" left="108" width="5" height="16" font="1"> </text> </page> </pdf2xml> Interpretation 135-2004-18 - January 21, 2006 2006-01-21 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-18.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="115" width="72" height="14" font="0">Page 1 of 1 </text> <text top="1099" left="216" width="4" height="14" font="0"> </text> <text top="1099" left="270" width="536" height="14" font="0"> ©2006 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2004-18 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="339" width="244" height="16" font="1">Approval Date: January 21, 2006 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="246" height="16" font="2">Request from: Rene Quirighetti (</text> <text top="239" left="354" width="221" height="16" font="3">rene.quirighetti@siemens.com</text> <text top="239" left="575" width="181" height="16" font="1">), Siemens Schweiz AG, </text> <text top="260" left="108" width="328" height="16" font="1">Gubelstrasse 22, Zug, Switzerland CH-6300. </text> <text top="260" left="436" width="5" height="16" font="3"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="589" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="398" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Sections.12.25.9. </text> <text top="345" left="108" width="5" height="16" font="1"> </text> <text top="366" left="108" width="624" height="16" font="2">Background: Section 12.25.9 in BACnet standard 135-2004 defines that the property </text> <text top="387" left="108" width="669" height="16" font="1">Log_Interval must be writable if present. The same clause also defines, that Trend Log shall </text> <text top="408" left="108" width="644" height="16" font="1">issue COV subscriptions for the referenced property, if Log_Interval has a value of zero. </text> <text top="429" left="108" width="694" height="16" font="1">The standard is not specific about changing Log_Interval between any non-zero value and zero. </text> <text top="450" left="108" width="702" height="16" font="1">This however would result in toggling between polling the referenced property and issuing COV </text> <text top="471" left="108" width="302" height="16" font="1">subscriptions for the referenced property. </text> <text top="492" left="108" width="5" height="16" font="1"> </text> <text top="513" left="108" width="666" height="16" font="2">Interpretation: We do not assume that it is the intention of the standard to change between </text> <text top="534" left="108" width="653" height="16" font="1">polling and COV subscribed logging during one logging session, i.e. while Log_Enable is </text> <text top="555" left="108" width="616" height="16" font="1">TRUE. Therefore our interpretation is, that while Log_Enable is true, writing zero to </text> <text top="576" left="108" width="652" height="16" font="1">Log_Interval that was non-zero prior to the write attempt or writing any non zero value to </text> <text top="597" left="108" width="686" height="16" font="1">Log_Interval that had a value of zero prior to the write attempt may be refused with a negative </text> <text top="618" left="108" width="613" height="16" font="1">response with Error class PROPERTY and Error code VALUE_OUT_OF_RANGE. </text> <text top="639" left="108" width="5" height="16" font="1"> </text> <text top="660" left="108" width="292" height="16" font="2">Question: Is this interpretation correct? </text> <text top="681" left="108" width="5" height="16" font="1"> </text> <text top="702" left="108" width="96" height="16" font="2">Answer: No </text> <text top="723" left="108" width="5" height="16" font="1"> </text> <text top="744" left="108" width="687" height="16" font="2">Comments: It was never the intent of the committee to restrict the switching between poll and </text> <text top="765" left="108" width="646" height="16" font="1">COV data acquisition while Log_Enable is TRUE for Trend Logs that support COV data </text> <text top="786" left="108" width="84" height="16" font="1">acquisition.</text> <text top="788" left="192" width="4" height="14" font="0"> </text> <text top="816" left="108" width="5" height="16" font="1"> </text> </page> </pdf2xml> Interpretation 135-2004-19 - January 27, 2007 2007-01-27 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-19.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="16" family="Times" color="#000000"/> <fontspec id="5" size="13" family="Times" color="#000000"/> <text top="1099" left="108" width="72" height="14" font="0">Page 1 of 2 </text> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="520" width="267" height="14" font="0"> ©2007 ASHRAE. All rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2004-19 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="339" width="244" height="16" font="1">Approval Date: January 27, 2007 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="246" height="16" font="2">Request from: Rene Quirighetti (</text> <text top="239" left="354" width="221" height="16" font="3">rene.quirighetti@siemens.com</text> <text top="239" left="575" width="181" height="16" font="1">), Siemens Schweiz AG, </text> <text top="260" left="108" width="324" height="16" font="1">Gubelstrasse 22, Zug, Switzerland CH-6300.</text> <text top="260" left="432" width="5" height="16" font="3"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="589" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="586" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Sections.15.9.1.1.5, 15.10.3.2.4 and 19.2.1. </text> <text top="345" left="108" width="5" height="16" font="1"> </text> <text top="366" left="108" width="696" height="16" font="2">Background: Sections 15.9.1.1.5, 15.10.3.2.4 and 19.2.1 in BACnet Standard 135-2004 define, </text> <text top="387" left="108" width="690" height="16" font="1">that if an attempt is made to write to a commandable property without specifying the priority, a </text> <text top="408" left="108" width="435" height="16" font="1">default priority of 16 (the lowest priority) shall be assumed. </text> <text top="429" left="108" width="699" height="16" font="1">The standard does not explicitly define, how the responder shall react on an attempt to write to a </text> <text top="450" left="108" width="695" height="16" font="1">commandable or a not commandable but writable property if the value of the Priority parameter </text> <text top="471" left="108" width="665" height="16" font="1">in the WriteProperty or in the WritePropertyMultiple service is outside the defined range of </text> <text top="492" left="108" width="45" height="16" font="1">1..16. </text> <text top="513" left="108" width="425" height="16" font="1">There are two different kind of behaviour possible: Either </text> <text top="534" left="108" width="518" height="16" font="1">(a) the parameter is regarded as malformed leading to a Reject PDU or </text> <text top="555" left="108" width="612" height="16" font="1">(b) the parameter is regarded as absent leading to a prio 16 commanding in case of a </text> <text top="575" left="108" width="619" height="16" font="1">commandable property or to a simple writing in case of a non commandable property </text> <text top="596" left="108" width="88" height="16" font="1">respectivly. </text> <text top="617" left="108" width="5" height="16" font="1"> </text> <text top="639" left="108" width="658" height="16" font="2">Interpretation: Even so both types of behavior could comply with the general rules of the </text> <text top="660" left="108" width="622" height="16" font="1">standard we are opting for (b). This is in line with the definition given for writing to a </text> <text top="681" left="108" width="703" height="16" font="1">commandable property without specifying a priority. It therefore leads to a better understandable </text> <text top="702" left="108" width="289" height="16" font="1">and predictable behavior of the service. </text> <text top="723" left="108" width="5" height="16" font="1"> </text> <text top="744" left="108" width="292" height="16" font="2">Question: Is this interpretation correct? </text> <text top="765" left="108" width="5" height="16" font="1"> </text> <text top="786" left="108" width="105" height="16" font="2">Answer: No. </text> <text top="807" left="108" width="5" height="16" font="1"> </text> <text top="837" left="108" width="107" height="16" font="2">Comments: </text> <text top="867" left="108" width="663" height="16" font="1">The committee’s initial response to this interpretation request, approved at the Winter 2006 </text> <text top="888" left="108" width="119" height="16" font="1">meeting, stated: </text> <text top="918" left="135" width="639" height="16" font="4">In the case where the property being written to is commandable, the request shall result </text> <text top="939" left="135" width="648" height="16" font="4">in a Reject-PDU being returned. If the property being written to is not commandable, the </text> <text top="959" left="135" width="544" height="16" font="4">device has the option to ignore the invalid priority or return a Reject-PDU.</text> <text top="961" left="679" width="4" height="14" font="5"> </text> <text top="989" left="108" width="603" height="16" font="1">Upon further review, it was noted that use of a Reject-PDU is inconsistent with the </text> <text top="1010" left="108" width="467" height="16" font="1">WritePropertyMultiple service procedure. From clause 15.10.2: </text> <text top="1040" left="135" width="645" height="16" font="4">If, in the process of carrying out the modification of the indicated properties in the order </text> <text top="1061" left="135" width="603" height="16" font="4">specified in the 'List of Write Access Specifications', a property is encountered that </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <text top="1099" left="108" width="72" height="14" font="0">Page 2 of 2 </text> <text top="1099" left="432" width="4" height="14" font="0"> </text> <text top="1099" left="520" width="267" height="14" font="0"> ©2007 ASHRAE. All rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="135" width="594" height="16" font="4">cannot be modified, the responding BACnet-user shall issue a 'Result(-)' response </text> <text top="112" left="135" width="626" height="16" font="4">primitive indicating the reason for the failure. The result of this service shall be either </text> <text top="133" left="135" width="614" height="16" font="4">that all of the specified properties or only the properties up to, but not including, the </text> <text top="153" left="135" width="594" height="16" font="4">property specified in the 'First Failed Write Attempt' parameter were successfully </text> <text top="174" left="135" width="72" height="16" font="4">modified. </text> <text top="204" left="108" width="681" height="16" font="1">The intent is not to force implementations to scan an entire WritePropertyMultiple request for </text> <text top="225" left="108" width="670" height="16" font="1">errors before executing any part of the request. Therefore, at the Summer 2006 meeting, the </text> <text top="246" left="108" width="558" height="16" font="1">committee agreed to revise the response. Following is the updated response: </text> <text top="276" left="135" width="645" height="16" font="4">In the case where the property being written to is commandable, it is a local matter as to </text> <text top="297" left="135" width="590" height="16" font="4">whether the request shall cause a Reject PDU to be returned or cause a Result(-) </text> <text top="317" left="135" width="172" height="16" font="4">response to be issued. </text> <text top="343" left="135" width="646" height="16" font="4">If the property being written to is not commandable, it is a local matter as to whether the </text> <text top="363" left="135" width="103" height="16" font="4">request shall: </text> <text top="384" left="135" width="374" height="22" font="1">− Be executed, ignoring the invalid Priority value </text> <text top="411" left="135" width="293" height="22" font="1">− Result in the return of a Reject PDU </text> <text top="437" left="135" width="314" height="22" font="1">− Cause a Result(-) response to be issued </text> <text top="468" left="108" width="5" height="16" font="1"> </text> </page> </pdf2xml> Interpretation 135-2004-20 - January 27, 2007 2007-01-27 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-20.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="9" family="Times" color="#000000"/> <text top="1099" left="115" width="72" height="14" font="0">Page 1 of 2 </text> <text top="1099" left="216" width="582" height="14" font="0"> ©2007 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2004-20 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="339" width="244" height="16" font="1">Approval Date: January 27, 2007 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="235" height="16" font="2">Request from: David Hudson (</text> <text top="239" left="343" width="206" height="16" font="3">dhudson@deltacontrols.com</text> <text top="239" left="549" width="193" height="16" font="1">) Delta Controls, 17850 56</text> <text top="235" left="742" width="9" height="11" font="4">th</text> <text top="239" left="751" width="5" height="16" font="1"> </text> <text top="260" left="108" width="223" height="16" font="1">Avenue, Surrey, BC V3S-1C7.</text> <text top="260" left="331" width="9" height="16" font="3"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="594" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="699" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Sections 5.4, 5.4.1, 5.4.5.1, 5.4.5.3, and 12.11.27 related to </text> <text top="345" left="108" width="359" height="16" font="1">Device Object and the APDU_Timeout property. </text> <text top="366" left="108" width="5" height="16" font="1"> </text> <text top="387" left="108" width="657" height="16" font="2">Background: Clause 12.11.27 (APDU_Timeout) does not indicate that, in addition to the </text> <text top="408" left="108" width="677" height="16" font="1">existing definition, APDU_Timeout is an indication of the maximum amount of time a server </text> <text top="429" left="108" width="698" height="16" font="1">device shal take between recieving a confirmed APDU request and sending its response or abort </text> <text top="450" left="108" width="690" height="16" font="1">PDU. My interpretation of the following portions of Clause 5 is that a server device will either </text> <text top="471" left="108" width="677" height="16" font="1">respond to a Confirmed APDU request or send an abort within (APDU_Timeout + the time it </text> <text top="492" left="108" width="631" height="16" font="1">took to decode the received APDU and start the RequestTimer) of when it received the </text> <text top="513" left="108" width="136" height="16" font="1">confirmed APDU. </text> <text top="534" left="108" width="5" height="16" font="1"> </text> <text top="555" left="108" width="649" height="16" font="1">Clause 5.4.1, for Tout, states "This parameter represents the value of the APDU_Timeout </text> <text top="575" left="108" width="277" height="16" font="1">property of the node's Device object." </text> <text top="596" left="108" width="5" height="16" font="1"> </text> <text top="617" left="108" width="582" height="16" font="1">Clause 5.4.5.1 (State Machine for Responding BACnet User (server), IDLE) for </text> <text top="638" left="108" width="633" height="16" font="1">ConfirmedUnsegmentedRecieved states "If a BACnet-Confirmed-Request-PDU whose </text> <text top="659" left="108" width="649" height="16" font="1">'segmented-message' parameter is FALSE is received from the network layer, then send a </text> <text top="680" left="108" width="668" height="16" font="1">CONF_SERV indication to the local application program, start RequestTimer; and enter the </text> <text top="701" left="108" width="213" height="16" font="1">AWAIT_RESPONSE state." </text> <text top="722" left="108" width="5" height="16" font="1"> </text> <text top="743" left="108" width="693" height="16" font="1">Clause 5.4.5.3 (State Machine for Responding BACnet User (server, AWAIT_RESPONSE) for </text> <text top="764" left="108" width="664" height="16" font="1">Timeout, states "If RequestTimer becomes greater than Tout, then issue an N-UNITDATA. </text> <text top="785" left="108" width="687" height="16" font="1">request with 'data_expecting_reply' = FALSE to transmit a BACnet-Abort-PDU with 'server' = </text> <text top="806" left="108" width="661" height="16" font="1">TRUE; send ABORT.indication to the local application program; and enter the IDLE state. </text> <text top="827" left="108" width="5" height="16" font="1"> </text> <text top="848" left="108" width="676" height="16" font="1">Clause 5.4 states "...All BACnet devices shall be able to act as responding BACnet-users and </text> <text top="869" left="108" width="591" height="16" font="1">therefore shall be prepared to receive APDUs sent by requesting BACnet-users.". </text> <text top="890" left="108" width="5" height="16" font="1"> </text> <text top="911" left="108" width="644" height="16" font="2">Interpretation: In addition to being an indication of the amount of time in milliseconds </text> <text top="932" left="108" width="697" height="16" font="1">between retransmissions of an APDU requiring acknowledgment for which no acknowledgment </text> <text top="953" left="108" width="589" height="16" font="1">has been received (which is documented in 12.11.27), the Device object property </text> <text top="974" left="108" width="645" height="16" font="1">APDU_Timeout is an indication of the maximum amount of time the device shall take to </text> <text top="995" left="108" width="690" height="16" font="1">respond to, or send an abort to, a ConfirmedRequest-PDU and as such should never be allowed </text> <text top="1016" left="108" width="173" height="16" font="1">to have a value of zero. </text> <text top="1037" left="108" width="5" height="16" font="1"> </text> <text top="1058" left="108" width="297" height="16" font="2">Question: Is this interpretation correct? </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="5" size="14" family="Times" color="#000000"/> <text top="1099" left="115" width="72" height="14" font="0">Page 2 of 2 </text> <text top="1099" left="216" width="582" height="14" font="0"> ©2007 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="108" width="5" height="16" font="1"> </text> <text top="112" left="108" width="105" height="16" font="2">Answer: No. </text> <text top="133" left="108" width="5" height="16" font="1"> </text> <text top="154" left="108" width="98" height="16" font="2">Comments: </text> <text top="175" left="108" width="5" height="16" font="1"> </text> <text top="196" left="135" width="680" height="15" font="5">“The intent of the APDU_Timeout property has always been for its use in clients. There has been an </text> <text top="215" left="135" width="680" height="15" font="5">error in the standard from the beginning and it should never have been used for server devices. The </text> <text top="234" left="135" width="157" height="15" font="5">standard shall be fixed. </text> <text top="253" left="135" width="4" height="15" font="5"> </text> <text top="272" left="135" width="680" height="15" font="5">In server devices, the APDU_Timeout value indicates the maximum amount of time that the device </text> <text top="291" left="135" width="679" height="15" font="5">will take to respond to a request and does not take into account network delay. For server devices that </text> <text top="310" left="135" width="489" height="15" font="5">are always capable of responding immediately, a value of 0 is acceptable. </text> <text top="329" left="135" width="4" height="15" font="5"> </text> <text top="348" left="135" width="682" height="15" font="5">In any device that is configured to initiate BACnet-ConfirmedRequest-PDUs the APDU_Timeout </text> <text top="367" left="135" width="684" height="15" font="5">value is required to be non-zero. This value reflects both network delay and maximum server </text> <text top="387" left="135" width="124" height="15" font="5">processing time.” </text> <text top="406" left="108" width="5" height="16" font="1"> </text> </page> </pdf2xml> Interpretation 135-2004-21 - January 27, 2007 2007-01-27 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-21.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="115" width="72" height="14" font="0">Page 1 of 2 </text> <text top="1099" left="216" width="582" height="14" font="0"> ©2007 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2004-21 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="339" width="244" height="16" font="1">Approval Date: January 27, 2007 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="222" height="16" font="2">Request from: Carl Neilson (</text> <text top="239" left="330" width="205" height="16" font="3">cneilson@deltacontrols.com</text> <text top="239" left="535" width="255" height="16" font="1">), Delta Controls, 61 Seagirt Road, </text> <text top="260" left="108" width="191" height="16" font="1">East Sooke, BC V0S-1N0.</text> <text top="260" left="299" width="9" height="16" font="3"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="594" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="639" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Section 12.24.4, 12.24.7 and 12.24.8 regarding the </text> <text top="345" left="108" width="570" height="16" font="1">Present_Value of an object is evaluated within a selected Weekly_Schedule or </text> <text top="366" left="108" width="157" height="16" font="1">Exception_Schedule. </text> <text top="386" left="108" width="5" height="16" font="1"> </text> <text top="408" left="108" width="684" height="16" font="2">Background: In Clause 12.24.4, the standard describes how the Present_Value of a Schedule </text> <text top="429" left="108" width="665" height="16" font="1">object is to be evaluated. The fifth paragraph provides direction on how to determine which </text> <text top="450" left="108" width="605" height="16" font="1">value within a selected Weekly_Schedule or Exception_Schedule shall be selected: </text> <text top="471" left="108" width="5" height="16" font="1"> </text> <text top="492" left="108" width="706" height="16" font="1">"The method for evaluating the current value of a schedule (either exception or weekly) is to find </text> <text top="513" left="108" width="703" height="16" font="1">the latest element in the list of BACnetTimeValues that occurs on or before the current time, and </text> <text top="534" left="108" width="686" height="16" font="1">then use that element's value as the current value for the schedule. If no such element is found, </text> <text top="555" left="108" width="405" height="16" font="1">then the current value for the schedule shall be NULL." </text> <text top="575" left="108" width="5" height="16" font="1"> </text> <text top="596" left="108" width="686" height="16" font="1">This language does not provide direction in the case where there are 2 or more entries with the </text> <text top="617" left="108" width="82" height="16" font="1">same time. </text> <text top="638" left="108" width="5" height="16" font="1"> </text> <text top="659" left="108" width="687" height="16" font="1">Without understanding how a device will behave with such a schedule, developing an accurate </text> <text top="680" left="108" width="539" height="16" font="1">graphical UI for an arbitrary schedule object is difficult, if not impossible. </text> <text top="701" left="108" width="5" height="16" font="1"> </text> <text top="722" left="108" width="390" height="16" font="1">We considered 4 possibilities for resolving this issue: </text> <text top="743" left="108" width="5" height="16" font="1"> </text> <text top="764" left="108" width="696" height="16" font="1">1) When there are 2 or more entries in a schedule that have the same Time, the entry that occurs </text> <text top="785" left="108" width="330" height="16" font="1">first (or last) in the list shall take precedence. </text> <text top="806" left="108" width="5" height="16" font="1"> </text> <text top="827" left="108" width="700" height="16" font="1">But, given that the schedules are implemented as BACnet lists, it is our contention that there can </text> <text top="848" left="108" width="646" height="16" font="1">be no order implied by the client that configured the properties. Since, through the use of </text> <text top="869" left="108" width="676" height="16" font="1">AddListElement, the client cannot control the order of the elements in any given list and thus </text> <text top="890" left="108" width="706" height="16" font="1">cannot convey any order to the Time/Value pairs other than through the Time portion. This could </text> <text top="911" left="108" width="693" height="16" font="1">result in 2 different BACnet devices having a schedule that behaves differently after being built </text> <text top="932" left="108" width="343" height="16" font="1">from the same set of AddListElement requests. </text> <text top="953" left="108" width="5" height="16" font="1"> </text> <text top="974" left="108" width="688" height="16" font="1">It is thus our opinion that the order of the entries in the list cannot be used to select the entry to </text> <text top="995" left="108" width="33" height="16" font="1">use. </text> <text top="1016" left="108" width="5" height="16" font="1"> </text> <text top="1037" left="108" width="616" height="16" font="1">2) Any of the duplicate entries can be chosen at the discretion of the schedule object. </text> <text top="1058" left="108" width="5" height="16" font="1"> </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <text top="1099" left="115" width="72" height="14" font="0">Page 2 of 2 </text> <text top="1099" left="216" width="582" height="14" font="0"> ©2007 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="108" width="688" height="16" font="1">This could also result in 2 different BACnet devices having a schedule that behaves differently </text> <text top="112" left="108" width="509" height="16" font="1">after being built from the same sequence of AddListElement requests. </text> <text top="133" left="108" width="5" height="16" font="1"> </text> <text top="154" left="108" width="677" height="16" font="1">3) The schedule object checks for this condition and rejects any attempt to place the schedule </text> <text top="175" left="108" width="140" height="16" font="1">into this condition. </text> <text top="196" left="108" width="5" height="16" font="1"> </text> <text top="217" left="108" width="682" height="16" font="1">When modifying a schedule object via the AddListElement and RemoveListElement services, </text> <text top="238" left="108" width="590" height="16" font="1">this requirement would require that RemoveListElement requests always precede </text> <text top="259" left="108" width="698" height="16" font="1">AddListElement requests for entries where the Value has changed and the Time portion has not. </text> <text top="280" left="108" width="556" height="16" font="1">This stipulation does not appear to be supported by anything in the standard. </text> <text top="301" left="108" width="5" height="16" font="1"> </text> <text top="322" left="108" width="509" height="16" font="1">4) The schedule object detects this condition and sets its Reliability to </text> <text top="343" left="108" width="226" height="16" font="1">CONFIGURATION_ERROR. </text> <text top="364" left="108" width="704" height="16" font="1">While the Schedule object’s description does not specifically call out the use of this error for this </text> <text top="385" left="108" width="663" height="16" font="1">condition, this choice is supported by the description of the schedule’s Reliability property: </text> <text top="406" left="108" width="690" height="16" font="1">“The Reliability property, of type BACnetReliability, provides an indication that the properties </text> <text top="427" left="108" width="511" height="16" font="1">of the schedule object are in a consistent state. …” and the description </text> <text top="448" left="108" width="618" height="16" font="1">CONFIGURATION_ERROR: “The object's properties are not in a consistent state.”. </text> <text top="468" left="108" width="5" height="16" font="1"> </text> <text top="490" left="108" width="692" height="16" font="2">Interpretation: A Weekly_Schedule or Exception_Schedule entry with 2 or more entries with </text> <text top="511" left="108" width="597" height="16" font="1">the same Time shall result in the Schedule object setting its Reliability property to </text> <text top="532" left="108" width="226" height="16" font="1">CONFIGURATION_ERROR. </text> <text top="553" left="108" width="5" height="16" font="1"> </text> <text top="574" left="108" width="297" height="16" font="2">Question: Is this interpretation correct? </text> <text top="595" left="108" width="5" height="16" font="1"> </text> <text top="616" left="108" width="105" height="16" font="2">Answer: No. </text> <text top="637" left="108" width="5" height="16" font="1"> </text> <text top="658" left="108" width="697" height="16" font="2">Comments: It is a local matter as to what the behavior of the Schedule object is when there are </text> <text top="679" left="108" width="675" height="16" font="1">multiple entries in a Weekly_Schedule or Exception_Schedule entry with the same time. The </text> <text top="700" left="108" width="547" height="16" font="1">committee will review this issue to determine if any changes are necessary. </text> <text top="721" left="108" width="5" height="16" font="1"> </text> </page> </pdf2xml> Interpretation 135-2004-22 - April 25, 2007 2007-04-25 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-22.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="9" family="Times" color="#000000"/> <text top="1099" left="115" width="72" height="14" font="0">Page 1 of 2 </text> <text top="1099" left="216" width="582" height="14" font="0"> ©2007 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2004-22 OF </text> <text top="113" left="263" width="367" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="1">® - </text> <text top="134" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="1"> </text> <text top="197" left="348" width="226" height="16" font="1">Approval Date: April 25, 2007 </text> <text top="218" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="222" height="16" font="2">Request from: Carl Neilson (</text> <text top="239" left="330" width="205" height="16" font="3">cneilson@deltacontrols.com</text> <text top="239" left="535" width="255" height="16" font="1">), Delta Controls, 61 Seagirt Road, </text> <text top="260" left="108" width="191" height="16" font="1">East Sooke, BC V0S-1N0.</text> <text top="260" left="299" width="5" height="16" font="3"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="303" left="108" width="594" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="652" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Sections 6.5.3 and 9.5.6.4 regarding the methods for </text> <text top="345" left="108" width="487" height="16" font="1">establishing the address of a BACnet router for a particular DNET. </text> <text top="366" left="108" width="5" height="16" font="1"> </text> <text top="387" left="108" width="676" height="16" font="2">Background: In Clause 6.5.3 of Standard 135 four methods for establishing the address of a </text> <text top="408" left="108" width="270" height="16" font="1">router are detailed. The methods are: </text> <text top="429" left="108" width="566" height="16" font="1">1) the address may be established manually at the time a device is configured, </text> <text top="450" left="108" width="702" height="16" font="1">2) the address may be learned by issuing a Who-Is request and noting the SA associated with the </text> <text top="471" left="128" width="686" height="16" font="1">subsequent I-Am message (assuming the device specified in the Who-Is is located on a remote </text> <text top="492" left="128" width="558" height="16" font="1">DNET and the I-Am message was handled by a router on the local network), </text> <text top="513" left="108" width="525" height="16" font="1">3) by using the network layer message Who-Is-Router-To-Network, and </text> <text top="534" left="108" width="689" height="16" font="1">4) by using the local broadcast MAC address in the initial transmission to a device on a remote </text> <text top="555" left="128" width="673" height="16" font="1">DNET and noting the SA associated with any subsequent responses from the remote device. </text> <text top="575" left="108" width="5" height="16" font="1"> </text> <text top="596" left="108" width="664" height="16" font="1">Note that none of these options describe extracting the router's address from a non-solicited </text> <text top="617" left="108" width="681" height="16" font="1">message (such as a ConfirmedRequest-PDU) in order to send a response although this is what </text> <text top="638" left="108" width="223" height="16" font="1">most implementations will do. </text> <text top="659" left="108" width="5" height="16" font="1"> </text> <text top="680" left="108" width="694" height="16" font="1">In Clause 9.5.6.4, WAIT_FOR_REPLY, in MS/TP Master Node State Machine description, the </text> <text top="701" left="108" width="697" height="16" font="1">ReceivedReply transition requires that the DestinationAddress of the received packet is equal to </text> <text top="722" left="108" width="673" height="16" font="1">TS (this station) thus disallowing the use of a local broadcast MAC address in a non-delayed </text> <text top="743" left="108" width="198" height="16" font="1">response frame on MS/TP. </text> <text top="764" left="108" width="5" height="16" font="1"> </text> <text top="785" left="108" width="704" height="16" font="1">In Clause 10.1 of Standard 135.1-2003, which is testing that the IUT can respond to requests that </text> <text top="806" left="108" width="652" height="16" font="1">originate from a remote network, test step 2 allows the response to be sent with a LOCAL </text> <text top="827" left="108" width="118" height="16" font="1">BROADCAST. </text> <text top="848" left="108" width="5" height="16" font="1"> </text> <text top="869" left="108" width="325" height="16" font="2">Interpretation: In Clause 6.5.3 of 135 the 4</text> <text top="865" left="433" width="9" height="11" font="4">th</text> <text top="869" left="443" width="344" height="16" font="1"> method for establishing the address of a router </text> <text top="890" left="108" width="655" height="16" font="1">was never intended to be used for replies as the request indicates the router address. When </text> <text top="911" left="108" width="702" height="16" font="1">replying to a DER frame from a remote network, if the responding device does not already know </text> <text top="932" left="108" width="684" height="16" font="1">a route to the remote network, it shall use the source MAC address from the DER frame as the </text> <text top="953" left="108" width="373" height="16" font="1">address through which to route the response frame. </text> <text top="974" left="108" width="5" height="16" font="1"> </text> <text top="995" left="108" width="297" height="16" font="2">Question: Is this interpretation correct? </text> <text top="1016" left="108" width="5" height="16" font="1"> </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <text top="1099" left="115" width="72" height="14" font="0">Page 2 of 2 </text> <text top="1099" left="216" width="582" height="14" font="0"> ©2007 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="108" width="365" height="16" font="2">Answer: Yes, this interpretation is correct. The 4</text> <text top="87" left="473" width="9" height="11" font="4">th</text> <text top="91" left="482" width="296" height="16" font="1"> method for establishing the address of a </text> <text top="112" left="108" width="692" height="16" font="1">router was never intended to be used for replies, since it is implied that the address and route of </text> <text top="133" left="108" width="442" height="16" font="1">the requestor is known at the time of response to the request. </text> <text top="154" left="108" width="5" height="16" font="1"> </text> <text top="175" left="108" width="609" height="16" font="2">Comments: While the interpretation is correct, it should be noted that some current </text> <text top="196" left="108" width="696" height="16" font="1">implementations take advantage of method 4 to re-determine the route to the requestor. It is the </text> <text top="217" left="108" width="676" height="16" font="1">view of the committee that this method will work in the case of non-MS/TP networks. In the </text> <text top="238" left="108" width="692" height="16" font="1">case of MS/TP, the sender’s (a router, in this case) MasterNodeStateMachine is not expecting a </text> <text top="259" left="108" width="678" height="16" font="1">broadcast at this point. This scenario will cause the broadcasted response to be discarded. In </text> <text top="280" left="108" width="690" height="16" font="1">order for method 4 to work on MS/TP, a device must first send a ReplyPostponed to the source </text> <text top="301" left="108" width="700" height="16" font="1">MS/TP MAC address and then send the broadcasted response the next time it becomes the token </text> <text top="322" left="108" width="692" height="16" font="1">holder. It should also be noted that method 4 will not work for MS/TP slave devices since they </text> <text top="343" left="108" width="236" height="16" font="1">are incapable of token passing. </text> </page> </pdf2xml> Interpretation 135-2004-23 - June 21, 2008 2008-06-21 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-23.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 2 ©2008 ASHRAE. All Rights reserved. </text> <text top="91" left="301" width="320" height="16" font="1">INTERPRETATION IC 135-2004-23 OF </text> <text top="113" left="263" width="367" height="16" font="1">ANSI/ASHRAE STANDARD 135-2004 BACnet</text> <text top="107" left="630" width="29" height="22" font="2">® - </text> <text top="134" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="155" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="176" left="108" width="5" height="16" font="2"> </text> <text top="197" left="364" width="194" height="16" font="2">Approval Date: 6/21/2008 </text> <text top="218" left="108" width="5" height="16" font="2"> </text> <text top="239" left="108" width="246" height="16" font="1">Request from: Rene Quirighetti (</text> <text top="239" left="354" width="221" height="16" font="3">rene.quirighetti@siemens.com</text> <text top="239" left="575" width="181" height="16" font="2">), Siemens Schweiz AG, </text> <text top="260" left="108" width="328" height="16" font="2">Gubelstrasse 22, Zug, Switzerland CH-6301. </text> <text top="281" left="108" width="5" height="16" font="2"> </text> <text top="303" left="108" width="589" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="324" left="108" width="582" height="16" font="2">ANSI/ASHRAE Standard 135-2004, Section 13.2 relating to intrinsic reporting. </text> <text top="345" left="108" width="5" height="16" font="2"> </text> <text top="366" left="108" width="700" height="16" font="1">Background: BACnet is ambiguous about the application of eventing and alarming from within </text> <text top="387" left="108" width="370" height="16" font="2">BACnet objects (also called "intrinsic reporting"). </text> <text top="408" left="108" width="5" height="16" font="2"> </text> <text top="429" left="108" width="522" height="16" font="2">Analyzing the different statements in Chapter 13 of Standard 135-2004: </text> <text top="450" left="108" width="5" height="16" font="2"> </text> <text top="471" left="108" width="322" height="16" font="2">A. Clause 13.2 "Intrinsic Reporting" states: </text> <text top="492" left="135" width="622" height="16" font="2">"….Intrinsic reporting allows a BACnet device to provide one or more alarm or event </text> <text top="513" left="135" width="634" height="16" font="2">sources, intrinsic to the device, which generate alarm or event notifications that may be </text> <text top="534" left="135" width="289" height="16" font="2">directed to one or more destinations…" </text> <text top="555" left="135" width="602" height="16" font="2">This sentence is not specific about which object types may generate alarm or event </text> <text top="575" left="135" width="99" height="16" font="2">notifications. </text> <text top="596" left="108" width="238" height="16" font="2">B. Further-on this clause states: </text> <text top="617" left="135" width="671" height="16" font="2">"…Certain BACnet standard objects may optionally support intrinsic reporting by providing </text> <text top="638" left="135" width="649" height="16" font="2">optional properties for defining the type of alarm or event to be generated and options for </text> <text top="659" left="135" width="325" height="16" font="2">handling and routing of the notifications…." </text> <text top="680" left="108" width="514" height="16" font="2">C. Further down in the 3rd paragraph of Clause 13.2 a sentence reads </text> <text top="701" left="135" width="671" height="16" font="2">"… The standardized objects that may optionally provide intrinsic event notification support </text> <text top="722" left="135" width="522" height="16" font="2">and the event types they shall employ are summarized in Table 13-2…" </text> <text top="743" left="135" width="616" height="16" font="2">Considering citations A, B and C we conclude, that the expression " Certain BACnet </text> <text top="764" left="135" width="588" height="16" font="2">standard objects may optionally support intrinsic reporting by providing optional </text> <text top="785" left="135" width="664" height="16" font="2">properties.." is not specific to certain types of objects but may be applied to any object-type </text> <text top="806" left="135" width="639" height="16" font="2">that indicates the need for intrinsic reporting by supporting either the Event_State or the </text> <text top="827" left="135" width="151" height="16" font="2">Reliability property. </text> <text top="848" left="108" width="350" height="16" font="2">D. Clause 13.2 also states in its first paragraph: </text> <text top="869" left="135" width="667" height="16" font="2">".. Internal status changes and alarms may also use intrinsic reporting to generate diagnostic </text> <text top="890" left="135" width="120" height="16" font="2">notifications…" </text> <text top="911" left="135" width="297" height="16" font="2">and further down in the same paragraph: </text> <text top="932" left="135" width="678" height="16" font="2">" If a standard object provides intrinsic reporting, then changes of value of specific properties </text> <text top="953" left="135" width="666" height="16" font="2">of the object, in some cases based on programmable criteria, or changes of status internal to </text> <text top="974" left="135" width="608" height="16" font="2">the object trigger event notifications to be sent to one or more destinations based on </text> <text top="995" left="135" width="139" height="16" font="2">notification class." </text> <text top="1016" left="135" width="678" height="16" font="2">None of these citations gives any indication, that the "changes of status internal to the object" </text> <text top="1037" left="135" width="662" height="16" font="2">limits the object types to those listed in Table 13-2 nor that this intenal status change has to </text> <text top="1058" left="135" width="630" height="16" font="2">be reflected in a transition to / from OFFNORMAL or FAULT state. There are already </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <text top="1120" left="108" width="699" height="14" font="0">Page 2 of 2 ©2008 ASHRAE. All Rights reserved. </text> <text top="91" left="135" width="653" height="16" font="2">examples of event notifications without status changes in the standard, i.e. a NORMAL to </text> <text top="112" left="135" width="237" height="16" font="2">NORMAL transition is notified. </text> <text top="133" left="108" width="410" height="16" font="2">E. Clause 13.2 furthermore states in it's 3rd paragraph: </text> <text top="154" left="135" width="626" height="16" font="2">"…Proprietary intrinsic reporting shall use the services described in 13.8 and 13.9…." </text> <text top="175" left="135" width="654" height="16" font="2">This sentence supports statement D. There is no restriction of object types mentioned. (Be </text> <text top="196" left="135" width="649" height="16" font="2">aware that "proprietary intrinsic reporting" denotes the reporting kind not the originating </text> <text top="217" left="135" width="95" height="16" font="2">object type). </text> <text top="238" left="135" width="5" height="16" font="2"> </text> <text top="259" left="108" width="672" height="16" font="2">Conclusion: The standard is ambiguous about usage of the different kind of event. Providing </text> <text top="280" left="108" width="652" height="16" font="2">FAULT event- and "internal status change" event-notifications for any standard objects is </text> <text top="301" left="108" width="699" height="16" font="2">covered by the wording of the standard, Applying these events to any object type does not cause </text> <text top="322" left="108" width="702" height="16" font="2">any interoperability issues. It even provides for better interoperability in case of reliability issues </text> <text top="343" left="108" width="273" height="16" font="2">within a device or in specific objects. </text> <text top="364" left="108" width="5" height="16" font="2"> </text> <text top="385" left="108" width="692" height="16" font="1">Interpretation: The BACnet standard only limits the application of OFFNORMAL events to a </text> <text top="406" left="108" width="701" height="16" font="2">finate list of standard object types. Other kind of event notifications may be issued by any object </text> <text top="427" left="108" width="40" height="16" font="2">type. </text> <text top="448" left="108" width="5" height="16" font="2"> </text> <text top="469" left="108" width="292" height="16" font="1">Question: Is this interpretation correct? </text> <text top="490" left="108" width="5" height="16" font="2"> </text> <text top="511" left="108" width="100" height="16" font="1">Answer: No. </text> <text top="532" left="108" width="5" height="16" font="2"> </text> <text top="553" left="108" width="703" height="16" font="1">Comments: As described in point C, Clause 13.2 states that only the objects listed in Table 13-2 </text> <text top="574" left="108" width="704" height="16" font="2">may support intrinsic reporting. Other standard object types may not support intrinsic reporting. </text> <text top="595" left="108" width="681" height="16" font="2">In addition, supporting the Event_State and/or Reliability property is not allowed for standard </text> <text top="616" left="108" width="682" height="16" font="2">object types because this is not one of the four specifically allowed mechanisms for extending </text> <text top="637" left="108" width="97" height="16" font="2">the standard. </text> </page> </pdf2xml> Interpretation 135-2004-24 - June 21, 2008 2008-06-21 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-24.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="115" width="72" height="14" font="0">Page 1 of 2 </text> <text top="1099" left="216" width="582" height="14" font="0"> ©2008 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2004-24 OF </text> <text top="112" left="270" width="382" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet - </text> <text top="133" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="1"> </text> <text top="196" left="364" width="194" height="16" font="1">Approval Date: 6/21/2008 </text> <text top="217" left="108" width="5" height="16" font="1"> </text> <text top="238" left="108" width="234" height="16" font="2">Request from: Bernhard Isler (</text> <text top="238" left="342" width="210" height="16" font="3">bernhard.isler@siemens.com</text> <text top="238" left="551" width="210" height="16" font="1">), Siemens Switzerland Ltd., </text> <text top="259" left="108" width="433" height="16" font="1">Building Technologies Group, Zug, Switzerland CH-6301. </text> <text top="280" left="108" width="5" height="16" font="1"> </text> <text top="302" left="108" width="594" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="629" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Sections 19.2, 21 and 23.3, and Addendum “f” to </text> <text top="344" left="108" width="703" height="16" font="1">ANSI/ASHRAE Standard 135-2004 regarding ENUMERATED values in BACnetPriorityValue. </text> <text top="365" left="108" width="5" height="16" font="1"> </text> <text top="386" left="108" width="668" height="16" font="2">Background: Section 23.2 requires that for proprietary commandable properties additional </text> <text top="407" left="108" width="594" height="16" font="1">properties shall be provided that fulfill the role of the standard Priority_Array and </text> <text top="428" left="108" width="227" height="16" font="1">Relinquish_Default properties. </text> <text top="449" left="108" width="5" height="16" font="1"> </text> <text top="470" left="108" width="673" height="16" font="1">Section 19.2 implicitly defines that the Priority_Array property contains 16 values which are </text> <text top="491" left="108" width="695" height="16" font="1">either NULL or of the same data type as the commandable property and the Relinquish_Default </text> <text top="512" left="108" width="620" height="16" font="1">property. The Priority_Array property is of the type BACnetPriorityArray, which is a </text> <text top="533" left="108" width="325" height="16" font="1">BACnetArray [16] of BACnetPriorityValue. </text> <text top="554" left="108" width="5" height="16" font="1"> </text> <text top="575" left="108" width="673" height="16" font="1">BACnetPriorityValue is defined in Section 21, and offers four application type options and a </text> <text top="595" left="108" width="538" height="16" font="1">context tagged option for constructed values (“constructedValue” option). </text> <text top="616" left="108" width="5" height="16" font="1"> </text> <text top="637" left="108" width="700" height="16" font="1">The ENUMERATED application type in the BACnetPriorityValue construct is written such that </text> <text top="658" left="108" width="679" height="16" font="1">it appears to be restricted for use only with BACnetBinaryPV enumerations, although if other </text> <text top="679" left="108" width="687" height="16" font="1">application tagged ENUMERATED types were allowed, they would be indistinguishable from </text> <text top="700" left="108" width="202" height="16" font="1">the BACnetBinaryPV case. </text> <text top="721" left="108" width="5" height="16" font="1"> </text> <text top="742" left="108" width="694" height="16" font="1">With the addition of the Access Door object to the standard (Addendum “f”), there is a need for </text> <text top="763" left="108" width="670" height="16" font="1">another type of enumeration in the BACnetPriorityValue construct, BACnetDoorValue. The </text> <text top="784" left="108" width="691" height="16" font="1">BACnetPriorityValue construct was not changed to include an alternate ENUMERATED entry </text> <text top="805" left="108" width="155" height="16" font="1">for this enumeration. </text> <text top="826" left="108" width="5" height="16" font="1"> </text> <text top="847" left="108" width="632" height="16" font="1">In addition, the current definition of BACnetPriorityValue does not appear to allow for </text> <text top="868" left="108" width="686" height="16" font="1">proprietary object types that have an ENUMERATED Present_Value to be commandable, and </text> <text top="889" left="108" width="647" height="16" font="1">does not appear to allow for proprietary properties of an ENUMERATED data type to be </text> <text top="910" left="108" width="110" height="16" font="1">commandable. </text> <text top="931" left="108" width="5" height="16" font="1"> </text> <text top="952" left="108" width="698" height="16" font="2">Interpretation: A simple ENUMERATED value is encoded into a BACnetPriorityValue using </text> <text top="973" left="108" width="661" height="16" font="1">the ENUMERATED application tag. The “binary” option is to be interpreted as an abstract </text> <text top="994" left="108" width="668" height="16" font="1">ENUMERATED option, to be used for any ENUMERATED value. The real enumeration is </text> <text top="1015" left="108" width="687" height="16" font="1">sufficiently determined by the context of the “Priority_Array” property, namely the type of the </text> <text top="1036" left="108" width="512" height="16" font="1">associated commandable property and “Relinquish_Default” property. </text> <text top="1057" left="108" width="5" height="16" font="1"> </text> <text top="1078" left="108" width="5" height="16" font="1"> </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <text top="1099" left="115" width="72" height="14" font="0">Page 2 of 2 </text> <text top="1099" left="216" width="582" height="14" font="0"> ©2008 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="108" width="297" height="16" font="2">Question: Is this interpretation correct? </text> <text top="112" left="108" width="5" height="16" font="1"> </text> <text top="134" left="108" width="106" height="16" font="2">Answer: Yes </text> <text top="154" left="108" width="5" height="16" font="1"> </text> </page> </pdf2xml> Interpretation 135-2004-25 - June 21, 2008 2008-06-21 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-25.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="16" family="Times" color="#000000"/> <text top="1120" left="108" width="72" height="14" font="0">Page 1 of 2 </text> <text top="1120" left="216" width="4" height="14" font="0"> </text> <text top="1120" left="270" width="83" height="14" font="0"> </text> <text top="1120" left="378" width="4" height="14" font="0"> </text> <text top="1120" left="432" width="4" height="14" font="0"> </text> <text top="1120" left="486" width="4" height="14" font="0"> </text> <text top="1120" left="540" width="238" height="14" font="0">©2008 ASHRAE. All Rights reserved. </text> <text top="91" left="301" width="320" height="16" font="1">INTERPRETATION IC 135-2004-25 OF </text> <text top="112" left="270" width="382" height="16" font="1">ANSI/ASHRAE STANDARD 135-2004 BACnet - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="364" width="194" height="16" font="2">Approval Date: 6/21/2008 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="246" height="16" font="1">Request from: Rene Quirighetti (</text> <text top="238" left="354" width="221" height="16" font="3">rene.quirighetti@siemens.com</text> <text top="238" left="575" width="181" height="16" font="2">), Siemens Schweiz AG, </text> <text top="259" left="108" width="328" height="16" font="2">Gubelstrasse 22, Zug, Switzerland CH-6301 </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="672" height="16" font="2">ANSI/ASHRAE Standard 135-2004, Sections 13.2 and 13.3 relating to fault event reporting. </text> <text top="344" left="108" width="5" height="16" font="2"> </text> <text top="365" left="108" width="657" height="16" font="1">Background: The general rule in the current standard and subsequent addenda is that TO-</text> <text top="386" left="108" width="702" height="16" font="2">FAULT transitions are triggered by changes in the value of the Reliability property, independent </text> <text top="407" left="108" width="698" height="16" font="2">of object type. This is analogous to the relationship between TO-OFFNORMAL transitions and </text> <text top="428" left="108" width="377" height="16" font="2">changes in the value of the Present_Value property. </text> <text top="453" left="108" width="654" height="16" font="2">Unfortunately, the notification parameters listed in table 13-4 are not adequate to properly </text> <text top="474" left="108" width="662" height="16" font="2">express TO-FAULT transitions, since the value which caused the transition (the Reliability </text> <text top="495" left="108" width="329" height="16" font="2">property) is not included in the notification. </text> <text top="521" left="108" width="325" height="16" font="2">Section 13.8.1.14, Event Values, starts with: </text> <text top="546" left="162" width="609" height="16" font="4">This parameter, of type BACnetNotificationParameters, shall convey a set of values </text> <text top="567" left="162" width="245" height="16" font="4">relevant to the particular event… </text> <text top="592" left="108" width="692" height="16" font="2">This appears to indicate that the original intent was that notifications should include the current </text> <text top="613" left="108" width="697" height="16" font="2">values of the properties which caused the event state transition. Looking at the event parameters </text> <text top="634" left="108" width="271" height="16" font="2">in table 13.3 enforces this indication. </text> <text top="660" left="108" width="668" height="16" font="2">Including the relevant property values corresponding to the time of the event state transition </text> <text top="681" left="108" width="689" height="16" font="2">enables a client to receive a consistent set of the actual values describing the event (time stamp </text> <text top="701" left="108" width="702" height="16" font="2">of transition, from state, to state, actual property values which caused the transition). Otherwise, </text> <text top="722" left="108" width="664" height="16" font="2">eventing clients may be required to read dynamic property values describing the event after </text> <text top="743" left="108" width="701" height="16" font="2">receiving an event notification in order to display and / or archive the corresponding event. Such </text> <text top="764" left="108" width="687" height="16" font="2">a reading of properties should be prevented because the value of a dynamic property may have </text> <text top="785" left="108" width="673" height="16" font="2">changed in the meantime and could lead to an inconsistent set of data on the eventing client. </text> <text top="811" left="108" width="702" height="16" font="2">In the case of Multistate-Input objects, a client is forced to read the Reliability property after any </text> <text top="832" left="108" width="662" height="16" font="2">TO-FAULT event notification, since the event notification conveys the same values for the </text> <text top="853" left="108" width="647" height="16" font="2">MULTI_STATE_FAULT case as well as for those cases where the Present_Value is still </text> <text top="874" left="108" width="421" height="16" font="2">reliable, but took on a value that is listed in Fault_Values. </text> <text top="899" left="108" width="696" height="16" font="2">In the recent past, a significant amount of work has been done to clarify the conditions resulting </text> <text top="920" left="108" width="623" height="16" font="2">in TO-FAULT transitions; however, the issue of notifications has yet to be addressed. </text> <text top="946" left="108" width="679" height="16" font="2">To summarize, it is clear that TO-FAULT transitions are based on changes to the value of the </text> <text top="967" left="108" width="679" height="16" font="2">Reliability property. Given this, it is unreasonable to assume that the framers had the explicit </text> <text top="988" left="108" width="648" height="16" font="2">intention to exclude Reliability from TO_FAULT event notifications when it provides an </text> <text top="1009" left="108" width="687" height="16" font="2">indication that Present_Value is unreliable. It seems much more likely that this is an oversight </text> <text top="1030" left="108" width="689" height="16" font="2">associated with the current inconsistencies with the eventing model in general and TO-FAULT </text> <text top="1051" left="108" width="191" height="16" font="2">notifications in particular. </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <text top="1120" left="108" width="72" height="14" font="0">Page 2 of 2 </text> <text top="1120" left="216" width="4" height="14" font="0"> </text> <text top="1120" left="270" width="83" height="14" font="0"> </text> <text top="1120" left="378" width="4" height="14" font="0"> </text> <text top="1120" left="432" width="4" height="14" font="0"> </text> <text top="1120" left="486" width="4" height="14" font="0"> </text> <text top="1120" left="540" width="238" height="14" font="0">©2008 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="643" height="16" font="2">A good guiding principle is that event notifications should contain a consistent set of the </text> <text top="112" left="108" width="494" height="16" font="2">dynamic information describing the time and the cause of the event. </text> <text top="137" left="108" width="5" height="16" font="2"> </text> <text top="159" left="108" width="692" height="16" font="1">Interpretation: The event values provided in Table 13-4, Notification Parameters for Standard </text> <text top="180" left="108" width="694" height="16" font="2">Event Types, do not provide appropriate information for TO-FAULT events. It is unreasonable </text> <text top="201" left="108" width="649" height="16" font="2">to assume that there is an explicit intention to exclude Reliability from TO-FAULT event </text> <text top="222" left="108" width="678" height="16" font="2">notifications. Resolving both this specific issue and general inconsistencies in the fault event </text> <text top="243" left="108" width="668" height="16" font="2">model are currently working group discussion topics. Therefore, until this issue is resolved, </text> <text top="264" left="108" width="684" height="16" font="2">implementations are free to use proprietary event types for TO-FAULT events for the case the </text> <text top="285" left="108" width="686" height="16" font="2">Present_Value is unreliable, in order to comply with the statement in 13.8.1.14, and to provide </text> <text top="305" left="108" width="430" height="16" font="2">appropriate property values that are in-sync with the event. </text> <text top="331" left="108" width="5" height="16" font="2"> </text> <text top="352" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="373" left="108" width="5" height="16" font="2"> </text> <text top="394" left="108" width="105" height="16" font="1">Answer: No. </text> <text top="415" left="108" width="5" height="16" font="2"> </text> <text top="437" left="108" width="660" height="16" font="1">Comments: While the committee agrees that the standard language should be changed, as </text> <text top="458" left="108" width="698" height="16" font="2">currently written the standard seems to strongly indicate that standard object types may only use </text> <text top="479" left="108" width="677" height="16" font="2">standard Event_Types as indicated in Table 13-2. As such, fault events from standard objects </text> <text top="500" left="108" width="680" height="16" font="2">may not use the complex Event_Type to report fault event information. Fault events therefore </text> <text top="521" left="108" width="706" height="16" font="2">must use standard Event_Types, even though the notification parameters do not currently include </text> <text top="541" left="108" width="299" height="16" font="2">appropriate information for fault events. </text> </page> </pdf2xml> Interpretation 135-2004-26 - September 17, 2008 2008-09-17 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-26.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="9" family="Times" color="#000000"/> <text top="1099" left="115" width="72" height="14" font="0">Page 1 of 1 </text> <text top="1099" left="216" width="582" height="14" font="0"> ©2008 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2004-26 OF </text> <text top="112" left="264" width="395" height="16" font="2">ANSI/ASHRAE STANDARD 135-2004 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="1"> </text> <text top="196" left="329" width="265" height="16" font="1">Approval Date: September 17, 2008 </text> <text top="217" left="108" width="5" height="16" font="1"> </text> <text top="238" left="108" width="222" height="16" font="2">Request from: Carl Neilson (</text> <text top="238" left="330" width="205" height="16" font="3">cneilson@deltacontrols.com</text> <text top="238" left="535" width="197" height="16" font="1">), Delta Controls, 17850 56</text> <text top="234" left="732" width="9" height="11" font="4">th</text> <text top="238" left="742" width="43" height="16" font="1"> Ave, </text> <text top="259" left="108" width="161" height="16" font="1">Surrey, BC V3S 1C7. </text> <text top="280" left="108" width="5" height="16" font="1"> </text> <text top="302" left="108" width="594" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="595" height="16" font="1">ANSI/ASHRAE Standard 135-2004, Section 13.11.1.1.5 regarding Priority Filter. </text> <text top="344" left="108" width="5" height="16" font="1"> </text> <text top="365" left="108" width="535" height="16" font="2">Background: The Priority Filter parameter is documented as providing: </text> <text top="386" left="108" width="5" height="16" font="1"> </text> <text top="407" left="108" width="683" height="16" font="1">"… a means of restricting the summary to only those event-initiating objects that can generate </text> <text top="428" left="108" width="478" height="16" font="1">event notifications with a Priority as specified by this parameter." </text> <text top="449" left="108" width="5" height="16" font="1"> </text> <text top="470" left="108" width="666" height="16" font="1">Event-initiating objects in BACnet can generate notifications with 3 differenct priorities (to-</text> <text top="491" left="108" width="229" height="16" font="1">normal, to-fault, to-offnormal). </text> <text top="512" left="108" width="5" height="16" font="1"> </text> <text top="533" left="108" width="700" height="16" font="1">The ability of an object to generate a notification with any one of those priorities can be affected </text> <text top="554" left="108" width="701" height="16" font="1">by the algorithm (i.e. BUFFER_READY only issues to-normal and to-fault notifications) and by </text> <text top="575" left="108" width="689" height="16" font="1">the Event_Enable and Limit_Enable properties. This results in the question of what it means to </text> <text top="595" left="108" width="673" height="16" font="1">be able to generate a notification with a given priority. Does it simply mean that the object is </text> <text top="616" left="108" width="706" height="16" font="1">related to a Notification Class object with at least one priority that matches the Priority Filter? Or </text> <text top="637" left="108" width="624" height="16" font="1">does it mean that the object capable to generate a notification, based on the algorithm, </text> <text top="658" left="108" width="690" height="16" font="1">Event_Enable and Limit_Enable properties, and is related to a Notification Class object with at </text> <text top="679" left="108" width="364" height="16" font="1">least one priority that matches the Priority Filter? </text> <text top="700" left="108" width="5" height="16" font="1"> </text> <text top="721" left="108" width="698" height="16" font="1">There is also the concept of whether the object is fully configured or not. For example, an Event </text> <text top="742" left="108" width="652" height="16" font="1">Enrollment object with an Object_Property_Reference that contains the wildcard instance </text> <text top="763" left="108" width="688" height="16" font="1">(4194303) is not referencing an object and is thus not able to generate notifications. This is but </text> <text top="784" left="108" width="641" height="16" font="1">one example of how an event-initiating object might be configured such that it would be </text> <text top="805" left="108" width="277" height="16" font="1">incapable of generating notifications. </text> <text top="826" left="108" width="5" height="16" font="1"> </text> <text top="847" left="108" width="640" height="16" font="2">Interpretation: An event-initiating object matches the Priority Filter if it is related to a </text> <text top="868" left="108" width="687" height="16" font="1">Notification Class object with at least one priority that matches the Priority Filter regardless of </text> <text top="889" left="108" width="703" height="16" font="1">whether the object is fully configured and regardless of the values contained in its Limit_Enable, </text> <text top="910" left="108" width="267" height="16" font="1">Event_Enable or any other property. </text> <text top="931" left="108" width="5" height="16" font="1"> </text> <text top="953" left="108" width="297" height="16" font="2">Question: Is this interpretation correct? </text> <text top="973" left="108" width="5" height="16" font="1"> </text> <text top="995" left="108" width="111" height="16" font="2">Answer: Yes. </text> <text top="1016" left="108" width="5" height="16" font="1"> </text> <text top="1037" left="108" width="677" height="16" font="2">Comments: It should be noted that the other filters are also not affected by these conditions. </text> </page> </pdf2xml> Interpretation 135-2004-27 - September 17, 2008 2008-09-17 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-27.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="9" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 1 ©2008 ASHRAE. All Rights reserved. </text> <text top="91" left="301" width="320" height="16" font="1">INTERPRETATION IC 135-2004-27 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2004 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="329" width="265" height="16" font="2">Approval Date: September 17, 2008 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="202" height="16" font="1">Request from: Bill Swan (</text> <text top="238" left="310" width="193" height="16" font="3">bill.swan@honeywell.com</text> <text top="238" left="502" width="157" height="16" font="2">), Alerton, 6675 - 185</text> <text top="234" left="659" width="9" height="11" font="4">th</text> <text top="238" left="669" width="76" height="16" font="2"> Ave. NE, </text> <text top="259" left="108" width="172" height="16" font="2">Redmond, WA 98052. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="668" height="16" font="2">ANSI/ASHRAE Standard 135-2004, Section 21 relating to BACnetEventParameters 'buffer-</text> <text top="344" left="108" width="104" height="16" font="2">ready' choice. </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="659" height="16" font="1">Background: The BACnetEventParameters production has two parameters for the 'buffer-</text> <text top="407" left="108" width="678" height="16" font="2">ready' choice: notification-threshold and previous-notification-count. However, Table 12-15 </text> <text top="428" left="108" width="682" height="16" font="2">(Clause 12.12.5 on p.186) in the Event Enrollment object shows only Notification_Threshold. </text> <text top="449" left="108" width="706" height="16" font="2">The function of this parameter is not clear -- it is also the only 'parameter' that is not configurable </text> <text top="470" left="108" width="301" height="16" font="2">but which reflects the state of an object. </text> <text top="491" left="108" width="5" height="16" font="2"> </text> <text top="512" left="108" width="683" height="16" font="2">The parameter is traceable back to the introduction of the Trend Log object in Addendum 135-</text> <text top="533" left="108" width="54" height="16" font="2">1995b. </text> <text top="554" left="108" width="5" height="16" font="2"> </text> <text top="575" left="108" width="632" height="16" font="1">Interpretation: The presence of 'previous-notification-count' in the buffer-ready event </text> <text top="596" left="108" width="479" height="16" font="2">parameters in the BACnetEventParameters production is an error. </text> <text top="617" left="108" width="5" height="16" font="2"> </text> <text top="638" left="108" width="292" height="16" font="1">Question: Is this interpretation correct? </text> <text top="659" left="108" width="5" height="16" font="2"> </text> <text top="680" left="108" width="100" height="16" font="1">Answer: No. </text> <text top="701" left="108" width="5" height="16" font="2"> </text> <text top="722" left="108" width="316" height="16" font="1">Comments: Clause 13.3.7 explains its use. </text> </page> </pdf2xml> Interpretation 135-2004-28 - September 17, 2008 2008-09-17 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-28.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="9" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 1 ©2008 ASHRAE. All Rights reserved. </text> <text top="91" left="301" width="320" height="16" font="1">INTERPRETATION IC 135-2004-28 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2004 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="329" width="265" height="16" font="2">Approval Date: September 17, 2008 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="202" height="16" font="1">Request from: Bill Swan (</text> <text top="238" left="310" width="193" height="16" font="3">bill.swan@honeywell.com</text> <text top="238" left="502" width="157" height="16" font="2">), Alerton, 6670 - 185</text> <text top="234" left="659" width="9" height="11" font="4">th</text> <text top="238" left="669" width="76" height="16" font="2"> Ave. NE, </text> <text top="259" left="108" width="172" height="16" font="2">Redmond, WA 98052. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="579" height="16" font="2">ANSI/ASHRAE Standard 135-2004, Sections 15.10.1.3.1 and 18.8.4 relating to </text> <text top="344" left="108" width="345" height="16" font="2">WritePropertyMultiple with incorrect datatype. </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="682" height="16" font="1">Background: Clause 15.10.1.3.1 mandates a specific Result(-) return for the case where one </text> <text top="407" left="108" width="697" height="16" font="2">element of a WritePropertyMultiple-Request contains the wrong datatype for the property being </text> <text top="428" left="108" width="663" height="16" font="2">written; this concept also appears in ANSI/ASHRAE Standard 135.1-2007 Clause 9.23.2.6. </text> <text top="449" left="108" width="5" height="16" font="2"> </text> <text top="470" left="108" width="692" height="16" font="2">However, Standard 135 Clause 18.8.4 (Reject Reason INVALID_TAG) notes the possibility of </text> <text top="491" left="108" width="704" height="16" font="2">there being an "invalid tag" in an APDU with no clear definition of what makes a tag "invalid" -- </text> <text top="512" left="108" width="639" height="16" font="2">leaving it up to the implementer. The clause also permits other possible Reject Reasons </text> <text top="533" left="108" width="702" height="16" font="2">including INVALID_ PARAMETER_DATA_TYPE. One will note that parameter datatypes do </text> <text top="554" left="108" width="668" height="16" font="2">not appear in the Clause 20.1 "Fixed Part of BACnet APDUs", therefore the Reject Reasons </text> <text top="575" left="108" width="488" height="16" font="2">must generally apply to the Clause 21 elements of service requests. </text> <text top="595" left="108" width="5" height="16" font="2"> </text> <text top="616" left="108" width="669" height="16" font="2">One notes too that (Standard 135) Clause 20.1.8 states, "The BACnet Reject-PDU is used to </text> <text top="637" left="108" width="669" height="16" font="2">reject… based on syntactical flaws or other protocol errors that prevent the PDU from being </text> <text top="658" left="108" width="611" height="16" font="2">interpreted --> or the requested service from being provided. <--" (emphasis added). </text> <text top="679" left="108" width="5" height="16" font="2"> </text> <text top="700" left="108" width="691" height="16" font="2">From these it seems clear that there is support in Standard 135 for BACnet parsers that are able </text> <text top="721" left="108" width="672" height="16" font="2">to check for correct datatypes during the parsing of a service request conducted in its totality </text> <text top="742" left="108" width="678" height="16" font="2">before execution begins, in this case said execution being governed by (Standard 135) Clause </text> <text top="763" left="108" width="688" height="16" font="2">15.10. But (Standard 135.1) Clause 9.23.2.6 will cause devices that contain such "pre-parsers" </text> <text top="784" left="108" width="524" height="16" font="2">to fail; this seems to be an oversight excluding a valid implementation. </text> <text top="805" left="108" width="5" height="16" font="2"> </text> <text top="826" left="108" width="685" height="16" font="1">Interpretation: It was not the intent of Standard 135 to prohibit datatype checking before the </text> <text top="847" left="108" width="275" height="16" font="2">execution of a service request begins. </text> <text top="868" left="108" width="5" height="16" font="2"> </text> <text top="890" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="911" left="108" width="5" height="16" font="2"> </text> <text top="932" left="108" width="111" height="16" font="1">Answer: Yes. </text> <text top="953" left="108" width="5" height="16" font="2"> </text> <text top="974" left="108" width="414" height="16" font="1">Comments: The standard will be modified accordingly. </text> </page> </pdf2xml> Interpretation 135-2004-29 - January 24, 2009 2009-01-24 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2004-29.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="9" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 1 ©2009 ASHRAE. All Rights reserved. </text> <text top="91" left="301" width="320" height="16" font="1">INTERPRETATION IC 135-2004-29 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2004 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="339" width="244" height="16" font="2">Approval Date: January 24, 2009 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="202" height="16" font="1">Request from: Bill Swan (</text> <text top="238" left="310" width="193" height="16" font="3">bill.swan@honeywell.com</text> <text top="238" left="502" width="157" height="16" font="2">), Alerton, 6670 - 185</text> <text top="234" left="659" width="9" height="11" font="4">th</text> <text top="238" left="669" width="76" height="16" font="2"> Ave. NE, </text> <text top="259" left="108" width="172" height="16" font="2">Redmond, WA 98052. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="671" height="16" font="2">ANSI/ASHRAE Standard 135-2004, Section 19.1.3.2, relating to creating configuration File </text> <text top="344" left="108" width="217" height="16" font="2">objects in the restore process. </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="691" height="16" font="1">Background: The Standard notes that once "device B" has responded with a 'Result(+)' to the </text> <text top="407" left="108" width="704" height="16" font="2">request that it start the restore process, if the configuration File objects do not exist in "device B" </text> <text top="428" left="108" width="639" height="16" font="2">then "device A" must create these objects in "device B" using the CreateObject service. </text> <text top="449" left="108" width="695" height="16" font="2">However, the CreateObject service has many options, including 'object type' vs. 'object instance </text> <text top="470" left="108" width="553" height="16" font="2">creation, and an optional capability to initialize the File object's properties. </text> <text top="491" left="108" width="5" height="16" font="2"> </text> <text top="512" left="108" width="660" height="16" font="2">However, object creation does not succeed if even a single property in the initialization list </text> <text top="533" left="108" width="683" height="16" font="2">cannot be initialized, and there is no guarantee that a created but uninitialized property will be </text> <text top="554" left="108" width="694" height="16" font="2">writable. Attempting initialization, even with the property values read in the Backup procedure </text> <text top="575" left="108" width="663" height="16" font="2">(including File_Size and Record_Count?) does not appear to be a straightforward process. </text> <text top="595" left="108" width="5" height="16" font="2"> </text> <text top="617" left="108" width="702" height="16" font="1">Interpretation: "Device A" is not required to initialize any File object properties when creating </text> <text top="638" left="108" width="417" height="16" font="2">File objects as part of the Restore process in Clause 19.1. </text> <text top="659" left="108" width="5" height="16" font="2"> </text> <text top="680" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="701" left="108" width="5" height="16" font="2"> </text> <text top="722" left="108" width="111" height="16" font="1">Answer: Yes. </text> <text top="743" left="108" width="5" height="16" font="2"> </text> <text top="764" left="108" width="678" height="16" font="1">Comments: There is no expectation that the A device will provide any property values in the </text> <text top="785" left="108" width="676" height="16" font="2">CreateObject service or follow the CreateObject service with any writes to initialize property </text> <text top="806" left="108" width="682" height="16" font="2">values of file objects. The only requirement on the A device is that it uses the objectIdentifier </text> <text top="827" left="108" width="372" height="16" font="2">form of CreateObject and not the objectType form. </text> </page> </pdf2xml> Interpretation 135-2008-1 - June 20, 2009 2009-06-20 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-1.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 1 ©2009 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2008-1 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="351" width="221" height="16" font="2">Approval Date: June 20, 2009 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="226" height="16" font="1">Request from: Roland Laird (</text> <text top="238" left="334" width="204" height="16" font="3">rlaird@reliablecontrols.com</text> <text top="238" left="537" width="258" height="16" font="2">), Reliable Controls, 120 Hallowell </text> <text top="259" left="108" width="220" height="16" font="2">Road, Victoria, BC V8L5B4. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="659" height="16" font="2">ANSI/ASHRAE Standard 135-2008, Sections 12.19.10 and 12.20.10, relating to Shrinking </text> <text top="344" left="108" width="411" height="16" font="2">Number_of_States in Commandable Multi-state objects. </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="705" height="16" font="1">Background: A question came up regarding what to do with the Present_Value, Priority_Array </text> <text top="407" left="108" width="692" height="16" font="2">and the Relinquish_Default values if they exceed the new value of a shrunk Number_Of_States </text> <text top="428" left="108" width="70" height="16" font="2">property. </text> <text top="449" left="108" width="5" height="16" font="2"> </text> <text top="470" left="108" width="665" height="16" font="2">Imagine the Present_Value, Relinguish_Default and Priority_Array having values of 9. The </text> <text top="491" left="108" width="698" height="16" font="2">number of states property is adjusted from 10 to the value 7. What should happen to elements of </text> <text top="512" left="108" width="467" height="16" font="2">the Priority_Array, Relinquish_Default and the Present_Value? </text> <text top="533" left="108" width="5" height="16" font="2"> </text> <text top="554" left="108" width="657" height="16" font="2">In Section 12.20.10 the definition of the Number_Of_States property includes "defines the </text> <text top="575" left="108" width="691" height="16" font="2">number of states the Present_Value may have.", but the Priority_Array and Relinguish_Default </text> <text top="595" left="108" width="312" height="16" font="2">properties are not limited in the same way. </text> <text top="616" left="108" width="5" height="16" font="2"> </text> <text top="637" left="108" width="316" height="16" font="2">This issue was identified to the BTL-WG. </text> <text top="658" left="108" width="5" height="16" font="2"> </text> <text top="680" left="108" width="700" height="16" font="1">Interpretation: Existing Priority_Array, Relinguish_Default, and Present_Value values are not </text> <text top="701" left="108" width="444" height="16" font="2">required to be changed when the Number_Of_States shrinks. </text> <text top="722" left="108" width="5" height="16" font="2"> </text> <text top="743" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="764" left="108" width="5" height="16" font="2"> </text> <text top="785" left="108" width="111" height="16" font="1">Answer: Yes. </text> <text top="806" left="108" width="5" height="16" font="2"> </text> <text top="827" left="108" width="642" height="16" font="1">Comments: It should be noted that there are other properties such as Alarm_Values and </text> <text top="848" left="108" width="623" height="16" font="2">Fault_Values that are not required to be updated when the Number_of_States shrinks. </text> </page> </pdf2xml> Interpretation 135-2008-2 - June 20, 2009 2009-06-20 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-2.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 2 ©2009 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2008-2 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="351" width="221" height="16" font="2">Approval Date: June 20, 2009 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="238" height="16" font="1">Request from: Craig Gemmill (</text> <text top="238" left="346" width="206" height="16" font="3">craig.gemmill@tridium.com</text> <text top="238" left="552" width="193" height="16" font="2">), Tridium, 3951 Westerre </text> <text top="259" left="108" width="322" height="16" font="2">Parkway, Suite 350, Richmond, VA 23233. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="620" height="16" font="2">ANSI/ASHRAE Standard 135-2008, Section 12.24.4, related to the calculation of the </text> <text top="344" left="108" width="331" height="16" font="2">Present_Value property of a Schedule object. </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="683" height="16" font="1">Background: There is potentially some ambiguity in how a Schedule object’s Present_Value </text> <text top="407" left="108" width="329" height="16" font="2">shall be calculated in the following situation: </text> <text top="423" left="135" width="632" height="22" font="2">• there are no entries in the Exception_Schedule that are in effect for the current day. </text> <text top="445" left="135" width="674" height="22" font="2">• there are no entries in the Weekly_Schedule array for the present day with a time prior to </text> <text top="472" left="162" width="123" height="16" font="2">the current time. </text> <text top="488" left="135" width="502" height="22" font="2">• there are entries in the Weekly_Schedule array for an earlier day. </text> <text top="515" left="108" width="5" height="16" font="2"> </text> <text top="536" left="108" width="616" height="16" font="2">Most of the language in Section 12.24.4 appears to support the interpretation that the </text> <text top="557" left="108" width="643" height="16" font="2">Present_Value should NOT be assigned a value from the Weekly_Schedule in this case. </text> <text top="578" left="108" width="702" height="16" font="2">Therefore, the Present_Value should take on the value of Schedule_Default, according to item 3. </text> <text top="599" left="108" width="187" height="16" font="2">in paragraph 3 of 12.24.4 </text> <text top="620" left="108" width="5" height="16" font="2"> </text> <text top="641" left="108" width="695" height="16" font="2">However, section 12.24.4, paragraph 4 states: “The method for evaluating the current value of a </text> <text top="662" left="108" width="566" height="16" font="2">schedule (either exception or weekly) is to find the latest element in the list of </text> <text top="683" left="108" width="692" height="16" font="2">BACnetTimeValues that occurs on or before the current time, and then use that element's value </text> <text top="704" left="108" width="670" height="16" font="2">as the current value for the schedule.” Reading the Weekly_Schedule as a continuous list of </text> <text top="725" left="108" width="683" height="16" font="2">time value pairs, the “latest element in the list” is the BACnetTimeValue that appeared for the </text> <text top="746" left="108" width="678" height="16" font="2">previous day, or perhaps earlier. So according to this, if the previous day has a value at some </text> <text top="767" left="108" width="694" height="16" font="2">point, this is the value the Present_Value should take on. In this case, the Present_Value would </text> <text top="788" left="108" width="694" height="16" font="2">only be driven by Schedule_Default when there are no entries in either the Exception_Schedule </text> <text top="809" left="108" width="641" height="16" font="2">or the Weekly_Schedule. This implies the need for a cross-day backwards evaluation to </text> <text top="830" left="108" width="217" height="16" font="2">determine the Present_Value. </text> <text top="851" left="108" width="5" height="16" font="2"> </text> <text top="872" left="108" width="699" height="16" font="1">Interpretation: My interpretation is that each element of the Weekly_Schedule is distinct from </text> <text top="893" left="108" width="684" height="16" font="2">the other elements, and one day’s entries have no effect on another the object’s Present_Value </text> <text top="914" left="108" width="697" height="16" font="2">for another day. The object is re-evaluated at 00:00:00.00 of every day, and if no entry exists in </text> <text top="935" left="108" width="539" height="16" font="2">the Weekly_Schedule at that time, it takes on the Schedule_Default value. </text> <text top="956" left="108" width="5" height="16" font="2"> </text> <text top="977" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="998" left="108" width="5" height="16" font="2"> </text> <text top="1019" left="108" width="111" height="16" font="1">Answer: Yes. </text> <text top="1040" left="108" width="5" height="16" font="2"> </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <text top="1120" left="108" width="699" height="14" font="0">Page 2 of 2 ©2009 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="706" height="16" font="1">Comments: This is made clear by the last paragraph of clause of 12.24.4 which reads as follows: </text> <text top="112" left="108" width="643" height="16" font="2">Note that the Present_Value property will be assigned the value of the Schedule_Default </text> <text top="133" left="108" width="655" height="16" font="2">property at 00:00 of any given day, unless there is an entry for 00:00 in effect for that day. </text> </page> </pdf2xml> Interpretation 135-2008-3 - January 23, 2010 2010-01-23 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-3.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 1 ©2010 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2008-3 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="339" width="244" height="16" font="2">Approval Date: January 23, 2010 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="234" height="16" font="1">Request from: Bernhard Isler (</text> <text top="238" left="342" width="210" height="16" font="3">bernhard.isler@siemens.com</text> <text top="238" left="551" width="205" height="16" font="2">), Siemens Switzerland Ltd, </text> <text top="259" left="108" width="546" height="16" font="2">Building Technologies Group, Gubelstrasse 22, CH6301 Zug, Switzerland. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="655" height="16" font="2">ANSI/ASHRAE Standard 135-2008, Section 12, relating to the data type of the number of </text> <text top="344" left="108" width="537" height="16" font="2">elements of an array when accessing an array property with array index 0. </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="646" height="16" font="1">Background: A question came up regarding what data type to be used for encoding the </text> <text top="407" left="108" width="674" height="16" font="2">Property Value parameter in read and write services when reading or writing array element 0 </text> <text top="428" left="108" width="190" height="16" font="2">(i.e. the size of the array). </text> <text top="449" left="108" width="5" height="16" font="2"> </text> <text top="470" left="108" width="701" height="16" font="2">In 135-2008, there is no explicit definition for this. In clause 12 on page 129 one can find "count </text> <text top="491" left="108" width="205" height="16" font="2">of the number of elements". </text> <text top="512" left="108" width="663" height="16" font="2">One hint is the data type of the Number_Of_States property in Multi-state objects, which is </text> <text top="533" left="108" width="698" height="16" font="2">Unsigned. This number corresponds with what is read from State_Text array element 0. Also, in </text> <text top="554" left="108" width="684" height="16" font="2">all related services the Property Array Index parameter is of type Unsigned. The highest index </text> <text top="575" left="108" width="321" height="16" font="2">corresponds to the value of array element 0. </text> <text top="595" left="108" width="5" height="16" font="2"> </text> <text top="616" left="108" width="436" height="16" font="2">In 135.1-2007, no explicit statement on this could be found. </text> <text top="637" left="108" width="5" height="16" font="2"> </text> <text top="658" left="108" width="428" height="16" font="2">Also, the BTL Implementation Guide is unspecific on this. </text> <text top="679" left="108" width="5" height="16" font="2"> </text> <text top="701" left="108" width="676" height="16" font="1">Interpretation: When reading or writing array element 0 (i.e. the number of elements of the </text> <text top="722" left="108" width="688" height="16" font="2">array), the Property Value parameter of the respective read and write services shall be encoded </text> <text top="743" left="108" width="361" height="16" font="2">as a primitive application tagged Unsigned value. </text> <text top="764" left="108" width="5" height="16" font="2"> </text> <text top="785" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="806" left="108" width="5" height="16" font="2"> </text> <text top="827" left="108" width="111" height="16" font="1">Answer: Yes. </text> <text top="848" left="108" width="5" height="16" font="2"> </text> </page> </pdf2xml> Interpretation 135-2008-4 - January 23, 2010 2010-01-23 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-4.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 1 ©2010 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2008-4 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="339" width="244" height="16" font="2">Approval Date: January 23, 2010 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="234" height="16" font="1">Request from: Bernhard Isler (</text> <text top="238" left="342" width="210" height="16" font="3">bernhard.isler@siemens.com</text> <text top="238" left="551" width="205" height="16" font="2">), Siemens Switzerland Ltd, </text> <text top="259" left="108" width="546" height="16" font="2">Building Technologies Group, Gubelstrasse 22, CH6301 Zug, Switzerland. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="684" height="16" font="2">ANSI/ASHRAE Standard 135-2008, Section 12.13.7, File Object Modification_Date property </text> <text top="344" left="108" width="48" height="16" font="2">value. </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="701" height="16" font="1">Background: BACnet allows devices to have no clock. This is implied by the requirements for </text> <text top="407" left="108" width="688" height="16" font="2">the Device Object properties Local_Date and Local_Time, the data type of the Device Object's </text> <text top="428" left="108" width="694" height="16" font="2">Last_Restore_Time being of type BACnetTimeStamp, in the Event_Time_Stamps properties of </text> <text top="449" left="108" width="666" height="16" font="2">type BACnetTimeStamp of event reporting objects, and the Time Stamp parameter of event </text> <text top="470" left="108" width="211" height="16" font="2">notification service requests. </text> <text top="491" left="108" width="5" height="16" font="2"> </text> <text top="512" left="108" width="669" height="16" font="2">In clause 12.13, File Object Type, there is no requirement that a device must have a clock in </text> <text top="533" left="108" width="216" height="16" font="2">order to support File Objects. </text> <text top="554" left="108" width="5" height="16" font="2"> </text> <text top="575" left="108" width="669" height="16" font="2">The File Object's Modification_Date property (clause 12.13.7) is a required property of type </text> <text top="595" left="108" width="686" height="16" font="2">BACnetDateTime. In the definition of this property, there is no statement on what the value of </text> <text top="616" left="108" width="377" height="16" font="2">this property shall be when the device has no clock. </text> <text top="637" left="108" width="5" height="16" font="2"> </text> <text top="658" left="108" width="689" height="16" font="2">BACnetDateTime is a sequence of primitive Date and Time values. Date and Time values may </text> <text top="679" left="108" width="675" height="16" font="2">have all octets set to X'FF' to indicate "any" or "don't care", as defined in clauses 20.2.12 and </text> <text top="700" left="108" width="63" height="16" font="2">20.2.13. </text> <text top="721" left="108" width="5" height="16" font="2"> </text> <text top="742" left="108" width="671" height="16" font="2">In 135.1-2007, clause 9.13.1, Positive AtomicWriteFile Execution Tests, all tests are written </text> <text top="763" left="108" width="676" height="16" font="2">under the assumption that a device has a clock. This appears to be a requirement which is not </text> <text top="784" left="108" width="162" height="16" font="2">covered by 135-2008. </text> <text top="805" left="108" width="5" height="16" font="2"> </text> <text top="826" left="108" width="654" height="16" font="1">Interpretation: BACnet allows devices to have no clock. BACnet does not prohibit such </text> <text top="847" left="108" width="691" height="16" font="2">devices to support File objects. For devices that have no clock, the Modification_Date property </text> <text top="868" left="108" width="686" height="16" font="2">of File Objects may contain X'FF' in all octets of Date and Time. This special value is the only </text> <text top="889" left="108" width="432" height="16" font="2">option available to indicate "don't know", there is no clock. </text> <text top="910" left="108" width="5" height="16" font="2"> </text> <text top="932" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="953" left="108" width="5" height="16" font="2"> </text> <text top="974" left="108" width="105" height="16" font="1">Answer: No. </text> <text top="995" left="108" width="5" height="16" font="2"> </text> <text top="1016" left="108" width="706" height="16" font="1">Comments: The standard is unclear on this matter. If the device does not contain the Local_Date </text> <text top="1037" left="108" width="696" height="16" font="2">and Local_Time properties, then the content of the Modificaion_Date property is a local matter. </text> </page> </pdf2xml> Interpretation 135-2008-5 - May 28, 2010 2010-05-28 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-5.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="9" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 1 ©2010 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2008-5 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="351" width="221" height="16" font="2">Approval Date: May 28, 2010 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="277" height="16" font="1">Request from: William (Bill) Swan (</text> <text top="238" left="385" width="193" height="16" font="3">bill.swan@honeywell.com</text> <text top="238" left="578" width="227" height="16" font="2">), Alerton – Honeywell, 6670 - </text> <text top="259" left="108" width="27" height="16" font="2">185</text> <text top="255" left="135" width="9" height="11" font="4">th</text> <text top="259" left="144" width="244" height="16" font="2"> Ave NE, Redmond, WA 98052. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="464" height="16" font="2">ANSI/ASHRAE Standard 135-2008 relating to Date and Time. </text> <text top="344" left="108" width="5" height="16" font="2"> </text> <text top="365" left="108" width="645" height="16" font="1">Background: Dates and times are frequently noted throughout the standard, sometimes </text> <text top="386" left="108" width="664" height="16" font="2">modified by the terms "local" or "current" or "UTC", but usually not. Generally it has been </text> <text top="407" left="108" width="690" height="16" font="2">assumed that unless otherwise specified, dates and times are "local" dates and times, to wit, the </text> <text top="428" left="108" width="686" height="16" font="2">date and time in effect at the location where the device resides and not UTC date and time, but </text> <text top="449" left="108" width="273" height="16" font="2">this is not explicitly stated anywhere. </text> <text top="470" left="108" width="5" height="16" font="2"> </text> <text top="491" left="108" width="657" height="16" font="1">Interpretation: All dates and times not explicitly declared to be UTC dates and times are </text> <text top="512" left="108" width="214" height="16" font="2">always local dates and times. </text> <text top="533" left="108" width="9" height="16" font="2"> </text> <text top="554" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="575" left="108" width="5" height="16" font="2"> </text> <text top="596" left="108" width="106" height="16" font="1">Answer: Yes </text> <text top="617" left="108" width="5" height="16" font="2"> </text> </page> </pdf2xml> Interpretation 135-2008-6 - October 28, 2010 2010-10-28 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-6.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="16" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 1 ©2010 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2008-6 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="338" width="246" height="16" font="2">Approval Date: October 28, 2010 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="212" height="16" font="1">Request from: René Kälin (</text> <text top="238" left="320" width="190" height="16" font="3">rene.kaelin@siemens.com</text> <text top="238" left="509" width="249" height="16" font="2">), Siemens Schweiz AG, Building </text> <text top="259" left="108" width="703" height="16" font="2">Technologies Division, International Headquarters, Gubelstrasse 22, CH-6301 Zug, Switzerland. </text> <text top="259" left="811" width="5" height="16" font="3"> </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="669" height="16" font="1">Reference: This request for interpretation refers to the change of requirements presented in </text> <text top="323" left="108" width="608" height="16" font="2">ANSI/ASHRAE Addendum l to ANSI/ASHRAE Standard 135-2008, Section 1 and </text> <text top="344" left="108" width="694" height="16" font="2">ANSI/ASHRAE Addendum v to ANSI/ASHRAE Standard 135-2008, Section 3, relating to the </text> <text top="365" left="108" width="448" height="16" font="2">support of the BIBB NM-CE-A in the device profile B-AWS. </text> <text top="386" left="108" width="5" height="16" font="2"> </text> <text top="407" left="108" width="115" height="16" font="1">Background: </text> <text top="428" left="108" width="653" height="16" font="2">In Addendum 135-2008l an additional device profile B-AWS is specified for an advanced </text> <text top="449" left="108" width="679" height="16" font="2">workstation. The BIBBs of the B-OWS device profile are reduced to get a device profile with </text> <text top="469" left="108" width="674" height="16" font="2">limited capabilities in relation to B-AWS. With this the BIBB NM-CE-A was moved from B-</text> <text top="490" left="108" width="683" height="16" font="2">OWS to B-AWS together with other BIBBs of the section Device & Network Mgmt (e.g. DM-</text> <text top="511" left="108" width="176" height="16" font="2">DCC-A, DM-BR-A, ..). </text> <text top="532" left="108" width="5" height="16" font="2"> </text> <text top="553" left="108" width="657" height="16" font="2">In Addendum 135-2008v Section 3 the BIBB NM-CE-A shall be removed from the device </text> <text top="574" left="108" width="664" height="16" font="2">profiles because of the following reason (see rationale): 'The PTP connection establishment </text> <text top="595" left="108" width="631" height="16" font="2">mechanism has identified deficiencies in certain situations. Until those deficiencies are </text> <text top="616" left="108" width="660" height="16" font="2">addressed, the requirement for the inclusion of the PTP connection establishment BIBBs is </text> <text top="637" left="108" width="72" height="16" font="2">removed. </text> <text top="658" left="108" width="5" height="16" font="2"> </text> <text top="679" left="108" width="705" height="16" font="2">It is not obvious if the BIBB NM-CE-A has to be supported for the device profile B-AWS or not. </text> <text top="700" left="108" width="5" height="16" font="2"> </text> <text top="721" left="108" width="617" height="16" font="1">Interpretation: The BIBB NM-CE-A is not required for the device profile B-AWS. </text> <text top="742" left="108" width="667" height="16" font="2">It is not intended to keep or reintroduce the BIBB NM-CE-A for the device profile B-AWS. </text> <text top="763" left="108" width="691" height="16" font="2">Even it is not explicitly stated in Addendum 135-2008v Section 3, removing the BIBB NM-CE-</text> <text top="784" left="108" width="698" height="16" font="2">A has to be applied to all device profiles. Neither the rational nor the change to the table implies </text> <text top="805" left="108" width="292" height="16" font="2">a restriction for specific device profiles. </text> <text top="826" left="108" width="5" height="16" font="2"> </text> <text top="847" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="868" left="108" width="5" height="16" font="2"> </text> <text top="890" left="108" width="111" height="16" font="1">Answer: Yes. </text> </page> </pdf2xml> Interpretation 135-2008-7 - October 28, 2010 2010-10-28 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-7.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="9" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 1 ©2010 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2008-7 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="338" width="246" height="16" font="2">Approval Date: October 28, 2010 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="222" height="16" font="1">Request from: Carl Neilson (</text> <text top="238" left="330" width="205" height="16" font="3">cneilson@deltacontrols.com</text> <text top="238" left="535" width="197" height="16" font="2">), Delta Controls, 17850 56</text> <text top="234" left="732" width="9" height="11" font="4">th</text> <text top="238" left="742" width="48" height="16" font="2"> Ave., </text> <text top="259" left="108" width="165" height="16" font="2">Surrey, BC V3S 1C7. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="551" height="16" font="2">ANSI/ASHRAE Standard 135-2008, Clauses 5.4 and 5.4.5.3, relating to the </text> <text top="344" left="108" width="496" height="16" font="2">CannotSendSegmentedComplexACK for the AWAIT_RESPONSE. </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="618" height="16" font="1">Background: In the AWAIT_RESPONSE state of the server Application TSM, the </text> <text top="407" left="108" width="685" height="16" font="2">CannotSendSegmentedComplexACK transition describes the conditions under which a device </text> <text top="428" left="108" width="693" height="16" font="2">should abort a request based on the size of the response. In Section 5.4.5.3 Conditions (c) & (d) </text> <text top="449" left="108" width="646" height="16" font="2">require knowledge of the total number of segments that will be required for the response. </text> <text top="470" left="108" width="5" height="16" font="2"> </text> <text top="491" left="108" width="682" height="16" font="2">In Paragraph 5 of Clause 5.4, the standard describes an implementation approach whereby the </text> <text top="512" left="108" width="661" height="16" font="2">segmentation is handled by the application program, and thus the total number of segments </text> <text top="533" left="108" width="431" height="16" font="2">required is not necessarily known by the Application TSM. </text> <text top="554" left="108" width="5" height="16" font="2"> </text> <text top="575" left="108" width="664" height="16" font="1">Interpretation: The existence of Conditions (c) & (d) in Clause 5.4.5.3 do not constitute a </text> <text top="596" left="108" width="690" height="16" font="2">requirement that an implementation know the total size of a response before the initial segment </text> <text top="617" left="108" width="688" height="16" font="2">of the response is transmitted. The conditions are only provided for those implementations that </text> <text top="638" left="108" width="426" height="16" font="2">do know the total size of the response at this point in time. </text> <text top="659" left="108" width="9" height="16" font="2"> </text> <text top="680" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="701" left="108" width="5" height="16" font="2"> </text> <text top="722" left="108" width="111" height="16" font="1">Answer: Yes. </text> <text top="743" left="108" width="5" height="16" font="2"> </text> <text top="764" left="108" width="5" height="16" font="2"> </text> </page> </pdf2xml> Interpretation 135-2008-8 - October 28, 2010 2010-10-28 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-8.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 1 ©2010 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2008-8 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="338" width="246" height="16" font="2">Approval Date: October 28, 2010 </text> <text top="217" left="459" width="5" height="16" font="2"> </text> <text top="238" left="108" width="226" height="16" font="1">Request from: Dean Matsen (</text> <text top="238" left="334" width="217" height="16" font="3">dean.matsen@honeywell.com</text> <text top="238" left="550" width="196" height="16" font="2">), Alerton Dealer Business </text> <text top="259" left="108" width="654" height="16" font="2">Honeywell Automation & Control Solutions, 6670 185th Ave. NE, Redmond, WA 98052. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="692" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in Addendum g </text> <text top="323" left="108" width="658" height="16" font="2">to ANSI/ASHRAE Standard 135-2008, Section 24.5 and Figure 24-2 (page 32), relating to </text> <text top="344" left="108" width="295" height="16" font="2">securing proprietary network messages. </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="680" height="16" font="1">Background: Figure 24-2 of Addendum g to 135-2008 offers, as an example, the mehod for </text> <text top="407" left="108" width="688" height="16" font="2">wrapping an NPDU containing a standard network message, but there is no mention of what to </text> <text top="428" left="108" width="284" height="16" font="2">do with proprietary network messages. </text> <text top="449" left="108" width="5" height="16" font="2"> </text> <text top="470" left="108" width="684" height="16" font="1">Interpretation: I would assume that in Figure 24-2, in the "NSDU" section, there would be a </text> <text top="491" left="108" width="462" height="16" font="2">two-byte vendor identifier following the "Message-Type" field. </text> <text top="512" left="108" width="5" height="16" font="2"> </text> <text top="533" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="554" left="108" width="5" height="16" font="2"> </text> <text top="575" left="108" width="106" height="16" font="1">Answer: Yes </text> <text top="596" left="108" width="5" height="16" font="2"> </text> <text top="617" left="108" width="5" height="16" font="2"> </text> <text top="638" left="108" width="5" height="16" font="2"> </text> </page> </pdf2xml> Interpretation 135-2008-9 - October 28, 2010 2010-10-28 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-9.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 1 ©2010 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2008-9 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="338" width="246" height="16" font="2">Approval Date: October 28, 2010 </text> <text top="217" left="459" width="5" height="16" font="2"> </text> <text top="238" left="108" width="226" height="16" font="1">Request from: Dean Matsen (</text> <text top="238" left="334" width="217" height="16" font="3">dean.matsen@honeywell.com</text> <text top="238" left="550" width="196" height="16" font="2">), Alerton Dealer Business </text> <text top="259" left="108" width="659" height="16" font="2">Honeywell Automation & Control Solutions, 6670 185th Ave. NE, Redmond, WA 98052. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="692" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in Addendum g </text> <text top="323" left="108" width="615" height="16" font="2">to ANSI/ASHRAE Standard 135-2008, Sections 12.X.15 and 24.16.2, relating to the </text> <text top="344" left="108" width="408" height="16" font="2">Do_Not_Hide property of the Network Security object. </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="119" height="16" font="1">Background: </text> <text top="407" left="108" width="5" height="16" font="2"> </text> <text top="428" left="108" width="454" height="16" font="1">12.X.15 Do_Not_Hide (page 79 of Addendum g to 135-2008) </text> <text top="449" left="108" width="673" height="16" font="2">This writable property, of type BOOLEAN, indicates whether or not the device is allowed to </text> <text top="470" left="108" width="669" height="16" font="2">ignore certain network security error conditions. When True, the device is required to return </text> <text top="491" left="108" width="395" height="16" font="2">errors in all of the conditions described in Clause 24.3 </text> <text top="512" left="108" width="5" height="16" font="2"> </text> <text top="533" left="108" width="636" height="16" font="1">24.16.2 Selecting Error Codes (page 47 of Addendum g to 135-2008) states "When an </text> <text top="554" left="108" width="686" height="16" font="2">ignorable error occurs, it is a local matter as to whether the device returns the error or does not </text> <text top="575" left="108" width="114" height="16" font="2">respond at all." </text> <text top="596" left="108" width="5" height="16" font="2"> </text> <text top="617" left="108" width="702" height="16" font="1">Interpretation: Section 24.16.2 is only true when the Do_Not_Hide property is FALSE. When </text> <text top="638" left="108" width="678" height="16" font="2">the Do_Not_Hide property is TRUE, a device must respond with all ignorable errors; it is not </text> <text top="659" left="108" width="370" height="16" font="2">allowed to decide not to respond as a local matter. </text> <text top="680" left="108" width="5" height="16" font="2"> </text> <text top="701" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="722" left="108" width="5" height="16" font="2"> </text> <text top="743" left="108" width="111" height="16" font="1">Answer: Yes. </text> <text top="764" left="108" width="5" height="16" font="2"> </text> <text top="785" left="108" width="5" height="16" font="2"> </text> </page> </pdf2xml> Interpretation 135-2008-10 - October 28, 2010 2010-10-28 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-10.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="16" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="13" family="Times" color="#0000ff"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="91" left="301" width="320" height="16" font="0">INTERPRETATION IC 135-2008-10 OF </text> <text top="112" left="264" width="395" height="16" font="0">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="0">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="0">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="1"> </text> <text top="196" left="338" width="246" height="16" font="1">Approval Date: October 28, 2010 </text> <text top="217" left="459" width="5" height="16" font="1"> </text> <text top="238" left="108" width="226" height="16" font="0">Request from: Dean Matsen (</text> <text top="240" left="334" width="181" height="14" font="2">dean.matsen@honeywell.com</text> <text top="238" left="514" width="196" height="16" font="1">), Alerton Dealer Business </text> <text top="259" left="108" width="654" height="16" font="1">Honeywell Automation & Control Solutions, 6670 185th Ave. NE, Redmond, WA 98052. </text> <text top="259" left="762" width="5" height="16" font="3"> </text> <text top="280" left="108" width="5" height="16" font="1"> </text> <text top="302" left="108" width="692" height="16" font="0">Reference: This request for interpretation refers to the requirements presented in Addendum g </text> <text top="323" left="108" width="674" height="16" font="1">to ANSI/ASHRAE Standard 135-2008, Section 24.16.1, relating to APDU and NPDU sizes. </text> <text top="344" left="108" width="5" height="16" font="1"> </text> <text top="365" left="108" width="678" height="16" font="0">Background: Section 24.16.1 (page 46 of Addendum g to 135-2008) lists some new APDU </text> <text top="386" left="108" width="661" height="16" font="1">sizes that leave extra room for the security header. However, for whatever reason, different </text> <text top="407" left="108" width="693" height="16" font="1">amounts of space for the security information appear to be assumed for each media without any </text> <text top="428" left="108" width="406" height="16" font="1">explanation of justification as to why they are different. </text> <text top="449" left="108" width="5" height="16" font="1"> </text> <text top="470" left="108" width="659" height="16" font="1">The BACnet/Ethernet max APDU size has been reduced from 1476 to 1420. This seems to </text> <text top="491" left="108" width="324" height="16" font="1">reserve 56 extra bytes for security overhead. </text> <text top="512" left="108" width="5" height="16" font="1"> </text> <text top="533" left="108" width="690" height="16" font="1">The MS/TP and PTP max APDU size has been reduced from 480 to 412. This seems to reserve </text> <text top="554" left="108" width="268" height="16" font="1">68 extra bytes for security overhead. </text> <text top="575" left="108" width="5" height="16" font="1"> </text> <text top="595" left="108" width="671" height="16" font="1">The BACnet/IP APDU size is left as-is, but the limit for the next lower layer has been raised </text> <text top="616" left="108" width="635" height="16" font="1">from 1497 (I think) to 1562. This seems to reserve 65 extra bytes for security overhead. </text> <text top="637" left="108" width="5" height="16" font="1"> </text> <text top="658" left="108" width="665" height="16" font="1">The LonTalk max APDU has been reduced from 206 to 140. This seems to reserve 66 extra </text> <text top="679" left="108" width="205" height="16" font="1">bytes for security overhead. </text> <text top="700" left="108" width="5" height="16" font="1"> </text> <text top="721" left="108" width="682" height="16" font="1">No rationale is given for the numbers 56, 65, 66, and 68, nor is any explanation given for why </text> <text top="742" left="108" width="280" height="16" font="1">they are different for each media type. </text> <text top="763" left="108" width="5" height="16" font="1"> </text> <text top="784" left="108" width="673" height="16" font="1">This does not give a clear guideline for what max NPDU sizes to assume in order to support </text> <text top="805" left="108" width="662" height="16" font="1">APDU sizes other than those shown in Table 24-28 (page 47 of Addendum g to 135-2008). </text> <text top="826" left="108" width="5" height="16" font="1"> </text> <text top="847" left="108" width="680" height="16" font="0">Interpretation No.1: Before security was proposed, the difference between max_APDU and </text> <text top="868" left="108" width="699" height="16" font="1">max_NPDU was always 21 bytes (1476 vs. 1497 and 480 vs. 501). So this implies that 21 bytes </text> <text top="889" left="108" width="242" height="16" font="1">should be reserved for the NPCI. </text> <text top="910" left="108" width="5" height="16" font="1"> </text> <text top="932" left="108" width="337" height="16" font="0">Question No.1: Is this interpretation correct? </text> <text top="953" left="108" width="5" height="16" font="1"> </text> <text top="974" left="108" width="157" height="16" font="0">Answer No.1: YES. </text> <text top="995" left="108" width="5" height="16" font="1"> </text> <text top="1016" left="108" width="661" height="16" font="0">Interpretation No.2: The security overhead differs for each media type for some unstated </text> <text top="1037" left="108" width="587" height="16" font="1">reason. For BACnet/Ethernet, it is 56 bytes. For PTP and MS/TP, it is 68 bytes. </text> <text top="1058" left="108" width="5" height="16" font="1"> </text> <text top="1079" left="108" width="337" height="16" font="0">Question No.2: Is this interpretation correct? </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="4" size="13" family="Times" color="#000000"/> <fontspec id="5" size="13" family="Times" color="#000000"/> <text top="58" left="108" width="101" height="14" font="4">IC 135-2008-10 </text> <text top="1120" left="108" width="699" height="14" font="5">Page 2 of 2 ©2010 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="5" height="16" font="1"> </text> <text top="112" left="108" width="262" height="16" font="0">Answer No.2: NO. See comments. </text> <text top="133" left="108" width="5" height="16" font="1"> </text> <text top="154" left="108" width="680" height="16" font="0">Interpretation No.3: When implementing BACnet/Ethernet with a maximum APDU limit of </text> <text top="175" left="108" width="576" height="16" font="1">max_APDU, assume max_NPDU = max_APDU + 21 + 56 = max_APDU + 77 </text> <text top="196" left="108" width="5" height="16" font="1"> </text> <text top="218" left="108" width="337" height="16" font="0">Question No.3: Is this interpretation correct? </text> <text top="239" left="108" width="5" height="16" font="1"> </text> <text top="260" left="108" width="262" height="16" font="0">Answer No.3: NO. See comments. </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="302" left="108" width="649" height="16" font="0">Interpretation No.4: When implementing MS/TP or PTP with maximum APDU limit of </text> <text top="323" left="108" width="621" height="16" font="1">max_APDU, assume max_NPDU = max_APDU + 21 + 68 = max_APDU + 89 </text> <text top="344" left="108" width="5" height="16" font="1"> </text> <text top="365" left="108" width="337" height="16" font="0">Question No.4: Is this interpretation correct? </text> <text top="386" left="108" width="5" height="16" font="1"> </text> <text top="407" left="108" width="262" height="16" font="0">Answer No.4: NO. See comments. </text> <text top="428" left="108" width="5" height="16" font="1"> </text> <text top="450" left="108" width="94" height="16" font="0">Comments: </text> <text top="471" left="108" width="5" height="16" font="0"> </text> <text top="492" left="108" width="693" height="16" font="1">The max APDU values in clause 24.16.1 are incorrectly calculated; they are based on an earlier </text> <text top="512" left="108" width="168" height="16" font="1">draft of the addendum. </text> <text top="533" left="108" width="5" height="16" font="1"> </text> <text top="554" left="108" width="697" height="16" font="1">The max APDU values vary by datalink due to the requirement that the encrypted portion of the </text> <text top="575" left="108" width="698" height="16" font="1">packet be a multiple of the encryption block size which in this case is 16 octets. To calculate the </text> <text top="596" left="108" width="565" height="16" font="1">max secure APDU for a given max APDU size the following formula is used: </text> <text top="617" left="108" width="5" height="16" font="1"> </text> <text top="638" left="135" width="4" height="16" font="1"> </text> <text top="638" left="162" width="411" height="16" font="1">max-secure-apdu = floor((max-apdu – s1) / bs) * bs – s2 </text> <text top="659" left="108" width="5" height="16" font="1"> </text> <text top="680" left="108" width="54" height="16" font="1">where: </text> <text top="701" left="108" width="5" height="16" font="1"> </text> <text top="722" left="135" width="522" height="16" font="1">max-apdu is the max-apdu size for a non-secured packet on the datalink </text> <text top="743" left="135" width="580" height="16" font="1">s1 is the number of octets of security information that is not encrypted and is 32 </text> <text top="764" left="135" width="553" height="16" font="1">s2 is the number of octets of security information that is encrypted and is 27 </text> <text top="785" left="135" width="670" height="16" font="1">bs is the size of the encryption algorithm's block size and is 16 for the encryption algorithms </text> <text top="806" left="162" width="283" height="16" font="1">used by the current security addendum </text> <text top="827" left="135" width="5" height="16" font="1"> </text> <text top="848" left="108" width="558" height="16" font="1">This results in the following max-secure-apdu sizes for the current datalinks: </text> <text top="869" left="108" width="5" height="16" font="1"> </text> <text top="890" left="135" width="147" height="16" font="1">LON: 131 </text> <text top="911" left="135" width="132" height="16" font="1">MS/TP: 419 </text> <text top="932" left="135" width="153" height="16" font="1">PTP: 419 </text> <text top="953" left="135" width="112" height="16" font="1">ARCNET: 419 </text> <text top="974" left="135" width="132" height="16" font="1">Ethernet: 1411 </text> <text top="995" left="135" width="140" height="16" font="1">ZigBee: 1411 </text> <text top="1016" left="135" width="5" height="16" font="1"> </text> <text top="1037" left="108" width="578" height="16" font="1">The B/IP max-secure-apdu is not subject to these constraints and remains 1476. </text> </page> </pdf2xml> Interpretation 135-2008-11 - October 28, 2010 2010-10-28 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-11.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="16" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#0000ff"/> <text top="91" left="304" width="315" height="16" font="0">INTERPRETATION IC135-2008-11 OF </text> <text top="112" left="203" width="517" height="16" font="0">ANSI/ASHRAE STANDARD ADDENDUM 135-2008p BACnet® - </text> <text top="133" left="284" width="355" height="16" font="0">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="0">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="1"> </text> <text top="196" left="338" width="246" height="16" font="1">Approval Date: October 28, 2010 </text> <text top="217" left="108" width="5" height="16" font="1"> </text> <text top="238" left="108" width="229" height="16" font="0">Request from: Klaus Wagner( </text> <text top="238" left="337" width="235" height="16" font="2">klaus.wagner@ch.sauter-bc.com</text> <text top="238" left="572" width="225" height="16" font="1"> ), Fr. Sauter AG, Switzerland, </text> <text top="259" left="108" width="121" height="16" font="1">Im Surinam 55. </text> <text top="280" left="108" width="5" height="16" font="1"> </text> <text top="302" left="108" width="706" height="16" font="0">Reference: This request for interpretation refers to the requirements presented in Addendum p to </text> <text top="323" left="108" width="491" height="16" font="1">ANSI/ASHRAE Standard 135-2008, Section 13.3.X, relating to the </text> <text top="344" left="108" width="338" height="16" font="1">CHANGE_OF_STATUS_FLAGS Algorithm. </text> <text top="365" left="108" width="5" height="16" font="1"> </text> <text top="386" left="108" width="653" height="16" font="0">Background: Section 13.3.X (page 10 of Addendum p to 135-2008) describes: "After the </text> <text top="407" left="108" width="705" height="16" font="1">algorithm is in the OFFNORMAL state, if the set of selected flags in the referenced property that </text> <text top="428" left="108" width="681" height="16" font="1">have a value of TRUE changes, then this algorithm shall generate another TO-OFFNORMAL </text> <text top="449" left="108" width="85" height="16" font="1">transition." </text> <text top="470" left="108" width="5" height="16" font="1"> </text> <text top="491" left="108" width="672" height="16" font="1">The section "if the set of selected flags in the referenced property that have a value of TRUE </text> <text top="512" left="108" width="324" height="16" font="1">changes" can be interpreted in several ways. </text> <text top="533" left="108" width="5" height="16" font="1"> </text> <text top="554" left="108" width="695" height="16" font="1">I assume that interpretation number 1 below is correct, that a new TO-OFFNORMAL transition </text> <text top="575" left="108" width="688" height="16" font="1">is triggered, if any True-to-False transition or False-to-True transition of any bit in the selected </text> <text top="595" left="108" width="695" height="16" font="1">set occurs and at least one flag of the set of selected flags in the referenced property has still the </text> <text top="616" left="108" width="695" height="16" font="1">value of TRUE. If the set of flags is changed a new TO-OFFNORMAL shall be issued if the set </text> <text top="637" left="108" width="695" height="16" font="1">of TRUE values changes, (a TRUE flag is added or a TRUE flag is omitted and at least one flag </text> <text top="658" left="108" width="376" height="16" font="1">in the referenced property has the value of TRUE). </text> <text top="679" left="108" width="5" height="16" font="1"> </text> <text top="701" left="108" width="681" height="16" font="0">Interpretation No.1: If at least one flag of the set of selected flags in the referenced property </text> <text top="722" left="108" width="664" height="16" font="1">will change whether to TRUE or to FALSE (and at least one referenced property within the </text> <text top="743" left="108" width="664" height="16" font="1">selected flags still has the value of TRUE) a new TO-OFFNORMAL event shall be issued. </text> <text top="764" left="108" width="5" height="16" font="1"> </text> <text top="785" left="108" width="332" height="16" font="0">Question No.1: Is this interpretation correct? </text> <text top="806" left="108" width="5" height="16" font="1"> </text> <text top="827" left="108" width="146" height="16" font="0">Answer No.1: Yes. </text> <text top="848" left="108" width="5" height="16" font="1"> </text> <text top="869" left="108" width="186" height="16" font="0">Comments No.1: None. </text> <text top="890" left="108" width="5" height="16" font="1"> </text> <text top="911" left="108" width="689" height="16" font="0">Interpretation No.2: If the "set" has the value of TRUE and the set itself changes (increase or </text> <text top="932" left="108" width="693" height="16" font="1">decrease of the set) a new TO-OFFNORMAL shall be issued regardless of the new value of the </text> <text top="953" left="108" width="155" height="16" font="1">set of selected flags. </text> <text top="974" left="108" width="5" height="16" font="1"> </text> <text top="996" left="108" width="332" height="16" font="0">Question No.2: Is this interpretation correct? </text> <text top="1016" left="108" width="5" height="16" font="1"> </text> <text top="1038" left="108" width="149" height="16" font="0">Answer No.2: No. </text> <text top="1059" left="108" width="5" height="16" font="1"> </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="3" size="13" family="Times" color="#000000"/> <fontspec id="4" size="13" family="Times" color="#000000"/> <text top="58" left="108" width="101" height="14" font="3">IC 135-2008-11 </text> <text top="1099" left="108" width="390" height="14" font="4">Page 2 of 2 </text> <text top="1099" left="540" width="238" height="14" font="4">©2010 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="108" width="677" height="16" font="0">Comments No.2: It is defined to be the set of "selected flags that are true". If you add a new </text> <text top="112" left="108" width="676" height="16" font="1">flag to the collection of selected flags, but it is not true, then the set of "selected flags that are </text> <text top="133" left="108" width="165" height="16" font="1">true" has not changed. </text> <text top="154" left="108" width="5" height="16" font="1"> </text> <text top="175" left="108" width="703" height="16" font="0">Interpretation No.3: If any True-to-False transition or False-to-True transition occurs of any bit </text> <text top="196" left="108" width="701" height="16" font="1">in the selected set, or the selected set is increased or decreased, because Selected_Flags changes, </text> <text top="217" left="108" width="648" height="16" font="1">would generate another transition to OFF-NORMAL. Even if there is a transition to OFF-</text> <text top="238" left="108" width="652" height="16" font="1">NORMAL when the last of the flags completes a True-to-False transition and all flags are </text> <text top="259" left="108" width="664" height="16" font="1">FALSE (though there are no TRUE flags left, at that moment the set of selected flags in the </text> <text top="280" left="108" width="416" height="16" font="1">referenced property that have a value of TRUE changes). </text> <text top="301" left="108" width="5" height="16" font="1"> </text> <text top="323" left="108" width="332" height="16" font="0">Question No.3: Is this interpretation correct? </text> <text top="343" left="108" width="5" height="16" font="1"> </text> <text top="365" left="108" width="694" height="16" font="0">Answer No.3: No. When the set of "selected flags that are true" is empty, then the transition to </text> <text top="386" left="108" width="404" height="16" font="1">normal occurs before the check for set changes occurs. </text> <text top="407" left="108" width="5" height="16" font="1"> </text> <text top="428" left="108" width="186" height="16" font="0">Comments No.3: None. </text> </page> </pdf2xml> Interpretation 135-2008-12 - October 28, 2010 2010-10-28 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-12.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="9" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 1 ©2010 ASHRAE. All Rights reserved. </text> <text top="91" left="301" width="320" height="16" font="1">INTERPRETATION IC 135-2008-12 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="338" width="246" height="16" font="2">Approval Date: October 28, 2010 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="277" height="16" font="1">Request from: William (Bill) Swan (</text> <text top="238" left="385" width="193" height="16" font="3">bill.swan@honeywell.com</text> <text top="238" left="578" width="227" height="16" font="2">), Alerton – Honeywell, 6670 - </text> <text top="259" left="108" width="27" height="16" font="2">185</text> <text top="255" left="135" width="9" height="11" font="4">th</text> <text top="259" left="144" width="244" height="16" font="2"> Ave NE, Redmond, WA 98052. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="701" height="16" font="2">ANSI/ASHRAE Standard 135-2008, Sections 12.1 and 12.1.11, relating to Accumulator object's </text> <text top="344" left="108" width="118" height="16" font="2">Scale property. </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="693" height="16" font="1">Background: A question was raised in the BACNET-L forum about the Accumulator object's </text> <text top="407" left="108" width="678" height="16" font="2">Scale property. This property is a CHOICE between REAL and INTEGER datatypes and the </text> <text top="428" left="108" width="653" height="16" font="2">question was whether both had to be supported when the underlying application uses only </text> <text top="449" left="108" width="702" height="16" font="2">integers. A response to this question noted that if the property were read-only it could be a fixed </text> <text top="470" left="108" width="658" height="16" font="2">datatype, though this could be a deficiency if there were a need to change the scale value. </text> <text top="491" left="108" width="5" height="16" font="2"> </text> <text top="512" left="108" width="702" height="16" font="2">It was surmised that the intent was for the choice to be determined by the application and not my </text> <text top="533" left="108" width="696" height="16" font="2">a client, as hinted in 12.1 (the Accumulator object), "Its purpose is to provide information about </text> <text top="554" left="108" width="677" height="16" font="2">the quantity being measured, such as electric power, water, or natural gas usage, according to </text> <text top="575" left="108" width="693" height="16" font="2">criteria specific to the application" and 12.1.11, (the Scale property), "The choice of options for </text> <text top="595" left="108" width="696" height="16" font="2">this property determine how the scaling operation (which is performed by the client reading this </text> <text top="616" left="108" width="162" height="16" font="2">object) is performed." </text> <text top="637" left="108" width="5" height="16" font="2"> </text> <text top="658" left="108" width="698" height="16" font="2">This runs somewhat counter to the general approach of SSPC 135 as regards services, where the </text> <text top="679" left="108" width="706" height="16" font="2">server supports all options and the client selects which option, but in terms of properties there are </text> <text top="700" left="108" width="703" height="16" font="2">other cases where ths server determines the datatype and the client has to adapt (think Schedule's </text> <text top="721" left="108" width="120" height="16" font="2">Present_Value). </text> <text top="742" left="108" width="5" height="16" font="2"> </text> <text top="763" left="108" width="677" height="16" font="2">Therefore it is proposed that the application selects the datatype of the Scale property and the </text> <text top="784" left="108" width="100" height="16" font="2">client adapts. </text> <text top="805" left="108" width="5" height="16" font="2"> </text> <text top="826" left="108" width="702" height="16" font="1">Interpretation: The application represented by the Accumulator object determines the datatype </text> <text top="847" left="108" width="512" height="16" font="2">of the Scale object, and the client has to accept the datatype presented. </text> <text top="868" left="108" width="9" height="16" font="2"> </text> <text top="890" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="911" left="108" width="5" height="16" font="2"> </text> <text top="932" left="108" width="698" height="16" font="1">Answer: No. The standard, as currently written, is not clear about this topic. Based on that, an </text> <text top="953" left="108" width="704" height="16" font="2">application is free to take the approach described here, but another application is also free to take </text> <text top="974" left="108" width="214" height="16" font="2">the less restrictive approach. </text> </page> </pdf2xml> Interpretation 135-2008-13 - January 29, 2011 2011-01-29 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-13.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="108" width="699" height="14" font="0">Page 1 of 2 ©2011 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2008-13 OF </text> <text top="112" left="264" width="395" height="16" font="2">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="1"> </text> <text top="196" left="339" width="244" height="16" font="1">Approval Date: January 29, 2011 </text> <text top="217" left="108" width="5" height="16" font="1"> </text> <text top="238" left="108" width="222" height="16" font="2">Request from: Carl Neilson (</text> <text top="238" left="330" width="205" height="16" font="3">cneilson@deltacontrols.com</text> <text top="238" left="535" width="255" height="16" font="1">), Delta Controls, 61 Seagirt Road, </text> <text top="259" left="108" width="200" height="16" font="1">East Sooke, BC V9Z 1A3. </text> <text top="280" left="108" width="5" height="16" font="1"> </text> <text top="302" left="108" width="594" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="639" height="16" font="1">ANSI/ASHRAE Standard 135-2008, Clauses 6.4.7 and 6.4.8 (pages 55 and 56), relating </text> <text top="344" left="108" width="431" height="16" font="1">Initialize-Routing-Table and Initialize-Routing-Table-Ack. </text> <text top="365" left="108" width="5" height="16" font="1"> </text> <text top="386" left="108" width="697" height="16" font="2">Background: In Clause 6.4.7, the Initialize-Routing-Table service is described and it provides </text> <text top="407" left="108" width="685" height="16" font="1">two purposes. The service can be used to 'initialize' a device's routing table or it can be used to </text> <text top="428" left="108" width="336" height="16" font="1">query the contents of a device's routing table. </text> <text top="449" left="108" width="5" height="16" font="1"> </text> <text top="470" left="108" width="705" height="16" font="1">The third paragraph of Clause 6.4.7 describes the semantic of the content of the request message: </text> <text top="491" left="108" width="5" height="16" font="1"> </text> <text top="512" left="108" width="679" height="16" font="1">"... Following this field are sets of data indicating the DNET directly connected to this port or </text> <text top="533" left="108" width="706" height="16" font="1">accessible through a dial-up PTP connection, Port ID, Port Info Length, and, in the case Port Info </text> <text top="554" left="108" width="698" height="16" font="1">Length is non-zero, Port Info. If an Initialize-Routing-Table message is sent with the Number of </text> <text top="575" left="108" width="691" height="16" font="1">Ports equal to zero, the responding device shall return its complete routing table in an Initialize-</text> <text top="595" left="108" width="490" height="16" font="1">Routing-Table-Ack message without updating its routing table. …" </text> <text top="616" left="108" width="5" height="16" font="1"> </text> <text top="637" left="108" width="643" height="16" font="1">The language is clear that only directly connected DNETs (and PTP dial-up DNETs) are </text> <text top="658" left="108" width="670" height="16" font="1">described in the request. But in the response, it is not clear what a device's 'complete routing </text> <text top="679" left="108" width="689" height="16" font="1">table' contains. Are only directly connected networks included (as described by the data format </text> <text top="700" left="108" width="682" height="16" font="1">description), or are all networks reachable through the router included (as possibly implied by </text> <text top="721" left="108" width="252" height="16" font="1">the term 'complete routing table'). </text> <text top="742" left="108" width="5" height="16" font="1"> </text> <text top="763" left="108" width="673" height="16" font="1">There is no language dealing with this question within Clause 6.4.8; it only indicates that the </text> <text top="784" left="108" width="570" height="16" font="1">format is the same as the data portion of the Initialize-Routing-Table message: </text> <text top="805" left="108" width="5" height="16" font="1"> </text> <text top="826" left="108" width="706" height="16" font="1">"The data portion of this message, returned only in response to a routing table query, conveys the </text> <text top="847" left="108" width="697" height="16" font="1">routing table information, and it has the same format as the data portion of an Initialize-Routing-</text> <text top="868" left="108" width="318" height="16" font="1">Table message. See 6.4.7 and Figure 6-11." </text> <text top="889" left="108" width="5" height="16" font="1"> </text> <text top="910" left="108" width="686" height="16" font="1">In considering this problem, it is also worth noting that having the response indicate all known </text> <text top="931" left="108" width="674" height="16" font="1">networks may result in the service not working in large BACnet installations because routers </text> <text top="952" left="108" width="701" height="16" font="1">would be unable to provide all directly connected DNETs plus all learned distant DNETs. It also </text> <text top="973" left="108" width="672" height="16" font="1">makes the determination of which networks are directly connected to a router difficult, if not </text> <text top="994" left="108" width="679" height="16" font="1">impossible (e.g. when a router cannot cache all networks in the system and thus reports fewer </text> <text top="1015" left="108" width="669" height="16" font="1">than all networks, or when the response is too large thus resulting in no response or a partial </text> <text top="1036" left="108" width="78" height="16" font="1">response). </text> <text top="1057" left="108" width="5" height="16" font="1"> </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="4" size="13" family="Times" color="#000000"/> <text top="58" left="108" width="101" height="14" font="4">IC 135-2008-13 </text> <text top="1120" left="108" width="699" height="14" font="0">Page 2 of 2 ©2011 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="702" height="16" font="2">Interpretation: Given that Clause 6.4.7 indicates that the 'Number of Ports' field is followed by </text> <text top="112" left="108" width="669" height="16" font="1">a list of directly connected DNETs, that Clause 6.4.8 states that the response is to follow the </text> <text top="133" left="108" width="706" height="16" font="1">same format as the request, and that the service fails to fulfill basic needs if all ports are reported, </text> <text top="154" left="108" width="670" height="16" font="1">the term 'complete routing table' shall mean all directly connected DNETs (plus PTP dial-up </text> <text top="175" left="108" width="70" height="16" font="1">DNETs). </text> <text top="196" left="108" width="9" height="16" font="1"> </text> <text top="217" left="108" width="297" height="16" font="2">Question: Is this interpretation correct? </text> <text top="238" left="108" width="5" height="16" font="1"> </text> <text top="260" left="108" width="111" height="16" font="2">Answer: Yes. </text> <text top="281" left="108" width="5" height="16" font="1"> </text> </page> </pdf2xml> Interpretation 135-2008-14 - January 29, 2011 2011-01-29 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-14.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1120" left="108" width="813" height="14" font="0">Page 1 of 1 ©2011 ASHRAE. All Rights reserved. </text> <text top="91" left="301" width="320" height="16" font="1">INTERPRETATION IC 135-2008-14 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="339" width="244" height="16" font="2">Approval Date: January 29, 2011 </text> <text top="217" left="459" width="5" height="16" font="2"> </text> <text top="238" left="459" width="5" height="16" font="2"> </text> <text top="259" left="108" width="226" height="16" font="1">Request from: Dean Matsen (</text> <text top="259" left="334" width="217" height="16" font="3">dean.matsen@honeywell.com</text> <text top="259" left="550" width="196" height="16" font="2">), Alerton Dealer Business </text> <text top="280" left="108" width="659" height="16" font="2">Honeywell Automation & Control Solutions, 6670 185th Ave. NE, Redmond, WA 98052. </text> <text top="301" left="108" width="5" height="16" font="2"> </text> <text top="323" left="108" width="692" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in Addendum g </text> <text top="344" left="108" width="706" height="16" font="2">to ANSI/ASHRAE Standard 135-2008, Clause 24.2.11 (page 13), relating to Authentication Data </text> <text top="365" left="108" width="125" height="16" font="2">length encoding. </text> <text top="386" left="108" width="5" height="16" font="2"> </text> <text top="407" left="108" width="700" height="16" font="1">Background: Clause 24.2.11 states "If the Authentication Mechanism has a value of 1 through </text> <text top="428" left="108" width="692" height="16" font="2">199, then the next 2 octets of this field shall be an unsigned integer (most significant octet first) </text> <text top="449" left="108" width="368" height="16" font="2">indicating the length, in octets, of the entire field." </text> <text top="470" left="108" width="5" height="16" font="2"> </text> <text top="491" left="108" width="427" height="16" font="2">The precise meaning of "the entire field" is a little unclear. </text> <text top="512" left="108" width="5" height="16" font="2"> </text> <text top="533" left="108" width="702" height="16" font="1">Interpretation: The length of the entire field includes everything from the first byte of the User </text> <text top="554" left="108" width="364" height="16" font="2">Id through the last byte of the authentication data. </text> <text top="575" left="108" width="5" height="16" font="2"> </text> <text top="596" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="617" left="108" width="5" height="16" font="2"> </text> <text top="638" left="108" width="115" height="16" font="1">Answer: Yes. </text> <text top="659" left="108" width="5" height="16" font="2"> </text> </page> </pdf2xml> Interpretation 135-2008-15 - January 29, 2011 2011-01-29 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-15.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1099" left="108" width="699" height="14" font="0">Page 1 of 2 ©2011 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2008-15 OF </text> <text top="112" left="264" width="395" height="16" font="2">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="1"> </text> <text top="196" left="339" width="244" height="16" font="1">Approval Date: January 29, 2011 </text> <text top="217" left="459" width="5" height="16" font="1"> </text> <text top="238" left="459" width="5" height="16" font="1"> </text> <text top="259" left="108" width="226" height="16" font="2">Request from: Dean Matsen (</text> <text top="259" left="334" width="217" height="16" font="3">dean.matsen@honeywell.com</text> <text top="259" left="550" width="196" height="16" font="1">), Alerton Dealer Business </text> <text top="280" left="108" width="659" height="16" font="1">Honeywell Automation & Control Solutions, 6670 185th Ave. NE, Redmond, WA 98052. </text> <text top="301" left="108" width="5" height="16" font="1"> </text> <text top="323" left="108" width="692" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in Addendum g </text> <text top="344" left="108" width="708" height="16" font="1">to ANSI/ASHRAE Standard 135-2008, Clauses 24.2.3 and 24.12.1 (pages 11 and 40), relating to </text> <text top="365" left="108" width="671" height="16" font="1">Selecting General-Network-Access key for encryption when another key is used for signing. </text> <text top="386" left="108" width="5" height="16" font="1"> </text> <text top="407" left="108" width="668" height="16" font="2">Background: Clause 24.2.3 states "If the do-not-decrypt flag has a value of 0, the General-</text> <text top="428" left="108" width="694" height="16" font="1">Network-Access key is used to decrypt the message as it is the only key that is guaranteed to be </text> <text top="449" left="108" width="389" height="16" font="1">known by intermediate routers (see Clause 24.21.1)." </text> <text top="470" left="108" width="5" height="16" font="1"> </text> <text top="491" left="108" width="692" height="16" font="1">Clause 24.12.1 states "A signed message shall be encrypted using the General-Network-Access </text> <text top="512" left="108" width="696" height="16" font="1">key if the security policy of the outgoing port is 'encrypted'. The do-not-decrypt flag shall be set </text> <text top="533" left="108" width="44" height="16" font="1">to 0." </text> <text top="554" left="108" width="5" height="16" font="1"> </text> <text top="575" left="108" width="676" height="16" font="1">Both of these paragraphs allude to the possibility that the key identifier in the security header </text> <text top="595" left="108" width="706" height="16" font="1">may only indicate the key used to sign the message, not the one used to encrypt/decrypt it (and in </text> <text top="616" left="108" width="633" height="16" font="1">cases where the keys are different, it is the General-Network-Access key that is used to </text> <text top="637" left="108" width="128" height="16" font="1">encrypt/decrypt). </text> <text top="658" left="108" width="5" height="16" font="1"> </text> <text top="679" left="108" width="698" height="16" font="1">Both of these paragraphs also use the term "the General-Network-Access key" as if there is only </text> <text top="700" left="108" width="658" height="16" font="1">one. In fact, there can be two General-Network-Access keys active at one time during the </text> <text top="721" left="108" width="693" height="16" font="1">overlapping period between two key sets. There is no guideline given for how to choose which </text> <text top="742" left="108" width="244" height="16" font="1">GNA key to use during this time. </text> <text top="763" left="108" width="5" height="16" font="1"> </text> <text top="784" left="108" width="703" height="16" font="1">Failure to specify this is very likely to lead to interoperability failures where one device uses one </text> <text top="805" left="108" width="696" height="16" font="1">algorithm to choose the GNA key for encryption, and another devices uses a different algorithm </text> <text top="826" left="108" width="641" height="16" font="1">to choose the GNA key for decryption. The algorithm for choosing the GNA key in this </text> <text top="847" left="108" width="554" height="16" font="1">situation needs to be the same for both the sending and the receiving device. </text> <text top="868" left="108" width="5" height="16" font="1"> </text> <text top="889" left="108" width="696" height="16" font="1">Furthermore, there is no information given on what error should be returned if a device receives </text> <text top="910" left="108" width="675" height="16" font="1">a message that needs to be decrypted with the GNA, but the device does not have a matching </text> <text top="931" left="108" width="675" height="16" font="1">GNA key with which to decrypt it. On the surface, it seems that returning "unknownKey" or </text> <text top="952" left="108" width="664" height="16" font="1">"unknownKeyRevision" might be appropriate, but there are three problems with doing this: </text> <text top="973" left="108" width="5" height="16" font="1"> </text> <text top="994" left="108" width="703" height="16" font="1">1. "unknownKey" requires specifying the key identifier of the key that was unknown. Normally, </text> <text top="1015" left="108" width="684" height="16" font="1">this is no problem because this information is given in the security header, but in this case, the </text> <text top="1036" left="108" width="628" height="16" font="1">security header could be specifying some other key/algorithm/revision. Therefore, the </text> <text top="1057" left="108" width="694" height="16" font="1">responding device could fill in the key number "General-Network-Access", but it does not have </text> <text top="1078" left="108" width="233" height="16" font="1">any way to fill in the algorithm. </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="4" size="13" family="Times" color="#000000"/> <text top="58" left="108" width="101" height="14" font="4">IC 135-2008-15 </text> <text top="1120" left="108" width="699" height="14" font="0">Page 2 of 2 ©2011 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="5" height="16" font="1"> </text> <text top="112" left="108" width="682" height="16" font="1">2. "unknownKeyRevision" requires specifying the revision that was unknown. This poses the </text> <text top="133" left="108" width="232" height="16" font="1">same problem as item 1, above. </text> <text top="154" left="108" width="5" height="16" font="1"> </text> <text top="175" left="108" width="673" height="16" font="1">3. Above all, since the incoming message was received encrypted with the GNA key, such a </text> <text top="196" left="108" width="666" height="16" font="1">security response would also have to be encrypted using the GNA key, and since there is an </text> <text top="217" left="108" width="697" height="16" font="1">apparent mismatch in GNA keys between the two devices, the other device would not be able to </text> <text top="238" left="108" width="218" height="16" font="1">decrypt the response anyway. </text> <text top="259" left="108" width="5" height="16" font="1"> </text> <text top="280" left="108" width="702" height="16" font="2">Interpretation No.1: If the security header indicates the General-Network-Access key, then the </text> <text top="301" left="108" width="706" height="16" font="1">device should use the algorithm and version of GNA key specified in the header for both signing </text> <text top="322" left="108" width="627" height="16" font="1">and for encryption -- there is no need to use a separate algorithm to find the GNA key. </text> <text top="343" left="108" width="5" height="16" font="1"> </text> <text top="364" left="108" width="337" height="16" font="2">Question No.1: Is this interpretation correct? </text> <text top="385" left="108" width="5" height="16" font="1"> </text> <text top="406" left="108" width="151" height="16" font="2">Answer No.1: Yes. </text> <text top="427" left="108" width="5" height="16" font="1"> </text> <text top="449" left="108" width="703" height="16" font="2">Interpretation No.2: If the security header indicates a key other than General-Network-Access, </text> <text top="470" left="108" width="674" height="16" font="1">and the message needs to be encrypted/decrypted, then the device should use the most recent </text> <text top="491" left="108" width="656" height="16" font="1">General-Network-Access key that is within its active period based on the timestamp in the </text> <text top="512" left="108" width="285" height="16" font="1">message (NOT the current timestamp). </text> <text top="533" left="108" width="5" height="16" font="2"> </text> <text top="554" left="108" width="337" height="16" font="2">Question No.2: Is this interpretation correct? </text> <text top="575" left="108" width="5" height="16" font="1"> </text> <text top="596" left="108" width="674" height="16" font="2">Answer No.2: No (the standard is clear that the security header indicates the key revision to </text> <text top="617" left="108" width="39" height="16" font="1">use). </text> <text top="638" left="108" width="5" height="16" font="2"> </text> <text top="659" left="108" width="703" height="16" font="2">Interpretation No.3: If a receiving device cannot find a usable General-Network-Access key to </text> <text top="680" left="108" width="502" height="16" font="1">attempt to decrypt the message, then the message should be dropped. </text> <text top="701" left="108" width="5" height="16" font="2"> </text> <text top="723" left="108" width="337" height="16" font="2">Question No.3: Is this interpretation correct? </text> <text top="744" left="108" width="5" height="16" font="1"> </text> <text top="765" left="108" width="636" height="16" font="2">Answer No.3: No (the unknownKeyRevision error handling is applicable to this case). </text> <text top="786" left="108" width="5" height="16" font="2"> </text> <text top="807" left="108" width="191" height="16" font="2">Comments: See answers. </text> <text top="828" left="108" width="5" height="16" font="2"> </text> </page> </pdf2xml> Interpretation 135-2008-16 - January 29, 2011 2011-01-29 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-16.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1103" left="108" width="648" height="14" font="0">Page 1 of 1 ©2011 ASHRAE. All Rights </text> <text top="1120" left="108" width="357" height="14" font="0">reserved. </text> <text top="91" left="301" width="320" height="16" font="1">INTERPRETATION IC 135-2008-16 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="339" width="244" height="16" font="2">Approval Date: January 29, 2011 </text> <text top="217" left="459" width="5" height="16" font="2"> </text> <text top="238" left="459" width="5" height="16" font="2"> </text> <text top="259" left="108" width="226" height="16" font="1">Request from: Dean Matsen (</text> <text top="259" left="334" width="217" height="16" font="3">dean.matsen@honeywell.com</text> <text top="259" left="550" width="196" height="16" font="2">), Alerton Dealer Business </text> <text top="280" left="108" width="659" height="16" font="2">Honeywell Automation & Control Solutions, 6670 185th Ave. NE, Redmond, WA 98052. </text> <text top="301" left="108" width="5" height="16" font="2"> </text> <text top="323" left="108" width="692" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in Addendum g </text> <text top="344" left="108" width="700" height="16" font="2">to ANSI/ASHRAE Standard 135-2008, Clause 24.16.2 and Tables 24-8, 24-18, 24-22 and 24-24 </text> <text top="365" left="108" width="640" height="16" font="2">(pages 47, 19, 22-23, 26-27, 28-29), relating to order of error checking in key messages. </text> <text top="386" left="108" width="5" height="16" font="2"> </text> <text top="407" left="108" width="675" height="16" font="1">Background: Clause 24.16.2 says that general security layer errors are to be checked in the </text> <text top="428" left="108" width="622" height="16" font="2">table-specified order, and that they are to be checked before any authorization errors. </text> <text top="449" left="108" width="5" height="16" font="2"> </text> <text top="470" left="108" width="590" height="16" font="2">According to Table 24-8, destinationDeviceIdRequired, encryptionRequired, and </text> <text top="491" left="108" width="355" height="16" font="2">sourceSecurityRequired are authorization errors. </text> <text top="512" left="108" width="5" height="16" font="2"> </text> <text top="533" left="108" width="637" height="16" font="2">In the Request-Key-Update error table (Table 24-18), destinationDeviceIdRequired and </text> <text top="554" left="108" width="638" height="16" font="2">encryptionRequired appear between the two general security errors badTimeStamp and </text> <text top="575" left="108" width="109" height="16" font="2">notKeyServer. </text> <text top="595" left="108" width="5" height="16" font="2"> </text> <text top="616" left="108" width="682" height="16" font="2">In the Update-Key-Set error table (Table 24-22), all three authorization errors appear between </text> <text top="637" left="108" width="537" height="16" font="2">the two general security errors badTimeStamp and keyUpdateInProgress. </text> <text top="658" left="108" width="5" height="16" font="2"> </text> <text top="679" left="108" width="682" height="16" font="2">In the Update-Distribution-Key error table (Table 24-24), all three authorization errors appear </text> <text top="700" left="108" width="553" height="16" font="2">between the two general security errors badTimeStamp and cannotUseKey. </text> <text top="721" left="108" width="5" height="16" font="2"> </text> <text top="743" left="108" width="561" height="16" font="1">Interpretation: The destinationDeviceIdRequired, encryptionRequired, and </text> <text top="764" left="108" width="686" height="16" font="2">sourceSecurityRequired are to be considered general security errors when processing Request-</text> <text top="784" left="108" width="704" height="16" font="2">Key-Update, Update-Key-Set, and Update-Distribution-Key requests. These errors may NOT be </text> <text top="805" left="108" width="364" height="16" font="2">checked after all the other general network errors. </text> <text top="826" left="108" width="5" height="16" font="2"> </text> <text top="848" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="869" left="108" width="5" height="16" font="2"> </text> <text top="890" left="108" width="111" height="16" font="1">Answer: Yes. </text> </page> </pdf2xml> Interpretation 135-2008-17 - January 29, 2011 2011-01-29 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-17.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1082" left="108" width="648" height="14" font="0">Page 1 of 2 ©2011 ASHRAE. All Rights </text> <text top="1099" left="108" width="59" height="14" font="0">reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2008-17 OF </text> <text top="112" left="264" width="395" height="16" font="2">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="1"> </text> <text top="196" left="339" width="244" height="16" font="1">Approval Date: January 29, 2011 </text> <text top="217" left="459" width="5" height="16" font="1"> </text> <text top="238" left="459" width="5" height="16" font="1"> </text> <text top="259" left="108" width="226" height="16" font="2">Request from: Dean Matsen (</text> <text top="259" left="334" width="217" height="16" font="3">dean.matsen@honeywell.com</text> <text top="259" left="550" width="196" height="16" font="1">), Alerton Dealer Business </text> <text top="280" left="108" width="659" height="16" font="1">Honeywell Automation & Control Solutions, 6670 185th Ave. NE, Redmond, WA 98052. </text> <text top="301" left="108" width="5" height="16" font="1"> </text> <text top="323" left="108" width="692" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in Addendum g </text> <text top="344" left="108" width="668" height="16" font="1">to ANSI/ASHRAE Standard 135-2008, Clauses 24.15.2.1 (page 45), relating to methods for </text> <text top="365" left="108" width="130" height="16" font="1">discovering time. </text> <text top="386" left="108" width="5" height="16" font="1"> </text> <text top="407" left="108" width="675" height="16" font="2">Background: Clause 24.15.2.1 describes the preferred method of acquiring the time, which </text> <text top="428" left="108" width="672" height="16" font="1">involves challenging an unspecified device (presumably any peer device?). This "preferred" </text> <text top="449" left="108" width="583" height="16" font="1">procedure is not described in any detail other than to say it involves a challenge. </text> <text top="470" left="108" width="5" height="16" font="1"> </text> <text top="491" left="108" width="686" height="16" font="1">Clauses 24.15.2.1.1-3 describe three methods in more detail, but these sections are following a </text> <text top="512" left="108" width="704" height="16" font="1">clause that implies that cryptographic-quality pseudorandom number generation is required to do </text> <text top="533" left="108" width="640" height="16" font="1">any of them (this is the last paragraph of 24.15.2.1, which starts with "other methods for </text> <text top="554" left="108" width="304" height="16" font="1">determining time are described below...") </text> <text top="575" left="108" width="5" height="16" font="1"> </text> <text top="595" left="108" width="672" height="16" font="1">The only attack described in 24.15.2.1 is a replay attack. To avoid a reply in this situation, a </text> <text top="616" left="108" width="694" height="16" font="1">device must use a challenge it has never used before. While a crypto-PRNG would do this, it is </text> <text top="637" left="108" width="640" height="16" font="1">not the only way to do it. The persistent "next special message ID" scheme described in </text> <text top="658" left="108" width="697" height="16" font="1">24.15.2.1 would work just as well (in fact, maybe BETTER because the PRNG is more likely to </text> <text top="679" left="108" width="700" height="16" font="1">suffer from a birthday collision, since the PRNG output gets expressed in the relatively small 32-</text> <text top="700" left="108" width="688" height="16" font="1">bit time stamp and/or message ID). In any case, ultimately there is no justification for why the </text> <text top="721" left="108" width="490" height="16" font="1">algorithms of 24.15.2.1.1-3 require crypto-PRNG to operate safely. </text> <text top="742" left="108" width="5" height="16" font="1"> </text> <text top="763" left="108" width="652" height="16" font="1">Based on this, one could argue that any of the mechanisms in Clauses 24.15.2.1.1 through </text> <text top="784" left="108" width="702" height="16" font="1">24.15.2.1.3 can be used safely with either kind of challenge ID/timestamp generator described in </text> <text top="805" left="108" width="77" height="16" font="1">24.15.2.1. </text> <text top="826" left="108" width="5" height="16" font="1"> </text> <text top="847" left="108" width="679" height="16" font="1">It would be reasonable to guess that an editorial error makes it sound like Clauses 24.15.2.1.1 </text> <text top="868" left="108" width="702" height="16" font="1">through 24.15.2.1.3 require the crypto-PRNG described at the end of 24.15.2.1, even though that </text> <text top="889" left="108" width="121" height="16" font="1">wasn't intended. </text> <text top="910" left="108" width="5" height="16" font="1"> </text> <text top="931" left="108" width="706" height="16" font="2">Interpretation No.1: The "preferred" vs. "other" has to do with whether a device is able to store </text> <text top="952" left="108" width="659" height="16" font="1">the "next special Message ID" between power cycles. If it can't, then it has to use a crypto-</text> <text top="973" left="108" width="700" height="16" font="1">PRNG with entropy, etc... in order to ensure that it doesn't do the same thing on every power up. </text> <text top="994" left="108" width="5" height="16" font="1"> </text> <text top="1015" left="108" width="337" height="16" font="2">Question No.1: Is this interpretation correct? </text> <text top="1036" left="108" width="5" height="16" font="1"> </text> <text top="1058" left="108" width="151" height="16" font="2">Answer No.1: Yes. </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="4" size="13" family="Times" color="#000000"/> <text top="58" left="108" width="101" height="14" font="4">IC 135-2008-17 </text> <text top="1103" left="108" width="648" height="14" font="0">Page 2 of 2 ©2011 ASHRAE. All Rights </text> <text top="1120" left="108" width="59" height="14" font="0">reserved. </text> <text top="91" left="108" width="5" height="16" font="1"> </text> <text top="112" left="108" width="686" height="16" font="2">Interpretation No.2: Clauses 24.15.2.1.1 through 24.15.2.1.3 describe algorithms that can be </text> <text top="133" left="108" width="638" height="16" font="1">used with the "preferred" as well as the "other" method of producing unique challenges. </text> <text top="154" left="108" width="5" height="16" font="1"> </text> <text top="175" left="108" width="337" height="16" font="2">Question No.2: Is this interpretation correct? </text> <text top="196" left="108" width="5" height="16" font="1"> </text> <text top="218" left="108" width="151" height="16" font="2">Answer No.2: Yes. </text> </page> </pdf2xml> Interpretation 135-2008-18 - January 29, 2011 2011-01-29 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-18.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1103" left="108" width="648" height="14" font="0">Page 1 of 2 ©2011 ASHRAE. All Rights </text> <text top="1120" left="108" width="59" height="14" font="0">reserved. </text> <text top="91" left="301" width="320" height="16" font="1">INTERPRETATION IC 135-2008-18 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="339" width="244" height="16" font="2">Approval Date: January 29, 2011 </text> <text top="217" left="459" width="5" height="16" font="2"> </text> <text top="238" left="459" width="5" height="16" font="2"> </text> <text top="259" left="108" width="226" height="16" font="1">Request from: Dean Matsen (</text> <text top="259" left="334" width="217" height="16" font="3">dean.matsen@honeywell.com</text> <text top="259" left="550" width="196" height="16" font="2">), Alerton Dealer Business </text> <text top="280" left="108" width="659" height="16" font="2">Honeywell Automation & Control Solutions, 6670 185th Ave. NE, Redmond, WA 98052. </text> <text top="301" left="108" width="5" height="16" font="2"> </text> <text top="323" left="108" width="692" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in Addendum g </text> <text top="344" left="108" width="681" height="16" font="2">to ANSI/ASHRAE Standard 135-2008, Clauses 24.2.8, 24.2.9, 24.3.7, 24.12.1, S.1 (pages 12, </text> <text top="365" left="108" width="536" height="16" font="2">29, 39, 98), relating to Security Applied to Request-Master-Key message. </text> <text top="386" left="108" width="5" height="16" font="2"> </text> <text top="407" left="108" width="670" height="16" font="1">Background: Consider an undeployed secure BACnet device having no keys and having a </text> <text top="428" left="108" width="408" height="16" font="2">non-battery-backed RTC, and which is deployed on an </text> <text top="449" left="108" width="692" height="16" font="2">encrypted network. Such a device starts out its life with no means to discover its time stamp or </text> <text top="470" left="108" width="127" height="16" font="2">network number. </text> <text top="491" left="108" width="5" height="16" font="2"> </text> <text top="512" left="108" width="706" height="16" font="2">When such a device emits its Request-Master-Key request, the request would need to have a zero </text> <text top="533" left="108" width="88" height="16" font="2">time stamp. </text> <text top="554" left="108" width="5" height="16" font="2"> </text> <text top="575" left="108" width="668" height="16" font="2">Clause 24.3.7 makes a provision for routers to allow routing this message even if it does not </text> <text top="595" left="108" width="223" height="16" font="2">meet the local network policy. </text> <text top="616" left="108" width="5" height="16" font="2"> </text> <text top="637" left="108" width="515" height="16" font="2">Clauses 24.2.8 and 24.2.9 talk about allowing for the SNET to be zero. </text> <text top="658" left="108" width="5" height="16" font="2"> </text> <text top="679" left="108" width="672" height="16" font="2">Clause 24.12.1 allows a router to validate the source MAC, time stamp, and message ID of a </text> <text top="700" left="108" width="237" height="16" font="2">message that is passing through. </text> <text top="721" left="108" width="5" height="16" font="2"> </text> <text top="742" left="108" width="680" height="16" font="2">Annex S, Clause S.1 seems to imply that a bad time stamp is a possibility here, but that's only </text> <text top="763" left="108" width="93" height="16" font="2">informative. </text> <text top="784" left="108" width="5" height="16" font="2"> </text> <text top="805" left="108" width="703" height="16" font="2">The problem here is that some router vendor might decide to apply time stamp check (or perhaps </text> <text top="826" left="108" width="700" height="16" font="2">other checks that are destined to fail) to the Request-Master-Key message, without realizing that </text> <text top="847" left="108" width="696" height="16" font="2">is defeats the entire mechanism. This is apparently allowed by 24.12.1 (maybe even encouraged </text> <text top="868" left="108" width="271" height="16" font="2">for the overachieving router vendor). </text> <text top="889" left="108" width="5" height="16" font="2"> </text> <text top="910" left="108" width="654" height="16" font="2">However, vendors of non-routing devices depend on the routers to support the mechanism </text> <text top="931" left="108" width="391" height="16" font="2">correctly and consistently, as defined by the standard. </text> <text top="952" left="108" width="5" height="16" font="2"> </text> <text top="973" left="108" width="706" height="16" font="1">Interpretation No.1: A router should not apply any security checks to Request-Master-Key, but </text> <text top="994" left="108" width="692" height="16" font="2">should rather just route it according to Clause 6. The easiest error to make here would be to try </text> <text top="1015" left="108" width="309" height="16" font="2">to validate the time stamp or SNET fields. </text> <text top="1036" left="108" width="5" height="16" font="2"> </text> <text top="1057" left="108" width="337" height="16" font="1">Question No.1: Is this interpretation correct? </text> <text top="1078" left="108" width="5" height="16" font="2"> </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="4" size="13" family="Times" color="#000000"/> <text top="58" left="108" width="101" height="14" font="4">IC 135-2008-18 </text> <text top="1103" left="108" width="648" height="14" font="0">Page 2 of 2 ©2011 ASHRAE. All Rights </text> <text top="1120" left="108" width="59" height="14" font="0">reserved. </text> <text top="91" left="108" width="151" height="16" font="1">Answer No.1: Yes. </text> <text top="112" left="108" width="5" height="16" font="2"> </text> <text top="134" left="108" width="687" height="16" font="1">Interpretation No.2: The only security a router applies to Request-Master-Key is to refuse to </text> <text top="154" left="108" width="691" height="16" font="2">route it altogether, and only then if explicitly configured to do so (which must not be its default </text> <text top="175" left="108" width="112" height="16" font="2">configuration). </text> <text top="196" left="108" width="5" height="16" font="2"> </text> <text top="218" left="108" width="337" height="16" font="1">Question No.2: Is this interpretation correct? </text> <text top="239" left="108" width="5" height="16" font="2"> </text> <text top="260" left="108" width="151" height="16" font="1">Answer No.2: Yes. </text> <text top="281" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="689" height="16" font="1">Interpretation No.3: A key server needs to accept a Request-Master-Key message with a bad </text> <text top="323" left="108" width="156" height="16" font="2">(or zero) time stamp. </text> <text top="344" left="108" width="5" height="16" font="2"> </text> <text top="365" left="108" width="337" height="16" font="1">Question No.3: Is this interpretation correct? </text> <text top="386" left="108" width="5" height="16" font="2"> </text> <text top="407" left="108" width="151" height="16" font="1">Answer No.3: Yes. </text> </page> </pdf2xml> Interpretation 135-2008-19 - January 29, 2011 2011-01-29 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-19.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 2 ©2011 ASHRAE. All Rights reserved.</text> <text top="1118" left="807" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2008-19 OF </text> <text top="112" left="264" width="395" height="16" font="2">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="1"> </text> <text top="196" left="339" width="244" height="16" font="1">Approval Date: January 29, 2011 </text> <text top="217" left="459" width="5" height="16" font="1"> </text> <text top="238" left="459" width="5" height="16" font="1"> </text> <text top="259" left="108" width="226" height="16" font="2">Request from: Dean Matsen (</text> <text top="259" left="334" width="217" height="16" font="3">dean.matsen@honeywell.com</text> <text top="259" left="550" width="196" height="16" font="1">), Alerton Dealer Business </text> <text top="280" left="108" width="659" height="16" font="1">Honeywell Automation & Control Solutions, 6670 185th Ave. NE, Redmond, WA 98052. </text> <text top="301" left="108" width="5" height="16" font="1"> </text> <text top="323" left="108" width="692" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in Addendum g </text> <text top="344" left="108" width="686" height="16" font="1">to ANSI/ASHRAE Standard 135-2008, Clause 24.3.3.3 and Table 24.11 (page 20), relating to </text> <text top="365" left="108" width="323" height="16" font="1">What it means for a device to "know a key". </text> <text top="386" left="108" width="5" height="16" font="1"> </text> <text top="407" left="108" width="683" height="16" font="2">Background: Clause 24.3.3.3 states "The List Of Known Keys is populated with each of the </text> <text top="428" left="108" width="282" height="16" font="1">Key Identifiers that the device knows" </text> <text top="449" left="108" width="5" height="16" font="1"> </text> <text top="470" left="108" width="694" height="16" font="1">This is somewhat vague and very subject to interpretation. There is no given definition of what </text> <text top="491" left="108" width="190" height="16" font="1">it means to "know" a key. </text> <text top="512" left="108" width="5" height="16" font="1"> </text> <text top="533" left="108" width="651" height="16" font="1">It is also not specified whether the Device-Master-Key and/or Distribution-Keys are to be </text> <text top="554" left="108" width="680" height="16" font="1">included in the list. Most devices apparently "know" these, but it's useless information to any </text> <text top="575" left="108" width="255" height="16" font="1">other device except the key server. </text> <text top="595" left="108" width="5" height="16" font="1"> </text> <text top="616" left="108" width="671" height="16" font="1">Furthermore, it is not specified whether keys are to be included in the list if they reside in an </text> <text top="637" left="108" width="706" height="16" font="1">expired or not-yet-active key set. One could argue that the device apparently "knows" these keys </text> <text top="658" left="108" width="536" height="16" font="1">as well, but they are not that useful to the other device at the current time. </text> <text top="679" left="108" width="5" height="16" font="1"> </text> <text top="700" left="108" width="692" height="16" font="1">There is no indication of what to do if both key sets are simultaneously active. Knowing this is </text> <text top="721" left="108" width="589" height="16" font="1">important because it may require the device to compute the union of the key sets. </text> <text top="742" left="108" width="5" height="16" font="1"> </text> <text top="763" left="108" width="702" height="16" font="1">There is a clause in 24.3.3.3 that states "A device may optionally leave out of the List Of Known </text> <text top="784" left="108" width="648" height="16" font="1">Keys any keys that the device knows will not grant sufficient access if the failed action is </text> <text top="805" left="108" width="686" height="16" font="1">retried." On the surface, this sounds like optionally leaving weak(er) keys off the list and only </text> <text top="826" left="108" width="681" height="16" font="1">including strong(er) keys. However, it could also be possibly interpreted to mean leaving any </text> <text top="847" left="108" width="692" height="16" font="1">keys off the list that the other device can't use at all (If the device can't use the key at all, then it </text> <text top="868" left="108" width="219" height="16" font="1">won't grant sufficient access). </text> <text top="889" left="108" width="5" height="16" font="1"> </text> <text top="910" left="108" width="658" height="16" font="1">Given this, it seems that the device "knowing" the key is almost irrelevant. Rather, the list </text> <text top="931" left="108" width="677" height="16" font="1">should only include keys the receiver of the error could possibly use, additionally leaving out </text> <text top="952" left="108" width="244" height="16" font="1">any known weak(er) keys. </text> <text top="973" left="108" width="5" height="16" font="1"> </text> <text top="994" left="108" width="597" height="16" font="2">Interpretation: The returned list of "known" keys is to be formulated as follows: </text> <text top="1015" left="108" width="5" height="16" font="1"> </text> <text top="1036" left="108" width="483" height="16" font="1">- The Device-Master-Key and Distribution-Key are left off the list </text> <text top="1057" left="108" width="5" height="16" font="1"> </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="4" size="13" family="Times" color="#000000"/> <text top="58" left="108" width="101" height="14" font="4">IC 135-2008-19 </text> <text top="1120" left="108" width="813" height="14" font="0">Page 2 of 2 ©2011 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="699" height="16" font="1">- Only keys from currently active key sets are returned. Keys from expired or not yet active key </text> <text top="112" left="108" width="132" height="16" font="1">sets are excluded. </text> <text top="133" left="108" width="5" height="16" font="1"> </text> <text top="154" left="108" width="661" height="16" font="1">- If both key sets are active, a cheap implementation may just concatenate the two key sets, </text> <text top="175" left="108" width="680" height="16" font="1">possibly listing the same key twice. A better implementation may optionally ensure that each </text> <text top="196" left="108" width="170" height="16" font="1">key is only listed once. </text> <text top="217" left="108" width="5" height="16" font="1"> </text> <text top="238" left="108" width="297" height="16" font="2">Question: Is this interpretation correct? </text> <text top="259" left="108" width="5" height="16" font="1"> </text> <text top="280" left="108" width="105" height="16" font="2">Answer: No. </text> <text top="301" left="108" width="5" height="16" font="1"> </text> <text top="323" left="108" width="648" height="16" font="2">Comments: The response should only consider keys from the revision used to secure the </text> <text top="343" left="108" width="675" height="16" font="1">message. Also the DeviceMaster and Distribution keys should be included due to their use in </text> <text top="364" left="108" width="300" height="16" font="1">certain services that can report this error. </text> </page> </pdf2xml> Interpretation 135-2008-20 - May 25, 2011 2011-05-25 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-20.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="9" family="Times" color="#000000"/> <text top="1099" left="108" width="699" height="14" font="0">Page 1 of 1 ©2011 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2008-20 OF </text> <text top="112" left="264" width="395" height="16" font="2">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="1"> </text> <text top="196" left="351" width="221" height="16" font="1">Approval Date: May 25, 2011 </text> <text top="217" left="108" width="5" height="16" font="1"> </text> <text top="238" left="108" width="222" height="16" font="2">Request from: Carl Neilson (</text> <text top="238" left="330" width="205" height="16" font="3">cneilson@deltacontrols.com</text> <text top="238" left="535" width="197" height="16" font="1">), Delta Controls, 17850 56</text> <text top="234" left="732" width="9" height="11" font="4">th</text> <text top="238" left="742" width="56" height="16" font="1"> Street, </text> <text top="259" left="108" width="165" height="16" font="1">Surrey, BC V3S 1C7. </text> <text top="280" left="108" width="5" height="16" font="1"> </text> <text top="302" left="108" width="594" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="660" height="16" font="1">ANSI/ASHRAE Standard 135-2008, Clauses J.2 (page 617), relating to BACnet Broadcast </text> <text top="344" left="108" width="592" height="16" font="1">Management Device (BBMD) and BACnet Virtual Link Layer (BVLL) Services. </text> <text top="365" left="108" width="5" height="16" font="1"> </text> <text top="386" left="108" width="701" height="16" font="2">Background: Annex J does not clearly specify what a device that is not a BBMD should do on </text> <text top="407" left="108" width="688" height="16" font="1">receipt of a BVLL message that is intended for a BBMD (Write-Broadcast-Distribution-Table; </text> <text top="428" left="108" width="667" height="16" font="1">Read-Broadcast-Distribution-Table; Register-Foreign-Device; Read-Foreign-Device-Table; </text> <text top="449" left="108" width="560" height="16" font="1">Delete-Foreign-Device-Table-Entry; and Distribute-Broadcast-To-Network). </text> <text top="470" left="108" width="5" height="16" font="1"> </text> <text top="491" left="108" width="670" height="16" font="1">There is a provision for NAKing these services, but the standard does not indicate whether a </text> <text top="512" left="108" width="663" height="16" font="1">non-BBMD should be NAKing, returning some other response (such as an empty BDT to a </text> <text top="533" left="108" width="450" height="16" font="1">Read-Broadcast-Distribution-Table), or ignoring the requests. </text> <text top="554" left="108" width="5" height="16" font="1"> </text> <text top="575" left="108" width="690" height="16" font="1">This question applies to both devices that can never be BBMDs, and to devices which could be </text> <text top="595" left="108" width="399" height="16" font="1">BBMDs but are not configured to operate as a BBMD. </text> <text top="616" left="108" width="5" height="16" font="1"> </text> <text top="638" left="108" width="660" height="16" font="2">Interpretation: Devices that are not BBMDs (and cannot be configured as BBMDs) shall </text> <text top="659" left="108" width="465" height="16" font="1">return a NAK when one of the above noted services is received. </text> <text top="680" left="108" width="5" height="16" font="1"> </text> <text top="701" left="108" width="702" height="16" font="1">Devices that are capable of operating as a BBMD but are not configured as a BBMD shall return </text> <text top="722" left="108" width="694" height="16" font="1">a NAK to Register-Foreign-Device, and Distribute-Broadcast-To-Network services. It is a local </text> <text top="743" left="108" width="573" height="16" font="1">matter whether an ACK or a NAK is returned in response to the other services. </text> <text top="764" left="108" width="9" height="16" font="1"> </text> <text top="785" left="108" width="297" height="16" font="2">Question: Is this interpretation correct? </text> <text top="806" left="108" width="5" height="16" font="1"> </text> <text top="827" left="108" width="111" height="16" font="2">Answer: Yes. </text> <text top="848" left="108" width="5" height="16" font="1"> </text> <text top="869" left="108" width="5" height="16" font="1"> </text> <text top="890" left="108" width="5" height="16" font="1"> </text> <text top="911" left="108" width="5" height="16" font="1"> </text> <text top="932" left="108" width="5" height="16" font="1"> </text> <text top="953" left="108" width="5" height="16" font="1"> </text> <text top="974" left="108" width="5" height="16" font="1"> </text> <text top="995" left="108" width="5" height="16" font="1"> </text> <text top="1016" left="108" width="5" height="16" font="1"> </text> <text top="1037" left="108" width="5" height="16" font="1"> </text> <text top="1058" left="108" width="5" height="16" font="1"> </text> <text top="1079" left="108" width="5" height="16" font="1"> </text> </page> </pdf2xml> Interpretation 135-2008-21 - May 25, 2011 2011-05-25 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2008-21.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="9" family="Times" color="#000000"/> <text top="1099" left="108" width="699" height="14" font="0">Page 1 of 2 ©2011 ASHRAE. All Rights reserved. </text> <text top="1118" left="108" width="5" height="16" font="1"> </text> <text top="91" left="301" width="320" height="16" font="2">INTERPRETATION IC 135-2008-21 OF </text> <text top="112" left="264" width="395" height="16" font="2">ANSI/ASHRAE STANDARD 135-2008 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="2">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="2">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="1"> </text> <text top="196" left="351" width="221" height="16" font="1">Approval Date: May 25, 2011 </text> <text top="217" left="108" width="5" height="16" font="1"> </text> <text top="238" left="108" width="222" height="16" font="2">Request from: Carl Neilson (</text> <text top="238" left="330" width="205" height="16" font="3">cneilson@deltacontrols.com</text> <text top="238" left="535" width="197" height="16" font="1">), Delta Controls, 17850 56</text> <text top="243" left="732" width="12" height="11" font="4">th </text> <text top="238" left="745" width="51" height="16" font="1">Street, </text> <text top="259" left="108" width="161" height="16" font="1">Surrey, BC V3S 1C7. </text> <text top="280" left="108" width="5" height="16" font="1"> </text> <text top="302" left="108" width="594" height="16" font="2">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="609" height="16" font="1">ANSI/ASHRAE Standard 135-2008, Clauses 12.25 (pages 259 and 281), relating to </text> <text top="344" left="108" width="271" height="16" font="1">Timestamping of Trend Log records. </text> <text top="365" left="108" width="5" height="16" font="1"> </text> <text top="386" left="108" width="692" height="16" font="2">Background: Records in Trend Log and Trend Log Multiple objects include a timestamp that </text> <text top="407" left="108" width="691" height="16" font="1">indicate, as per Clause 12.25.14, "The local date and time when the record was collected." This </text> <text top="428" left="108" width="694" height="16" font="1">language is ambiguous as to whether the timestamp of the record is the time at which the object </text> <text top="449" left="108" width="651" height="16" font="1">starts the attempt to retrieve the data value, or the time at which it receives the data value. </text> <text top="470" left="108" width="5" height="16" font="1"> </text> <text top="491" left="108" width="645" height="16" font="1">There are other properties, Align_Intervals, Interval_Offset that impact when records are </text> <text top="512" left="108" width="655" height="16" font="1">collected. The existance of these properties appear to indicate that the time that a record is </text> <text top="533" left="108" width="693" height="16" font="1">collected is important. The question is whether it is important that the collection occurs at these </text> <text top="554" left="108" width="615" height="16" font="1">special offsets, or that the timestamps of the records end up being aligned for ease of </text> <text top="575" left="108" width="102" height="16" font="1">consumption. </text> <text top="595" left="108" width="5" height="16" font="1"> </text> <text top="616" left="108" width="662" height="16" font="1">If the timestamp marks the time at which the logging object starts its attempt to retrieve the </text> <text top="637" left="108" width="589" height="16" font="1">value, then the timestamps will reflect the interval and interval offset constraints. </text> <text top="658" left="108" width="5" height="16" font="1"> </text> <text top="679" left="108" width="656" height="16" font="1">If the timestamp marks the time at which the value is placed in the Log_Buffer, then when </text> <text top="700" left="108" width="641" height="16" font="1">logging remote properties, the timestamps will not reflect the interval and interval offset </text> <text top="721" left="108" width="260" height="16" font="1">characteristics of the configuration. </text> <text top="742" left="108" width="5" height="16" font="1"> </text> <text top="763" left="108" width="662" height="16" font="1">In the normal operation of the system, the two timestamps are effectively equal in accuracy </text> <text top="784" left="108" width="682" height="16" font="1">given that neither represents the exact time at which the value is extracted from the monitored </text> <text top="805" left="108" width="683" height="16" font="1">object. When device binding, or route determination is required, the time at which the value is </text> <text top="826" left="108" width="318" height="16" font="1">place in the buffer would be more accurate. </text> <text top="847" left="108" width="5" height="16" font="1"> </text> <text top="868" left="108" width="691" height="16" font="1">Another aspect to consider whether the Log_Interval is the time between the start of an attempt </text> <text top="889" left="108" width="686" height="16" font="1">and the next start of an attempt to acquire data, or whether it is the time from when a sample is </text> <text top="910" left="108" width="467" height="16" font="1">placed in the log and the next start of an attempt to acquire data. </text> <text top="931" left="108" width="5" height="16" font="1"> </text> <text top="952" left="108" width="691" height="16" font="1">As there may be a delay between when a timer expires and when the controller is able to act on </text> <text top="973" left="108" width="691" height="16" font="1">the expiration of the timer, the log may not start at the absolute time indicated by Log_Interval, </text> <text top="994" left="108" width="667" height="16" font="1">Align_Intervals, and Interval_Offset. When the log is configured to align intervals, does the </text> <text top="1015" left="108" width="658" height="16" font="1">timestamp indicate the indicate the time at which the log is supposed to start the attempt to </text> <text top="1036" left="108" width="653" height="16" font="1">acquire the data sample, or should it reflect the actual time that the log starts the attemp to </text> <text top="1057" left="108" width="62" height="16" font="1">acquire. </text> <text top="1078" left="108" width="5" height="16" font="1"> </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="5" size="13" family="Times" color="#000000"/> <text top="58" left="108" width="101" height="14" font="5">IC 135-2008-21 </text> <text top="1120" left="108" width="699" height="14" font="0">Page 2 of 2 ©2011 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="706" height="16" font="2">Interpretation: The timestamp reflects the time at which the logging object is scheduled to start </text> <text top="112" left="108" width="677" height="16" font="1">its attempt to acquire the data sample(s) based on the values of Log_Interval, Align_Intervals </text> <text top="133" left="108" width="688" height="16" font="1">and Interval_Offset, and thus the timestamps of successive polled records will be Log_Interval </text> <text top="154" left="108" width="211" height="16" font="1">hundredths of seconds apart. </text> <text top="175" left="108" width="9" height="16" font="1"> </text> <text top="196" left="108" width="297" height="16" font="2">Question: Is this interpretation correct? </text> <text top="217" left="108" width="5" height="16" font="1"> </text> <text top="239" left="108" width="111" height="16" font="2">Answer: Yes. </text> <text top="260" left="108" width="5" height="16" font="1"> </text> <text top="281" left="108" width="5" height="16" font="1"> </text> <text top="302" left="108" width="5" height="16" font="1"> </text> <text top="323" left="108" width="5" height="16" font="1"> </text> <text top="343" left="108" width="5" height="16" font="1"> </text> <text top="364" left="108" width="5" height="16" font="1"> </text> <text top="385" left="108" width="5" height="16" font="1"> </text> <text top="406" left="108" width="5" height="16" font="1"> </text> <text top="427" left="108" width="5" height="16" font="1"> </text> <text top="448" left="108" width="5" height="16" font="1"> </text> <text top="469" left="108" width="5" height="16" font="1"> </text> <text top="490" left="108" width="5" height="16" font="1"> </text> <text top="511" left="108" width="5" height="16" font="1"> </text> <text top="532" left="108" width="5" height="16" font="1"> </text> <text top="553" left="108" width="5" height="16" font="1"> </text> <text top="574" left="108" width="5" height="16" font="1"> </text> <text top="595" left="108" width="5" height="16" font="1"> </text> <text top="616" left="108" width="5" height="16" font="1"> </text> <text top="637" left="108" width="5" height="16" font="1"> </text> <text top="658" left="108" width="5" height="16" font="1"> </text> <text top="679" left="108" width="5" height="16" font="1"> </text> <text top="700" left="108" width="5" height="16" font="1"> </text> </page> </pdf2xml> Interpretation 135-2010-1 - May 25, 2011 2011-05-25 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2010-1.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 2 ©2011 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2010-1 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2010 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="351" width="221" height="16" font="2">Approval Date: May 25, 2011 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="234" height="16" font="1">Request from: Bernhard Isler (</text> <text top="238" left="342" width="210" height="16" font="3">bernhard.isler@siemens.com</text> <text top="238" left="551" width="205" height="16" font="2">), Siemens Switzerland Ltd, </text> <text top="259" left="108" width="675" height="16" font="2">Building Technologies Division, International Headquarters, Gubelstrasse 22, CH-6301 Zug, </text> <text top="280" left="108" width="95" height="16" font="2">Switzerland. </text> <text top="301" left="108" width="5" height="16" font="2"> </text> <text top="323" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="344" left="108" width="620" height="16" font="2">ANSI/ASHRAE Standard 135-2010, Clause 12.24, relating to Schedule Object Type. </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="694" height="16" font="1">Background: In the lighting domain a schedule needs to be able to command the same value at </text> <text top="407" left="108" width="666" height="16" font="2">subsequent points in time (e.g. 18:00 OFF; 20:00 OFF; ..). This allows e.g. to override local </text> <text top="428" left="108" width="676" height="16" font="2">commands at the same command priority. The actual language in Clause 12.24.4 is unclear if </text> <text top="449" left="108" width="691" height="16" font="2">this is allowed. The language could be interpreted in the following way: if the Present_Value is </text> <text top="470" left="108" width="651" height="16" font="2">OFF and the subsequent entry in e.g. Weekly_Schedule is also OFF, then this value is not </text> <text top="491" left="108" width="661" height="16" font="2">written to the referenced properties. The Clauses 12.24.7 to 12.24.9 use the terms 'schedule </text> <text top="512" left="108" width="520" height="16" font="2">action' and 'in effect' which are independent if the value changes or not. </text> <text top="533" left="108" width="5" height="16" font="2"> </text> <text top="726" left="810" width="5" height="16" font="2"> </text> <text top="742" left="108" width="705" height="16" font="2">A similar use case for this feature is present in HVAC control, where a temperature setting has to </text> <text top="763" left="108" width="693" height="16" font="2">be reset, e.g. each midnight, to a default value, in order to override manual settings done during </text> <text top="784" left="108" width="62" height="16" font="2">the day. </text> <text top="805" left="108" width="5" height="16" font="2"> </text> <text top="827" left="108" width="180" height="16" font="1">12.24.4 Present_Value </text> <text top="847" left="108" width="594" height="16" font="2">... This property shall be writable when Out_Of_Service is TRUE (see 12.24.14). </text> <text top="868" left="108" width="5" height="16" font="2"> </text> <text top="889" left="108" width="568" height="16" font="2">Any change in the value of this property shall be written to all members of the </text> <text top="910" left="108" width="366" height="16" font="2">List_Of_Object_Property_References property. ... </text> <text top="931" left="108" width="5" height="16" font="2"> </text> <text top="952" left="108" width="686" height="16" font="2">The normal calculation of the value of the Present_Value property is illustrated as follows (the </text> <text top="973" left="108" width="598" height="16" font="2">actual algorithm used is a local matter but must yield the same results as this one): </text> <text top="994" left="108" width="5" height="16" font="2"> </text> <text top="1015" left="135" width="642" height="16" font="2">1. Find the highest relative priority (as defined by Clause 12.24.8) Exception_Schedule </text> <text top="1036" left="162" width="626" height="16" font="2">array element that is in effect for the current day and whose current value (see method </text> <text top="1057" left="162" width="536" height="16" font="2">below) is not NULL, and assign that value to the Present_Value property. </text> <text top="674" left="149" width="27" height="14" font="0">0:00</text> <text top="674" left="189" width="27" height="14" font="0">2:00</text> <text top="674" left="230" width="27" height="14" font="0">4:00</text> <text top="674" left="405" width="34" height="14" font="0">12:00</text> <text top="674" left="540" width="156" height="14" font="0">18:00 20:00 22:00 23:59</text> <text top="674" left="270" width="27" height="14" font="0">6:00</text> <text top="607" left="108" width="28" height="14" font="0">OFF</text> <text top="566" left="108" width="22" height="14" font="0">ON</text> <text top="566" left="702" width="70" height="14" font="0">00:00 OFF </text> <text top="584" left="702" width="70" height="14" font="0">02:00 OFF </text> <text top="601" left="702" width="70" height="14" font="0">04:00 OFF </text> <text top="619" left="702" width="70" height="14" font="0">18:00 OFF </text> <text top="636" left="702" width="70" height="14" font="0">20:00 OFF </text> <text top="654" left="702" width="70" height="14" font="0">22:00 OFF </text> <text top="701" left="243" width="444" height="14" font="0">Example of a daily schedule to do an override every 2 hours during night </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="4" size="13" family="Times" color="#000000"/> <text top="58" left="108" width="93" height="14" font="4">IC 135-2010-1 </text> <text top="1120" left="108" width="699" height="14" font="0">Page 2 of 2 ©2011 ASHRAE. All Rights reserved. </text> <text top="91" left="135" width="638" height="16" font="2">2. If the Present_Value was not assigned in the previous step, then evaluate the current </text> <text top="112" left="162" width="632" height="16" font="2">value of the Weekly_Schedule array element for the current day and if that value is not </text> <text top="133" left="162" width="346" height="16" font="2">NULL, assign it to the Present_Value property. </text> <text top="154" left="135" width="664" height="16" font="2">3. If the Present_Value was not assigned in the previous steps, then assign the value of the </text> <text top="175" left="162" width="429" height="16" font="2">Schedule_Default property to the Present_Value property. </text> <text top="196" left="108" width="5" height="16" font="2"> </text> <text top="217" left="108" width="698" height="16" font="2">The method for evaluating the current value of a schedule (either exception or weekly) is to find </text> <text top="238" left="108" width="703" height="16" font="2">the latest element in the list of BACnetTimeValues that occurs on or before the current time, and </text> <text top="259" left="108" width="686" height="16" font="2">then use that element's value as the current value for the schedule. If no such element is found, </text> <text top="280" left="108" width="398" height="16" font="2">then the current value for the schedule shall be NULL. </text> <text top="301" left="108" width="18" height="16" font="2">... </text> <text top="322" left="108" width="5" height="16" font="2"> </text> <text top="343" left="108" width="339" height="16" font="1">12.24.7 Weekly_Schedule (first paragraph) </text> <text top="364" left="108" width="695" height="16" font="2">... A BACnetDailySchedule consists of a list of BACnetTimeValues that are (time, value) pairs, </text> <text top="385" left="108" width="591" height="16" font="2">which describe the sequence of schedule actions on one day of the week when no </text> <text top="406" left="108" width="256" height="16" font="2">Exception_Schedule is in effect. ... </text> <text top="427" left="108" width="5" height="16" font="2"> </text> <text top="448" left="108" width="378" height="16" font="1">12.24.8 Exception_Schedule (second paragraph) </text> <text top="469" left="108" width="704" height="16" font="2">... If the current date matches any of the calendar entry criteria, the Exception Schedule would be </text> <text top="490" left="108" width="514" height="16" font="2">activated and the list of BACnetTimeValues would be enabled for use. </text> <text top="511" left="108" width="18" height="16" font="2">... </text> <text top="532" left="108" width="5" height="16" font="2"> </text> <text top="553" left="108" width="338" height="16" font="1">12.24.9 Schedule_Default (first paragraph) </text> <text top="574" left="108" width="669" height="16" font="2">This property holds a default value to be used for the Present_Value property when no other </text> <text top="595" left="108" width="357" height="16" font="2">scheduled value is in effect (see Clause 12.24.4). </text> <text top="616" left="108" width="18" height="16" font="2">... </text> <text top="637" left="108" width="5" height="16" font="2"> </text> <text top="658" left="108" width="692" height="16" font="1">Interpretation: A schedule action is in effect when a (time, value) pair is active for the current </text> <text top="679" left="108" width="697" height="16" font="2">time. This schedule action is in effect until another (time, value) pair comes into effect. A (time, </text> <text top="700" left="108" width="690" height="16" font="2">value) pair that comes into effect and has the value NULL stops the effect of a schedule action. </text> <text top="721" left="108" width="679" height="16" font="2">This may activate a weekly schedule action or the Schedule_Default value. A schedule action </text> <text top="742" left="108" width="654" height="16" font="2">ends latest at the end of the day. If a schedule action goes into effect, the Present_Value is </text> <text top="763" left="108" width="362" height="16" font="2">updated and the referenced properties are written. </text> <text top="784" left="108" width="5" height="16" font="2"> </text> <text top="805" left="108" width="702" height="16" font="2">The Schedule object's behavior on writing to the referenced properties is independent of whether </text> <text top="826" left="108" width="613" height="16" font="2">the value changes from one schedule action to the next, or to and from the use of the </text> <text top="846" left="108" width="702" height="16" font="2">Schedule_Default value. Schedule actions that come into effect with the same value are different </text> <text top="867" left="108" width="650" height="16" font="2">schedule actions and thus will update the Present_Value and the referenced properties are </text> <text top="888" left="108" width="60" height="16" font="2">written. </text> <text top="909" left="108" width="5" height="16" font="2"> </text> <text top="931" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="952" left="108" width="5" height="16" font="2"> </text> <text top="973" left="108" width="105" height="16" font="1">Answer: No. </text> <text top="994" left="108" width="5" height="16" font="2"> </text> <text top="1015" left="108" width="694" height="16" font="1">Comments: The standard is ambiguous. The standard does not rule whether an implementation </text> <text top="1036" left="108" width="702" height="16" font="2">is required to write, or is not allowed to write a value out if the newly calculated value is derived </text> <text top="1057" left="108" width="567" height="16" font="2">from a new time- value pair but with a value that is equal to the present value. </text> </page> </pdf2xml> Interpretation 135-2010-2 - October 27, 2011 2011-10-27 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2010-2.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 1 ©2011 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2010-2 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2010 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="360" width="203" height="16" font="2">Approval Date: 10/27/2011 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="234" height="16" font="1">Request from: Bernhard Isler (</text> <text top="238" left="342" width="210" height="16" font="3">bernhard.isler@siemens.com</text> <text top="238" left="551" width="205" height="16" font="2">), Siemens Switzerland Ltd, </text> <text top="259" left="108" width="573" height="16" font="2">Building Technologies Division, Gubelstrasse 22, CH-6301 Zug, Switzerland. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="654" height="16" font="2">ANSI/ASHRAE 135-2010 clauses 12.25.5 (Trend Log Object Type, Enable property) and </text> <text top="344" left="108" width="703" height="16" font="2">12.25.14 (Trend Log Object Type, Log_Buffer property). This interpretation request also applies </text> <text top="365" left="108" width="695" height="16" font="2">to the corresponding property clauses of the Event Log Object Type (12.27.8, 12.27.13) and the </text> <text top="386" left="108" width="384" height="16" font="2">Trend Log Multiple Object Type (12.30.8, 12.30.19) </text> <text top="406" left="108" width="5" height="16" font="2"> </text> <text top="428" left="108" width="694" height="16" font="1">Background: In Clause 12.25.5, last sentence of first paragraph, the language for log-status is: </text> <text top="449" left="108" width="673" height="16" font="2">'Log_Buffer records of type log-status are recorded without regard to the value of the Enable </text> <text top="470" left="108" width="73" height="16" font="2">property.' </text> <text top="491" left="108" width="5" height="16" font="2"> </text> <text top="512" left="108" width="591" height="16" font="2">In Clause 12.25.14 the language for the log-status LOG_INTERRUPTED flag is: </text> <text top="533" left="108" width="682" height="16" font="2">'This flag indicates that the collection of records by the Trend Log object was interrupted by a </text> <text top="554" left="108" width="677" height="16" font="2">power failure, device reset, object reconfiguration or other such disruption, such that samples </text> <text top="575" left="108" width="325" height="16" font="2">prior to this record might have been missed.' </text> <text top="595" left="108" width="5" height="16" font="2"> </text> <text top="616" left="108" width="704" height="16" font="2">The language for the LOG_INTERRUPTED flag indicates that logging was active ('collection of </text> <text top="637" left="108" width="636" height="16" font="2">records ... interrupted') if a log-status record with the LOG_INTERUPTED flag set was </text> <text top="658" left="108" width="689" height="16" font="2">recorded. But the language in 12.25.5 requires that log-status records are recorded independent </text> <text top="679" left="108" width="667" height="16" font="2">of the value of the Enable property, i.e. independent of collection of records is active or not. </text> <text top="700" left="108" width="5" height="16" font="2"> </text> <text top="722" left="108" width="658" height="16" font="1">Interpretation: After having logged a log-disabled status, there is never a log-interrupted </text> <text top="743" left="108" width="324" height="16" font="2">record logged, as long as the log is disabled. </text> <text top="764" left="108" width="5" height="16" font="2"> </text> <text top="785" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="806" left="108" width="5" height="16" font="2"> </text> <text top="827" left="108" width="106" height="16" font="1">Answer: Yes. </text> <text top="848" left="108" width="5" height="16" font="2"> </text> <text top="869" left="108" width="692" height="16" font="1">Comments: Yes, it is correct that a log-interrupted status is never logged after the log has been </text> <text top="890" left="108" width="681" height="16" font="2">disabled and a log disabled status has been logged. There are cases where a log interruption is </text> <text top="911" left="108" width="674" height="16" font="2">detected and the log is disabled at the same time, so a log-status record may be logged where </text> <text top="932" left="108" width="435" height="16" font="2">both LOG_INTERRUPTED and LOG_DISABLED are set. </text> </page> </pdf2xml> Interpretation 135-2010-3 - October 27, 2011 2011-10-27 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2010-3.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 1 ©2011 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2010-3 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2010 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="360" width="207" height="16" font="2">Approval Date: 10/27/2011 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="249" height="16" font="1">Request from: Christoph Zeller (</text> <text top="238" left="357" width="256" height="16" font="3">Christoph.zeller@ch.sauter-bc.com</text> <text top="238" left="612" width="150" height="16" font="2">), Fr. Sauter AG, Im </text> <text top="259" left="108" width="313" height="16" font="2">Surinam 55, CH-4016 Basel, Switzerland. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="608" height="16" font="2">ANSI/ASHRAE 135-2010, Clause 12.11.50 (Device Object Type, Interval_Offset). </text> <text top="344" left="108" width="5" height="16" font="2"> </text> <text top="365" left="108" width="657" height="16" font="1">Background: In the device object are 2 types of synchronization recipients (12.11.31 and </text> <text top="386" left="108" width="655" height="16" font="2">12.11.47). If the UTC offset is not a multiple of full hours, it becomes unclear whether the </text> <text top="407" left="108" width="492" height="16" font="2">alignment has to be done separately for the two recipient list or not. </text> <text top="428" left="108" width="5" height="16" font="2"> </text> <text top="449" left="108" width="576" height="16" font="2">If Interval_Offset is set to 15minutes and the UTC offset is 30minutes, then the </text> <text top="470" left="108" width="526" height="16" font="2">Timesynchronization has to be either at x.15 local time or x.15 utc-time. </text> <text top="491" left="108" width="5" height="16" font="2"> </text> <text top="512" left="108" width="674" height="16" font="1">Interpretation: The Interval_Offset property describes the offset in local_time units even if </text> <text top="533" left="108" width="649" height="16" font="2">only the UTC_Time_Synchronization_Recipients property is populated (Non empty list). </text> <text top="554" left="108" width="5" height="16" font="2"> </text> <text top="575" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="596" left="108" width="5" height="16" font="2"> </text> <text top="617" left="108" width="111" height="16" font="1">Answer: Yes. </text> <text top="638" left="108" width="5" height="16" font="2"> </text> <text top="659" left="108" width="643" height="16" font="1">Comments: The Align_Intervals property causes alignment based on local time, and the </text> <text top="680" left="108" width="314" height="16" font="2">Interval_Offset defines an offset form that. </text> <text top="701" left="108" width="5" height="16" font="2"> </text> </page> </pdf2xml> Interpretation 135-2010-4 - July 16, 2012 2012-07-16 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2010-4.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="9" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 2 ©2012 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2010-4 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2010 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="352" width="218" height="16" font="2">Approval Date: July 16, 2012 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="222" height="16" font="1">Request from: Carl Neilson (</text> <text top="238" left="330" width="205" height="16" font="3">cneilson@deltacontrols.com</text> <text top="238" left="535" width="197" height="16" font="2">), Delta Controls, 17850 56</text> <text top="234" left="732" width="9" height="11" font="4">th</text> <text top="238" left="742" width="48" height="16" font="2"> Ave., </text> <text top="259" left="108" width="165" height="16" font="2">Surrey, BC V3S 1C7. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="698" height="16" font="2">ANSI/ASHRAE 135-2010, Clauses 5.2.1.2, 6, 6.4.4 and 6.6.3.5, as well as Table 6.1, relating to </text> <text top="344" left="108" width="151" height="16" font="2">router requirements. </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="703" height="16" font="1">Background: The standard does not make any explicit statements as to whether, or not, a router </text> <text top="407" left="108" width="642" height="16" font="2">is required to be capable of routing the maximum sized NPDU between any two directly </text> <text top="428" left="108" width="153" height="16" font="2">connected networks. </text> <text top="449" left="108" width="5" height="16" font="2"> </text> <text top="470" left="108" width="505" height="16" font="2">In describing the maximum conveyable APDU, Clause 5.2.1.2 states: </text> <text top="491" left="108" width="5" height="16" font="2"> </text> <text top="512" left="162" width="26" height="16" font="2">(b) </text> <text top="512" left="216" width="578" height="16" font="2">the maximum APDU size conveyable by the internetwork to the remote device, </text> <text top="533" left="162" width="639" height="16" font="2">which is constrained by the maximum NPDU length permitted by the data links used by </text> <text top="554" left="162" width="532" height="16" font="2">the local, remote, and any intervening networks, as specified in Clause 6; </text> <text top="575" left="108" width="5" height="16" font="2"> </text> <text top="595" left="108" width="635" height="16" font="2">Similarly in, in Clause 6, the standard discusses the restrictions on NPDU size. The last </text> <text top="616" left="108" width="213" height="16" font="2">paragraph of Clause 6 states: </text> <text top="637" left="108" width="5" height="16" font="2"> </text> <text top="658" left="162" width="627" height="16" font="2">Another common network layer function is message segmentation and reassembly. To </text> <text top="679" left="162" width="643" height="16" font="2">obviate the need for these capabilities at the network layer, BACnet imposes a limitation </text> <text top="700" left="162" width="640" height="16" font="2">on the length of the NPDU in messages passed through a BACnet router. The maximum </text> <text top="721" left="162" width="620" height="16" font="2">NPDU length shall not exceed the capability of any data link technology encountered </text> <text top="742" left="162" width="607" height="16" font="2">along the path from source to destination. A list of the maximum NPDU lengths for </text> <text top="763" left="162" width="384" height="16" font="2">BACnet data link technologies is given in Table 6-1. </text> <text top="784" left="108" width="5" height="16" font="2"> </text> <text top="805" left="108" width="697" height="16" font="2">These statements allow for the generation of messages of the maximum NPDU length permitted </text> <text top="826" left="108" width="689" height="16" font="2">on a data link as defined in the standard; it does not make any allowance for routers that do not </text> <text top="847" left="108" width="463" height="16" font="2">support the maximum for data links not defined in the standard. </text> <text top="868" left="108" width="5" height="16" font="2"> </text> <text top="889" left="108" width="696" height="16" font="2">Related to the question of routing of the largest messages supported by a data link, is the receipt </text> <text top="910" left="108" width="706" height="16" font="2">and processing of the largest messages supported by a data link. Clause 6.6.3.5 and 6.4.4 indicate </text> <text top="931" left="108" width="706" height="16" font="2">that a Reject-Message-To-Network with reason 4 is to be returned when a message is too large to </text> <text top="952" left="108" width="702" height="16" font="2">route to the next data link en route to its destination. No language indicates that a router shall be </text> <text top="973" left="108" width="529" height="16" font="2">capable of receiving all NPDUs in the valid size range for the data link. </text> <text top="994" left="108" width="5" height="16" font="2"> </text> <text top="1015" left="108" width="692" height="16" font="1">Interpretation No.1: Routers shall support the routing of the largest NPDUs between any two </text> <text top="1036" left="108" width="685" height="16" font="2">directly connected networks. For example, if a router supports 1 BACnet/IP port and 1 MS/TP </text> <text top="1057" left="108" width="597" height="16" font="2">port, it shall support the routing of 501 octet NPDUs between these two networks. </text> <text top="1078" left="108" width="5" height="16" font="2"> </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="5" size="13" family="Times" color="#000000"/> <text top="58" left="108" width="93" height="14" font="5">IC 135-2010-4 </text> <text top="1120" left="108" width="699" height="14" font="0">Page 2 of 2 ©2012 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="337" height="16" font="1">Question No.1: Is this interpretation correct? </text> <text top="112" left="108" width="5" height="16" font="2"> </text> <text top="134" left="108" width="151" height="16" font="1">Answer No.1: Yes. </text> <text top="154" left="108" width="5" height="16" font="2"> </text> <text top="176" left="108" width="653" height="16" font="1">Comments: The router shall support routing the largest NPDU supported by the directly </text> <text top="197" left="108" width="219" height="16" font="2">connected datalinks involved. </text> <text top="218" left="108" width="5" height="16" font="2"> </text> <text top="239" left="108" width="690" height="16" font="1">Interpretation No.2: Routers shall be capable of receiving the largest NPDU transmittable on </text> <text top="260" left="108" width="681" height="16" font="2">directly connected data links even if they are not routable to any other directly connected data </text> <text top="281" left="108" width="627" height="16" font="2">link or are too large for the router's application layer so as to allow for the returning of </text> <text top="302" left="108" width="691" height="16" font="2">appropriate Reject-Message-To-Network messages. (In this context "receive" means the ability </text> <text top="323" left="108" width="683" height="16" font="2">to detect properly formed messages that are too large to route or process; it does not imply the </text> <text top="344" left="108" width="369" height="16" font="2">ability to receive and store the complete message). </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="337" height="16" font="1">Question No.2: Is this interpretation correct? </text> <text top="407" left="108" width="5" height="16" font="2"> </text> <text top="428" left="108" width="146" height="16" font="1">Answer No.2: Yes </text> <text top="449" left="108" width="5" height="16" font="2"> </text> <text top="470" left="108" width="5" height="16" font="2"> </text> </page> </pdf2xml> Interpretation 135-2010-5 - July 16, 2012 2012-07-16 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2010-5.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="9" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 2 ©2012 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2010-5 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2010 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="352" width="218" height="16" font="2">Approval Date: July 16, 2012 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="222" height="16" font="1">Request from: Carl Neilson (</text> <text top="238" left="330" width="205" height="16" font="3">cneilson@deltacontrols.com</text> <text top="238" left="535" width="197" height="16" font="2">), Delta Controls, 17850 56</text> <text top="234" left="732" width="9" height="11" font="4">th</text> <text top="238" left="742" width="48" height="16" font="2"> Ave., </text> <text top="259" left="108" width="165" height="16" font="2">Surrey, BC V3S 1C7. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="625" height="16" font="2">ANSI/ASHRAE 135-2010, Clauses 12.25.9 and K.4.3, relating to T-VMT-E-B BIBB. </text> <text top="344" left="108" width="5" height="16" font="2"> </text> <text top="365" left="108" width="527" height="16" font="1">Background: This interpretation request originated from the BTL-WG. </text> <text top="386" left="108" width="5" height="16" font="2"> </text> <text top="407" left="108" width="531" height="16" font="2">In Clause 12.25.9, the description of the Log_Interval property, it states: </text> <text top="428" left="108" width="5" height="16" font="2"> </text> <text top="449" left="162" width="653" height="16" font="2">If present, this property shall be writable if Logging_Type has either the value POLLED </text> <text top="470" left="162" width="657" height="16" font="2">or the value COV. This property shall be read-only if Logging_Type has the value </text> <text top="491" left="162" width="111" height="16" font="2">TRIGGERED. </text> <text top="512" left="108" width="5" height="16" font="2"> </text> <text top="533" left="108" width="439" height="16" font="2">In T-VMT-E-B, it states that Log_Interval shall be writable: </text> <text top="554" left="108" width="5" height="16" font="2"> </text> <text top="575" left="162" width="629" height="16" font="1">K.4.3 BIBB - Trending-Viewing and Modifying Trends External-B (T-VMT-E-B) </text> <text top="596" left="162" width="9" height="16" font="2"> </text> <text top="617" left="162" width="653" height="16" font="2">The B device is capable of trending properties of objects contained in other devices. The </text> <text top="638" left="162" width="666" height="16" font="2">B device shall support T-VMT-I-B and DS-RP-A. The Log_Interval and </text> <text top="658" left="162" width="409" height="16" font="2">Log_DeviceObjectProperty properties must be writable. </text> <text top="679" left="162" width="9" height="16" font="2"> </text> <text top="700" left="162" width="658" height="16" font="2">The Trend Log objects must be capable of trending REAL, Unsigned, INTEGER, </text> <text top="721" left="162" width="404" height="16" font="2">BOOLEAN, Bit String, Enumerated and NULL values. </text> <text top="742" left="108" width="5" height="16" font="2"> </text> <text top="763" left="108" width="700" height="16" font="2">The purpose of the BIBB is to indicate that a device is capable of trending objects / properties in </text> <text top="784" left="108" width="692" height="16" font="2">other devices (as per first sentence). Since many devices do not support COV, a Trend Log that </text> <text top="805" left="108" width="677" height="16" font="2">only allows a value of 0 (meaning COV) to the Log_Interval would not be interoperable with </text> <text top="826" left="108" width="107" height="16" font="2">many devices. </text> <text top="847" left="108" width="5" height="16" font="2"> </text> <text top="868" left="108" width="695" height="16" font="1">Interpretation No.1: T-VMT-E-B requires that the device supports Trend Log objects support </text> <text top="889" left="108" width="661" height="16" font="2">a Logging_Type other than TRIGGERED so that Log_Interval is able to be made writable. </text> <text top="910" left="108" width="5" height="16" font="2"> </text> <text top="932" left="108" width="337" height="16" font="1">Question No.1: Is this interpretation correct? </text> <text top="953" left="108" width="5" height="16" font="2"> </text> <text top="974" left="108" width="146" height="16" font="1">Answer No.1: Yes </text> <text top="995" left="108" width="5" height="16" font="2"> </text> <text top="1016" left="108" width="668" height="16" font="1">Interpretation No.2: T-VMT-E-B requires that the device supports Trend Log objects that </text> <text top="1037" left="108" width="645" height="16" font="2">support values other than 0 in Log_Interval so as to fulfill the first sentence of the BIBB. </text> <text top="1058" left="108" width="5" height="16" font="2"> </text> <text top="1079" left="108" width="337" height="16" font="1">Question No.2: Is this interpretation correct? </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="5" size="13" family="Times" color="#000000"/> <text top="58" left="108" width="93" height="14" font="5">IC 135-2010-5 </text> <text top="1120" left="108" width="699" height="14" font="0">Page 2 of 2 ©2012 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="5" height="16" font="2"> </text> <text top="112" left="108" width="146" height="16" font="1">Answer No.2: Yes </text> <text top="133" left="108" width="5" height="16" font="2"> </text> </page> </pdf2xml> Interpretation 135-2010-6 - June 13, 2012 2012-06-13 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2010-6.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="9" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 2 ©2012 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2010-6 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2010 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="351" width="221" height="16" font="2">Approval Date: June 13, 2012 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="222" height="16" font="1">Request from: Carl Neilson (</text> <text top="238" left="330" width="205" height="16" font="3">cneilson@deltacontrols.com</text> <text top="238" left="535" width="197" height="16" font="2">), Delta Controls, 17850 56</text> <text top="234" left="732" width="9" height="11" font="4">th</text> <text top="238" left="742" width="48" height="16" font="2"> Ave., </text> <text top="259" left="108" width="165" height="16" font="2">Surrey, BC V3S 1C7. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="633" height="16" font="2">ANSI/ASHRAE 135-2010, Clause 15.7.2, relating to the special property OPTIONAL. </text> <text top="344" left="108" width="5" height="16" font="2"> </text> <text top="365" left="108" width="527" height="16" font="1">Background: This interpretation request originated from the BTL-WG. </text> <text top="386" left="108" width="5" height="16" font="2"> </text> <text top="407" left="108" width="702" height="16" font="2">The standard does not explicitly state what to do when executing a ReadPropertyMultple request </text> <text top="428" left="108" width="698" height="16" font="2">for the special property OPTIONAL when the referenced object contains no optional properties. </text> <text top="449" left="108" width="5" height="16" font="2"> </text> <text top="470" left="108" width="620" height="16" font="2">In Standard135, in Clause 15.7.2, the ReadPropertyMultiple service procedure states: </text> <text top="491" left="108" width="694" height="16" font="2">If the 'List of Property References' portion of the 'List of Read Access Specifications' parameter </text> <text top="512" left="108" width="704" height="16" font="2">contains the property identifier ALL, REQUIRED, or OPTIONAL, then the 'List of Read Access </text> <text top="533" left="108" width="678" height="16" font="2">Results' shall be constructed as if each property being returned had been explicitly referenced </text> <text top="554" left="108" width="121" height="16" font="2">(see 15.7.3.1.2). </text> <text top="575" left="108" width="5" height="16" font="2"> </text> <text top="595" left="108" width="646" height="16" font="2">In Standard 135, in Clause 15.7.3.1.2, the ReadPropertyMultple service procedure states: </text> <text top="616" left="108" width="668" height="16" font="2">The property identifier OPTIONAL means that only those standard properties present in the </text> <text top="637" left="108" width="434" height="16" font="2">object that have a conformance code "O" shall be returned. </text> <text top="658" left="108" width="5" height="16" font="2"> </text> <text top="679" left="108" width="660" height="16" font="2">In Standard135, in Clause 15.7.2, with respect to errors, the ReadPropertyMultipel service </text> <text top="700" left="108" width="126" height="16" font="2">procedure states: </text> <text top="721" left="108" width="673" height="16" font="2">If none of the specified objects is found or if none of the specified properties of the specified </text> <text top="742" left="108" width="684" height="16" font="2">objects can be accessed, either a 'Result(-)' primitive or a Result(+) primitive that returns error </text> <text top="763" left="108" width="695" height="16" font="2">codes for all properties shall be issued. If any of the specified properties of the specified objects </text> <text top="784" left="108" width="679" height="16" font="2">can be accessed, then a 'Result(+)' primitive shall be issued, which returns all accessed values </text> <text top="805" left="108" width="438" height="16" font="2">and error codes for all properties that could not be accessed. </text> <text top="826" left="108" width="5" height="16" font="2"> </text> <text top="847" left="108" width="383" height="16" font="2">In Standard 135.1-2009, in Clause 9.20.1.8, it states: </text> <text top="868" left="108" width="684" height="16" font="2">Notes to Tester: If no optional properties are supported then an empty 'List of Results' shall be </text> <text top="889" left="108" width="256" height="16" font="2">returned for the specified property. </text> <text top="910" left="108" width="5" height="16" font="2"> </text> <text top="931" left="108" width="624" height="16" font="2">Based on the description in 15.7.2 the list of properties to return would be of length 0. </text> <text top="952" left="108" width="5" height="16" font="2"> </text> <text top="973" left="108" width="597" height="16" font="2">In Standard 135, Clause 15.7.3.1.2, it states about the List of Property References: </text> <text top="994" left="108" width="542" height="16" font="2">This parameter shall be a list of one or more BACnetPropertyReferences... </text> <text top="1015" left="108" width="5" height="16" font="2"> </text> <text top="1036" left="108" width="701" height="16" font="2">Given this, there would never be a case where the no properties were requested for an object and </text> <text top="1057" left="108" width="672" height="16" font="2">thus in the response there would be no other case where the List Of Results would be empty. </text> <text top="1078" left="108" width="701" height="16" font="2">This could lead to one assuming that for the OPTIONAL property, in the case where no optional </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="5" size="22" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 2 of 2 ©2012 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="665" height="16" font="2">properties are supported, that an error entry would be required (so that a non-empty List-Of-</text> <text top="112" left="108" width="214" height="16" font="2">Results would be generated). </text> <text top="133" left="108" width="5" height="16" font="2"> </text> <text top="154" left="108" width="504" height="16" font="2">To contrast this, in Standard 135.1-2009, in Clause 9.20.1.8, it states: </text> <text top="175" left="108" width="684" height="16" font="2">Notes to Tester: If no optional properties are supported then an empty 'List of Results' shall be </text> <text top="196" left="108" width="256" height="16" font="2">returned for the specified property. </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="656" height="16" font="1">Interpretation: If no optional properties are supported by the referenced object type then </text> <text top="259" left="108" width="694" height="16" font="2">reading the OPTIONAL property shall result in an empty 'List of Results' (in the presence of no </text> <text top="280" left="108" width="99" height="16" font="2">other errors). </text> <text top="301" left="108" width="5" height="16" font="2"> </text> <text top="322" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="343" left="108" width="5" height="16" font="2"> </text> <text top="364" left="108" width="106" height="16" font="1">Answer: Yes </text> <text top="385" left="108" width="5" height="16" font="2"> </text> <text top="420" left="108" width="5" height="28" font="5"> </text> </page> </pdf2xml> Interpretation 135-2010-7 - June 13, 2012 2012-06-13 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2010-7.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <fontspec id="4" size="16" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 3 ©2012 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2010-7 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2010 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="351" width="221" height="16" font="2">Approval Date: June 13, 2012 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="234" height="16" font="1">Request from: Bernhard Isler (</text> <text top="238" left="342" width="210" height="16" font="3">bernhard.isler@siemens.com</text> <text top="238" left="551" width="205" height="16" font="2">), Siemens Switzerland Ltd, </text> <text top="259" left="108" width="675" height="16" font="2">Building Technologies Division, International Headquarters, Gubelstrasse 22, CH-6301 Zug, </text> <text top="280" left="108" width="95" height="16" font="2">Switzerland. </text> <text top="301" left="108" width="5" height="16" font="2"> </text> <text top="323" left="108" width="697" height="16" font="1">Reference: This request for interpretation refers to standard ANSI/ASHRAE 135-2010, Clause </text> <text top="344" left="108" width="691" height="16" font="2">13.1, "Change of Value Reporting" on page 412, Table 13-1 on page 413, and Table 13-1a on </text> <text top="365" left="108" width="75" height="16" font="2">page 414. </text> <text top="386" left="108" width="5" height="16" font="2"> </text> <text top="407" left="108" width="106" height="16" font="1">Background: </text> <text top="428" left="108" width="680" height="16" font="2">In the course of testing property Change of Value (COV) reporting functionality, a discussion </text> <text top="449" left="108" width="660" height="16" font="2">with a test tool supplier came up on criteria for when to notify a change, and what property </text> <text top="470" left="108" width="463" height="16" font="2">values should be conveyed in the respective COV notifications. </text> <text top="491" left="108" width="5" height="16" font="2"> </text> <text top="512" left="108" width="321" height="16" font="2">COV reporting appears to have two flavors: </text> <text top="533" left="108" width="5" height="16" font="2"> </text> <text top="554" left="108" width="184" height="16" font="1">Object COV Reporting </text> <text top="575" left="108" width="623" height="16" font="2">The service SubscribeCOV is used to subscribe for COV notifications from an object. </text> <text top="596" left="108" width="694" height="16" font="2">Standardized objects use the standardized criteria for when to notify a change, and a defined set </text> <text top="617" left="108" width="520" height="16" font="2">of property values is conveyed in COV notifications, as per Table 13-1. </text> <text top="638" left="108" width="5" height="16" font="2"> </text> <text top="659" left="108" width="201" height="16" font="1">Property COV Reporting </text> <text top="680" left="108" width="677" height="16" font="2">The service SubscribeCOVProperty is used to subscribe for COV notifications of a particular </text> <text top="701" left="108" width="684" height="16" font="2">property. The Table 13-1a lists criteria per property data type for when to notify a change, and </text> <text top="722" left="108" width="698" height="16" font="2">the set of property values conveyed in COV notifications, for properties other than those listed </text> <text top="743" left="108" width="110" height="16" font="1">in Table 13-1. </text> <text top="764" left="108" width="5" height="16" font="2"> </text> <text top="785" left="108" width="592" height="16" font="2">For Property COV Reporting of a particular property, there seem to be two cases: </text> <text top="806" left="135" width="661" height="16" font="2">a) If the property subscribed to is the property that appears to be the "monitored property" </text> <text top="827" left="162" width="589" height="16" font="2">as with Object COV Reporting, then Table 13-1 applies for the criteria and set of </text> <text top="848" left="162" width="310" height="16" font="2">properties conveyed in COV notifications. </text> <text top="869" left="135" width="663" height="16" font="2">b) For any other property subscribed to, then Table 13-1a applies for the criteria and set of </text> <text top="890" left="162" width="376" height="16" font="2">property values conveyed in the COV notifications. </text> <text top="911" left="108" width="5" height="16" font="2"> </text> <text top="932" left="108" width="679" height="16" font="2">The Device object property Active_COV_Subscriptions, Clause 12.11.39, page 201, does not </text> <text top="953" left="108" width="662" height="16" font="2">specify what property the "Monitored Property" field of the COV context should reference. </text> <text top="974" left="108" width="5" height="16" font="2"> </text> <text top="995" left="108" width="699" height="16" font="2">Language in Clause 13.1, third paragraph, last sentence, refers to properties listed in Table 13-1, </text> <text top="1016" left="108" width="487" height="16" font="2">but Table 13-1 lists object types. The table caption of Table 13-1a "</text> <text top="1018" left="596" width="4" height="14" font="0"> </text> <text top="1016" left="599" width="169" height="16" font="2">Criteria Used for COV </text> <text top="1037" left="108" width="676" height="16" font="2">Reporting of Properties Other Than Those Listed in Table 13-1" makes the same reference to </text> <text top="1058" left="108" width="293" height="16" font="2">Table 13-1, but which lists object types. </text> <text top="1079" left="108" width="5" height="16" font="2"> </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <text top="1120" left="108" width="699" height="14" font="0">Page 2 of 3 ©2012 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="640" height="16" font="2">Following interpretations do not necessarily depend on each other, and their sequence is </text> <text top="112" left="108" width="71" height="16" font="2">arbitrary. </text> <text top="133" left="108" width="5" height="16" font="2"> </text> <text top="154" left="108" width="134" height="16" font="1">Interpretation 1: </text> <text top="175" left="108" width="694" height="16" font="2">For Object COV Reporting, the "monitored property" of standard object types as listed in Table </text> <text top="196" left="108" width="694" height="16" font="2">13-1 is the Present_Value, except for Access Point objects, where the Access_Event property is </text> <text top="217" left="108" width="688" height="16" font="2">the "monitored property". This is the property the COV context in the Device object shall refer </text> <text top="238" left="108" width="23" height="16" font="2">to. </text> <text top="259" left="108" width="5" height="16" font="1"> </text> <text top="280" left="108" width="310" height="16" font="1">Question 1: Is this interpretation correct? </text> <text top="301" left="108" width="5" height="16" font="2"> </text> <text top="322" left="108" width="115" height="16" font="1">Answer 1: Yes </text> <text top="343" left="108" width="5" height="16" font="2"> </text> <text top="365" left="108" width="134" height="16" font="1">Interpretation 2: </text> <text top="385" left="108" width="694" height="16" font="2">In Property COV Reporting, the "monitored property" is the property specified in the Subscribe </text> <text top="406" left="108" width="690" height="16" font="2">COV Property service. This is the property the COV context in the Device object shall refer to. </text> <text top="428" left="108" width="5" height="16" font="1"> </text> <text top="449" left="108" width="310" height="16" font="1">Question 2: Is this interpretation correct? </text> <text top="470" left="108" width="5" height="16" font="2"> </text> <text top="491" left="108" width="115" height="16" font="1">Answer 2: Yes </text> <text top="512" left="108" width="5" height="16" font="2"> </text> <text top="533" left="108" width="134" height="16" font="1">Interpretation 3: </text> <text top="554" left="108" width="627" height="16" font="2">In Property COV Reporting, if the "monitored property" is the property that is also the </text> <text top="575" left="108" width="701" height="16" font="2">"monitored property" in Object COV Reporting for the object, Table 13-1 applies for the criteria </text> <text top="596" left="108" width="690" height="16" font="2">when to notify changes and what property values have to be conveyed in the COV notification. </text> <text top="617" left="108" width="5" height="16" font="1"> </text> <text top="638" left="108" width="310" height="16" font="1">Question 3: Is this interpretation correct? </text> <text top="659" left="108" width="5" height="16" font="2"> </text> <text top="680" left="108" width="115" height="16" font="1">Answer 3: Yes </text> <text top="701" left="108" width="5" height="16" font="2"> </text> <text top="723" left="108" width="134" height="16" font="1">Interpretation 4: </text> <text top="743" left="108" width="627" height="16" font="2">In Property COV Reporting, if the "monitored property" is any other property than the </text> <text top="764" left="108" width="694" height="16" font="2">"monitored property" in Object COV Reporting for the object, Table 13-1a applies, for both the </text> <text top="785" left="108" width="703" height="16" font="2">criteria when to notify changes and what property values have to be conveyed in the notification. </text> <text top="807" left="108" width="5" height="16" font="1"> </text> <text top="828" left="108" width="310" height="16" font="1">Question 4: Is this interpretation correct? </text> <text top="849" left="108" width="5" height="16" font="2"> </text> <text top="870" left="108" width="115" height="16" font="1">Answer 4: Yes </text> <text top="891" left="108" width="5" height="16" font="2"> </text> <text top="912" left="108" width="134" height="16" font="1">Interpretation 5: </text> <text top="933" left="108" width="637" height="16" font="2">Based on Table 13-1a, column "Properties Reported": If the monitored property is not a </text> <text top="954" left="108" width="696" height="16" font="2">"monitored property" from Table 13-1, the property values conveyed in COV notifications shall </text> <text top="975" left="108" width="698" height="16" font="2">be: 1) the "monitored property" (or subscribed-to property), and 2) the value of the Status_Flags </text> <text top="996" left="108" width="220" height="16" font="2">property if the object has one. </text> <text top="1017" left="108" width="5" height="16" font="1"> </text> <text top="1038" left="108" width="310" height="16" font="1">Question 5: Is this interpretation correct? </text> <text top="1059" left="108" width="5" height="16" font="2"> </text> <text top="1080" left="108" width="115" height="16" font="1">Answer 5: Yes </text> </page> <page number="3" position="absolute" top="0" left="0" height="1188" width="918"> <text top="1120" left="108" width="699" height="14" font="0">Page 3 of 3 ©2012 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="5" height="16" font="2"> </text> <text top="112" left="108" width="134" height="16" font="1">Interpretation 6: </text> <text top="133" left="108" width="695" height="16" font="2">As a critical case: For Property COV Reporting, as per Table 13-1a, if the "monitored property" </text> <text top="154" left="108" width="684" height="16" font="2">is Status_Flags, the COV notification shall convey two property values: 1) Status_Flags as the </text> <text top="175" left="108" width="564" height="16" font="2">"subscribed-to" property, and 2) Status_Flags (the object has one, obviously). </text> <text top="196" left="108" width="5" height="16" font="1"> </text> <text top="217" left="108" width="310" height="16" font="1">Question 6: Is this interpretation correct? </text> <text top="238" left="108" width="5" height="16" font="2"> </text> <text top="260" left="108" width="115" height="16" font="1">Answer 6: Yes </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="301" left="108" width="5" height="16" font="2"> </text> </page> </pdf2xml> Interpretation 135-2010-8 - November 7, 2012 2012-11-07 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2010-8.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 2 ©2012 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2010-8 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2010 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="334" width="255" height="16" font="2">Approval Date: November 7, 2012 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="675" height="16" font="1">Request from: Duffy O’Craven (btl-manager@bacnetinternational.org), Quinda Inc., 41 St. </text> <text top="259" left="108" width="342" height="16" font="2">Hilda’s Av. Toronto ON M4N 2P5 CANADA. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="691" height="16" font="2">ANSI/ASHRAE 135-2010, Clause 12.24.4 and 12.24.6, relating to the behavior of the property </text> <text top="344" left="108" width="279" height="16" font="2">Present_Value of the Schedule object. </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="656" height="16" font="1">Background: This interpretation request originated from the BTL-WG, whilst discussing </text> <text top="407" left="108" width="233" height="16" font="2">Clarification Request CR-0272. </text> <text top="428" left="108" width="5" height="16" font="2"> </text> <text top="449" left="108" width="695" height="16" font="2">The standard states explicitly two conflicting behaviors regarding Present_Value changes while </text> <text top="470" left="108" width="275" height="16" font="2">Schedule is outside Effective_Period. </text> <text top="491" left="108" width="5" height="16" font="2"> </text> <text top="512" left="108" width="690" height="16" font="2">In Standard135, in Clause 12.24.6, the Present_Value of the Schedule object description states: </text> <text top="533" left="108" width="659" height="16" font="2">These calculations are such that they can be performed at any time and the correct value of </text> <text top="554" left="108" width="671" height="16" font="2">Present_Value property will result. These calculations must be performed at 00:00 each day, </text> <text top="575" left="108" width="634" height="16" font="2">whenever the device resets, whenever properties that can affect the results are changed, </text> <text top="595" left="108" width="704" height="16" font="2">whenever the time in the device changes by an amount that may have an effect on the calculation </text> <text top="616" left="108" width="642" height="16" font="2">result, and at other times, as required, to maintain the correct value of the Present_Value </text> <text top="637" left="108" width="334" height="16" font="2">property through the normal passage of time. </text> <text top="658" left="108" width="5" height="16" font="2"> </text> <text top="679" left="108" width="643" height="16" font="2">Note that the Present_Value property will be assigned the value of the Schedule_Default </text> <text top="700" left="108" width="655" height="16" font="2">property at 00:00 of any given day, unless there is an entry for 00:00 in effect for that day. </text> <text top="721" left="108" width="5" height="16" font="2"> </text> <text top="742" left="108" width="689" height="16" font="2">None of those statements contain any qualification indicating which, if any, do not apply while </text> <text top="763" left="108" width="275" height="16" font="2">Schedule is outside Effective_Period. </text> <text top="784" left="108" width="5" height="16" font="2"> </text> <text top="805" left="108" width="662" height="16" font="2">In Standard 135, in Clause 12.24.6, the Effective_Period of the Schedule object description </text> <text top="826" left="108" width="50" height="16" font="2">states: </text> <text top="847" left="108" width="684" height="16" font="2">This property specifies the range of dates within which the Schedule object is active. Seasonal </text> <text top="868" left="108" width="665" height="16" font="2">scheduling may be achieved by defining several SCHEDULE objects with non-overlapping </text> <text top="889" left="108" width="424" height="16" font="2">Effective_Periods to control the same property references. </text> <text top="910" left="108" width="5" height="16" font="2"> </text> <text top="931" left="108" width="661" height="16" font="2">This effectively precludes writing to members of the List_Of_Object_Property_References </text> <text top="952" left="108" width="702" height="16" font="2">property while Schedule is outside Effective_Period, but does not directly preclude recalculating </text> <text top="973" left="108" width="451" height="16" font="2">Present_Value while its Schedule is outside Effective_Period. </text> <text top="994" left="108" width="5" height="16" font="2"> </text> <text top="1015" left="108" width="695" height="16" font="2">Standard 135.1-2009, in Clause 7.3.2.23.1 with Test concept: “… the Present_Value property is </text> <text top="1036" left="108" width="680" height="16" font="2">monitored to verify that write operations occur only within the Effective_Period.” has step 7: </text> <text top="1057" left="108" width="18" height="16" font="2">7. </text> <text top="1057" left="162" width="220" height="16" font="2">VERIFY Present_Value = V2 </text> <text top="1078" left="108" width="666" height="16" font="2">This is perhaps an error, since BTL revised the test. The revised test BTL -7.3.2.23.1 states: </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="3" size="16" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 2 of 2 ©2012 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="18" height="16" font="2">7. </text> <text top="91" left="162" width="229" height="16" font="2">VERIFY Present_Value = V21 </text> <text top="112" left="108" width="628" height="16" font="2">Test BTL – 7.3.2.23.1 is executed if and only if the IUT is prior to protocol revision 4. </text> <text top="133" left="108" width="5" height="16" font="2"> </text> <text top="154" left="108" width="659" height="16" font="2">There is another BTL test which is executed if and only if the IUT is protocol revision 4 or </text> <text top="175" left="108" width="704" height="16" font="2">higher, with Test concept: “…a property referenced by the List_Of_Object_Property_References </text> <text top="196" left="108" width="677" height="16" font="2">property is monitored to verify that write operations occur only within the Effective_Period.” </text> <text top="217" left="108" width="613" height="16" font="2">That test, in the applicable corresponding step, expresses a different approach. BTL -</text> <text top="238" left="108" width="208" height="16" font="2">7.3.2.23.X.1 at step 7 states: </text> <text top="259" left="108" width="18" height="16" font="2">7. </text> <text top="259" left="162" width="271" height="16" font="2">VERIFY "referenced property" = V1 </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="301" left="108" width="673" height="16" font="1">Interpretation: Though writes to the members of the List_Of_Object_Property_References </text> <text top="322" left="108" width="706" height="16" font="2">property while Schedule is outside Effective_Period are precluded, the standard does not prohibit </text> <text top="343" left="108" width="548" height="16" font="2">recalculating Present_Value while its Schedule is outside Effective_Period. </text> <text top="364" left="108" width="5" height="16" font="2"> </text> <text top="385" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="406" left="108" width="5" height="16" font="2"> </text> <text top="427" left="108" width="100" height="16" font="1">Answer: No </text> <text top="448" left="108" width="5" height="16" font="2"> </text> <text top="470" left="108" width="671" height="16" font="1">Comments: The first sentence of 12.24.6 says "… range of dates within which the Schedule </text> <text top="491" left="108" width="681" height="16" font="2">object is active." It is therefore not expected that the schedule object will be re-calculating its </text> <text top="512" left="108" width="646" height="16" font="2">Present_Value when it is not "active." Since Present_Value is not changing, writes to the </text> <text top="532" left="108" width="466" height="16" font="2">members of List_Of_Object_Property_References do not occur. </text> </page> </pdf2xml> Interpretation 135-2010-9 - November 7, 2012 2012-11-07 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2010-9.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 2 ©2012 ASHRAE. All Rights reserved. </text> <text top="91" left="306" width="311" height="16" font="1">INTERPRETATION IC 135-2010-9 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2010 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="334" width="255" height="16" font="2">Approval Date: November 7, 2012 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="675" height="16" font="1">Request from: Duffy O’Craven (btl-manager@bacnetinternational.org), Quinda Inc., 41 St. </text> <text top="259" left="108" width="342" height="16" font="2">Hilda’s Av. Toronto ON M4N 2P5 CANADA. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="690" height="16" font="2">ANSI/ASHRAE 135-2010, Clauses 15.1.1.4.1.2, 15.1.1.4.2.2, 15.1.1.4.3.2, and 15.8.2, relating </text> <text top="344" left="108" width="621" height="16" font="2">to the content of ReadRange-ACK when MORE_ITEMS is true, and the Count in the </text> <text top="365" left="108" width="254" height="16" font="2">ReadRange-Request was negative. </text> <text top="386" left="108" width="5" height="16" font="2"> </text> <text top="407" left="108" width="656" height="16" font="1">Background: This interpretation request originated from the BTL-WG, whilst discussing </text> <text top="428" left="108" width="233" height="16" font="2">Clarification Request CR-0278. </text> <text top="449" left="108" width="5" height="16" font="2"> </text> <text top="470" left="108" width="618" height="16" font="2">The standard states ambiguously what the content of ReadRange-ACK shall be when </text> <text top="491" left="108" width="652" height="16" font="2">MORE_ITEMS is true, and the requested Count in the ReadRange-Request was negative. </text> <text top="512" left="108" width="5" height="16" font="2"> </text> <text top="533" left="108" width="612" height="16" font="2">In Standard 135, in Clause 15.1.1.4.1.2, under Reference Index the procedure states: </text> <text top="554" left="108" width="661" height="16" font="2">“… if 'Count' is negative the record specified by 'Reference Index' shall be the last record.” </text> <text top="575" left="108" width="5" height="16" font="2"> </text> <text top="595" left="108" width="704" height="16" font="2">In Standard 135, in Clause 15.1.1.4.2.2, under Reference Sequence Number the procedure states: </text> <text top="616" left="108" width="698" height="16" font="2">“If 'Count' is negative the record specified by 'Reference Sequence Number' shall be the last and </text> <text top="637" left="108" width="248" height="16" font="2">newest record read and returned.” </text> <text top="658" left="108" width="5" height="16" font="2"> </text> <text top="679" left="108" width="609" height="16" font="2">In Standard 135, in Clause 15.1.1.4.3.2, under Reference Time the procedure states: </text> <text top="700" left="108" width="680" height="16" font="2">“… if 'Count' is negative, the newest record with a timestamp older than the time specified by </text> <text top="721" left="108" width="383" height="16" font="2">'Reference Time' shall be the last and newest record. </text> <text top="742" left="108" width="5" height="16" font="2"> </text> <text top="763" left="108" width="694" height="16" font="2">In Standard 135, in Clause 15.8.2 the service procedure states several things. However, because </text> <text top="784" left="108" width="679" height="16" font="2">that uses slightly different wording, it throws the meaning of the above statements into doubt. </text> <text top="805" left="108" width="679" height="16" font="2">For 'By Position' the service procedure states: “… the responding BACnet-user shall read and </text> <text top="826" left="108" width="665" height="16" font="2">attempt to return all of the items specified. The items specified include the item at the index </text> <text top="847" left="108" width="689" height="16" font="2">specified by 'Reference Index' plus up to 'Count' - 1 items following if 'Count' is positive, or up </text> <text top="868" left="108" width="392" height="16" font="2">to -1 - 'Count' items preceding if 'Count' is negative.” </text> <text top="889" left="108" width="5" height="16" font="2"> </text> <text top="910" left="108" width="689" height="16" font="2">For 'By Time' the service procedure states: “If 'Count' is negative, the records specified include </text> <text top="931" left="108" width="668" height="16" font="2">the newest record with a timestamp older than 'Reference Time' and up to -1-'Count' records </text> <text top="952" left="108" width="681" height="16" font="2">preceding. The sequence number of the first item returned shall be included in the response… </text> <text top="973" left="108" width="387" height="16" font="2">The items shall be returned in chronological order.” </text> <text top="994" left="108" width="5" height="16" font="2"> </text> <text top="1015" left="108" width="677" height="16" font="2">For 'By Sequence Number' the service procedure states: “…in the range 'Reference Sequence </text> <text top="1036" left="108" width="508" height="16" font="2">Number' plus 'Count'+1 to 'Reference Sequence' if 'Count' is negative. </text> <text top="1057" left="108" width="5" height="16" font="2"> </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="3" size="22" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 2 of 2 ©2012 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="634" height="16" font="2">It has thus been argued that the phrase: shall “… be the last and newest record read and </text> <text top="112" left="108" width="697" height="16" font="2">returned.” could mean “… shall eventually be the last and newest record read and returned from </text> <text top="133" left="108" width="682" height="16" font="2">the last of a series of ReadRange-Requests, subsequent to the first one returning a ReadRange-</text> <text top="154" left="108" width="664" height="16" font="2">ACK which has MORE_ITEMS as true.” That would be the first time that the 135 standard </text> <text top="175" left="108" width="558" height="16" font="2">would be using the concept of the eventual response to a subsequent request. </text> <text top="196" left="108" width="5" height="16" font="2"> </text> <text top="217" left="108" width="701" height="16" font="2">It has been argued that when the content of ReadRange-ACK has MORE_ITEMS as true, then it </text> <text top="238" left="108" width="703" height="16" font="2">should be permitted to return a contiguous range of entries as long as that is flush with either end </text> <text top="259" left="108" width="699" height="16" font="2">of the whole requested range. First_Sequence_Number will indicate which records are included. </text> <text top="280" left="108" width="704" height="16" font="2">But then any client using 'By Time' needs to also make requests for additional records, both prior </text> <text top="301" left="108" width="648" height="16" font="2">and subsequent, to find those that potentially match the whole requested 'By Time' range. </text> <text top="322" left="108" width="5" height="16" font="2"> </text> <text top="343" left="108" width="682" height="16" font="2">Also if that interpretation is taken and the content of ReadRange-ACK is permitted to return a </text> <text top="364" left="108" width="694" height="16" font="2">contiguous range of entries as long as that is flush with either end of the whole requested range, </text> <text top="385" left="108" width="627" height="16" font="2">then any client using 'By Position' has no way to interpret what was received when the </text> <text top="406" left="108" width="694" height="16" font="2">ReadRange-ACK has MORE_ITEMS as true, since there is nothing like a First_Position_Index </text> <text top="427" left="108" width="259" height="16" font="2">when the request was 'By Position'. </text> <text top="448" left="108" width="5" height="16" font="2"> </text> <text top="469" left="108" width="688" height="16" font="1">Interpretation: As long as there are items in the list that match the 'Range' parameter criteria, </text> <text top="490" left="108" width="623" height="16" font="2">then even when the requested Count in the ReadRange-Request was negative, and the </text> <text top="511" left="108" width="705" height="16" font="2">ReadRange-ACK MORE_ITEMS flag is true, every ReadRange-ACK shall include a contiguous </text> <text top="532" left="108" width="653" height="16" font="2">range of records ending with the record specified by 'Reference Index' if 'By Position'; the </text> <text top="553" left="108" width="687" height="16" font="2">newest record with a timestamp older than the time specified by 'Reference Time' if 'By Time'; </text> <text top="574" left="108" width="583" height="16" font="2">and record specified by 'Reference Sequence Number' if 'By Sequence Number'. </text> <text top="595" left="108" width="5" height="16" font="2"> </text> <text top="616" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="637" left="108" width="5" height="16" font="2"> </text> <text top="658" left="108" width="111" height="16" font="1">Answer: Yes. </text> <text top="679" left="108" width="5" height="16" font="2"> </text> <text top="713" left="108" width="5" height="28" font="3"> </text> </page> </pdf2xml> Interpretation 135-2010-10 - November 7, 2012 2012-11-07 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2010-10.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 2 ©2012 ASHRAE. All Rights reserved. </text> <text top="91" left="301" width="320" height="16" font="1">INTERPRETATION IC 135-2010-10 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2010 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="334" width="255" height="16" font="2">Approval Date: November 7, 2012 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="675" height="16" font="1">Request from: Duffy O’Craven (btl-manager@bacnetinternational.org), Quinda Inc., 41 St. </text> <text top="259" left="108" width="342" height="16" font="2">Hilda’s Av. Toronto ON M4N 2P5 CANADA. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="680" height="16" font="2">ANSI/ASHRAE 135-2010, Clauses 12.25 Preamble and 12.27 Preamble and 12.30 Preamble, </text> <text top="344" left="108" width="580" height="16" font="2">relating to the behavior of the property Total_Record_Count of logging objects. </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="656" height="16" font="1">Background: This interpretation request originated from the BTL-WG, whilst discussing </text> <text top="407" left="108" width="233" height="16" font="2">Clarification Request CR-0274. </text> <text top="428" left="108" width="5" height="16" font="2"> </text> <text top="449" left="108" width="666" height="16" font="2">The standard never states explicitly when, if ever, the Total_Record_Count, may or shall be </text> <text top="470" left="108" width="239" height="16" font="2">reduced by writing to the object. </text> <text top="491" left="108" width="5" height="16" font="2"> </text> <text top="512" left="108" width="362" height="16" font="2">In Standard 135, in Clause 12.25 preamble states: </text> <text top="533" left="108" width="683" height="16" font="2">The buffer may be cleared by writing a zero to the Record_Count property. Each record in the </text> <text top="554" left="108" width="691" height="16" font="2">buffer has an implied SequenceNumber which is equal to the value of the Total_Record_Count </text> <text top="575" left="108" width="343" height="16" font="2">property immediately after the record is added. </text> <text top="595" left="108" width="5" height="16" font="2"> </text> <text top="616" left="108" width="582" height="16" font="2">And in a later provision gives that implied SequenceNumber semantic meaning: </text> <text top="637" left="108" width="5" height="16" font="2"> </text> <text top="658" left="108" width="671" height="16" font="2">A missed notification may be detected by a subscriber if the 'Current Notification' parameter </text> <text top="679" left="108" width="624" height="16" font="2">received in the previous BUFFER_READY notification is different than the 'Previous </text> <text top="700" left="108" width="504" height="16" font="2">Notification' parameter of the current BUFFER_READY notification </text> <text top="721" left="108" width="5" height="16" font="2"> </text> <text top="742" left="108" width="586" height="16" font="2">Similar statements appear in standard 135, in Clause 12.27 and 12.30 preambles. </text> <text top="763" left="108" width="5" height="16" font="2"> </text> <text top="784" left="108" width="680" height="16" font="2">Also Standard 135.1-2009, in Clause 7.3.2.24.8 with Test concept: “…Record_Count is set to </text> <text top="805" left="108" width="686" height="16" font="2">zero and Log_Buffer is read to verify no records are present. Collection of data proceeds until </text> <text top="826" left="108" width="686" height="16" font="2">Record_Count is about Buffer_Size/2, collection is halted and Log_Buffer is read to verify the </text> <text top="847" left="108" width="687" height="16" font="2">Record_Count value. Collection then resumes until Buffer_Size records are read; collection is </text> <text top="868" left="108" width="574" height="16" font="2">then halted and Log_Buffer read to verify Record_Count again.” has steps 1-3: </text> <text top="889" left="108" width="217" height="16" font="2">1. WRITE Record_Count = 0 </text> <text top="910" left="108" width="297" height="16" font="2">2. WAIT Internal Processing Fail Time </text> <text top="931" left="108" width="334" height="16" font="2">3. CHECK ( that Log_Buffer has no records ) </text> <text top="952" left="108" width="5" height="16" font="2"> </text> <text top="973" left="108" width="588" height="16" font="2">Test 7.3.2.24.8 is executed if and only if the IUT is protocol revision 3 or higher. </text> <text top="994" left="108" width="5" height="16" font="2"> </text> <text top="1015" left="108" width="690" height="16" font="2">There are other tests which also write a 0 to Record_Count, but never state any constraint upon </text> <text top="1036" left="108" width="508" height="16" font="2">Total_Record_Count to give guidance. For instance in test 7.3.2.24.1: </text> <text top="1057" left="108" width="246" height="16" font="2">1. WRITE Log_Enable = FALSE </text> <text top="1078" left="108" width="217" height="16" font="2">2. WRITE Record_Count = 0 </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="3" size="9" family="Times" color="#000000"/> <fontspec id="4" size="22" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 2 of 2 ©2012 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="292" height="16" font="2">3. WAIT Internal Processing Fail Time </text> <text top="112" left="108" width="287" height="16" font="2">4. TRANSMIT ReadProperty-Request, </text> <text top="133" left="108" width="4" height="16" font="2"> </text> <text top="133" left="162" width="4" height="16" font="2"> </text> <text top="133" left="216" width="145" height="16" font="2">'Object Identifier' = </text> <text top="133" left="378" width="183" height="16" font="2">(the object being tested), </text> <text top="154" left="108" width="227" height="16" font="2"> 'Property </text> <text top="154" left="286" width="124" height="16" font="2">Identifier' </text> <text top="154" left="360" width="64" height="16" font="2">= </text> <text top="154" left="378" width="206" height="16" font="2">Total_Record_Count </text> <text top="175" left="108" width="250" height="16" font="2">5. RECEIVE ReadProperty-ACK, </text> <text top="196" left="108" width="4" height="16" font="2"> </text> <text top="196" left="162" width="4" height="16" font="2"> </text> <text top="196" left="216" width="145" height="16" font="2">'Object Identifier' = </text> <text top="196" left="378" width="183" height="16" font="2">(the object being tested), </text> <text top="217" left="108" width="227" height="16" font="2"> 'Property </text> <text top="217" left="286" width="124" height="16" font="2">Identifier' </text> <text top="217" left="360" width="64" height="16" font="2">= </text> <text top="217" left="378" width="206" height="16" font="2">Total_Record_Count </text> <text top="238" left="108" width="4" height="16" font="2"> </text> <text top="238" left="162" width="4" height="16" font="2"> </text> <text top="238" left="216" width="135" height="16" font="2">'Property Value' = </text> <text top="238" left="378" width="149" height="16" font="2">(any valid value, X) </text> <text top="259" left="108" width="5" height="16" font="2"> </text> <text top="280" left="108" width="661" height="16" font="1">Interpretation: Though writes of 0 to Record_Count property in logging objects clear the </text> <text top="301" left="108" width="695" height="16" font="2">buffer, and writes of new values to Log_DeviceObjectProperty render the contents of the buffer </text> <text top="322" left="108" width="628" height="16" font="2">obsolete and may clear the buffer, writing to either of those properties shall not reduce </text> <text top="343" left="108" width="683" height="16" font="2">Total_Record_Count, except in the condition where incrementing Total_Record_Count wraps </text> <text top="364" left="108" width="289" height="16" font="2">around its maximum possible value of 2</text> <text top="360" left="397" width="12" height="11" font="3">32</text> <text top="364" left="409" width="277" height="16" font="2"> – 1, as its next value then becomes 1. </text> <text top="385" left="108" width="5" height="16" font="2"> </text> <text top="406" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="427" left="108" width="5" height="16" font="2"> </text> <text top="448" left="108" width="111" height="16" font="1">Answer: Yes. </text> <text top="469" left="108" width="5" height="16" font="2"> </text> <text top="491" left="108" width="689" height="16" font="1">Comments: It does not matter how the buffer is cleared, be it by writing 0 to Record_Count or </text> <text top="512" left="108" width="602" height="16" font="2">changing Log_DeviceObjectProperty, the Total_Record_Count does not reset to 0. </text> <text top="546" left="108" width="5" height="28" font="4"> </text> </page> </pdf2xml> Interpretation 135-2010-11 - November 7, 2012 2012-11-07 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2010-11.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 1 ©2012 ASHRAE. All Rights reserved. </text> <text top="91" left="301" width="320" height="16" font="1">INTERPRETATION IC 135-2010-11 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2010 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="334" width="255" height="16" font="2">Approval Date: November 7, 2012 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="234" height="16" font="1">Request from: Bernhard Isler (</text> <text top="238" left="342" width="210" height="16" font="3">bernhard.isler@siemens.com</text> <text top="238" left="551" width="205" height="16" font="2">), Siemens Switzerland Ltd, </text> <text top="259" left="108" width="675" height="16" font="2">Building Technologies Division, International Headquarters, Gubelstrasse 22, CH-6301 Zug, </text> <text top="280" left="108" width="95" height="16" font="2">Switzerland. </text> <text top="301" left="108" width="5" height="16" font="2"> </text> <text top="323" left="108" width="697" height="16" font="1">Reference: This request for interpretation refers to standard ANSI/ASHRAE 135-2010, Clause </text> <text top="344" left="108" width="704" height="16" font="2">12.11.19, "Segmentation_Supported", and Clause 12.11.20, "Max_Segments_Accepted", both </text> <text top="365" left="108" width="97" height="16" font="2">on page 199. </text> <text top="386" left="108" width="5" height="16" font="2"> </text> <text top="407" left="108" width="106" height="16" font="1">Background: </text> <text top="428" left="108" width="644" height="16" font="2">The property Segmentation_Supported of the Device object indicates the segmentation </text> <text top="449" left="108" width="553" height="16" font="2">capabilities of the BACnet device. Two of the possible values of this object, </text> <text top="470" left="108" width="671" height="16" font="2">SEGMENTED_BOTH and SEGMENTED_RECEIVE, indicate that the device is capable of </text> <text top="491" left="108" width="679" height="16" font="2">receiving segmented APDUs. Receiving segmented APDUs covers both receiving segmented </text> <text top="512" left="108" width="511" height="16" font="2">confirmed requests and receiving segmented complex ACK messages. </text> <text top="533" left="108" width="5" height="16" font="2"> </text> <text top="554" left="108" width="701" height="16" font="2">The property Max_Segments_Accepted of the Device object indicates the maximum number of </text> <text top="575" left="108" width="685" height="16" font="2">segments of an APDU that the device can receive, for both segmented requests and segmented </text> <text top="596" left="108" width="186" height="16" font="2">complex ACK messages. </text> <text top="617" left="108" width="5" height="16" font="2"> </text> <text top="638" left="108" width="121" height="16" font="1">Interpretation: </text> <text top="659" left="108" width="650" height="16" font="2">For the case that a BACnet device is claiming support of reception of segmented APDUs, </text> <text top="680" left="108" width="593" height="16" font="2">indicated by SEGMENTED_BOTH or SEGMENTED_RECEIVE in the property </text> <text top="701" left="108" width="523" height="16" font="2">Segmentation_Supported of the Device object, the value of the property </text> <text top="722" left="108" width="628" height="16" font="2">Max_Segments_Accepted of the Device object shall have a value greater than one (1). </text> <text top="743" left="108" width="5" height="16" font="1"> </text> <text top="764" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="785" left="108" width="5" height="16" font="2"> </text> <text top="807" left="108" width="106" height="16" font="1">Answer: Yes. </text> <text top="827" left="108" width="5" height="16" font="2"> </text> </page> </pdf2xml> Interpretation 135-2010-12 - January 26, 2013 2013-01-26 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2010-12.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <fontspec id="3" size="16" family="Times" color="#0000ff"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 2 ©2013 ASHRAE. All Rights reserved. </text> <text top="91" left="301" width="320" height="16" font="1">INTERPRETATION IC 135-2010-12 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2010 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="2"> </text> <text top="196" left="339" width="244" height="16" font="2">Approval Date: January 26, 2013 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="241" height="16" font="1">Request from: Frank Schubert (</text> <text top="238" left="349" width="244" height="16" font="3">Frank.schubert@mbs-software.de</text> <text top="238" left="592" width="163" height="16" font="2">), SSPC 135 Member, </text> <text top="259" left="108" width="434" height="16" font="2">Römerstr. 15, D-47809 Krefeld, Germany, Krefeld, 47809. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="700" height="16" font="1">Reference: This request for interpretation refers to ANSI/ASHRAE Standard 135-2010, Clause </text> <text top="323" left="108" width="574" height="16" font="2">12, regarding the Object_Identifier property and the instance number 4194303. </text> <text top="344" left="108" width="5" height="16" font="2"> </text> <text top="365" left="108" width="694" height="16" font="1">Background: Chapter 12 (page 144) states that "No object shall have an Object_Identifier with </text> <text top="386" left="108" width="704" height="16" font="2">an instance number of 4194303. Object properties that contain BACnetObjectIdentifiers may use </text> <text top="407" left="108" width="409" height="16" font="2">4194303 to indicate that the property is not initialized." </text> <text top="428" left="108" width="5" height="16" font="2"> </text> <text top="449" left="108" width="179" height="16" font="2">Loop-Object Properties: </text> <text top="470" left="162" width="249" height="16" font="2">Manipulated_Variable_Reference </text> <text top="491" left="162" width="235" height="16" font="2">Controlled_Variable_Reference </text> <text top="512" left="162" width="147" height="16" font="2">Setpoint_Reference </text> <text top="533" left="108" width="5" height="16" font="2"> </text> <text top="554" left="108" width="695" height="16" font="2">Loop-Object implementation may or may not support references to external BACnet objects for </text> <text top="575" left="108" width="696" height="16" font="2">the Manipulated_Variable_Reference, Controlled_Variable_Reference and Setpoint_Reference. </text> <text top="595" left="108" width="689" height="16" font="2">In case the Loop-object does not support either of the three properties it is not clearly specified </text> <text top="616" left="108" width="421" height="16" font="2">how a missing (non-existent) reference may be presented. </text> <text top="637" left="108" width="5" height="16" font="2"> </text> <text top="658" left="108" width="696" height="16" font="2">The foreword of Chapter 12 allows for BACnetObjectIdentifiers to be represented by 4.194.303 </text> <text top="679" left="108" width="684" height="16" font="2">in case it is not associated to an object, but the data-type of the manipulated variable reference </text> <text top="700" left="108" width="613" height="16" font="2">and the controlled variable reference properties is BACnetObjectPropertyReference. </text> <text top="721" left="108" width="5" height="16" font="2"> </text> <text top="742" left="108" width="562" height="16" font="2">We noticed that some implementations use the object identifier portion of the </text> <text top="763" left="108" width="677" height="16" font="2">BACnetObjectPropertyReference set to 4.194.303, but we did not find any reference if this is </text> <text top="784" left="108" width="113" height="16" font="2">allowed or not. </text> <text top="805" left="108" width="5" height="16" font="2"> </text> <text top="826" left="108" width="487" height="16" font="2">The setpoint is already a sequence with one optional argument (the </text> <text top="847" left="108" width="445" height="16" font="2">BACnetObjectProperyReference), but the two others are not. </text> <text top="868" left="108" width="5" height="16" font="2"> </text> <text top="889" left="108" width="684" height="16" font="1">Interpretation #1: Manipulated_Variable_Reference and Controlled_Variable_Reference are </text> <text top="910" left="108" width="353" height="16" font="2">allowed to contain the object instance 4194303. </text> <text top="931" left="108" width="5" height="16" font="2"> </text> <text top="953" left="108" width="319" height="16" font="1">Question #1: Is this interpretation correct? </text> <text top="973" left="108" width="5" height="16" font="2"> </text> <text top="995" left="108" width="124" height="16" font="1">Answer #1: Yes </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <text top="1120" left="108" width="699" height="14" font="0">Page 2 of 2 ©2013 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="5" height="16" font="2"> </text> <text top="112" left="108" width="699" height="16" font="1">Interpretation #2: When either of these properties contains this 4194303 as the object instance, </text> <text top="133" left="108" width="386" height="16" font="2">it indicates that there is no related referenced object. </text> <text top="154" left="108" width="5" height="16" font="1"> </text> <text top="176" left="108" width="319" height="16" font="1">Question #2: Is this interpretation correct? </text> <text top="197" left="108" width="5" height="16" font="2"> </text> <text top="218" left="108" width="124" height="16" font="1">Answer #2: Yes </text> <text top="239" left="108" width="5" height="16" font="2"> </text> <text top="260" left="108" width="665" height="16" font="1">Interpretation #3: It is a local matter whether, or not, the existence of 4194303 in either of </text> <text top="281" left="108" width="450" height="16" font="2">these properties results in the Loop object stopping operation. </text> <text top="302" left="108" width="5" height="16" font="1"> </text> <text top="323" left="108" width="319" height="16" font="1">Question #3: Is this interpretation correct? </text> <text top="344" left="108" width="5" height="16" font="2"> </text> <text top="365" left="108" width="124" height="16" font="1">Answer #3: Yes </text> <text top="386" left="108" width="5" height="16" font="2"> </text> <text top="407" left="108" width="5" height="16" font="2"> </text> </page> </pdf2xml> Interpretation 135-2010-13 - January 26, 2013 2013-01-26 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2010-13.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="13" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#000000"/> <text top="1120" left="108" width="699" height="14" font="0">Page 1 of 2 ©2013 ASHRAE. All Rights reserved. </text> <text top="91" left="301" width="320" height="16" font="1">INTERPRETATION IC 135-2010-13 OF </text> <text top="112" left="264" width="395" height="16" font="1">ANSI/ASHRAE STANDARD 135-2010 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="1">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="1">Automation and Control Networks </text> <text top="176" left="459" width="5" height="16" font="1"> </text> <text top="196" left="339" width="244" height="16" font="2">Approval Date: January 26, 2013 </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="239" left="108" width="675" height="16" font="1">Request from: Duffy O’Craven (btl-manager@bacnetinternational.org), Quinda Inc., 41 St. </text> <text top="260" left="108" width="338" height="16" font="2">Hilda’s Av. Toronto ON M4N 2P5 CANADA </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="302" left="108" width="594" height="16" font="1">Reference: This request for interpretation refers to the requirements presented in </text> <text top="323" left="108" width="656" height="16" font="2">ANSI/ASHRAE 135-2010af-31, Clause 12.X, relating to the behavior of the AckRequired </text> <text top="344" left="108" width="623" height="16" font="2">Boolean in ConfirmedEventNotification and UnconfirmedEventNotification requests. </text> <text top="365" left="108" width="5" height="16" font="2"> </text> <text top="386" left="108" width="527" height="16" font="1">Background: This interpretation request originated from the BTL-WG. </text> <text top="407" left="108" width="5" height="16" font="2"> </text> <text top="428" left="108" width="620" height="16" font="2">The standard states no explicit behaviors regarding the AckRequired Boolean field in </text> <text top="449" left="108" width="703" height="16" font="2">ConfirmedEventNotification and UnconfirmedEventNotification requests that are engendered by </text> <text top="470" left="108" width="705" height="16" font="2">Alert Enrollment objects, though it is stated that "Information alerts" are never in need of/cannot </text> <text top="491" left="108" width="166" height="16" font="2">be Acknowledgement. </text> <text top="512" left="108" width="5" height="16" font="2"> </text> <text top="533" left="108" width="595" height="16" font="2">Standard 135-2010af-31, in Clause 12.X preamble of Alert Enrollment mentions: </text> <text top="554" left="108" width="5" height="16" font="2"> </text> <text top="575" left="108" width="698" height="16" font="2">..."Information alerts" are interesting notifications that are not related to algorithmic or intrinsic </text> <text top="596" left="108" width="684" height="16" font="2">reporting of an object. The Alert Enrollment object allows these alerts to be generated without </text> <text top="617" left="108" width="651" height="16" font="2">impacting the Event_State of the object to which the alerts are Related. Alerts are always </text> <text top="638" left="108" width="685" height="16" font="2">distributed using ConfirmedEventNotification or UnconfirmedEventNotification services with </text> <text top="658" left="108" width="605" height="16" font="2">‘To State’ and ‘From State’ set to NORMAL and an ‘Event Type’ of EXTENDED. </text> <text top="679" left="108" width="5" height="16" font="2"> </text> <text top="700" left="108" width="513" height="16" font="2">Standard 135-2010af-32, in Clause 13.2 preamble, paragraph 5, states: </text> <text top="721" left="108" width="9" height="16" font="2"> </text> <text top="742" left="108" width="696" height="16" font="2">Alert reporting allows any object to provide event reports that are unrelated to the object's event </text> <text top="763" left="108" width="700" height="16" font="2">state and the intrinsic reporting algorithm of the object. Conceptually, when the need for an alert </text> <text top="784" left="108" width="626" height="16" font="2">message is identified by an object, the alert is passed to an Alert Enrollment object for </text> <text top="805" left="108" width="687" height="16" font="2">distribution. Alerts differ from intrinsic reporting and algorithmic reporting in that there are no </text> <text top="826" left="108" width="704" height="16" font="2">standard conditions under which alerts are generated and in that alerts are stateless and cannot be </text> <text top="847" left="108" width="113" height="16" font="2">acknowledged. </text> <text top="868" left="108" width="5" height="16" font="2"> </text> <text top="889" left="108" width="683" height="16" font="2">Standard 135-2010, in Clause 13.8.1.11 and similarly in 13.9.1.11 describes AckRequired in a </text> <text top="910" left="108" width="616" height="16" font="2">ConfirmedEventNotification and UnconfirmedEventNotification request, as follows: </text> <text top="931" left="108" width="5" height="16" font="2"> </text> <text top="952" left="108" width="606" height="16" font="2">This parameter, of type BOOLEAN, shall convey whether this notification requires </text> <text top="973" left="108" width="677" height="16" font="2">acknowledgment (TRUE) or not (FALSE). This parameter shall only be present if the 'Notify </text> <text top="994" left="108" width="295" height="16" font="2">Type' parameter is EVENT or ALARM. </text> <text top="1015" left="108" width="5" height="16" font="2"> </text> <text top="1036" left="108" width="663" height="16" font="2">Standard 135-2010, in Clause 12.21.7 describes the Ack_Required in Notification Class, as </text> <text top="1057" left="108" width="64" height="16" font="2">follows: </text> <text top="1078" left="108" width="5" height="16" font="2"> </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <text top="1120" left="108" width="699" height="14" font="0">Page 2 of 2 ©2013 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="645" height="16" font="2">This property, of type BACnetEventTransitionBits, shall convey three separate flags that </text> <text top="112" left="108" width="629" height="16" font="2">represent whether acknowledgment shall be required in notifications generated for TO-</text> <text top="133" left="108" width="583" height="16" font="2">OFFNORMAL, TO-FAULT, and TO-NORMAL event transitions, respectively. </text> <text top="154" left="108" width="5" height="16" font="2"> </text> <text top="175" left="108" width="679" height="16" font="2">From Access Point object, there is language setting a precedent for ignoring the AckRequired </text> <text top="196" left="108" width="706" height="16" font="2">property in the associated Notification Class. In Clause 12.31.40 for Access Point object it states: </text> <text top="217" left="108" width="5" height="16" font="2"> </text> <text top="238" left="108" width="707" height="16" font="2">The Ack_Required property of the respective Notification Class object is ignored and the </text> <text top="259" left="108" width="663" height="16" font="2">value FALSE is conveyed in the AckRequired parameter of the event notification message. </text> <text top="280" left="108" width="5" height="16" font="2"> </text> <text top="301" left="108" width="615" height="16" font="1">Interpretation: When notifications are generated by an Alert Enrollment object, the </text> <text top="322" left="108" width="648" height="16" font="2">Ack_Required property in the associated Notification Class is ignored. The AckRequired </text> <text top="343" left="108" width="687" height="16" font="2">Boolean field in ConfirmedEventNotification and UnconfirmedEventNotification requests that </text> <text top="364" left="108" width="438" height="16" font="2">are engendered by Alert Enrollment objects is always False. </text> <text top="385" left="108" width="5" height="16" font="2"> </text> <text top="406" left="108" width="297" height="16" font="1">Question: Is this interpretation correct? </text> <text top="427" left="108" width="5" height="16" font="2"> </text> <text top="448" left="108" width="106" height="16" font="1">Answer: Yes </text> <text top="469" left="108" width="5" height="16" font="2"> </text> </page> </pdf2xml> Interpretation 135-2010-14 - May 9, 2013 2013-05-09 00:00:00 http://www.bacnet.org/Interpretations/IC%20135-2010-14.pdf <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pdf2xml SYSTEM "pdf2xml.dtd"> <pdf2xml producer="poppler" version="0.24.5"> <page number="1" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="0" size="16" family="Times" color="#000000"/> <fontspec id="1" size="16" family="Times" color="#000000"/> <fontspec id="2" size="16" family="Times" color="#0000ff"/> <text top="91" left="301" width="320" height="16" font="0">INTERPRETATION IC 135-2010-14 OF </text> <text top="112" left="264" width="395" height="16" font="0">ANSI/ASHRAE STANDARD 135-2010 BACnet® - </text> <text top="133" left="284" width="355" height="16" font="0">A Data Communication Protocol for Building </text> <text top="154" left="325" width="273" height="16" font="0">Automation and Control Networks </text> <text top="175" left="108" width="5" height="16" font="1"> </text> <text top="196" left="355" width="212" height="16" font="1">Approval Date: May 9, 2013 </text> <text top="217" left="108" width="5" height="16" font="1"> </text> <text top="238" left="108" width="229" height="16" font="0">Request from: Gerhard Bahr (</text> <text top="238" left="337" width="219" height="16" font="2">gerhard.bahr@honeywell.com</text> <text top="238" left="555" width="233" height="16" font="1">), Honeywell GmbH, Böblinger </text> <text top="259" left="108" width="195" height="16" font="1">Str. 17, Schönaich 71101. </text> <text top="280" left="108" width="5" height="16" font="1"> </text> <text top="302" left="108" width="646" height="16" font="0">Reference: This request for interpretation refers to ANSI/ASHRAE Standard 135-2010, </text> <text top="323" left="108" width="550" height="16" font="1">Clauses 12.4.9, 12.8.9 and 12.20.9, regarding the Out_Of_Service property. </text> <text top="344" left="108" width="5" height="16" font="1"> </text> <text top="365" left="108" width="663" height="16" font="0">Background: In Clauses 12.4.9 / 12.8.9 / 12.20.9 of the Standard, the meaning of the third </text> <text top="386" left="108" width="636" height="16" font="1">sentence is unclear. Either it does not belong to this section or it is meant to describe an </text> <text top="407" left="108" width="704" height="16" font="1">alternative to the previous sentences. In addition to that the language for the newer Value objects </text> <text top="428" left="108" width="681" height="16" font="1">differs from the above mentioned. Depending on the way the Value object is used, the desired </text> <text top="449" left="108" width="688" height="16" font="1">behavior of the object could be different. Also it is not clear, what is really meant by “software </text> <text top="470" left="108" width="685" height="16" font="1">local to the device”. Applications may be restructured in a way that a producer or consumer of </text> <text top="491" left="108" width="679" height="16" font="1">the value is moved from inside a device to another device. Is the behavior expected to change </text> <text top="512" left="108" width="44" height="16" font="1">then? </text> <text top="533" left="108" width="5" height="16" font="1"> </text> <text top="554" left="108" width="192" height="16" font="1">Language of the standard: </text> <text top="575" left="162" width="26" height="16" font="1">(1) </text> <text top="575" left="216" width="552" height="16" font="1">The Out_Of_Service property, of type BOOLEAN, is an indication whether </text> <text top="595" left="216" width="579" height="16" font="1">(TRUE) or not (FALSE) the Present_Value of the …. Value object is prevented </text> <text top="616" left="216" width="584" height="16" font="1">from being modified by software local to the BACnet device in which the object </text> <text top="637" left="216" width="59" height="16" font="1">resides. </text> <text top="658" left="162" width="26" height="16" font="1">(2) </text> <text top="658" left="216" width="575" height="16" font="1">When Out_Of_Service is TRUE, the Present_Value property may be written to </text> <text top="679" left="216" width="51" height="16" font="1">freely. </text> <text top="700" left="162" width="26" height="16" font="1">(3) </text> <text top="700" left="216" width="586" height="16" font="1">If the Priority_Array and Relinquish_Default properties are present, then writing </text> <text top="721" left="216" width="546" height="16" font="1">to the Present_Value property shall be controlled by the BACnet command </text> <text top="742" left="216" width="301" height="16" font="1">prioritization mechanism. See Clause 19. </text> <text top="763" left="108" width="5" height="16" font="1"> </text> <text top="784" left="108" width="668" height="16" font="1">The language of Clauses 12.37.9 / 12.38.9 / 12.39.9 / 12.40.10 / 12.41.9 / 12.42.9 / 12.43.9 / </text> <text top="805" left="108" width="661" height="16" font="1">12.44.9 / 12.45.9 / 12.46.9 / 12.47.9 (other value objects) differs from the above mentioned </text> <text top="826" left="108" width="61" height="16" font="1">clauses. </text> <text top="847" left="162" width="26" height="16" font="1">(1) </text> <text top="847" left="216" width="576" height="16" font="1">The optional property, of type BOOLEAN, is an indication whether (TRUE) or </text> <text top="868" left="216" width="539" height="16" font="1">not (FALSE) the Present_Value of the …. Value object is decoupled from </text> <text top="889" left="216" width="564" height="16" font="1">software local to the BACnet device in which the object resides that normally </text> <text top="910" left="216" width="494" height="16" font="1">produces the Present_Value as an output or consumes it as an input. </text> <text top="931" left="162" width="26" height="16" font="1">(2) </text> <text top="931" left="216" width="575" height="16" font="1">When Out_Of_Service is TRUE, the Present_Value property may be written to </text> <text top="952" left="216" width="51" height="16" font="1">freely. </text> <text top="973" left="108" width="5" height="16" font="1"> </text> </page> <page number="2" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="3" size="16" family="Times" color="#000000"/> <fontspec id="4" size="13" family="Times" color="#000000"/> <text top="59" left="108" width="120" height="16" font="3">IC 135-2010-14 </text> <text top="1120" left="108" width="699" height="14" font="4">Page 2 of 5 ©2013 ASHRAE. All Rights reserved. </text> <text top="91" left="108" width="654" height="16" font="1">If an external Schedule or Command is writing to the Present_Value, then the only way to </text> <text top="112" left="108" width="691" height="16" font="1">decouple this external data flow is to write with a higher priority, or to perform a local override </text> <text top="133" left="108" width="584" height="16" font="1">within the device (i.e. the Overridden bit is TRUE in the Status_Flags property). </text> <text top="154" left="108" width="5" height="16" font="1"> </text> <text top="175" left="108" width="524" height="16" font="1">Following are a couple of pertinent emails on the topic from BACnet-L: </text> <text top="196" left="108" width="5" height="16" font="1"> </text> <text top="217" left="108" width="664" height="16" font="1">Regrettably the original idea behind Out_Of_Service has become obscure over the years by </text> <text top="238" left="108" width="699" height="16" font="1">several well-meaning, but erroneous, “clarifications” to the standard. There has been an effort in </text> <text top="259" left="108" width="666" height="16" font="1">the past several years to craft language that again clarifies the exact meaning in several new </text> <text top="280" left="108" width="69" height="16" font="1">addenda. </text> <text top="301" left="108" width="5" height="16" font="1"> </text> <text top="322" left="108" width="695" height="16" font="1">Value objects (AV, BV, MSV etc.) have the unique characteristic that they can represent values </text> <text top="343" left="108" width="657" height="16" font="1">known to the device (sort of like “inputs”) or values that we give to the device (sort of like </text> <text top="364" left="108" width="700" height="16" font="1">“outputs”). Picture the value object’s Present_Value as a bucket that contains some value. When </text> <text top="385" left="108" width="658" height="16" font="1">the value object is acting like an input, some process in the device periodically updates the </text> <text top="406" left="108" width="686" height="16" font="1">bucket with a new value, maybe every 10ms or every second, however often it needs to. When </text> <text top="427" left="108" width="689" height="16" font="1">the value is acting like an output, other BACnet devices or humans fill the bucket by writing to </text> <text top="448" left="108" width="672" height="16" font="1">the Present_Value property through BACnet. Again some process periodically (as often as it </text> <text top="468" left="108" width="552" height="16" font="1">wants to) gets the value from the bucket and does something with the value. </text> <text top="489" left="108" width="5" height="16" font="1"> </text> <text top="510" left="108" width="650" height="16" font="1">The operative term is “some process” which is periodically reading from or writing to the </text> <text top="531" left="108" width="590" height="16" font="1">bucket. Keep in mind that the “bucket” is essentially the Present_Value property. </text> <text top="552" left="108" width="5" height="16" font="1"> </text> <text top="573" left="108" width="645" height="16" font="1">The idea of Out_Of_Service is similar for inputs and outputs. If the object is “in service” </text> <text top="594" left="108" width="667" height="16" font="1">(Out_Of_Service=FALSE) then the bucket may be filled by the internal process if the value </text> <text top="615" left="108" width="694" height="16" font="1">object is an input, or the process may use the bucket value if the value object is an output. If the </text> <text top="636" left="108" width="699" height="16" font="1">object is “out of service” (Out_Of_Service=TRUE) then the process may NOT fill the bucket (if </text> <text top="657" left="108" width="683" height="16" font="1">it’s an input) or may NOT use the bucket value (if it’s an output). So Out_Of_Service is like a </text> <text top="678" left="108" width="398" height="16" font="1">switch that connects the bucket to the internal process. </text> <text top="699" left="108" width="5" height="16" font="1"> </text> <text top="720" left="108" width="706" height="16" font="1">On the BACnet side however we read and write to the bucket only. The prioritization mechanism </text> <text top="741" left="108" width="369" height="16" font="1">for commandable values only writes to the bucket. </text> <text top="762" left="108" width="5" height="16" font="1"> </text> <text top="783" left="108" width="695" height="16" font="1">If you have an input object you would normally never write to the Present_Value because a few </text> <text top="804" left="108" width="594" height="16" font="1">milliseconds later the internal process is going to overwrite your value anyway. If </text> <text top="825" left="108" width="686" height="16" font="1">Out_Of_Service is TRUE then this internal refreshing of the bucket is prevented, so you could </text> <text top="846" left="108" width="677" height="16" font="1">theoretically write to Present_Value and your value would stay there. In the case of an output </text> <text top="867" left="108" width="699" height="16" font="1">when you write to the Present_Value AND it’s Out_Of_Service is TRUE, the internal process is </text> <text top="888" left="108" width="687" height="16" font="1">not allowed to look at the bucket so it doesn’t change its behavior and just continues to use the </text> <text top="909" left="108" width="404" height="16" font="1">last value it got before Out_Of_Service became TRUE. </text> <text top="930" left="108" width="5" height="16" font="1"> </text> <text top="951" left="108" width="588" height="16" font="1">So the Clause 12.8.9 language (and similar clauses) is overly broad when it says: </text> <text top="972" left="162" width="626" height="16" font="3">“… the Present_Value of the Binary Value object is prevented from being modified by </text> <text top="992" left="162" width="475" height="16" font="3">software local to the BACnet device in which the object resides.” </text> <text top="1013" left="108" width="5" height="16" font="1"> </text> <text top="1034" left="108" width="317" height="16" font="1">What it should really say is something like: </text> <text top="1055" left="162" width="596" height="16" font="3">“… for input-style Binary Values, the Present_Value of the Binary Value object is </text> <text top="1076" left="162" width="600" height="16" font="3">prevented from being modified by the internal process which normally updates the </text> </page> <page number="3" position="absolute" top="0" left="0" height="1188" width="918"> <fontspec id="5" size="9" family="Times" color="#000000"/> <fontspec id="6" size="16" family="Times" color="#212121"/> <text top="59" left="108" width="120" height="16" font="3">IC 135-2010-14 </text> <text top="1120" left="108" width="699" height="14" font="4">Page 3 of 5 ©2013 ASHRAE. All Rights reserved. </text> <text top="91" left="162" width="643" height="16" font="3">Present_Value in the BACnet device in which the object resides. For output-style Binary </text> <text top="112" left="162" width="639" height="16" font="3">Values, any value written to Present_Value is prevented from being used by the internal </text> <text top="133" left="162" width="559" height="16" font="3">process which normally uses Present_Value to perform the output function.” </text> <text top="153" left="108" width="5" height="16" font="1"> </text> <text top="174" left="108" width="696" height="16" font="1">In your example, the DDC program is separate from the Binary Value itself. This is no different </text> <text top="195" left="108" width="602" height="16" font="1">from a human operator, or control program in another device, that wants to use say </text> <text top="216" left="108" width="682" height="16" font="1">WriteProperty to write to that BV Present_Value. All of these are allowed and should have no </text> <text top="237" left="108" width="692" height="16" font="1">knowledge of the state of Out_Of_Service. Only the internal mechanism of the BV object cares </text> <text top="258" left="108" width="172" height="16" font="1">about Out_Of_Service. </text> <text top="279" left="108" width="5" height="16" font="1"> </text> <text top="300" left="108" width="104" height="16" font="0">David Fisher </text> <text top="321" left="108" width="66" height="16" font="1">PolarSoft</text> <text top="317" left="174" width="9" height="11" font="5">®</text> <text top="321" left="183" width="37" height="16" font="1"> Inc. </text> <text top="342" left="108" width="5" height="16" font="0"> </text> <text top="363" left="108" width="643" height="16" font="1">I agree with everything that David Fisher wrote about Out_Of_Service. I happened to be </text> <text top="384" left="108" width="643" height="16" font="1">answering a question about Out_Of_Service, Reliability, Present_Value, and error codes </text> <text top="405" left="108" width="677" height="16" font="1">yesterday, and I would like to inject some of that here, as in some ways it goes beyond David </text> <text top="426" left="108" width="693" height="16" font="1">Fisher's statements, in case people gain greater understanding from seeing it expressed a couple </text> <text top="447" left="108" width="113" height="16" font="1">different ways. </text> <text top="468" left="108" width="5" height="16" font="1"> </text> <text top="489" left="108" width="653" height="16" font="6">A writable Out_Of_Service property is always recommended, and never required. It is for </text> <text top="510" left="108" width="697" height="16" font="6">purposes of testing only. Several scenarios of behavior are all-but-impossible to bring about "on </text> <text top="531" left="108" width="669" height="16" font="6">demand" in a working device, such as seeing what the system does while Present_Value is a </text> <text top="552" left="108" width="152" height="16" font="6">particular, seldom en</text> <text top="552" left="260" width="115" height="16" font="1">countered value</text> <text top="552" left="374" width="426" height="16" font="6">. It is nice, for purposes of testing only, to make them easy </text> <text top="573" left="108" width="402" height="16" font="6">to bring about, while Out_Of_Service property is True. </text> <text top="594" left="108" width="5" height="16" font="6"> </text> <text top="615" left="108" width="658" height="16" font="6">The main one is to make Reliability property accepts write requests while Out_Of_Service </text> <text top="636" left="108" width="705" height="16" font="6">property is True, but there are also some scenarios regarding values in Present_Value property as </text> <text top="657" left="108" width="559" height="16" font="6">well. Some values you maybe want to return VALUE_OUT_OF_RANGE or </text> <text top="678" left="108" width="672" height="16" font="6">WRITE_ACCESS_DENIED to Write requests if they occur in a working device. But testing </text> <text top="699" left="108" width="623" height="16" font="6">what happens if that *does* become the value can still be a desirable testing scenario. </text> <text top="720" left="108" width="668" height="16" font="6">While Out_Of_Service property is True, is when to let Present_Value take on those "tricky" </text> <text top="741" left="108" width="600" height="16" font="6">values for testing purposes. By doing it while Out_Of_Service property is True, so </text> <text top="762" left="108" width="695" height="16" font="6">that Present_Value is disconnected from being continuously written by any internal process and </text> <text top="783" left="108" width="633" height="16" font="6">from any signals to the outside world, the behavior of the BACnet side of things can be </text> <text top="804" left="108" width="609" height="16" font="6">observed, for testing purposes, while the rest of the system is disconnected from the </text> <text top="825" left="108" width="702" height="16" font="6">consequences of those "tricky" values. Writing Out_Of_Service property as True, is the standard </text> <text top="846" left="108" width="676" height="16" font="6">prescribed means to prevent the device from continuous overwriting those "tricky" values, so </text> <text top="867" left="108" width="223" height="16" font="6">there is time to see the effects. </text> <text top="888" left="108" width="5" height="16" font="6"> </text> <text top="908" left="108" width="671" height="16" font="6">Everything about Priority_Array prioritization and also effects from and upon other BACnet </text> <text top="929" left="108" width="653" height="16" font="6">properties (i.e. Relinquish_Default, Alarm_Values, Event_State) is expected to be just the </text> <text top="950" left="108" width="660" height="16" font="6">same while Out_Of_Service property is True as when Out_Of_Service property is False. If </text> <text top="971" left="108" width="603" height="16" font="6">Present_Value is written with a value of 4 at priority 12 in an object that contains a </text> <text top="992" left="108" width="609" height="16" font="6">Priority_Array, then even while Out_Of_Service property is True, array index 12 of </text> <text top="1013" left="108" width="679" height="16" font="6">the Priority_Array becomes 4. If there is a value in Priority_Array at a priority superior to 12, </text> <text top="1034" left="108" width="681" height="16" font="6">then Present_Value takes on the value from the superior priority, not the value which was just </text> <text top="1055" left="108" width="691" height="16" font="6">written. The 3. statement which Gerhard originally posted is the attempt in the standard to state </text> <text top="1076" left="108" width="704" height="16" font="6">that in an object that has clause 19 command prioritization, the clause 19 command prioritization </text> </page> <page number="4" position="absolute" top="0" left="0" height="1188" width="918"> <text top="59" left="108" width=&quo