[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [smartgrid-interest] Is there a difference? (Time and Schedule)
|
All good points gentlemen. With regard to the CIM, I can tell you that as we (in IEC TC57 WG14)
developed 61968-9 Ed. 1, we planned to leverage the extended capabilities of
ISO 8601. As you may know it not only contains the simple W3C timestamp, but
the ability to build from that begin times, end times, begin+timespan,
timespan+end, recurring times, and more. So the element of type string labeled as
the timestamp was to be left to the implementer to choose what they needed out
of the ISO 8601 arsenal. We received quite a bit of pushback from developers
who don’t want to build support for all of 8601. We also found a need to
harmonize with WG13 and others who have gotten by fairly well with the start/end
construct. There is a similar story with MultiSpeak. Our plans for the second edition of 61968-9 are to use the
start/end construct as you are promoting below. Toby asked originally for some perspectives as to the need. We’ve
found with the Part 9 development a few usecases that may interest you. 1.) At the
messaging level the general thought is that “do not start before”
and “do not continue after (or end)” controls are necessary.
For example, if one system were to make a request for exhaustive outage data for
all of the meters on a given circuit, the user might want to ask for the
process to start now, but end in 15 minutes from now. The reason being
that the user would any answers provided after 15 minutes would be irrelevant
to their current need. 2.) At
the data request level, it is useful to ask for specific dates and times as
well as all of readings that fall within specific dates and times. For
example, a request for meter readings between a CIS and MDM might say “give
me all of the readings from this particular meter starting on a given dateTime
and ending on another dateTime.” CIS systems tend to work with cutoff
dates with respect to a target reading date. Many utilities allow a reading to
occur 1-2 days before a target date and 1-2 days after a date. They are
thinking in terms of specific dates on a calendar +/- X days. 3.) Interval
data is particularly tricky. As we move to develop 61968-9 Ed. 2, we are
leaning towards the idea of allowing interval data timestamps to populate the “start”
and/or “end” fields as appropriate. Not only does the interval data
usually get presented in a block which covers a span of time (start/end), but
the individual intervals themselves are captured over a span of time. This span
of time is usually described by the ReadingTypeId (e.g. 60-minute Incremental
IntervalData Net SecondaryMetered-Energy (kWh)), so it would be sufficient to
just populate the “start” or “end” tag with timestamps as
appropriate (not both) to indicate without ambiguity that the interval started
or stopped at the particular moment in time. This practice among some systems
is to just put a timestamp with the data and rely on external documentation to
tell the user if it is the start or end of the interval. We would like to discourage
this practice. 4.) Effectivity
dates need to be considered for nearly everything. If a “start”
field is populated, and the date is in the past, and the corresponding “end”
field is not populated, that would indicate that the configuration is currently
effective. An end date, if populated, could be in the past or into the future.
Likewise, a future configuration could be presented by populating the “start”
field with a future date and time. Anyway, good discussion. You asked for some feedback. I’ve
copied Gary McNaughton, convener of the MultiSpeak standard, and Scott Neumann,
part 9 team lead. David Haynes From: Edward Koch
[mailto:ed@akuacom.com] While I think Ed C has a very good point concerning the CIM, I
agree with David’s point and tend to prefer specifications that reduce
the ability to create illegal instances of data. The fewer illegal
instances of data a consumer has to deal with the simpler and more robust the
whole system will be. It is worth pointing out that a lot of the security holes
in today’s systems were exposed as flaws in a protocol stack’s
ability to handle malformed or illegal data parameters in messages. This type
of vulnerability becomes magnified in lower end systems where engineers are
cutting corners in their resource constrained devices. -ed koch From: Ed Cazalet
[mailto:ed@cazalet.com] In CIM and OpenSG I believe they use start/end. I think
the reason is that even though meter reads may be scheduled every 15 min or
prices published every 5 min, occasionally the read or the published time does
not happen on a regular duration. While a start/duration would work with
a variable duration, I think we should be consistent with their start/end practice. Edward G. Cazalet, Ph.D. 101 First Street, Suite 552 Los Altos, CA 94022 650-949-5274 cell: 408-621-2772 From: David RR Webber (XML)
[mailto:david@drrw.info] Toby, Re-casting this: 1) Start / Duration 2) Start / End The only snag I see with 2) is this: 2) 14:00 / 1:00 and I assume for Duration is has to be fully qualified - e.g.
01:00:00 and not just 1 Thanks, DW p.s. They are using military time, right?!
---------------------------------------------------------------------
To unsubscribe, e-mail: smartgrid-interest-unsubscribe@lists.oasis-open.org For
additional commands, e-mail: smartgrid-interest-help@lists.oasis-open.org |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]