desolat / bacnet_interpretations

BACnet Interpretations


A directory of interpretations to the BACnet standard ASHRAE 135.

Forked from ScraperWiki

Contributors desolat

Last run failed with status code 1.

Console output of last run

Injecting configuration and compiling... Injecting scraper and running... http://www.bacnet.org/Interpretations [<Element table at 0x2b41bf0>, <Element table at 0x2b41c50>, <Element table at 0x2b41cb0>] [<Element tr at 0x2b41d10>, <Element tr at 0x2b41d70>, <Element tr at 0x2b41dd0>, <Element tr at 0x2b41e30>] [<Element td at 0x2b41e90>] <td>&#160;<br> 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. <p>To jump to the interpretations for a particular consolidated version of the standard, click below:</p> <a href="#135-2001">135-2001</a><br> <a href="#135-2004">135-2004</a><br> <a href="#135-2008">135-2008</a><br> <a href="#135-2010">135-2010</a><br> <a href="#135-2012">135-2012</a><br> <a href="#135-2016">135-2016</a><br> <br> <a href="#135.1-2019">135.1-2019</a><br> <a name="135-2001"><p><font color="red"><b>Interpretations of 135-2001</b></font></p> <p><a href="IC%20135-2001-1.pdf">Interpretation 135-2001-1 - June 26, 2004</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Addendum b to ANSI/ASHRAE Standard 135-2001, Section 15.8 ReadRange Service.) </i></p> </a><a name="135-2004"><p><font color="red"><b>Interpretations of 135-2004</b></font></p> <p><a href="IC%20135-2004-1.pdf">Interpretation 135-2004-1 - June 26, 2004</a> <i>(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.)</i></p> <p><a href="IC%20135-2004-2.pdf">Interpretation 135-2004-2 - June 26, 2004</a> <i>(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.)</i></p> <p><a href="IC%20135-2004-3.pdf">Interpretation 135-2004-3 - June 26, 2004</a> <i>(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.)</i></p> <p><a href="IC%20135-2004-4.pdf">Interpretation 135-2004-4 - June 26, 2004</a> <i>(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.)</i></p> <p><a href="IC%20135-2004-5.pdf">Interpretation 135-2004-5 - June 26, 2004</a> <i>(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.)</i></p> <p><a href="IC%20135-2004-6.pdf">Interpretation 135-2004-6 - February 5, 2005</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 12.24.8, Exception_Schedule.)</i></p> <p><a href="IC%20135-2004-7.pdf">Interpretation 135-2004-7 - February 5, 2005</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Sections K.5.15 and K.5.16.)</i></p> <p><a href="IC%20135-2004-8.pdf">Interpretation 135-2004-8 - June 25, 2005</a> <i>(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.)</i></p> <p><a href="IC%20135-2004-9.pdf">Interpretation 135-2004-9 - June 25, 2005</a> <i>(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.)</i></p> <p><a href="IC%20135-2004-10.pdf">Interpretation 135-2004-10 - June 25, 2005</a> <i>(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.) </i></p> <p><a href="IC%20135-2004-11.pdf">Interpretation 135-2004-11 - June 25, 2005</a> <i>(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.) </i></p> <p><a href="IC%20135-2004-12.pdf">Interpretation 135-2004-12 - June 25, 2005</a> <i>(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.)</i></p> <p><a href="IC%20135-2004-13.pdf">Interpretation 135-2004-13 - June 25, 2005</a> <i>(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.) </i></p> <p><a href="IC%20135-2004-14.pdf">Interpretation 135-2004-14 - September 28, 2005</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 6.3.2, relating to Network Layer routing.)</i></p> <p><a href="IC%20135-2004-15.pdf">Interpretation 135-2004-15 - September 28, 2005</a> <i>(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.)</i></p> <p><a href="IC%20135-2004-16.pdf">Interpretation 135-2004-16 - June 24, 2006</a> <i>(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 Reliability properties.)</i></p> <p><a href="IC%20135-2004-17.pdf">Interpretation 135-2004-17 - April 24, 2006</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 12.25.14, related to Log_Buffer.)</i></p> <p><a href="IC%20135-2004-18.pdf">Interpretation 135-2004-18 - January 21, 2006</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 12.25.9, related to Log_Interval.)</i></p> <p><a href="IC%20135-2004-18.pdf">Interpretation 135-2004-18 - January 21, 2006</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 12.25.9, related to Log_Interval.)</i></p> <p><a href="IC%20135-2004-19.pdf">Interpretation 135-2004-19 - January 27, 2007</a> <i>(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.)</i></p> <p><a href="IC%20135-2004-20.pdf">Interpretation 135-2004-20 - January 27, 2007</a> <i>(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.)</i></p> <p><a href="IC%20135-2004-21.pdf">Interpretation 135-2004-21 - January 27, 2007</a> <i>(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.)</i></p> <p><a href="IC%20135-2004-22.pdf">Interpretation 135-2004-22 - April 25, 2007</a> <i>(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.)</i></p> <p><a href="IC%20135-2004-23.pdf">Interpretation 135-2004-23 - June 21, 2008</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 13.2 relating to intrinsic reporting.)</i></p> <p><a href="IC%20135-2004-24.pdf">Interpretation 135-2004-24 - June 21, 2008</a> <i>(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.)</i></p> <p><a href="IC%20135-2004-25.pdf">Interpretation 135-2004-25 - June 21, 2008</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Sections 13.2 and 13.3 relating to fault event reporting.)</i></p> <p><a href="IC%20135-2004-26.pdf">Interpretation 135-2004-26 - September 17, 2008</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 13.11.1.1.5 regarding Priority Filter.)</i></p> <p><a href="IC%20135-2004-27.pdf">Interpretation 135-2004-27 - September 17, 2008</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2004, Section 21 relating to BACnetEventParameters 'buffer-ready' choice.)</i></p> <p><a href="IC%20135-2004-28.pdf">Interpretation 135-2004-28 - September 17, 2008</a> <i>(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.)</i></p> <p><a href="IC%20135-2004-29.pdf">Interpretation 135-2004-29 - January 24, 2009</a> <i>(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.)</i></p> </a><a name="135-2008"><p><font color="red"><b>Interpretations of 135-2008</b></font></p> <p><a href="IC%20135-2008-1.pdf">Interpretation 135-2008-1 - June 20, 2009</a> <i>(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.)</i></p> <p><a href="IC%20135-2008-2.pdf">Interpretation 135-2008-2 - June 20, 2009</a> <i>(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.)</i></p> <p><a href="IC%20135-2008-3.pdf">Interpretation 135-2008-3 - January 23, 2010</a> <i>(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.)</i></p> <p><a href="IC%20135-2008-4.pdf">Interpretation 135-2008-4 - January 23, 2010</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2008, Section 12.13.7, File Object Modification_Date property value.)</i></p> <p><a href="IC%20135-2008-5.pdf">Interpretation 135-2008-5 - May 28, 2010</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2008 relating to Date and Time.)</i></p> <p><a href="IC%20135-2008-6.pdf">Interpretation 135-2008-6 - October 28, 2010</a> <i>(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.)</i></p> <p><a href="IC%20135-2008-7.pdf">Interpretation 135-2008-7 - October 28, 2010</a> <i>(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.)</i></p> <p><a href="IC%20135-2008-8.pdf">Interpretation 135-2008-8 - October 28, 2010</a> <i>(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.)</i></p> <p><a href="IC%20135-2008-9.pdf">Interpretation 135-2008-9 - October 28, 2010</a> <i>(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.)</i></p> <p><a href="IC%20135-2008-10.pdf">Interpretation 135-2008-10 - October 28, 2010</a> <i>(Refers to the requirements presented in Addendum g to ANSI/ASHRAE Standard 135-2008, Section 24.16.1, relating to APDU and NPDU sizes.)</i></p> <p><a href="IC%20135-2008-11.pdf">Interpretation 135-2008-11 - October 28, 2010</a> <i>(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.)</i></p> <p><a href="IC%20135-2008-12.pdf">Interpretation 135-2008-12 - October 28, 2010</a> <i>(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.)</i></p> <p><a href="IC%20135-2008-13.pdf">Interpretation 135-2008-13 - January 29, 2011</a> <i>(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.)</i></p> <p><a href="IC%20135-2008-14.pdf">Interpretation 135-2008-14 - January 29, 2011</a> <i>(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.)</i></p> <p><a href="IC%20135-2008-15.pdf">Interpretation 135-2008-15 - January 29, 2011</a> <i>(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.)</i></p> <p><a href="IC%20135-2008-16.pdf">Interpretation 135-2008-16 - January 29, 2011</a> <i>(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.)</i></p> <p><a href="IC%20135-2008-17.pdf">Interpretation 135-2008-17 - January 29, 2011</a> <i>(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.)</i></p> <p><a href="IC%20135-2008-18.pdf">Interpretation 135-2008-18 - January 29, 2011</a> <i>(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.)</i></p> <p><a href="IC%20135-2008-19.pdf">Interpretation 135-2008-19 - January 29, 2011</a> <i>(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".)</i></p> <p><a href="IC%20135-2008-20.pdf">Interpretation 135-2008-20 - May 25, 2011</a> <i>(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.)</i></p> <p><a href="IC%20135-2008-21.pdf">Interpretation 135-2008-21 - May 25, 2011</a> <i>(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.)</i></p> </a><a name="135-2010"><p><font color="red"><b>Interpretations of 135-2010</b></font></p> <p><a href="IC%20135-2010-1.pdf">Interpretation 135-2010-1 - May 25, 2011</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2010, Clause 12.24, relating to Schedule Object Type.)</i></p> <p><a href="IC%20135-2010-2.pdf">Interpretation 135-2010-2 - October 27, 2011</a> <i>(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).)</i></p> <p><a href="IC%20135-2010-3.pdf">Interpretation 135-2010-3 - October 27, 2011</a> <i>(Refers to the requirements presented in ANSI/ASHRAE 135-2010, Clause 12.11.50 (Device Object Type, Interval_Offset).)</i></p> <p><a href="IC%20135-2010-4.pdf">Interpretation 135-2010-4 - July 16, 2012</a> <i>(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.)</i></p> <p><a href="IC%20135-2010-5.pdf">Interpretation 135-2010-5 - July 16, 2012</a> <i>(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.)</i></p> <p><a href="IC%20135-2010-6.pdf">Interpretation 135-2010-6 - June 13, 2012</a> <i>(Refers to the requirements presented in ANSI/ASHRAE 135-2010, Clause 15.7.2, relating to the special property OPTIONAL.)</i></p> <p><a href="IC%20135-2010-7.pdf">Interpretation 135-2010-7 - June 13, 2012</a> <i>(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.)</i></p> <p><a href="IC%20135-2010-8.pdf">Interpretation 135-2010-8 - November 7, 2012</a> <i>(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.)</i></p> <p><a href="IC%20135-2010-9.pdf">Interpretation 135-2010-9 - November 7, 2012</a> <i>(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.)</i></p> <p><a href="IC%20135-2010-10.pdf">Interpretation 135-2010-10 - November 7, 2012</a> <i>(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.)</i></p> <p><a href="IC%20135-2010-11.pdf">Interpretation 135-2010-11 - November 7, 2012</a> <i>(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.)</i></p> <p><a href="IC%20135-2010-12.pdf">Interpretation 135-2010-12 - January 26, 2013</a> <i>(Refers to ANSI/ASHRAE Standard 135-2010, Clause 12, regarding the Object_Identifier property and the instance number 4194303.) </i></p> <p><a href="IC%20135-2010-13.pdf">Interpretation 135-2010-13 - January 26, 2013</a> <i>(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.)</i></p> <p><a href="IC%20135-2010-14.pdf">Interpretation 135-2010-14 - May 9, 2013</a> <i>(Refers to ANSI/ASHRAE Standard 135-2010, Clauses 12.4.9, 12.8.9 and 12.20.9, regarding the Out_Of_Service property.)</i></p> </a><a name="135-2012"><p><font color="red"><b>Interpretations of 135-2012</b></font></p> <p><a href="IC%20135-2012-1.pdf">Interpretation 135-2012-1 - May 9, 2013</a> <i>(Refers to the requirements presented in ANSI/ASHRAE 135-2012, Clause 12.25.14, relating to recording time-change events in trendlog logbuffer.)</i></p> <p><a href="IC%20135-2012-2.pdf">Interpretation 135-2012-2 - June 22, 2013</a> <i>(Refers to ANSI/ASHRAE Standard 135-2012, Clause 19, regarding the Command Prioritization.)</i></p> <p><a href="IC%20135-2012-3.pdf">Interpretation 135-2012-3 - June 22, 2013</a> <i>(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).)</i></p> <p><a href="IC%20135-2012-4.pdf">Interpretation 135-2012-4 - June 22, 2013</a> <i>(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.)</i></p> <p><a href="IC%20135-2012-5.pdf">Interpretation 135-2012-5 - June 22, 2013</a> <i>(Refers to ANSI/ASHRAE Standard 135-2012, Clauses 12.4.9, 12.8.9 and 12.20.9, regarding the Out_Of_Service property.)</i></p> <p><a href="IC135-2012-6.pdf">Interpretation 135-2012-6 - November 6, 2013</a> <i>(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.)</i></p> <p><a href="IC135-2012-7.pdf">Interpretation 135-2012-7 - November 6, 2013</a> <i>(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.)</i></p> <p><a href="IC135-2012-8.pdf">Interpretation 135-2012-8 - November 6, 2013</a> <i>(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.)</i></p> <p><a href="IC135-2012-9.pdf">Interpretation 135-2012-9 - November 6, 2013</a> <i>(Refers to the requirements presented in ANSI/ASHRAE 135-2012, Clause 12, relating to the execution of alarming related messages containing timestamps with wildcards.)</i></p> <p><a href="IC135-2012-10.pdf">Interpretation 135-2012-10 - January 18, 2014</a> <i>(Refers to the requirements presented in ANSI/ASHRAE 135-2012, Clause 15.8.2, relating to ReadRange executed with a Range parameter of 'byTime'.)</i></p> <p><a href="IC135-2012-11.pdf">Interpretation 135-2012-11 - January 18, 2014</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clause 12.25.14, regarding all logging objects (TL, TLM, EL).)</i></p> <p><a href="IC135-2012-12.pdf">Interpretation 135-2012-12 - April 9, 2014</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clause 5, regarding all Property MaxSegmentsAccepted, Client State Machine.)</i></p> <p><a href="IC135-2012-13.pdf">Interpretation 135-2012-13 - January 24, 2015</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clause 19.1.3.3, regarding file objects using record-access.)</i></p> <p><a href="IC135-2012-14.pdf">Interpretation 135-2012-14 - January 24, 2015</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clause 19.1.3.3, regarding restoring the configuration files.)</i></p> <p><a href="IC135-2012-15.pdf">Interpretation 135-2012-15 - January 24, 2015</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clause 15.8, regarding ReadRange Service, by position with negative count.)</i></p> <p><a href="IC135-2012-16.pdf">Interpretation 135-2012-16 - April 30, 2015</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clause 13.7, regarding UnconfirmedCOVNotification Service, K1-11 BIBB DS-COV-A.)</i></p> <p><a href="IC135-2012-17.pdf">Interpretation 135-2012-17 - April 30, 2015</a> <i>(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.)</i></p> <p><a href="IC135-2012-18.pdf">Interpretation 135-2012-18 - November 4, 2015</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clause 13.14, regarding SubscribeCOV service with indefinite lifetime.)</i> </p> <p><a href="IC135-2012-19.pdf">Interpretation 135-2012-19 - November 4, 2015</a> <i>(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.)</i> </p> <p><a href="IC135-2012-20.pdf">Interpretation 135-2012-20 - April 19, 2016</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2012, Clause 12.11.39, regarding Optionality of COV_Increment in Active_COV_Subscriptions.)</i> </p> </a><a name="135-2016"><p><font color="red"><b>Interpretations of 135-2016</b></font></p> <p><a href="IC135-2016-1.pdf">Interpretation 135-2016-1 - July 21, 2016</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause 12.56, regarding the Network Port object.)</i> </p> <p><a href="IC135-2016-2.pdf">Interpretation 135-2016-2 - October 25, 2016</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause 13.3.6, regarding the direct transitions.)</i> </p> <p><a href="IC-135-2016-3.pdf">Interpretation 135-2016-3 - June 26, 2017</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clauses H.2.2.1 Offline Devices and H.2.3.2 Offline Devices, regarding consistent BACnet gateway behavior for offline devices.)</i> </p> <p><a href="IC-135-2016-4.pdf">Interpretation 135-2016-4 - June 26, 2017</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause W.5.3 The .auth Data Item, regarding the format of public keys.)</i> </p> <p><a href="IC-135-2016-5.pdf">Interpretation 135-2016-5 - October 24, 2017</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause 12.12.21, regarding Event Enrollment Reliability property.)</i> </p> <p><a href="IC-135-2016-6.pdf">Interpretation 135-2016-6 - October 24, 2017</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, regarding the exact meaning of some defined units in the BACnet standard.)</i> </p> <p><a href="IC-135-2016-7.pdf">Interpretation 135-2016-7 - October 24, 2017</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause 16.1, regarding DeviceCommunicationControl for BACnet Router.)</i> </p> <p><a href="IC-135-2016-8.pdf">Interpretation 135-2016-8 - October 24, 2017</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016 regarding adding properties from future protocol revisions.)</i> </p> <p><a href="IC-135-2016-9.pdf">Interpretation 135-2016-9 - October 24, 2017</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause K.2.4 AE-ACK-A, and Clause K.2.2 AE-N-I-B, regarding date and time synchronization requirements.)</i> </p> <p><a href="IC-135-2016-10.pdf">Interpretation 135-2016-10 - April 17, 2018</a> <i>(Refers to the requirements presented in Clause L.7 Miscellaneous Profiles, regarding B-BBMD, B-RTR, DS-WP-B, and WriteProperty Execution.)</i> </p> <p><a href="IC-135-2016-11.pdf">Interpretation 135-2016-11 - April 17, 2018</a> <i>(Refers to the requirements presented in Clauses K and L regarding BIBBs and Device Profiles and how they relate to protocol revisions.)</i> </p> <p><a href="IC-135-2016-12.pdf">Interpretation 135-2016-12 - July 11, 2018</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause 12.3.12, regarding Present_Value property.)</i> </p> <p><a href="IC-135-2016-13.pdf">Interpretation 135-2016-13 - April 10, 2019</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Figure 6-12, regarding router discovery.)</i> </p> <p><a href="IC-135-2016-14.pdf">Interpretation 135-2016-14 - April 12, 2019</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause 13.15.1.1.6, regarding the COV Increment parameter of the SubscribeCOVProperty service.)</i> </p> <p><a href="IC-135-2016-15.pdf">Interpretation 135-2016-15 - June 20, 2019</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clauses 13.2.2.1 and 13.3, regarding Transitions out of FAULT while an OFFNORMAL condition exists.)</i> </p> <p><a href="IC-135-2016-16.pdf">Interpretation 135-2016-16 - June 20, 2019</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause K.1.12, regarding devices claiming conformance to DS-COV-B.)</i> </p> <p><a href="IC-135-2016-17.pdf">Interpretation 135-2016-17 - June 20, 2019</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause 12.56 and Tables 12.71 and 12.72, regarding Required vs Optional properties of the Network Port object type.)</i> </p> <p><a href="IC-135-2016-18.pdf">Interpretation 135-2016-18 - June 20, 2019</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clauses 13.1 and 13.15.1.1.6, regarding COV_Increment for numeric properties.)</i> </p> <p><a href="IC-135-2016-19.pdf">Interpretation 135-2016-19 - October 30, 2019</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause 12.56, regarding activating changes.)</i> </p> <p><a href="IC-135-2016-20.pdf">Interpretation 135-2016-20 - October 30, 2019</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clauses 5.2.1.2, 9.7.1 and 19.4, regarding the requirements for devices to know the Maximum Conveyable APDU to remote networks.)</i> </p> <p><a href="IC-135-2016-21.pdf">Interpretation 135-2016-21 - October 30, 2019</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause 13.3.1, regarding BITSTRING Object.)</i> </p> <p><a href="IC-135-2016-22.pdf">Interpretation 135-2016-22 - January 14, 2019</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Addendum bl, Clause 12.18.10, regarding Multi-state Input object when the Out_Of_Service property is TRUE and the resulting requirements of the Reliability and Status_Flags properties and the fault algorithm.)</i> </p> <p><a href="IC-135-2016-23.pdf">Interpretation 135-2016-23 - February 1, 2020</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause 12.56 and Table 12.71, regarding the presence of optional properties.)</i> </p> <p><a href="IC-135-2016-24.pdf">Interpretation 135-2016-24 - February 1, 2020</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause 12.57, regarding writing when State_Change_Values intends to relinquish on all transitions from RUNNING.)</i> </p> <p><a href="IC-135-2016-25.pdf">Interpretation 135-2016-25 - February 1, 2020</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause 12.56.11 Network_Number.)</i> </p> <p><a href="IC-135-2016-26.pdf">Interpretation 135-2016-26 - July 6, 2020</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, regarding the ability to read property values.)</i> </p> <p><a href="IC-135-2016-27.pdf">Interpretation 135-2016-27 - July 6, 2020</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016 Addendum bi, regarding the specified type of the Member_Of property.)</i> </p> <p><a href="IC-135-2016-28.pdf">Interpretation 135-2016-28 - July 6, 2020</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135-2016, Clause 12.56.13 Changes_Pending.)</i> </p> </a><a name="135.1-2019"><p><font color="red"><b>Interpretations of 135.1-2019</b></font></p> <p><a href="IC-135.1-2019-1.pdf">Interpretation 135.1-2019-1 - July 6, 2020</a> <i>(Refers to the requirements presented in ANSI/ASHRAE Standard 135.1-2013, Clause 13.5.3, regarding slave proxy functionality.)</i> </p> </a></td>&#13; 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"><b>INTERPRETATION IC 135-2001-1 OF </b></text> <text top="110" left="263" width="368" height="19" font="2"><b>ANSI/ASHRAE STANDARD 135-2001 BACnet</b></text> <text top="107" left="630" width="29" height="23" font="2"><b> - </b></text> <text top="131" left="284" width="355" height="19" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="152" left="325" width="273" height="19" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-1 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b><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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2004-2 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b><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"><b>Reference:</b> 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"><b>Background:</b> The GetEnrollmentSummary service includes a parameter, Priority, which </text> <text top="429" left="108" width="648" height="16" font="1">&#34;indicates the priority of notifications generated by the object.&#34; 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2004-3 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-4 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-5OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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 &#34;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.&#34;</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"><b>INTERPRETATION IC 135-2004-6 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-7 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-8 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer: </b>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"><b>Comments: </b>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"><b>INTERPRETATION IC 135-2004-9 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> The BACnet Standard uses at numerous places the expression &#34;object&#34;. 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 &#34;These properties are required if the object supports </text> <text top="471" left="108" width="695" height="16" font="1">intrinsic reporting.&#34; 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"><b>Interpretation:</b> The expression &#34;object&#34; 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> Throughout the standard, &#34;object type&#34; 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 &#34;object&#34; 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"><b>INTERPRETATION IC 135-2004-10 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> (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"><b>INTERPRETATION IC 135-2004-11 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-12 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-13 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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 &#34;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.&#34; </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: &#34;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.&#34; </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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments: </b>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.<b> </b></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"><b>INTERPRETATION IC 135-2004-14 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> The &#34;network of origin&#34; in Section 6.3.2, Broadcast Messages, from the </text> <text top="576" left="108" width="683" height="16" font="1">sentence &#34;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&#34;, 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-15 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-16 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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 &#34;fault&#34; 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 &#34;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&#34; </text> <text top="701" left="108" width="694" height="16" font="1">contradicts the sentence &#34;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.&#34; </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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-17 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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, &#34;these choices represent data values read from the </text> <text top="450" left="108" width="673" height="16" font="1">monitored object and property&#34;. Because the word &#34;represent&#34; 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer: </b>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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-18 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer: </b>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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-18 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer: </b>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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-19 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer: </b> 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"><b>Comments:</b> </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"><i>In the case where the property being written to is commandable, the request shall result </i></text> <text top="939" left="135" width="648" height="16" font="4"><i>in a Reject-PDU being returned. If the property being written to is not commandable, the </i></text> <text top="959" left="135" width="544" height="16" font="4"><i>device has the option to ignore the invalid priority or return a Reject-PDU.</i></text> <text top="961" left="679" width="4" height="14" font="5"><i> </i></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"><i>If, in the process of carrying out the modification of the indicated properties in the order </i></text> <text top="1061" left="135" width="603" height="16" font="4"><i>specified in the 'List of Write Access Specifications', a property is encountered that </i></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"><i>cannot be modified, the responding BACnet-user shall issue a 'Result(-)' response </i></text> <text top="112" left="135" width="626" height="16" font="4"><i>primitive indicating the reason for the failure. The result of this service shall be either </i></text> <text top="133" left="135" width="614" height="16" font="4"><i>that all of the specified properties or only the properties up to, but not including, the </i></text> <text top="153" left="135" width="594" height="16" font="4"><i>property specified in the 'First Failed Write Attempt' parameter were successfully </i></text> <text top="174" left="135" width="72" height="16" font="4"><i>modified. </i></text> <text top="204" left="108" width="681" height="16" font="1">The intent is <i>not</i> 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"><i>In the case where the property being written to is commandable, it is a local matter as to </i></text> <text top="297" left="135" width="590" height="16" font="4"><i>whether the request shall cause a Reject PDU to be returned or cause a Result(-) </i></text> <text top="317" left="135" width="172" height="16" font="4"><i>response to be issued. </i></text> <text top="343" left="135" width="646" height="16" font="4"><i>If the property being written to is not commandable, it is a local matter as to whether the </i></text> <text top="363" left="135" width="103" height="16" font="4"><i>request shall: </i></text> <text top="384" left="135" width="374" height="22" font="1">− <i>Be executed, ignoring the invalid Priority value </i></text> <text top="411" left="135" width="293" height="22" font="1">− <i>Result in the return of a Reject PDU </i></text> <text top="437" left="135" width="314" height="22" font="1">− <i>Cause a Result(-) response to be issued </i></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"><b>INTERPRETATION IC 135-2004-20 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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 &#34;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.&#34; </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 &#34;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.&#34; </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 &#34;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 &#34;...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.&#34;. </text> <text top="890" left="108" width="5" height="16" font="1"> </text> <text top="911" left="108" width="644" height="16" font="2"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> </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"><b>INTERPRETATION IC 135-2004-21 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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">&#34;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.&#34; </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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments: </b>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.<b> </b></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"><b>INTERPRETATION IC 135-2004-22 OF </b></text> <text top="113" left="263" width="367" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="1">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-23 OF </b></text> <text top="113" left="263" width="367" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet</b></text> <text top="107" left="630" width="29" height="22" font="2">®<b> - </b></text> <text top="134" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="155" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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 &#34;intrinsic reporting&#34;). </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 &#34;Intrinsic Reporting&#34; states: </text> <text top="492" left="135" width="622" height="16" font="2">&#34;….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…&#34; </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">&#34;…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….&#34; </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">&#34;… 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…&#34; </text> <text top="743" left="135" width="616" height="16" font="2">Considering citations A, B and C we conclude, that the expression &#34; 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..&#34; 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">&#34;.. 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…&#34; </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">&#34; 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.&#34; </text> <text top="1016" left="135" width="678" height="16" font="2">None of these citations gives any indication, that the &#34;changes of status internal to the object&#34; </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">&#34;…Proprietary intrinsic reporting shall use the services described in 13.8 and 13.9….&#34; </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 &#34;proprietary intrinsic reporting&#34; 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 &#34;internal status change&#34; 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-24 OF </b></text> <text top="112" left="270" width="382" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet - </b></text> <text top="133" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2004-25 OF </b></text> <text top="112" left="270" width="382" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><i>This parameter, of type BACnetNotificationParameters, shall convey a set of values </i></text> <text top="567" left="162" width="245" height="16" font="4"><i>relevant to the particular event… </i></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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-26 OF </b></text> <text top="112" left="264" width="395" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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">&#34;… 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.&#34; </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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-27 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-28 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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 &#34;invalid tag&#34; in an APDU with no clear definition of what makes a tag &#34;invalid&#34; -- </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 &#34;Fixed Part of BACnet APDUs&#34;, 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, &#34;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 --&gt; or the requested service from being provided. &lt;--&#34; (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 &#34;pre-parsers&#34; </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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2004-29 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2004 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> The Standard notes that once &#34;device B&#34; 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 &#34;device B&#34; </text> <text top="428" left="108" width="639" height="16" font="2">then &#34;device A&#34; must create these objects in &#34;device B&#34; 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"><b>Interpretation:</b> &#34;Device A&#34; 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2008-1 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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 &#34;defines the </text> <text top="575" left="108" width="691" height="16" font="2">number of states the Present_Value may have.&#34;, 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2008-2 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2008-3 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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 &#34;count </text> <text top="491" left="108" width="205" height="16" font="2">of the number of elements&#34;. </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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2008-4 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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 &#34;any&#34; or &#34;don't care&#34;, 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"><b>Interpretation:</b> 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 &#34;don't know&#34;, 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2008-5 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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 &#34;local&#34; or &#34;current&#34; or &#34;UTC&#34;, 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 &#34;local&#34; 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2008-6 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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 <i>l </i>to ANSI/ASHRAE Standard 135-2008, Section 1 and </text> <text top="344" left="108" width="694" height="16" font="2">ANSI/ASHRAE Addendum <i>v</i> 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"><b>Background:</b> </text> <text top="428" left="108" width="653" height="16" font="2">In Addendum 135-2008<i>l</i> 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 &amp; 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-2008<i>v</i> 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"><b>Interpretation:</b> 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-2008<i>v</i> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2008-7 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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) &amp; (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"><b>Interpretation:</b> The existence of Conditions (c) &amp; (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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2008-8 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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 &amp; 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> I would assume that in Figure 24-2, in the &#34;NSDU&#34; section, there would be a </text> <text top="491" left="108" width="462" height="16" font="2">two-byte vendor identifier following the &#34;Message-Type&#34; 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2008-9 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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 &amp; 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"><b>Reference:</b> 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"><b>Background:</b> </text> <text top="407" left="108" width="5" height="16" font="2"> </text> <text top="428" left="108" width="454" height="16" font="1"><b>12.X.15 Do_Not_Hide</b> (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"><b>24.16.2 Selecting Error Codes </b>(page 47 of Addendum g to 135-2008) states &#34;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.&#34; </text> <text top="596" left="108" width="5" height="16" font="2"> </text> <text top="617" left="108" width="702" height="16" font="1"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2008-10 OF </b></text> <text top="112" left="264" width="395" height="16" font="0"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="0"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="0"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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 &amp; 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation No.1:</b> 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"><b>Question No.1:</b> 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"><b>Answer No.1:</b> 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"><b>Interpretation No.2:</b> 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"><b>Question No.2:</b> 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"><i>IC 135-2008-10 </i></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"><b>Answer No.2:</b> 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"><b>Interpretation No.3: </b>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"><b>Question No.3:</b> 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"><b>Answer No.3:</b> 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"><b>Interpretation No.4: </b>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"><b>Question No.4:</b> 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"><b>Answer No.4:</b> 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"><b>Comments: </b></text> <text top="471" left="108" width="5" height="16" font="0"><b> </b></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"><b>INTERPRETATION IC135-2008-11 OF </b></text> <text top="112" left="203" width="517" height="16" font="0"><b>ANSI/ASHRAE STANDARD ADDENDUM 135-2008p BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="0"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="0"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> Section 13.3.X (page 10 of Addendum p to 135-2008) describes: &#34;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.&#34; </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 &#34;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&#34; 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"><b>Interpretation No.1: </b>If at least <b>one flag</b> 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"><b>Question No.1:</b> 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"><b>Answer No.1: </b>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"><b>Comments No.1: </b> 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"><b>Interpretation No.2:</b> If the &#34;set&#34; has the value of TRUE and <b>the set</b> 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"><b>Question No.2:</b> 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"><b>Answer No.2:</b> 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"><i>IC 135-2008-11 </i></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"><b>Comments No.2:</b> It is defined to be the set of &#34;selected flags that are true&#34;. 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 &#34;selected flags that are </text> <text top="133" left="108" width="165" height="16" font="1">true&#34; has not changed.<b> </b></text> <text top="154" left="108" width="5" height="16" font="1"> </text> <text top="175" left="108" width="703" height="16" font="0"><b>Interpretation No.3:</b> 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"><b>Question No.3:</b> 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"><b>Answer No.3: </b>No. When the set of &#34;selected flags that are true&#34; 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.<b> </b></text> <text top="407" left="108" width="5" height="16" font="1"> </text> <text top="428" left="108" width="186" height="16" font="0"><b>Comments No.3:</b> 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"><b>INTERPRETATION IC 135-2008-12 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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), &#34;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&#34; and 12.1.11, (the Scale property), &#34;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.&#34; </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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2008-13 OF </b></text> <text top="112" left="264" width="395" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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">&#34;... 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. …&#34; </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">&#34;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.&#34; </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"><i>IC 135-2008-13 </i></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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2008-14 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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 &amp; 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"><b>Reference:</b> 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"><b>Background:</b> Clause 24.2.11 states &#34;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.&#34; </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 &#34;the entire field&#34; 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2008-15 OF </b></text> <text top="112" left="264" width="395" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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 &amp; 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"><b>Reference:</b> 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"><b>Background:</b> Clause 24.2.3 states &#34;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).&#34; </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 &#34;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.&#34; </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 &#34;the General-Network-Access key&#34; 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 &#34;unknownKey&#34; or </text> <text top="952" left="108" width="664" height="16" font="1">&#34;unknownKeyRevision&#34; 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. &#34;unknownKey&#34; 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 &#34;General-Network-Access&#34;, 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"><i>IC 135-2008-15 </i></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. &#34;unknownKeyRevision&#34; 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"><b>Interpretation No.1:</b> 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"><b>Question No.1:</b> 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"><b>Answer No.1:</b> 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"><b>Interpretation No.2:</b> 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).<b> </b></text> <text top="533" left="108" width="5" height="16" font="2"><b> </b></text> <text top="554" left="108" width="337" height="16" font="2"><b>Question No.2:</b> 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"><b>Answer No.2:</b> 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"><b> </b></text> <text top="659" left="108" width="703" height="16" font="2"><b>Interpretation No.3:</b> 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.<b> </b></text> <text top="701" left="108" width="5" height="16" font="2"><b> </b></text> <text top="723" left="108" width="337" height="16" font="2"><b>Question No.3:</b> 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"><b>Answer No.3:</b> No (the unknownKeyRevision error handling is applicable to this case). </text> <text top="786" left="108" width="5" height="16" font="2"><b> </b></text> <text top="807" left="108" width="191" height="16" font="2"><b>Comments:</b> See answers. </text> <text top="828" left="108" width="5" height="16" font="2"><b> </b></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"><b>INTERPRETATION IC 135-2008-16 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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 &amp; 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2008-17 OF </b></text> <text top="112" left="264" width="395" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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 &amp; 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"><b>Reference:</b> 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"><b>Background:</b> 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 &#34;preferred&#34; </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 &#34;other methods for </text> <text top="554" left="108" width="304" height="16" font="1">determining time are described below...&#34;) </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 &#34;next special message ID&#34; 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"><b>Interpretation No.1:</b> The &#34;preferred&#34; vs. &#34;other&#34; has to do with whether a device is able to store </text> <text top="952" left="108" width="659" height="16" font="1">the &#34;next special Message ID&#34; 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"><b>Question No.1:</b> 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"><b>Answer No.1:</b> 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"><i>IC 135-2008-17 </i></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"><b>Interpretation No.2:</b> 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 &#34;preferred&#34; as well as the &#34;other&#34; 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"><b>Question No.2:</b> 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"><b>Answer No.2:</b> 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"><b>INTERPRETATION IC 135-2008-18 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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 &amp; 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation No.1:</b> 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"><b>Question No.1:</b> 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"><i>IC 135-2008-18 </i></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"><b>Answer No.1:</b> 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"><b>Interpretation No.2:</b> 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"><b>Question No.2:</b> 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"><b>Answer No.2:</b> 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"><b>Interpretation No.3:</b> 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"><b>Question No.3:</b> 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"><b>Answer No.3:</b> 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"><b>INTERPRETATION IC 135-2008-19 OF </b></text> <text top="112" left="264" width="395" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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 &amp; 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"><b>Reference:</b> 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 &#34;know a key&#34;. </text> <text top="386" left="108" width="5" height="16" font="1"> </text> <text top="407" left="108" width="683" height="16" font="2"><b>Background:</b> Clause 24.3.3.3 states &#34;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&#34; </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 &#34;know&#34; 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 &#34;know&#34; 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 &#34;knows&#34; 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 &#34;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.&#34; 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 &#34;knowing&#34; 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"><b>Interpretation:</b> The returned list of &#34;known&#34; 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"><i>IC 135-2008-19 </i></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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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.<b> </b></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"><b>INTERPRETATION IC 135-2008-20 OF </b></text> <text top="112" left="264" width="395" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2008-21 OF </b></text> <text top="112" left="264" width="395" height="16" font="2"><b>ANSI/ASHRAE STANDARD 135-2008 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="2"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="2"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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, &#34;The local date and time when the record was collected.&#34; 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"><i>IC 135-2008-21 </i></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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2010-1 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2010 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>12.24.4 Present_Value </b></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"><i>IC 135-2010-1 </i></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"><b>12.24.7 Weekly_Schedule (first paragraph) </b></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"><b>12.24.8 Exception_Schedule (second paragraph) </b></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"><b>12.24.9 Schedule_Default (first paragraph) </b></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"><b>Interpretation: </b>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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments: </b>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"><b>INTERPRETATION IC 135-2010-2 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2010 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b>INTERPRETATION IC 135-2010-3 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2010 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments: </b>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"><b>INTERPRETATION IC 135-2010-4 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2010 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation No.1:</b> 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"><i>IC 135-2010-4 </i></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"><b>Question No.1:</b> 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"><b>Answer No.1:</b> 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"><b>Comments: </b>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.<b> </b></text> <text top="218" left="108" width="5" height="16" font="2"> </text> <text top="239" left="108" width="690" height="16" font="1"><b>Interpretation No.2:</b> 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 &#34;receive&#34; 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"><b>Question No.2:</b> 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"><b>Answer No.2:</b> 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"><b>INTERPRETATION IC 135-2010-5 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2010 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>K.4.3 BIBB - Trending-Viewing and Modifying Trends External-B (T-VMT-E-B) </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"><b>Interpretation No.1:</b> 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"><b>Question No.1:</b> 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"><b>Answer No.1:</b> 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"><b>Interpretation No.2:</b> 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"><b>Question No.2:</b> 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"><i>IC 135-2010-5 </i></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"><b>Answer No.2:</b> 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"><b>INTERPRETATION IC 135-2010-6 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2010 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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 &#34;O&#34; 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b> </b></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"><b>INTERPRETATION IC 135-2010-7 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2010 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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, &#34;<b>Change of Value Reporting</b>&#34; 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"><b>Background:</b> </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"><b>Object COV Reporting </b></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"><b>Property COV Reporting </b></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 <b>other than those listed </b></text> <text top="743" left="108" width="110" height="16" font="1"><b>in Table 13-1</b><i>. </i></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 &#34;monitored property&#34; </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 &#34;Monitored Property&#34; 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 &#34;</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&#34; 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"><b>Interpretation 1: </b></text> <text top="175" left="108" width="694" height="16" font="2">For Object COV Reporting, the &#34;monitored property&#34; 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 &#34;monitored property&#34;. 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"><b> </b></text> <text top="280" left="108" width="310" height="16" font="1"><b>Question 1:</b> 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"><b>Answer 1:</b> 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"><b>Interpretation 2: </b></text> <text top="385" left="108" width="694" height="16" font="2">In Property COV Reporting, the &#34;monitored property&#34; 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"><b> </b></text> <text top="449" left="108" width="310" height="16" font="1"><b>Question 2:</b> 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"><b>Answer 2:</b> 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"><b>Interpretation 3: </b></text> <text top="554" left="108" width="627" height="16" font="2">In Property COV Reporting, if the &#34;monitored property&#34; is the property that is also the </text> <text top="575" left="108" width="701" height="16" font="2">&#34;monitored property&#34; 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"><b> </b></text> <text top="638" left="108" width="310" height="16" font="1"><b>Question 3:</b> 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"><b>Answer 3:</b> 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"><b>Interpretation 4: </b></text> <text top="743" left="108" width="627" height="16" font="2">In Property COV Reporting, if the &#34;monitored property&#34; is any other property than the </text> <text top="764" left="108" width="694" height="16" font="2">&#34;monitored property&#34; 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"><b> </b></text> <text top="828" left="108" width="310" height="16" font="1"><b>Question 4:</b> 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"><b>Answer 4:</b> 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"><b>Interpretation 5: </b></text> <text top="933" left="108" width="637" height="16" font="2">Based on Table 13-1a, column &#34;Properties Reported&#34;: If the monitored property is not a </text> <text top="954" left="108" width="696" height="16" font="2">&#34;monitored property&#34; 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 &#34;monitored property&#34; (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"><b> </b></text> <text top="1038" left="108" width="310" height="16" font="1"><b>Question 5:</b> 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"><b>Answer 5:</b> 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"><b>Interpretation 6: </b></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 &#34;monitored property&#34; </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">&#34;subscribed-to&#34; property, and 2) Status_Flags (the object has one, obviously). </text> <text top="196" left="108" width="5" height="16" font="1"><b> </b></text> <text top="217" left="108" width="310" height="16" font="1"><b>Question 6:</b> 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"><b>Answer 6:</b> 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"><b>INTERPRETATION IC 135-2010-8 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2010 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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 = V2<i>1 </i></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 &#34;referenced property&#34; = 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> The first sentence of 12.24.6 says &#34;… range of dates within which the Schedule </text> <text top="491" left="108" width="681" height="16" font="2">object is active.&#34; 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 &#34;active.&#34; 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"><b>INTERPRETATION IC 135-2010-9 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2010 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b> </b></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"><b>INTERPRETATION IC 135-2010-10 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2010 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><b>Interpretation:</b> 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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>Comments:</b> 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"><b> </b></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"><b>INTERPRETATION IC 135-2010-11 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2010 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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, &#34;<b>Segmentation_Supported</b>&#34;, and Clause 12.11.20, &#34;<b>Max_Segments_Accepted</b>&#34;, 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"><b>Background:</b> </text> <text top="428" left="108" width="644" height="16" font="2">The property <b>Segmentation_Supported</b> 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 <b>Max_Segments_Accepted</b> 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"><b>Interpretation: </b></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"><b> </b></text> <text top="764" left="108" width="297" height="16" font="1"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2010-12 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2010 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> Chapter 12 (page 144) states that &#34;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.&#34; </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"><b>Interpretation #1: </b>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"><b>Question #1:</b> 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"><b>Answer #1:</b> 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"><b>Interpretation #2: </b>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"><b> </b></text> <text top="176" left="108" width="319" height="16" font="1"><b>Question #2:</b> 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"><b>Answer #2:</b> 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"><b>Interpretation #3: </b>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.<b> </b></text> <text top="302" left="108" width="5" height="16" font="1"><b> </b></text> <text top="323" left="108" width="319" height="16" font="1"><b>Question #3:</b> 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"><b>Answer #3:</b> 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"><b>INTERPRETATION IC 135-2010-13 OF </b></text> <text top="112" left="264" width="395" height="16" font="1"><b>ANSI/ASHRAE STANDARD 135-2010 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="1"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="1"><b>Automation and Control Networks </b></text> <text top="176" left="459" width="5" height="16" font="1"><b> </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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 &#34;Information alerts&#34; 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">...&#34;Information alerts&#34; 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"><b>Interpretation: </b>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"><b>Question:</b> 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"><b>Answer:</b> 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"><b>INTERPRETATION IC 135-2010-14 OF </b></text> <text top="112" left="264" width="395" height="16" font="0"><b>ANSI/ASHRAE STANDARD 135-2010 BACnet® - </b></text> <text top="133" left="284" width="355" height="16" font="0"><b>A Data Communication Protocol for Building </b></text> <text top="154" left="325" width="273" height="16" font="0"><b>Automation and Control Networks </b></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"><b>Request from:</b> 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"><b>Reference:</b> 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"><b>Background:</b> 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"><i>IC 135-2010-14 </i></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"><i>“… the Present_Value of the Binary Value object is prevented from being modified by </i></text> <text top="992" left="162" width="475" height="16" font="3"><i>software local to the BACnet device in which the object resides.”</i> </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"><i>“… for input-style Binary Values, the Present_Value of the Binary Value object is </i></text> <text top="1076" left="162" width="600" height="16" font="3"><i>prevented from being modified by the internal process which normally updates the </i></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"><i>IC 135-2010-14 </i></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"><i>Present_Value in the BACnet device in which the object resides. For output-style Binary </i></text> <text top="112" left="162" width="639" height="16" font="3"><i>Values, any value written to Present_Value is prevented from being used by the internal </i></text> <text top="133" left="162" width="559" height="16" font="3"><i>process which normally uses Present_Value to perform the output function.” </i></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"><b>David Fisher </b></text> <text top="321" left="108" width="66" height="16" font="1">Polar<i>Soft</i></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"><b> </b></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 &#34;on </text> <text top="531" left="108" width="669" height="16" font="6">demand&#34; 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" lef