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" |