5.8 KiB
5.8 KiB
Downward pressure on energy prices
| Function Block | Deliverable / Dependency | Staff | Min Months | Max Months |
|---|---|---|---|---|
| Registration & Discovery | CSIPAUS 1.3 Battery Extensions | 1 | 0 | |
| Registration & Discovery | Droplet work to integrate with Battery | 2 | 0 | |
| Assignment & Portability |
Integration with customer consent to add to population PUT /populations/test { customerConsent } |
|||
| Assignment & Portability |
ONI Data work for population | |||
| Population Management |
ONI Data work for population mgmt | |||
| Population Management |
Delegate populations to FSAs (or whatever) | |||
| Status & Telemetry | Aggregate population telemetry being delivered to retailer | |||
| Status & Telemetry | Device level telemetry available via query / pushed | |||
| Contraints Forecasting | the weatherman endpoint in ONI for making available forecasts |
|||
| Contraints Forecasting | store DOEs / forecasts | |||
| Maintenance | Notifications of device issues | |||
| Maintenance | Assurances | |||
| Retailer Controls | Portfolio mgmt (could be gnarly because time based: eg slices of community battery) | |||
| Control Resolution | ONI Primacy | |||
| Control Resolution | Constraint engine reference (3 ausgrid algos) | 0 |
Registration & Discovery
Key Elements
- CER/DER asset is registered for access via interface interface presumable == ONI
- Assets can be discovered and participate in functions below
Deliverable
- Can already do this with DER via
ControlPlane- Convert that to ONI?
- need to prove it with something new?
- battery?
- 2030p5 stuff for batteries
- Synergy defining CSIP aus 1.3 ext for batteries
Assignment and Portability
Key Elements
- Asset assigned to retailer (by consumer choice)
- Consumer’s assets grouped together
- Assets ported between retailers (on consumer’s election)
Deliverable
-
mechanism for consumer to choose to be assigned / listed
- retailer integration
- NRN
- retailer integration
-
Assume ONI reference impl server w/ big postgres managing groups
Population Management
Key Elements
- Retailer organises assigned assets into one or more groups; reporting/control will be managed by groups
Deliverable
- ONI -> FSAs ?
- Assume ONI reference impl server w/ big postgres managing groups
Status & Telemetry
Key Elements
- DNSPs periodically report status and telemetry by population
Deliverable
ONI to implement Langdale(TM) data models of aggregate telemetry data IEC CIM?
population telemetry -> UTSRV -> ONI -> retailer also needs individual device info - push / pull ? - get telemetry by lfdi /id
Constraint Forecasts
Key Elements
- DNSPs issue DOE forecasts for upcoming period
Deliverable
the weatherman curtailment events predicted to be activated in the next day publish predicted DOEs via schedule distinct from DOE schedule
Maintenance
Key Elements
- DNSPs report on a Retailer’s assets in errored states
Deliverable
- assurance -> ONI
- resolutions (implies existence of issue / tickets)
Retailer Controls
Key Elements
- Individual consumer group control
- group of devices connected to a site
- Retailers apply controls by population
Deliverable
- utility server does it
- hook utility sever up to UoW Battery
- populations via FSA?
- Customer Portfolio
- Solar on roof
- Battery in shed
- Community Battery that they get from 10-11am daily
- Community Battery that they get 10kwhr / day
Control Resolution
Key Elements
- DNSPs check DOE bounds as controls are exercised
- Determine how controls are dispatched across populations
Deliverable
- Resolution of DOEs originating from retailer against restrictions set by DNSP
roughly == primacy?
retailler sends 20kw xplim dnsp for same site has specified 10kw xplim
report on violation
ausgrid 3 algorithms for application
Retailer forecasts (stretch)
Key Elements
DNSPs check DOE bounds as controls are exercisedDetermine how controls are dispatched across populations
Deliverable
Pricing signals
Key Elements
Pricing signals Retailer → ONI → CSIP-AUS → CER ClientPricing signals from DNSP → ONI → Retailer