CIM SteadyState Solution Interfaces Jay Britton Use Cases
CIM Steady-State Solution Interfaces Jay Britton
Use Cases u Exchange of network models. w EMS A and B are neighbors in an interconnection and therefore each needs to represent the other as part of its external model. w Requires exchange of internal models. w Scope is limited to network data and measurement placements. u Common Modeling Source. w One modeling application for the enterprise. w An EMS requires a model that covers any point in time. w Other targets require data for a specific “case”. u Exchange of solved cases. Several variations… w Real-time exchange among different applications. w Real-time cases to study. w Exchange of study cases between different tools. w Import of study cases to EMS. u UCTE Day-Ahead. w Study cases are generated for the next day by each TSO representing the expected state of their internal network. 3 3
Requirements Analysis u Sets of Data w Equipment. l Identifies equipment and describes basic characteristics. w Connectivity. l Describes electrical connectivity that would be input to topology processing. w Schedules. l Describes input to functions that derive parameters for a specific point in time. w Status. l The state of switches – input to topology processing. w Topology. l The result of topology processing. i. e. Description of how equipment connects into buses and how buses makeup connected systems. w Scheduled. l This is the result of time scheduling to develop input for a case. w Analogs. l The set of SCADA values for analog measurements for a particular point in time. w State. l 4 This is the set of state variables used in the mathematical formulation that the algorithms work with. 4
Requirements Analysis u In an EMS environment: 1. A modeler supplies Equipment + Connectivity + Schedules to the EMS. 2. The EMS code develops Topology + Scheduled data for the desired case. 3. Manual override of the Topology + Scheduled result is allowed. 4. Scheduled data plus local directives are used to initialize State. 5. Algorithm develops solved State. u In a planning environment, w Typical applications start with a “case”. l Equipment + Topology + Scheduled l i. e. EMS step 3. u Both environments feed the same case data (Equipment + Topology + Scheduled) into their solution applications. u Main question is how to address the different starting points. 5 5
Requirements Analysis u A standard for exchanging solved cases is required. w Receivers of solved cases often need to recreate the case input. w Since there is normally the possibility of manual override of data, cases cannot simply be recreated from 452 static model data. w This means we need to define exchange of Topology + Scheduled data as well as State. u If we need to exchange Topology + Scheduled anyway, w A family of profiles are desired such that use cases may bypass Connectivity and Schedules where that makes sense. 6 6
Static Model Exchange (61970 -452/552) Equipment + [Connectivity] + [Schedule] u The following changes should be made to the 61970 -452 profile: w Connectivity data should be optional. This includes the Connectivity. Node class and the association between Connectivity. Node and Terminal. w Schedule data should be optional. u Notes: w In state estimator usage, it is important for the Equipment model to include status and analog measurement definitions that are to be obtained from SCADA sources. u Questions: w Are bus name markers part of the optional Connectivity data? The bus name markers are static input data used as input to rules used by topology processing that create Topological. Nodes with names. 7 7
Case Input Exchange Ref(static model) + Topology + Scheduled w Note reference to a static model instance. w Includes all the data required to define a “case” (one steady-state instance) that is not already available in Equipment data. u Topology data includes: w Topological. Node objects with associations directly to Terminals. l This allows the electrical structure of the network to be understood from Equipment and Topology without any use of Connectivity. Nodes. w Topological. Node objects may have names. l Source of these names could either be manual entry or computed by topology processing based upon bus name markers and various rules. w Switches. l Only retained switches. w Topology. Nodes are grouped into Topology. Islands. l 8 Groups of connected buses that should be solved with a separated voltage angle reference. 8
Case Input Exchange u Scheduled data includes: w At generators: l MW and MW limits. l MVAR or MVAR limits. l Voltage regulation target value, deadbands, etc. w At loads: l MW, MVAR w At capacitor banks: l Continuous variable and reactive limits, or discrete reactive values. l Voltage regulation target value, deadbands, etc. w At transformer taps: l Continuous voltage tap and tap limits, or discrete tap positions. l Voltage regulation target value for voltage control, deadbands, etc. l Continuous phase angle shift and limits, or discrete tap positions. l Flow regulation target value for flow control, deadbands, etc. w At DC converters: l Control specifications. w At Topology. Islands: l Reference angle location and value. w At equipment: l Limits? w At control areas: 9 l Net interchange. l Slack specification. l Tie points. l Generator participation. 9
Case Input Exchange u Modeling approach: w Topology is already modeled and no changes are anticipated except the addition of a direct association from Terminals to Topology. Node. w For scheduled data, l l Option 1 is that Scheduled data should simply be additional attributes on existing classes. Option 2 is to create new classes dedicated to Scheduled data that would often simply have 1: 1 relationships with existing classes. u Questions: w Do we need discussion o guidance on how to manage MRID for Topological node or other created objects? Just when is a Topological. Node new? w Switch status needs to be reported – things like Contingency Analysis will need to know the status input. 10 10
Solved State Exchange Ref(case input) + State w Note reference to a case input. w Includes all the state variables. u State Variables w Topology. Node voltage and angle. w Gen injection w Load injection w Topology. Node MW, MVAR mismatch. (i. e. The amount left when you sum all the terminal flows into the bus. ) w Cap bank MVAR. (This is equivalent and interchangeable with impedance since we have the voltage. ) w Voltage tap, angle tap. w DC ? ? w Slack variable. w Terminal MW, MVAR flow. u All state variables share: w Value w Variable type (continuous, integer, status, discrete) w Limit type and limits u Notes: w The standard includes the report of mismatch/residuals at buses, which allows any condition (solved or not) to be exchanged. w Should we exchange redundant state information or limit the scope to what is needed to recompute? u Modeling Approach: w State variables have a general class with sub-classes for each type of variable. w Associations from the sub-classes to Equipment classes, Topology classes and Scheduled classes describe the specifics of each variable type. 11 11
State Variable Modeling 12 12
UCTE Case Submission – Bus Branch Model Daily Exchange: u Part One instance per day. w w u Equipment l Full model exchange format. l The same equipment model will be in effect all day. l The sending TSO is one model authority set. Initial Topology l Full model exchange format. l May change case by case. l The sending TSO is one model authority set. l X-nodes included or excluded? Part Two. One instance per case. w w w Topology l Normally null indicating no change. l Changes reported in incremental format. l TSO model authority set. Scheduled l Full model format. l TSO model authority set. State l Full model format. l TSO model authority set. l X-node model authority set. 13 X-node injections reported as mismatch. 13
UCTE Case Submission – EMS Model Daily Exchange: u Part One instance per day. w Equipment l Full model exchange format. l The same equipment model will be in effect all day. l The sending TSO is one model authority set. w Initial Connectivity l Full model exchange format. l May change case by case. l The sending TSO is one model authority set. l X-nodes in separate model authority set. w Initial Schedules 14 l Full model exchange format. l May change case by case. l The sending TSO is one model authority set. 14
UCTE Case Submission – EMS Model Daily Exchange: u Part Two. One instance per case. w Connectivity l Reported in incremental format – normally null. w Schedules l Reported in incremental format – normally null. w Topology l Reported in incremental format – normally null. l TSO model authority set. w Scheduled l Full model format. l TSO model authority set. w State l Full model format. l TSO model authority set. l X-node model authority set. 15 X-node injections reported as mismatch. 15
- Slides: 15