This raises some more points about scheduled events in the SG (I may
be wandering way off point here....again...;-).
For a lot of things that happen on a schedule, the schudule can be
pretty soft, and in fact that will be desirable for overall system
performance. For routine periodic status of endpoints as an example,
you want it to happen periodically at some specific interval a but you
don't really care if it is + or - quite a bit, and in fact if you have
10 million end points you definitely don't want to have all of them
reporting in lock step at exactly the same time. Introduction of some
randomness in the schedule is a big help to network performance.
In a dangerous move, I'll extend your analogy. If I'm scheduling a
meeting with the CFO of my company, I know (via a priori knowledge)
that she has a 2 minute tolerance for start time - after that she
leaves. So that start time has to be met within +2 minutes and -0
minutes (never, ever start before she gets there!). If you miss that
tolerance, you have a schedule failure (and a pissed off CFO, which we
strive to avoid). On the other hand, when scheduling the presenters in
the meeting, I know time slots with offsets so only one presenter is up
at a time, slots are allocated for a fixed time, but with an understood
"sloppiness" that if one finishes early, the next will start early, and
likewise if one goes long. In other words, the schedule is defined
with specific times, but execution of the schedule is allowed to be
adapted to the actual conditions.
So when talking about schedules we need also to consider things like:
- Tolerance ("hardness" or "looseness" of the schedule)
- duty cycle (how much of available resources should be spent)
- what happens if it can't be met (resources not available)
Does that help?
-Ben
043f01cb08a8$8f920330$aeb60990$@gmail.com"
type="cite">
Too
clever by half. For this
conversation, assume UTC, leaving out DST and related issues. I’m
looking for whether there should be a deeper meaning when applied to
services. For people, if a meeting starts at 12:00 and goes for an
hour, one could argue that since they always start at 12:05, this means
that it is scheduled until 1:05….
For
services, I am interested in what is the required / expected state of
the service at 3:01.
Let’s say
I schedule a room for 78 degrees between 2-3.
Let’s say
I schedule the same room for 72 degrees between 3-4.
Let’s say
that I know it takes 10 minutes to go between the temperatures.
If the
first schedule is in response to DR for Energy, then I am committed to
not setting the thermostat *until* 3:00
If the
second schedule is in response to CEO arriving for a meeting, then I am
committed to getting the room temperature down *by* 3:00
There may
be real differences at the edges point for non-instantaneous services
tc
"If
something is not worth doing, it`s not worth doing well" - Peter Drucker
The
only snag I see with 2) is this:
and
I assume for Duration is has to be fully qualified - e.g. 01:00:00 and
not just 1
p.s.
They are using military time, right?!
--------
Original Message --------
Subject: [smartgrid-interest] Is there a difference? (Time and
Schedule)
From: "Toby Considine" <Toby.Considine@gmail.com>
Date: Thu, June 10, 2010 10:07 am
To: <smartgrid-interest@lists.oasis-open.org>
I am
thinking about information and conformance in schedules, and I want to
ask for a broader perspective than in the WS-Calendar committee. Note I
am *not asking* for contributions to the committee, I am asking
for perspectives on what the standard should support. Note that there
is always a tension between “support everything” and “interoperation”
The
WS-Calendar current draft is out for public comment. It is in many ways
a WS instantiation of iCalendar and related IETF specifications. At its
core is a series of time slices based upon the well-known vtodo object.
Each slice may reference a usage a price, or any other information
artifact. Assume it is a series or energy prices or a series of DR
requests…..
As I
meditate on this object I arrive at the following question:
What’s the
difference in *actions*, and in *performance* between
A)
Do
X beginning at 2:00 for an hour duration
B)
Do
X beginning at 2:00 for and ending at 3:00
C)
Do
X for an hour ending at 3:00
All are
possible using the VTODO data structure.
One (C) is
not allowed if I understand correctly
Within any
interaction, it would be simpler, cleaner to allow only (A) or (B)
Do we need
to allow both?
Does B have
a finite stop and A does not?
Why would
we support both?
“It is
difficult to get a man to understand something, when his salary depends
upon his not understanding it” -- Upton Sinclair.
OASIS Technical Advisory Board
TC Chair: oBIX & WS-Calendar
TC Editor: EMIX, EnergyInterop
U.S.
National Inst. of Standards and Tech. Smart Grid Architecture Committee
|
|
|
|