Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC TS 62746-3:2015 – Systems Interface Between Customer Energy Management and Power Management – Architecture
💡 Key Insight: This architecture enables the “energy internet” — treating customer energy resources (solar, storage, EVs, smart appliances) as dispatchable grid assets that can be aggregated and managed through standardized internet-based protocols, just as servers are managed on the internet today.
1. Scope and Architectural Foundation
IEC TS 62746-3 defines an architecture for systems interface between the Customer Energy Management System (CEM) and the Power Management System (PMS), enabling management of customer energy resources including distributed energy resources (DER). These resources may include load, generation, and storage — individually or as aggregated virtual resources. The architecture leverages the Internet for communications between grid operators, market operators, distribution system operators, electricity suppliers, aggregators, service providers, and energy resources.
The standard is built on a role-based model derived from OpenADR 2.0, where actors assume technical roles such as Virtual Top Node (VTN) — typically the utility or grid operator — and Virtual End Node (VEN) — the customer-side system or DER Management System. This architecture supports multiple communication domains: a VTN in one domain may simultaneously act as a VEN in another, enabling hierarchical aggregation of energy resources.
✅ Architectural Goal: Create a scalable, interoperable framework where millions of distributed energy resources can participate in grid services — demand response, frequency regulation, voltage support — through standardized interfaces that abstract the heterogeneity of individual devices.
2. Key Actors and Their Roles
2.1 Virtual Top Node (VTN)
The VTN is the server/manager role that sends signals, receives responses, and manages resources within its communication domain. A VTN is responsible for sending DR signals or set points, receiving event responses and reports from VENs, and managing opt-in/opt-out schedules. The VTN role can be taken by various actors: a utility, an independent system operator (ISO), a load-serving entity, or an aggregator.
2.2 Virtual End Node (VEN)
The VEN is the client/participant role that receives signals and manages resources at the customer premises. A VEN may be responsible for one or more energy resources (physical or aggregated). The VEN receives and processes DR events, reports resource status and measurements, and implements local control strategies to respond to grid signals.
2.3 Customer Energy Manager (CEM)
The CEM is the central managing function used by the customer to manage the flow of information between the grid and connected smart devices at the customer premises. It acts as the customer’s gateway for energy management, interfacing with both the grid side (VTN) and device side (smart appliances, PV inverters, EV chargers, batteries, thermostats).
| Role | Function | Communication Direction |
|---|---|---|
| Virtual Top Node (VTN) | Send signals, manage resources | Downstream to VENs |
| Virtual End Node (VEN) | Receive signals, control resources | Upstream to VTN |
| Customer Energy Manager (CEM) | Central customer-side management | Bidirectional (grid + devices) |
| Smart Grid Connection Point (SGCP) | Logical info access point from grid to premises | Bidirectional |
3. Communication Architecture and Data Model
3.1 Communication Domains
The architecture defines communication domains as logical associations of a VTN with a set of VENs supported by underlying communication infrastructure. Each domain provides for authentication of VENs and secure communication services. The architecture supports domain hierarchies — a VEN in one domain can act as a VTN in another, enabling scalable aggregation from individual devices through facility-level systems to utility-level systems.
3.2 Payload and Message Structure
The standard specifies a payload structure including: event identification and descriptors, event status (active, cancelled, completed), intervals with start times and durations, target values and tolerances, and reporting capabilities. Messages follow a request/response pattern that can be initiated by either VTN or VEN, supporting both grid-requested (top-down) and customer-initiated (bottom-up) interactions.
| Message Type | Initiator | Purpose |
|---|---|---|
| Event Request/Response | VTN | Grid sends DR event to VENs |
| Query Request/Response | Either | Status inquiry about resources |
| Report | VEN | Resource status, measurements, compliance |
| Registration | VEN | VEN registers with VTN, declares capabilities |
| Opt Schedule | VEN | Customer indicates availability preferences |
3.3 Data Model Foundation
The data model is based on IEC 61968-9 (distribution management interfaces), extending it with the specific requirements for customer energy management interactions. This ensures consistency with the broader CIM (Common Information Model) framework used across the IEC 61970/61968 series for utility enterprise application integration.
⚠️ Engineering Note: The architecture explicitly supports both pull and push communication models. For grid stability applications requiring fast response (≤ 4 seconds for primary frequency response), the architecture supports direct control signals. For economic DR programs, a publish/subscribe model with longer timelines is more appropriate.
4. Engineering Design Insights
💡 Practical Takeaways for Engineers:
- Scalability through hierarchy: The VTN/VEN hierarchical model allows a single utility VTN to interface with thousands of aggregation VENs, each of which acts as a VTN for hundreds of individual customer VENs. This architecture scales to millions of endpoints while maintaining manageability.
- Cyber security by design: Each communication domain provides authentication of VENs and secure communication services. The architecture supports TLS, certificate-based authentication, and signed payloads. Security is not an add-on — it is integral to the domain concept.
- Device abstraction: The VEN abstracts the heterogeneity of behind-the-meter devices. A VEN controlling a 10 MW battery storage system uses the same interface as a VEN controlling a 3 kW residential solar system — the difference is in capability reporting, not protocol.
- Interoperability with existing standards: The architecture builds on IEC 61968 for distribution management and aligns with OpenADR 2.0 profiles. This means existing OpenADR implementations can map directly to the IEC 62746-3 architectural framework.
- Future-proofing: The architecture is technology-agnostic regarding underlying communication protocols — it works over any IP-based network (Ethernet, Wi-Fi, cellular, satellite). This allows deployment in diverse geographic and infrastructure contexts.
5. Frequently Asked Questions
Q1: How does this architecture support different demand response program types?
The architecture supports all major DR program types through flexible event parameters: price-based DR (via target values representing price signals), incentive-based DR (via event notifications with participation payments), and direct load control (via set point signals to specific resources). The reporting mechanism allows utilities to verify compliance for settlement purposes.
Q2: Can a single customer premises have multiple VENs?
Yes. A large commercial or industrial customer may have separate VENs for different resource types (e.g., one for HVAC, one for process load, one for on-site generation). Each VEN would have its own communication domain relationship with the relevant VTN, and the CEM coordinates among them to ensure overall energy objectives are met.
Q3: What is the Smart Grid Connection Point (SGCP)?
The SGCP is the logical information access point from the grid to the customer premises. It is NOT the electrical connection point (the meter) — it is a logical interface through which information flows. The SGCP enables separation of the physical electricity connection from the information connection, allowing customers to choose different energy service providers independent of their physical utility connection.
Q4: How does this architecture handle islanding or microgrid operation?
While the primary focus is on grid-connected operation, the architecture can support islanded/microgrid operation. The VEN/CEM can be configured to manage local resources autonomously when grid communication is lost, using the same underlying data models and control logic. The VTN/CEM interface supports scheduled reconnection coordination when grid service is restored.
