Written by Technical Team | Last updated 27.02.2026 | 13 minute read
Interoperability in electricity distribution has moved from a “nice-to-have” integration goal to an operational necessity. As networks absorb more distributed energy resources (DER), electrify heat and transport, and face tighter reliability expectations, utilities increasingly rely on three platform families working in concert: Distributed Energy Resource Management Systems (DERMS), Advanced Distribution Management Systems (ADMS) and Outage Management Systems (OMS). Each is powerful in its own lane, yet the value is unlocked when they behave like one coherent operating environment rather than a set of loosely connected applications.
That coherence is difficult because these systems evolved with different data models, different vendor interpretations of “the network”, and different time horizons. DERMS cares about flexibility, availability windows, customer constraints, device telemetry and dispatch obligations. ADMS cares about connectivity, switching state, voltage and power flow, control room operations and network limits. OMS cares about incidents, customer impact, crew work, restoration steps and regulatory metrics. If each platform maintains its own truth about assets, topology and state, the utility ends up with duplicate integration logic, inconsistent decisions and operational friction during the moments that matter most.
IEC 61968 and IEC 61970—together with the Common Information Model (CIM)—offer a practical way out, but only if implemented as an engineering discipline rather than treated as a box-tick “standards compliant” label. In practice, success comes from establishing a common semantic backbone (CIM), designing profiles and interface contracts that match real workflows, and governing model ownership and change so that interoperability survives the next release cycle, the next programme, and the next grid transformation.
At its heart, IEC 61970 defines the core CIM concepts historically associated with energy management and network modelling, while IEC 61968 extends CIM into distribution operations and enterprise integration. The result is not simply a set of messages, but a shared meaning for things utilities talk about every day: feeders, switches, transformers, measurements, customers, work, outages, and increasingly DER assets and their operational characteristics.
That shared meaning is the key difference between “integration” and “interoperability”. Point-to-point integration can move data between systems, but it rarely guarantees that the sender and receiver interpret the data the same way. Interoperability means DERMS, ADMS and OMS can exchange information and make consistent decisions because they are operating against a compatible view of the world—especially the network model, operating states, events, and relationships between assets, locations and customers.
For DERMS–ADMS–OMS, CIM-based interoperability is most valuable in three places where utilities often struggle:
First, the network model and topology. ADMS typically holds the operational connectivity model; OMS often relies on a network model to infer customer outages and restoration; DERMS needs network context to understand constraints, hosting capacity, and where flexibility can be safely used. When these models diverge, dispatch can violate operational constraints, predicted customer impact becomes unreliable, and restoration can be slower and less safe.
Second, operational events and workflows. Switching, tagging, fault isolation, restoration steps, planned outages, DER curtailment, constraint management and emergency response all cross system boundaries. If each platform has its own event vocabulary and workflow states, the utility ends up with brittle translations and manual “bridge calls” between teams and tools.
Third, the pace of change. DER onboarding, new flexibility markets, evolving network visibility, and new regulatory reporting requirements mean interfaces can’t be one-off projects. The interoperability approach must be resilient to continuous change, allowing a utility to add new messages, attributes and flows without rewiring the estate every time.
A practical architecture starts by treating CIM as a semantic contract and IEC 61968/61970 as the primary reference for what data means, not just what fields exist. This shifts the design conversation from “Which API do we call?” to “Which system is authoritative for each concept, and how do we synchronise it reliably?” Once that is clear, message payloads, APIs, middleware and event streams become implementation details rather than sources of ambiguity.
Most utilities benefit from a canonical information layer: not necessarily a monolithic system, but a disciplined approach where CIM profiles define the payload content and relationships, and integration mechanisms preserve those semantics end-to-end. Some organisations implement this through an enterprise integration platform or service bus; others use API management plus event streaming; many adopt a hybrid where operational events are streamed and heavier model exchanges are handled through governed services. The choice matters less than maintaining semantic integrity, version control and repeatable patterns.
The next architectural decision is how to use profiles. CIM is intentionally broad, so real implementations must select subsets of classes, attributes and associations that match specific use cases. Profiles act as the contract: “For this workflow, these are the objects and attributes that must be present, these are optional, and this is how identifiers and references behave.” Without profiles, projects drift into ad-hoc interpretations of CIM, and interoperability becomes a matter of tribal knowledge rather than engineered repeatability.
Interface patterns typically fall into a small number of recurring shapes across DERMS, ADMS and OMS:
The final architectural element is identity and traceability. Interoperability fails quietly when identifiers are not stable, not unique, or not consistently mapped. A robust implementation establishes a utility-wide identifier strategy for assets, connectivity nodes, measurements, DER resources, and organisational entities, and then enforces it through integration contracts. Traceability also matters operationally: when OMS declares an outage, ADMS and DERMS must be able to tie that event back to the underlying network objects, the customer set, and the operational actions taken, with a clear audit trail.
Network model exchange is the most underestimated part of DERMS–ADMS–OMS interoperability. Many programmes focus on “getting data across” while assuming the model will sort itself out. In reality, the network model is the shared language that makes outage prediction credible, DER dispatch safe, and operator decisions explainable.
A workable approach begins with defining model authority. ADMS is often the operational authority for switch status, connectivity and real-time topology, while asset systems may be authoritative for static equipment attributes, and GIS may be authoritative for spatial placement. OMS may not need to own the model, but it must trust the model it uses for customer-impact analysis and restoration logic. DERMS needs enough network fidelity to respect constraints, including phase connectivity where relevant, and enough topology awareness to understand how flexibility maps to feeders, substations, or constraint zones.
Interoperability challenges surface in the gaps between “as-designed”, “as-built” and “as-operated”. GIS and asset systems may represent the engineered network, while ADMS represents the operated network with temporary configurations, open points, and switching changes. OMS often cares about the operated network during incidents, but also about the relationship between network objects and customers. DERMS straddles both: it needs the planning model to assess flexibility potential and the operated model to ensure dispatch is safe at the moment it is executed.
A common practical pattern is to separate the exchange into layers. One layer covers relatively static equipment and connectivity (the backbone). Another layer covers operational state (switch positions, energisation state, constraints) that changes frequently. A third layer covers derived views used for specific analytics (such as constraint zones or flexibility groupings) that may not exist as first-class objects in all systems. Treating these layers explicitly prevents “full model reload” habits that create downtime windows, and instead supports incremental updates aligned to operational needs.
Topology alignment also demands disciplined handling of references and namespaces. When a feeder is remodelled, a switch is replaced, or a customer is reconnected, all dependent references must remain consistent. This is where profile discipline pays off: if each exchange includes the minimum context required to preserve referential integrity, systems can evolve without breaking one another. Conversely, if payloads are “whatever the project happened to include”, the first major network change becomes an integration outage.
Finally, model alignment is not a one-time migration. It is a continuous operating process. Utilities that succeed treat model exchange like a living product: they monitor model deltas, measure reconciliation quality, and manage changes through controlled releases. They also define what “good enough” looks like for each consuming system. DERMS may not need every asset attribute OMS cares about, and OMS may not need every electrical parameter ADMS uses for power flow, but each must have what it needs to do its job without guessing.
Once the network model is aligned, the next major value comes from interoperable workflows that cross the control room, flexibility operations and outage response. This is where standards-based interoperability stops being an IT concern and becomes an operational performance advantage.
Consider a constraint management scenario on a heavily loaded feeder. ADMS detects an emerging voltage or thermal constraint through telemetry and analytics, and needs flexibility support. DERMS can provide a portfolio response—curtailment, battery dispatch, demand response—subject to contractual availability, customer constraints and device capabilities. Interoperability here is not just “send a setpoint”; it is the controlled exchange of context: where the constraint is, what the operating limits are, how long the issue is expected to last, what verification is required, and what fallback actions exist if flexibility under-delivers.
A mature implementation treats these as lifecycle interactions rather than single messages. DERMS needs to acknowledge requests, propose responses, execute dispatch, and report delivered performance. ADMS needs to validate that a proposed response is safe against current topology and switching state, and update its view of system state as the response is delivered. OMS needs to know about flexibility actions when they affect customer experience or restoration priorities, and it may also need to prevent dispatch into de-energised sections during outages for safety reasons.
Outage response adds additional complexity because the operating context changes rapidly. When a fault occurs, OMS typically logs the incident and begins predicting affected customers. ADMS may detect faults, infer probable fault locations, and execute switching plans to isolate and restore. DERMS may need to curtail generation to prevent backfeed into faulted sections, manage islanding where permitted, or prioritise critical loads supported by local resources. Interoperability must therefore handle fast-moving state changes, safety constraints, and command sequencing.
The crucial “in practice” detail is conflict management. During restoration, operators may open and close ties, change normal open points, and temporarily reconfigure feeders. If DERMS continues dispatch based on a stale topology snapshot, it can inadvertently worsen constraints or violate safety rules. The solution is to ensure topology and energisation state changes are shared as first-class operational events, and that DERMS has clear rules on when to pause, revalidate, or resynchronise before acting.
There is also a human factor: control room trust. Operators must believe that DERMS actions are predictable and that OMS predictions align with what the network is doing. Interoperability should therefore prioritise explainability: when a dispatch is requested, the reasoning and boundaries should be visible; when an outage is declared or cleared, the downstream impacts should reconcile consistently. This is less about adding dashboards and more about making sure the same identifiers, locations and network context appear across systems so that teams are not translating between incompatible representations during high-pressure situations.
Implementing IEC 61968/61970 across DERMS, ADMS and OMS is as much about operating model as technology. Utilities that treat it as a one-off integration project often end up with “CIM-flavoured” interfaces that still behave like bespoke point-to-point links. A practical roadmap establishes governance and repeatable delivery patterns early, so each new interface is an incremental extension of a coherent interoperability product.
A useful starting point is to define a CIM governance function with both business and technical ownership. This function controls profiles, naming conventions, identifier rules, and versioning policies, and it arbitrates disputes about data authority. It also owns a backlog of interoperability capabilities aligned to operational outcomes, such as “topology updates to DERMS within operational tolerances” or “OMS and ADMS outage state reconciliation within defined time windows”. When governance is only technical, it can become a modelling exercise detached from operations; when it is only business-led, it can become aspiration without engineering discipline.
Testing deserves equal attention. Interoperability failures often arise from edge cases: partial payloads, version mismatches, unexpected nulls, topology changes mid-process, or concurrency during major incidents. A robust approach treats interface testing like product testing, with automated contract tests, regression packs for profiles, and scenario-based end-to-end simulations that mimic real operating days—including storms, planned outages and high DER export periods.
Security and resilience must be designed into the interoperability layer rather than bolted on. These interfaces carry operationally sensitive information and, in some cases, control actions. Authentication, authorisation, message integrity, audit logging, and replay protection are not optional. Equally, operational resilience matters: if OMS or DERMS is unavailable, ADMS must degrade safely; if event streams are delayed, systems must detect staleness and avoid acting on outdated context.
A pragmatic delivery sequence often looks like this:
The final success factor is change management across vendors and internal teams. DERMS, ADMS and OMS vendors may support CIM in different ways, and utilities often need to balance “out of the box” capabilities with utility-specific requirements. The most effective stance is to treat the standard as the baseline contract while acknowledging that implementation details still require careful engineering: mapping choices, profile extensions, performance tuning, and operational acceptance criteria. When this is handled transparently—with clear contracts, shared test evidence and controlled releases—interoperability becomes an asset that compounds over time rather than a fragile web of integrations.
Ultimately, implementing IEC 61968/61970 across DERMS, ADMS and OMS is about creating a shared operational truth that can keep up with a rapidly changing distribution system. Done well, it reduces integration cost, improves outage and constraint response, enables scalable DER participation, and gives operators confidence that the systems supporting them are aligned when the network is under stress. The practical payoff is not simply “standards compliance”, but a distribution control environment that behaves predictably, adapts quickly, and turns flexibility into a dependable operational tool.
Is your team looking for help with Energy & Utilities software interoperability? Click the button below.
Get in touch