Feature #597
SCTs updating the confRev of 9-2 LE Sampled Value streams - problem with subscription to test tool SV injection
0%
- 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.
SCT must recognize 9-2LE as fixed configuration.
61850-90-28
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.
Updated by Vladan Cvejic almost 4 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.
Updated by Carlos Rodriguez del Castillo over 2 years ago
- Discuss in Upcoming Meeting changed from No to Yes
Updated by Herbert Falk over 2 years 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?
Updated by Vladan Cvejic over 2 years 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
Updated by Christophe CAMELIS about 2 years 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.
Updated by Carlos Rodriguez del Castillo over 1 year ago
- Standard(s) changed from TF Communication supervision to 61850-90-28
- Needs More Information set to No