[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [TypeDisc] EventState
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]