Published on February 28, 2014
Building Automation Systems Methods to enable competitive purchase for expansion projects without sacrificing performance.
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.
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.
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.
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)
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.
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.
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.
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/
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.
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.
An open protocol (such as BACnet) GUI may still be hostile Proprietary Database methods Software expiration License restrictions Password restrictions Pigeonholed features Training restrictions
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
Thank You Prepared by: Rich Purtell Climate Control Technologies, Inc. Cell phone: 607-425-9730 email@example.com
Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...
In this presentation we will describe our experience developing with a highly dyna...
Presentation to the LITA Forum 7th November 2014 Albuquerque, NM
Un recorrido por los cambios que nos generará el wearabletech en el futuro
Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...
... you get a competitive, ... when selecting a Building Automation System (BAS) / Building ... BAS/BMS to perform additional strategies ...
... Building Automation Systems Market research ... System integrators Building ... These players adopted various strategies such as new ...
... Price on Smart Buildings Market - Global Industry Analysis ... of building automation systems (BAS) ... system, building ...
By leveraging known energy saving strategies, ... controlled via a building automation system (BAS). ... benefits of buying energy-efficient ...
... Guelph Hydro 2013 Sustainability Report, ... concern to our stakeholders and develop strategies to ... , building automation system (BAS) ...
Prop 39 for California Schools: A+ Report Card for ... control HVAC units or a building automation system (BAS). ... sample of competitive ...
... VirtuWatt Link web services application and Novar’s Opus Building Automation System (BAS) ... By buying power directly ... Smart Grid Strategies.
Building Controls An FPL Technical Brief ... Building Automation Systems ... one mechanical system on a BAS network.