Dave,
I’m certainly not against adding more attributes
especially if it is needed to insure that we can send the right type and range
of information. The working assumption was that as some of the data types
such as price were more richly defined that there would naturally be more
attributes added to the data and I always assumed we would make the
representations richer than they currently are. That being said there will always
be a tradeoff between the flexibility vs complexity issue and I would hesitate
to make a blanket statement that we will make the data as self descriptive as
possible. I will definitely have to object if we start straying into
meta-schemas. Every time we make a change of this nature we should ask
ourselves the following questions:
-
What is the effect of adding more attributes or complexity to
the data structures for the lowest end devices that might consume these
messages. BTW – I’d like to avoid a debate about the cost and
power of cpus because that’s not the issue.
-
What is the effect of adding more attributes or complexity to
the data types on the ease of creating simple rules that can be defined by the
end user to translate the information into actionable load control strategies.
One might be tempted to assume that you can deal with complexities with the
appropriate SW tools, but if we aren’t careful then we might find that a
somewhat sophisticated tool with a rich user interface is required.
Again, I’m not married to the current schema in this
regard and I think that we should add whatever attributes we think are
necessary. I just want to do it with the proper considerations.
-ed koch
I think the
EventState type provides a good example of the flexibility/complexity challenge
that I would like to highlight. As you’ll notice from either the
XSD or PNG attached, the lowest level of the SmartClientDREventData provides a
list of decimal values & time offset pairs. The type of theses values
is designated in the string value eventInfoName.
eventInfoName
Documentation
--------------------------------------
This is the
name for the Event Info Type that was given by the Utility when the DR program
was first established. It is analogous to a variable name. By having a
name it allows multiple instances of the same type (i.e. PRICE_ABSOLUTE) to be
sent in the Event Instance.
--------------------------------------
For example:
EventInfoValue:
Value: 3.50
timeOffset: 900
Compare this
approach with a more strongly/structured typed approach:
EventInfoValue:
Price: 3.50
Currency: USD
SecondsOffset: 900
LoadTarget: 250
As a
potential consumer of this information, I want the types of the values to be
defined inside the interface (at least to the level of Price, Load,
Consumption, Reduction vs Absolute) while the business rules can be a priori
defined in the program/contract.
Was the
common program in OpenADR definition the only factor contributing to the
weaker/flatter type approach? What other factors drove this design?
Do you agree
or disagree with the general trend to add more meaning to the elements for the
EnergyInterop specification?
Regards,
Dave
<<EventInfo.xsd>>
<<EventState.png>>
David
Wilson
Enterprise
Solutions Portfolio Manager
Trane
Commercial Systems
Ingersoll
Rand
Office:
+1.651.407.4168
Mobile:
+1.612.741.2759
Email:
davidcwilson@trane.com
www.trane.com
The information contained in this message is privileged and
intended only for the recipients named. If the reader is not a representative
of the intended recipient, any review, dissemination or copying of this message
or the information it contains is prohibited. If you have received this message
in error, please immediately notify the sender, and delete the original message
and attachment..