Dynamic Price & Contract Notification

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

Email: 

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 attachments.