831   Setting of ConfRevNum in LGOS

Created: 13 Mar 2012

Status: In Force (green)

Part: Part 7-4 (2010; Edition 2)

Links:

Page: 25

Clause: 5.3.6

Paragraph: LGOS

Category: Issue may impact interoperability of implementations of Edition 2

Issue

The LN LGOS defines ConfRevNum as a "STATUS" value and to be the "expected Configuration Revision Number" with CDC of INS. I believe that this is incorrect as the "Expected" value should be a setting from the configuration. The STATUS value should reflect the value of ConfRev as set in the Received GOOOSE message. I note that the other DOs in the list (e.g. NdsCom, SimSt, and LastStNum) are all values from the Received GOOSE message. ConfRevNum should be the same. Additionally, I suggest that the semantic should be changed to ConfRev to match the semantic of GOOSE.

A new SETTING should be created - ExConfRev - for Expected Configuration Revision. This value should be an Integer Status Setting (ING)

Proposal

Change ConfRevNum to ConfRev to match the semantic of GOOSE
Change the definition of the STATUS value to be the Configuration Revision of the RECEIVED GOOSE message
Add a new SETTING - ExConfRev - for Expected Configuration Revision with a CDC of ING

Note that this issue is identical with the LSVS LN

Discussion Created Status
05 Oct 12 In Force (green)
several definition missing in the semantic table + harmonization with UML task force.
see attached document for complete definitions.

1) NdsCom does not exist in Table 10, but SbsNdsCom.
-> change Table 10 for backward compatibility and keep NdsCom .

2) According to discussion in Berlin: NdsCom is not clear.
-> change text to: “Subscription needs commissioning, i.e. when true, the received message does not conform the current subscription configuration; either the dataSetRef is wrong, the data set members, the configuration revision number, …”

3) According to discussion in Berlin / Tissue 831: definition of ConfRevNum is not clear.
-> Add DOI RxConfRevNum (INS): Configuration revision number of the received message. If no telegram is received, the attribute q.validity is set to invalid.
-> DOI ConfRevNum (INS): Expected configuration revision number

4) According to Mark Adamiak, other diagnostic information is missing.
- GOOSE: DatSetRef + RxDatSetRef? GoID + RxGoID? NdsCom? DataSet structure mismatch? Authentication failure?
- SV: SvID + RxSvID? DatSetRef + RxDatSetRef? DataSet structure mismatch? SmpRate? Authentication failure? numOfASDU mismatch?
-> Wait for Requirement, i.e. document of Mark Adamiak. When the requirements are defined, open a new tissue with proposal for further extension.

5) DO St definition is missing in Table 10.
-> add St definition according to UML Task Force definition: “if true, the multicast subscription is active, other is inactive.”

6) DO SimSt
-> change definition to UML Task force definition: “If true, multicast subscribed messages with the simulation bit set are being received and accepted.”


7) There is no State Number in an SV value format
-> remove DOI LastStNum from LSVS.
27 Jun 12 Discussion (red)
ING implies that this can be set via setting services. This is NOT the case, this value is derived from the CID file or similar configuration data used to configure the IED communication part, and needs to be tightly coupled to the 'known' data set structure at the sender. Therefore I would leave it as INS.
If we have GOOSE only senders, then it might be helpful to also supply the really sent confRev value - however as a mismatch should only occure at commissioning time, then also other tools should be available to find its value respective the reason for any detected mismatch. 		14 Jun 12 Discussion (red)
7-4 states that ConfRevNum expected configuration revision number.
I agree that ING is probably a better CDC for an expectation.
There is howver no need to change to DO name. 		20 Mar 12 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1