Building automation OEMs can choose from many communications technologies. However, for product designers, this choice of technologies introduces risk and cost when trying to address the different protocol options. Interchangeable modules remove this risk in a cost effective way.

At the top of the list of contemporary protocol choices are BACnet and LonWorks, with protocols such as Metasys N2 and Modbus RTU as perennial favorite ‘legacy’ protocols. ZigBee is emerging as an exciting wireless protocol that seems poised to take off in 2005/2006 if it can hit critical mass.

[an error occurred while processing this directive]

What protocol should be selected for a new design?

When it comes to selecting one protocol to design into a new controller, the choice can be tough. There are many, often conflicting, factors that need to be taken into account:

• The controller may need to interface with the existing protocol at a site

• The customer specifies the protocol requirement

• Marketing requirements for an equipment manufacturer’s product requires emerging new protocol to differentiate the product

• Sales pressure for the equipment manufacturer might dictate interface to an installed base of legacy protocols

And production wants to avoid adding unnecessary cost to the bill of materials.

This means that here may be no choice for designers but to support all the available applicable protocols for their products.

The situation is made worse by different hardware requirements

This situation is made worse when one realizes that BACnet and Modbus have multiple hardware layers to support, (Ethernet, RS-232 and RS-485), LonWorks requires special hardware (FTT-10 transceiver and neuron chip) and ZigBee needs a special radio chip - and even the ZigBee standard allows for different radio hardware platforms.

Because of this hardware element, it would be impossible to design small controllers that support all possible alternatives in a cost effective manner.

Significant resources are required to support some protocols

Even if the scope was limited to one hardware layer, e.g. Ethernet, protocols such as BACnet require a substantial memory footprint and CPU power to support, significantly more than what is available in the common MCU (microcontroller) chips used in most small controllers.

Modular Approach satisfies conflicting demands

So in the face of conflicting demands, (cost, flexibility, customer specifications, eventual dominant protocol), the concept of interchangeable protocol modules have significant appeal.

FieldServer Technologies has introduced a range of such modules called ProtoCessors (www.ProtoCessor.com). These modules are designed so that they all have a common PCB footprint and identical host interface to the MCU on the controller board. An open protocol and accompanying source code is supplied to implement the software side of the host interface.

It should be noted that Modbus RTU or Metasys N2 Open could also be used as a host interface protocol if one of those protocols is already implemented on the host MCU. In addition, proprietary protocols are easy to implement on ProtoCessors. This means that the ProtoCessor architecture enables connectivity with the absolute minimum redesign of existing controllers.

[an error occurred while processing this directive] BOM cost-reduction a priority

The PCB footprint for the host interface has been designed for absolute minimum cost on the controller bill of material – two single rows of pins. These pins supply the ProtoCessor with power and data via a standard asynchronous serial transmit (Tx) and receive (Rx) signals – basically TTL level RS-232 or RS-485. The rest of the pins are reserved for future functionality and mechanical stability. In addition, PCB space underneath the module is useable for host controller functionality, so there is not even a significant PCB real estate cost.

This approach has additional benefits:

1. Optional install: If a communications protocol is not required, the module does not have to be installed at the factory, providing substantial cost of goods savings.

2. Compatible with legacy designs: The host socket is designed to accommodate a default protocol on the host PCB. If the default protocol such as Modbus is chosen for the controller, then the electrical interface allows this protocol to be used if the ProtoCessor module is not installed. The host system software does not have to change.

3. Field Installable: The modules can be installed or changed in the field by end users.

4. Significant R&D savings: Even if a module supporting a protocol requires a 32bit processor with 8MB RAM and 2MB flash, all this complexity is on the ProtoCessor module itself, and does not impact the host controller PCB – this significantly reduces the controller PCB trace layout and can result in a four or even a two-layer board instead of a more expensive six or eight layer board

Summary

Interchangeable modules are a way to retain flexibility while avoiding cost, as well as allow the latest and most appropriate “best of breed” technology to be used. They allow designs to be future-proofed against changes in technology, changes in market demands and component obsolescence. They allow significant cost of goods savings by allowing protocols to be installed as needed, and not on every box shipped out of the door, and by removing unnecessary built in complexity into the basic controller design.

About the Author
Eddie Hague is the CTO of FieldServer Technologies and the inventor of the FieldServer line of very successful and powerful protocol gateways, as well as the new ProtoCessor line of OEM protocol coprocessors. He has 25 years of experience in developing protocols for the industrial and building automation marketplace.

About ProtoCessor
www.ProtoCessor.com ProtoCessors are a family of modules that are developed, manufactured and supported by FieldServer Technologies, a very well known and established vendor in the building automation communication field. FieldServers support all of the major building and industrial automation protocols and have been doing so since 1994. FieldServer Technologies is a division of Sierra Monitor Corporation, a publicly traded company.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]