Re: Positions and CTS

[wtcox <wtcox@coxsoftwarearchitects.com>]

One further note:

Managing a specific party's position can be done by the party itself (algebraic add of buy/sell quantity) or anyone else that can see the stream of that party's EiTransactions.

In the EML-CTS implementation, the logical points are

(1) The user or its agent which receives all EiTransactions relevant to itself - and can create a (logical) database table for only THAT party's position

(2) The LMA which sees all EiTransactions - and can create a database table for ALL parties

Fortunately, the database in (2) is partitioned into the union of all databases (1), so either approach works.

One conclusion is that a local database or data structure can be used for databases (1) so perhaps MySQL need not be used. For (2), a relational database is simpler, and simplifies a broader range in the API for retrieving position - the API calls for a time period, and in that future version would return the total position for all intervals contained in the time period in the request. (Feel free to ignore this paragraph).

Thanks!

bill

On 4/22/21 10:37 AM, wtcox wrote:

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

Thanks!

bill

--

William CoxÂ

Email: wtcox@CoxSoftwareArchitects.comÂ

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

+1 862 485 3696 mobile

--

William CoxÂ

Email: wtcox@CoxSoftwareArchitects.comÂ

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

+1 862 485 3696 mobile