In the last month, I’ve read over 50 research papers, blog posts, and articles on analytics software for buildings. I realize this would put most people to sleep, but I love it. It’s also part of my job. One thing I don’t love is the standard, copy-and-paste framework most people are using to describe analytics software. I think it’s confusing, outdated, and it’s inhibiting the adoption of this powerful tool.
It’s time for a new answer to the fundamental question, “What is it?”.
The Standard Framework
The most common answer is perpetuated far and wide throughout the public and private sectors. I’ll call it the standard EMIS framework. The acronym “EMIS”, short for energy management and information systems, is an umbrella term designed to wrangle together 5 technologies, separated by whether they focus on “meter-level” data or “system-level” data.
- Meter-Level EMIS:
- Monthly Energy Metering (MEM) – focused on analyzing utility bills
- Energy Information Systems (EIS) – focused on analyzing interval meter data
- System-Level EMIS
- Building Automation Systems (BAS) – focused on controlling equipment
- Fault Detection & Diagnostics (FDD) – focused on identifying, notifying and recommending solutions when a system or component is operating outside of expected performance criteria
- Automated System Optimization (ASO) – focused on supervisory control of systems
To summarize, the standard EMIS framework answer to “What is it?” is this:
It’s is an EMIS. EMIS is a broad family of 5 technologies: MEM, EIS, BAS, FDD, and ASO.
I think we can do better.
To be fair, this framework did the job we needed at the time. There were these five distinct-ish categories of energy management software on the market, and we needed a way to group them together because they were doing similar tasks. We needed common terminology to create clarity for industry professionals in hopes it would help people understand what they were buying. We needed that umbrella acronym, and we got it.
But here we are, many years later, and confusion about the offers in the analytics marketplace – i.e. what is it? – remains one of the biggest barriers to adoption. I’ve seen the consequences first hand: When building owners are confused, they slow down purchases, do nothing, or purchase a lousy product that doesn’t meet their needs and sets them back for years. I think this old framework is at least partially to blame. Let’s walk through the 5 ways it confuses me, and you can decide for yourself.
Why it’s confusing
No building owner wants to use 5 separate tools
They’re overwhelmed as it is and they already have enough silos. It’s no longer good enough to just be an EIS tool. If one tool can’t meet all needs, we need interoperability between tools into one system, but that’s not what the framework promotes.
It’s not extensible
The framework isn’t extensible to new types of capabilities. For example, where do new developments like machine learning fit in? Similarly, the framework stops short of conveying the growing influence of analytics software beyond energy management. For example, EMIS is now used for predictive maintenance, which stretches beyond energy into O&M and capital planning. Occupant engagement is another example.
The boundaries are blurry between the “family members” and some members cross boundaries
The software market is too messy to divide into 5 distinct categories. And yet, in the framework they appear so. For example, if an EIS tool pulls in only meter-level data but has FDD capabilities, I don’t know what to make of it using the standard framework. Many vendors ar providing many of the categories and will continue to expand. Some “can” provide multiple categories, but not out of the box.
The building automation system (BAS) is not an EMIS
It’s simply a group of controllers, actuators, and sensors. It’s a data source for analytics, not an analytics tool. A building management system (BMS) does have some EMIS-like capabilities, such as supervisory control and trend analysis, which adds to the confusion. Most BMS implementations are notoriously terrible at using data to provide insights for the user. Telling an owner their BAS or BMS counts as an EMIS makes it seem like they don’t need to consider adding new capabilities, which isn’t true in 99% of buildings.
It’s difficult to use the framework to compare vendors
Although it’s not intended to help select vendors, it often gets used for that. I find that with just 5 categories, it’s impossible to capture the nuances between vendors. For example, Automated Logic and SkySpark both provide FDD. And yet, they’re almost completely different use cases.
A New Framework: Scope, EMIS Stack, Capabilities
Okay, so what would a new framework look like? We want something that is simple, stands the test of time, and promotes adoption.
I think the essence of EMIS comes down to three questions:
- What devices and systems are you connected to? This is the scope of your EMIS.
- What combination of hardware and software are you using? This is your EMIS stack.
- What are you doing with the data? These are the capabilities of your EMIS.
The EMIS scope could be any of the underlying systems in the building, plus any third-party systems. The integration with each system could be a one-way transfer of data into the EMIS, or it could be a two-way communication stream. Here’s a partial list of potential scope:
- Utility Bills
- Weather Data
- Facility Data
- Interval Meters or Automated Metering Infrastructure
- Building Automation Systems
- Distributed Energy Resources
- Electric Grid Systems
- Internet of Things
- Electric Vehicle Charging Stations
- Geographical Information Systems
- Computerized Maintenance Management System (CMMS)
- Occupant Engagement Applications
- And more!
An EMIS typically isn’t one product or application, although it should perform like one. The stack is all of the devices, data services, and applications that meet the needs of the user. Depending on the EMIS implementation, the stack has many different layers:
- The integration layer is responsible for managing communication between the Scope and the historian layer. It could include hardware and software, including drivers for protocol translation.
- The historian layer stores time series data and associated metadata in one or more databases, providing those data on request to applications.
- The application layer consists of all high-level analysis tools that rely on collected building performance data.
- The control layer supports applications that have a need to affect the operation of building devices in an automated or semi-automated manner.
Okay, so what does your stack actually do by connecting to all these systems? Does it do these out of the box or does it need to be customized to handle them? Here’s a partial list of the capabilities in the EMIS marketplace:
- Centralize, Normalize, Visualize Data
- Dashboards/User Interface
- Key Performance Indicators
- Advanced Visualization
- Applied Modeling
- Machine Learning
- Utility Bill Management
- Usage and Cost Tracking
- Bill Processing
- Interval Meter Analytics
- Advanced Bill Processing
- Power Quality Monitoring
- DER monitoring
- Measurement & Verification (M&V)
- IPMVP Option C
- M&V with Interval Data
- Operational Verification
- Automated Fault Detection and Diagnostics (AFDD)
- Supervisory Control
- Automated System Optimization (ASO)
- Setpoint Compliance
- Demand Management
- Load-Changing Control (to support a Grid-Interactive Efficient Building (GEB))
- Automated Performance Testing
- O&M Optimization
- Issue Tracking
- Work Order Generation and Management
- Condition-Based and Predictive Maintenance
And Finally, A New Answer
So, based on this new framework, What is it? What is EMIS?
An EMIS is a system of devices, data services, and software applications (stack!) that communicates with any building system or third-party data source (scope!) to aggregate data and transform it into new capabilities (capabilities!) that aid in the optimization of the building.
What do you think?