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 about 3 years ago.
Updated 11 months ago.
Category:
Standard clarification required
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.
Discuss in Upcoming Meeting:
No
Short Proposal:
SCT must recognize 9-2LE as fixed configuration.
Needs More Information:
No
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.
- 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
- Discuss in Upcoming Meeting changed from No to Yes
- 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?
- 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
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.
- Standard(s) changed from TF Communication supervision to 61850-90-28
- Needs More Information set to No
Also available in: Atom
PDF