Having problems specifying rapidly evolving building automation?

[an error occurred while processing this directive]The Request For Proposal (RFP) approach has been used by the Information Technology (IT) industry for several years. This approach allows the purchaser to focus on actual functional requirements rather than being confused with the various technologies supplied by vendors. Time is well-spent defining mandatory requirements and gives a clearer understanding of how the technology will achieve our goals. Once mandatory requirements and "nice to have" features are defined we can send out a Request For Proposal to allow vendors using different technologies to present proposals on how they will meet our requirements as well as expounding on their ability to provide further enhancements.

As an automation consultant, I first learned of the need for the RFP in the early days of the Direct Digital Control evolution. It became clear that to purchase this rapidly evolving technology, while keeping focused on achieving the client's mandatory requirements, the traditional bid and spec approach would not work. If a known automation system with an operating history was specified the system was by definition obsolete. If another vendor was allowed to be equal to this specified obsolete product since there was little equivalency between products you could end up with almost anything as a control system.

The rapid evolution of control products was, and still is, many times faster than the construction time line for most large projects. Specifying automation products in the original design insures obsolescence and feature limited products.

The concept of removing DDC automation from project design and purchasing it in a "just in time" fashion in an RFP became the solution to our problem. This approach increased the rate at which the automation industry could evolve and proposals often included proven products, leading edge products and bleeding edge products. The bleeding edge or alpha and beta products were not all bad as the union of vendor and owner allowed insight into each others camp. This helped propel DDC industry growth. Proposals often included "at no cost" features that we had not originally conceived, while constantly providing lower costs.

Our present juncture in time is similar to the early 1980s when we had a myriad of very different approaches to DDC control. It seemed then that if we kept focused on our actual requirements, the original intent, and how the technology could help us, constructive growth could occur. With this said we could not ignore the fact that technology changed the way we approached control. This feedback had to be inserted into the next RFP making the document very dynamic. By the mid and late 1980s the DDC industry had settled into some strong patterns with fewer new players.

Understanding how we came to be where we are in the DDC industry gives us insight into the next evolutionary level of web and network control. These same principles will help us grow. We must document our clients actual requirements, while better understanding his complete IT enterprise and how it will become integrated in the new building wide control strategy.

[an error occurred while processing this directive]Be sure that the RFP includes everything we have come to expect in a traditional DDC system. A well-written RFP will allow a representation of our requirements by the proposing vendors. Ask vendors to provide details on how data will be passed from field devices to browser-based interfaces. As the vendors educate us on their approaches, it will become clearer which systems will last and which are custom built. Systems with reliance on existing IT standards will likely be the systems of choice.

Field bus standards, ie BACnet, should be a mandatory requirement to insure the ability for future interface with another vendor's system. Products that support most field bus and IT standards will be the clear winners providing a path to future proofing. Vendors with the largest amount of proprietary communication standards and proprietary web interface code will be the least desirable. Fashion your RFP to have vendors supply details so you can determine if data flow is only one direction or if a true interactive interface is present.

Evaluate the complete strength of the proponent including pulling wires, installing devices, programming stand alone controls, creating field bus interfaces to BACnet and Lon devices, graphic presentation skills and general IT skills. We now require more from our automation contractors, but most companies have restructured and are up to the challenge.

Will the "just in time" RFP approach work? Yes, it will allow purchase of a leading edge system based not just on low price, but on technical merit, overall functionality, ease of operation and lower ongoing maintenance costs. The IT industry has done this for years.

Return to Articles

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]