927   New SFD file

Created: 28 Sep 2012

Status: Future Improvement

Part: Part 6 (2009-12; Edition 2)

Links:

Page: 26

Clause: 7

Paragraph: all

Category: Issue for edition 3 of this part

Issue

The SSD file is intended to represent the primary plant and Logical Nodes for the system.
This presumes that it is known (to some extent) at the outset how many LNs may be required for the system related to the primary plant requirements and/or the performance requirements of the scheme.
Therefore the asset owner trying to specify their requirements needs to already have some idea of the IEC 61850 model implementation.

In previous engineering processes the asset owner would initially specify things in a generic sense eg "distance protection" or "device 21"

Beyond that simple statement are a lot of implied detailed modelling engineering must be done - 1/3phase, ph-ph/ph-g, number of zones, U/V, SOTF, CBF, PSB, U/F .. which a slightly more detailed specification would develop.
or a TF dif scheme requires 3 CTs on each side and a single CT on the neutral.

The current SSD effectively presumes a lot of this subsequent detailed model engineering has been identified in order to identify all the LN requirements - number of PDIS, PTOC, PTUF, PTUV, TCTR .... and in which physical devices they are needed (eg for conventional CTs you need TCTR in each IED whereas they only appear in Merging Units if used.

A full description is presented in the attachments.

Proposal

Create a new file type called SFD - System Functional Description.
Add 2 new DO to the Common LN section : LNType and GrRef

The SFD is a more generic functional specification not requiring specific LN instance identification.
This is combined with 2 new Data Objects: LNType (grouped/unique) and GrRef (linking a unique LN to its parent grouped LNType) These 2 new Dos in the Common section identify a hierarchy of LN relationships i.e. that a highlevel PDIS has certain DO/Att which are inherited by all the "sub" PDIS elements that have a GrRef to the 'parent' (Similar concept as LD Heirarchy)

Discussion Created Status
19 Jul 15 Future Improvement
A revised PPT was presented at WG10 in Mexico Feb 2013 - contact Rod Hughes directly for a copy
rgh
then the proverbial at
rodhughesconsulting.com
16 Feb 13 Not Applicable
An SSD file does not force to specify details which are not known or for the customer not relevant. it allows to specify details down to needed optional data objects and attributes without reference to any IED allocation. It allows to specify LN groupings in LDs even if iedname='None'. The LLN0.GrRef data object even allows to specify (IED relative) LD hierarchies.
Further, using the Substation section with Function / SubFunction elements and accompanying Text elements allows to specify or reference arbitrary texts and customer wanted function structures. Therefore I see no need for an Edition 2 enhancement with a new file type. Any additional work related to specification can be discussed in the working group for Edition 3.
16 Oct 12 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1