ABSTRACT

A short overview on today's trends in BACS (Building Automation and Control Systems) is presented. The influence of standard protocols and web technology is analysed, and some of the most promising ones, in the author's view, are analysed in more detail. The actual status of the different standard protocols by international standard bodies is outlined. Finally an outlook is given to how the future in the building automation world could look in the next few years.

TABLE OF CONTENTS
Trends and Future Challenges in Building Automation and Control Systems
The Technology Behind
The What, Why and Where of Standards
What Has to be Covered by Open Communication Standards for Building Automation and Control Systems?
BACnet versus LonMark
European Standardization
International Standardization
BACnet, EIB/KNX, LonMark, etc. - Where to Use What
OPC - A New Alternative?
Some Actual Customer Needs Covered by Web-Technology
Embedded Web-Server versus Application Server
Application Server - Target Groups
Application Server - Solutions
General System Architecture
Will Web-Technology Replace BACnet?
Summary and Conclusions

[an error occurred while processing this directive]

TRENDS AND FUTURE CHALLENGES IN BUILDING AUTOMATION AND CONTROL SYSTEMS

Facilities must meet business needs more and more closely and reduce operating and maintenance costs. Leaner budgets and environmental considerations demand advanced energy management. Growing expectations for comfort and service require advanced managerial instruments.

Every enterprise has a unique pattern of building management requirements. Freedom to choose the right solution to meet specific needs is crucial.

It's time to change the way we look at facility and building management. Only a coherent automation and control framework, within which many different systems are to evolve, can remove the barriers to progress. A common interface, Open, normative system standards, Web Technology and advanced integration are prerequisites for success.

Below is a list of actual customer requirements.

• Reduction of initial investments

• Building Automation uses existing IT and CT infrastructure

• A unique user interface for all building disciplines (HVAC, Lighting, Lifts, Fire, Access, Intrusion, …) 

• Customers want higher supplier independence in case of later system enhancement

• Reduction of operating, energy and maintenance costs

• Mobile operators want to operate the building at any time, from everywhere, immediately

• Less trained operator needs "obvious" operating

• Technical competence centre serves many buildings in a defined geographical region

• Growing expectations for comfort and service

• Reduced energy consumption

… the answer: System and Communication Standards and Web-Technology

THE TECHNOLOGY BEHIND

[an error occurred while processing this directive]System Standards for BACS 
The main expenditure is in the efforts for the complete engineering of BACS plants. The costs are in direct relation to the type and amount of functions necessary. The I/O points just provide - or use - the signals. To avoid unnecessary risks for costs at tendering, execution and billing the use of standardized terms is necessary. Free and fair competition, including the potential for innovations, is only possible by specifications using a unique language for all parties involved. The CEN/TC247WG3 has developed a set of standards for a common understanding of hardware and functions. This definition of functions helps i.e. in the case of system integration to determine the tasks of each involved system and to calculate the proper costs for the system engineering. This work has been adopted by the relevant ISO committee TC205.

Communication Standards for BACS 
Standardised communication protocols such as BACnetTM, EIB/KNX, LONMARK^®, etc. and interfacing standards such as OPC (OLE for Process Control) allow exchange of information between different manufactures devices, systems and programs in an agreed way. Communication standards are the prerequisite for cost efficient integration of various manufactures subsystems.

IT & Web Technology State-of-the-Art 
IT and Web-Technology is widely used by BACS. This allows smooth data-exchange with the customer's office automation system and business process. Existing communication infrastructure such as LAN / WAN (Wide Area Networks) can be shared - which reduces cabling cost and allows flexible solutions. Web technology brings additional benefits such as easier and central software updates & maintenance / local operation using slim, low cost clients (only a browser is needed).

Some of the most important technologies from the IT world are: Ethernet, TCP/IP, Int@net, Web, OLE/COM, XML, SOAP.

Communication standards for BACS IT & Web technology

THE WHAT, WHY AND WHERE OF STANDARDS

Efficiency Means Profitability 
An integrated management system enables a building to be operated more easily and with greater efficiency, so helping to reduce operating costs and increase profitability. Instead of using a variety of dedicated devices for operation, the facility manager's team can perform all activities from operator stations with the same look and feel, keeping training and operating costs to a minimum and reducing the likelihood of incorrect operations. Dedicated security systems, of course, send their alarms to the security guards and the fire brigade. However, if information of all systems in the building is brought together to one or to many networked operator stations with unique human interface, faults and alarms can be identified and dealt with immediately, for the better protection of people and property.

Precondition for System Integration 
Stable and reliable communication is one precondition for system integration. Protocols and functions must be exactly described if successful performance and integration is to take place. In the case of multi vendor systems integration, the right contracts, mutual coordination and agreed upon responsibility is indispensable. Nevertheless, there are practical limits to implementation:

• The fusion of different concepts is difficult and demands considerable investment of time and energy. This is hardly justifiable for a single application!

• The delimitation of responsibility at the interfaces and uncoordinated alterations in the subsystems represent almost intolerable complications for integration.

To overcome these limits the industry agreed on communication standards, which describe the basic functions in the disciplines of HVAC, lighting, safety, etc. These basic functions defined as objects can then be exchanged by different services, disciplines or management systems easily and with a minimum of effort via communication networks, routers, gateways etc.

Integration will only be really successful, however, when standard protocols are implemented internally within the individual systems. This eliminates complex conversion and, above all, too much loss of functionality. The standardization of engineering data and the engineering and commissioning workflow in the future will further help to lower costs and to increase the reliability and functionality of integrated systems! 

Typical applications in a building: air, water, lighting and sun-blinds, heating, cooling, ventilation, energy distribution, safety and security, refrigeration, transportation and ancillary systems.

(The user; source: Michael Newman, ASHRAE)

Integration plays a key role in bringing down operating costs and allows us to look at the building as one single process.

WHAT HAS TO BE COVERED BY OPEN COMMUNICATION STANDARDS FOR BUILDING AUTOMATION AND CONTROL SYSTEMS?

I would like to highlight some concepts on which to focus our attention when deciding which protocol is the right solution for BACS.

The involved parties should consider different topics when deciding which standard protocol fulfils the requirement. The following main issues have to be addressed:

The European standardization committee had to weigh up over 100 issues for the selection of the present pre-standard protocols.

BACnet VERSUS LONMARK

If we apply above criteria to BACnet^TM and LonMark^® we get the following picture.

…. and as we can see, a clear positioning where to use what:

LonMark^® 
[an error occurred while processing this directive] We talk about LonMark, because the LonTalk^® protocol is a proprietary product from Echelon Inc. The defined LonMark templates cover the functionality needed for the field level: Data exchange and interactions between devices on the same bus, monitoring of values such as temperatures, operating states and simple control functions e.g. lights on/off, etc. The field device functions are normally implemented in one single chip (the Neuron^® and the LonWorks^® transceivers support a range of transmission media, e.g. the inexpensive Cat. 4 cables. In addition there is a relatively large (>180) number of manufacturers available to choose devices for building applications from, but the product's ability for interoperation has to be checked by the system integrator. 

All this may give the LonWorks based products a future potential to network at the field level. But "normal" sensors and actuators cost less - from a point of view without taking the overall system costs and the engineering into account.

EIB/KONNEX
The application of a standardized and internationally accepted protocol for specific applications is still no guarantee that a device by manufacturer A can be exchanged for one supplied by manufacturer B. For this purpose, further standardization of design and of the exact functionality of a device is necessary. One step in this direction has been made by the EIB concept for building applications. Each of the more than 5,000 available EIB devices is supplied with its relevant parameterization data stored on a floppy disc which can be used - together with the neutral EIBA tool software ETS (11.000 licenses in use) - by the installer for combination. (EIBA = European Installation Bus Association, Brussels/Belgium). 

There are 65 certified training organizations and 15 national EIBA Organizations. More than 70.000 projects have been finished all over the world. 

Today's market provides such an extreme diversity of applications that an all-comprehensive testing procedure is hardly feasible under economic aspects. Testing is less arduous and expensive for less sophisticated devices (e.g. devices for the European Installation Bus EIB) whose range of functions has been defined through "interworking standards". The EIB Functional blocks describe not only the semantics of a function in English language, but also define how to access the services associated with that function. This is done on the base of Data Points. 

The EIB Communications Protocol is part of ANSI EIA 776.1 to .5 standard and incorporates a CEBus - EIB Router. 

EIBA has been assigned a unique BACnet vendor ID (74, decimal) by the ASHRAE organization. This vendor ID must be used for the mappings of EIB applications to BACnet. The document ISO/TC205WG3 BACnet draft addendum H.5 describes how European Installation Bus (EIB) Functional Blocks, which are part of Object Interface Specifications (ObIS) of the Interworking Model defined by the EIB Association (EIBA), are mapped to the corresponding Building Automation and Control networks (BACnet) object model definitions.

EIB - the true interchangeability

In a convergence project the three European Associations EIBA, BCI, EHSA have been migrated to the Konnex Association (March 2001) and the protocols "EIB", "BatiBus" and "EHS" grow together to the "KNX" (Konnex) protocol.

BACnet
In most other protocols there are some basic BACS functionalities missing for open interoperability. Services and functions which are needed for mature building management such as: Trend / History, Time Scheduling, Back-up/ Restore, Remote Management, Alarm Distribution, and many others.

BACnet covers all these requirements. In addition BACnet supports, in a flexible way, modern IT and networking technology such as Ethernet and IP (Internet Protocol) as this is needed in today's modern IT environments.

BACnet is therefore the best choice for the upper system levels where a broader functionality and full IT compliance is needed.

EUROPEAN STANDARDIZATION

After having analysed these main topics in order to decide which standard protocols are preferred for our BACS system, we should have a look also at the standardization situation in Europe, because there, the open communication was started earlier then anywhere else.  Implementation began in Germany in 1984 with IBM's FACN protocol, followed by the FND in 1987.

European pre-standards for communication protocols in BACS:

As we can see there is not just one single communication standard - but for each functional "system level" there is a choice of various standards with different functionalities and benefits. Since there were over 20 protocols in the beginning of the standardization process (1990), the decision was to limit the number to three per functional level.  So the consensus, rather than the compromise, is shown in the picture. Fortunately the experimental standards may only stay for 5 years, then a new decision must be made. The FND was withdrawn as a standard in 2001, but it still is there as a "private" public document. The experts within CEN decided to treat the other protocols also in relation to their acceptance in the marketplace.

BACnet is the only standard covering management, automation and field level functions in an open standardized way, supporting various data transportation methods. This brings additional benefits for customers and system integrators: Since no protocol conversion is needed we get higher functionality at lower cost (no gateways needed) - the upper two system levels can be collapsed and even more complex field devices can be integrated.

On the field level both EIB/KNX and LonMark have future potential. EIB, BATIbus and EHS are about to evolve to one new standard: KONNEX (KNX), the EIBA has migrated to the Konnex Association covering over one hundred producers.

• LonMark is well suited for complex field level applications where a certain engineerable flexibility is required.

• KONNEX (KNX) will be optimal for standard solutions - cost effective, simple and easy to implement.

INTERNATIONAL STANDARDIZATION

The ISO/TC205 committee treats the Building Automation and Control System in its WG3 standard. This covers hardware, functions, applications, communication, conformance testing, project and system implementation. There is only one protocol without any level dedication: BACnet as ANSI/ASHRAE 135. It is expected that the EIB/KONNEX Functional Blocks, which are part of the EIB Object Interface Specification, will become a part of the BACnet specification by mapping them to the BACnet objects. It is also expected to have the first worldwide enquiry in 2002. This ISO enquiry will be also be done in parallel among European countries, so we can expect to have one protocol standard for BACS all over.

BACnet, EIB/KNX, LONMARK, ETC. - WHERE TO USE WHAT

So where to use what? After considering all the above the picture gets clearer.

On the floors, for Room Automation, where a large number of devices have to be linked together and to interact - EIB/KNX for real open craftsmen solutions and - LonMark for more complex engineered solutions. Both offer good cost-effective products covering the functionality needed.

In the plant rooms - more functionality is needed - this functionality is currently best covered in a standard way by BACnet. For BACnet the most effective physical media has to be selected, e.g. the same as for the floors. For management applications we need in addition to BACnet's high functionality also its IT compliance, so here BACnet on Ethernet/IP will cover the requirements.

OPC - A NEW ALTERNATIVE?

OPC stands for "OLE for Process Control", a communication standard based on OLE/COM technology that brings the same benefits to industrial hardware and software that standard printer drivers brought to word processing.

Based on Microsoft's OLE, COM (Component Object Model) and DCOM (Distributed Object Model) technologies, OPC consists of standard interfaces, properties and methods for use in process control and manufacturing-automation applications.

The OLE/COM technologies define how individual standard components can interact and share data.

OPC provides an interfacing standard for factory automation where every system and every communication driver can freely connect and communicate. Having such a standard, the communication and interactions between different applications, from the plant to the MIS (Management Information System), becomes easier with truly open enterprise communication.

OPC… what it is not? 
OPC is not a new standard bus or a universal protocol, but it is an interface definition defined by different companies from industrial automation and Microsoft.

The complex data structures definition are not yet fully defined in OPC, leaving them dependent on the application. From the driver point of view, it is still vendor specific.

SOME ACTUAL CUSTOMER NEEDS COVERED BY WEB-TECHNOLOGY

Web technology is found almost everywhere. The following attributes go with the Internet, which are also valid for web applications within BACS:

• Global connectivity

• Global companies need global BMS information

• Easy to operate

• Access at any time, from everywhere, immediately

• Use mainstream technology

• IT-world compliance 

• Slim, inexpensive clients

In addition, the web technology facilitates and centralises software maintenance, updates and support. Last but not least, the web offers new services and opens up new business opportunities.

EMBEDDED WEB-SERVER VERSUS APPLICATION SERVER

Web technology can be implemented in almost any device from small embedded systems like a DDC controller to large application servers. Do we need in future still conventional management stations or can they be fully replaced by embedded systems?

Let's look where BACS functionality can be realised using web technology:

As we can see, for small and simple applications where functionality such as graphical plant operation, alarming, simple trending and reports are needed embedded Web-Servers can and will fully cover this area. 

For larger and/or distributed installations where centralised functions such as navigation between various sites, alarm dispatching, data evaluation, billing, statistics, maintenance management, etc. are required a central application server will be needed. 

Web-embedded systems and application servers are complementary. Functionality and data management is distributed on autonomous servers within an intranet / internet.

APPLICATION SERVER - TARGET GROUPS

Application servers will address the following target groups:

APPLICATION SERVER - SOLUTIONS

The application server will primarily support the following technical and technological solutions:

Operating

• Reporting

• Alarm handling

• Plant optimisation

• Security

• Lighting

• HVAC

• Media access

• Room Automation …

Data Management

• Reporting

• Energy data evaluation

• Consumption Control

• Process data evaluation

• Trends

• Billing

• Error and System Log …

Service and Maintenance

• Application libraries

• Customer specific solutions and programs

• Online documentation 

• Knowledge database

• Preventive maintenance information 

• Support / Hotline · …

Integration Platform

• Integration on operating level (e.g. using ActiveX)

• Subsystem integration via standards communication protocols and interfaces (BACnet, EIB/KNX, LONMARK, OPC, ... )

• Data exchange with customers business processes, office environment, etc.

GENERAL SYSTEM ARCHITECTURE

In the traditional Windows based management stations business logic and presentation (using e.g. MS Windows) are running on the same HW platform, normally a personal computer. With state-of-the-art web technology the presentation layer and the business logic is separated. 

To view and operate the system only a simple web browser is needed, which runs on a large variety of clients. The core part, the business logic, where functions such as alarm routing, trend / history data evaluation, etc. are realised, remains on a dedicated machine, the application server.

Real-time process data is handled by dedicated DDC controllers optimised for the various building management disciplines. 

Standard database, preferably the leading IT standards SQL / MSDE are used to store engineering and process data on the management level.

WILL WEB-TECHNOLOGY REPLACE BACnet?

Communication protocol between web-server and clients is based on the leading edge Internet technology such as HTML, DHTML, XML, SOAP, .NET-framework. These standards out of the IT world are optimised for their specific purposes: to transmit data needed for presentation by slim to fat clients through firewalls over the Intranet / Internet.

For communication between subsystems and application server the specific BACS functionality such as trending / history, alarming, scheduling etc. has to be covered. Here BACnet is the right choice. Only BACnet currently provides this functionality within an open standard format - to assure interoperability between different systems in an open way.

So we see both BACnet & the Web are needed!

SUMMARY AND CONCLUSIONS

• Proprietary communication protocol will lose importance.

• There will be a limited number of communication and interfacing standards which will dominate.

• BACnet, EIB/KNX, LONMARK, OPC have good future potential.

• Debundling - best of breed solution for every level / application.

• More and more integration of all technical applications.

• Turnkey solutions from one supplier.

• Web technology will be used on operating level.

• Both embedded servers and applications servers will play important roles and allow distributed functionality and data management in geographical networks.

• Technologies with very good future potential are: HTML, DHTML, XML, SOAP, NET-framework.

• BACnet, OPC and Web are complementary technologies. 

• Application Service Providers will offer new ways to operate optimise and manage a building.

And do not forget: We have tried to explain in which direction the building automation and control industry is moving - as usual, however the marketplace will take the final decision!

More Articles

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

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