What is EMIS? We need a new answer.

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. 

EMIS Scope

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!

EMIS Stack

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. 

EMIS Capabilities 

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
    • Reporting
    • Advanced Visualization 
    • Applied Modeling
    • Machine Learning
  • Utility Bill Management
    • Usage and Cost Tracking 
    • Benchmarking
    • Bill Processing 
  • Interval Meter Analytics 
    • Advanced Bill Processing 
    • Visualization 
    • 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)
    • Rules-based
    • Model-based
    • Black-box-based 
  • 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?

If this article resonated with you, I invite you to subscribe to my weekly(ish) newsletter on smart buildings and analytics. It will keep you up to date on the industry and any new article I write.

Share or Save

One thought on “What is EMIS? We need a new answer.”

  1. James, very well written and thought through approach to a messy subject. I generally think we can start to think about the overall stack based on an increasingly complex and valuable functionality set.

    If we lean on software frameworks, we might find a way to bridge from the physical to the digital world:

    Data: The first is and always will be data. Collecting data from meters, sensors, actuators, etc provides the foundation for all other uses. It’s extremely important, but also the lowest value.

    Analytics: Analyzing the data is the most basic value add function. You’ve done a great job of identifying the quality and type of analytics common in buildings.

    Operations/Transformations: Using the data and analytics to do something is the next function and is the typical function found in BAS/EMS/etc. Basis steps is take data inputs and either directly create an output, or use analytics or something other operation to transform the data before creating an output. Typically highly algorithmic right now.

    ML/AI Autonomy: The next frontier in building automation that will ultimately replace and/or augment the previous three layers. Some early technologies specific to equipment and/or use cases that will eventually expand into full building, campus, and grid level autonomy.

Leave a Reply

Your email address will not be published. Required fields are marked *