S4 Open Appliances Evolution
A few years ago when we designed the OPC-N2 Router we envisioned that this initial product would be the first of many offerings in the S4 Open product line. The system architecture was defined with a set of protocol independent core services and protocol plug-ins that implemented the Upstream and Downstream protocol stacks. I have mentioned the fact that the Obermeier Software SNMP-OPC Server product line was adopting the same architecture and compatible protocol plug ins.
This sets the stage for some exciting new offerings that we’ll be starting to test in the next couple of months. This variation of the S4 Open appliance will perform an integration service to bring field devices using standard protocols into the Metasys environment, or into any other BAS supporting BACnet IP. The first of these offerings will be a S4 Open appliance that automatically discovers OPC servers on a network and publish the objects that it finds as VND devices on a N2 Network or as BACnet IP devices. The compelling application here is to collect data from energy meters and bring the results into legacy Metasys systems. We expect the development to be completed on this effort in about 6 weeks with QA and BETA testing to follow shortly after that. Modbus and SNMP variations will follow as our workload allows and depending on customer demand. The OPC-N2 Router and the BACnet-N2 Router served the role of N2 bus master and enabled the integration of legacy N2 devices into open environments. With this offering we are addressing another need to integrate devices using foreign protocols into Metasys, and other BAS systems.
As many of you know we have been active in the EnOcean Alliance and BACnet International working groups addressing gateway technology. These activities, along with the fact that our integration partners have been taking on much larger and more sophisticated projects, have caused us to refine the way we think about the relationship between the BACnet-N2 Router, the BACnet Client, and the N2 field devices. Our initial approach to building the BACnet-N2 Router was looking at it as providing a gateway service and the protocols provided the line of demarcation between the various domains defined by the various network technologies.
We found that this approach provided a solution that followed the letter of the BACnet specs but didn’t always meet the expectations and demands of our integration partners. A case in point is our emulation of the BACnet priority array and the associated Relinquish Default processing. We took a step back and determined that instead of looking at the N2 protocol as the line of demarcation between the BACnet-N2 Router and the N2 network of field devices we needed to look at the BACnet-N2 Router as encapsulating the N2 environment. The nuance here is that for any given BACnet function we may need to perform protocol translation, perform feature emulation, and issue a series of N2 commands to the N2 field devices completely transparently to the BACnet client.
Work is underway in this area and the results will be seen in upcoming maintenance releases of the BACnet-N2 Router.
The activities with the EnOcean Alliance and the BACnet International working groups were driven by our development of yet another new member of the S4 Open product family, the BACnet-EnOcean Router. Initial prototypes of the product have been tested and we are rapidly moving towards QA test and BETA testing. In order to provide the functionality and flexibility that our integration partners and the EnOcean community required, and at the same time fully comply with the BACnet specifications, we needed to take a much broader look at the EnOcean technology than was obvious on the surface when we first investigated the viability of developing this product. This resulted in the development of our EnOcean Hotspot from the hardware side and in the utilization of the remote management features of the EnOcean protocol in our software in addition to the basic EnOcean wireless protocol.
During our live demos of the BACnet-N2 Router we typically refer to the Building Control Network folder in the S4 Open Management Console as a view into the Core Services of the appliance. This is a protocol independent virtual representation of all the points being published. Historically, the organization of the BCN reflected the physical networks connected to the appliance. As part of the development effort for the BACnet-EnOcean Router the BCN takes on the ability to reflect a logical view of a building being managed as shown in this screenshot from one of our prototype test cases.
Notice also that because of the system architecture including protocol plug-ins the BACnet-EnOcean Router will optionally be able to also handle legacy N2 networks. This facilitates upgrading, or expanding, existing buildings that contain a legacy Metasys installation with EnOcean technology. Watch for more details in upcoming issues of The Gateway.