This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.TN.1832

NIST Technical Note 1832

Facility Smart Grid Interface and a 

Demand Response Conceptual Model

David G. Holmberg

David B. Hardin

Steven T. Bushby 

http://dx.doi.org/10.6028/NIST.TN.1832
This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.TN.1832

NIST Technical Note 1832

Facility Smart Grid Interface and a 

Demand Response Conceptual Model

David G. Holmberg

Steven T. Bushby

Energy and Environment Division

Engineering Laboratory

David B. Hardin

Upperbay Systems

Franklin, MA

This publication is available free of charge from:

http://dx.doi.org/10.6028/NIST.TN.1832

August 2014

U.S. Department of Commerce 

Penny Pritzker, Secretary

National Institute of Standards and Technology 

Willie May, Acting Under Secretary of Commerce for Standards and Technology and Acting Director 
This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.TN.1832

Certain commercial entities, equipment, or materials may be identified in this

document in order to describe an experimental procedure or concept adequately.

Such identification is not intended to imply recommendation or endorsement by the

National Institute of Standards and Technology, nor is it intended to imply that the

entities, materials, or equipment are necessarily the best available for the purpose. 

National Institute of Standards and Technology Technical Note 1832

Natl. Inst. Stand. Technol. Tech. Note 1832, 14 pages (August 2014)

This publication is available free of charge from:

http://dx.doi.org/10.6028/NIST.TN.1832

CODEN: NTNOEF
This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.TN.1832

1

Abstract

Residential, commercial, and industrial facilities have potential to support electric grid reliability with demand 

response (DR) via use of facility energy management approaches. The ability of different DR approaches to 

successfully engage the maximum amount of customer response (and customer benefit in terms of energy and energy 

cost reduction) depends in part on proper selection of communication interfaces. This paper examines the impact of 

facility systems diversity on the communications interface, and analyzes use case requirements to derive basic use case 

classes and a resulting set of key information elements needed to support smart grid customer interface 

communications. The derived customer interface functional requirements are used to develop a “DR Conceptual 

Model” which provides a high-level view of the scope of DR interactions and guidance on the selection of 

communication interfaces.

Keywords: buildings, communications interface, customer, demand response, smart grid

Introduction

The United States and other nations have policies that are encouraging: renewable energy integration, CO2 reduction, 

building energy efficiency, and demand response (DR) for grid energy efficiency [1, 2, 3]. Meeting these policy goals 

while maintaining grid reliability represents a significant challenge. The combination of variable supply due to 

renewable generation and demand peaks due (primarily) to air-conditioning or heating loads has contributed to a move 

toward a paradigm where demand-side entities respond to supply-side conditions. Demand response has already been 

shown effective in managing load peaks. When facilities are taken together, they represent a viable resource to 1) offset 

peak loads through energy curtailment as well as 2) balance short-term supply and demand and aid the integration of 

intermittent renewables through ancillary services [4, 5].

However, DR as widely implemented today, utilizing DR event communications and direct load control (DLC), has 

only realized a fraction of the available demand response resource. It will be helpful to examine the reasons why this is 

true so as to better understand how demand response can be increased. Examining the diversity of the customer domain 

demonstrates the need for more abstract communication interfaces for achieving wide scale demand response. Use case 

analysis leads to understanding functional requirements for communications with the diverse customer domain and 

from which are derived use case classes. These classes are important for guiding the development of interface 

standards. Together, the results of these analyses lead to a higher-level view of DR interactions—a DR Conceptual 

Model. This DR Conceptual Model presents the range of DR interactions along with the drivers for adopting one DR 

approach versus another. The DR Conceptual Model is a tool for understanding the trade-offs among different DR 

approaches and options for implementing demand response.

As a first step, a working definition of the customer communications interface is presented. Following that, an analysis 

of customer domain characteristics is presented. These characteristics cover a diversity of business goals, customer 

loads (energy consuming systems and devices), and communication protocols used in different types of customer 

facilities. In order to realize the potential for DR, the customer communications interface design needs to account for 

this customer diversity. 

Section four presents an analysis of the use cases for Smart Grid interactions between grid-side service providers and 

customer facility systems. These use cases reveal the functional requirements of the interface and basic information 

elements that must be communicated at the interface. The final section presents the DR conceptual model.
This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.TN.1832

2

Baseline Definition of the Customer Communication Interface 

The customer energy services interface (ESI) is a logical demarcation point at a facility asset ownership or operations 

support boundary that enables secure communication of information between entities internal to the customer domain 

(i.e., energy management systems, electrical loads, meters, storage and generation) and external entities (e.g., energy 

service providers, aggregators, and markets), Fig. 1. A clear demarcation point encourages market development of 

competitive devices, equipment and appliances that facilitate demand response, energy efficiency and energy 

management. The ESI comprises the devices and applications that provide secure interfaces between energy service 

providers and customers, facilitating machine-to-machine communications to support business processes [6, 7].

Fig. 1 Customer energy services interface (blue bar) as demarcation between independent domains.

The ESI may be instantiated in many forms, running different application services, implemented in different devices, at 

different levels of a hierarchy (e.g., with an aggregator), even multiple ESIs within a single system interacting with 

different outside parties. It may be owned and operated by either an energy services provider or customer. Real-world

implementations will need to support operational variations among customers to account for diverse customer business 

models with different types of assets in different types of customer facilities controlled by a range of automation.

Considering general interface principles, a standardized interface defines what and how specific information is 

transferred through the interface but not how that information is processed nor what functions and features are provided 

by systems that implement the interface [8]. Vendors in the market do not compete on the standard interface, but rather 

on the products, systems and services that implement and use the information transferred to provide enhanced customer 

value through innovation. An interface that promotes both interoperability and innovation needs to provide separation 

between the systems that interact. This shields one side of the interface from changes that occur on the other, thus 

improving system robustness and stability.

Customer Domain Characteristics

It is important to recognize the customer facility (home, commercial, industrial) as a separate domain of the smart grid, 

as shown in Fig. 2, and as acknowledged by smart grid architectural efforts [7, 9]. The customer domain is segmented 

into separate sub-domains for home, commercial/institutional, and industrial (Fig. 2). Each sub-domain has a diverse 

set of actors, applications and technology. This diversity results in a challenge for grid-side service providers to engage 

with a range of customer systems and devices, managed for different purposes, using a wide variety of communication 

protocols. The customer interface needs to accept and adapt to this customer diversity in order to achieve scalability 

and a high level of acceptance.
This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.TN.1832

3

Fig. 2 Conceptual Reference Diagram for the Customer Domain 

(Source: adapted from NIST Framework, 2.0 [7]).

Customer diversity can be categorized based upon differences associated with: 1) business values and business 

priorities, 2) system complexity and 3) communications technology.

Diversity of Business Values and Priorities

A discontinuity exists between the business values and priorities surrounding grid operations and those of customers. 

Each has different policies and regulations, different business models, drivers, processes and procedures, and different 

but complex information models and technologies.

Grid operations are typically focused on actively managing and controlling the delicate balance between the energy 

produced and energy consumed on the grid in real-time. Minimizing operational risk is a very high priority due to the 

costly impact of electric system instability or collapse. Minimizing risk often entails minimizing complexity and 

options. Customers are viewed through this lens.

Customers on the other hand are not focused on the grid but rather on achieving a totally different set of wide-ranging 

business objectives such as: profitably operating a large manufacturing business, maintaining a comfortable 

environment for customers in a retail store, or enjoying home entertainment. Maintaining profitability and comfort are 

high priorities. These customer objectives typically assume the continued availability of reliable and relatively 

inexpensive electricity.
This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.TN.1832

4

Diversity of System Complexity

In general, system complexity is minimal in residential buildings, increases in commercial facilities and is greatest 

within industrial facilities. Most homes have appliances, air conditioning, lights, home entertainment and other loads 

but these typically operate independently as stand-alone devices. Integrated home automation systems are installed in a 

small percentage of the residential market.

Most commercial facilities have heating, ventilation, air conditioning, lighting and general plug loads along with 

specialized loads such as kitchen equipment or data processing equipment. Larger facilities and campuses may have 

distributed generation in the form of backup generators or combined heat and power (CHP) cogeneration power plants. 

In addition, equipment within larger facilities and campuses is often monitored and controlled by distributed building 

automation systems.

Industrial facilities typically include an even wider range of highly specialized equipment monitored and controlled by 

automation systems using distributed programmable logic control systems designed for operation in harsh conditions 

and with critical timing constraints. Manufacturing operations in larger industrial enterprises are often integrated with 

business systems and enterprise resource management to optimize efficiency and profit.

The capability for customers to react to opportunities and challenges that occur in the electrical system (i.e., dynamic 

pricing, demand response events and retail energy transactions) is highly dependent upon the customer’s flexibility to 

dynamically schedule and optimize the operation of energy assets which is impacted by the level of automation [10] 

and operational constraints. As an example, an energy asset considered critical to producing revenue or ensuring health 

and safety will probably not be available for rescheduling.

Automation systems represent significant capital investments and on-going operational expense. They are typically 

implemented based on the control system’s ability to address operational and business challenges while providing a 

return on investment measured against the costs of manual operation. Typically, the benefits of automation increase as 

the complexity and costs of a task increase.

Diversity of Communications Technology

Communication protocols have been developed in the customer sub-domains to meet the economic and technical 

requirements indigenous to each sub-domain. Home technologies are very cost sensitive and targeted at a limited range 

of relatively simple applications while commercial and industrial technologies must meet more demanding 

requirements associated with performance and reliability in a broader set of complex applications. This has led to a 

diversity of protocols which must interact with an ESI. The development of the Facility Smart Grid Information Model 

standard [11, 12] provides a common information model for smart grid interactions with the customer domain, and 

which in turn aids in defining standard interfaces to diverse customer domain protocols [13].

Communications between grid-side service providers and customers should accommodate customer diversity, to the 

degree possible, in order to enable innovation through thriving product markets while limiting diversity and risk in grid 

operations. Achieving this requires that the information elements that flow between the domains be limited to: 1) what 

is required to satisfy the use cases and 2) the overlapping information that links the different domain models together. 

In general, a given interface will be more broadly useful to a diversity of devices/systems if the information 

communicated across the interface is more abstract, exposing fewer system-specific details. The level of abstraction 

provided by an interface should vary based on the business and application requirements. 
This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.TN.1832

5

Use Case Analysis for Interface Information Requirements

In this section the various smart grid use cases involving customer interactions are distilled to common use case classes 

and the information elements from these common classes are then identified. These key information elements serve as 

the building blocks for cross-domain interface standards. A given interface standard must define communication 

protocol messages for relevant information elements which are themselves represented according to some data model. 

Use case classes help to define the protocol messages and the information elements that need to be exchanged. 

Significant effort has been expended over the last decade to collect use cases for electric grid interactions, of which 

some apply to customer-to-grid service provider interactions [14, 15, 16, 17]. The use cases cover a wide range of smart 

grid interactions, with emphasis on different domains and applications for grid service providers and customers. Many 

Table 1 Customer Interface Use Cases and Corresponding Information Elements

Use Case Classes Description Customer Interface Required Information Elements

Energy Market 

Transactions

Balancing and trading power, externally 

with electricity, gas and other energy 

markets, and internally balancing energy 

sources.

Energy supply cost data (including electricity price 

forecasts), market transactions (indications of interest, 

bids, and trans-actions). Demand forecasts also require 

weather forecast data. 

Demand 

Response

Demand Response: Day ahead capacity DR 

and Day-of DR; Fast-DR (ancillary 

services); and price communications. 

Includes event communications, supporting 

services, feedback, and measurement and 

verification (M&V).

DR event information (start time, duration, and 

level/amount), price and product, event status, market 

context, resource ID and service location. Support 

information includes: registration, opt in/out, availability, 

event response and meter data for M&V.

Direct Load 

Control (DLC)

Direct control of facility loads. Commands to turn on/turn off end node, or more 

sophisticated generator/storage control signals.

Facility Energy 

Management 

(FEM)

Energy management of facility loads, 

storage and generation which includes 

monitoring, planning and control of facility 

energy use, emissions, and power quality.

Validated meter (energy usage) data, energy cost data 

(including electric price forecasts), emissions data and 

weather forecasts.

Remote System 

Monitoring and 

Management

Monitoring and management of system 

health by service providers to allow system 

diagnostics and remote energy 

management.

High-frequency meter data, power quality data and 

sub-system status. Remote FEM may require additional 

building system data (occupancy and process schedules, 

business planning, etc.)

Integration of 

Customer 

Distributed 

Energy 

Resources

Exchange of grid and distributed energy 

resource (DER) status.

Grid power voltage and quality forecasts, generation and 

storage status (available power, charge level, ramp rates, 

availability schedule, priority, present demand, forecast 

demand, etc.). Alternatively, DER integration may be 

enabled via market transactions or DR signals.

Emergency 

Notification

Notification that a power disruption is 

imminent.

Alerts and warnings of power system degradation or 

failure.
This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.TN.1832

6

of these use cases include communication of information elements across the ESI, and these use cases in turn can be 

summarized in a small set of use case classes that are presented in Table 1. Abstracting away some of the use case 

details and combining them in this way helps to clarify the capabilities needed in an ESI.

The information elements in the right hand column of Table 1 may be reduced to a set of key elements, as given in 

Table 2. These information elements represent key functions of the interface that must be supported by interface 

standards in order to meet use case requirements. One important observation is that there is a limited set of information 

elements that together satisfy the needs of a large set of use cases. The use case classes (Table 1) cover essentially all of

the envisioned smart grid interactions that enable customer load and distributed energy resources (DER) support of grid 

reliability to achieve smart grid goals.

Another observation is that significantly different types of DR interactions appear in Table 1. DLC requires low-level 

control interfaces that will be limited in application to specific types of devices and perhaps only certain customer 

groups. DR event signals can be more broadly disseminated, but may be implemented at different levels of abstraction 

with more or less visibility into customer sub-systems. Energy market transactions represent a fully decoupled 

interaction with the customer.

Table 1 use case classes have been presented in terms of abstracted applications on the grid side and customer side. For 

example, one does not see “distribution system management” or “electric-vehicle management”. Instead, one sees the 

more abstract classes of demand response and customer DER integration. Also, Table 1 includes the abstract customer 

application of facility energy management. Please note that the information elements in the right hand column are only 

those which cross the ESI, and not all information needed for facility energy management or any other customer or 

utility application.

It should be noted that a service provider of “Remote System Monitoring and Management”, may be either an energy 

provider or third party. Also, the “Integration of Customer DER” use case class calls for communication of DER status 

information. This may be communicated by a low-level control protocol or a higher-level DR protocol. “Integration of 

Customer DER” also includes grid power voltage and quality forecasts which provide grid status information from an 

energy service provider to the customer. Similarly, the “Emergency Notification” use case class acknowledges the need 

for alerts to warn customers of imminent disruptions so that appropriate actions may be taken. 

Table 2 Key Information Elements for the ESI

1 Price and product information (real-time and forecasts)

2 Market transaction data (bids, indications of interest, transactions)

3

DR signals (events and support services: registration, availability, 

opt-in/opt-out, feedback)

4 Energy usage information (meter data) including demand forecasts

5 Direct control signals

6 Weather forecasts

7 Power quality

8 Emissions data

9 Generation and storage status data

10 Emergency notifications
This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.TN.1832

7

The DR Conceptual Model

Demand response refers to changes in electric usage by end-use customers from their normal consumption patterns in 

response to changes in the price of electricity over time, or to incentive payments designed to induce lower electricity 

use at times of high wholesale market prices or when system reliability is jeopardized [18].

The electric industry has implemented various methods of demand response. ISO/IEC 15067-3 [19] divides these 

methods into direct and indirect load control that may convey control and price signals. Considering the use case 

classes of Table 1 leads to further refinement of these two levels into four levels. These methods can be viewed as four 

distinct hierarchical levels of interactions as presented in the “DR Conceptual Model” of Fig. 3.

Fig. 3 Levels of Abstraction: DR Conceptual Model.

The DR Conceptual Model illustrates a range of service provider-to-customer interactions, from business level 

transactions down to direct load control. It defines four levels of abstractions from the perspective of the service 

provider: 1) Transactive Energy, 2) Request Demand Modification, 3) Indirect Monitoring and Control and 4) Control 

Physical Devices.

The DR Conceptual Model also shows the hierarchy of control that exists in any customer facility, depending on the 

level of automation present. Within the Customer Domain, customer business decisions provide input to energy 

management and control systems which interface to lower level system controls and finally to control actions at the 

physical device level. External grid service providers or markets can interact with the Customer Domain at the 

customer enterprise, facility, system or device levels, entering the Customer Domain control hierarchy at different 

points with different effect and implications as discussed below. 
This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.TN.1832

8

Transactive Energy

Transactive energy is the highest level of abstraction. At this level, a service provider interacts with the customer 

through business processes communicating business value. By interacting at the business process level, the service 

provider views the customer as an autonomous decision-making entity that is capable of optimizing its internal 

behavior in response to grid signals. The customer determines and performs all control actions.

The interface can represent a facility or enterprise (e.g., multiple facilities) and the data transferred across the customer

interface may include energy price quotes, market-based tendered energy bids and resulting transactions, weather and 

weather forecasts, system status information and notifications of imminent grid disruption. The service provider does 

not have visibility beyond the interface although sufficient information is available at the interface to enable both 

customers and service providers to execute specific use cases.

At this level, the customer or customer’s automation systems decide on the optimum course of action to achieve the 

best economic and performance results. The customer has a choice on how, or whether, to respond and the service 

provider is not impacted by internal system changes that occur on the user side. More advanced automation strategies 

may be required to take advantage of time-variant prices while minimizing risk.

Request Demand Modification

At this level, the focus is on “what” needs to be achieved, while the customer retains control of “how” to respond. The 

service provider specifies and conveys the desired results and the user decides how to achieve those results, e.g., 

"Reduce load by 10 kW." The customer or the customer’s automation systems decide on the optimum course of action, 

based on an analysis of the tradeoffs, to achieve the desired results with the minimum negative operational impact and 

maximum positive impact on the facility. The service provider does not require knowledge of the exact details of how 

the user will respond internally, only the overall result. This also minimizes the impact of system changes that occur on 

the customer side.

A service provider should not expect all customers to fully comply with a reduction request. However, depending upon 

the contractual relationship, the customer may be fully responsible for achieving the agreed upon results and may risk 

penalties if they fail to achieve the requested results.

Indirect Monitoring and Control

At this next level of abstraction, service providers interact with “logical” systems or devices, not physical ones. There is 

control logic between the service provider and the load; the service provider requests an action to occur on a logical 

device or system. For example, a service provider might send a command to a thermostat setting a specific set point. 

Higher priority requirements in the control logic may override the signal from the service provider, e.g., overrides 

related to safety or equipment reliability.

Indirect monitoring and control provides indirection and decouples the customer’s internal physical systems and 

devices from the service provider permitting changes (e.g., device replacement) to occur on either side of the interface. 

The logical devices can implement and expose consistent behaviors to the service provider. All physical control 

actions, manual or automatic, are performed by the customer and can be overridden by the customer. Service providers 

do not require full knowledge of the devices in the customer domain, because the automation system ensures that 

appropriate facility and equipment constraints are maintained.

Data transferred across the customer interface may include demand response signals or set points commanding certain 

indirect actions (e.g., reduce consumption to baseline, increase temperature 2 degrees, charge/discharge storage), meter 
This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.TN.1832

9

readings, power quality, emissions, availability of load reduction or generation for DR, DR feedback for measurement 

and verification, fault detection, power quality monitoring, etc.

Some example applications that use indirect monitoring and control are: 1) contracted DR programs, 2) external 

equipment monitoring, 3) DR feedback and 4) measurement and verification.

The customer requires some level of automation capability depending upon what devices are being controlled. This 

may increase cost if new automation equipment is required. Addressing the associated risks related to security and 

privacy concerns may also result in additional costs.

Service providers gain more granular interactions but may be impacted by changes in the customer’s automation 

equipment if the changes are not performed in a coordinated and safe manner. In addition, the customer is only 

responsible for doing what was requested and not for whether the request is sufficient to achieve the needed demand 

reduction.

Currently, service providers wishing to communicate at this level must interface with a number of well-established 

protocols used by existing automation systems.

Control Physical Devices

At the lowest layer of abstraction, the service provider directly controls the power to loads through the command and 

control of physical systems or end devices within a customer facility. This normally involves service providers sending 

commands to start and stop physical devices and query device value and status information. An important requirement 

is that all controlled devices are the same or very similar.

All decision making and automation is performed by the service provider with little or no involvement by the customer. 

The customer has no risk or responsibility for whether the load is actually controlled as directed by the service provider. 

The service provider however must understand exactly how the load operates in order to turn power on and off directly 

and how this affects safety, reliability, environment, comfort, etc. As such, it is most appropriate for interfacing simple 

devices that control simple static loads that don’t change over time. Low-level physical control is often the lowest cost 

in the absence of existing automation equipment.

Some example applications include: 1) remote cycling of air conditioning (AC) units, 2) remote cycling of water 

heaters, and 3) remote operation of back-up generation units. An example of remote cycling is the use of a radio 

frequency signal to trigger relays on air conditioning units in the summer. 

The term “direct load control” (DLC) is often used to refer to a DR service provider directly switching on or off

customer systems, devices, or appliances. DLC is widely used with residential customers and ISO/IEC 15067-3 

defines DLC in the residential context as “remote control of one or more appliances by a utility or third-party service 

provider” [19].

Cross-Cutting Issues of the DR Conceptual Model 

The drivers for moving up or down the DR hierarchy in Fig. 3 are represented in the arrows on the right side of the 

figure. This section examines each of these. 

Increasing Customer Choice

From the perspective of the service provider, higher abstractions result in greater dependence upon the customer to 

perform as requested. This requires greater customer technical and decision-making capability which includes 
This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.TN.1832

10

automation systems. This results in greater complexity for the customer and requires investment in automation systems 

that must be justified as they require up-front capital and on-going maintenance investment. 

Increasing Customer Responsibility

At lower levels of customer interaction, the service provider is responsible for installation and maintenance of 

equipment and connections used to control the system response. The service provider is also responsible for all 

demand reductions which are achieved or not achieved as a result of system problems. At higher levels of demand 

response interaction, responsibility for installation and maintenance of facility equipment that is used to control the 

response shifts to the customer. The financial benefits and risks of participating in the program also shift to the 

customer.

Increasing Need for Customer Automation

At lower levels of interaction, the customer is not required to have any automation equipment since the service provider 

directly controls whether power is allowed to flow to the load. The need for automation increases at higher levels of 

interaction. At the level just above Control Physical Devices, this may be as simple as a thermostat. Higher levels of 

interaction may require a building management system, energy management system, or even some type of enterprise 

level system that considers tradeoffs between energy prices and other business considerations. 

Increasing Grid/Customer Decoupling

The customer domain diversity section earlier demonstrated the benefits of a more abstract interface that can interact 

with a wider range of customer devices and systems. Lower levels of interaction require detailed knowledge of devices 

or systems on the customer side of the ESI and make such an interaction more end-system specific and less scalable and 

reusable. The interface used for a specific application use case should be at as high level as possible but matched to, or 

balanced with, required application functionality. If an interface provides insufficient functionality, techniques may be 

implemented to circumvent or bypass the interface, resulting in decreased interoperability. If the interface provides 

excessive functionality, the costs to implement and maintain the interface increase [13]. Conformance to this important 

abstraction principle will help achieve the interoperability and reliability goals of the smart grid and enable future 

innovations by hiding complexity and enabling independent development within domains.

Increasingly Deterministic Results

At lower levels of interaction, the resulting response can be very deterministic since the service provider is directly 

disconnecting the power to the load. At the higher levels of interaction, the resulting response is more indeterminate 

unless aggregation of numerous resources is included. Aggregation converts a collection of indeterminate resources 

into a determinate resource for the grid. 

Independence of Quality-of-Service Requirements

This paper has focused on functional requirements at the customer interface, as seen in Table 1. Each use case also has 

a range of non-functional quality-of-service requirements: message transport, network performance, security and 

privacy, scalability, etc. Here we specifically note that while quality-of-service requirements are important in interface 

implementations, they are also orthogonal to the DR Conceptual Model. Any level of the DR Conceptual Model may 

be implemented with any given set of quality-of-service requirements. The important corollary is that one should 

implement an interface in such a way that the messages that communicate the information elements are separated from 

the transport, security and other quality characteristics. 
This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.TN.1832

11

Conclusion

Demand response implementation has largely focused on what can be accomplished to manage customer load during 

grid demand peaks. There has not been a careful examination of the nature of the customer domain and associated use 

cases. This paper has presented the diversity of the customer domain and an analysis of smart grid customer interaction 

use cases from which were deduced a set of use case classes and key information elements crossing the customer 

energy services interface. This analysis was used in the development of a DR Conceptual Model which presents the 

range of DR interactions along with the drivers for adopting one DR approach versus another. Customer domain 

diversity emphasizes the need for broadly applicable interfaces using more abstract communications and minimal 

information for a given application. Use case classes and derived key information elements guide development of more 

broadly applicable interface standards. 

Acknowledgements

Special thanks to Allen Jones, Schneider Electric, for his support in developing and articulating the customer interface 

stack. Thanks also to the SGIP Building-to-Grid Domain Expert Working Group for input and collaboration in 

development of some concepts in this paper.

References

[1] European Commission communication, “Europe 2020: a strategy for European Union growth”, March 2010, 

available at: http://europa.eu/legislation_summaries/employment_and_social_policy/eu2020/em0028_en.htm.

[2] Organization for Economic Cooperation and Development, “Declaration on Green Growth,” C/MIN(2009)5/

ADD1/FINAL, June 2009.

[3] U.S. Public Law 110-14, Energy Independence and Security Act (EISA) of 2007.

[4] Holmberg, D. G., G. Ghatikar, E. Koch, and J. Boch, "OpenADR Advances", ASHRAE Journal, vol. 54, issue 11, 

2012.

[5] C. Ashley, L. Holmes, G. Wikler, EnerNOC Utility Solutions, “Using More Energy Can Be a Good Thing: C&I 

Loads as a Balancing Resource for Intermittent Renewable Energy,” 2013 ACEEE Summer Study on Energy 

Efficiency in Industry, July, 2013, available at: http://aceee.org/files/proceedings/2013/data/papers/3_090.pdf.

[6] Holmberg, D.G., “Facility Interface to the Smart Grid”, Proceedings of Grid-Interop 2009, The Road to an 

Interoperable Grid, November 17-19, Denver, CO, page 161. Available at: 

http://www.grid-interop.com/2009/downloads/GI09-Procedings.pdf. Need 266.

[7] NIST, “NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 2.0,” NIST Special 

Publication 1108r2, Feb, 2012.

[8] The Open Group, “ArchiMate® 2.0 Specification”, 2012, available at: 

http://pubs.opengroup.org/architecture/archimate2-doc/.

[9] CEN-CENELEC-ETSI Smart Grid Coordination Group, “Smart Grid Reference Architecture,” November, 2012. 

Available at: http://ec.europa.eu/energy/gas_electricity/smartgrids/doc/xpert_group1_reference_architecture.pdf.

[10] Endsley, M.R., Kaber, D.B., “Level of automation effects on performance, situation awareness and workload in a 

dynamic control task,” Ergonomics, v 42, NO. 3, p462, 1999.

[11] American Society of Heating Refrigeration and Air-conditioning Engineers, “Facility Smart Grid Information 

Model,” ASHRAE Draft Standard 201 and ISO CD 17800.

[12] Bushby, S.T., "Information Model Standard for Integrating Facilities with Smart Grid", ASHRAE Journal Vol. 53 

No. 11, November 2011.

[13] Smart Grid Interoperability Panel B2G/I2G/H2G Domain Expert Working Groups, “Customer Energy Services 

Interface White Paper Version 1.0,” D. Hardin, Ed., 2009. Available at: 
This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.TN.1832

12

http://collaborate.nist.gov/twiki-sggrid/pub/SmartGrid/EnergyServices

Interface/EnergyServicesInterfaceWhitePaper_V1_0.pdf.

[14] EIS Alliance, “Energy Information Standards (EIS) Alliance Customer Domain Use Cases,” v. 3.01, May 2010, 

available at: http://www.eisalliance.org/. 

[15] IEC PC118 Smart Grid User Interface collected use cases, to be published in upcoming PC118 Technical Report. 

[16] UCA International User Group OpenHAN Task Force of the Open Smart Grid Technical Committee, ”UCAIug 

Home Area Network System Requirements Specification,” v2.0, August 2010, information available at: 

http://osgug.ucaiug.org/sgsystems/openhan/default.aspx.

[17] Smart Grid Interoperability Panel Interoperability Knowledge Base “IKB Use Cases”, available at: 

http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/IKBUseCases.

[18] U.S. Department of Energy, “Benefits of Demand Response in Electricity Markets and Recommendations for 

Achieving Them: A Report to the United States Congress Pursuant to Section 1252 of the Energy Policy Act of 2005,” 

February 2006.

[19] ISO/IEC 15067-3 “Information technology -- Home Electronic System (HES) application model -- Part 3: Model 

of a demand-response energy management system for HES,” 2012.