Innovations in Comfort, Efficiency, and Safety Solutions.
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.
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
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
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
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
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:
has to provide all complex and simple data structures to accomplish daily functions like:
The data approach has to be object oriented.
support services for system start-up, network management and
has to provide independent media access to support modern IT & CT networking standards and cabling systems.
has to allow extensions to provide the possibilities of future innovations.
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 BACnetTM and LonMark® we get the following picture.
. and as we can see, a clear positioning where to use what:
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.
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.
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.
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.
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.
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 companies need global BMS information
Easy to operate
Access at any time, from everywhere, immediately
Use mainstream technology
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:
Energy data evaluation
Process data evaluation
Error and System Log
Service and Maintenance
Customer specific solutions and programs
Preventive maintenance information
Support / Hotline ·
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!
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]