Good discussion on today’s call about the list of services required and transactional energy.
I propose that we add an AggregatorOperator “notification” service (we can fold it into one of the other services if required). This service would be used to communicate routine real-time/scheduled prices or allowable load levels. I’m influenced here
by the Texas model.
It is easy to imagine that an Aggregator might have both event-driven & continuous programs in place. Is this even the case in Texas (are there continuous price streaming and emergency events that may overlap)?
This service could be used to communicate ws-calendar & emix tuples and/or one of the simpler structures from OpenADR?
I believe separating the “event” services from “notification” services will better allow software developers to separate messages that require workflow from messages that simply update state values.
So specifically, I recommend:
AggregatorOperator, sendNotification
ParticipantOperator, getNotification
ParticipantOperator, listNotifications
Regards,
Dave
p.s. This email assumes dynamic pricing is in scope. Please start another thread if you wish to discuss if this pricing is in scope. Thanks!
David Wilson
Enterprise Solutions Portfolio Manager
Trane Commercial Systems
Ingersoll Rand
Office: +1.651.407.4168
Mobile: +1.612.741.2759
________________________________
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 attachments.