Model Authorities and Model Exchange

2. Model Authorities and Model Exchange Jay Britton Principal Architect

3. Model Exchange Business Goal • Neighboring parties in an interconnect exchange models. • Each party is the “modeling authority” only for its own territory. • Each party will use other parties’ internal models to create their external model. • To accomplish this, • Each party exports its internal model to its neighbors and keeps it up to date. • Each party imports each neighbor’s model and uses it to develop and update its external model. • Proposed Goal: an external model can be updated within an hour of a change to a neighbor’s internal.

4. Initial CIM Model Exchange Concept CIM Exchange (full, partial, incremental) CIM import / export CIM import / export System B Import Model System A Import Model a Proprietary / Home grown Extract / Merge Tools Proprietary / Home grown Extract / Merge Tools b A Internal Model B’s Model of A System A Local Vendor Model System B Local Vendor Model A’s model of B B Internal Model System B EMS System A EMS

5. Making CIM Exchange a Complete Process • MRIDs as permanent unique object identifiers. • Decide who assigns identifiers to each object. • Name registry manages naming differences. • Model exchange uses consistent identifiers. • Specify the modeling territories precisely within the model. • Include security against changes submitted by unauthorized parties. • Report updates with CIM incremental updates. • If problems arise, it is easy to identify the source. • Mark equivalents in the model. • Import process can easily recognize whether an update requires a new reduction. • On-line systems receive and test updates incrementally. • If problems arise, it is easy to identify the source

6. Central Concept: Model Authority Sets (MAS) • Notation: • Nodes represent individual CIM objects. • Branches represent relations between objects. • Two MAS types: • Regional (single authority) • Boundary (bipartisan authority / single caretaker) • Rules: • Every CIM object is in one and only one MAS. • Each MAS controls object MRIDs in its territory. • No object in a regional set relates directly to any object in another regional set.

7. A little more detailed look at a boundary example.

8. A UCTE boundary example.

9. Use Case: Peer-to-Peer Full Model Exchange CIM Modeler CIM Modeler A Region A Region boundary boundary B Region B Region a A Region (reduced) B Region (reduced) b System A EMS System B EMS CIM import CIM import Proprietary Model B Proprietary Model A

10. Use Case: A to B Incremental Update CIM Modeler CIM Modeler a a A Region A Region boundary boundary B Region B Region A Region (reduced) B Region (reduced) If the change can be processed against the reduced region, then it can be transferred directly to the CIM import for system B. System A Local Vendor System B Local Vendor CIM delta CIM MAS CIM delta Proprietary Model B Proprietary Model A

11. Use Case: Hierarchical Exchange CIM Upper Tier Modeling x A Region boundary B Region CIM Region Modeling CIM Region Modeling A Region A Region boundary boundary B Region B Region a b A Region (reduced) B Region (reduced) CIM import CIM import System A Local Vendor System B Local Vendor Proprietary Model A Proprietary Model B

12. Why is this a good thing? • Generality • MAS delineate all objects, not just the physical connection boundaries. • Establishing authority and responsibility… • Basis for efficient, repeatable processes. • Clarifies responsibility for naming and MRIDs for all objects. • Processing efficiency for model exchange: • Merging regions is a simple union of objects. • Extraction is a simple transfer of objects without modification. • Replace simply extracts and discards before merging. • Maximum XML file size can be limited to maximum largest MAS size, rather than whole interconnect. • Checking that a change comes from the correct source. • As a regional MA submitting a change: • You can make any change you want to your regional set without fear that it would disturb a relationship from another region. • Your changes can easily be validated because they must be referentially complete without any other regional set. • If your change cannot comply with the above condition, it tells you immediately that you need to arbitrate a change in a boundary set. • As the receiver checking the right to make a change: • It must be referentially complete against the source’s region plus its boundaries.