Subject: Visualization of Fault Location Final Report

advertisement
Subject: Visualization of Fault Location Final Report
To: Becky Stewart
Prepared by: Team Fault Finders
Team Members:
Cliff Clark, Gary Hollingshead, Elizabeth Reese
Jamie Nance, Ryan Savage
Sponsored By:
Others Involved:
Date: May 12, 2011
University of Idaho
College of Engineering
Moscow, ID 83843
May 12, 2011
Idaho Power
1221 W. Idaho St.
Boise, ID 83702
Attention: Becky Stewart, Engineering Specialist
Subject: Visualization of Fault Location
Attached please find the final report for the Visualization of Fault Location Project.
The report contains the design details for a prototype program built to automatically display
the location of a fault after it has been detected. This report includes the different designs
considered and a detailed explanation of the completed design. Additional information can be
found at our team’s website: < http://seniordesign.engr.uidaho.edu/20102011/fault_finders/documents.html>
If you have any comments, concerns, or questions please contact us. Thank you for the help
you have provided throughout this project and for the opportunities this project has presented.
Respectfully,
Team Fault Finders
1
TABLE OF CONTENTS
EXECUTIVE SUMMARY ................................................................................................. 3
1.0 INTRODUCTION ...................................................................................................... 4
1.1 Sponsor Background ............................................................................................................. 4
1.2 Project Background ............................................................................................................... 4
2.0 PROBLEM DEFINITION ............................................................................................ 5
2.1 Problem Objective ................................................................................................................. 5
2.2 Specification .......................................................................................................................... 5
2.3 Deliverables ........................................................................................................................... 6
2.4 Constraints ............................................................................................................................ 6
3.0 CONCEPTS .............................................................................................................. 6
3.1 Concepts Considered............................................................................................................. 6
4.0 PRODUCT DESCRIPTION ......................................................................................... 8
4.1 Description of Concept .......................................................................................................... 8
4.2 Explanation of Concept Choice ............................................................................................. 8
5.0 PROJECT DESIGN .................................................................................................... 8
5.1 File Watcher: ......................................................................................................................... 8
5.2 Newfault.ashx........................................................................................................................ 9
5.3 Index.htm .............................................................................................................................. 9
5.4 Idaho Power Fault Trace Code ............................................................................................ 10
6.0 OTHER PROJECT DETAILS ...................................................................................... 10
6.1 Cost and Estimated Savings................................................................................................. 10
7.0 CONCLUSION ....................................................................................................... 11
7.1 Evaluation of Final Product ................................................................................................. 11
7.2 Product Testing ................................................................................................................... 11
7.3 Recommendation for Future Work ..................................................................................... 11
APPENDIX .................................................................................................................. 13
2
EXECUTIVE SUMMARY
The purpose of this design project is to automate the process of receiving information about a
power line fault from relays and displaying the information and location on a map to assist in a
quicker response time in repairing the fault. This project is sponsored by Idaho Power Company
and also assisted by Schweitzer Engineering Laboratories.
Transmission line faults occur no matter how much protection and monitoring of a distribution
system a company has. The goal of this design project is to provide a more informative, more
accurate, and quicker response for these faults. As of now, Idaho Power Company has the
ability to display the location of a fault on their mapping software (ArcGIS). However, the
process of receiving the fault information to displaying it on a map is not done in the most time
efficient manner as possible and requires user interaction with the relays and programs.
Using the software provided by Schweitzer Engineering Laboratories (SELocator), the program
will read the fault information found from SELocator, run it through a program provided by
Idaho Power to decipher the latitude and longitude, and then plot the location of the fault using
ArcGIS mapping software. All of this will be done automatically within minutes after the fault
was detected by the relays.
There are always many ways to design a program. The first thing to be investigated was the
best way to design the layout of the program. After that was complete, the next step was
making sure the design chosen could accommodate all of the tasks it needed to. Then the
implementation could begin.
The program has been completed and can automatically plot the estimated location of the fault
on a map as requested. There were a few other requests about the user interface of the final
webpage that were unfortunately not completed, but those features could be added on later.
This design will be a prototype for Idaho Power Company to build upon in the years to come.
This program will create an easy solution to displaying faults on the mapping software used, will
perform this task automatically and quickly, and will be beneficial in the response reactions of
the repair crew.
3
1.0 INTRODUCTION
1.1 Sponsor Background
The Visualization of Fault Location project is a senior design project at the University of Idaho
sponsored by Idaho Power Company of Boise, Idaho along with support by Schweitzer
Engineering Laboratories of Pullman, Washington. Idaho Power Company installs, maintains,
and repairs power transmission and distribution lines. Becky Stewart is the client representing
Idaho Power. Schweitzer Engineering Laboratories designs, manufactures, and supports a
complete line of products for protection, monitoring, control and metering of electric power
systems.
The purpose of this project is to automate the process of getting the event files from the relays,
finding the latitude and longitude of the fault, and displaying the location of the fault in the
ArcGIS program. With this whole process automated, it will save a lot of time for the workers
and provide a quicker reaction.
Idaho Power uses an accurate geographic information system (GIS) known as ArcGIS to create a
complete model of their distribution system. This model includes details on all of the
equipment including power pole information, transmission line information, substation
information, and more.
On the transmission lines, Idaho Power uses protective relays made by Schweitzer Engineering
Laboratories. These include SEL-321’s, SEL-421’s, and a few other models. These relays are used
to take readings of the voltage, current, and many other measurements of the power lines. This
allows power line faults to be detected quickly. When a fault occurs, the relays create an “event
report” file. This file includes several different readings of measurements that were taken and
time stamps before, during, and after the fault occurred. This event file is used in the process of
finding the location of the fault on a transmission line.
SELocator is a program provided by Schweitzer Engineering Laboratories which communicates
with the relays through ethernet or serial port and provides a more accurate fault location then
the previously used method. When a fault occurs and the relays create an event report file,
SELocator retrieves the file automatically. The program then calculates the type of fault and the
distance down the line a fault occurred using all the measurements provided in the event
report file. The information calculated by SELocator is outputted to a text file. This text file will
be described in more detail later on.
1.2 Project Background
Previously, Idaho Power employees would have to “call” the relays (by Ethernet) to get the
event report files from the relays. Then the Idaho Power employees would use a program to
estimate the distance down the line that the fault occurred. After they have the distance, they
would have to open the map, click on the line that the fault occurred on, and enter the distance
4
down a line in a little pop up box. Then a small program referred to as “trace code” is used to
find a latitude and longitude of the fault location. In the ArcGIS maps, the transmission line with
the fault would then be highlighted and an indicator would be visible at a location where the
fault was estimated. Although this process indicates where the fault was estimated to be, many
changes could be made to make the process quicker and easier. Figure 1.1 in the appendix
shows an example of the current fault location mapping used by Idaho Power Company.
Displaying the location of the fault in the ArcGIS program is very beneficial because it allows the
repair crew to easily see where the fault is, which allows them to determine what type of
equipment they might need to repair the fault by looking at the attributes that ArcGIS stores
about all the different equipment. Having a location displayed on a map will also make it easier
for the repair crew to plan the quickest route to the fault.
2.0 PROBLEM DEFINITION
2.1 Problem Objective
The objective of this project is to automate the process of receiving power line fault
information from relays and displaying the information and location on a map to assist in a
quicker response time in repairing the fault
2.2 Specification
Here is a list of the specifications of what the product should include and how it should
perform:
 Completely automated and triggered by an event report file being generated in the SEL
relays
 Read text files from SELocator
 Parse the information from the text file and convert to file type and information that
can be used in ArcGIS programs
 Find the correct power line the fault is located on and use the provided Fault Trace Code
to convert information from text file to a latitude, longitude
 Place a symbol in ArcGIS server at the nearest structure to the fault
 User ability to easily mark finished faults and set a default time-out for each fault to
remove itself
 Display fault within minutes after event file is created by relays
5
2.3 Deliverables
DELIVERABLES
Item
Date
Completed?
Demo showing a fault in Google
12/28/2010
Prototype of program showing fault in ArcGIS
Get Sample SELocator output text file to use
Test complete program
Complete web page specs
Have product packaged up with user manual and sent to
Idaho Power
2/25/2010
3/10/2011
4/07/2011
4/20/2011
Yes
Only showing fault in Google
Maps
Had to just create one by hand
Yes
Not quite
5/06/2011
Yes
TABLE 1.2 Deliverables for the Complete Project
2.4 Constraints
This project has a special situation because two team members left after the first semester and
two new team members joined. This created a period where the two new team members were
learning about the project and trying to pick up where the other two members left off. This is
why there is quite a gap in the deliverables between December 2010 and February 2011.
The program provided by Schweitzer Engineering Laboratories currently only works with the
most recent models of the relays (SEL-421 relays) and will therefore not work on many of the
Idaho Power transmission lines because they use many different relays including some of the
older models. SELocator will eventually work with more models of SEL relays. Therefore Idaho
Power can only use this program for the lines which contain SEL-421 relays for now, but will be
able to use on more after a later version of SELocator is available.
SELocator takes around 3 minutes to retrieve the complete event report file from the SEL
relays. This is longer than was expected. However, the fault will still be visible within about 4
minutes after the fault occurs.
3.0 CONCEPTS
3.1 Concepts Considered
This design project contains several steps from getting the data from SELocator to displaying it
in ArcGIS programs. Each design considered must complete the following in some form:
6
1. Monitor the folder in which SELocator stores the text files it creates with all the
location data so it will immediately know when a new file has been added
indicating a new fault occurred.
2. Take the information provided by the text file from SELocator and use the trace
code (provided by Idaho Power) to find the latitude and longitude of the fault
and the line that the fault occurred on.
3. Store the information in a table in the system’s geo-database where it can be
accessed.
4. With the information stored in the geo-database table, the program can query
the table for the necessary info when creating the web page.
The team explored three basic concepts that could complete the necessary steps listed above.
Our first design option was to write all or most of the project in the programming language of
Python and install it as an ArcMap plug-in. The advantage of this approach is ArcMap would be
available to the user, and we would not have to write any graphics/user interface code. The
disadvantage is that we would be limited by what ArcGIS allows in their Python environment. If
we later found that file access or other system facilities were somehow restricted by ArcGIS, we
would have to re-implement our project in another language. Therefore this concept was
abandoned.
The second concept considered was to write the entire project in the programming language of
C# (C “sharp”). This would give us more control than writing the plug-in, and the ArcObjects API
(application programming interface) was available which allowed us to interact with ArcGIS
without having to be an integrated part of the ArcGIS program itself. We could also control the
user interface to make it simpler for users. Another benefit was that the fault trace code
provided by Idaho Power already used the ArcObjects API, so it would have been easy to just
use the provided code as part of our program. The downside is that you still need to have
ArcGIS installed and configured, along with SELocator installed and running all on the same
computer. Only one person could easily run the program for a set of relays. This concept would
become too complicated on the application side even though it seemed easy on the design side
and so we moved on to another concept.
Finally, the team settled on splitting the design up into two main parts. The first piece is a file
monitoring program to gather the fault data from the SELocator output text file. The second
piece is a web service. This part of the application stores the faults, runs the code provided to
find the required information in order to locate the fault in the ArcGIS mapping programs, and
then displays the faults on a web page. The main benefit to this is that it is much easier to run
than the other concepts. Since this program has all the ArcGIS information and shows it on a
web page, any of the users can look at the web page to see the faults whether the computer
they use has ArcGIS software installed or not.
7
4.0 PRODUCT DESCRIPTION
4.1 Description of Concept
The concept design that was chosen consisted of two main pieces: the file watcher, and the
web service part of the program. The file watcher program monitors the SELocator log directory
where the text file containing the fault information calculated is stored. When a change is
detected in the log directory, the file watcher program loads the information and performs a
web request to store it. The web service runs the fault trace code to calculate the latitude and
longitude of the fault and then stores all of the fault information in the geo-database. The web
application then provides a web page for any number of users to view the maps with the faults.
Figure 1.3 in the appendix shows a flow diagram of the whole design program and has a brief
explanation for each step.
4.2 Explanation of Concept Choice
This is the most flexible approach, because the computer (or computers) that monitor the
relays will not need ArcGIS installed. Also, many users can view the fault information at once,
and like the computers that monitor the relays, these computers will not need to have the GIS
software installed. The only machine in this model with a dependency on ArcGIS is the web
server hosting the web pages. This will allow for a simplified installation process and allow any
number of clients to both add faults and view faults.
5.0 SYSTEM DESIGN
5.1 File Watcher:
Requirements:
1) Built in C# and .NET 3.5 framework. Due to this, this program requires a Windows
operating system.
2) Must run on a program with read and write access to the SELocator output directory.
3) Must run on computer with network access.
4) Must run as a user with permissions to contact newfault.ashx on web server.
Operation:
The File Watcher program asks for the folder location of the SELocator output. Once started, it
monitors the folder looking for a .txt file. Once a file is located, it is immediately renamed to a
.tmp file to prevent collisions while parsing. File Watcher then parses the .tmp file (which is in
CSV format) and generates a web request to newfault.ashx. All fields from the parse are sent as
variables on the URL request. Once the request is generated and sent, the line is appended to a
8
.dat file in the same directory named according to the current month. Once all lines in the .tmp
file are parsed and sent, the .tmp file is deleted.
5.2 Newfault.ashx
Requirements:
1) Requires access to Idaho Power Trace Code, and meet all trace code requirements.
2) Must run on a web server with access to a FeatureService running on a ArcGIS Server.
3) Requires IIS
4) Requires .NET 3.5 Framework
Operation:
The newfault.ashx file parses the requesting URL for the variables (FaultDistance, RelayName,
FaultTime, FaultType, LineName) generated and provided by the file watcher program. Once
the variables are acquired from the URL, it passes the information to the Idaho Power Trace
Code to turn the relayname and distance into a latitude longitude location. Once that
information is received back, newfault generates a new web post request to the ArcGIS server.
This post request includes all the previously mentioned variables as attributes and includes the
latitude and longitude. The URL of this post request is dependent on the local configuration of
the ArcGIS server, and therefore there is a setting in the .ashx file for the location of the
AddFeature service of the FeatureServer. Once the web request is generated and sent,
diagnostic information is returned to the requesting service. The AddFeature service takes the
information provided and generates a point feature and stores the variables as attributes in the
geo-database.
5.3 Index.htm
Requirements:
1) Access to the ArcGIS Server MapService, FeatureService, and Geometry Service.
2) A webserver
3) ESRI Javascript API Proxy Page. This is created and provided by ESRI, the company who
makes ArcGIS, and instructions for this can be found in the Javascript API concept
documentation from ESRI.
4) Access to the ArcGIS Javascript Dojo library, part of the Javascript API provided by ESRI.
Typically accessed directly from esri.com, however can be copied locally and hosted on
the intranet.
Operation:
The current state of this webpage is not complete. There are several settings within the file
that require knowing the URL to the Map and Feature Services of the ArcGIS server. These
settings must but configured to match the local environment. The ArcGIS Proxy page must also
be configured and setup on the web server. The index page currently uses the attribute
inspector widget of the Javascript API. This widget allows the querying of data from the geodatabase and saving the information back to the database. It also displays all of the map layers
9
of the MapService. When a user clicks on a fault location, a balloon menu opens and allows the
editing of the attributes for the fault. When the user changes focus away from a field, the data
is saved back to the geo-database.
5.4 Idaho Power Fault Trace Code
Requirements:
1) This code requires access to the ArcObject API
2) This code needs access to the geo-database through the ArcObject API
Operation:
We were provided this code, and therefore do not know all of the operation of this code. From
inspecting the code and watching the operation, it accesses the geo-database through the
iWorkspace interface. It looks in a data table and gets the ArcID of the relay the fault is to be
traced from. It then finds that point in the ArcMap layer and traces the distance down the line
feature. Once the distance is reached, it gets the latitude and longitude of the point and
returns it to the calling information.
6.0 OTHER PROJECT DETAILS
6.1 Cost and Estimated Savings
ITEM
ESTIMATED COST OF PROJECT
Cost to Team
Actual Cost*
ArcGIS Software
EXPO Day Poster
Visual Studio 2010 (Pro)
SELocator
$60
$88
Free (for students)
Free
$2,500
$88
$800
Not Available Yet
Total Costs:
$148
$3300+
TABLE 1.4: COST OF PROJECT
*Actual Cost is compared to the educational version of the software made available to us.
Actual Cost estimates found online and may vary slightly
10
7.0 CONCLUSION
7.1 Evaluation of Final Product
The main goal of this project was to create a program that would automate the process of
visualizing the location of a power line fault on a map. It was also specified that the program
should use the output text file from SELocator to accomplish this task. The final program
developed does complete this goal. The fault will appear on the maps around 4 minutes after
the fault has occurred.
Along with the main goal of this project, there were some smaller goals. Unfortunately, only
parts of those goals were completed. The final page showing the faults also shows the
information about a specific fault when clicked on. However, there were other user interface
tools and information that was requested for the page that we did not have time to finish. If
another student wanted to finish this project, they would need to learn to use the Javascript
API made to work with ArcGIS, but writing the code would take less time than learning about it.
Figure 1.2 in the Appendix shows the final web page that the program creates. It does present a
lot of information about the faults and shows the location easily. There are still many things to
add to the user interface of the webpage.
7.2 Product Testing
The complete program was tested by using a sample SELocator output text file. There were
difficulties with the model power system used with SELocator so a sample output file had to be
created to use. However, SEL provided an actual output file from a setup that they ran. So the
sample file that was used was of the exact form of a real output file from SELocator.
The program was tested by placing the sample output file into a specified folder while the
program was running. The program should run if a text file was added or edited in the specified
folder. Therefore, just creating the sample output files and placing them into the folder should
trigger the program to run. The fault location successfully showed up on the web page map
with the correct information about each fault.
7.3 Recommendation for Future Work
The program designed this semester is very specific to ArcGIS. There are many different types
of GIS programs used among utilities. Something that could be continued on for this project is
to generalize the program to any type of GIS program. This could mean writing separate
application code for all the different types of GIS programs and then having a settings option to
specify which type of GIS is being used.
Another constraint for generalization of this program is the trace code that was provided by
Idaho Power. This code accesses information in the ArcGIS geo-database and somehow
11
calculates the latitude and longitude based on the line the fault occurred on and the distance
down the line. This code would have to be rewritten so that the program does not use code
belonging to a specific utility and its geo-database information.
There were some improvements for the user interface that should be made to the index.htm
page, as follows:
 When fetching faults from the geo-database, the query should be limited to a time
range specified by a drop-down box on the page.
 The table of faults should have a checkbox for whether or not each fault is cleared, and
a button should let the user "clear selected faults."
 It would be nice if clicking on fault info in the table caused the map to focus on that fault
point.
12
APPENDIX
FIGURE 1.1: Current Fault Location Mapping Output
Figure 1.1 above represents the output of the fault location mapping program that Idaho Power
Company is currently using and that this design project will replace someday.
13
FIGURE 1.2: Current Fault Location Mapping Output
Figure 1.2 above shows the results from this project. The fault is shown as a red dot with
crosshairs in it. If it is clicked on, the dialog box pops up with information about the fault. There
is also a table below the figure with all the faults and the information.
14
FIGURE 1.3: Flow Chart of Design Concept Chosen
Figure 1.3 above shows and explains briefly the layout of the design concept chosen to proceed
with. All the material inside of the red dotted line will be part of the program developed in this
project.
15
Download