Open Systems and the Programmable Controller

Open Systems and the Programmable Controller

By Adam VanOort, President of DataNab

Installing proprietary systems in building automation and facilities management seem approximate to signing one’s life away.  There are fewer reasons to lock into a closed solution given the options on today’s market.

The customers we speak to that are looking for a way out of these systems cite long-term expense and integration capabilities as the leading concerns.  Service also becomes an issue over time as components break down and high upfront costs mutate into high ongoing maintenance expenses as the customer has limited, if any options beyond getting service directly from the manufacturer or dealer of those systems.

This is not to say that all proprietary systems are bad— it’s more about providing the customer with the freedom to choose whatever solution works best.  As the cost of manufacturing in technology has dropped, there have become more open options than ever, and the benefits of locking into a propriety system continue to shrink, especially in the area of communicating I/O devices and programmable controllers

Open Communication Protocols

ModBus and BACnet are the best protocol options to support on open I/O and control devices.   Both protocols use RS485 as the communications backbone, i.e., the physical network that supports the data traffic.  RS485 is the ideal communication network environment for devices as it supports long-distance network runs over a single twisted pair — up to approximately 4000 feet in normal conditions.  This makes life easier for integrators and end users that need to position end devices in rooms far from the main controller or head end system.

BACnet is a standard data communications protocol that specifies most of the common functions in control and automation applications.  Its protocol rules apply to all pertinent actions in a control operation, including network access, electrical signaling, error checking and message sequencing.

Its openness makes BACnet a more attractive option than proprietary protocols, but there are drawbacks.  Writing drivers for BACnet can be time-consuming, which foreshadows the often complex process of integrating those drivers into the customer’s software and/or main controller.

A common concern we hear is that there are challenges in finding power and demand meters that support BACnet — a problem for many DataNab customers who use our universal monitoring and control devices to measure usage tied to utilities.  This may be related to the relative newness of BACnet, which first appeared in the late 1980s.

Another concern is that BACnet drivers can take up a lot of code space on devices.  This makes the controllers a bit more expensive to manufacture and program because the protocol requires a fairly sizeable amount of memory and capacity.

The Modbus protocol, by comparison, is simple and efficient.  Its existence dates to the late 1970s, with a well-worn reputation for reliability, simplicity and strength.    Programming drivers is achieved in a short amount of time, and Modbus enables simple integration of devices into different software environments and controller brands.

Comparing Modbus to other control and automation protocols demonstrates its true openness.  LonWorks, a fine protocol in its right, requires the purchase of special components — thus creating a complicated and more expensive and time-consuming development process. 

Designing or integrating Modbus devices requires no special components.  Hardware that supports RS485 communication is widely available from a wide variety of vendors at a very low cost, and it is relatively simple to develop Modbus drivers on devices.

Controller Designs 
Most programmable controllers can perform the same types of functions at the end of the day.  For many integrators and end users it’s about finding the right mix of inputs and outputs for the job and ease of installation.   Consider the systems integrator:  The number of sensors and outputs needed to monitor/control attached equipment will likely differ from job to job.

Vendors adapt their design approaches based on customer feedback.  We have noticed two trends from our customer feedback:  a need to gather data from a larger number of sensors using a single device; and an interest in the incorporation of pulse counters to accommodate metering applications in utility measurement.

The need for more inputs makes sense in modern building automation and alternative energy systems given the high amount of information that is required to optimize and manage today’s systems.  Having a large number of inputs also makes it possible for users to inexpensively monitor sub-circuits by connecting current transducers.  This can help with measuring usage tied to specific elements, such as lighting circuits — and is particularly helpful in large buildings to measure how much energy “circuit X” is using.

The integration of pulse counters into programmable I/O devices and controllers is also a design trend.  DataNab, for example, recently introduced a new device that incorporates two high-speed, 32-bit pulse counters.  These are often requested by customers for tracking consumption of electrical, water and gas usage.  As most utility meters offer pulse outputs, the inclusion of pulse inputs into devices can help users track and manage utility costs.

On the commercial side there is an interest in bringing more output relays into the device designs in order to control more components and systems network-wide.   This includes everything from the lights to rooftop units and boiler room systems.  Form C outputs are especially useful for integrators and contractors as they offer normally closed and normally open contacts for each relay —simplifying the wiring process.

The IP Equation

What has been discussed to this point mostly relates to devices that support communication over RS485 networks, but we’d be remiss to not address where IP networks fit into the picture.

It’s still too cost-prohibitive to manufacture every control and automation component as an IP-supported device.  But the growing need to quickly glean system information over a network from any location means that IP is steadily penetrating the industry.

Most IP-enabled building automation and facilities management systems get away with having a central IP controller that bridges a number of RS485 devices over the network via various converters and gateways.  Keeping the end devices as RS485 components and bridging them to the IP network via a gateway device keeps the system costs to a minimum, while reaping the user-friendly monitoring benefits that the IP environment offers. 

The IP environment is also conducive to more easily marrying building automation systems to other building systems, from audio/video to security and life safety.  In these cases the RS485 controllers continue to operate on their own slice of the network and take up a minimal amount of bandwidth as data passes between the RS485 devices and main IP controller.  Meanwhile, the central IP controller or software works to consolidate these various elements into a single user interface, as opposed to working as disparate systems.

The explosion of IP in the control and automation space is representative of the network-everywhere philosophy today.  Modern society essentially demands it — especially in the business world, and it will be interesting to see how the relationship between legacy and IP systems evolve.