[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: problem of sending signals to participants form multiple sources
|
Ed K. In looking at your response, I think this
looks reasonable. I rearranged your text a bit to come up the the
paragraph below. If the group agrees, this paragraph could be placed in
the vicinity of figure 6 line 672 to clarify this issue. Ed C. – assuming you agree with the
gist of this, you probably want to look at the last two sentences in particular
and see if they need edits to correctly describe the contractual element. "As illustrated in Figure 6, a
participant receives signals from an ERM entity above it in a hierarchical
structure in the general case. Note however that an implementer could
identify and configure scenarios where a participant may receive signals from
multiple sources. This specification asserts that how conflicts between
signals get resolved is beyond the scope of this specification. If this
is a potential conflict, it will need to be resolved either by the receiver of
the signals or at the level of the sending entity. To enable resolution
of potential conflicts, communication packets include an attribute identifying
the source of the signals. Coordination between the different
entities sending the signals is out of the scope of this specification. Consider
that the receiver / participant can also resolve any conflicts in it's implementation
of the actions and the response. As an additional note, resolution of
this potential issue may actually be via a contractual basis. Contracts
with either Aggregators or Utilities may preclude this situation from occurring
or becoming an issue." Gale R.
Horst Electric
Power Research Institute (EPRI) From: Edward Koch
[mailto:ed@akuacom.com] Gale, I’m going to kill two birds with one
stone and also cc my response to the EI list. Bear in mind that my response below is within
the context of what we discussed during the 1.0 drafting of the spec, although
I suspect the EI will come to similar conclusions. Just like as shown in figure 6, we did in
fact identify scenarios where someone may receive signals from multiple sources.
The conclusion we came to at the time was that how any conflicts between
signals get resolved was beyond the scope of our specification. What this
means is that if this is a potential conflict exists then it will need to be
resolved either by the receiver of the signals or the senders. The
implications to the specification we wrote were that the most we were willing
to do to help resolve conflicts was to add an attribute identifying the source
of the signals. Anything beyond that would require some sort of
coordination between the different entities sending the signals and we
didn’t want to go down that road. Of course the receiver can also
resolve any conflict himself, and while they might feed back some information
concerning how they resolved the conflict it probably does not affect the
downstream DR signal itself. Note that I think that much of what is
done today to help resolve these issues is on a contractual basis.
Customers often sign contracts with either Aggregators or Utilities which preclude
this situation from occurring. Some aspect of this might be reflected in
the transactional energy model. Perhaps Ed C could elaborate more on this. Thanks, -ed koch From: Horst, Gale
[mailto:ghorst@epri.com] Ed and Rish: Your action items from the energyinteropTC call today:
What are the architectural implications? For exampe
will each end node be linked to receive from one entity above it in the
hierarchy? Or is it acceptable to be able to receive from multiple
senders (REC or entity above) concurrently. We may want to reference the diagram in the proposed
solution to this item. For example Figure 6 in “energyinterop-1.0-spec-wd-12.pdf” line
672 would seem to have an implication. I can see where signals ORIGINATE
from several sources. But will the “Entity A” (REC) be responsible
to sort / prioritize and send the appropriate signal on? Perhaps other
developments or OpenADR has hashed their way through this issue and can bring
some clarity. We may want to check that we have described the background
text in the document to be sure it relays the proper understanding. THANKS, Gale Gale R. Horst Electric Power Research
Institute (EPRI)
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]