University of Northern Iowa Electric Distribution Modeling: Final Document

Group#: May14-33 Client: University of Northern Iowa Advisor: Professor Colin Christy
Members: Justin Craig John Hanke Chris Hankey Darin Lamos

Table of Contents
Section 1: Roles and Responsibilities..3 Section 2: Problem Statement.3 Section 3: System Description4 Section 4: Operating Environment.4 Section 5: Functional Requirements.4 Section 6: Non-functional Requirements.5 Section 7: Engineering Study..5 Section 8: Timeline.6 Section 9: Design Process...6-7 Appendix 1: Operation Manual8-15 Appendix 2: Alternative Designs16-19 Appendix 3: What We Learned from the Process..20

Section 1: Roles and Responsibilities

Justin Craig - Chief Executive Officer - As the CEO, Justin was in charge of making sure the team is always on the same page. Some of his roles included organizing group meetings, updating Faculty Advisor, evaluating progress and updating team timeline.

Chris Hankey - Chief Information Officer - As the CIO, Chris was in charge of researching and leading the team through all of the software design and setup for the group. He was also in charge of preventing miscellaneous computer related issues.

Darin Lamos - Chief Operating Officer - As the COO, Darin was in charge of all group communications. Darin was in charge of client relations and making sure that our client was constantly updated and in-the-loop with weekly decision and progress.

John Hanke - Chief Technical Officer - As the CTO, John was in charge of interactions with ETAP. He was our connection to ETAP and was in constant contact with their sales engineer and their software support team.

Section 2: Problem Statement

The University of Northern Iowa does not have the ability to realize their medium voltage distribution system. They currently use an old notebook in a toolbox to keep track of the systems current state. Our goal, was to develop electronic alternatives for University of Northern Iowas Facilities Department to choose from, then use that choice to model the distribution system. This program needs to be streamlined and user friendly.

Section 3: System description The user will start by entering a username and password into the University of Northern Iowas system. The system needs to be easily understandable. The system will be made up of the Universitys medium voltage distribution system. It will be easy to realize the condition of all the switches. Another component will be the ability to visually identify all five of the distribution systems, and their interconnections between them. The overall model will have a scenario manager feature that will allow for the ability to manipulate the circuits for the purpose of load transfer studies and possible future upgrades to the system.

4. Operating environment

Our project will be developed with ETAP software on a local machine that utilizes a hardware key that issues the license required to use the software. After completing the design files of their system, we will install the software to one of their windows environment machines. We can then transfer over the files that we design. No physical measurements of their system need to be used in our implementation of the design.

5. Functional requirements

1. 2. 3. 4. 5. 6. 7. 8.

Clearly be able to identify each individual circuit Be able to recognize individual switches within each circuit The condition of the switches is obvious to the user Power flow calculations must be accurate for simulation Ability to manipulate circuits, for the purpose of load transfer modeling Operational manual for clients ETAP applications Scenario manager to run simulations for potential circuits Real-life switch conditions is separate from scenario power flow circuits

6. Nonfunctional requirements

1. 2. 3. 4. 5. 6. 7.

Client needs to easily understand graphics from the software design New updates for the software should be easy to perform Training manual for new employees that will need to work with interface All different circuit branches need to be distinguished The system must be secure enough to pass their security requirements Simply navigation from real conditions to what if conditions Program is simple and can be easily understood by non-engineers

7. Engineering Study At the start of the project we had two options suitable for a solution. Developing the program had the positives of being built custom for the client, at low cost, and gave us the ability to integrate their metering data to the software. A negative of this approach, is no continued support after we graduate. The other option was utilizing commercial software. The positives for using commercial software are well tested software and tech support offered by a company. The negatives are a cost for the software and functions less specific to a client. Commercial software was more attractive to our client because of the continued support available to them. The development environments that we looked at were; Microsoft Visual Studio, NetBeans, and Adobe Flex SDK. Commercial software we investigated were ETAP, Power World and SKM for our commercial software. We choose ETAP based on the flexibility in the program. Power World is intended for high level, robust, electrical grids which is beyond the scope of our project. SKM is a power flow program with multiple study capabilities. A downside to SKM is the fact we have to purchase all of the software. Whereas with ETAP, we have the ability to purchase specific modules of the software. The client decided at the end of the study that they were going to purchase the basic ETAP package for their application. The decision was based on ETAPs flexibility, the ability to add more modules if needed, colleague in Iowa State University Facilities Department uses ETAP, and the continued support after graduation.

8. Time Line Project Schedule - Fall Semester September 23rd - Project scope is due September 27th Initial website drafted October 4th - Project plan is due November 2nd Presentation parallel options rough draft November 6th - Presentation to UNI, client decision on parallel option December 9th - Start of dead week December 16th - Finals week

Project Schedule - Spring Semester January 13th - Spring semester starts March 17-23 - Spring break March 28th - Design is nearing completion April 27th - Finishing touches on the design and have user documents done. May 1st - Present program to UNI

9. Design Process The process we followed was to create the functional and nonfunctional requirements with our client. Then we decided to pursue two parallel development paths, instead of devoting all of our attention on one idea. We researched different software, both commercial power software and development platforms to find the best possible solution for the client. We then presented our findings to UNI for them to make the decision for which idea they wanted us to continue. We then spent the spring semester developing the final product.

Design Process:

Appendix I: Operation Manual

Beginners guide to ETAP:

For the University of Northern Iowa Facilities Department

 Opening the Program

Double click on the ETAP icon on your desktop. After a few seconds, the program will load and you will see a screen similar to the one below:

Click on either the open button in the top left corner, or follow the path File -> Open to select the proper file. You will be looking for UNI Medium Voltage Diagram.

Double click on the file or click open. Once this is done, you will see two more pop -up windows.

For this step, all the information should be correct. Hit ok and move to the next window. In the next window, instead of seeing Chris Hankey you will see UNI Facilities. Hit OK.

10

At this point, you should see something like this.

Working with the Software

Here is an explanation of the different buttons on the ETAP interface.

1. Editor view: You need to be in this view in order to change the switch states or to add any components 2. Power Flow view: Larger License required for this view 3. Open File: This gives a different path to open a file.

11

The below image can be seen in Editor View on the right side of the window. It contains all of the necessary elements for a one-line diagram.

1 2

4 5 6 7

1. 2. 3. 4. 5. 6. 7. 8.

Add Bus: If a new switch is added to your system, a bus is required to model it. Add Transformer Add Underground Cable Add Generator Add Photovoltaic Add Motor Add Load Add circuit elements: includes switches, breakers, fuses, etc. 12

1. One-Line Diagram: Click this button to view the one-line diagram view. 2. Recycle Bin: During an editing session if you delete an item, it will still exist in the recycle bin. In order to create an item with same name, you need to delete it from the recycle bin first.

13

 Switches
To model the switches for the system, you have to build them using a bus and single throw switches. An example can be seen below.
Bus

Switch

To name the switches or to set them open and closed, double click on the switch. You will get a window that should look like this.

14

Name

Set State

The switch on the one-line will show if it is open or closed as well.

15

Appendix II: Alternative Designs With our project, there were multiple approaches to the problem that could potentially fulfill the requirements. As such, we came up with some alternative designs that did not make the cut into the final development. To start, we had two major routes that could be taken to complete the project. One involves creating our own software that would be specialized in modeling their system. The other route, which we ended up using in the final design, was to utilize commercial software to model the system. There were a few different potential software solutions that we looked at: Microsoft Visual Studio - This development environment would be useful for our needs. It has a fairly large library for building browser-based applications. It would also make connecting to UNIs Microsoft SQL server for metering data a much simpler process. In the end, this was the best software option for our needs. NetBeansIDE - This platform allows applications to be developed from a set of modular software components. NetBeans has an application platform framework for Java desktop applications. This is a great option for our integrated development environment. Adobe Flex SDK - This option seems best for more visual intensive designing. It would be difficult to program the power flow applications. Not a cost effective option.

16

Below, there are a series of pictures/diagrams below of designs that were used in creating our own software. This picture is a simple concept sketch of what our own software design might look like.

17

This is a simple block diagram of how a user would interact with our software.

18

The picture below is a prototype of a design run in a web browser on our local machine.

We also contemplated a couple other commercialized software options that did not make the cut for the final design. SKM - SKM is a power flow program. This program was considered because John Hanke had previous experience in an internship with it. SKM allows creation of a power circuit on a one-line diagram with multiple libraries of manufactured parts. There are several power flow studies that can be run in this program, such as short circuit and fault studies. We chose not to use this program because it lacks color code in the circuit, which was a non-functional requirement for the client. This program also contains features that the client doesnt need and canno t be purchased separately like Etap. PowerWorld - Powerworld is high level grid modeling software. Powerworld can be used to model the whole grid in the United States. This made it so that this software wasnt really good for our application because our distribution system is low level.

19

Appendix III: What We Learned from the Process There are a number of things that we learned about major design projects during this course. Large-scale projects can be difficult to implement correctly. Looking back, there are some mistakes we could have avoided and some things that we did really well along the way. Towards the start of the semester, we quickly found that effective communication would be important. Since our client did not have a clear plan for how the design should be constructed, it was up to us to ensure that they would be satisfied with the final result. We also quickly realized that administrative delays would be a big factor in this project and that planning for these delays would be essential to finishing the project. At first, we were a little quick to try and implement one design instead of exploring our options. With some advice from our advisor, which turned out to be very useful, we decided to instead try multiple approaches at the problem. In this way, we were able to pinpoint potentially serious concerns that could have been problematic further down the road. For example, there were some security concerns with respect to creating our own software. It would have been very challenging to overcome the security issues without the use of commercialized software. Another thing that became a slightly problematic was that ETAP and many other software companies attempt to squeeze as much money out of their customers as they can. For example, not only do they make you pay extra for simulation modules, but they also wanted to double the cost of the program for simply adding more busses to the model than the default. It would have been beneficial to use more time and resources to pursue even more commercial software options.

20