Variations Changes to the Network Model. Kendall Demaree - Alstom Grid June 17, 2014 Oslo, Norway

Transcription

1 Variations Changes to the Network Model Kendall Demaree - Alstom Grid June 17, 2014 Oslo, Norway

2

3 Toddler talks about Popes

4 Popes everywhere?

5 The answer is == clover

6 Everywhere so hard to grasp

7 Model variations are everywhere Updates and versioning of a model Comparing alternative construction choices Different representations for different purposes Reduced models HV only models Detailed intermachine dynamics studies Outages, especially planned outages Integrating a new updated external neighbor model Edit of a model Audit trail as annotation on variations Contingencies System Integrity Protection Schemes (SIPS), Remedial Action Schemes (RAS)

8 Goal: Manage model updates and alternatives Manage for business purposes means: Assemble into cases Schedule changes Test/verify Communicate Structure alternatives to avoid duplication Avoid duplication in alternatives Describe and relate model changes Workflow of designing and approving outages or construction

9 Part 2) Background Simple algebra for models CIM history, philosophy, and status regarding variations IEC and Difference Model Warm up with examples

10 Notation for model updates Start with model M A Specific change to any model is D AB (aka Difference Model ) Note AB is just a naming convention Use + to apply the change The result when applied to M A is model M B M A + D AB = M B

11 Difference Model creation Given full model M A and full model M B The specific difference model D AB can be determined Use - to represent difference operation from: gives: M A + D AB = M B D AB = M B - M A

12 CIM background regarding variations CIM (network models) mainly represent one point in time, one alternative, one case Resisted adding effective dates to all classes (good move) Some exceptions such as: RegularIntervalSchedule and other forms of schedules ActivityRecord, metering changes and events, Outages and Contingencies commonly accepted IEC (CIM RDF XML) and IEC (XSD verbs)

13 IEC Title: Implementation Profiles for IEC Defines XSD message patterns and envelope structures Header denotes CRUD style (and several other) verbs: create change delete Verbs can be nested to any depth Best if payloads avoid nested containment as in CIM RDF XML Not the focus here, but equally capable to describe change

14 IEC DifferenceModel Title: CIMXML Model Exchange Format The CIM/RDF/XML flavor of describing model differences InterOp tested and used in many active systems Initially designed to simply stream a set of changes to be copied in another system Can be (and often is) used in other scenarios Describes a forward, reverse, and precondition Contains header with limited context information

15 Simple example of Difference Model

16 Reverse (undo)

17 Apply Difference Model elsewhere

18 Network example on the EQ profile Equipment profile of IEC CPSM specification Add a tap load on line between station A and B New tap station named T. Split original impedance 50/50 Add load one conforming load in tap station. Retain the original terminal locations (for measurements) Classic: M A + D AB = M B

19 Initial EQ model A drawing

20 Final EQ model B drawing

21 Initial EQ model A

22 Initial EQ model A objects

23 Final EQ model B

24 Final EQ model B

25 Example network Difference Model

26 header information Some context information, but limited Contains: Model identity Model Authority Set Created date Profile Version DependentOn relationship to other models Supercedes relationship to other models

27 Header model relationships

28 Part 3) Power System Projects Communicate planned changes Describe schedule Describe dependencies Describe steps or phases within the project Give business lifecycle state specification for network change

29 Timeline for EQ profile

30 Timeline for EQ + SSH profile

31 Power System Projects status Informative UML now Adds effective date Adds recursive containment (projects contain projects) To add: User defined business states Description of the changes (Difference models) Tentative plan: Model, profile, and exchange as CIM data

32 Present informative Projects model Warning : Informative! Warning : Informative! Warning : Informative! Warning : Informative!

33 Differential Model detailed modeling WG13 presently considering best approach All WG s could optionally could adopt same approach Options: Reference an existing style difference file Model explicitly (does not work well for complex changes) Express directly in model using property objects

34 Outage profile explicit UML model WG14 has developed an outage profile based on limited changes, like generic de-rating and open/close a switch Straight forward and simple approach for basics Duplicates modeling and descriptions Practically limited to small scope of model changes No clear rules, pattern, or style developed yet Would be similar to property objects approach

35 Warning : Draft! WG14 explicit Outage model Warning : Draft! Warning : Draft! Warning : Draft!

36 Warning : Draft! Property objects to express change Model in UML and borrow profile classes but not their MRID. Property objects: Effectively reference normal model MRID s Contain their own identity (could be payload local) Shaped like normal profile classes, all properties optional Classic references only to other Proxy objects in playload Could serialize just like any other data Analogy with DiagramLayout strategy Use existing serialization and profiling techniques Explicit association to IdentifiedObject for generality

37 Class diagram for property objects Warning : Draft! Warning : Draft! Warning : Draft!

38 Instance diagram for property objects Renames VoltageLevel.name to MyNewName on object VL1. Warning : Draft! Warning : Draft! Warning : Draft!

39 Outage as SSH change Outage

40 Outage change specification With explicit WG14 planned outage profile Domain logic understands Outage/SwitchAction/Switch Implements change to Switch.open in SSH data With incremental difference model reference, apply it Requires jump to different content, heavy for context change Profile should be defined instance content would be to change Switch.open With properties object, generically read changes and apply Profile should be defined Requires new type of processing Described in native objects along with Outage object instance content would be to change Switch.open

41 Part 4) Frames and full models When changes are too numerous use full model Organize full models so never include duplicates Frames and ModelPartSpec provide a means to select

42 Basic frames example

43 Frame with a

44 Alternates also have s

45 Frames with s

46 Boundaries also have s

47 Manage change everywhere

48 Generic Change Modeling Task Force Just formed last week (circa June 13) IEC TC57 WG 13, 14, and 16 interest Objective: Define a modeling approach for expressing a collection of changes to a CIM dataset as an Incremental Dataset Goals: construction, outages, SIPS, audit trail, proposed plans, Grouped changes, and augmented with context information Target of change is unknown or varies Narrow or constrain the allowed changes (like a profile) Works well with RDF, XSD, or other serialization technologies

49 Take aways Change and variations are all around us Our goal is to manage network model variations Fundamentals are in place for network case semantics Change specifications exist Working on giving changes and alternate models context Frames and PowerSystemProject models in IEC development Your feedback is welcome

50 Questions or feedback M A + D AB = M B kendall.demaree@alstom.com