Specifying Energy Management and Integration Software for Buildings

The procurement process for an energy management system (EMS) in new construction would typically use a design-bid delivery method where requirements are specified and the qualified bidder with the lowest bid is awarded the job. It is a process that may work well when the procurement is for hardware or equipment and materials where very specific requirements have been identified or calculated. However, as more software applications, such as energy management, integration platforms and other software monitoring and managing sub-systems are deployed in buildings, , and these applications need to be configured, customized, have special dashboards developed, or require integration into business systems, the procurement of the software through a “low” bid process can become complicated. Existing buildings may use what is likely a better process to procure an EMS, which is, issuing a request for information (RFI) to the marketplace followed by a request for proposal (RFP), and then making an award to a contractor based on price as well as other factors.

Regardless of the process, you will want to present clear software specifications to potential contractors including the quantification of as many variables as possible. What follows are some “do’s and don’ts” in pulling together software specifications in order to truly reflect the client’s needs and environment, and clearly convey the information to the potential contractors.

  1. Defining What the Software Is Supposed to Do

Some software for specific applications may be “out of the box” or “one size fits all” applications, while other software, especially enterprise-level products and those involving system integration, will take some customizing. In addition to integration and energy management software applications, clients may need applications such as fault detection and diagnostics, predictive analytics, alarm management, trending, automated demand response scenarios and document management. Clients may benefit from obtaining additional information and education regarding the marketplace to get a sense of what is available and doable; however, they should realize their requirements are not marketing wish lists. This “programming” exercise needs to include various groups within the client’s organization such as facility management, facility engineers, IT, the design team and possibly business executives. The result of this effort should delineate what the software has to do, clearly and concisely identifying the functionality that the client wants in the software.

This piece of the procurement project is critical; vagueness in stating your functional requirements will not only drive up the price as bidders assume more risk but it will also, and more importantly, probably result in a less than successful software implementation. A study by the Standish Group found about half of IT projects were “challenged,” that is over-budget, over schedule and with less functionality. Why were they challenged? Incomplete requirements and specifications, lack of user input and changing requirements and specifications — all of which are related simply to not doing it right in the first place.

  1. Identify the Required Dashboards or User Interfaces

This is really an exercise in identifying who in the organization needs or can use the building data or energy information generated by the software. For energy management, this could mean everyone from the facility engineer to the business executive to the general public; each group will need varying information displayed in different ways. Many vendors will have standard dashboards or at least the dashboards created for their last client; this may be a starting point in deciding on what you require. Make a list of all the dashboards required, including those for each individual piece of equipment, summary dashboards, drill down dashboards, those for particular spaces or zones and special dashboards. The dashboards are what many clients see as the project deliverables.

EMS Weasel Words

  1. Identify the Integration or External Interfaces Required

If the software is focused on energy management, you will need to connect into the BMS, a power management system and metering for electric, natural gas, steam and water. You may need network controllers, additional software or even an upgrade to the latest software for a BMS to access its database. Beyond that, however, you will probably need data from external systems such as weather data, energy budgets and costs from the organization’s financial software, utility rate structures, occupancy data and schedules — all of which require some external interface. The bidder must know how to interface into all these systems, which party is responsible for additional hardware or software related to interfacing systems and the format of the data.

  1. Provide a Basis for a Bidder to Estimate Costs

This is where a “hard” bid is different than an RFP. If the award of a contract is based solely on price, you want to make sure that as much information as possible is quantified so the bids reflect similar efforts and deliverables. You will want to identify the number of data points, the number of dashboards, the number of applications, the hardware requirements, the availability of control drawings, what is to be supplied by the client’s IT department, the IT department’s standards for hardware and software, the specifics of the energy control systems, other sub-systems to be integrated, the responsibilities and required coordination of contractors for the sub-systems and the project schedule. The number of data points is fundamental to pricing many software applications because each point needs to be configured in the software. This is a task to quantify the requirements of the programming document as much as possible.

  1. Identify the Required Performance of the Software

There are several performance indicators you will want to identify:

  • User Response Time
    This is the top concern for most users; the dashboards may look great, but if it takes a while to respond users are impatient and unhappy. Response time may be affected by whether the software is a remote hosted solution or on site.
  • Throughput on the System
    The issues here are network bandwidth, latency, transmission overhead and the performance of the network. It is not uncommon for a decent size building to have tens of thousands of data points or for a campus or enterprise to have hundreds of thousands of data points. Depending on the polling interval and the method of obtaining data, acquisition of the data from a site could be affected by inadequate network throughput.
  • Scalability of the System
    Most enterprise-wide deployments start on a small scale such as a pilot project and upon acceptance of the results are ramped up to a campus or all buildings in the real estate portfolio. You need to know how both the hardware and software scale, with special attention to the scaling of the database.
  • Reliability
    This deals with redundancy, recovery time of software functions, resource utilization, backups of hardware and software, data loss and connectivity. If you are using a hosted solution on an enterprise basis and lose connectivity to a building, what happens to the building’s data?
  1. Identify the Testing, Acceptance and Handoff Process

Much of what happens during the close-out and handoff of the software implementation is simply related to good project management. Here are a few suggestions: (a) Establish a review and approval process for customized dashboards as to not get caught in an endless loop of revisions and reviews. (b) If the installers are different than the manufacturer of the software, get the manufacturer’s representative to manage startup of the completed system. (c) Address the warranty period including emergency and non-emergency services, vendor response times and software upgrades and changes. (d) Have the contractor provide initial formal training and refresher training during the warranty period. (e) Require that the vendor prepare a user manual specific to your configuration. (f) Obtain all hard and soft copy documentation related to the installation, including record submittals.

In a growing and rapidly changing marketplace for energy management and integration software, it is important to take a methodical approach in the procurement and deployment of an EMS and focus not so much on the marketplace but rather your unique requirements and building operations.

Jim Sinopoli is the managing principal at Smart Buildings, which provides engineering and consulting services for the design and operation of integrated building technology systems. His background is in construction practices, design, procurement, project management, and building systems and operation, with a particular focus on monitoring and managing a building’s performance.

He has a bachelor of science degree in aeronautical engineering from Purdue University and a master of arts in applied science and environmental management degree from Governor’s State University. He is a licensed professional engineer, an accredited LEED professional and a registered Communications Distribution Designer.

Practical Guide to Transforming Energy Data into Better Buildings
Sponsored By: Lucid

Choosing the Correct Emission Control Technology
Sponsored By: Anguil Environmental Systems

Planning for a Sustainable Future
Sponsored By: VelocityEHS

Avoid the RFP Trap: The Smart Guide to Purchasing EHS Software
Sponsored By: VelocityEHS


2 thoughts on “Specifying Energy Management and Integration Software for Buildings

  1. This was a good primer for people interested in specifying an energy management system for a new or existing building.
    A few other considerations to keep in mind would be:
    1. What are the expected lifecycle costs? Will the software license need to be renewed in the future? Are there ongoing maintenance costs and mandatory service contracts? Can you manage and maintain it yourself? If the vendor updates the software will they keep supporting your version?
    2. Is the system open or proprietary? This can apply to hardware, software and your data – is it all open or closed and will you be able to migrate or integrate other technologies or systems in the future as needs arise.
    3. Do you just need a dashboard type system for reporting or a more comprehensive energy management framework or even possibly a control system? Is just having new software enough or will you also need the help of specialized energy management consultants or a team?
    4. Does the system integrate with other data standards relevant to your building? Energy Star Portfolio Manager? Green Button? Haystack?
    5. Does the software give you high quality analytical tools to use, and can these be customized for your needs? Can you use the analytics to compare your site internally and externally to benchmarks?
    The EMS market is growing and there’s so many options available – think about your needs and decision making process carefully top ensure a positive legacy at your facility.

Leave a Comment

User Name :
Password :
If you've no account register here first time
User Name :
User Email :
Password :

Login Now
Translate »