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 34-bus model for validation.
 * 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. [I'LL SEND YOU A PIC OF THE GAUSSIAN]. 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, [I CAN ALSO SEND YOU PICS OF THESE] 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 here [ABOVE OR BELOW ETC]. 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.

=Final Design=

=Validation=

=Schedule=

Fall Semester:
October November December
 * 10/08 - Project Schedule (All)
 * 10/15 - Snapshot Day #1 (All)
 * 10/16 - Logbook and Portfolio Review (All)
 * 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:
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/14 - GOOSE protocol implementation (EE)
 * 02/21 - Interface GOOSE protocol with RTAC (EE)
 * 02/21 - Engineering Release Review (All)
 * 02/21 - Logbook Review (All)
 * 02/28 - ATP testing (EE)
 * 02/28 - Further Communication work (CS)
 * 03/08 - Handle changing EE requirements--changes to real time buffer (CS) (1-2 weeks)
 * 03/10 - Snapshot Day #3 (All)
 * 03/10 - Portfolio, Wikipage, Team Member Citizenship (All)
 * 03/13 - RSCAD testing (EE)
 * 03/13 - ATP auctioning system testing (All)
 * 03/27 - RSCAD auctioning system testing (All)
 * 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 (All)
 * 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