Re: [energyinterop] Positions and CTS

Yes; the trust requirements must support seeing all transactions
      that flow. The LMA is simplest, but the TEUA is probably the right
      place as it already must see and act on transactions.

    
BTW in our open source implementation a Java Collection Class is
      a lot simpler than integrating a database, which is why if one
      were to evolve that code I'd consider that directions.

    
But the initial implementation was for a simulation testbed, so
      being able to track positions from an "outside-the-simulation
      observer" seemed valuable.

    
Thanks!

    
bill

    

    
On 4/22/21 10:51 AM, Holmberg, David G.
      (Fed) wrote:

    

    
      
      
      
      

        
Thanks Bill. The thought that comes to mind
          is that the position manager must be hosted by a common
          trusted party, like the market provider.

        
 

        

          

            
From:
              
              <>
              On Behalf Of wtcox

              Sent: Thursday, April 22, 2021 10:37 AM

              To: EITC <>

              Subject: [energyinterop] 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: 
                 

          
Web: 
                http://www.CoxSoftwareArchitects.com 

          
+1 862 485 3696 mobile

          
 

        

      

    
    
-- 

      
      
      
      
      
      
      
William Cox 

      
Email:  

      
Web: http://www.CoxSoftwareArchitects.com 

      
+1 862 485 3696 mobile