North Building Technologies

Open Protocols

What are Open Systems? Silly question? Well I would argue otherwise, today's controls market has as many different answers to this question as there are technical solutions. Perhaps that's the problem. A useable standard across all disciplines has long been seen as some kind of controls nirvana. I suggest we need to be careful what we wish for. Allow me to explain.

Layers

One of the biggest issues we face is a lack of understanding in the industry. Many people don't recognise that each buzzword - LON, BACnet, IP, ModBus et al - normally represents only one layer of seven in the Open Systems Interconnection (OSI) reference model as defined by ISO. Learn more about the OSI seven layer reference model.

So the race is still on and there are several contenders for the "Industry Standard" title, let me introduce them to you.

XML

XML is a markup language for documents containing structured information. Structured information contains both content (words, values, etc.) and some indication of what role that content plays (name, temperature, etc.).

Originally designed to meet the challenges of large-scale electronic publishing; XML is playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere. There is wide ranging support for this protocol but it has a long way to go before it offers the iBMS industry a suitable standard as no common application layer has been defined.
I'll explain: I might label all of my setpoint values as "SP" where as another manufacturer might define theirs as "SETPOINT". It is at this level that definitions need to be made.

XML generally operates over IP (Internet Protocol) and is therefore suited more to management networks rather than field bus and control level where the chances of an IP connection are both slim and anyway unsuitable. Also XML does not have any concept of alarm events or data logs but then amazingly these often take a back seat when iBMS standards are being developed.

The main benefit being that this is a well understood protocol that is very simple to implement and already has a broad acceptance within the IT industry. (The IT boys understand it and would tend to be more open to allowing XML on their precious networks)

BACnet

Developed with the support of ASHRAE, BACnet is a standard communications protocol for the HVAC controls industry. One of the biggest selling points of BACnet is its flexibility, yet this is also its biggest downfall.

BACnet is based on a collapsed four-layer version of the OSI model. The physical and data link layers of BACnet support many different medium including Ethernet, Arcnet, EIA-485/MSTP, EIA-232/PTP, LonTalk and IP. BACnet devices can also choose to support different services, objects and even the version of the protocol.

So you could have the situation of 'system A' supporting BACnet/PTP and 'system B' supporting BACnet/IP; one supporting multi-state value the other analog value object types. Both 'BACnet compatible' but neither able to communicate with each other - that's straightforward then!

Fortunately BACnet devices must describe which parts of the protocol they support in a document called a PIC statement. BACnet routers are also available to convert between physical layers.

Advantages are that BACnet does not rely on any specialist hardware to operate and has a broad acceptance in the US, which -like all things American- is catching on in the UK.

ModBus

Developed by Modicon in 1979, Modbus is by far the most established protocol in building automation devices today. Modbus is an application layer protocol, positioned at layer 7 of the OSI model.

Modbus originated as a standard for programmable logic controllers (PLCs) to access simple integer and binary values. The protocol has no concept of floating-point values, text values, data logs or alarm events but is well understood and has very broad acceptance across many disciplines.

Its main strength is that this is a very simple protocol that may be easily implemented in low-level devices. ModBus is the standard in power metering, UPS and generators.

LonWorks

LonWorks is a firm favourite with lighting controls and small fixed function controllers that do not require many data points. The main advantages of a LonWorks network is that the industry has a good working knowledge and wide ranging technical support available. It has some good strengths when it comes to installation in that power and data can be run down the same pair of wires, and the network speeds tend to be fast and well optimised for building data at field bus level.

Its disadvantages tend to be technical - any device wishing to communicate on a LonWorks network must use a Neuron chip to access the LonTalk protocol, this involves expensive re-design of systems and incurs many hidden costs such as training, documentation and support. Once you are on board with LonWorks each Neuron chip is limited to 64 Standard Network Variables Types (SNVTs) that can be shared with other systems; fine for a lighting ballast but quite limited for a big motor control centre.

For different LonWorks devices to interoperate they need to conform to a LonMark functional profile; such as lighting switch, VAV controller, humidity sensor, etc. Again data logging and alarm events was something of an afterthought and are only available as bolt on interfaces.

Levels

There is a strong argument for employing different protocols at different levels within the building. The classic 3 layer model has a lot going for it; the data that travels between a temperature sensor and a controller has different networking requirements to the data that travels between an IT server and a workstation. When you realise that Ethernet was designed specifically to get very large quantities of data across it very infrequently we can all see that perhaps that's not the best medium for transmitting a light switch or occupancy bit. As soon as you get very frequent transmissions from lots of addresses Ethernet tends to fall over quite quickly.

The opposite is true at higher levels - when you want to read a temperature data archive from the server that may be several KB in size then RS485 may not be well suited. This topology better suits small packets of data travelling very frequently and would struggle to pass a large file across it efficiently.

As different tasks have different requirements should we all be racing towards a single network solution that will ultimately compromise one or both ends of the networking problem? Perhaps we need two or three standards as per the OSI model. I could easily see an XML based standard at viewer level, BACnet at controller level and perhaps LON or ModBus at field bus level. None of these are perfect but each has its strongest offerings in very definite areas.

Commercial reality

The bottom line is that almost all of these standards have a large commercial downside. If I make my controller 100% compatible with my main competitors then all I have left to go to market with is price. None of the manufacturers want a price war - in fact none can afford a price war in the current climate where the idea of margin and profit on BMS jobs has long been consigned to the history books. To win a project you need every conceivable technical advantage possible, constricting your R&D to one system is perhaps not the best route to achieving that.

Whether the protocol is ModBus, LonWorks, BACnet, XML or proprietary is frankly irrelevant, either way there is still little guarantee of compatibility. The only real solution for consultants is to specify a truly independent systems integrator. One that has a strong track record working with a variety of integration tools and that sets out their stall as a team of integration experts. They are out there -we use them all the time- and they do know what they are doing.

After all, if you end up using interfaces anyway, why bother limiting your tender returns to one protocol? You could be ruling out the best mechanical or technical solution for your project. The aim should be to specify open protocol systems - and by open I mean any protocol that a manufacturer makes available - and to employ the best mechanical and electrical solutions for the project regardless of what protocol was in fashion at the time the system was designed.

---

By James Palmer, Business Development.
Article originally published in Building Services & Environmental Engineer (BSEE) magazine, February 2004.

All trademarks are property of their respective owner.

---

---

---