[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (ENERGYINTEROP-614) EIReports section is still very unclear
[ http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28579#action_28579 ]
Toby Considine commented on ENERGYINTEROP-614:
----------------------------------------------
Bringing over from where miss-posted on 621
If we take Ed's example:
One can certainly define a Historian whose purpose is to measure Real Power at an Emix Interface at a granularity of 15 minute intervals.
One can define a reportBack Duration for that historian of every 15 minutes.
If the [VTN] is unreachable, the application could keep or toss the reading. It is a conformance spec to declare the application should save un-delivered reading for eventual delivery instead of discarding. I think specifying that behavior is out of scope. I am open to adding a flag.
So: That says we can define the report. When we define a report and create a schedule, we have a request and therefore a reportRequestID. That could be standardized. Let's say its name is OpenADR20-favorite.
We can specify that a VEN must deliver OpenADR20-favorite and put it in the market context. It can be Requested, so folks can find out what it is. It can be a pre-loaded into every Alliance-certified system so it is always known.
That is a reasonable white-paper topic. Is there anything else we need?
[ Show » ] Toby Considine added a comment - 04/Nov/11 03:14 PM If we take Ed's example: One can certainly define a Historian whose purpose is to measure Real Power at an Emix Interface at a granularity of 15 minute intervals. One can define a reportBack Duration for that historian of every 15 minutes. If the [VTN] is unreachable, the application could keep or toss the reading. It is a conformance spec to declare the application should save un-delivered reading for eventual delivery instead of discarding. I think specifying that behavior is out of scope. I am open to adding a flag. So: That says we can define the report. When we define a report and create a schedule, we have a request and therefore a reportRequestID. That could be standardized. Let's say its name is OpenADR20-favorite. We can specify that a VEN must deliver OpenADR20-favorite and put it in the market context. It can be Requested, so folks can find out what it is. It can be a pre-loaded into every Alliance-certified system so it is always known. That is a reasonable white-paper topic. Is there anything else we need?
> EIReports section is still very unclear
> ---------------------------------------
>
> Key: ENERGYINTEROP-614
> URL: http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-614
> Project: OASIS Energy Interoperation TC
> Issue Type: Improvement
> Affects Versions: wd33
> Reporter: Ed Koch
> Assignee: Toby Considine
> Fix For: wd34
>
>
> I honestly still do not understand how to use the EIReports to do some of the very simple feedback use cases that I want to support. The sections seems to be a muddled collection of services and it is not clear what services are really required and how you would use them. There seem to be a bunch of bureaucratic services for creating "historians" and "report specifications", but how they are tied together and used is very unclear. If I can't understand this then I honestly don't know how someone coming into this cold has a hope of understanding it.
> For example on line 1707 it says "EiReport is prepared by a Party upon request and supplied to the requesting party. It may also be defined in the expectations of the Market Context." Does this mean that the only way a report can be generated is by request? The simple use cases deployed today do not require any registrations or report specification services or any of this overhead. The report specifications and what not are created by convention and while some systems may want to employ all these extra meta data services they should not be required.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]