The Power of a Test Routine
What do you need to do your job? A test set and test plans? Training? More time in the day?
What about “a procedure modeler” or “a knowledge capturer”? Terminology aside, the point is relay testing is consequential to other people’s jobs, a profession with accountabilities beyond technical work with equipment. Getting the job done properly starts and ends with information—information that concerns employers and fellow workers alike. Results from relay tests help stakeholders understand the condition of protection systems and the effectiveness of approaches to testing and maintaining them…as long as test results capture such information in the first place.
Between performing tests and completing work orders, relay testers use separate software tools for different purposes in their workflow. Consequently, their data can come from and go to different systems: technical test data in proprietary software files and operational data in work management systems, for example. Handling field data in this fashion isn’t uncommon and neither is being somewhat employee dependent as a result. In other words, key details about protection system reliability might never rise to the purview of decision-makers in a workflow built on separated record keeping.
Look at the test plans themselves: the included (and excluded?) tests, the pass/fail parameters, formulas and calculations, the order of tests and so forth. In such a complex field as relay testing, crafting test plans that work – with programmable multi-function relays in particular – is the hallmark of a qualified technician, essentially showcasing his or her experience, knowledge, and philosophy. But relay programming and professional opinions differ, and it’s possible that eventually a testing crew will utilize a number of differently created test plans, each with their own inner workings, for the same type of relay. Aside from inconsistencies at the testing level, the flat file approach that proprietary test set software typically employs for test data management all but ensures that the differentiations go unnoticed at the reporting level.
Against this risk, I’ve known of companies to go to painstaking extents to pull together field and office data. In one instance, I recall meeting an individual whose job entailed NERC PRC-005 evidence collection which had become overwhelming to her. She was working, too often, into her personal time to stay current. Her company used “packets” which, no exaggeration, were about as thick as a ream of copy paper. In each packet were check listed sections of required documentation. The packets would route to relay testers who would complete the test portion, then send them along to the next person in the chain from whatever other O&M area played a part. Her role was to shepherd the whole matter, deal with the imperfections and breakdowns along the way, and come up with reportable compliance evidence.
Why was all this necessary? Because of inertia. Her company’s operations were generally sound as long as different areas kept to their own devices in terms of their normal workflow. Relay testers kept test records on their individual laptops and backed them up to shared drives assigned per division where records for given substations and discrete relays were collected.
Given the multiple locations of test results, the sheer volume of device instances and files per each, and the fact that their company’s test plans were definitely not of one design, automating their NERC compliance tracking was impossible. Their IT department didn’t have the resources available to even begin stitching together a data gathering solution let alone meeting the criteria the business had for functionality, reporting and support.
So, relay testers continued on with the packets: printing their results, manually cataloging and collating whatever needed to be tracked. The process wasn’t complete until the packets passed internal auditing, which brings us full circle to the distressed admin in this particular example.
But the story didn’t end there. Ultimately, test routines replaced their packet system. Test routines are universal procedures that meld data points – the who, what, where, when, why, and how of field work – into single information sources. Developers can create a test routine per a given device type, for example, which means one routine is the template for countless devices of that type. Only to this extent are test plans like test routines. Beyond this similarity, the differences really stack up.
A test routine models a workflow from beginning to end. This means that developers can take the administrative parts of the job and set them into the test process directly; work and asset management steps can be designed into the routine in conjunction with device tests. Whether operational or technical, the step-by-step process gives the relay tester whatever requirements are intended and the approved, proven methodologies for testing any given device in whatever situation or circumstance.
At the completion of the routine, the data contained in the results satisfy the informational and reporting needs of supervisory, administrative, and compliance tracking stakeholders. Software that supports routines can manage procedures and device data collectively without forcing records to become multiplied through separately saved results per each discrete device.
A quality test routine can cure many ills that plague test and maintenance operations. First of all, it sets the standard and keeps it ironclad, conserving philosophies and opinions that win, ensuring process consistency. Next, it spells out the work that’s expected – the standard operating procedure – and can include job aids. Additionally, with some forethought, test routines can be designed for capturing and sharing first-hand insights from field workers that stakeholders need.
Yes, test sets are fundamental necessities of relay testing but a test routine benefits the job. It’s a different kind of tool, one for testers and administrators alike that places information management directly into the test process for a crucial field-to-office link that no team should be without.
Additional Information:
- Originally published in the The Relay™ Newsletter. Subscribe on LinkedIn.
- Learn about Doble Protection Testing Solutions
