In spite of open protocols there has been a real problem with multi-vendor competitive procurement to keep costs down yet still provide owners with functional, high performance systems. This slide show provides some tips on how to achieve success.

1. Building Automation
Systems
Methods to enable competitive
purchase for expansion projects
without sacrificing performance.

2. All I need is open
protocol, right?



This over-simplified and false belief
may have prevailed for a short time.
Open protocol (BACnet, LON,
MODBus, etc.) is just the starting
point.
If no more effort than “give me
BACnet” is put into specification
writing and quality assurance, failure is
almost guaranteed.

3. Forcing the issue of
competitive purchase



Vendors don’t want competition because
that lowers prices and profits.
Vendors spread propaganda that
interoperable systems will either not work or
will be extremely costly/cumbersome to
maintain.
Vendors and manufacturers have a conflict
of interest, don’t expect a very truthful
message about open protocols from MOST
of them.

4. Breaking down the
integration task



Device to device communication
(equipment level, VAV boxes, chillers,
air handlers, etc.).
Building level controlling devices.
The Holy Grail- The “Front end”
graphical interface.

5. Device to device
communication:



BACnet IP devices use Ethernet
If your system is all BACnet IP, you
can have all the brands you want.
Controllers may still use different kinds
of internal logic, the front end has to
be able to adapt (more on that later)

6. Device to Device comm.



What about BACnet MS/TP – 18/2
twisted shielded?
Might be slight variations in speed,
other communication tweaks.
Route to BACnet IP. Routers only
cost $300. Easy solution for multibrands.

7. Building level
communication




These devices will most always be BACnet
IP, so they can co-exist from a
communication perspective.
BUT, the internal programming and
architecture can vary, so be careful about
mixing and matching brands.
Multi-brand operation means good
documentation, testing, and owner training.
Keep as much logic resident in the
equipment as possible. This helps reliability
as well as multi-brand function.

8. The Achilles HeelGraphical User Interface
“Front end”




This is where systems often fail in their
ability to be interoperable.
To most end users the equipment
controllers are “black boxes”. Once the
logic is debugged and they run, the program
code doesn’t need modification.
Most of the attention needs to be on the
front end.
Most end users do NOT want multiple front
end brands. Still, even if this occurs, if they
are just “mouse clicker” end users, is it
really that terrible to have multiple front
ends? See vendor propaganda again.

9. So what is a “front end”
GUI?


A Graphical User Interface for a building
management system is a “Window” into the
system. For viewing live graphic images,
changing setpoints, changing schedules,
monitoring alarms. Typically these would be
B-AWS or B-OWS BACnet Testing Laboratory
certified software programs, running under a
Microsoft Windows platform.
http://www.bacnetinternational.net/btl/

10. Dual Purpose GUI
/building controller


B-BC building controller devices are often dual
purpose. They offer building level
programming/management features. But
many of the B-BC profile devices are also
GUI’s, web servers. A B-BC device can have
some of the same features, and the same
issues, as B-OWS or B-AWS software.
A B-BC is a “black box” whereas the B-OWS
or B-AWS software typically runs on a PC.

11. What the GUI means to
the average BMS
manufacturer



For most DDC controller manufacturers the
development cost for the GUI is never
recovered. So the tendency is to run with a
product for years, long after it has become a
stale technology.
The reason to develop and sell the GUI isn’t
to make money on the GUI, it is to keep
systems closed! This protects profits and
sales for the controller hardware.
Key means to manipulate the marketplace.

12. An open protocol (such as
BACnet) GUI may still be
hostile






Proprietary Database methods
Software expiration
License restrictions
Password restrictions
Pigeonholed features
Training restrictions

13. Proprietary Database
Methods



GUI may use proprietary database
methods exclusively for software
functions.
Doesn’t seem to be a problem, but
would be a really nasty feature if you
may encounter it.
Look for SQL, CSV export, etc. for
standardized data format.

14. Software Expiration




Obvious tactic to force the purchase of
service contracts, mandate expansion
work to the GUI supplier.
There should be no expiration.
Upgrades optional.
Also not much of a problem recently.

15. License Restrictions




The end user may not own the license.
End user can only be an operator, no
other software rights.
No sub-letting of license rights to
another party, AKA a contractor for
another control manufacturer.
This has improved in recent years, but
read your fine print.

16. Password restrictions



This is more often an installer choice
and not a manufacturer mandate.
One of the most important things to
police and monitor prior to system
approval/payment.
Keep them in a safe place in
MULTIPLE locations.

17. Pigeonholed Features




BACnet BTL products still have variations in
how they work.
The GUI may be built to do scheduling in a
specific manner, and trending, and alarm
notifications.
Try to use another BTL BACnet product, it
may not work so well.
Similar impacts with LON and other
protocols as well.

18. Broad Features of Open
GUI




The open GUI products must offer
broad features to work with as many
open protocol brands as possible.
Scheduling- Multiple methods.
Alarming- Multiple methods.
Trending- Multiple methods.

19. Training Restrictions





No manuals and poor/no help files.
Training only available to the territorially
protected supplier.
Makes success a challenge for a new
vendor who must “seamlessly integrate” to
an existing GUI.
This is the most often abused issue with the
proprietary GUIs.
Favors large BMS vendors. Solution to
integrate: Steal employees from each other.

20. Training- The Right Way




Training available to anyone.
Doesn’t have to be free, but a
reasonable cost.
Fair pricing policy would charge end
users and competitors the same price.
No dealership or volume commitment
needed.

21. Other benefits of open
GUI: The “Protocol
Wars”


When the GUI is provided by the
controller manufacturer, there is an
agenda to promote a protocol
(BACnet, LON, OPC UA, MODbus,
etc.).
With the open GUI, the GUI supplier
wants to be neutral and will develop a
product to speak as many languages
as possible.

22. GUI features to specify:


Submittal requiring an open software
license to the owner, with full level
passwords, no expiration.
Require in the submittal a signed letter
saying that training will be offered to
anyone, including a competitor, at a
reasonable cost. This will cause many
GUI manufacturers to be disqualified!
Tell them to stick to selling controllers!

23. CCTV system analogy


With CCTV systems cameras are specified
and then VMS (Video Management
Software) solutions are specified
separately.
Best practice for BMS systems is probably
to do the same thing. Open protocol helps
with controller interoperability, but system
interoperability requires a “cooperative” front
end.

24. Military analogy




UFGS 25 10 10 provides the “front end”
specification for military projects.
Controllers for equipment in one bid, “front
end” integration often is another bid.
UFGS 230923 is oriented to LNS Lon. New
versions forthcoming for BACnet.
Again demonstrates that interoperable
systems need a “front end” that is broad and
not restrictive.

25. Industrial analogy



Years ago PLCs (Programmable Logic
Controllers) and HMIs (Human
Machine Interface, front end in the
industrial world) were made by the
same companies.
This was a functional mess.
Separate HMI products evolved circa
15 years ago.

26. Five year expansion
example



BTL listed native BACnet system
installed 5 years ago.
Supplier installed their own brand of
GUI, with some hostile features
discussed earlier.
Expansion project with no option for
competition. Price inflated $50,000 by
the vendor – profiteering on the
situation.

27. Five year expansion- do
it right




The proprietary GUI is giving the existing
vendor too much leverage.
Include GUI upgrade as part of the new
project.
The savings in having competitive
procurement will most always outweigh the
cost of the new GUI.
The open GUI will almost surely be a better
product with lower cost of ownership in the
long run.

28. What options are there
for an open HMI?







Tridium NiagaraAX 3.6+ (BTL listed)
Iconics GENESIS64 (BTL listed)
Plexus Technologies OPIS
Priva Top Integration (BTL listed)
Copadata Xenon
Open Source “Freeware”. Why not? Users
that do this help the industry. See Linux.
Exponential growth now like we saw with
PLCs and industrial controls years ago.

29. What else is needed for
the expansion project?



The owner often doesn’t know what he
has in the way of controllers, panels,
etc. He just knows the brand of
system.
Press the basis of design vendor for
an accurate riser diagram to be
included in bid documents.
The riser diagram is the most
important bid item for a competing
vendor.

30. Lighting Controls





It seems that the lighting control business
parallels some of the issues of HVAC
controls, more-so than CCTV and card
access.
Look for things such as DALI, and EnOcean
open lighting solutions.
Ask the same questions of lighting control
vendors as HVAC control vendors.
Lighting uses lots of energy. True “energy
management systems” should include
lighting controls.
ASHRAE 90.1 is going to accelerate the use
of automated lighting controls.

31. What is coming about
now:



Fully integrated buildings: HVAC, lighting,
card access, security, network cameras, fire
and life safety.
The big vendors/manufacturers are ready to
jump on this to provide single vendor
solutions, provided you give them a blank
check, of course.
We need to take design responsibility away
from the vendors and get it back to the
specifying engineers, otherwise pricing is
only going to get worse. Much worse.

32. Thank You
Prepared by:
Rich Purtell
Climate Control Technologies, Inc.
Cell phone: 607-425-9730
rpurtell2@stny.rr.com