What are the Best Practices for Performing a Metasys N2 Integration via the S4 Open: BACnet-N2 Router with Tridium or Niagara Systems (KBA-01022-Z8N3J2) ?

This article documents lessons learned and best practices for performing integrations utilizing the S4 Open: BACnet-N2 Router and Tridium, or Niagara, systems. Testing was a cooperative effort between The S4 Group and Tridium. This guidance is appropriate for versions of The S4 Open: BACnet-N2 Router prior to firmware release 1.22.

BACnet devices can act as either a client or a server depending on the function that they are performing at any given point in time. When acting as a client a BACnet device will use its own APDU Timeout, APDU Segment Timeout, and Number of APDU Retries to manage the communications between itself and any other BACnet devices it is communicating with. There is no absolute correct settings for these properties so the installer needs to adjust them to reflect the conditions presented by each installation.

In this integration the Tridium system is acting as a BACnet client and the S4 Open: BACnet-N2 Router is acting as a BACnet server. The S4 Open: BACnet-N2 Router is a BACnet IP device capable of supporting a high speed Ethernet connection between itself and Tridium. However, throughput and response times are limited by the speed of the legacy Metasys N2 bus and the methods required to handle timeout errors on this slow interface. This lead to the S4 recommendation to set an untraditionally high APDU Timeout value in any BACnet client utilizing its gateway services. The side effect of following this recommendation in the Tridium system is that points are more prone to go "Stale" when timeout errors are encountered on the N2 bus.

With appropriate tuning following the guidelines below you will achieve optimal performance and unleash the full power of the S4 Open: BACnet-N2 Router and your Tridium installation working together.

If there is any concern about this guidance you should contact your Tridium support team or your S4 Open Appliance integrator before implementing any changes.
Current guidance:
- You need at least S4 Open: BACnet-N2 Router firmware version 1.19.2157.01.
- The settings of APDU Timeout and APDU Segment Timeout in the N2 Router should be left at the default values of APDU Timeout 20000 and APDU Segment Timeout 10000.
- In the Tridium Local Device settings start with the Tridium recommended default settings for APDU Timeout, APDU Segment Timeout, and APDU Retries. Adjust these values to achieve optimal
results for your project. The BACnet and N2 bus performance stats in the BACnet-N2 Router will help you tune these settings.
- The Read Property Multiple (RPM) option in the BACnet-N2 Router Ethernet properties page should be deselected.
- COV support in both the BACnet-N2 Router and the Tridium system should be deselected.
- After changing these properties and parameters restart the Tridium station to make sure that it recognizes that the BACnet-N2 Router is not supporting RPM or COV.

Finding the optimal values for APDU Timeout and APDU Retries in the Tridium client is not an exact science and needs to balance the characteristics presented by the S4 Open: BACnet-N2 Router and the N2 devices hosted by its gateway function with the needs of all other BACnet servers that your particular Tridium system is interfacing with.

Additional Comments
With the current release of our S4 Open: BACnet-N2 Router (Firmware 1.19.2157.01 ) we found in our lab testing that by turning off support for RPM in the N2 Router configuration that Tridium will send only RP requests. We’ve tested APDU timeout settings in the Tridium system from 500 to 20000 and we see consistently good results. We’ve seen no sign of the stale points issue that started this investigation. So, the short term guidance is to turn off RPM support in the N2 Router and set the APDU timing properties in the Tridium Local Device as defined above.

Longer term (after additional enhancements are tested and released) the guidance for all BACnet clients will be:
1st preference is to use COV support. That puts the responsibility to manage the slow N2 bus, with all it’s wrinkles, completely on the N2 Router. We’ll report the COV notifications as requested in the BACnet subscription. This code was implemented some time ago but we found some problems in the initial field trial and turned it off by default until we had a fix.
2nd preference if the BACnet client cannot support COV subscriptions and notifications is to use the caching technology provided in the BACnet-N2 Router as a protocol independent service. This is newly introduced to the BACnet-N2 Router test build but it is mature code borrowed from our OPC implementations. This will decouple the BACnet implementation from having to deal with the slowness of the N2 bus and provide nearly instantaneous responses to BACnet read transactions. It simply does the caching process transparently to the BACnet client. This was a feature requested by one of our partners whose BACnet cannot support COV some time ago.
3rd preference would be, if the BACnet client cannot support COV subscriptions and notifications, would be to turn off RPM support in the BACnet-N2 Router and additionally make the decision if they want the N2 Router to provide the transparent protocol independent caching service. That decision would be up to the integrator and would be driven by the requirements of their project. Our recommendation would be to always use the caching service but the option provides additional flexibility.

We will update this knowledge base article as our testing continues and the new features are moved into production status.

We found numerous facts during this testing.
1) S4 has always recommended a large APDU Timeout setting because of the way Metasys® handles non-responsive devices on the N2 bus. Even though we receive BACnet transactions at
Ethernet speeds we need to account for the round trip time to traverse the 9600 BD half-duplex bus and return the results. N2 devices themselves are notoriously slow. We also need to account
for having to wait the timeout period, when necessary. With RPM requests we need to wait the timeout period for each requested point so the impact is cumulative.
2) Tridium likes the APDU Timeout to be as low as possible because this setting also impacts the scheduling of their poll sequences and retry algorithms. The side effect here is that large values of
APDU Timeout therefore can cause points in Tridium to go stale when encountering errors on the N2 bus.

3) Tridium also likes to see the APDU retry number set as low as possible.
4) Turning off support for RPM in the S4 Open: BACnet-N2 Router so that Tridium sends only RP requests for individual points greatly improved the performance of the integration
5) We observed that when Tridium encounters timeout errors for several points on a device it will declare the entire device down and not try again until a Tridium Ping process finds the device back
online. This can be problematic when less than perfect N2 bus conditions provide a false indication that an entire N2 device is inoperable.