Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC TS 61968-2:2011: Power System Management โ Distribution Management Interface
💡 Key Insight: IEC TS 61968-2:2011 is the architectural backbone of the 61968 series, defining the Interface Reference Model (IRM) for distribution management system integration. Unlike most power system standards that focus on specific equipment or protocols, this Technical Specification addresses the fundamental challenge of how disparate utility enterprise applications — outage management, asset management, SCADA, GIS, metering — communicate and share data in a coherent, standards-based architecture.
1. The IEC 61968 Series and Distribution Management Context
IEC 61968 is a multi-part standard series for electric power distribution management system interfaces. The series is part of the broader IEC Common Information Model (CIM) standards family (IEC 61970/61968/62325) that provides a comprehensive framework for utility enterprise application integration. IEC TS 61968-2:2011, as Part 2, provides the glossary and interface reference model that underpins all other parts of the series.
Distribution management systems (DMS) have evolved from isolated, function-specific systems into integrated enterprise platforms that must exchange data across multiple organizational boundaries: between control center and field crews, between planning and operations, between distribution and transmission operations, and increasingly between the utility and customer DER (distributed energy resource) systems. The 61968 series addresses these integration challenges by defining standardized interfaces based on the CIM, using service-oriented architecture (SOA) principles with message-level interoperability rather than tightly coupled API designs.
⚠> Integration Challenge: Prior to IEC 61968, a typical medium-sized utility operated 15–25 separate distribution management applications from different vendors, with point-to-point custom integrations between them. Each integration was a unique implementation, resulting in a “spaghetti” integration topology. A utility with 20 applications had up to 190 potential point-to-point interfaces. The IRM approach reduces this to 10–12 standardized bus interfaces, each defined by the standard’s interface profiles.
2. Interface Reference Model Architecture
The IRM defines a set of business functions and the interfaces between them. It organizes distribution management into 11 major functional domains, each with defined information exchange requirements:
- Network Operation (I1): SCADA, substation automation, feeder automation, fault detection and restoration
- Records and Asset Management (I2): GIS-based network inventory, equipment specifications, asset health tracking
- Operational Planning and Optimization (I3): Load forecasting, volt/VAR optimization, network reconfiguration
- Maintenance and Construction (I4): Work management, crew scheduling, field force automation
- Network Extension Planning (I5): Capacity planning, DER interconnection studies
- Customer Support (I6): Outage call handling, customer information system integration
- Meter Reading and Control (I7): AMI/ADMS integration, meter data management
- Supply and Delivery Planning (I8): Energy trading, demand response, load control
- SCADA Interface (I9): Real-time telemetry, control commands, alarm processing
- External Market Operations (I10): Wholesale market participant interfaces
- Regulatory and Compliance (I11): Reporting, audit trail, compliance data exchange
| Interface ID | Functional Domain | Primary Data Exchanged | Typical Protocol |
|---|---|---|---|
| I1 | Network Operation | Status, measurements, alarms, control commands | IEC 61850 / DNP3 |
| I2 | Records and Asset Management | Asset register, network topology, equipment data | CIM XML / SOAP |
| I3 | Operational Planning | Forecasts, optimization schedules, study cases | CIM XML |
| I4 | Maintenance and Construction | Work orders, switching schedules, crew status | CIM XML / REST |
| I5 | Network Extension Planning | Load growth, DER proposals, capacity studies | CIM XML |
| I6 | Customer Support | Outage notifications, service requests, customer data | SOAP / REST |
| I7 | Meter Reading and Control | Interval data, connect/disconnect commands | CIM XML / IEC 62056 |
| I8 | Supply and Delivery Planning | Load profiles, DER schedules, DR events | CIM XML / OpenADR |
| I9 | SCADA Interface | Telemetry, control, time-series data | DNP3 / IEC 60870-5 |
| I10 | External Market Operations | Bids, settlements, market results | CIM XML / EDXL |
| I11 | Regulatory and Compliance | Reports, events, compliance data | CIM XML / PDF |
3. Service-Oriented Architecture and Message Exchange
IEC TS 61968-2 defines a service-oriented architecture (SOA) for DMS integration. Applications communicate through standardized message exchanges rather than through direct API calls or shared databases. The standard defines seven message exchange patterns: Request/Response, Publish/Subscribe, Send/Receive, Query/Response, Create/Update/Delete (CRUD), Event/Action, and Fire/Forget. Each pattern is mapped to specific use cases — for example, Publish/Subscribe is used for real-time alarm distribution, while Request/Response is used for on-demand asset information queries.
The message payloads are encoded using CIM XML schemas that define the structure and semantics of the exchanged data. The standard specifies both the message header (containing source, destination, message ID, timestamp, and correlation information) and the message body (containing the business data). A critical architectural requirement is message idempotency: repeated delivery of the same message must not produce duplicate side effects. This is essential for reliable integration in systems where network failures can cause message retransmission.
✅ Engineering Best Practice: When implementing IEC 61968 interfaces, deploy an Enterprise Service Bus (ESB) as the integration backbone rather than implementing point-to-point messaging between each application. The ESB handles message routing, protocol transformation (e.g., DNP3 to CIM XML), message persistence, and guaranteed delivery. Real-world deployments at major utilities (e.g., EDF, RWE, Tennessee Valley Authority) consistently demonstrate 30–50% lower integration lifecycle costs using ESB-based architectures compared to direct integrations, primarily due to reduced point-to-point interface testing and maintenance overhead.
4. Relationship to IEC 61970 (EMS API) and CIM
IEC TS 61968-2 is closely related to IEC 61970 (Energy Management System Application Program Interface). While 61970 focuses on transmission-level EMS and the CIM base model, 61968 extends the CIM into the distribution domain. The two series share the same core CIM model (IEC 61970-301) but specialize it for their respective domains. The 61968 series adds distribution-specific classes: feeders, distribution substations, meters, customer agreements, and DER installations. The 61970 series adds transmission-specific classes: power transformers, transmission lines, generating units, and market management. Both series use the same UML modeling methodology (IEC 61970-501) and the same XML Schema representation (IEC 61970-552 CIMXML).
🚨 Implementation Warning: A common and costly mistake is implementing IEC 61968 message interfaces without a well-maintained CIM profile. The CIM contains over 1,500 classes and 5,000+ attributes — no single interface needs all of them. IEC 61968 mandates the use of profiles (also called “profiles” or “contextualized views”) that select only the CIM classes and attributes relevant to a specific interface. Implementing interfaces against the full CIM schema leads to massive, slow XML payloads (a common problem early CIM adopters faced, with some messages exceeding 50 MB). A properly profiled interface typically reduces payload size by 80–95% while maintaining semantic interoperability.
5. Frequently Asked Questions
Q1: Is IEC TS 61968-2:2011 a normative standard or a technical specification?
It is a Technical Specification (TS), meaning it is published for provisional application with the goal of gathering experience before potentially becoming a full International Standard. The TS status reflects the evolving nature of distribution management system integration practices. Despite its TS status, it is widely adopted by major DMS vendors as the basis for their integration platforms.
Q2: How does IEC 61968-2 relate to the smart grid concept?
The IRM defined in IEC 61968-2 is one of the foundational architectures for smart grid distribution systems. It enables the “system of systems” integration required for smart grid functions: automated fault location and restoration, DER management, demand response integration, volt/VAR optimization with distributed resources, and advanced metering integration. Many national smart grid roadmaps (IEC Smart Grid Standards Map, NIST Framework) reference IEC 61968 as the core distribution integration standard.
Q3: What is the role of the glossary in IEC TS 61968-2?
Part 2’s glossary is critically important for semantic interoperability. Terms like “outage,” “interruption,” “DER,” “feeder,” and “service point” have different meanings in different utility organizations. The glossary establishes unambiguous definitions used consistently across all 61968 parts, ensuring that an “outage” message from the customer support system (I6) is interpreted identically by the network operation system (I1).
Q4: Can IEC 61968 interfaces use web services (SOAP/REST) directly?
Yes. IEC 61968 interfaces are protocol-independent at the architectural level, but the standard includes implementation profiles for SOAP-based web services and, in later parts, RESTful HTTP interfaces. The choice between SOAP and REST depends on the interface requirements: SOAP is preferred for transactional reliability and security (interfaces I1, I9), while REST is preferred for query-heavy, stateless interactions (interfaces I2, I6, I7). Both must carry CIM XML payloads for semantic interoperability.
