**NIST SG function description and use case template**

**DGH ver.2**

**(Building-centric view of Smart Grid)**

# Smart Grid function description

## SG function name

Load management with dynamic tariffs, predictable and non-predictable
demand reduction with demand shifting, shedding and limiting and/or
on-site generation capability without local resource optimization.

## Description

**Load management** is a daily effort with a goal to minimize utility
costs. While the goals in the future may include reducing CO2 emission
minimization or buying "green" power in which case generation resources
need to communicate these attributes (or these attributes may be a part
of the price?), in this use case, load management is defined as managing
a consumer's supply and demand sources using dynamic prices as the main
trigger. DR is any action taken by the consumer to reduce loads when
market conditions raise price of electricity. In this use case, high
prices will trigger DR. **Predictable on-site generation** is any
generation unit with known parameters for *min, max, ave load, ramp up
and ramp down time and with an availability schedule.* The availability
schedule may be fixed or dynamically produced.

**Non-predictable on-site generation** is any generation (e.g. solar,
wind, PHEV) where at least one of the parameters may be missing from an
availability schedule.

. **Demand limiting** refers to shedding loads when pre-determined peak
demand limits are about to be exceeded. This is historically done in
daily load management activities to minimize peak demand charges. Loads
are restored when the building demand is sufficiently reduced. Demand
limiting is done to flatten the load shape when the electric load shape
is nearing a pre-determined peak. **Demand shifting** moves electric
loads from peak times to off-peak periods. The most common technologies
to support diurnal demand shifting are thermal energy storage systems,
which are often designed with ice or chilled water. **Demand shedding**
is dynamic temporary reduction of peak load that can be dispatched with
automated controls.

**Local resource optimization** means buying power from the resources on
the same feeder before buying it from the grid. IEEE 1547 only addresses
what a small generator must do to be allowed to connect to the grid. It
says nothing about the economic relationships. In CA, the rules allow
sales between neighbors with a common boundary, but not across roads,
rivers, etc. A separate use case is needed to hash out this issue.

There are several underlying assumptions for this use case:

1.  There is a uniform market infrastructure that allows for each
    consumer to buy and sell power, that is information exchange between
    an energy provider and a single consumer can be the same as the one
    between an ISO and an aggregator.

2.  Buildings have sophisticated energy management and controls systems
    and/or energy information systems such as real-time optimization,
    predictive controls, etc.

3.  There is a clearly defined divide between building-side technologies
    and strategies and energy provider technologies and strategies. The
    energy provider does not reach into the buildings but provides
    information to the consumer systems in a form that can be directly
    utilized.

## Smart Grid context and standards

### Business Objective

The goal of this function is for the consumers to manage their load so
that they can minimize utility costs. This requires optimization of
resources such as on-site generation plus electric load management with
changing price of electricity.

### Smart Grid domain and stakeholders

There are two main parts to managing load: utility-side information
delivery (prices) and building-side information process (demand and
on-site supply management). On the building-side, energy information
system providers, control system providers, building owners, facility
management firms, building system manufacturers, etc. On the
utility-side, the stake holders are ISOs, T&D as well as energy
providers.

### Standards landscape

  --------------------- ----------------------- --------------------------
  ***Standard/          ***SDO/ organizations   ***Gaps/ harmonization
  guideline/            involved***             efforts***
  standardization                               
  effort***                                     

  Utility Price         Lawrence Berkeley       
  delivery - OpenADR    National Laboratory     

  Building-side demand  Various building        
  and supply management controls protocols      
  -?                                            

  Local Supply and      None so far...          
  Demand Management                             
  --------------------- ----------------------- --------------------------

## Function use case narrative

The simplest use case is current typical case in CA where large
commercial customers manage their loads for TOU rates and Demand
Charges. It is assumed that smaller customers may participate
individually and directly in the future.

Typical scenario includes:

1.  Energy Provider publishes prices a day ahead or day-of (one hour or
    15 min. before).

2.  Facility sets up price thresholds and for each threshold, decides
    what kind of load reduction or on-site generation they want to bring
    up and pre-program these strategies (or have tools to dynamically
    respond).

3.  For predictable loads, all known parameters (min, max, average, ramp
    up, ramp down) are sent as "predicted response schedule"

4.  For non-predictable loads, estimated parameters are sent as
    "estimated response schedule"

5.  Energy Provider receives this information and uses it in its
    planning.

> Note: This scenario can be used for DR and Daily Peak Load Management.

## Actors

  ------------- -----------------------------------------------------------
  ***Name***    ***Role description***

  Utility/ISO   Provide a brief description of the role that an Actor has
                in this particular use case. An Actor can be a human or a
                system. The same Actor can play different roles in
                different use cases but only one role in one use case. If
                the same Actor does play multiple roles in one use case,
                list these separately.

  Building      
  EIS/EMCS      

  Local         
  resource      
  network       

                
  ------------- -----------------------------------------------------------

## Information exchanged 

Describe any information exchanged in this function.

+--------------------+-------------------------------------------------+
| > ***Information   | > ***Information Object Description***          |
| > Object Name***   |                                                 |
+====================+=================================================+
|                    |                                                 |
+--------------------+-------------------------------------------------+
|                    |                                                 |
+--------------------+-------------------------------------------------+

## Services 

Describe or list the services involved in this Function (in the context
of this Function). A service can be provided by a computer system, a set
of applications, or manual procedures. These services should be
described at an appropriate level, with the understanding that
sub-services should be described if they are important for operational
issues, automation needs, and implementation reasons. Other sub-services
could be left for later analysis.

  -----------------------------------------------------------------------
  ***Service Name***      ***Services Provided***
  ----------------------- -----------------------------------------------
                          

                          
  -----------------------------------------------------------------------

## Contracts, regulations, other constraints

Identify any human-initiated contracts, regulations, policies, financial
considerations, engineering constraints, pollution constraints, or other
issues that affect the design and requirements of the function.

  --------------------------------------------------------------------------------
  ***Contract/Regulation***   ***Impact of Contract/Regulation on Function***
  --------------------------- ----------------------------------------------------
                              

  --------------------------------------------------------------------------------

  --------------- ------------ ----------- ---------- ------------- --------------------------- ----------
  ***Policy\      ***From      ***May***   ***Shall   ***Shall***   ***Description (verb)***    ***To
  ***             Actor\                   Not***                                               Actor***
                  ***                                                                           

  ProvideEnergy   ESP                                 X             Provide power on demand     Customer

                                                                                                

                                                                                                
  --------------- ------------ ----------- ---------- ------------- --------------------------- ----------

  ------------------ ------------ -------------------------------- --------------------
  ***Constraint***   ***Type***   ***Description***                ***Applies to***

                                                                   

                                                                   

                                                                   

                                                                   
  ------------------ ------------ -------------------------------- --------------------

# Step by step analysis of function

## Pre-conditions and assumptions

Describe conditions that must exist prior to the initiation of the
Function, such as prior state of the actors and activities.

Identify any assumptions, such as what systems already exist, what
contractual relations exist, and what configurations of systems are
probably in place.

Identify any initial states of information exchanged in the steps in the
next section. For example, if a purchase order is exchanged in an
activity, its precondition to the activity might be 'filled in but
unapproved'.

  --------------------------------------------------------------------------------------
  ***Actor/System/Information/Contract***   ***Preconditions or Assumptions***
  ----------------------------------------- --------------------------------------------
                                            

                                            
  --------------------------------------------------------------------------------------

## Normal sequence

Describe the normal sequence of events, and focus on steps that identify
new types of interactions, new information, or new issues to address.
Should the sequence require detailed steps that are also used by other
functions, consider creating a new "sub" function and then referring to
that "sub-routine" in this function.

+---+-------+-------+----------------+---------------+----------------+
| * | *     | ***S  | ***Description | *             | ***Response to |
| * | **Eve | ender | of             | **Information | action***      |
| * | nt*** | to*** | pro            | to be         |                |
| S |       |       | cess/action*** | exchanged***  |                |
| t |       | ***r  |                |               |                |
| e |       | eceiv |                |               |                |
| p |       | er*** |                |               |                |
| * |       |       |                |               |                |
| * |       |       |                |               |                |
| * |       |       |                |               |                |
+---+-------+-------+----------------+---------------+----------------+
| 1 | Trigg | What  | Describe the   | Identify the  | Describe the   |
| \ | ering | actor | actions that   | information   | response to    |
| . |       | or    | take place in  |               | the action in  |
|   | event | s     | active and     | that will be  | present tense  |
|   |       | ystem | present tense. | exchanged.    | form as for    |
|   |       | is    | The step       |               | the "Actor     |
|   |       | se    | should be a    | Indicate      | action."       |
|   |       | nding | descriptive    | special       | "If.           |
|   |       | to    | noun-verb      | conditions    | ..Then...Else" |
|   |       | what  | phrase that    |               | scenarios can  |
|   |       | other | portrays an    | such as       | be captured as |
|   |       | actor | outline        | accuracy,     | multiple       |
|   |       | or    | summary of the | security, and | responses or   |
|   |       | s     | step.          | availability  | as separate    |
|   |       | ystem |                |               | steps.         |
|   |       |       |                | requirements. |                |
+---+-------+-------+----------------+---------------+----------------+
| 2 |       |       |                |               |                |
| \ |       |       |                |               |                |
| . |       |       |                |               |                |
+---+-------+-------+----------------+---------------+----------------+
| 3 |       |       |                |               |                |
| \ |       |       |                |               |                |
| . |       |       |                |               |                |
+---+-------+-------+----------------+---------------+----------------+
| 4 |       |       |                |               |                |
| \ |       |       |                |               |                |
| . |       |       |                |               |                |
+---+-------+-------+----------------+---------------+----------------+

## Alternative/exception sequences

Describe any alternative or exception sequences that may be required
that deviate from the normal course of activities.

+----+------+------------+--------------+-------------+---------------+
| ** | ***  | ***Sender  | **           | ***         | ***Response   |
| *S | Even | to***      | *Description | Information | to action***  |
| te | t*** |            | of           | to be       |               |
| p* |      | ***r       | proce        | e           |               |
| ** |      | eceiver*** | ss/action*** | xchanged*** |               |
+----+------+------------+--------------+-------------+---------------+
| 1  |      |            |              |             |               |
| \. |      |            |              |             |               |
+----+------+------------+--------------+-------------+---------------+
| 2  |      |            |              |             |               |
| \. |      |            |              |             |               |
+----+------+------------+--------------+-------------+---------------+
| 3  |      |            |              |             |               |
| \. |      |            |              |             |               |
+----+------+------------+--------------+-------------+---------------+
| 4  |      |            |              |             |               |
| \. |      |            |              |             |               |
+----+------+------------+--------------+-------------+---------------+

## Post-conditions

Describe conditions that must exist at the conclusion of the Function.
Identify significant items similar to that in the preconditions section.

Describe any significant results from the Function

  ---------------------------------------------------------------------------
  ***Actor/Activity***   ***Post-conditions Description and Results***
  ---------------------- ----------------------------------------------------
                         

                         
  ---------------------------------------------------------------------------

# Additional issues

## References and contacts

Documents and individuals or organizations used as background to the
function described; other functions referenced by this function, or
acting as "sub" functions; or other documentation that clarifies the
requirements or activities described. All prior work (intellectual
property of the company or individual) or proprietary (non-publicly
available) work must be so noted.

  ---------- ----------------------- -----------------------------------------
  ***ID***   ***Title or contact***  ***Reference or contact information***

                                     

                                     
  ---------- ----------------------- -----------------------------------------

## Key Interfaces

Note key interfaces between function stakeholders. For each interface,
discuss GWAC interoperability framework cross-cutting issues (shared
meaning of content, resource identification, time synch and sequence,
security and privacy, logging and auditing, transaction and state
management, system preservation, quality of service, discovery and
configuration, system evolution and scalability).

  -----------------------------------------------------------------------
  ***Interface between*** ***Cross-cutting issues***
  ----------------------- -----------------------------------------------
                          

                          
  -----------------------------------------------------------------------

## Outstanding Issues

As the use case is developed, identify issues that need clarification,
resolution, or other notice taken of them. This can act as an action
item list.

  ---------- ---------------------------------------- -----------------------
  ***ID***   ***Description***                        ***Status***

                                                      

                                                      
  ---------- ---------------------------------------- -----------------------

## Revision history

  ----------- ------------ ------------------ ----------------------------------
  ***No.***   ***Date***   ***Author***       ***Description***

                                              

                                              
  ----------- ------------ ------------------ ----------------------------------

## Diagram

For clarification, draw (using UML diagram conventions, as appropriate)
the interactions described above and identify the steps where possible.