OpenADR 2.0b Protocol

The protocol uses a push-based, event-driven model where a Virtual Top Node (VTN) server issues signals to Virtual End Nodes (VENs). Each event contains:

• Event Status: Active, cancelled, or completed
• Operation Mode: Normal, moderate, high, or special
• Signal Payload: Absolute load reduction (kW), relative reduction (%), or price signal
• Ramp-up/Ramp-down durations for smooth transitions This structure allows for precise, time-bound load modification without continuous polling, reducing network overhead.

VENs can programmatically accept or decline participation in events using opt schedules. Key mechanisms include:

• Opt-In: VEN commits to a specific event or time block
• Opt-Out: VEN declares unavailability, often due to occupant comfort constraints or critical processes
• Availability Windows: Pre-negotiated timeframes where the resource is dispatchable This bidirectional negotiation ensures demand response does not disrupt mission-critical operations while maximizing grid flexibility.

OpenADR 2.0b mandates standardized reporting mechanisms for measurement and verification. VENs must support:

• Historical Reports: Past interval data for baseline calculation
• Telemetry Reports: Near-real-time power readings during events
• Metadata Reports: Device capabilities, accuracy class, and sampling rates Reports use XML payloads conforming to the Energy Interoperation (EI) schema, ensuring interoperability across vendor systems for settlement and performance auditing.

The profile enforces TLS 1.2 or higher with mutual authentication for all communications. Security layers include:

• X.509v3 Certificates: Both VTN and VEN must present valid certificates
• XML Signature: Critical payload elements are digitally signed to prevent tampering
• HMAC-based Authentication: Ensures message integrity and non-repudiation This cryptographic framework protects against spoofing, replay attacks, and unauthorized load control commands in critical infrastructure environments.

Unlike OpenADR 2.0a's full push model, Profile b specifies a polling-based HTTP pull architecture for VENs behind firewalls or NATs. Characteristics:

• VEN initiates periodic HTTP GET requests to the VTN
• VTN responds with queued events and signals
• Polling frequency is configurable, typically 10-60 seconds
• Eliminates the need for inbound firewall rules at customer sites This design simplifies deployment in residential and small commercial environments where network ingress is restricted.

OpenADR 2.0b supports multiple signal types beyond simple load shed:

• Price Signals: Real-time, day-ahead, or tiered tariff information
• Grid Condition Signals: Frequency deviation, reserve margin status
• Load Control Signals: Direct setpoint adjustments for thermostats or EV chargers
• Ancillary Service Signals: Requests for regulation up/down or spinning reserve This multi-signal capability allows a single VEN interface to participate in wholesale markets, retail programs, and emergency reliability events simultaneously.