Though the price of energy has been dropping recently and is predicted to continue dropping as shale gas extraction increases in North America, there remains an incentive to closely monitor energy usage. That incentive is money. After all, even with energy prices dropping so dramatically that taking steps in 2012 to save $30,000 a year may only net, say, a $20,000 or 25,000 savings in 2013 … that’s still a lot of money that could be put to good use elsewhere.
With that in mind, the concept of creating energy management dashboards so that all levels of your business can visualize how much energy they’re using and therefore be smarter about their use of it remains relevant. The problem is that numerous definitions of and solutions for energy management exist, such as:
• Utility metering
• Energy management and control system (EMCS)
• Greenhouse gas emissions
• Asset management
• Project performance tracking
• Metrics and analysis
• Billing and accounting
All of these systems, taken individually or combined, can be configured as an enterprise energy management dashboard. That’s why understanding the terminology and function of each system is critical. For example, EMCS can also be called a Building Management System or Building Automation System. The term EMS (Energy Management System) is considered by many to be metering. For others, it relates HVAC or metering and HVAC.
Furthermore, marketing literature can make it difficult for an end user to differentiate between the functionality of these systems. For example, an enterprise metering solution that provides power quality, real-time and minute level data is very different than an Enterprise Asset Management system that provides utility meter usage and reports.
To make sense of it all, and be successful in engineering and implementing an enterprise energy management dashboard, Feras Karim, senior system engineer at SAIC says systems integrators and end users need to understand both company goals and user requirements as well as technical and product requirements.
To start, Karim notes five key aspects of establishing enterprise goals and requirements:
• Define your objective. Is it to:
-- Increase awareness?
--Reduce energy use and greenhouse gas emissions?
-- Achieve a specific level of corporate sustainability?
• Who is your audience?
-- Management
-- Technical staff/Operators
• What data does your audience need?
-- Utility usage
-- Temperatures
-- Cost
• How does the data need to be displayed?
-- Graphical representation (e.g., HMI)
-- Tables
-- Charts and reports
• Enterprise dashboard display
-- If real-time data is needed, how will it be presented? (e.g., proactive versus reactive)
-- Define metrics by establishing the top five metrics for your business
-- Leverage the same data for everyone
Karim says that once you’ve addressed these five aspects, it’s time to understand the related technical and product requirements. For the technical architecture of an enterprise energy management system, Karim says there are six issues to address:
• Identify available data from existing devices and systems.
• System communication protocols. Karim says you need to determine what type of protocols can be supported by the system. This means you need to understand the difference between real-time protocols such as OPC, ModBus, BacNET, LON, etc., as well as historical/database structures like XML, OBIX and SQL. He also cautions that is critical to understand what is meant by the terms “open protocol” or “standard protocol” or even “open” … because not all protocols follow open standards. “Some adapt a version of the standard, while others expose a limited subset of data via the protocol,” he says. “Furthermore, some OEM solutions will use open protocols one way. They will talk to devices using open protocols but not allow for third party hardware/software to communicate to their devices/software via the same open protocols. Bottom line: an ‘open protocol’ does not always translate to an open system.”
• Communication infrastructure. To understand the hardware, devices and I/O requirements for system communication media, Karim says you should be able to answer a few critical questions, such as: Will your system use Ethernet (wired, wireless), RS485, cellular or other communication media? What is the impact of the data flowing from I/O to the controller to the SCADA, database and the enterprise system? What are the constraints/load exerted on the system infrastructure as data is polled or queried? For example, what is the impact on your network/process if your enterprise system requires 1-5 minute data resolution for analytics? The network may not support the additional load so the end user may need to either accept the constraint and dial back the resolution to an acceptable rate or look into upgrading the communication infrastructure to accommodate the additional load.
• Infrastructure bandwidth. Bandwidth has similar constraints and considerations as communication infrastructure. Resolutions may include assembling data files that are uploaded to the enterprise periodically to alleviate bottlenecks and stressing the network.
• Security. This is, obviously, a huge issue – too big to be covered here. I suggest searching on the term “security” in the search box at the top of any page at www.automationworld.com to access a plethora of resources.
• Hardware and software requirements. Karim says you need to ask questions such as: Can you afford data gaps? If not, does a store-and-forward strategy work to mitigate network outages? What stage of the enterprise deployment are you at? How scalable is the solution? Do I need a dedicated server or can the solution run on a virtual machine? How are patches and software updates handled? There are many considerations that impact both the sustainability and cost of the solution. Due to the rapid advancement in technology—especially software—the system purpose, short/medium/long-term life cycle and goals need to be evaluated.
Finally, when you get to the steps of actual product selection with which to implement your energy management dashboard, there are six areas to address.
• Vendor independence (hardware and software). Users should focus on how open the system is, Karim says. “This not only applies to communication protocols, hardware and operating systems, but also to who can design, install, commission and support the system. Several OEMs limit who can provide these functions to their staff, distributor networks, etc., thus leaving many third-party systems integrators out of the equation. This limits and restricts the end users’ options. If an end user asks, ‘Can I modify the solution?’ the answer may technically be yes. However, in practice modification rights could be restricted to the OEM, the OEM’s solutions and services group, the OEM’s distribution network, and the end user. If the end user chooses to hire a third-party systems integrator that is not part of the OEM’s network, their warranty may be void.
• Is the system really open? (see discussion above under “system communication protocols”).
• Licensing agreement and support model (is it per user, device asset, point, server, processor, site, etc.)
• Sustainability of system, i.e., how will patches/upgrades be handled?
• Who maintains the system (owner, system integrator, distributor, etc.)?
• Who owns and maintains the data (owner, externally hosted, both)?
