Testing vs Testing - the System

© Copyright Rod Hughes Consulting Pty Ltd
Rod Hughes Consulting
General Web Site
 
Applications
Home
Innovations and
Solutions Home

A bit about
Rod Hughes
 Link to this page...

The URL in the browser address bar is volatile and may be broken at any time.

To obtain a link to this page, click the <<Share>> button top-right of the screen.

  

Note - if the navigation pane on the left of this window is not visible, click the 2-pane icon on the top bar



we need to think about how many times we test the same thing and that also depends on how "same" it is.

Apart from proving the design does what it should and doesn't do what it shouldn't, the other aspect of testing is really about finding what errors humans have made in the implementation.

For wire based schemes, that is a very laborious process because there are so many human interpretations and activities between the sketch design, making all the connections devices to terminal blocks and the final connections being made on site.

So for an IEC 61850 system, let’s consider the GOOSE.

For one IED publishing a GOOSE containing PTRC.Op, we don't really need to test over and over and over again that particular GOOSE gets all the way to the one or dozens of devices that need to subscribe to that GOOSE. i.e. the PTRC may have say 20 Pxxx.Op inputs to it within the same IED - we do not need to verify that all the subscribing IEDs get that GOOSE message when we test each of those Pxxx functions individually. It suffices to prove once only that published GOOSE is subscribed correctly by each of the required IEDs.

We would of course also need to test that each of the subscribing IEDs correctly interpret and use the information in the dataset according to their particular functionality, but again we only need do that twice - once for the PTRC.Op "0" value and once for the "1" value in the dataset.

Indeed for GOOSE publishing, we don't actually have to test it relative to the protection function test of the publishing IED at all since that GOOSE message is being repeated every 1 second so it suffices to check once that each subscribing IED is receiving that particular GOOSE - whether or not the Pxxx.op functions have operated or not.

What is then necessary to test is that for that particular IED, the 20 Pxxx.Op are indeed correctly configured as inputs to its PTRC and would trigger the change in the GOOSE dataset value. That is indeed testing each of the 20 Pxxx in turn that the GOOSE will change from heartbeat to fast repetition with the changed value in the data set.

Now here comes the really clever bit if you've used a good IEC 61850 engineering process and tools (many haven't) based on bay structure derived in the SSD file prior to doing anything with SCD or even just ICD files, then ...

Having confirmed that the 20 Pxxx.Op are correctly configured in this first IED as inputs to its PTRC,

and that PTRC correctly publishes its GOOSE for that bay,

we can copy that bay configuration in our engineering tools and simply change the bay name each time.

We now have to ask ourselves, having proved the first bay configuration of the 20 Pxx.Op and the PTRC.Op in the GOOSE and that GOOSE is correctly subscribed by the receiving IEDs, and we have simply copied all that configuration and just changed the name of the bay - do we have to test all that configuration again??? There has been no human intervention other than the name change.

So some good thinking in choosing your engineering process and preparing the test plan will avoid a huge amount of unnecessary testing.

We need to test what needs to be tested .. and not repeat tests that have already been done.

 

Contact Me

Skype: (ping even if showing offline)

Email Me

A phone call is nearly always welcome depending on the time of night wherever I am in the world.
Based in Adelaide UTC +9:30 hours e.g.

April-SeptemberNoon UK = 2030 Adelaide
October-March:Noon UK = 2230 Adelaide

  Office + 61 8 7127 6357
  Mobile + 61 419 845 253



Extra Notes:

Disclaimer
No Liability:
Rod Hughes Consulting Pty Ltd accepts no direct nor consequential liability in any manner whatsoever to any party whosoever who may rely on or reference the information contained in these pages.  Information contained in these pages is provided as general reference only without any specific relevance to any particular intended or actual reference to or use of this information. Any person or organisation making reference to or use of this information is at their sole responsibility under their own skill and judgement.

No Waiver, No Licence:
This page is protected by Copyright ©
Beyond referring to the web link of the material and w
hilst the information herein is accessible "via the web", Rod Hughes Consulting Pty Ltd grants no waiver of Copyright nor grants any licence to any extent  to any party in relation to this information for use, copy, storing or redistribution of this material in any form in whole or in part without written consent of Rod Hughes Consulting Pty Ltd.