BACnet Versatility, Facilitating a 3-Way Integration

As we were reviewing last month’s newsletter results around the water cooler, it became obvious what my next article needed to be. Without BACnet priority array services it would have been impossible to deliver the 3-way integration that has become the hallmark of our S4 Open Appliances. I’ve done hundreds of presentations talking about our ability to co-exist with the legacy supervisory controller. BACnet made that possible so I’m going to zero in on why.

I’m going to use our S4 Open: BACnet-N2 Router as an example. The three integrations are:

• Metasys® Supervisory Controller to S4 Open: BACnet-N2 Router
• BACnet Environment to S4 Open: BACnet-N2 Router
• BACnet-N2 Router to Metasys® field bus and N2 devices

For those of you familiar with the Metasys® architecture, it probably seems strange that we are talking about one of these integrations involving the Metasys® supervisory Controller. Doesn’t that just come naturally? It doesn’t, and that’s because the N2 bus is a single master architecture. The supervisory controller is going to assume that it has access to the bus any time it wants. We can’t change that behavior because of our policy of not making any changes to configurations in either the supervisory controller or the field devices. The S4 box has to act as a virtual N2 bus to the supervisory controller and route the N2 transactions generated by the supervisory controller to the physical N2 bus. But, this can be done only when we have not allocated the physical N2 bus to other tasks. This functionality takes advantage of the transaction retry and device availability algorithms built into every generation of Metasys® supervisory controller. From the standpoint of the supervisory controller, it is business as usual!

Now, we add a bit of magic to the mix. Because we wrote our own BACnet stack, we have the flexibility to implement the details as we need them in order to deliver the services needed. Remember, BACnet is a standard that specifies the objects, properties, and services that enable interoperability between devices and systems. Implementation details are left up to the developer, leaving the door wide open for innovation. Since S4 integrations were intended to be scalable to support installations of any size, we needed to solve the problem that if we did nothing special, every point in the installation would be under the control of the last client or application to command it. The question of who has control of a point needed to be deterministic. The solution was to extend the BACnet priority array mechanism to also support N2 transactions coming from the supervisory controller. Supervisory controller N2 transactions now follow all the same priority array rules as BACnet transactions. They will only be routed to the field device if the supervisory controller is controlling the point. Thus came the feature name Supervisory Controller as a BACnet Client. Again, from the standpoint of the supervisory controller, it is business as usual.

The S4 Box presents itself as a BACnet Router to the BACnet ecosystem. When the system is installed, each S4 Box is assigned a virtual BACnet network number. Every field device discovered on the N2 bus is emulated as a BACnet/IP device under this virtual BACnet network. The core services in the S4 box ensure that BACnet does not have to know anything about N2 technology, or the existence of the supervisory controller. S4 device templates automatically define the BACnet point mapping for each device and all associated BACnet properties for the point and device. This includes a mechanism that enables BACnet clients to specify the basic functions of read, write, override, and release for integrated N2 points. Major BACnet network properties and services supported are configurable from the user interface. Performance metrics are built into the system to enable monitoring of how well BACnet communications are operating. From the standpoint of a BACnet client, it is talking to BACnet devices and all features of BACnet are fully supported.

The 3rd leg of this 3-way integration is the automatic discovery of N2 devices on the legacy N2 bus and the representation of those devices and points within the core services of the S4 box in a protocol-independent way. The core services of the S4 box perform the services of the N2 bus master whenever necessary. Performance metrics are built into the system to facilitate monitoring and management of the N2 bus and field devices. Caching services are provided within the S4 Box core services to compensate for the difference in speeds between the BACnet clients and the N2 technology and to protect the slow N2 bus from aggressive BACnet applications. The N2 bus and N2 field devices have no idea that they are being handled by the core services of the S4 box and not talking directly to a Metasys® supervisory controller.

The core services of the S4 box implement a protocol independent integration engine and play a key role in each of these integrations. Because of the flexibility of this architecture, we have been able to do things with the BACnet-N2 Router that many people have to see in action before they will believe that we actually deliver the capabilities that we do, including automation of much of the integration process itself. This framework of core services also sets the stage for many new integrations and products planned for the rest of this year.