[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Load predictions in EI
|
David, I should go back and check the EIUsage operations,
but I also had that use case in mind as well. If we are doing load profile
predictions then obviously EIUsage could be used for both use cases since it is
basically the same information. One data set is what you predict will
happen before the event and the other is what was measured to happen
during/after the event. One could argue that if in fact they are different data
types and semantics then it makes it hard to compare them, which is ultimately what
you probably need to do with the data. The other types of predictive information within
EI that may be communicated to the VTN (Utility/ISO/Service provider) by the
VEN is the constraint schedules, the opt in/out state, and the performance
envelope attributes such as ramp rates etc. If there is other types of VEN derived
information that the VTN would like to know to allow it to predict the VEN
performance then I’m not sure we have defined it. Thanks, -ed koch From: Holmberg, David
[mailto: Thanks Ed. I always thought EiUsage was
to transport the NAESB EUI data, which is the validated meter data from the
utility back end, rather than a forward load prediction or current status from
the facility. Anyone else have thoughts? Thanks, David From: Edward Koch
[mailto:ed@akuacom.com] David, There is an EIUsage service in EI. I
always assumed that your use case is precisely what that service was used for. Thanks, -ed koch From: Holmberg, David
[mailto: EI folks, The 201P use cases and current 201P
model includes the idea of feedback across the ESI that communicates load
estimates as well as generation and storage status. This might be in the
context of a microgrid where we are using EI to talk to some storage system,
and we need some representation of storage status, or of load shed availability
(here is what I, Building 110 EMS, expect as load for the next 6 hours given a
price curve) or of generation predictions. This could also be in the
context of an offsite aggregator/DSO utility. So, is load/storage/gen status
information now fully represented in EMIX? And how do we move that information
in EI? EiFeedback is currently associated with an event, but that
wouldn’t be the case here for load estimates, yet EiFeedback seems the
best fit. Maybe we define a part of Feedback that is independent of Events to
allow a request for feedback and response? The response would have an EMIX
object with load or generation estimates in a schedule. What do you think? David From: Holmberg, David Just
following up on this Duty Window
thread after an email exchange with Ed Koch. What we have in Energy Interop is
the detailed schedule for an event. Sub-intervals for compliance purposes (ala
Duty Window in the LCO) are defined as sub-intervals of the event schedule.
This is the way of communicating that this program will be looking at your
meter to check for compliance over this interval. Which is different from the
Feedback service in EI. EiFeedback provides information about the state of the
Resource as it responds to an Event signal, so it is self-reporting. It is
currently undefined as to what that feedback is. It could be "actual
present demand" or it could be "where I expect to end up for this
shed" (both a bit difficult to define), or something else. There is an
associated "reporting interval" attribute in the EiEvent class that I
think is the frequency of feedback (Bill?) -----Original
Message----- Do
we have anything in the 201 model equivalent to "Duty Window" in the
LCO? The only thing in Energy Interop is the duration of the event, which is
why I asked my last question. David -----Original
Message----- From:
Chandrashekhar Appanna [mailto:achandra@cisco.com] Sent:
Tuesday, April 05, 2011 1:29 PM To:
Holmberg, David Cc:
Chandrashekhar Appanna; Jerald.P.Martocci@jci.com; Gowri, Krishnan; Wallace,
Evan K.; daken.abigail@epa.gov; gmd14@psu.edu;
chantipal.sourignavong@honeywell.com; mikeg@echelon.com; Subject:
Re: SPC201 - Joint EM/Loads Discussion (Today, April 5) The
only fields in the Load Control Object that are contentious are expected shed and
actual. The first is not very clear in functionality and is only used before shedding
kicks in. The actual is the actual.. Now,
while this is considered feedback, it is not really modeled as that in our
case.. meaning
there is no implication of a transport. Both of the above pieces of information are
available in the model already - there is data on what is expected at each shed
level. And there is metering to measure over and above what is expected as specified.
So,
what else is missing? Regards, Chandra. On
Apr 5, 2011, at 10:21 AM, Holmberg, David wrote: >
Jerry, all, >
>
I missed the last call. To point number 1 below, I believe using the BACnet
Load Control approach is fine, because it is consistent across OpenADR and
BACnet. However, I think we should use the attributes already in the EM from
Energy Interop to fulfill the DR curtailment (shed) requests. >
>
I’m also still not comfortable with the Aggregated Load bringing EM
functionality to the Load Object. From the top side, the aggregated load looks
like any load, and I can send it a command to vary its power output based on
what it communicates about itself (“I have 20 states with this much power
available at each state, at these priorities” or whatever). But on the
backside of the Aggregated Load is an EM giving commands to lower level loads.
This is equivalent to the Virtual Top Node (VTN) and Virtual End Node (VEN) in
Energy Interop. That is, the Aggregated Load appears as an end-node Load to the
VTN EM, but on its backside is another VTN. This seems a different picture than
what we discussed before. Here is the old picture for our “smart
load”: >
<image002.png> >
But now it seems to look like this for an aggregated load serving as interface
to sub-loads (smart or dumb): >
<image003.png> >
>
For question number 3 below, is anyone aware of DR programs that evaluate
compliance based on a sub-interval (less than the duration of event)? That is,
seeing if you are, on average, below the agreed upon baseline across some
window of time less than the full event duration? >
>
Thanks, >
David >
>
From: Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com] >
Sent: Tuesday, April 05, 2011 9:50 AM >
To: Gowri, Krishnan; Wallace, Evan K.; daken.abigail@epa.gov; gmd14@psu.edu;
chantipal.sourignavong@honeywell.com; mikeg@echelon.com; >
Cc: Rich A Morgan; John.Ruiz@jci.com; Bushby, Steven T. >
Subject: SPC201 - Joint EM/Loads Discussion (Today, April 5) >
>
>
Hi All, >
>
Krishnan is on vacation this week and asked if I would host his meetings. >
>
We will have a phone conference today to continue the discussion of how the
Loads and EM models will coexist and interoperate. The meeting will
follow the normal EM schedule and be at 10:30 - 12:00 PDT, (11:30 - 1:00 MDT,
12:30 - 2:00 CDT, 1:30 - 3:00 EDT). The Webex info follows at the end of
this email. >
>
The agenda is currently as follows. We will pick up the discussion on
item 4 below. Please contact me before the meeting if you would like to
amend or reorder the agenda items: >
>
1. How will the EM signal the loads
for a curtailment request ? >
>
DONE: The teams agreed to follow the BACnet Load Control
Object model and incorporate its attributes into the Loads and EM models as
needed. >
>
2. Does the EM expect the loads to
support the interval demand and aggregation? >
3. What is the agreed time base for
demand data? >
>
WIP: This discussion commenced on last Thursday's meeting. We will
defer this question until this Thursday's meeting. Rich Morgan from the
Meters team will be on Thursday's call >
>
4. How are the load priorities
defined ? Is this only a Loads issue? >
5. Does the EM expect the Load to
warn the EM when a load is returning from a curtailment state? >
6. Does the EM handle the restore
’rebound’ effects? >
7. How will be the pricing
information be made available to the loads? >
8. What weather data is available
from the EM? >
9. Is the EM interested in Load Ramp
up/Ramp down time? How should the load present this information? >
10. If a load is direct controlled,
will the EM send a ‘restore’ to the load if communication is
lost? Will the EM filter the direct load control request? >
>
Not yet discussed >
>
>
The action items and assignments from the last call are as follows: >
>
>
1. Loads Team: The Load Team
should change 'ShedRating' to 'ShedLevels' in the Load Curtailment object to be
clearer on its intent. >
>
2. Loads Team: The Load Team
should advertise to the higher nodes what of the 3 shedding modes it supports
(i.e. absolute shed, relative shed and/or shed level) >
>
3. Loads Team: The Load Team
should consider splitting the LoadCurtailment object into two separate
associations a) attributes that have to do with shed control and 2) attributes
that are specific shedding attributes of the load itself. >
>
4. Loads Team: The Load
Team should do an attribute by attribute check of the LCO and the
CurtailableLoad to verify common operation and to describe to everyone the
relationship. >
>
5. SPC201: The entire SPC201 needs to
be consistent on defining whether an attribute is read-only or
read-write. Currently this is inconsistent in the overall model >
>
6. Jerry: We should develop the list
of EM use cases within the SPC201 model to help see if the EM is malleable
enough in its current breakout. >
>
7. Jerry: We should develop a list of
use cases to test if the overall SPC201 model is malleable to meet the needs. >
>
8. Jerry: We should contact Rich
Morgan and ask him to attend the next meeting to clarify the need and use of
the Demand Interval within the model. >
>
DONE: Rich will join in the Thursday meeting >
>
9. Jerry: Jerry will review the
list of 10 EM/Load items he discussed in >
>
DONE: Updated list above >
>
10. Jerry: Jerry will host the next
two EM/Load meetings; (Same bat-time, same bat-channel). >
>
DONE >
>
>
>
======================================================================================================== >
> Topic: SPC201 Energy Manager/Loads Joint Meeting >
> Time: 10:30 am, Pacific Standard Time ( >
> Meeting Number: 204 730 869 >
> Meeting Password: spc201 >
> >
> >
> ------------------------------------------------------- >
> To join the online meeting (Now from mobile devices!) >
> ------------------------------------------------------- >
> 1. Go to
https://cisco.webex.com/ciscosales/j.php?ED=159636682&UID=1496629277&PW=NMzgwMjMzMWE1&RT=MiM0 >
> 2. Enter your name and email address. >
> 3. Enter the meeting password: spc201 >
> 4. Click "Join Now". >
> >
> ------------------------------------------------------- >
> To join the teleconference only >
> ------------------------------------------------------- >
> 1. Dial into Cisco WebEx (view all Global Access Numbers at >
> http://cisco.com/en/US/about/doing_business/conferencing/index.html >
> 2. Follow the prompts to enter the Meeting Number (listed above) or Access
Code followed by the # sign. >
> >
> >
> >
> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 >
> >
> ------------------------------------------------------- >
> For assistance >
> ------------------------------------------------------- >
> contact: >
> achandra@cisco.com<mailto:achandra@cisco.com> >
> 1-408-526 6198 >
> >
>
>
>
<image001.jpg> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]