Using DataModels and GOOSE

© 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



Working backwards:

GOOSE is specifically for sending status information.

In fact it repetitively sends at least once every second (usual setting) the status of each element defined in the Dataset

If any element in the Dataset changes value, the GOOSE message reverts to a fast repetition cycle eventually decaying back to the repetitive message once per second

 

There is no "MUST" for what "should" be in the Dataset at least as far as the Standard is concerned.  It can be used to send any information from the datamodel available in the IED as required.

 

When it comes to the DataSet which appears in the GOOSE message itself, it depends on whether the IED vendor has allowed only their predefined DataSets, or allows you to configure specific DataSets at the systems integration engineering stage, or allows you to create DataSets at any time in the operating device by commands.  Some vendors are more restrictive than others.

 

The principle of a Logical Node is that it defines the data model of "something"

 

If the "something" is a physical circuit breaker, then the XCBR LN is used and is defined in Part 7-4  (you should probably start by understanding Modelling described in Part 5)

 

You will see that XCBR in 7-4 has a DataObject called ".Pos"

On the right side of the XCBR definition you will see that ".Pos" is Mandatory for all XCBR LNs

You will also see in in the CDC column that this uses the Common Data Class "DPC" which is defined in Part 7-3

There you see that the full extended Data Attribute of "stVal" can have a "coded enum" value with the meaning of "intermediate-state | off | on | bad-state"

 

Hence if in the devices data model XCBR.Pos.stVal = 1 means the CB is off i.e. open.

XCBR.Pos.stVal = 2 means the CB is on i.e. closed

 

So assuming the device has some physical means of knowing the status of the CB then you could add XCBR.Pos.stVal as one of the elements in the Dataset.

Then the GOOSE will continuously send the status as a 1 or a 2.

If that element changes from 1-to-2 or 2-to-1 (or any other change if it is in transition or there is some form of anomaly bad state), the GOOSE will go into the fast repetition cycle

 

The reason I laboured that explanation is that the device may have a protection function with a LN as well.  eg a distance element.  This is modelled by PDIS LN

 

Similarly it is defined in Part 7-4 where you will see it has a Mandatory ".Op"

 

and similarly you will see it has a CDC of "ACT"

 

similarly in 7-3 you will see ACT has a various Attributes as ".general" which is Mandatory, but ACT also has ".phsA", ".phsB", ".phsC", ".neutral" which are all Optional (in the sense it is up to the vendor to decide to make them available in the datamodel or not.

We could, depending on vendor limitations as mentioned above and optional inclusions in the datamodel, add one or more of these elements into the Dataset.

PDIS.Op.general = 1 would mean the distance element has operated on one or more phases

PDIS.Op.phsA = 1 would mean that the A phase element of the distance function has operated

 

So you need to be very careful when buying IEDs - you should really know how you want to use them and what sort of information and messages you want to communicate in what fashion - i.e. if you specifically need to know which phase of the distance function has operated, then you need to make sure you buy IEDs that do have the  ".phsA", ".phsB", ".phsC", ".neutral"Attributes available - there are some moves afoot to create an ISD file ot specify this level of detail.

 

In the mean time, to be bluntly critical of the insufficient specifications I've seen all too often which simply say "all IEDs shall comply to the Standard" :

"Compliance" to the Standard does not necessarily mean "usable for your requirement"

 

 

Contact Me

Skype: (ping even if showing offline)
My status

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.