Testing vs Testing - the System

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.

Extra Notes: