Distribution Inspection

[paul]

I'm starting this thread for open discussion on the design of our Distribution Inspection product module.

As we mentioned in the newsletter, we're focusing on this as a reasonably general and useful type of inspection. Our first deployment was to Tri-State, GA and we are making it available to the other Inspection System customers.

I would especially like these customers and the Inspection Advisory Board to weigh in, but anyone who is interested can participate. I'll start with a couple of posts and then let the fun begin.

[paul]

Here's a summary of the scope, goals, and basic concepts.

Scope

We define distribution inspection as routine inspection of overhead and underground structures and equipment past the substation.

This includes:
* poles
* poletop assemblies
* lines
* padmounts
* guys
* anchors
* wires
* switch cabinets
* transformers
* other devices
* meters

Furthermore, we'll divide these into three major inspection groups:
* overhead
* underground
* service

Goals

In this document, we would like to define the problem, propose some procedures, and design the beginnings of a data model for implementation in a software system. We'll also propose
some data-entry forms and reports that such a system should generate.

General Concepts

We'll use the term distribution inspection to cover overhead, underground, and service structures and equipment.

An inspection is a physical visit to a facility, examination of the facility, and recording of the results.

An inspection form is a data entry form appropriate to the facility inspected, with fields that may be numbers, text, picklists, checkboxes, etc.

An inspection record is the data representation of an inspection. When data is entered in an inspection form, an inspection record is created.

Scheduling is the act of identifying facilities that need to be inspected in a certain timeframe. This is generally done on some kind of rotating basis, for example poles might be inspected once every five years. The results of scheduling are scheduled inspections.

Assignment is the act of assigning inspection tasks to a specific person or crew. These are then referred to as assigned inspections or just assignments.

Distribution inspections are attached to the facility inspected, using an appropriate facility ID. This is essential for tracking and also allows display on a map.

Synchronization sends updated inspection records from field computers to a central server and vice-versa. This can be done as a batch process if no mobile network is available, or incrementally, if one is.

Priority indicates the urgency or importance of a particular inspection.

[paul]

The current schema in CSV format is here:
http://download.partnersoft.com/Distrib ... fields.csv

And the picklists are here:
http://download.partnersoft.com/Distrib ... klists.csv

These are per Tri-State's specs; we will evolve it based on customer needs but it would be nice to standardize as much as possible.

[paul]

I had a number of interesting conversations at TechAdvantage regarding Distribution Inspection.

Kevin Stucker (Linn County, Iowa) in particular was very helpful in providing insight and ideas. He's working with Inspection now as a developer and user and is helping evolve it as a standard.

I also spoke at length with Bill Koch, technical editor for RE Magazine. He is quite interested and gave me a number of directions to take the concept in.

Gary McNaughton and Bob Saint are the prime movers at MultiSpeak, and they are interested in helping evolve a MultiSpeak standard.

Everyone seemed to agree that:
* inspection is important
* there are no real existing standards for data or reports
* there is little or no automation
* co-ops will be doing more inspections and maintenance in a slow housing market

In the past we have simply followed our customers' lead. That is of course still a primary goal, but now that we have achieved some status with NRECA I think we should try working the standardization angle early. This forum thread is a start down that path. We are also pursuing:
* MultiSpeak standardization
* a CRN best-practices report
* one or more formal papers and presentations, e.g. to IEEE

MultiSpeak standardization is easy enough, we just need to agree on the schema. There's already been requests to get inspection data into GIS and WindMil and having a standard would sure be nice.

Everyone seems to think the CRN report is worth pursuing, but it might take awhile. I still need to talk to them but essentially it sounds like we just need to agree on a scope and then one or more of the customers need to formally request it. Apparently there is an existing report that relates to facility inventory but includes a full schema and is otherwise similar to what we might want from an inspection recommendation.

Papers and presentations will get folks talking in the larger community. Kevin said he was willing to do a paper for IEEE. Perhaps a collaboration with several people is in order. If nothing else, I'd like to get a decent white paper written that includes justifications and context instead of just specifications.

Many of these things have to be done by engineers or at least co-op personnel and not vendors. Obviously we have selfish interest but I do think opening this thing up will benefit the larger community and not just us and our users.

The Tri-State schema linked above is a good start. If we can give it a good going over I will present it to MultiSpeak and we can kick off some of these other efforts as well.

Any other references or examples of standard (or at least official-looking) reports would be helpful. FEMA, RUS, etc... surely somewhere someone has a list of requirements for routine inspections...

[paul]

Here are some RUS form examples:
http://www.usda.gov/rus/electric/forms/

[drowe]

It may also be useful to consider any federal and state regulations. It is likely that different states may have different safety standards and seperate processes to show compliance. If so, do you think we would need to consider different standard form templates for each state?

Perhaps:

General Inspection Standard: non-configurable for the utility, Multispeak standard

State standards: non-configurable for the utility, varies according to state, perhaps Multispeak? perhaps not?

Custom Fields: created and configured by Partner (or Inspection SDK clients), non-Multispeak but data is stored and archived within the utility.

Food for thought.

[paul]

Spoke with Marty. He says the paper on asset management data fields is actually open to the public and is sending me a copy. He says there is also a closed paper on maintenance inspections... unfortunately I can see the synopses but I can't see the papers or even use the search since I'm not a cooperative. You might search for inspection and/or maintenance.

I think the open paper is this one:
https://crn.cooperative.com/Results/ite ... _07-02.htm

I'll confirm when I get it.

Here are some other pertinent-looking articles:
* https://crn.cooperative.com/Results/ite ... 08-03K.htm
* https://crn.cooperative.com/Results/ite ... 06-25D.htm

Since we're not a CRN member those of you that are will have to do the reading and advise.

[Kevin]

I read my way through the CRN document this last weekend. I know I should have been working on cars but had sick kids.

The real crux of everything is in the Recommendedassets pdf file.

I think this data is a very good start although it likely isn't all inclusive.

I need to go through our data and see how it matches what is recommended.

[paul]

Got the document on CD today. It is indeed 07-02 November 2008 (even though the URL says 2007...).

It's tempting to go ahead and build a schema that matches the document exactly; then people could just leave out the stuff they don't want.

[paul]

Spoke at length with Luis Malave of Milsoft and Gerald Marlbury of Geospatial Extensions while I was in Abilene last week.

They are working on a damage assessment tool. Gerald has written a Windows Mobile phone application that integrates via web service to Milsoft's DisSPatch. They are working on MultiSpeak standardization.

It is an intentionally simple data schema. It does not depend on precise GPS location, and in fact allows for locational offsets (for when it's hard or dangerous to reach the location of the problem). It is a one-to-many relationship where multiple assessments are attached to one location. Each assessment would describe a different problem - down line, broken crossarm, etc. You can take a picture to attach to the location.

Most of the details are in the comments. As such it reminds me of what Charlie Allen at Black River described to me that they built - basically a simple damage reporting tool that everyone can use without having to fill out a big form.

We discussed this for awhile then came to the conclusion that really it's a different problem from that we are trying to solve with Distribution Inspection. Distribution Inspection is all about detailed, routine inspections, recording them for posterity and generating reports. Their tools is more oriented on problems and tracking the resolution of the problem in DisSPatch.

From what Gerald showed me, though, his phone app is quite flexible and could probably use our inspection schema configuration to build appropriate forms. So we may want to work with him on integration. Handing out phones could be a very good way to deal with crisis situations or bird-dogging, for example.

Also, I see no reason why we shouldn't integrate inspection with the DisSPatch damage assessment tool via a specific inspection module and MultiSpeak interface. Everyone agreed that the more ways these three technologies interoperated the better.

Luis also thinks their external table link, in WindMil, would be perfect for attaching inspection data to WindMil or WindMilMap. It appears to be one-to-one at the moment but he thinks he could do one-to-many (e.g. all the inspections for a given pole) without too much trouble.

[mhite]

After the ice storm about a month ago and then sitting down with the field guys trying to figure out exactly what they did, I am thinking to myself, there must be a better way to easily track this information. In a Damage Assessment situation, you want something fast, easy, but with detail at the same time, hard to get all of that. I like the idea of integrating a picture. Something as easy as clicking on a pole and then having a slew of check boxes saying I did this, this, and this with a corresponding text field to enter the number/ft. Problem is, not all the bird doggers had a laptop. Same thing with the phone, we do not have an abundance of extra company phones. Herein lies the issues.

On the Inspection side, this is our third year using an inspection mapset in the field. It works well. We are using it strictly for pole inspections. I will send the form to Paul to see what we are capturing. Different color dots on the poles represent different issues (replace, remove-not really here, no action needed). We have a contractor doing this for us and I tossed around the idea of having him using the staking software to redraw inconsistencies on the map, replace poles, etc , but decided against it. He started right after the ice storm and my heart just was not there this year.

We have a separate mapset for the operations supervisors/dispatch. Out Dispatcher looks at the information entered on the inspection and creates a service or work order if needed. This still requires creating the work order or SO in SEDC and rekeying data, again, using the staking software, some of that could have been avoided. Once the service or work order is created that information is entered on the pole. A report is generated that resembles a staking sheet for the work orders. When the job is returned as completed, it is marked as complete again on the pole. I have run an update against SEDC to close these also. At this point, the pole is back to normal on the map. All data is still in the DB so we can prove that we actually did inspections.

Sounds similar to the direction you are headed Paul. A standard multi-speak interface would be the way to go. Now, being a future customer of WindMilMap, the potential to have the inspection feed the map would be nice!

[paul]

Melissa:

You might check with Steven Latham at South Plains. He's working on integrating SEDC service orders with inspection.

Your form looks nice and is exactly the sort of thing we hope to accomplish with inspection.

You've captured the essence of the problem with damage assessment, though. At one end it would be nice to use cell phones or just throw icons on the map (a chainsaw here, a broken pole there, knick-knack-paddy-whack), but more information would definitely help. At the other end you could just take the staker out and completely capture everything needing to be done, with assemblies, and have all our existing tools and interfaces. But that requires a more highly trained user.

I suspect we'll end up integrating our own tools - e.g. import a damage inspection or inspections into a staking job, perhaps with it making some guesses on material or reading the existing facilities off the background map, then the user looks it over and adjusts as needed.