North Building Technologies

Whether you are a web designer in your Soho loft apartment or a jobbing refrigeration engineer in a basement at Canary Wharf, you will be aware of the impact of the internet on all aspects of life in the 21st century. From digital interactive television to BT payphones with web and email access, to e-commerce bookshops and dotcom travel companies. You would have to have been on Mars for the past 10 years to have missed it.

At the core of this revolution are two main technologies, TCP/IP (Transfer Control Protocol/Internet Protocol) and Ethernet, more of which later. TCP is a method of transferring data across IP. The large majority of this data contains HTML (Hyper Text Mark-up Language) embedded in a communications transport definition called Hyper-Text Transfer Protocol (HTTP). It is this code that programs such as Microsoft Internet Explorer and Netscape Navigator read to work out what Web pages look like. For example, what text to draw at what position, and in which colour and font - also placing photos and graphics on pages and creating links to other HTML pages.

You could be forgiven for thinking that TCP/IP and HTML would be useful to the controls and BMS world. After all, if all of our devices talk the same protocol on the same cable, and are capable of serving data in HTML format, then we're on to a winner. Right?

Bees in bonnets

Well, not quite. Not since the birth of RS232 has the industry got itself into such frenzy over communications. Manufacturers, trade associations, end users and consultants all have a 'bee in their bonnet' about IP. It is seen as a magical way to make many different systems communicate with each other. However, although IP will certainly allow many different systems to communicate across the same piece of cable, it does not mean they will necessarily be able to share data. As with all communications systems, there are many layers of protocol. IP over Ethernet are just two. Above these, there needs to be a definition of what data is passed, in terms of format and application.

This is similar to the way we humans communicate. I may decide to use my vocal chords to speak with a customer in Hong Kong. To connect to him, I pick up my telephone and dial his number...link established. I then start to speak...data is transmitted. However, if the person answering the phone is Chinese and does not have the correct protocol conversion knowledge to understand my English data, the data is useless to him, and the whole idea of us being connected on the same cable over the same telephony protocols becomes irrelevant.

It is therefore conceivable that you could have 20 systems in a building all connected via Ethernet, each with an IP address. Of course, if they can all serve HTML then your graphical user interface will be sorted. However, the systems will not necessarily be able to interoperate', or share data. In fact, it is odds on they can't.

So to solve this problem, you will need some marshalling device/s that can speak lots of protocols across IP and convert them into a common language, in order that data can be shared and viewed on common graphics. It strikes me that this is what we already have, but with serial communications gateways.

Small packets are the key

In fact, as a connection layer for real-time building services control and monitoring, serial communications are highly appropriate, compared to Ethernet. Ethernet is optimised for carrying large packets of data such as spreadsheet files and databases very quickly, but not very often. This means that when your accounts personnel get to work, they can call up a spreadsheet from the server and can expect it to appear straight away. However, if they all try at once, the network becomes bogged down with clashes, and delays start to occur.

When we look at the way building control systems communicate we can see that, in general, the data transfer requirements are different. Most building systems need to be able to transmit very small packets of data (temperatures, occupancy signals etc.) very frequently, to ensure that, for example, an occupancy signal is transmitted to the lighting system quickly and reliably. Virtually all proprietary building system networks can do this, as can networking and protocol standards designed specifically for use in buildings, such as BACNET and Compass.

In the mid 1990's, CEN (Comité European de Normalisation) explained the architecture of building systems using a three-layer model, comprising management, control and field layers. Manufacturers and industry pundits have subsequently adopted this model as a general explanation. Ethernet is generally shown at the management level, while coordinating networks, such as Compass, are generally shown at the control and/or management layer. Whether or not the three-layer model will serve into the future remains to be seen as the capabilities of building networks continue to expand.

So the moral of the story is: don't be fooled by the hype. There are definite benefits to be had from Transfer Control Protocol/Internet Protocol and Ethernet, but only if used at a supervisory level. Don't assume they are going to be a panacea for all of your networking desires.

What you will find, if you look carefully, is that your ideal bus has already arrived. All it takes is one small step and you will be on it.

---