Project

General

Profile

Feature #597

SCTs updating the confRev of 9-2 LE Sampled Value streams - problem with subscription to test tool SV injection

Added by Herbert Falk almost 2 years ago. Updated 4 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Standard clarification required
Start date:
Due date:
% Done:

0%

Estimated time:
Spent time:
ID:
1120
Source:
IOP_2019
TF Unique ID:
1120 # IOP_2019
WG10 Proposal:

- ConfRev in the message serves the purpose that the subscriber/client needs to be reconfigured- Reconfiguration may be dynamic (e.g. a client retrieving from the server the changes)- Based on that – detailed rules need to be defined, in what cases confRev needs to be increased ? this is currently discussed in the TF communication supervisionFeb-20: CRC: Check with Christophe CamelisJun-20: There are still discussions about ConfRev. A NWIP will be launched.

Estimated Completion:
Discuss in Upcoming Meeting:
No
To discuss in WG10:
No
Short Proposal:

SCT must recognize 9-2LE as fixed configuration.

Standard(s):

TF Communication supervision

Needs More Information:

Description

SCTs updating the confRev of 9-2 LE Sampled Value streams.
9-2 LE states attribute ConfRev to always have the same value.
Hence, the test tools which inject 9-2LE SV streams wouldn’t allow the user to modify the confRev.

But, the IEDs which do a check on the confRev of SV stream(s) before accepting the to 9-2LE streams wouldn’t subscribe to the SV streams from the test tools as there is a mismatch between the confRev of SV from the test tool (which is 1) and confRev of SV which the IED is expecting (as defind in the SCD).

1. The SCTs shouldn’t increment the confRev of 9-2LE SVs.
2. Suggestion: the IEDs accepting 9-2LE streams should perform a check on the confRev and should declare this in the PIXIT.


Proposal descriptions

Routed to TF 90-28 Communication supervision.

#1

Updated by Vladan Cvejic almost 2 years ago

  • Subject changed from SCTs updating the confRev of 9-2 LE Sampled Value streams. 9-2 LE states attribute ConfRev to always have the same value. Hence, to SCTs updating the confRev of 9-2 LE Sampled Value streams - problem with subscription to test tool SV injection
  • Status changed from New to In Progress
  • WG10 Proposal changed from - ConfRev in the message serves the purpose that the subscriber/client needs to be reconfigured - Reconfiguration may be dynamic (e.g. a client retrieving from the server the changes) - Based on that – detailed rules need to be defined, in what cases confRev needs to be increased ? this is currently discussed in the TF communication supervision Feb-20: CRC: Check with Christophe Camelis Jun-20: There are still discussions about ConfRev. A NWIP will be launched. to - ConfRev in the message serves the purpose that the subscriber/client needs to be reconfigured- Reconfiguration may be dynamic (e.g. a client retrieving from the server the changes)- Based on that – detailed rules need to be defined, in what cases confRev needs to be increased ? this is currently discussed in the TF communication supervisionFeb-20: CRC: Check with Christophe CamelisJun-20: There are still discussions about ConfRev. A NWIP will be launched.
  • Discuss in Upcoming Meeting set to No

Checking done.

#2

Updated by Carlos Rodriguez del Castillo 7 months ago

  • Discuss in Upcoming Meeting changed from No to Yes
#3

Updated by Herbert Falk 7 months ago

  • To discuss in WG10 set to No

Please note that the issue of confRev should take into account the case where a 61869-9 variant dataset is not 9-2LE compatible and then the variant and dataset is changed back to be "compatible" with 9-2LE subscribers. 9-2LE specifies that the confRev shall be 1. Does a non-one(1) value for confRev create an Interoperability problem?

#4

Updated by Vladan Cvejic 7 months ago

  • Status changed from In Progress to Resolved
  • Discuss in Upcoming Meeting changed from Yes to No
  • Proposal descriptions updated (diff)
  • Standard(s) changed from TF Communication superivison to TF Communication supervision
#5

Updated by Christophe CAMELIS 4 months ago

Check of confRev has been already considered for SV validation.
Regarding engineering rules, behavior related to increment of ConfRev has been defined in the TR, including special rule for 9-2 LE.
So, nothing to be done on subscriber IED side.

Also available in: Atom PDF