North Building Technologies

I started out in this industry in 1994, working for North, a Company that specialises in creating interfaces to allow disparate control systems to communicate with each other. We write software (drivers) that make language “A” compatible with language “B”, so that you can use information from the intruder system to tell the HVAC if a room is occupied for example.

During the late 90’s many of my industry contemporories would take great pleasure in assuring me that there would soon be no need for interfaces. This new protocol (language) called LON was to become the industry standard and all building services would share a common network and application standard for communications. As everything was going to talk this “Esperanto” there would be no need for translation services such as ours.

Well, we are still here, and selling communications interfaces is still a major part of our business. So what happened? Why didn’t the industry embrace this standard? There are a few obvious reasons: Firstly the standard was a commercial concern rather than an open protocol. It required huge investment in product re-development and dependence on a third party for the products success. Secondly, the idea of LON was that everything from the controller down to a room temperature sensor would communicate on the same network using the same protocol. The big manufacturers realised that as soon as they standardised their products to this degree they would be in a commodity market rather than a technology market. So any technical advantage they had worked hard for would be effectively thrown in the bin. Lastly the technology never really met expectations and many developers were forced to implement “private messaging” on this “open” protocol to over come these short comings, which made the protocol some what redundant.

What we have seen since is the release of the next big thing in protocols from the States, intent on solving those issues. The BACnet protocol does not require any particular hardware platform and tends to be implemented at a much higher level than sensors and actuators. In fact most interfacing occurs at a BACnet/IP level. Meaning the manufacturer can implement a simple gateway (whether in a separate box or internally) onto their proprietary protocols that shares data with the outside world, without having to re-design or commoditise their products.

This protocol has been embraced by many of the big controls manufacturers ( although surprisingly the biggest in the UK is yet to join the fray, and has in fact gone even further the other way by not releasing protocols to their latest product range.)

Marvellous I hear you cry; now at last we can specify a protocol for all of our building services that will allow us to create open and interoperable buildings. Well we need to be careful. You could indeed specify Chillers, HVAC controllers, Variable speed Drives, Fan Coil Units all with BACnet protocol implemented. This however would not necessarily allow the systems to even connect to each other, let alone share data. They may all talk the same language, but they often use different methods of talking that language. Some use Ethernet for the physical connection; others use RS485 and some RS232. We have even seen the BACnet protocol over a LON physical connection. Confused? Yep, me too. What use is a standard if there are a million and one ways to implement it? We may both speak English, but if I only have email and you only have a telephone, there is no way we can share data without some translation device. If we have to use interfaces why did we bother using the “standard” in the first place?

But things don’t stay still for long, even in this industry. Just as people are getting used to BACnet and the pitfalls and advantages as detailed above, all of a sudden the next “next big thing” arrives. And this time it has some real weight behind it. As in Microsoft type weight! It’s called XML (Extensible Mark-up language) and is understood by many thousands of IT people the world over. It has applications from all types of industry, from getting values from weather stations into your software, to reading BBC news headlines onto your desktop.

You may have heard of HTML (Hyper text mark-up Language.) HTML is the language designers use to create web pages for humans to browse. Well XML is a language designers use to create web pages for machines to read. There are application layer standards coming out of the US that may well be ratified soon to enable machines to share information on building services events via XML.

Essentially XML allows you to “publish” data from your system on the web that other controllers can read from you. There is another part to this. How do other controllers write information into you via XML? Well they don’t, they have to employ a further protocol called SOAP. SOAP allows a value within an XML schema to be adjusted by a third party system. So we use XML for speaking and SOAP for listening.

Great, another protocol! It seems the further down the road we get, the more protocols we have to support and every time a new “standard” pokes its head over the parapet another raft of manufacturers jump on the standards band wagon. Because of this the latest standard feels like it is gathering pace. However those that are just recovering from the last round of excitement still have a lot invested in the last protocol. At North Building Technologies we see standards in all sorts of areas. Security have their own set of standards (rarely employed), Lighting favour LON, Energy systems such as UPS, Meters and generators tend to use MODBus protocol, HVAC controllers go for a mix of LON, BACnet and proprietary open protocols. Although the biggest players often keep their proprietary protocols closed. The Fire detection people tend not to have any standards at the management layer, and let’s not even mention CCTV, with its many layers of complexity.

So we can talk all we like about the next big standard, the fact of the matter is very few components within a new building will comply (and legacy systems have no chance) to a great enough degree to achieve anything meaningful. The technologies are changing so fast that consultants hardly have time to get to grips with the last big thing, let alone the next.

If we want connected and converged buildings then we can have them. But let’s understand that there is no magical standard that will make this happen without some form of middle ware. There needs to be a layer to manage the different protocols, to generate a common user interface onto these systems and to take in those systems that do not comply with whatever standard is flavour of the day.

We have seen an increasing amount of competition in our market place. Companies such as North, Tridium and Plexus are supplying this middle ware framework and are investing heavily in the interfacing and convergence marketplace. North Building Technologies Ltd are still be being asked to write an average of 2 new interfaces per month (with over 250 already written) if there was any really viable standard out there would we need to? Interfacing is alive and well. As we say at North: “the more standards, the better”.

---