1229   LGOS.ConfRevNum should be ING

Created: 20 Mar 2014

Status: In Force (green)

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

Links:

Page: 25

Clause: 5.3.6

Paragraph:

Category: No impact on this part

Issue

The CDC for ConfRevNum is specified as INS and therefore grouped among the status information data objects. This was kept in the resolution of tissue #831. It doesn't make sense that a configuration/setting information is considered as status information. Neither the quality nor the timestamp attributes will ever change. They are therefore misleading. Also, clause 5.2 makes it clear that status information is produced locally. I don't think the argument in tissue #831 against changing it to ING is valid. Changing it to ING doesn't necessarily mean it can be written. See FC=SP in Table B.1 of 61850-7-3.

Proposal

Change the CDC for ConRevNum to ING and move it under settings.

Discussion Created Status
09 Sep 14 In Force (green)
I believe this is just a theoretical question. INT32 has a range of –2 147 483 648 to 2 147 483 647. If you follow the recomendation to increment by 10000 in case of offline changes (see part 6) then you have a lot to do to reach the limit. Generally it is in responsibility of the implementation (IED, tools) to supervise the limits.

To close this tissue, I suggest to reject the tissue again and the tissue goes to final proposal state. 		08 Aug 14 Ballot Period
The question is: how many setting are required by a LGOS to start the GOOSE supervision?
The current definition says: only GoCBRef.
Any other GoCB attributes that will be used for the proper supervision is a result of the GoCBRef.
LGOS.NdsCom = TRUE means: the subscription of the GoCBRef detects mismatch of expected vs got.
A SCT or ICT can set the GoCBRef but shall not take care of updating the ConfRevNum is the LGOS as soon as a configuration change led to update the ConfRev in the GoCB that whose supervision will be supervised. Therefore, ConfRevNum is already treated diffently.

25 Jun 14 Discussion (red)
How different is ConfRevNum from GoCBRef in terms of semantics? Isn't it also the expected GOOSE control block reference? I still do not see any reason why ConfRevNum is treated differently. 09 May 14 Discussion (red)
To conclude the tissue, the proposal will be rejected. 17 Apr 14 Discussion (red)
GoCBRef is already a setting. This should be the only setting authorized, otherwise, we have to deal with inconsistency of the Settings. GoCBRef and ConfRevNum.
GoCbRef being set by the configration is enoguh to perform a diagnostic of the GOOSE communication.
The other parameterization parameters are also to be taken from the SCL configuration: DatSet, DataSet content, Configuration revision number, GoId, and so on. and not display here.
Therefore, this is a status information: LGOS status is expecting a ConfRevNum. Changing the GoCBRef will change the ConfRevNum according to the SCL configuration that has been provided to the Subscriber.

The intention of LGOS is NOT to provide a dynamic GOOSE subscription interface but to provide a represention of the diagnostic of the configured GOOSE subscription. 		28 Mar 14 Discussion (red)
Not accepted. The semantic of LGOS.ConfRevNum clearly states: Expected configuration revision number. So this is not a setting, but a integer status as a result from the subscription configuration. 21 Mar 14 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1