1790   Exposing Configured Variants in SCL

Created: 02 Sep 2021

Status: Not Applicable

Part: Part 7-4 (2020; Edition 2.1)

Links:

Page: 21

Clause: 6.906.3

Paragraph: Various

Issue

There are currently no means to expose the variant(s) that have been configured in a SV publisher. Only the variant capabilities are exposed using LPHD.NamVariant, but the configured variant(s) are also required for engineering purposes.

Proposal

Propose a DO extension to the LLN0 that exposes the actual configured variants for each Logical Device. LLN0.ConfVariant (VSS). This new DO is required to support the system engineering process.

See attached proposal for LLN0.ConfVariantLLN0.ConfVariant

Discussion Created Status
Approve N/A 11 Oct 22 Not Applicable
After discussion within Group of experts and within UCAiug I would keep state N/A as it was already
19 Apr 22 Approval (N/A)
Back to discussion 19 Apr 22 Discussion (red)
back to the Ed2.1 technical issue

Tissue requester claims "There are currently no means to expose the variant(s) that have been configured in a SV publisher." -> this is not a true statement, as Ed2.1 compliant server implementations do expose all required information that need to be cosidered to derive the configured variant, both in the SCL file as well as over a TPAA.

Tissue requester "Propose a DO extension to the LLN0 that exposes the actual configured variants for each Logical Device. LLN0.ConfVariant (VSS). This new DO is required to support the system engineering process."

VSS implies an Ed2.1 compliant implementation -> as mentioned above, Ed2.1 compliant implementations expose all necessary information to derive the configured variant.

F is representing the sampling frenquency and can be derived from the SmpRate / SmpMod MSVCB attributes, as well as the TxTR.HzRtg setting vaules.
S is representing the number of ASDU is present in the noASDU MSVCB attribute (extended definition from IEC 61850-9-2 Ed2.1)
The number of currents and of voltages can be derived from the DataSet definition that is associated to the MSVCB.

A tool can easily convert the configuration (from SCL or from the run time model over the MMS communication) to expose the configured variant.
This is not interoperability problem but a tool implementation / representation issue.
I support the N/A category.


What has been identified in Golden Meeting and raised via Tissue https://iec61850.tissue-db.com/tissue/1673 is about the supported variants at the subscriber. This is out of scope of this tissue that is requesting extension of the publisher model not of the subscriber.
The variant supported by the subscriber to allow a interoperable engineering is to be discussed on the tissue 1673.
Note: this is true that the configured variant may not be derivable for Ed1/Ed2 SMV publisher, as the Rated Frequency HzRtg may not be visible in the implemented TxTR. Nevertheless, the tissue does not help, as the tissue propose a change for Ed2.1 publisher and not for Ed1. or Ed2 publisher.





12 Apr 22 Approval (Future Improvement)
Reading the comment of Dustin I think this is something that WG10 shall discuss: do we want to support dynamical configuration of SMV of MU? Do we need to declare this capabiity in e.g service section or in PICS/PIXIT?

Therefore this discussion should stop here and should be continued in WG10. Change to state Approval (Future Improvement). 		12 Apr 22 Approval (Future Improvement)
Change back to state Discussion to change all comments to public (even I didn't get a notification that I have to make them public.) 12 Apr 22 Discussion (red)
I believe there is a misunderstanding of the question, as well as an inaccurate response. Here is a clarification of both:

Misunderstanding of the question: The focus is on having this exposed via SCL and not what is available over the wire (via IED).

Inaccurate response: I agree in some cases the name variant can be derived using elements, but this is not always the case depending on the edition of 9-2, the 61869/9-2LE profile, and how the sampling rate/mode was configured. In some cases the system frequency is required to derive the sampling rate (F####), which is not always available in SCL. There is also a backwards compatibility issue with 9-2E. See TISSUE 1673. https://iec61850.tissue-db.com/tissue/1673#comment9130. Ironically I recall Thierry had raised this concern in the Golden WG10 meeting.

The proposed resolution to parse out various SCL parameters (in hopes they are all available) and then derive the variant, rather than using a standard element is disjointed. We already have a similar element (LPHD.NamVariant) defined in SCL to define IED’s SV capabilities, but need something similar to define IED’s SV configuration. Expecting the SCL tool to piece-together the name variant using elements that may (or may not be available) seems like an insensible approach. E.g. Asking a tool to count the number of CT/VT channels in each data set to derive the I##U##. Tools will derive the name variants differently, and this will lead to SCL interoperability issues.
11 Apr 22 Approval (N/A)
I retract my previous comment.
Upon further examination, I see "S" is exposed as MSVCB.noASDU since Ed (61850-9-2:2011. Therefore even "dynamic configuration" of sampled value subscription is possible. 		08 Apr 22 Approval (N/A)
I think the requester is considering "dynamic configuration" where the publisher capability is discovered ONLY by retrieving data across-the-wire and the SCL file was not consulted.

61850-6 defines a valid device (including a client/subscriber) as mandatory to read the SCD file.
Therefore I agree that this is NOT an interoperability issue but only a non-conformant subscriber.

I think WG10 needs to declare that discovery of capabilities over-the-wire is only a SUPPLEMENT to the SCL information and not all SCL information will be part of device data models. 		07 Apr 22 Approval (N/A)
Unquestionable, this topic is not an interopability issue.
We should state it as N/A (see also justification in Thierry's answer). 		07 Apr 22 Approval (N/A)
Well, I'm unsure, since the requester's proposal reads: "This new DO is required to support the system engineering process." Hence, the data already available in SCL is sufficient for a system engineering tool. 07 Apr 22 Approval (N/A)
I think there is a misunderstanding here. Requester is asking for values which are alreadyin the SCL file to be available online. Presently, MSVCB.Rate/SmpMod correspond to "F" and MSVCB.DatSet allows discovery of IxUy but there is no way to discover the "S" parameter (nofASDU).
Perhaps it could be argued that nofASDU is not needed online because each data frame has the value encoded in it. 		07 Apr 22 Approval (N/A)
F is representing the sampling frenquency and can be derived from the SmpRate / SmpMod MSVCB attributes.
S is representing the number of ASDU is present in the noASDU MSVCB attribute (extended definition from IEC 61850-9-2 Ed2.1)
The number of currents and of voltages can be derived from the DataSet definition that is associated to the MSVCB.

A tool can easily convert the configuration (from SCL or from the run time model over the MMS communication) to expose the configured variant.
This is not interoperability problem but a tool implementation / representation issue.
I support the N/A category.
06 Apr 22 Approval (N/A)
This statement is not true. Please explain where the configured variant (F####S#I#U#) is exposed in the MSVCB. 06 Apr 22 Approval (N/A)
Answer to tissue requester: The variant(s) that has(have) been configured is(are) visible in the configured control block(s). Another DO will create a possible inconsistency.

The tissue is proposed to be rejected and changed to "Approval (Not applicable)". 		06 Apr 22 Approval (N/A)
Yes, I would recommend that "Exposing Configured Variants in SCL" in a publisher be changed to status "Approval N/A".

Are you suggesting to move the subscriber issue to another TISSUE? I am reluctant to do this until UCAIug TPWG forms a consensus opinion. 		04 Apr 22 Triage
I understand your comments that this tissue can be changed to Approval N/A, right?
04 Apr 22 Triage
Agree that there is no problem to be solved for publishers.
But UCAIug TPWG is considering SCL changes for a SV subscriber to declare subscriber capability:
- Rate/nofASDU/current-channel-range/voltage-channel-range (proposal is to use same format as LPHD.NamVariant)
- Maximum number of subscribed channel in a single stream

See https://redmine.ucaiug.org/attachments/download/2500/R5308_proposal_Ed2p1_20220327.docx for the draft TPWG proposal to temporarily insert this information into the PIXIT.

Perhaps this subscriber discussion should be moved to a new TISSUE

04 Apr 22 Triage
Agree with Thierry, the requested information is already available.

Further, this would seem to require all SV streams in the LD to have the same config?

Suggest NotApplicable.
04 Apr 22 Triage
The variant(s) that has(have) been configured is(are) visible in the configured control block(s).
What is the use case of exposing the information both in the control block as well as in an object?
Duplicating information is always associated to system inconsistency.
Not in favor for such an DO(s).

04 Apr 22 Triage
Changed part from Part 9-2 (related to IEC 61869-9; 2016) to Part 7-4 (2020; Edition 2.1). 26 Feb 22 Triage
To add a DO, it must be in 7-4 or 61869-9. It is not an SCL issue unless instead of a DO (which would be observable at runtime) the desire is to convey the capabilities. That would require an analysis of the services section in SCL.

Either way, the issue needs to be moved (e.g. 7-4) or changed. 		02 Sep 21 Triage

 

Privacy | Contact | Disclaimer

Tissue DB v. 24.12.6.1