Utility Integration Design (IEC CIM): [Utility or programme name]
Solution design for integrating utility operational and business
systems (EMS, ADMS and DMS, OMS, GIS, MDM, asset management, customer
and billing, market systems) on the IEC Common Information Model. The
structure follows the IEC 61970 and IEC 61968 series: the CIM base in
IEC 61970-301:2020+AMD1:2022, the distribution extensions in
IEC 61968-11, the message implementation profile in IEC 61968-100,
grid model exchange with CGMES 3.0 (IEC TS 61970-600-1 and -600-2:2021,
ENTSO-E) and security with the IEC 62351 series. Replace every
[bracketed] value and every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [CIM-INT-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@utility-integration-architect] |
| Approvers/reviewers | [@network-model-manager], [@control-room-lead], [@gis-lead], [@ot-security-lead], [@enterprise-architect] |
| Utility type and segments | [TSO / DSO / vertically integrated / water or gas], [transmission, distribution, metering] |
| CIM baseline | [CIM UML release, e.g. CIM17 or later], IEC 61970-301:2020+AMD1:2022, IEC 61968-11 [edition] |
| Profiles in use | [CGMES 3.0, distribution profiles, IEC 61968-9 metering, local profiles] |
| Regulatory context | [ENTSO-E network codes, national regulator, NIS2 or national critical infrastructure rules] |
| Classification | [Internal / Confidential / Critical infrastructure restricted] |
| Last updated | YYYY-MM-DD |
Approvals
| Role | Name | Decision | Date |
|---|
| Network model manager | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Control room operations | [@name] | [Decision] | YYYY-MM-DD |
| OT security | [@name] | [Decision] | YYYY-MM-DD |
| Architecture board | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved for ADMS phase 1 |
| 1.1 | YYYY-MM-DD | [@name] | Example: Moved grid model exchange from CGMES 2.4.15 to CGMES 3.0 |
Contents
1. Scope and drivers
1.1 Scope
| In scope | Out of scope |
|---|
| Example: As-built distribution network model from GIS to ADMS and OMS | Protection relay settings management |
| Example: Meter events and readings from MDM to OMS and billing | Head-end to meter communication protocols |
| Example: Transmission grid model exchange with the regional coordination centre in CGMES | Market bidding and settlement |
| Example: Work orders between ADMS, asset management and mobile workforce | [Item] |
1.2 Drivers
| ID | Driver | Measure | Target |
|---|
| DRV-001 (Example) | One network model for control room and planning | Model build time from GIS change to ADMS | Under [24 hours] |
| DRV-002 (Example) | Faster outage restoration | Meter last-gasp events reaching OMS | Under [60 seconds] |
| DRV-003 (Example) | Regulatory model exchange | Accepted CGMES submissions | [100 %] on schedule |
| [DRV-NNN] | [Driver] | [Measure] | [Target] |
2. Requirements
2.1 Functional requirements
| ID | Requirement | Priority | Acceptance criterion |
|---|
| FR-001 (Example) | GIS publishes network changes as incremental model updates to ADMS | Must | ADMS applies a test change set without a full model reload |
| FR-002 (Example) | MDM sends meter outage and restoration events to OMS | Must | Events correlated to the correct transformer in 99 % of tests |
| FR-003 (Example) | OMS sends outage records to customer systems for notification | Must | Customer notice within [10 minutes] of outage confirmation |
| FR-004 (Example) | EMS exports the transmission model and state in CGMES 3.0 | Must | Files pass the ENTSO-E validation rules used by the coordination centre |
| FR-005 (Example) | Asset management receives equipment changes from field work orders | Should | Asset record updated within one working day |
| [FR-NNN] | [Requirement] | [Must / Should / Could] | [Criterion] |
2.2 Quality attributes
| ID | Attribute | Requirement | Verification |
|---|
| NFR-001 (Example) | Model size | Distribution model of [n] million objects loads within [n hours] | Load test |
| NFR-002 (Example) | Event latency | Meter events under [60 seconds] end to end during storm volumes of [n] events per minute | Storm simulation |
| NFR-003 (Example) | Availability | Control room interfaces keep working when the enterprise integration platform is down | Failover test |
| NFR-004 (Example) | Security | Interfaces to control systems meet the zone rules in section 9 | Security review |
| [NFR-NNN] | [Attribute] | [Requirement] | [Verification] |
2.3 Volumes and sizing
State the volumes that size the broker, the model repository and the OMS interfaces, and write down what each number means for the design. The figures below are a worked example for a mid-sized distribution utility; replace them with your own.
| ID | Quantity | Example value | Derivation | Design consequence |
|---|
| VOL-001 (Example) | Metered usage points | 1,200,000 | Customer register | Usage point mRIDs and the MDM to OMS mapping table hold 1.2 million rows |
| VOL-002 (Example) | Meters losing supply in a severe storm hour | 150,000 | 12.5 % of VOL-001 | Worst-case burst for MSG-001 |
| VOL-003 (Example) | Last-gasp messages received by the head-end | 90,000 in the first 30 minutes | 60 % reception rate of VOL-002 (last gasps are often lost when the network itself is down) | 3,000 events per minute on average; size the broker and the OMS adapter for 3 times that peak, 9,000 per minute, which becomes the NFR-002 storm figure |
| VOL-004 (Example) | Distribution network objects | 4,000,000 | GIS export count | A full model load is an hours-long job, so full reloads are a recovery path only (DEC-002) |
| VOL-005 (Example) | Approved GIS jobs per working day | 300 | GIS workflow statistics | About 300 difference models a day; at an average of 200 changed objects each, 60,000 object changes a day flow through VAL rules |
| VOL-006 (Example) | Outage records created per storm day | 2,500 | OMS history | MSG-003 volume is modest; latency, not throughput, drives its design |
Check the arithmetic each time a value changes: VOL-003 divided by 30 minutes gives the average rate, and VOL-005 times the average change-set size gives the daily validation load.
3. System landscape and IEC 61968 interface reference model
| Business function (IEC 61968-1 name) | System | Product | Owner |
|---|
| Network operations (Example) | ADMS, OMS | [Product] | @control-room-lead |
| Records and asset management (Example) | GIS, asset management | [Product] | @gis-lead |
| Operational planning and optimisation (Example) | ADMS study mode | [Product] | @operations-planning |
| Maintenance and construction (Example) | Work management, mobile workforce | [Product] | @field-ops |
| Network extension planning (Example) | Planning tool | [Product] | @network-planning |
| Customer support (Example) | CRM, customer portal | [Product] | @customer-it |
| Meter reading and control (Example) | MDM, head-end | [Product] | @metering-lead |
| Energy management (IEC 61970 scope) (Example) | EMS, SCADA | [Product] | @transmission-ops |
4. Canonical model and system of record
| CIM package or class group | System of record | Consumers | Identifier rule | Notes |
|---|
| Wires and connectivity (conducting equipment, terminals, connectivity nodes) (Example) | GIS for distribution, EMS modelling tool for transmission | ADMS, OMS, planning | Persistent mRID (UUID) assigned at creation, never reused | Boundary between GIS and EMS at the primary substation busbar |
| Assets (asset, asset info, lifecycle) (Example) | Asset management | GIS, ADMS | Asset mRID plus asset tag | Linked to power system resources |
| Measurements (analog, discrete, accumulator) (Example) | SCADA point database | ADMS, historian | mRID per measurement, mapped to SCADA point ID | |
| Metering (usage point, meter, readings, end device events) (Example) | MDM | OMS, billing | Usage point ID | Event types from IEC 61968-9 |
| Customers and service locations (Example) | CRM and billing | OMS, MDM | Customer account ID | Personal data minimised in operational systems |
| Work (work, work tasks) (Example) | Work management | ADMS, asset management | Work order number | |
| [Package or class group] | [System] | [Consumers] | [Rule] | [Notes] |
- Use the CIM master resource identifier (mRID) as the cross-system key for every exchanged object; keep local keys only as name aliases.
- Extend the CIM only in a utility namespace, record each extension in section 5.3 and propose it to the CIM Users Group when it is of general use.
- Never transform the meaning of a class between systems; if two systems disagree on what an object is, resolve it in the system of record.
4.1 Identifier governance
| ID | Rule | Reason |
|---|
| IDG-001 (Example) | The system of record creates the mRID at object creation, as a UUID, and never changes it, even when the object is moved, renamed or re-parented | Consumers keep history and links across model releases |
| IDG-002 (Example) | Replaced equipment gets a new mRID; the asset swap is recorded in the Assets package, not by reusing the old power system resource identifier | Separates the functional position from the physical asset installed there |
| IDG-003 (Example) | Each consumer stores the mRID alongside its local key; a cross-reference service answers lookups in both directions | Adapters do not need their own mapping tables |
| IDG-004 (Example) | Objects at the GIS and EMS boundary (primary substation busbars) are created once by the transmission model authority and referenced by the distribution model | Stops duplicate boundary objects when the two models are merged |
| IDG-005 (Example) | Deleted objects keep their mRID in a tombstone list for [7 years] | Historic outage and asset records still resolve |
| [IDG-NNN] | [Rule] | [Reason] |
Migration note: legacy systems rarely hold stable identifiers. Before the first model load, run an identifier assignment exercise: generate mRIDs in the system of record, publish the local key to mRID map, and freeze local key reuse from that date.
5. CIM profile selection and governance
5.1 Profile register
| Profile ID | Profile | Basis | Version | Used by | Owner |
|---|
| PRF-001 (Example) | Distribution network model (equipment, topology, geography) | IEC 61968-13 distribution profiles, local restrictions | [Version] | GIS to NMM to ADMS | @network-model-manager |
| PRF-002 (Example) | Transmission grid model and state | CGMES 3.0 (IEC TS 61970-600-1 and -600-2:2021, ENTSO-E) | 3.0 | EMS to coordination centre | @transmission-ops |
| PRF-003 (Example) | Meter end device events | IEC 61968-9 message types | [Edition] | MDM to OMS | @metering-lead |
| PRF-004 (Example) | Outage records | Local profile on CIM Operations and Customers packages | [Version] | OMS to CRM | @integration-lead |
| [PRF-NNN] | [Profile] | [Basis] | [Version] | [Used by] | [@owner] |
5.2 Profile governance
| Step | Rule |
|---|
| Authoring (Example) | Profiles are built from the baseline CIM UML in a profiling tool and stored with the UML in version control |
| Artefacts (Example) | Each profile publishes RDF schema or XML schema, documentation and validation rules |
| Versioning (Example) | Semantic versions; breaking changes need a migration window of [two releases] |
| Change board (Example) | Monthly; members from GIS, control room, metering, integration |
| Baseline upgrade (Example) | Review each new CIM release once a year; upgrade profiles only with a business need |
5.3 Extension register
| Extension ID | Class or attribute | Reason | Namespace | Proposed upstream |
|---|
| EXT-001 (Example) | Local feeder colour code attribute | Required by field crews | http://[utility]/cim/ext# | No |
| [EXT-NNN] | [Item] | [Reason] | [Namespace] | [Yes / No] |
6. Message design (IEC 61968-100)
6.1 Message catalogue
| ID | Noun (profile) | Verb pattern | Source | Target | Transport | Pattern | Latency class |
|---|
| MSG-001 (Example) | EndDeviceEvents (PRF-003) | created (event) | MDM | OMS | Message broker topic | Publish and subscribe | Seconds |
| MSG-002 (Example) | MeterReadings | get, reply | OMS | MDM | Web service or REST | Request and reply | Seconds |
| MSG-003 (Example) | OutageRecords (PRF-004) | created, changed, closed | OMS | CRM | Message broker | Publish and subscribe | Minutes |
| MSG-004 (Example) | WorkOrders | create, then reply | ADMS | Work management | Message broker queue | Asynchronous request and reply | Minutes |
| MSG-005 (Example) | Network model change set (PRF-001) | Model exchange, not a message | NMM | ADMS | File or model repository | Section 7 | Hours |
| [MSG-NNN] | [Noun] | [Verb] | [Source] | [Target] | [Transport] | [Pattern] | [Class] |
6.2 Envelope and header rules
| ID | Rule |
|---|
| HDR-001 (Example) | Every message carries a message ID, correlation ID, timestamp in UTC, source system and user or service identity |
| HDR-002 (Example) | Replies carry a result (OK, partial, failed) and error codes from the utility error catalogue |
| HDR-003 (Example) | Payloads validate against the profile schema before publishing; invalid payloads go to an error queue |
| HDR-004 (Example) | Large payloads are compressed and flagged in the header, or exchanged as files with a reference message |
| HDR-005 (Example) | Event consumers are idempotent on message ID |
| [HDR-NNN] | [Rule] |
6.3 Storm behaviour
During major events, meter last-gasp messages arrive in bursts. Design for the worst case named in NFR-002 and sized in VOL-003: buffer at the broker, filter duplicates by usage point and time window, prioritise events for already-predicted outages lower than new ones, and protect the OMS with a rate limit and back-pressure rather than dropping messages silently.
Design choices for the storm path:
| Option | How it works | Strength | Weakness |
|---|
| A. Pass every event to OMS (Example) | Broker forwards all MSG-001 events | Simple; OMS sees everything | OMS prediction engine saturates at storm peak |
| B. Aggregate in the adapter (Example) | Adapter groups events per distribution transformer over a [60 second] window and sends one summary per transformer | Cuts volume by roughly the meters per transformer ratio | Adds up to one window of latency; needs the usage point to transformer map from the network model |
| C. Filter at the head-end (Example) | Head-end suppresses events for meters already known to be off | Least traffic | Logic sits in a vendor system outside the profile governance |
Chosen: [Example: B, because it keeps the logic in a governed adapter and the 60 second window fits DRV-002]. Restoration events use the same path, so that OMS can confirm restoration per transformer and flag nested outages where some meters stay off.
6.4 Errors, retries and replay
| ID | Rule |
|---|
| ERR-001 (Example) | Transient failures (timeout, broker unavailable) retry with exponential back-off up to [5] attempts, then go to the dead-letter queue |
| ERR-002 (Example) | Validation failures never retry; they go straight to the error queue with the failing rule and the profile version |
| ERR-003 (Example) | Each dead-letter queue has an owner from section 11.1 and a response target of [4 working hours], or [30 minutes] for control room flows |
| ERR-004 (Example) | Replay keeps the original message ID and timestamp so that idempotent consumers (HDR-005) discard what they already processed |
| ERR-005 (Example) | Event topics keep [7 days] of history so a consumer restored from backup can rebuild its state |
| [ERR-NNN] | [Rule] |
7. Model exchange and network model management
7.1 Model authority sets
| Model authority set | Authority | Content | Exchange format | Frequency |
|---|
| MAS-01 (Example) | Distribution GIS team | Medium and low voltage equipment and connectivity | PRF-001, difference models | On each approved GIS job |
| MAS-02 (Example) | Transmission modelling team | High voltage network and substations | PRF-002 (CGMES 3.0) | Per release and on change |
| MAS-03 (Example) | Neighbouring TSO | External equivalents and boundary | CGMES boundary set | As published |
| [MAS-NN] | [Authority] | [Content] | [Format] | [Frequency] |
7.2 Model lifecycle
A network change moves through these states before the control room uses it. Only validated, approved change sets reach the ADMS; validation errors return to the model authority, never to a manual fix in the ADMS.
7.3 Validation rules
| ID | Rule | Severity |
|---|
| VAL-001 (Example) | Every conducting equipment has the number of terminals its class requires | Blocking |
| VAL-002 (Example) | Every feeder traces back to one source | Blocking |
| VAL-003 (Example) | No mRID appears twice | Blocking |
| VAL-004 (Example) | Ratings present for every transformer | Warning |
| VAL-005 (Example) | Geographic coordinates within the service territory | Warning |
| [VAL-NNN] | [Rule] | [Blocking / Warning] |
Run blocking rules before publication and warnings in a daily data quality report owned by the GIS lead. Track the count of open warnings as a model quality measure in section 11.
7.4 Grid model exchange for transmission (CGMES)
Where the utility is a TSO or delivers models to one, describe the exchange cycle with the regional coordination centre:
| Step | Design for this utility |
|---|
| Boundary set (Example) | Use the boundary set published for the synchronous area; load each new release into the modelling tool before building models that reference it |
| Individual grid model build (Example) | EMS modelling tool exports the equipment, topology, steady state hypothesis and state variable parts of the individual grid model (IGM) as CGMES 3.0 instance files |
| Timeframes (Example) | [Year-ahead, month-ahead, week-ahead, day-ahead, intraday] as required by the applicable network code methodology |
| Local validation (Example) | Run the same validation rule set the coordination centre applies, before upload; failures block submission |
| Submission (Example) | Upload through [the ENTSO-E operational planning data platform or regional channel]; record acknowledgement and quality report |
| Merge feedback (Example) | Quality issues from the common grid model (CGM) merge go back to the transmission modelling team as tickets with a fix deadline |
7.5 Planned projects and future network states
Network extension planning works on future states that the control room must not see until commissioning. Keep planned projects as separate difference models against a base release, tag each with its expected energisation date, and promote it to the as-built path in 7.2 only when field completion is recorded. When two projects change the same equipment, the later project is rebased and revalidated before approval.
8. Integration architecture
| Component | Purpose | Zone | Product | Owner |
|---|
| Enterprise integration platform (Example) | Request and reply, routing, transformation | Enterprise | [Product] | @integration-lead |
| Operational message broker (Example) | High-volume events (meter, outage) | Operations DMZ | [Product] | @integration-lead |
| Network model repository (Example) | Store and version CIM models and change sets | Operations | [Product] | @network-model-manager |
| Profile and schema registry (Example) | Publish profiles and validate payloads | Enterprise | [Product] | @integration-lead |
| Monitoring (Example) | End-to-end message tracking and alerting | Enterprise and operations | [Product] | @operations |
- Keep CIM transformation out of the control systems: adapters at the edge of each system convert local formats to profiles.
- Put the operational message broker in a DMZ between the enterprise and the control zone, so the ADMS never accepts inbound sessions from the enterprise.
- Use asynchronous messaging for all flows into the control zone and give each flow a dead-letter queue with an owner.
9. Security (IEC 62351 and OT boundary)
| Control area | Design |
|---|
| Zones and conduits (Example) | Enterprise, operations DMZ, control room and substation zones; conduits listed per exchange in section 9.1 |
| Transport security (Example) | TLS with mutual authentication on every interface; TLS profile per IEC 62351 where control protocols are involved |
| Role-based access (Example) | Service identities per interface; roles aligned with the IEC 62351 RBAC model for control functions |
| Key and certificate management (Example) | Utility PKI, automated renewal; see PKI Certificate Architecture (security/pki-certificate-architecture) |
| Model and file integrity (Example) | Signed model releases, checksums verified before ADMS load |
| Logging (Example) | Security events forwarded to the security operations centre with OT context |
| Regulation (Example) | Map controls to [NIS2 measures / national critical infrastructure rules]; see NIS2 Security Measures (compliance/nis2-security-measures) |
9.1 Conduits per exchange
| Conduit ID | Zones | Exchanges carried | Initiated from | Controls |
|---|
| CND-01 (Example) | Enterprise to operations DMZ | MSG-001 to MSG-004 (enterprise side) | Each side connects to the DMZ broker; no direct sessions across | Firewall allow list, mutual TLS, broker access control per topic |
| CND-02 (Example) | Operations DMZ to control room | MSG-001, MSG-003, MSG-004 (control side) | Control room adapters connect outbound to the DMZ broker | Mutual TLS, one service identity per adapter, topic allow list |
| CND-03 (Example) | Operations to control room | MSG-005 model change sets | Control room pulls signed releases from the model repository | Signature and checksum check, release approval record |
| CND-04 (Example) | Control room to external coordination centre | CGMES submissions (section 7.4) | Control room outbound only | Dedicated channel, certificate authentication |
| [CND-NN] | [Zones] | [Exchanges] | [Direction] | [Controls] |
Every exchange in section 6 maps to exactly one conduit path. Review the table whenever an exchange is added; an exchange without a conduit is not approved.
10. Testing and interoperability
| ID | Test | Pass criterion | Evidence |
|---|
| TST-001 (Example) | Profile conformance for PRF-001 to PRF-004 | All payloads validate; no unknown extensions | Validator reports |
| TST-002 (Example) | Model round trip GIS to ADMS | Change set applied; topology identical to GIS trace | Comparison report |
| TST-003 (Example) | Storm simulation | NFR-002 met at [n] events per minute | Load test report |
| TST-004 (Example) | CGMES submission | Coordination centre validation passes | Acceptance message |
| TST-005 (Example) | Integration platform outage | Control room flows continue through the operational broker | Failover record |
| TST-006 (Example) | Full model load | NFR-001 met for VOL-004 objects | Load test report |
| TST-007 (Example) | Outage notification end to end | FR-003 notice time met from OMS confirmation to customer message | Scenario test record |
| TST-008 (Example) | Work order to asset update | FR-005 asset record updated within one working day | Scenario test record |
| TST-009 (Example) | Conduit verification | Only the flows in section 9.1 pass; signed releases rejected when tampered | Firewall review, scan and tamper test results |
| [TST-NNN] | [Test] | [Criterion] | [Evidence] |
10.1 Traceability
| Requirement | Design element | Test |
|---|
| FR-001 (Example) | Section 7, PRF-001 | TST-002 |
| FR-002 (Example) | MSG-001, section 6.3 | TST-003 |
| FR-003 (Example) | MSG-003, PRF-004 | TST-007 |
| FR-004 (Example) | PRF-002, section 7.4 | TST-004 |
| FR-005 (Example) | MSG-004 | TST-008 |
| NFR-001 (Example) | Section 7, VOL-004 | TST-006 |
| NFR-002 (Example) | Section 6.3, VOL-003 | TST-003 |
| NFR-003 (Example) | Section 8 | TST-005 |
| NFR-004 (Example) | Section 9.1 | TST-009 |
| [ID] | [Element] | [Test] |
11. Operations, risks and decisions
11.1 RACI
| Activity | Network model manager | GIS team | Control room | Integration team | OT security |
|---|
| Model release (Example) | A | R | C | I | I |
| Profile change (Example) | A | C | C | R | C |
| Interface incident (Example) | I | I | C | R/A | C |
| Conduit change (Example) | I | I | C | C | R/A |
| Model data quality report (Example) | A | R | I | I | I |
| Dead-letter queue handling (Example) | C | C | I | R/A | I |
11.2 Risks
| ID | Risk | Likelihood | Impact | Response | Owner |
|---|
| RSK-001 (Example) | GIS connectivity data quality too low for ADMS | High | High | Data cleansing programme, VAL rules before go-live | @gis-lead |
| RSK-002 (Example) | Vendor implements an older CIM release | Medium | Medium | Profile version negotiation, adapter mapping | @integration-lead |
| RSK-003 (Example) | Storm volumes overload OMS | Medium | High | Section 6.3 controls, TST-003 | @control-room-lead |
| [RSK-NNN] | [Risk] | [L / M / H] | [L / M / H] | [Response] | [@owner] |
11.3 Decisions
| ID | Decision | Alternatives | Date |
|---|
| DEC-001 (Example) | GIS is the model authority for distribution connectivity | ADMS editing tools as master | YYYY-MM-DD |
| DEC-002 (Example) | Incremental model updates instead of nightly full loads | Full reload | YYYY-MM-DD |
| DEC-003 (Example) | Aggregate meter events per transformer in the adapter (section 6.3, option B) | Pass every event; filter at head-end | YYYY-MM-DD |
| [DEC-NNN] | [Decision] | [Alternatives] | YYYY-MM-DD |
Record each decision in full in an Architecture Decision Log (architecture/architecture-decision-log).
11.4 Delivery phases
| Phase | Scope | Exit criterion |
|---|
| 1. Foundations (Example) | mRID assignment (section 4.1), profile register, model repository, validation rules | First full model passes all blocking VAL rules |
| 2. Network model to ADMS (Example) | PRF-001 difference models, MSG-005, CND-03 | TST-002 and TST-006 passed; control room sign-off |
| 3. Outage and metering (Example) | MSG-001 to MSG-003, storm path | TST-003 and TST-007 passed at VOL-003 peak |
| 4. Work and assets (Example) | MSG-004, asset synchronisation | TST-008 passed |
| [Phase] | [Scope] | [Exit criterion] |
11.5 Operational measures
| Measure | Target | Owner |
|---|
| Change sets rejected by blocking rules (Example) | Under [5 %] of submissions per month | @gis-lead |
| Open model quality warnings (Example) | Falling month on month | @network-model-manager |
| Messages in dead-letter queues older than target (Example) | Zero | @integration-lead |
| CGMES submissions accepted first time (Example) | [95 %] | @transmission-ops |
12. Glossary and references
12.1 Glossary
| Term | Meaning |
|---|
| CIM | Common Information Model: the IEC information model for electric utilities, maintained as UML |
| Profile | Restricted, versioned subset of the CIM for one exchange purpose |
| mRID | Master resource identifier: globally unique, persistent object key |
| CGMES | Common Grid Model Exchange Standard: ENTSO-E profile set for transmission grid models |
| Model authority set | Part of a model maintained by one authority and exchanged as a unit |
| Difference model | Change set that adds, removes or modifies objects relative to a base model |
| IGM | Individual grid model: one TSO's model for a given timeframe, exchanged in CGMES |
| CGM | Common grid model: the merge of individual grid models for a synchronous area or region |
| Boundary set | Shared set of boundary points and equivalents that lets individual models be merged |
| Dead-letter queue | Queue that holds messages that could not be delivered or processed, for investigation and replay |
| ADMS | Advanced distribution management system |
| MDM | Meter data management system |
12.2 References
| Reference | Version or date | Use |
|---|
| IEC 61970-301:2020+AMD1:2022, CIM base, webstore.iec.ch | Edition 7.1, 2022-02-22 (stability date 2026; check for a newer edition) | Core, Wires, Topology packages |
| IEC 61968-11, Common information model extensions for distribution | Check the current edition at webstore.iec.ch | Distribution packages |
| IEC 61968-100, Implementation profiles for application integration | Check the current edition | Message envelope and verbs |
| IEC 61968-1, Interface architecture and general recommendations; IEC 61968-9, Interfaces for meter reading and control; IEC 61968-13, distribution profiles | Check current editions | Reference model, metering, distribution profiles |
| IEC 61970-552, CIM XML model exchange format | Check the current edition | Model serialisation |
| CGMES 3.0 (IEC TS 61970-600-1:2021 and -600-2:2021), ENTSO-E CIM for grid models exchange page | Page lists the UML package ENTSO-E CIM 17.2.0 / CGMES 3.0.0 / NC Profiles 2.5, approved 2026-09-10; CGMES 3.0 profiles unchanged since 2021 | Transmission model exchange |
| IEC 62351 series, power systems data and communications security | Check current part editions | Security controls |
| CIM Users Group, UCA International Users Group, ucaiug.org | Current CIM UML release | Model source, interoperability tests |
Standard and licence note
Structure aligned with the IEC 61970 and IEC 61968 series (IEC 61970-301:2020+AMD1:2022 CIM base, IEC 61968-1, -9, -11, -13 and -100, IEC 61970-552), the CGMES 3.0 profile set published by ENTSO-E and standardised as IEC TS 61970-600-1 and -600-2:2021, and the IEC 62351 security series. IEC standards are copyrighted: this template uses only part numbers, package, class and verb names, and all descriptions are original text written for this collection; obtain the standards from the IEC webstore and the CIM UML from the CIM Users Group for normative content. Check the current official editions before use. Template licence: MIT.