Printer Friendly

BACnet[R] down under.


In this article I attempt to provide a broad impression of the Australian building automation scene, particularly within a BACnet perspective. Some of the more prevalent building automation and control system (BACS) and BACnet problem areas are highlighted and discussed. The working environment of the BACS industry is considered within the context of the various imperatives and drivers that impact on the stakeholders.

Bidding Environment

The way bids are made, accepted and implemented impact how a BACS is delivered, and what is implemented. The contractual arrangement with which a BACS vendor is bound dictates the degree of separation from the owner or end user. This is set in the course of the bidding process and precedes implementation. The greater the degree of separation, the lesser is the opportunity to deal directly with and influence the building owner or end user.

In Australia three main bid paths exist for BACS: contract with the head contractor or developer; subcontract to the mechanical services contractor; and direct contract with the owner/end user. The further the degree of separation between the owner and BACS supplier, the greater the markups by the intermediaries. This also can give the owner/end user a negative perception of BACS costing, without the opportunity for the BACS vendor to have formal direct discussion with the building owner.

Contract with Head Contractor. This is uncommon but occurs from time to time, especially on large projects. It is only once removed from direct dealing and contract with the owner/end user. There also are speculative building projects, without an initial owner in the traditional sense. Overall approximate occurrence is about 10% (Figure 1).

Subcontract to Mechanical Services Contractor. This is by far the most common contractual arrangement and delivery mode. The degree of separation between the controls supplier and the owner/end user is further increased. There is no contractual relationship between the owner/end user. Communication is via other parties, which may or may not faithfully convey relevant communications, without imposing their interests. Overall approximate occurrence is about 70% (Figure 2).

Direct Contract with Owner/End User. This is arguably the most desirable arrangement for both the BACS supplier and the owner/end user. The former can deal directly with the party that will use the controls system and is able to tailor the system to meet their specific needs, without trying to interpret tender documents, particularly at bid times. It also gives the BACS supplier the opportunity to present various options, which may be precluded or filtered via the formalities of dealing through other parties (Figure 3).




Often, when aging BACS are replaced, if the provider has satisfied the owner needs they are in the ideal position to be awarded the upgrade, by negotiation and direct contract with the owner.

This delivery mode has the advantage of minimizing intermediary markups due to the direct owner-BACS supplier relationship. Overall approximate occurrence is about 20% (Figure 4).

So, how does this impact on the provision of BACnet systems?

Clearly, apart from success based on lowest price, for best outcomes vendors need to position themselves such that they are able to deal as directly as possible with the stakeholders and decision makers. This is particularly true when BACnet systems are not specifically called up in tender documents. In addition, contract variations discussions also may have better vendor outcomes if the BACnet vendor is able to present a case directly to the final decision maker, as the various parties have their own objectives and interests, which may not be complementary.

What Owners Want

For reasons associated with minimizing operational costs and maximizing profits, building owners require BACS that are characterized by flexibility, ease of operation, low capital expenditure, together with low operating cost. This includes:

* High reliability (infrequent breakdowns);

* High availability (short outages when breakdowns occur);

* Flexibility, both in operation and in obtaining competitive alternatives;

* Interoperability between BACSs or subsystems;

* Reasonable, nonpredatory service costs;

* Minimizing built-in obsolescence;

* Plug-and-play devices and features;

* Ability to access BACS data and migrate it across technical (e.g., energy management) and management (e.g., property management, accounting) systems; and

* Ability to manipulate data for accounting, energy management and establishment of key performance indices (KPI) for building performance tracking purposes.

Furthermore, in recent years public concerns and trailing government interest in matters that impact the environment has led to emerging powerful drivers to reduce energy consumption, with a concomitant reduction in greenhouse emissions (GHE). It's not that building owners and corporate property portfolio managers have necessarily suddenly seen the light with respect to GHE, but the negative publicity associated with energy waste and the deleterious effect on the environment can impact the ease of leasing, as well as the rates at which building space can be let.

Corporations increasingly are dressing up as being responsible corporate citizens, and environmentally friendly. This also is translated into their leasing requirements. Effectively, this means that they require energy friendly buildings to lease or own. Consider the negative impact of a publicly "green" corporation located in an energy voracious building.

BACnet has been the unifying medium that has enabled and facilitated the interoperability between BACSs. Interoperability has provided the means of accessing data across systems, and controlling multivendor system operations such that comfortable building environments are delivered at minimum energy consumption and reduced GHE. Some property owners have expressed interest and desire to display such details in select, high-exposure areas of their building, campus or establishment for public view to demonstrate good corporate citizenship.

Among the most detested BACS issues faced by building owners is the proprietary system lock-in and associated virtual total dependency on vendors to provide parts, service and involvement in system modifications. The temptation to take advantage of the owner or end user is often too great to resist.

Just prior to the availability of BACnet, a large Australian property owner/manager was so annoyed and disillusioned by the rampant overcharging for these services by proprietary system vendors that for several years it decided not to install any BACS, instead using electronic time clocks and simple controls. This was done as an interim measure while it assessed alternatives that would enable it to reclaim independence and flexibility.


When the first BACnet seminar was held in Sydney, Australia, in 1999, following the ISO/TC205 meeting in Canberra, the knowledge base among the specifying fraternity was low. Since then the knowledge base has increased somewhat, but is still relatively low compared to that of the United States, Canada and Europe. The main reason for this was the failure to establish BACnet training programs for specifiers and users in Australia, although there are training programs elsewhere.

However, even the marketing of BACnet systems by vendors has been rather ad hoc and at times bordering on misleading, as some vendors purport that their BACnet system is somehow better than those of their competitors. The latter approach has often confused potential clients, particularly those that were reasonably informed and understood that in using BACnet systems provides transparency through interoperability.

This is contrary to one of the core tenets of BACnet, which is the provision of a method by which computer-based control equipment and devices from disparate vendors can operate together (interoperate). This is achieved through the use of the BACnet communication protocol that enables messages between system components to be exchanged and understood. If one BACnet system were truly better than another, this interoperability would not be able to be effected. Indeed, BACnet can be seen as providing a level playing field as all BACnet products can be interconnected and provide interoperability.

Although, the knowledge base is comparatively low presently, the perceived benefits of BACnet are relatively high. A significant portion of this has been driven by the needs of developers, building owners and end users.

In Australia the main BACS specifiers are mechanical services consulting engineers. Consequently, the communications end of the BACS is not their forte. This is a practical problem that needs to be addressed. Some universities are aware of this and are offering degrees in mechatronics. Hopefully, this will enhance the profession, as younger engineers will have the additional skills to deal with a fast-moving area of technology that has been an uncomfortably imposed burden on traditional mechanical services engineers.



Some multidisciplinary consulting practices also have IT personnel. My experience is that often the two do not work together in a seamless manner. The bid documents produced are invariably akin to two detached sections, without an overarching common perspective.

Another important factor constraining good BACS specifications is few engineers from the BACS industry have migrated to consultancies. Specifications are frequently regurgitated, with a cutand-paste history, resulting in inaccuracies and inconsistencies. The amalgam of past systems and projects give rise to unclear control strategies that are left to BACS vendors to sort out--aren't they the controls experts? These form the legacies of future implementation and system problems.

On one occasion I was tasked with assessing the BACnet BACS capability of a well-known consultancy. In checking the bona fides, it turned out that not one of the listed reference sites was BACnet. When questioned about BACnet and client requirement for interoperability, the response regarding the various protocols used was that "they're all the same, more or less."

Another factor one needs to be wary of is the alternative offer. Often, a bidder makes a noncomplying bid. For a BACnet specified project, a non-BACnet bid may be offered at a cost saving. As a result of budget constraints, project managers may find the alternative offer attractive. Building owners should be clear of the issues in contemplating such alternatives, particularly when making their final decision. If interoperability is a real requirement, then the cost of being locked-in by proprietary protocols and restricted to using only that vendor for system extension (without competitive alternatives) should be carefully considered and the ramifications understood.

Current BACS Installation Specification

Over the last 12 months new projects (in Australia's more populous eastern states of Queensland, New South Wales and Victoria) requiring BACS have specified various communication protocols that can be grouped as follows (Figure 5):

* BACnet-only: 25%

* BACnet or LonWorks: 50%--(the majority ending up BACnet by market forces)

* LonWorks: 5 %

* Unstated: 20%--(usually retrofits, or where client knowledge is poor)

(Information assembled from major BACS vendors and is representative in nature.) From this it appears that BACnet systems are becoming the preferred BACS.

BACS Management

It is not sufficient to specify a BACS, even a BACnet system, without having a management plan in place before implementation.

The plan should include such matters as:

* As-built documentation and updating procedures;

* A process by means of which site changes are recorded e.g., software updates etc.;

* Testing and commissioning data records, including as built settings.

* Use of LANs, routers and gateways (the latter is a problem because it is difficult to maintain long term, with attendant warranty and responsibility issues);

* Interoperability between BACnet systems;

* Dealing with open and proprietary protocols; and

* Data storage, data migration and management.

A specific, site/campus/establishment BACnet system identification is required. BACS contractors need to strictly observe the following numbering scheme for each site:

1. MAC address;

2. Device Instance; and

3. Network Number.

In BACnet, each device has a unique MAC Address and Network Number that identifies it on the Internetwork. The Device Instance is an allocated number that uniquely identifies a BACnet device on any BACnet Internetwork. This numbering regime must be strictly enforced, as clashing device instance numbers can lead to system malfunction. This will ensure that changes, upgrades and system extensions can be implemented consistently and as seamlessly as possible. If strictly enforced, this will avoid conflicts in numbering, which can lead to system malfunctions, especially in multivendor sites.

In multivendor sites it is not uncommon for controllers to arrive, and be installed, with the same factory default settings. Vigilance and enforcement of site BACnet standards are essential for trouble-free outcomes.

Education and Training

In Australia, this needs urgent redress to ensure that progress in the marketing, acceptance and implementation of BACnet systems is not constrained. The lack of suitable education and training strikes at the heart of many issues concerning the proper specification, testing, commissioning and assessment of BACnet BACS.

Education is required for consultants, engineering personnel, system integrators, building owners and service providers. Most of the problems of poor specifications, inept implementation and operation arise from a lack of BACnet education and training opportunities. Fortunately, I believe that with a little planned effort this problem area can be easily addressed, turned around and greatly improved.

Unfortunately, the BACnet system vendors in Australia have been found wanting in championing and facilitating this need. Indeed, public debate has been confused, leaving it up to potential users and specifiers to make their own decisions, based on poor and undifferentiated comparative information. As a result, although progress in BACnet specification and acceptance has been quite reasonable, it should be better, and based on sound reasons rather than on general vague acknowledgement that "it's good."

Graphics and Perception

How does a vendor differentiate from competitors? When vendor representatives call to demonstrate the benefits of their particular BACS offerings, they invariably bring along their trusty laptop (sometimes a projector). This is the customer entry into their BACS world. Our perception is influenced by what we see.

Because of the interoperable nature of BACnet systems, properly implemented, it often comes down to how the graphics appear on the screen and the feel in navigating the system. Some vendors have even gone to the extent of implying that their BACnet BACS is better than that of their competitors, when the real difference is mostly in the graphic representation. The importance of the "touch and feel" aspect of a BACS should not be underestimated, as operators need to quickly see what's happening in a building, access relevant equipment and data and make decisions. Aids such as colors that indicate status such as room temperature (a range of preprogrammed colors to, for example, indicate setpoint deviation) can be quite useful to an operator. The floor status can be seen at a glance of a display.

Graphics are not dealt with by the BACnet standard, making them a powerful vendor differentiator. It can also be a useful visual marketing tool by giving comfort to potential and existing tenants. Care should be taken to ensure that the graphics are not a means of achieving a "proprietary" BACnet BACS, particularly in combination with a proprietary energy management package that may be offered by a vendor (sometimes "free"). Some vendors perceive that the graphics pages create an important customer-vendor nexus in that, notwithstanding a multivendor site, service calls initially would be made to the vendor that is associated with the graphics--an income stream is associated with this.

Testing and Commissioning

The crucial areas that impact directly on functionality and multivendor interoperability are the testing, commissioning and system acceptance processes.

Often, BACS are only partially tested. Not all blame should be leveled at consultants, as fee structures frequently do not allow for the in-depth process that really is required to not only ensure that what was contracted actually is delivered, but that all subsystems operate correctly within themselves, and between each other.

I'm aware of few installations specifically tested for BACnet conformance. Indeed, I am aware of several significant projects in recent years that were sold and installed as being BACnet but were not. At one establishment, which was tested a relatively short time after installation by a BACnet vendor, the job was found not to incorporate any BACnet equipment or devices. It was rather embarrassing to the establishment management that their existing, and relatively new BACS, was not a BACnet system at all, but a proprietary system. Further, the fact that the new BACnet BACS could not interoperate with the existing system added to their operational and managerial woes. All of this could have been avoided if suitable BACnet acceptance testing had been undertaken.

The Handover

This is an important aspect of all BACS projects. It is crucial for BACnet projects to ensure that conformance is as required to provide proper system operation, interoperability and future seamless BACS expandability. The handover is not, as is often perceived, the mere physical handing over of a set of documents to the owner or end user at the termination of a project, and happily walking away. Mission accomplished.

The handover should incorporate the inclusion of the service personnel and BACS operators in the process, sometime prior to the handover in the administrative and contractual sense. This will not only establish an inclusive spirit but give the various parties that are not part of the design and construction phases the opportunity to gain early exposure to the BACS and perhaps provide some valuable inputs and insights to post-implementation operation and maintenance. It also assists in developing a sense of ownership.

Quite often the vendor's service department becomes involved only after project practical completion has been achieved without an overlapping transition. Some vendors even have an internal policy that their service department is only involved some time after practical completion. Obviously, this would not be conducive to a seamless transition as would be expected by a building owner.

The reasons are many and varied, and include:

* Different vendor profit centers involved;

* Service department involvement in the transition phase is not included in the bid pricing;

* No contractual relationship with the service departments;

* Understaffed service departments too busy to be involved when not needed;

* Time pressures at project completion phase (the BACS is usually the last system commissioned); and * Operations not adequately included in BACS delivery process (this occurs more frequently than one would imagine).

The reality of the bidding processes is that generally one gets what one pays for. The importance of the transitions from the implementation to service and operation phases must be appropriately addressed in specifications and bidding negotiations, otherwise it will be a latent problem area. The service and operation personnel will not be adequately familiar with the system and this could initially result in slow repair time, leading to lower BACS availability and poor vendor perception.


Generally, there are three basic type of maintenance: comprehensive, selective and breakdown.

Comprehensive. This encompasses a broad range of involvement in BACS maintenance. It is the most expensive option, but provides the best state of system readiness and capability. The degree of comprehensiveness can be tailored to meet needs. Breakdowns and call-outs usually are included in the overall cost.

Selective. This is a derivative of the previous. However, the requirements are more narrowly defined, and although call-outs would not be included normally, breakdown service usually is.

Breakdown. This is the lowest category and cheapest form of maintenance. There is usually no requirement for ongoing system maintenance or assessment. The arrangements are merely an agreed hourly rate to visit the site to address operational problems on an ad hoc, needs-only basis.

Due to the unplanned nature of such service, it is difficult to obtain short response-time arrangements from service providers, or responsibility regarding system performance.

Generally, the BACS industry has operated on a differential pricing structure with lower profit margins for system supply and installation. The bulk of profits was obtained (and still is) from system maintenance and support over the system operational life. This was a main reason behind the lock-in and captive client mentality of BACS vendors. It impacted their bottom lines. In general, good BACS maintenance should pay for itself by delivering reduced service call-outs, reduced energy use and reduced energy costs.

An annual comprehensive maintenance program would include:

* Checking field devices for correct operation;

* Calibration checks;

* Checking and upgrading application software;

* Checking and upgrading the Web server (if installed), fire walls and virus protection;

* Checking all controller operation;

* Upgrading of operation and maintenance manuals;

* Checking communication network changes, including routers and gateways;

* Checking BACnet operation and interoperability; and

* Reporting on findings, together with recommendations arising from them.

Using gateways can introduce maintenance and interoperability problems. Be careful that proprietary data is not "flagged-off" by the non-BACnet party thus limiting system accessibility, functionality and flexibility. Future maintenance could be impacted if a product or protocol is no longer supported. Although gateways enable protocol translations and use of non-BACnet products (e.g., Modbus), these can become an extra point of failure and a difference that can become difficult to maintain.

A well-maintained, properly designed BACS will deliver a finely tuned building or establishment-wide control system. Additional benefits include:

* By accurately monitoring gas and electrical loads, energy consumption can be minimized, with attendant reduction in energy costs;

* Water consumption can be reduced with improved monitoring and control;

* Reduced energy use by more efficient plant and system management;

* Lower GHE due to improved plant performance;

* Prompt attention to faults and malfunctions due to fast system feedback;

* Increased system availability; and

* Enhanced customer satisfaction due to shorter response times and reduced problems that are experienced.

The Challenge for BACnet

In his seminal and incisive (and still very relevant) 1960 article Marketing Myopia, Theodore Leavitt, (1) observed that every industry was, at some point in time, a growth industry with managers convincing themselves that this trend was assured. In a herd-like mentality they convince themselves that there are no viable competitive substitutes. However, over time, decline invariably sets in for a variety of reasons, complacency and competitive market forces not being the least. Vigilance is a key to ongoing success.

The hard work that preceded the establishment of BACnet as ASHRAE and ISO standards must be maintained to ensure its continued usefulness and viability.

I believe that usefulness is the key. If it's not useful it won't be used, and decline will undoubtedly follow suit. The key is an ongoing ability for users to visualize BACnet as a great platform for connectivity, accessibility and interoperability.

Usefulness includes the ability and propensity to follow, facilitate and incorporate new communication technologies. This area has seen tremendous changes in recent years, without apparent abatement. In the past, the BACS industry has been rather slow to absorb some of these technological innovations. New technologies will present increased demands on BACS and BACnet. The challenge is to be able to address these demands, and to do so in a timely manner.

Building owners, who are often not necessarily well versed in BACS, ask why not just use an Internet-based system with suitable password protection, and IP addressing? Why the need for BACnet? Most PC users have experienced World Wide Web features that include accessibility and connectivity between establishments, and individual PC users. Why can't this be applied to BACS? Why can't we have plug-and-play flexibility? What's so difficult about this?

In the longer term, such queries and aspirations cannot be ignored. Now that the genie is out of the bottle, the bad old days of lock-ins and system constraints are well and truly in the past, with customer expectations now preceding and preempting market offerings. This is often as a result of exposure to technological innovations from industries other than BACS (particularly IT).

Although I've not dealt with this important aspect to any great degree, it is encouraging to note that ISO/TC205 has seen it appropriate to address BACnet implementation by identifying the practical needs and to this end has ISO 16484--Part 7 dealing with project implementation under development. This is a useful initiative that I strongly support.


Frustrated building owners wishing to avoid lock-ins and predatory pricing that were frequent features of proprietary BACS protocols in the past largely drove the importance of having a truly open BACS communications protocol. ASHRAE responded to these drivers by developing the BACnet protocol, specifically for building services. With the quick adoption of BACnet, the problems of the past are being quickly forgotten or overlooked.

There are aspects of business imperatives that are common, and those that differ between building owners and operators, developers, and BACS vendors, as well as other contractors having material interest in the BACS bidding and implementation processes. These drivers must be properly understood in order to achieve a good outcome for all. A number of these issues were canvassed from different perspectives, and clearly there are areas of potential conflict, or at least where problems could occur if not properly addressed.

In Australia, the matter of appropriate education and training needs to be better addressed to achieve enhanced market penetration of BACnet BACS, as well as enhanced BACS performance.

Significant aspects that require consideration in the effective implementation of a BACnet BACS are outlined together with operational and maintenance issues, as well as the importance of having a BACS and BACnet management plan.


(1.) Leavitt, T. 1960. "Marketing myopia." Harvard Business Review July-August.

About the Author

Edvin Krsevan, C.Eng., is managing director of Intek Consulting. He is a member of ISO technical committee ISO/TC205, Building Environment Design, Working Group 3, Building Control Systems Design.
COPYRIGHT 2007 American Society of Heating, Refrigerating, and Air-Conditioning Engineers, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2007 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:BACnet Today; building automation and control network in Australia
Author:Krsevan, Edvin
Publication:ASHRAE Journal
Article Type:Technical report
Geographic Code:8AUST
Date:Nov 1, 2007
Previous Article:BACnet[R] for megachurch.
Next Article:BACnet[R] a capital idea.

Terms of use | Privacy policy | Copyright © 2022 Farlex, Inc. | Feedback | For webmasters |