November 2009 |
[an error occurred while processing this directive] |
A “BACnet System” Procurement Challenge The fallacy of equating “standard protocol” with “standard system” |
Andy McMillan
President
|
Introduction
I’m a bit particular about words. I’m
particular because I’m persuaded that words often convey more (or in some cases
less) than their literal meaning. And the problem is compounded by the fact
that the nature of the “more” (or less) is often specific to individual
listeners and their personal contexts. Within the community of energy
management and building automation professionals, the words “BACnet System” seem
like a reasonable shortcut for the words “a system that utilizes the BACnet
protocol.” We ought to remember, however, that this is only a shortcut. And
when used within a broader business community, particularly purchasing, it’s a
shortcut that can lead to problems.
[an error occurred while processing this directive] |
[an error occurred while processing this directive] |
What is and
isn’t Standard
BACnet is a standard but devices and systems that incorporate BACnet are not.
One reason for this is that BACnet specifies how a device must
communicate but it does not specify what a given device must
communicate. By way of example let us suppose we have two air handlers that
both incorporate BACnet but one keeps track of fan motor runtime as a
BACnet-visible value and the other does not. They could both reasonably be
called “BACnet air handlers” but they provide different functionality and
potentially different value propositions. When you consider that a simple
packaged rooftop unit incorporating BACnet can have 50-100 readable values or
writable control points it becomes clear that not all BACnet devices are
necessarily created “equal” … and that is just at the device level. Combine a
few hundred devices and controllers in a system, add the unique attributes of
the programming and system management software, stir in the added variables of
system reliability, redundancy and extensibility and it becomes clear that
while BACnet is a standard, the systems incorporating BACnet are not “standard”
at all. Now, some people might say it’s just semantics. And perhaps they’re
right. But based on some of the energy management procurement processes I have
seen lately, I have to wonder if that “just semantics” is leading people down
the wrong path.
Components vs
Systems
For many years the BACnet community has
worked hard to ensure that BACnet is a global standard and that it’s implemented
consistently across multiple supplier product lines. BACnet International
devotes substantial resources to the BACnet Testing Lab (BTL) and to annual
device “plugfests” to support that objective. We regularly point out that
BACnet is a global consensus standard and we trumpet the value of standards. We
talk about component interoperability and in some cases even
interchangeability. All of this is good. Users need to understand the power of
standards and how specifying systems that incorporate BACnet can add value to
their building automation investments. However, by promoting BACnet as standard
and then using the shortcut term “BACnet System” we invite the unschooled to
mistakenly extend the concept of “standard” from the communications protocol to
the system. That seems to lead some of them to the conclusion that all “BACnet
Systems” are essentially equivalent and can be procured like commodity products
… even to the point of the “reverse auction” procurement process for an energy
management system I recently encountered.
Reverse
Auction Procurement
Reverse auctions have been around for
more than a decade. They evolved as a “simple” way for buyers to drive down the
cost of components. The essence of reverse auctions is that suppliers bid back
and forth for a well-defined piece of business on the basis of price.
Full-featured web platforms have evolved to support this purchasing model but,
even so, it has its limitations. One of the biggest limitations is that for it
to be effective, the product and its associated transaction attributes (e.g.
lead time, delivery date, etc.) need to be unambiguously defined in terms that
can be readily measured. And therein is the rub. Energy management and
building automation systems are complex so fully defining all of the important
attributes is a huge challenge. Leaving any important attribute undefined
results in suppliers compromising on those unspecified attributes to achieve the
lowest cost and win the business. On the surface the result might look like a
good deal for the buyer. But those compromises might well come back to haunt
the buyer in the long run.
[an error occurred while processing this directive]
Lessons
Learned
At the 2009 BACnet conference in
September I included a “lessons learned” list in my presentation. It was an
attempt to give people new to the BACnet community some insights based on the
experience of people who have already designed and operated systems built around
BACnet. One of those “lessons learned” was that a “BACnet System” is still a
system. The BACnet standard can make system integration faster, simpler and
more effective but it is not a substitute for system expertise, creativity or
design rigor. Nor does BACnet provide any assurance of product quality or
system effectiveness. These come only through knowledge and experience. So, I
encouraged owner/operators to develop a partnership approach to working with
suppliers who have that knowledge and experience.
In the early 1990’s I lived in the Detroit area and was deeply involved in the factory automation industry. I saw first-hand what happens when complex systems procurement is driven from a “first cost” perspective without sufficient focus on supplier partnerships. A prominent proponent of that approach was J. Ignacio Lopez de Arriortua at GM – known throughout the industry as just “Lopez.” As stated in a business school case study years later, “he is credited with saving GM approximately $4 billion in expenses, and potentially causing irreparable harm to the long-term supplier relationships that were key to GM's future competitiveness.” A similar risk applies in the procurement of energy management and building automation systems. These systems will not be static. They will need to evolve over time as regulatory, utility and corporate environments change. Successful evolution will depend on supplier relationships that are supportive and collaborative.
Summary
BACnet is a standard. Systems
incorporating BACnet are not standard. Understanding the difference is
important in establishing a procurement process that builds positive supplier
relationships and generates maximum value in acquiring an energy management or
building automation system.
As always, the views expressed in this column are mine and do not necessarily reflect the position of BACnet International, Teletrol Systems, Philips, ASHRAE, or any other organization. If you want to send comments to me directly, feel free to email me at andysview@arborcoast.com.
[an error occurred while processing this directive]
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]