Power Distribution Network (Transactive)

The goal of this project is to implement a small-scale simulated model of the power distribution network representing the impact of reverse power flows and analyze and discuss their impact on the stability and operation of the distribution system and on pricing.

=Problem Definition= A first step toward implementing electricity markets at the distribution system level and incorporating prosumers as providers within the public utility system requires a real-time market auction system. The above illustrates an example of the process flow for a transactive energy system. A previous senior design team developed a distribution system model in OpenDSS, and implemented planning level studies for analyzing transactions. The next step is to build an updated model with real-time communication between the small-scale model and an auctioning system for data analyzing purposes. This way, real-time data can be obtained by the use of the RTDS. A pricing system will also be created based on the results of the small-scale model. A modular integrated real-time auction system will need to be created so that users can buy and sell power between themselves and the current power producer, as well as allow for transaction prioritization on sponsor defined variables. The designed auction must be secure, maintainable, modular, and well-documented so that features can be added, dropped, or changed at a later date.

Background
In the modern power grid, consumers are transforming into prosumers where electric power end-users could also generate their own energy from renewable resources such rooftop photovoltaic panels (PVs) or have stored energy in batteries (electric vehicle) and inject it back into the grid to sell the excess energy. This results in reverse power flows that could have an impact on the stability and the economics of the operation of the power distribution and transmission systems. The power distribution system could benefit from this local distributed generation if the adequate controls and sensing are developed.

Deliverables

 * Working 34-bus RSCAD model, and ATP IEEE 34-bus model for validation as shown above.
 * Real-time pricing system, with implemented locational marginal pricing (LMPs).
 * Visualizations of both of both the pricing system and RSCAD/ATP models.
 * Implementation of PV into RSCAD/ATP models
 * Documentation about the program and model's inner workings, as well as the team's process in creating both.
 * A description of difficulties faced while creating the above.

Specifications
Functional Requirements The final product should be able to accept real-time bid input into the system, implement a changing locational marginal pricing (LMP), and conduct transactions without error. This should be able to be accomplished by using the continuous data being collected by an SEL RTAC (real-time automation controller) that is going to distribute data to the bid system. Reliability Requirements The system should process bids and transactions without error. It should be designed to operate for a defined amount of time without maintenance.

Model Requirements The model should be built in RSCAD off of the 34-bus model. The model must be able to accept input from the auctioning system in real-time. It must be built to handle expected and unexpected line outages, as well as have constraints such as voltage regulators, low voltages, and line conductors. The model that will be used to verify the RSCAD model will be built in ATP. This will allow for the data to show statically if the RSCAD model is correct.

Software Requirements The software should be designed to function constantly without restart. The software should be designed such that a single transaction failure should not cause system failure. The auctioning system should be able to take in real-time bids. The software should be able to relay transaction information to the model, and from the model to the auctioning system.

=Design Considerations=
 * Transferring a small-scale model from OpenDSS to a real-time automated program RSCAD
 * Develop full communication between small-scale model and an auctioning system for data analysis
 * Real-time communication between the RSCAD system and the developed auction system

=Project Learning=

EE side
RSCARD/ATP Models: Early Project: Late Project:

The EE side reviewed the OpenDSS 13-bus model and learned OpenDSS by attending a conference. This allowed the EE side to start working on the RSCAD and ATP 34-bus models. We then went through learning how to model different kinds of loads as well as trying to master three different modeling programs. While working through these modeling programs, we figured out the weird quirks of the programs (such as OpenDSS's inability to do controls, how ATP can't do three-phase loads so a splitter needs to be used to be able to do so, and how RSCAD can use real-time simulations using the RTDS to be able to control the system without stalling the simulation). We also are looking into which spot and distribution loads will be replaced with solar panels (solar power) to be able to emulate AVISTA's 34-bus system better. In the updated ATP model, three lookup tables have been added, one for each phase, to model an irradiance curve in the form of a Gaussian distribution, pictured above. Each phase of the irradiance curve is added up to total 100kW, which is the size of the PV load. This is then converted into a DC current, which is found by dividing the power by the maximum DC voltage of 600V. Using a shunt capacitor and a series resistor pictured above, the DC current is injected into a bus of the system.

Using SAM (System Advisory Model), which is a program created by NREL that pings the nearest weather station for data at a given location that you enter in, it gives you irradiance information in the form of 8760 data. The data collected for Spokane, chosen to represent Avista's service area is shown above. This data will be normalized to represent four days that for each seasonal load for Spokane: spring, summer, fall, and winter.

CS side
The CS side of the project first began work on the system flow and pricing tool portion of the project by visualizing the problem as a variant of the famous Knapsack problem. While working to develop this tool, several steps were made. The team came up with a comparison of various implementations of the Knapsack Problem, including a brute force, dynamic programming, and evolutionary computation method. The group found that the dynamic method was by far the fastest implementation with a very fast run time, whereas the evolutionary method had an execution time on the same order of magnitude, and used less memory--so it is perhaps more scalable for larger systems. A large portion of time was also spent developing a parser for the output OpenDSS consumer and bus information files. This implementation was done in Python, originally in a Pythonic-list-comprehension method and later transferred into a regular expression implementation method to allow for a more moddable workflow. The parser created graphs using NetworkX, a Python library for graph theory, and originally separated the phases of the network into three separate graphs. Per a suggestion from our client, this idea was discarded in favor of a single multigraph due to it being a closer representation of the overall system. This too caused issues due to the fact that the NetworkX library does not have a method to print multigraphs with separate lines. A solution was attempted to be created by hand by changing the ordering within the nodes libraries dictionaries, by adding the nodes in certain orders, and by exporting the graphs to .DOT files to be graphed in a different Python library called PyDot.

At this point, the CS side transitioned from a Knapsack Problem visualization of the network to a Min Cut/Max Flow visualization, as it was suggested to be a more applicable solution type for the goals required. This implementation also required a great deal of change, because the normal solution to the multi-source multi-sink Min Cut/Max Flow problem creates infinite capacity lines between a single imaginary source and sink and the various real ones to transfer a difficult problem to a more tractable one. This, however, does not match the reality of the situation, because this would consider the problem constraints satisfied as long as the correct overall amount of power was transferred to any subset of the consumers, instead of the right amount to each. Therefore, it was decided that the client would be approaching the problem as though it were a multi commodity network flow problem.

Currently, the CS side of the team is pursuing visualization of the problem. The parser that was previously used was rebuilt to handle output from the EE models, including a node filtering mechanism. Support is being added for coordinate input as well as Sphinx documentation.

=Final Design= RSCAD Figure 14 Figure 16 Figure 17 Figure 21 Figure 22 ATP Slide 10 Slide 14 Slide 17 Slide 23 Python Program

=Future Work= The next steps for the project will involve validating the ATP and RSCAD models by using the OpenDSS 34-Bus model’s data as well as running the RSCAD model with the RTDS to match the results of the ATP model. Then, communication between the RSCAD model and an automation controller needs to be established with real-time communication between the RSCAD model and an auctioning system for data analyzing purposes. This way, real-time data can be obtained by the use of the RTDS.

One of the next steps in the program is coordinate-based graphing. If coordinates of nodes could be specified, then it would be easy to switch between different visualizations (such as switching between graph theory, real-world coordinates, and an electrical engineering format). This would make communication between teams composed of people with different backgrounds to all be able to understand the information in the format with which they are most familiar.

A useful change that was beyond the scope of this class would be to implement images that can be scrolled into dynamically. This would drastically reduce the number of issues our graph visualization has with readability without compromising on what is visible in the graph as a whole.

The current comparison of the two node sets in the comparison function tests simple equality (if a bus exists in both sets and if its variables such as power and voltage are the same). A feature that would be relatively simple to implement would be to test whether values associated with buses are within a certain distance of each other (have similar powers or voltages). Because we did not know the specifics of real-world numbers, or what would be most useful to compare, we did not implement this behavior. However, it would be straightforward for this to be developed in the future.

Please refer to the project paper for further ideas on the project's direction in following semesters.

=Conclusion= This semester, we successfully:
 * Completed the IEEE 34-Bus model in both RSCAD and ATPdraw with PV implementation
 * Developed toolset to parse, organize, and analyze grid data in an extensible structure
 * Helped Avista explore the physical and economic feasibility of participating in a transactive energy network for their business mode

=Validation= While this plan was drawn up to meet project requirements, the team opted to use the EE standard for project validation. While the above are example tests, the project was actually implemented under a far greater number of small tests, in which a successful compilation was required before moving to the following one. The GOOSE protocol implementation was not completed due to the shutdown of campus due to COVID-19.

=Schedule=

Fall Semester:
October November December
 * 10/08 - Project Schedule (All)
 * 10/15 - Snapshot Day #1 (All)
 * 10/16 - Logbook and Portfolio Review (All) - Hussain will be gone at conference
 * 10/24 - Design Validation Plan (All)
 * 10/25 - Literature Review (All)
 * 10/31 - Project Value Proposition (All)
 * 10/31 - Code Setup and Graphs with consumers (CS)
 * 10/31 - ATP model draft (EE)
 * 10/31 - RSCAD model draft (EE)
 * 11/07 - Draft Wikipage (All) (1-2 weeks)
 * 11/14 - Logbook and Portfolio Review (All)
 * 11/22 - Concept Design Review (All)
 * 11/22 - Team Member Citizenship (All)
 * 11/22 - Test and compare ATP/RSCAD models for validation (EE)
 * 11/24 - Add Producers/Sinks into graph (CS)
 * 12/06 - Snapshot Day #2 (All)
 * 12/13 - Portfolio, Wikipage, Logbook Review (All)

Spring Semester:
Spring Semester: January February March April May
 * 01/24 - ATP controls draft (EE)
 * 01/24 - RSCAD controls draft (EE)
 * 01/24 - Have working min cut/max flow solution allowing for line removal (CS)
 * 01/28 - Design Expo Registration (All)
 * 01/28 - Test design--many transactions, conflicting transactions, stress testing (CS)
 * 02/10 - File Reading (CS)
 * 02/21 - Engineering Release Review (All)
 * 02/21 - Logbook Review (All)
 * 02/28 - ATP testing (EE)
 * 03/09 - Algorithm Implemented (CS)
 * 03/10 - Snapshot Day #3 (All)
 * 03/10 - Portfolio, Wikipage, Team Member Citizenship (All)
 * 03/10 - PV Implementation in RSCAD & ATP (EE)
 * 03/30 - CAL ISO data integrated (CS)
 * 03/27 - RSCAD auctioning system testing (All)
 * 04/06 - Graphical Output (CS)
 * 04/17 - Logbook Review (All)
 * 04/17 - Real-time data collection (All)
 * 04/24 - Demonstration testing (All)
 * 04/27-30 - EXPO preparation (All)
 * 05/01 - EXPO
 * 05/08 - Final Course Deliverables Due (Final hardware/software, Design report/project portfolio, Wikipage, Project Poster, Work Area Check-Out, Electronic Archive/File Management)

=Team Members=

=Additional Documentation=

Project Schedule Meeting Minutes Snapshot 1 Snapshot 2 Design Review Meeting Agendas Budget Value Proposition Product Requirements Project Proposal Design Validation Plan