EXECUTIVE SUMMARY .edu



Subject: Visualization of Fault Location Final ReportTo: Becky StewartPrepared by: Team Fault FindersTeam Members: Cliff Clark, Gary Hollingshead, Elizabeth ReeseJamie Nance, Ryan Savage1971675301625Sponsored By:1936115407670Others Involved:Date: May 12, 2011University of IdahoCollege of EngineeringMoscow, ID 83843May 12, 2011Idaho Power1221 W. Idaho St.Boise, ID 83702Attention: Becky Stewart, Engineering SpecialistSubject: Visualization of Fault LocationAttached 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: < 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 FindersTABLE OF CONTENTS TOC \o "1-3" \h \z \u EXECUTIVE SUMMARY PAGEREF _Toc166695843 \h 31.0 INTRODUCTION PAGEREF _Toc166695844 \h 41.1 Sponsor Background PAGEREF _Toc166695845 \h 41.2 Project Background PAGEREF _Toc166695846 \h 42.0 PROBLEM DEFINITION PAGEREF _Toc166695847 \h 52.1 Problem Objective PAGEREF _Toc166695848 \h 52.2 Specification PAGEREF _Toc166695849 \h 52.3 Deliverables PAGEREF _Toc166695850 \h 62.4 Constraints PAGEREF _Toc166695851 \h 63.0 CONCEPTS PAGEREF _Toc166695852 \h 63.1 Concepts Considered PAGEREF _Toc166695853 \h 64.0 PRODUCT DESCRIPTION PAGEREF _Toc166695854 \h 84.1 Description of Concept PAGEREF _Toc166695855 \h 84.2 Explanation of Concept Choice PAGEREF _Toc166695856 \h 85.0 PROJECT DESIGN PAGEREF _Toc166695857 \h 85.1 File Watcher: PAGEREF _Toc166695858 \h 85.2 Newfault.ashx PAGEREF _Toc166695859 \h 95.3 Index.htm PAGEREF _Toc166695860 \h 95.4 Idaho Power Fault Trace Code PAGEREF _Toc166695861 \h 106.0 OTHER PROJECT DETAILS PAGEREF _Toc166695862 \h 106.1 Cost and Estimated Savings PAGEREF _Toc166695863 \h 107.0 CONCLUSION PAGEREF _Toc166695864 \h 107.1 Evaluation of Final Product PAGEREF _Toc166695865 \h 117.2 Product Testing PAGEREF _Toc166695866 \h 117.3 Recommendation for Future Work PAGEREF _Toc166695867 \h 11APPENDIX PAGEREF _Toc166695868 \h 12EXECUTIVE SUMMARYThe 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.1.0 INTRODUCTION1.1 Sponsor BackgroundThe 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 BackgroundPreviously, 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 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 DEFINITION2.1 Problem ObjectiveThe 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 fault2.2 SpecificationHere 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 relaysRead text files from SELocatorParse the information from the text file and convert to file type and information that can be used in ArcGIS programsFind 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, longitudePlace a symbol in ArcGIS server at the nearest structure to the faultUser ability to easily mark finished faults and set a default time-out for each fault to remove itselfDisplay fault within minutes after event file is created by relays2.3 DeliverablesDELIVERABLESItemDateCompleted?Demo showing a fault in Google12/28/2010YesPrototype of program showing fault in ArcGIS2/25/2010Only showing fault in Google MapsGet Sample SELocator output text file to use 3/10/2011Had to just create one by hand?Test complete program4/07/2011Yes?Complete web page specs4/20/2011Not quite?Have product packaged up with user manual and sent to Idaho Power 5/06/2011Yes?TABLE 1.2 Deliverables for the Complete Project2.4 ConstraintsThis 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 ConsideredThis 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: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. 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. Store the information in a table in the system’s geo-database where it can be accessed. 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. 4.0 PRODUCT DESCRIPTION4.1 Description of ConceptThe 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 ChoiceThis 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 DESIGN5.1 File Watcher:Requirements: Built in C# and .NET 3.5 framework. Due to this, this program requires a Windows operating system.Must run on a program with read and write access to the SELocator output directory.Must run on computer with network access.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 .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.ashxRequirements:Requires access to Idaho Power Trace Code, and meet all trace code requirements.Must run on a web server with access to a FeatureService running on a ArcGIS Server.Requires IISRequires .NET 3.5 FrameworkOperation: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.htmRequirements:Access to the ArcGIS Server MapService, FeatureService, and Geometry Service.A webserverESRI 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.Access to the ArcGIS Javascript Dojo library, part of the Javascript API provided by ESRI. Typically accessed directly from , 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 geo-database and saving the information back to the database. It also displays all of the map layers 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 CodeRequirements:This code requires access to the ArcObject APIThis code needs access to the geo-database through the ArcObject APIOperation: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 DETAILS6.1 Cost and Estimated SavingsESTIMATED COST OF PROJECTITEMCost to TeamActual Cost*ArcGIS Software$60 $2,500 EXPO Day Poster$88$88Visual Studio 2010 (Pro)Free (for students)$800 SELocatorFreeNot Available YetTotal 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 slightly7.0 CONCLUSION7.1 Evaluation of Final ProductThe 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 TestingThe 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 WorkThe 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 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.APPENDIXFIGURE 1.1: Current Fault Location Mapping OutputFigure 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. FIGURE 1.2: Current Fault Location Mapping OutputFigure 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.FIGURE 1.3: Flow Chart of Design Concept ChosenFigure 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. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download