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

    
Thanks!

    
bill

    

    
-- 

      
      
      
      
      
      
      
William CoxÂ

      
Email: [email protected]Â

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

      
+1 862 485 3696 mobile