ANSI ASHRAE 135 INT 3-2017 BACnet - A Data Communication Protocol for Building Automation and Control Networks.pdf

1、Page 1 of 2 2017 ASHRAE. All Rights reserved. INTERPRETATION IC 135-2016-3 OF ANSI/ASHRAE STANDARD 135-2016 BACnet - A Data Communication Protocol for Building Automation and Control Networks Approval Date: June 26, 2017 Request from: Stephen Karg, Legrand/BCS Wattstopper, 2234 Rutherford Road, Carl

2、sbad, CA 92008. Reference: This request for interpretation 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. Background: In Clause H.2 about offline dev

3、ices for virtual network gateways: H.2.2.1 Offline Devices When modeling devices as a virtual BACnet network of devices, communication timeout errors between the gateway and the non-BACnet device shall not result in the gateway returning an error, abort, or reject PDU in response to BACnet requests

4、directed to the non-BACnet device. Instead, the gateway shall remain silent. This gives the best indication to the BACnet client that the device is offline. When a gateway has determined that a non-BACnet device is offline, it shall also not send I-Am or I-Have requests on behalf of that device. and

5、 for single device gateways: H.2.3.2 Offline Devices Communication errors between the gateway and the non-BACnet device should be indicated via the Reliability property and Fault flag in the associated BACnet objects. The gateway should support initiation of event notifications to report such faults

6、. Properties that exist in objects in the gateway device shall return values when read and not errors, even when the non-BACnet device from which those values are normally read is offline. It is not acceptable for this style of gateway device to not respond to confirmed requests just because the non

7、-BACnet device is offline. The offline behavior of the two types of gateway models is inconsistent. The manner in which a gateway is modeled should have no effect on its network behavior (responses), and modeling as either Single Device Gateway or Virtual Network Gateways should allow both types of

8、offline behavior. Devices which interact with either gateway model will have to expect either behavior. Consider a vendor modeling non-BACnet devices which acquire change-of-value or opportunistic data, sometimes with infrequent and asynchronous data updates, where the non-BACnet devices offline-sta

9、tus are not able to be detected, or modeling non-BACnet devices with an especially large amount of data. In both cases, the vendor is forced to model as a Single IC 135-2016-3 Page 2 of 2 2017 ASHRAE. All Rights reserved. Device Gateway, rather than the more inter-data relationship apparent Virtual

10、Network Gateways. Interpretation: A gateway modeled as a virtual BACnet network of devices may: 1) return positive responses to BACnet requests directed to the non-BACnet device if the non-BACnet device offline status is not detectable 2) and if the non-BACnet device offline status is detectable, th

11、e amount of time that the gateway may continue to return positive responses to BACnet requests directed to the non-BACnet device is a local matter 3) or include objects that behave in the same manner as H.2.3.2 Offline Devices, where the device shall return values when read and not errors, and the o

12、bjects use the Reliability property and the Fault flag in the associated BACnet objects to indicate their offline status. Question: Is this Interpretation correct? Answer: No Comments: H.2.2.1 and H.2.32 are mutually exclusive concepts and the text cannot be interpreted interchangeably. Once a Virtual Network Gateway has determined that a gatewayed virtual device is offline, then it must remain silent in response to requests for the gatewayed virtual device, thereby mimicking a physical route to the device that has gone offline.