davidbeach-
I agree with what you are saying, however there are certain things one must do to either satisfy a client specification or cover one's arse. A few examples:
1) New wind farm with 20 feeders, two busses, two transformers and one Utility PCC. The testing spec is created by someone with a different philosophy (copies NETA spec). Plant is built by a developer and sold off to owner/operator. Automating the settings for the feeders makes a lot of sense as only a few things will change from relay to relay. Ditto bus and Xfmr relays. Xfmr relays part of a NERC audit so consistency is important. PCC / Line relays are often review by interconnecting utility (or at least copies of report requested). Commissioning contractors are often paid after test reports are submitted. Three years after the job is complete, something trips and plant owner (with little knowledge of protection / power systems) calls looking for explanation. I've been on both sides of this having the detailed documentation showing that things were tested comprehensively or reviewing someone else's use of some software package that a monkey could run that shows a bunch of element pickups, but nothing in terms of logic (feeders also performing BF with no delay, etc).
2) In a utility environment. Say this time reclosing didn't work as expected. Someone gets a call from a relay placed in service 2 years ago. Glad we have not only the detailed test results, but captured the SER in the test report to show everything, at the time of testing, operated as designed.
3) In a utility environment, when a contractor is utilized instead of in house labor. It's often the in house relay techs that will scrutinize the test reports. Even though there may have been a specification provided in the bid specification, it can be vague and often times doesn't matter to the relay techs reviewing, as they may have their own view on what they want to see. In this case, it's also quite beneficial to over test / over document things.
4) As you are aware, there are multiple relay vendors and relay test set vendors. Each has its own nomenclature for whatever the protective function is. Take SEL vs. GE and Doble vs. Omicron. Take a element 21, 87T, 51. What we understand as O87P is or can be described differently by the relay vendor or test set vendor in their SW. Each relay vendor may have a different equation for restraint or even something goofy like a cubic spline between SLP1 and SLP2 (talking to you GE). Some utilities and many commissioning companies may have different test sets (that you only use every year or so), or you may run into a phase in the utility where vendor XYZ was used for a time and now no longer but the asset is still in service and now protecting a new transformer and must be retested. Every try and work on a non SEL early 90's IED? (Talking to you Alstom / ABB)
I work with many relay techs from our local distribution companies that also serve the transmission operator. Goods guys, but I also see many different personalities and testing philosophies. Maybe for them it's a CYA or "I get paid by the hour". Just last week I had this discussion with a very good relay tech and we both agreed that we are very, very unlikely to catch something wrong in a SEL-411L algorithm that wasn't thoroughly put through its paces at SEL R&D or RTDS.
Our Transmission company has a standard line package (or is trying to get there), as well as standard bus package, transformer package, etc. As a result, I have pretty good templates to cover these. Once I've seen the deviations of these and create my own iterations, it doesn't take too much effort to create a complete test that covers what's required and not touch a single thing in the relay during the test. That gives me more time to deal with the one incompetent person in the SCADA department the refuses to turn in their homework in a timely manner.
