Metasys Supervisory Controller and BACnet client co-existance

The Metasys^® N2 bus is a single master architecture so only one supervisory controller can have control of the bus. The S4 Open: BACnet-N2 Router acts as the gatekeeper and mediates who has control of the N2 bus. It either gives control to the legacy Metasys^® supervisory controller (Companion / Facilitator, NCM, N30, NAE, Facility Explorer, or custom application), to an active BACnet IP application, or to the BACnet-N2 Router itself. When there is not a Metasys^® supervisory controller on the Upstream N2 Interface of the BACnet-N2 Router it takes over as bus master.

The default mode of operation is to let the last person to touch a point have control. This adds a large degree of randomness to the process but is the most hands-off algorithm. The BACnet-N2 Router has a feature called Supervisory Controller as a BACnet Client which forces all transactions coming from the supervisory controller to pass through the BACnet priority array mechanism. See "Supervisory Controller as a BACnet Application" for details on how this feature works. This give the integrator direct control over the priority of transaction coming from the Metasys^® supervisory controller vs. transactions originated by BACnet OWS, global controllers, or other BACnet applications.

The final decision, however, lies with the individual N2 device. It can decide what transactions to accept, which ones to reject, and which ones to ignore. There are four basic data related commands that N2 devices support: N2 Read, N2 Write, N2 Override, and N2 Release. The unique variation of the N2 protocol for each Metasys^® product family implements these four basic commands in their own way. Once the command arrives at the N2 device there is a lot of lattitude for the application in the N2 device to handle the Command in the way best suited for the application currently loaded. Assuming that submitted N2 commands are syntactically correct, values of the correct data type, and within acceptable ranges, there are some important precedence rules that most devices implement in the same way.

•  If a Point is in Normal state the device will accept either N2 Write or N2 Override commands against that point.
•  If a point is in Override state the N2 device will ignore any N2 Write request that it receives for the point.
•  If a point is in Override state the N2 device will accept additional N2 Override commands and modify the overridden value.
•  If a point is in Override state a N2 Release command must be sent to the device to return it to Normal state before N2 Write commands will be accepted. The source of the N2 commands does not matter to the N2 device. Commands can be originated from ANY source with the same results. So, the general guideline is that if a N2 Override command is sent to a N2 point from ANY source, then ALL applications, controllers, OWS, etc. need to send N2 Override commands to change the value of a point.
  

The BACnet-N2 Router defaults to sending N2 Override commands to physical I/O points and N2 Write Commands to Internal points when it receives a BACnet write request over the BACnet IP interface. You also can specifically force specific behavior of points by adding parameters .Value, .Override, or .Release to the source string for N2 points on the point property page in the Building Control Network folder of the BACnet-N2 Router.

By using these two capabilities of the BACnet-N2 Router you can specifically and predictably determine who has control of any N2 point in your configuration.