CIM Distribution Grid Applications

small electric distribution network schematic

CIM Distribution Grid Applications

Derrick Oswald

ESC - overview

S - speaker notes

Distribution Networks

CIM

CIM Model

Types of Information

Electrical

                    
…
<cim:SwitchInfo rdf:ID="ART4179"> <!-- electrical characteristics -->
    <cim:IdentifiedObject.name>8DJH 24kV</cim:IdentifiedObject.name>
    <cim:IdentifiedObject.aliasName>810:el_int_switch_art</cim:IdentifiedObject.aliasName>
    <cim:IdentifiedObject.description>Gas-Insulated Medium-Voltage Switchgear</cim:IdentifiedObject.description>
    <cim:SwitchInfo.ratedVoltage>24000.0000</cim:SwitchInfo.ratedVoltage>
</cim:SwitchInfo>
<cim:Switch rdf:ID="TEI127390">
    <cim:IdentifiedObject.name>8DJH 24kV</cim:IdentifiedObject.name>
    <cim:IdentifiedObject.aliasName>276857882:el_int_switch</cim:IdentifiedObject.aliasName>
    <cim:IdentifiedObject.description>Switch</cim:IdentifiedObject.description>
    <cim:ConductingEquipment.BaseVoltage rdf:resource="#BaseVoltage_16000"/> <!-- voltage -->
    <cim:PowerSystemResource.Location rdf:resource="#_location_1621079552_427087358_276857884"/>
    <cim:PowerSystemResource.PSRType rdf:resource="#PSRType_Substation"/>
    <cim:PowerSystemResource.AssetDatasheet rdf:resource="#ART4179"/> <!-- info reference -->
    <cim:Equipment.EquipmentContainer rdf:resource="#FEL215886"/>
    <cim:Switch.normalOpen>false</cim:Switch.normalOpen> <!-- state -->
</cim:Switch>
…

Spatial

                    
…
<cim:Location rdf:ID="_location_1621079552_427087358_276857884"> <!-- spatial location -->
    <cim:Location.CoordinateSystem rdf:resource="#pseudo_wgs84"/>
    <cim:Location.type>geographic</cim:Location.type>
</cim:Location>
<cim:PositionPoint rdf:ID="_location_1621079552_427087358_276857884_p"> <!-- point location -->
    <cim:PositionPoint.Location rdf:resource="#_location_1621079552_427087358_276857884"/>
    <cim:PositionPoint.sequenceNumber>0</cim:PositionPoint.sequenceNumber>
    <cim:PositionPoint.xPosition>7.22933091967</cim:PositionPoint.xPosition>
    <cim:PositionPoint.yPosition>47.1121810794</cim:PositionPoint.yPosition>
</cim:PositionPoint>
<cim:Switch rdf:ID="TEI127390">
    <cim:IdentifiedObject.name>8DJH 24kV</cim:IdentifiedObject.name>
    <cim:IdentifiedObject.aliasName>276857882:el_int_switch</cim:IdentifiedObject.aliasName>
    <cim:IdentifiedObject.description>Switch</cim:IdentifiedObject.description>
    <cim:ConductingEquipment.BaseVoltage rdf:resource="#BaseVoltage_16000"/>
    <cim:PowerSystemResource.Location rdf:resource="#_location_1621079552_427087358_276857884"/>  <!-- reference -->
    <cim:Switch.normalOpen>false</cim:Switch.normalOpen>
…

Topology

                    
…
<cim:Terminal rdf:ID="TEI127390_terminal_1">
    <cim:IdentifiedObject.name>TEI127390_terminal_1</cim:IdentifiedObject.name>
    <cim:ACDCTerminal.sequenceNumber>1</cim:ACDCTerminal.sequenceNumber>
    <cim:Terminal.phases rdf:resource="http://iec.ch/TC57/2016/CIM-schema-cim17#PhaseCode.ABC"/>
    <cim:Terminal.ConnectivityNode rdf:resource="#PIN518369_node"/> <!-- connectivity reference -->
    <cim:Terminal.ConductingEquipment rdf:resource="#TEI127390"/> <!-- equipment reference -->
</cim:Terminal>
…
<cim:ConnectivityNode rdf:ID="PIN518369_node"> <!-- connection -->
    <cim:IdentifiedObject.name>PIN518369</cim:IdentifiedObject.name>
    <cim:IdentifiedObject.aliasName>276857893:el_int_pin</cim:IdentifiedObject.aliasName>
    <cim:IdentifiedObject.description>TEI127390 pin 2</cim:IdentifiedObject.description>
    <cim:ConnectivityNode.ConnectivityNodeContainer rdf:resource="#STA212"/>
</cim:ConnectivityNode>
…
<cim:Terminal rdf:ID="REF201114_terminal_1"> <!-- connection -->
    <cim:IdentifiedObject.name>REF201114_terminal_1</cim:IdentifiedObject.name>
    <cim:ACDCTerminal.sequenceNumber>1</cim:ACDCTerminal.sequenceNumber>
    <cim:Terminal.phases rdf:resource="http://iec.ch/TC57/2016/CIM-schema-cim17#PhaseCode.ABC"/>
    <cim:Terminal.ConnectivityNode rdf:resource="#PIN518369_node"/> <!-- connectivity reference -->
    <cim:Terminal.ConductingEquipment rdf:resource="#REF201114"/> <!-- equipment reference -->
</cim:Terminal>
…

Asset

                    
…
<cim:LifecycleDate rdf:ID=TEI127390_lifecycle"> <!-- lifecycle -->
    <cim:LifecycleDate.installationDate>2001</cim:LifecycleDate.installationDate>
</cim:LifecycleDate>
<cim:Asset rdf:ID="TEI127390_asset">
    <cim:IdentifiedObject.name>TEI127390</cim:IdentifiedObject.name>
    <cim:IdentifiedObject.aliasName>276857882:el_int_switch</cim:IdentifiedObject.aliasName>
    <cim:IdentifiedObject.description>Line Switch</cim:IdentifiedObject.description>
    <cim:Asset.type>8DJH 24kV</cim:Asset.type>
    <cim:Asset.lifecycleDate rdf:resource="#TEI127390_lifecycle"/> <!-- lifecycle reference -->
    <cim:Asset.Location rdf:resource="#_location_1621079552_427087358_276857884"/>
    <cim:Asset.PowerSystemResources rdf:resource="#TEI127390"/> <!-- equipment reference -->
</cim:Asset>
…

Spark

Turning now from data to applications... Apache Spark is software that is normally - executed on a cluster - usually using Hadoop, - and usually in a cloud environment, such as Amazon Web Services (AWS), Microsoft Azure or Google Cloud. Out of the box, Spark provides some interactive command line interpreters for Scala, Python and R, which can be run from a secure shell. Graphical user interfaces to Spark in a browser such as RStudio, Zeppelin, Jupiter, etc. must be installed separately. The Spark API is available for Scala, Python and R, and of course for Java, which it all comes down to in the end. For batch oriented use-cases, the spark-submit command is usually executed on the master node, by specifying a custom Java jar file and a command line.

Software Stack

HDFS

RDD

The primary data structure in Spark is the Resilient Distributed Dataset or RDD. Conceptually, it is a array or list of objects, usually Plain Old Java Objects, or PoJos, that exist in sets called partitions. Partitions are distributed within executors, and over the executors of the cluster on different machines. Each RDD is immutable, which facilitates parallelizing operations. The RDD API is primarily higher-order functions, that is, functions that take functions as parameters. In the example, the sequence of filter, map, and fold computes the sum of the distances associated with names starting with a 'B', over all partitions to get the scalar answer 'd'. RDD resiliency comes from remembering the sequence of performed operations as a recipe, that can be replayed as needed to recreate one immutable RDD from its immutable precursors - this is why immutability is important, if the data had changed this would not be possible. If memory becomes exhausted, RDDs are discarded, keeping only their recipe, and they can be rebuilt as needed. Caching, or persisting, an RDD locks that RDD in memory. In that case, if memory becomes exhausted, the cached RDDs can spill to disk as serialized objects, and then be re-hydrated when required.

Pair RDD

Transformations and Actions

All these Spark methods fall into two categories, transformations and actions. Transformations are local operations, where executors can operate independently, requiring no interaction with other executors. Evaluation of these is lazy, that is, it's done only when necessary. Mostly, these are in-memory operations, and hence quite fast - on the order of nano-seconds. These include map, filter and union. Actions are, conversely, non-local operations, where results need a cluster-wide consensus. Evaluation is eager - that is, they're done immediately upon being encountered in the recipe - so that other executors are not held up waiting for a lazy evaluation. These usually involve network traffic, called a shuffle, and hence are quite slow - on the order of micro-seconds. These include count, collect and fold. A lot of the tuning and optimization for Spark, involves eliminating these shuffle operations, either through different algorithms, different data structures or reordering operations for parallelization.

CIMReader

Class Hierarchy

The CIMReader generates a globally named RDD per CIM class. There are over 1500 such classes, but only those found in the CIM file are created. It also exposes these RDD as SQL Datasets for Spark SQL’s optimized execution engine called Catalyst. Each CIM subclass has its parent class encapsulated in it, somewhat like Russian dolls. In the example shown here, the Conducting Equipment superclass is embedded in class Switch, both of which are in a named RDD. This works up and down the hierarchy, so, one can access all switches, independent of whether they are Breaker, Disconnector, or Fuse subclasses by accessing the Switch RDD. These RDD are cached, so the CIM file reading only occurs once.

Architecture

GraphX & Pregel

An extremely useful API is provided by GraphX. As its name implies, it can construct a graph of edges and vertices of a network, which can then be operated on by the Pregel algorithm. The distributed Pregel algorithm, in higher-order functional form, takes three functions: - a vertex updating function - to handle incoming messages to a vertex, - a message generating function - propagate messages across edges, - and a message merging function - to combine messages to the same vertex The algorithm basically consists of sending an initial message to every vertex, then iterating over these three functions until there are no new messages generated.

Topological Processing

An example of Pregel processing is the network topology processor identifying topological nodes, that is, nodes at the same electric potential. In this case the vertex data and message are simply a node id, which is the hashCode of the element mRID - the primary key in CIM. The vertex program handles the incoming message by keeping the minimum vertex id. The send message program sends a message to any vertex with a greater vertex id, but only if they are topologically connected, either with a zero impedance cable or a closed switch. The merge message program, like the vertex program, keeps the minimum vertex id. When the algorithm terminates, each vertex is labeled with the minimum vertex id of all topologically connected vertices, which is used as a unique identifier for a topological node of all the connected nodes. The program then updates the TopologicalNode RDD and the Terminal RDD and all superclasses. Topological island processing is the same, except all cables are considered zero impedance, and the TopologicalIsland RDD is the one that's updated.

GridLAB-D

Where non-linear effects must be considered, as is the case in most network analysis, a load-flow or power-flow numerical analysis must be performed. Programs that do this solve large sparse matrix equations of the Thevenin or Norton equivalent circuit for a network, and provide values or time-series for the variables in these equations, such as cable current and node voltage. Of the many programs considered, GridLAB-D was chosen because - it is platform neutral, running on linux as well as Windows and OSX - it needs no licence, allowing clusters to be expanded as needed - it is open source, so there is the possibility of fixing show-stopper bugs, although one must know C/C++ to do that The nomenclature used by GridLAB-D includes: - glm - a file containing the network nodes, edges and configurations - configuration - a model of a transformer or cable - player - a Comma Separated Value (CSV) file of a boundary condition, essentially a time-series driving function for a variable - recorder - an output CSV file of the observed values of a variable such as: power, voltage, current, phase angle etc. - swing bus - infinite source or sink, a hard and fast pinning of a supply variable, a built in boundary condition When the program is invoked it reads in the glm model and the player files, and produces recorder files for requested variables.

Load Flow

Since the entire network is too large to solve all at once, the problem is partitioned into transformer service areas and these are solved individually. Essentially, complete GridLAB-D packages for each topological island are exported to the Hadoop Distributed File System, and then these are solved in parallel. The RDD pipe method is used, which basically bales out to the operating system to execute a script for each element of an RDD, in ths case the names of the transformer service areas. This is where the distributed parallel multi-threaded world of Spark boils down to the single-core, single-threaded isolated world of GridLAB-D. Since GridLAB-D knows nothing about Spark and HDFS, the script first copies the .glm and player files from HDFS to local disk, executes the gridlabd program and then copies the recorder files back to HDFS. The recorder files are then slurped into Spark, with the out-of-the-box CSV reader, producing RDD of the recorder time series double or complex values.

Short Circuit

The Short Circuit problem is to determine, in the case of a hypothetical short circuit at each consumer node, what the short circuit current under worst case conditions is. There are two worst case conditions of interest corresponding to low and high temperature. The low temperature condition has the least cable resistance and hence highest current, which is used to determine fuse over-current timing, locked-rotor motor starting currents, etc. The high temperature condition has the greatest cable resistance and hence lowest current. With rated currents of all the fuses and breakers along the supply path, one can determine whether: - any fuse or breaker is tripped, - or, the happy path, where the most specific fuse or breaker is tripped, - or if an upstream fuse or breaker trips interrupting service to too many customers.

Network Parameters

medium voltage network equivalent circuit

Short Circuit Pregel

Short Circuit Load Flow

Short circuit calculation with load flow

Maximum Feed In

The Maximum Feed In problem is to determine the maximum power for a hypothetical new solar installation, at each consumer node in the network, given the already existing or proposed PV installations, and under the assumption that no network reinforcement is performed. That means finding the maximum PV power that doesn't exceed the transformer power rating, cable current ratings along the path from the transformer to the node, or voltage tolerance limits for nodes in the transformer service area. You can see this value for your connection under https://account.bkw.ch/services Verteilnetz Netzanschluss.

Maximum Feed In Pregel

If there are no other power sources, that is, no other photo-voltaic (PV) installations, and the network is purely radial, the problem is a linear problem that can be solved with GraphX and Pregel. So, ignoring any installed PV, basically label each customer location with the total line impedance from the supplying transformer, and the minimum cable ampacity encountered along the path. Then, knowing the transformer characteristic, it becomes an Ohm's law calculation to determine what power level input would lead to: - excessive voltage - excessive current - or excessive transformer power If there really are no existing PV, and it's a radial network, we're done. Otherwise, this computed value is used as a best-case input to the next step, which is loadflow simulation.

Maximum Feed In Load Flow

Each transformer service area is exported and simulated separately using GridLAB-D. It is assumed that existing PV are operating at maximum capacity. To save time, the experiments for each house in a transformer service area are time multiplexed into one gridlabd execution - the first house is analyzed in the first five minutes of simulation, the second house in the next five, and so on. At each house, during its experiment, a stepped (negative) load is applied in the player file, and otherwise the player is zero as shown in the upper graph. Steps occur at regular intervals, with the number of steps determined by the best-case value from the precalculation done earlier with GraphX. The recorder files from gridlabd which are: - the time series of node voltages for each customer location - the time series of the current in each cable - the time series of power through the transformer are time-demultiplexed out of the five minute windows and then analyzed for the same excessive limits as in the precalculation. By knowing the time at which an excess occurs, the step - and hence the power - that caused it can be computed. To save time and increase the resolution, the simulation is actually done in two phases, one of ten thousand Watts per step and then a finer granularity phase of one thousand Watts per step.

Simulation

The simulation problem is to determine node voltages, cable currents and transformer powers for all elements of the network given smart meter readings from energy consumer meters. From these values, excessive conditions can be identified and summarized. Basically a GridLAB-D model file (a .glm file) is generated for each topological island. Player files (which can be considered initial conditions for each simulation interval) are created from the Cassandra smart meter records. GridLAB-D is invoked to perform load-flow analysis with the given .glm file, reading in the player files and producing recorder files as output. Any power factor (cosφ) is inherent in the complex player and recorder values.

Ingest

Smart meter data extract, transform, load to Cassandra

Smart meter data is collected from customer meters, through the concentrators, into the head-end-system. The Ingest program performs the extract, transform, load (ETL) to move it to Cassandra The head-end system generates (near) CSV files, one row per day – where the difference is at daylight savings time changes, where twice a year there are four more or less readings in a day. The system normally provides apparent power – because it's based on billing system requirements – but sometimes active and reactive power are available. Currently, readings are captured at 15 minute intervals approximately 300MB per year per substation. The ingest phase demultiplexes the daily reading records, and joins them to a CIM EnergyConsumer mRID via a mapping table which maps one or more Meter ID values, (which for Switzerland are CH#####) to a CIM mRID - the primary key. Records are summed over multiple meters at one mRID, and stored as one Cassandra row per 15 minute reading per EnergyConsumer. These are aggregated into hourly, three hour, and daily values, to be used for quicker client side access when drilling down from overview to specific measurements.

Generate Players

• identify loads using Spark query for EnergyConsumer

• query Cassandra to create “player” files (CSV) for loads from smart meter data

• conversion from energy ⇒ power (×4)

• back shift one 15 minute period

• output time stamp and complex value at 15 minute intervals

• time-series duration based on CIM cadence

To generate player files, we first query the CIM data using Spark SQL to find the mRID of EnergyConsumers and the topological node they are associated with. Then we query Cassandra by mRID for each consumer's meter data, to create “player” files in CSV format for each customer load. The readings are converted from energy to power (basically multiplying by four to go from Watt-Hours per fifteen minutes to Watts), They are also back shifted in time, because the meter reading is taken at the end of the 15 minute period, and we require the value at the beginning of the period. The span of the player time-series corresponds to the cadence of CIM file generation - one month.

Player Query

Spark SQL Query
select
    c.ConductingEquipment.Equipment.PowerSystemResource.IdentifiedObject.mRID mrid,
    'energy' type,
    concat(c.ConductingEquipment.Equipment.PowerSystemResource.IdentifiedObject.mRID, '_load') name,
    t.TopologicalNode parent,
    'constant_power' property,
    'Watt' unit,
    n.TopologicalIsland island
from
    EnergyConsumer c,
    Terminal t,
    TopologicalNode n
where
    c.ConductingEquipment.Equipment.PowerSystemResource.PSRType == 'PSRType_HouseService' and
    c.ConductingEquipment.Equipment.PowerSystemResource.IdentifiedObject.mRID = t.ConductingEquipment and
    t.TopologicalNode = n.IdentifiedObject.mRID

Query Result Fragment
mrid   type   name        parent          property       unit island
HAS160 energy HAS160_load HAS160_topo     constant_power Watt TRA173_terminal_2_island
HAS166 energy HAS166_load HAS166_topo     constant_power Watt TRA161_TRA162_terminal_2_island
HAS23  energy HAS23_load  HAS23_topo      constant_power Watt TRA161_TRA162_terminal_2_island
HAS49  energy HAS49_load  HAS49_fuse_topo constant_power Watt TRA153_terminal_2_island
…

GridLAB-D .glm Fragment
…
object load {
    name "HAS160_load_object";
    parent "HAS160_topo";
    phases AN;
    nominal_voltage 400.0V; };
object player {
    name "HAS160_load";
    parent "HAS160_load_object";
    property "constant_power_A";
    file "input_data/HAS160_load.csv"; };
…

Recorders

• Spark queries for “recorder” files for:

· PowerTransformer (N7) apparent power (VA)

· PowerTransformer (N7) current (A)

· BusbarSection (container PSRType_DistributionBox) voltage (V)

· BusbarSection (container PSRType_DistributionBox) apparent power (VA)

· EnergyConsumer (house service) voltage (V)

· EnergyConsumer (house service) apparent power (VA)

· ACLineSegment (N7) current (A)

• after simulation, read recorders, insert into Cassandra

• aggregate over 1, 3 and 24 hours

• time-to-live, 15 minute values “live” a year, daily values forever

Spark queries are also used to add “recorder” file specifications for: apparent power and current of PowerTransformers busbar apparent power and voltages energy consumer apparent power and voltages and cable currents GridLAB-D generates a CSV format file for each output recorder. All CSV files are read into Spark, with 15 minute interval values. The records are tagged with the mRID and units based on the CSV filename. Aggregations are performed over 1, 3 and 24 hours. The records are inserted in bulk into Cassandra. Disk size is proportional to number of elements and duration of the simulation. An average size transformer service area for one month is about 500 million records. When stored in Cassandra it consumes approximately 30MB of disk space. Currently the bottleneck is insertions per second per Cassandra node. Cassandra's “time-to-live” feature is used to age-out the detailed results over time, leaving only the aggregate values.

Recorder Query

Spark SQL Query
select
    concat (p.ConductingEquipment.Equipment.PowerSystemResource.IdentifiedObject.mRID, '_power_recorder') name,
    p.ConductingEquipment.Equipment.PowerSystemResource.IdentifiedObject.mRID mrid,
    p.ConductingEquipment.Equipment.PowerSystemResource.IdentifiedObject.mRID parent,
    'power' type,
    'power_out' property,
    'VA' unit,
    n.TopologicalIsland island
from
    PowerTransformer p,
    Terminal t,
    TopologicalNode n
where
    t.ConductingEquipment = p.ConductingEquipment.Equipment.PowerSystemResource.IdentifiedObject.mRID and
    t.ACDCTerminal.sequenceNumber > 1 and
    t.TopologicalNode = n.IdentifiedObject.mRID

Query Result Fragment
name                  mrid   parent        type  property  unit island
TRA168_power_recorder TRA168 TRA168_TRA169 power power_out VA   TRA168_TRA169_terminal_2_island
TRA180_power_recorder TRA180 TRA180        power power_out VA   TRA180_terminal_2_island
…

GridLAB-D .glm Fragment
…
object transformer {
    name "TRA168_TRA169";
    phases AN;
    from "MUI4786_topo";
    to "PIN2448_topo";
    configuration "_1260kVA16000$400V590e-5+396e-4jΩ"; };
object recorder {
    name "TRA168_power_recorder";
    parent "TRA168_TRA169";
    property "power_out_A";
    interval "900";
    file "output_data/TRA168_power_recorder.csv"; };
…

Postprocessing

• events are business rules for “problem” conditions

• include a severity for color coding at the client

• node voltage deviations ±6% at any time, severity 1

• node voltage deviations ±10% at any time, severity 2

• edge current exceeding 75% for 14 consecutive hours, severity 1

• edge current exceeding 90% for 3 consecutive hours, severity 2

• edge current exceeding 110% at any time, severity 2

• transformer power exceeding 75% for 14 consecutive hours, severity 1

• transformer power exceeding 90% for 3 consecutive hours, severity 2

• transformer power exceeding 110% at any time, severity 2

• save events in Cassandra tagged by transformer service area

• coincidence/diversity factor, load factor, responsibility factor

Summary

• short circuit analysis

• maximum photo-voltaic feed in limits

• out of limit conditions over time

derrick.oswald@9code.ch

https://github.com/derrickoswald/CIMSpark

https://github.com/derrickoswald/CIMApplication