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: [email protected]Â
Web: http://www.CoxSoftwareArchitects.comÂ
+1 862 485 3696 mobile
--
William CoxÂ
Email: [email protected]Â
Web: http://www.CoxSoftwareArchitects.comÂ
+1 862 485 3696 mobile
