DER Orchestration & Demand Response Platform
Primary service
Real-time Monitoring & Anomaly Detection
Secondary service
Data Modeling & Lineage
Proposed Cadvel capability — not a client case study.
Target client and segment
Utilities, electricity retailers and flexibility aggregators
Challenge
A demand response event is only as reliable as the data behind it. Operators need to know which assets are enrolled, available and responding before they commit flexibility.
Key capabilities
- A traceable relationship between customers, meters, devices and program eligibility.
- An operational view of requested actions, acknowledgements and measured response.
- Evidence for program assessment, with opt-outs and unavailable assets visible.
Business Challenge
Enrollment does not prove availability
Customer consent, device connectivity and program eligibility change independently. A stale enrollment record can overstate the capacity available for an event.
Commands and physical response are different
An accepted command does not confirm a load reduction. Operators need timestamps and telemetry that connect each instruction to the device response.
Event results are hard to explain
Late readings, opt-outs and changing baselines can distort performance reports unless calculation versions and exclusions are retained.
Program rules vary
Asset eligibility, event windows and reporting requirements differ by program. Hard-coded mappings make expansion expensive and difficult to audit.
Architecture and Tech Stack
Device and retail APIs → validated event stream → customer–meter–device model → event and telemetry store → operations dashboard and program reports. Keep command state in a transactional service; reconcile it with observations in the analytical layer.
Technology options
Kafka for replayable events; ClickHouse for time-series investigation; dbt for governed participation and baseline models. AWS or Azure can host the platform. Select components after latency, retention and access requirements are agreed.
Delivery boundary
Cadvel supplies the data, reconciliation and monitoring layer and integrates with the client’s authorized orchestration system. Dispatch permissions, opt-outs and rollback rules remain explicit controls.
Implementation and Solution
Proposed implementation stages
Define event evidence
Agree eligibility, asset identifiers, consent rules and a baseline methodology with program owners.
Connect and reconcile
Integrate one device class; test duplicate messages, late arrivals and meter-to-device mapping.
Validate event monitoring
Link requests, acknowledgements and readings; run shadow events and review exceptions with operators.
Roll out by program
Pilot approved dispatch integrations, compare event evidence and hand over monitoring and recovery procedures.
What this enables
Measurable success criteria — to be agreed and validated with the client; not achieved results.
Telemetry freshness
p95 seconds from device observation to operator availability, per device class.
Event evidence coverage
Events with linked request, acknowledgement and valid readings ÷ eligible dispatched events.
Verified load response
Event-period kW difference against the agreed baseline, with exclusions and uncertainty reported.
Enrollment integrity
Active enrolled devices with valid customer, meter and consent links ÷ active enrolled devices.
KPI targets and acceptance tolerances are set with the client during discovery; no achieved outcomes or ROI are asserted.
Source inspiration / reference
Source-derived facts
Codibly describes an APG&E platform covering enrollment, demand response scheduling and command monitoring, using Enode for initial thermostat connectivity. Additional asset classes and grid protocols are described as an expansion path; this is not evidence that every future integration is live.
Reference context only. Proposed Cadvel design and KPIs are independent of the source delivery.
