1840   The role of smpRate of MV/CMV

Created: 18 Aug 2022

Status: Discussion (red)

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

Links: #1850 The role of smpRate of MV/CMV (for attaching figures) , #1838 LNGroupS looks more like for processing/automation functions

Page: 51, 53

Clause: 7.4.3, 7.4.4

Paragraph: table 30, 31

Issue

Please link this tissue with tissue 1838.

Statement 1: According to 61850-500 (clause 11.1.3, 1st paragraph):
"The general conclusion is that also without process bus, all boundary LNs (LNs starting with T and X) should be present in the IED if applicable. This also refers to the T nodes if the samples are not released out of the IED because only an application function inside the IED needs these samples."
Statement 2: According to 61850-500 (clause 9.2, figure 8) LN Sxxx looks like bay level logical nodes, which get samples from boundary LN Txxx.

In this case: what is the role of MV.smpRate (CMV.smpRate)? LN Sxxx already receive SAMPLES... Or CMV.smpRate just show HOW OFTEN the function update input data for actualizing MV.instMag (CMV.instCVal)?
If yes - why the description of CMV.smpRate mentions only 'mag' (without 'ang'): "... used to determine instantaneous value 'instCVal.mag'"?

Proposal

Please, clarify using of MV/CMV.smpRate and correct the description of CMV.smpRate.

Discussion Created Status
After the consideration of previous comment:

The different Levels of defining the sample rate shall be understood as follows:

Clarification for DOI SmpRte for IEC 61850-7-4:
- TCTR indicates the rate at which the analog signal has been sampled and is a characteristic of the sensor (7-4)

Clarification for MSVCB.SmpRate for IEC 61850-7-1
- If sampled value transmission is used, MSVCB.SmpRate indicates the sample rate used for transmission, which may include a downsampling. The configured transmission sample rate shall match one of the supported sample rate specified in the name variant of the publisher according to a product standard if existing. In case of current and voltage transmission, the name variant is specified in the product standard IEC 61869-9. (7-1)

- The DA smpRate indicates the sample rate used to calculate the value of the associated DO, which may include a downsampling or upsampling from the source value that is received either directly from TCTR or over sampled value communication.

We propose to clarify the explanation of DA smpRate in 7-3 as follows:
in CDC CMV:
Samples per nominal period that has been used to determine instantaneous values 'instCVal.mag' and 'instCVal.ang'. This may include a downsampling or upsampling from the source value that is received either directly from TCTR or over sampled value communication

in CDC MV
Samples per nominal period that has been used to determine instantaneous values 'instmag'. This may include a downsampling or upsampling from the source value that is received either directly from TCTR or over sampled value communication. DA smpRate shall not be used for DOs, where the value is not related to an ac system


In response to the question in the comment:
INT16U type in control block/MTS vs INT32 (ING) type in 7-4, this is not a problem, and this is resulting in usage of existing CDC (ING) to expose INT16U values.
18 Jan 23 Discussion (red)
Think this TISSUE also needs to factor in the name variant for SV based signals. The name variant should take priority over the sampling rate and frequency elements, and mismatches between MSVCB.SmpRate (and system frequency) should be cross-checked against configured SV variant (FXXXXS#).

Secondly, there are data type mismatches between SmpRates. The SV service tracking (MTS) is using INT16U, and the others are INT32U. Is this deliberate?
24 Dec 22 Discussion (red)
The different Levels of defining the sample rate shall be understood as follows:
- TCTR indicates the rate at which the analog signal has been sampled
- If sampled value transmission is used, MNSVCB.SmpRate indicates the sample rate used for transmission, which may include a downsampling
- The DA smpRate indicates the sample rate used to calculate the value of the associated DO, which may include a downsampling or upsampling from the source value that is received either directly from TCTR or over sampled value communication

We propose to clarify the explanation of DA smpRate as follows:
in CDC CMV:
Samples per nominal period that has been used to determine instantaneous values 'instCVal.mag' and 'instCVal.ang'. This may include a downsampling or upsampling from the source value that is received either directly from TCTR or over sampled value communication

in CDC MV
Samples per nominal period that has been used to determine instantaneous values 'instmag'. This may include a downsampling or upsampling from the source value that is received either directly from TCTR or over sampled value communication. DA smpRate shall not be used for DOs, where the value is not related to an ac system
20 Dec 22 Discussion (red)
"We must not make definitions about the relations of the sample rates at different stages in the signal processing chain." - good point. I agree.

But in any case more detailed clarifications of Txxx.SmpRte, MSVCB.SmpRate and MV.SmpRate are needed.
Now it's very hard to understand what's the difference between them.
27 Oct 22 Accepted
We must not make definitions about the relations of the sample rates at different stages in the signal processing chain. This may restrict possible beneficial implementations. Any kind of resampling (also upsampling!) shall be allowed in a technical implementation. If the resulting signal quality satisfies certain applications must be individually assessed.

Also, the statement "MSVCB1.SmpRate indicate how often IED1 give away to communication network SV messages" may not be correct.
This also depends on the sample packing (# of ASDUs per APDU).
27 Oct 22 Accepted
Yes, Christoph, understand the comment correctly.
1)
Comments for the first explanation: Ok, 61850-500 is TR. But it is strange if just MMXU is used to present 3-phase measurement function, without LN Txxx.
From my point of view, we SHALL use «boundary» LNs (Txxx, Xxxx, Yxxx, Zxxx) in modeling. «Boundary» LNs «virtualize» outside (from IED point of view) values: «boundary» LNs look like link between physical and virtual world.
Comments for the second explanation: great example!
Please check my figures, which I have attached to tissue 1850 (I can't attach the figures to this comment). The figures contain all comments.
Variant 1: Variant 1_Sensor is not in the same device.
Variant 2: Sensor is in the same device.
If you agree with the content of the figures – descriptions of Txxx.SmpRte, MSVCB.SmpRate and MV.SmpRate should be updated. The figures could be a base for clarification.
2)
The need to change the description of CMV.smpRate depends on decision of the first part of the tissue.
26 Oct 22 Accepted
If I understand the comment correctly, there are two issues:

1) The question, why do we need as part of an Analog value the sample rate (e.g. DA smpRate in CDC MV), when we assume that there is as well the Txxx LN present that includes a DO with the sample rate (e.g. TCTR.SmpRte).

2) And related, the comment on the description for CMV.smpRate which refers only to mag.

On 1)
- One explanation could be that 61850-7-500 is only a TR and provides only recommendations, so we still can express the sample rate e.g. in the MMXU
- Another explanation could be as well, when the sensor is not in the same device: The sensor may have a sample rate that is not necessarily the same as the sample rate used for the SV transmission. E.g., a sensor may be able to sample at a high frequency as used for power quality. The MU may then support both the protection frame and the PQ frame according to 9-2LE guideline. So how would such a MU be modeled? Just one TCTR or two? If only one TCTR, it would indicate the high sample rate; but if my MMXU uses the protection frame, it would indicate a different sample rate.

But yes - I agree that this may require clarification.

On 2)
We may change the description to that it applies to the calculation of just instCVal



25 Oct 22 Accepted

 

Privacy | Contact | Disclaimer

Tissue DB v. 22.12.20.1