OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Positions and CTS

In the EML's open source project EML-CTS we have implemented, but not used, a "Position Manager."

A party's position is the algebraic sum of committed sales and purchases for a particular instrument, which is a time interval for a specific product. In EML-CTS the product is implicit, and today is energy, typically in one hour intervals.

A user (building controller, engaged microgrid, external market, etc) determines their energy needs for a specific time period.

If they have a position (net purchases,sales are negative quantities) then the User OR the User Agent (TEUA) MAY net the planned consumption against what's already committed for the party.

So if User 17 determines it needs 23 kWh in the 2pm hour tomorrow, and nhas already bought (committed through Buy side EiTransactions) 20 kWh for that time period, then TEUA shouldn't buy 23...rather, the agent should acquire 3.

Likewise, if User 17 manages its own position, it would issue a buy request for 3.

The original thought was that a User (say a building controller) would compute its total need, ask its TEUA, and the TEUA would net the request against the position for that time period.

After much thought and experimentation, then PositionManager was made available to the User and to the TEUA, so the choice would be explicit in the code. The automatic netting would require a different semantic for the User if automatic offset of position were used.

To avoid complication, the position manager is in EML-CTS code (search for source files with "position" in the title on the dev branch at https://github.com/EnergyMashupLab/eml-cts (e.g. PositionService.java and other files).

Why is this important?

SOMEONE has to keep track of committed purchases/sales so the User doesn't re-purchase or waste what's already committed. The Position Manager does that, but we assume that the User/client applies the knowledge. The position manager encapsulates that knowledge, and can be called from a User.

Our code in eml-cts keeps the position for each time interval, updating (adding) for each EiTransaction on BUY side, and decrementing for each EiTransaction on the SELL side. User code can request position or manage it itself.

The implementation uses the MySQL Community Edition database to retain position information. (Detail: the Spring Boot application eml-cts reinitializes the database on each run, but can be configured to persist the positions).




William CoxÂ

Email: wtcox@CoxSoftwareArchitects.comÂ

Web: http://www.CoxSoftwareArchitects.comÂ

+1 862 485 3696 mobile

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]