A. FCDA not in Reports
----------------------
In 14.2.3.2.2.9 the values to be reported are from Data only (FCD). FCDA are not allowed to this definition.
In 11.2.2.3 we allow FCDA as members of DataSets.
To allow reporting FCDAs we need to revise the specification in 14.2.3.2.2.9 accordingly.
B. FCDA Components not supported in DataSet and Reporting (Logging, ...)
-------------------------------------------------------
FCDAs may be composed of several components:
mag value is of type AnalougeValue
Instances of AnalogueValue may have one or two components:
i only
i and f
f only
If both components are implemented, then a report (log entry, GOOSE message, SV message) would contain BOTH values (i AND f) according to 14.2.3.2.2.9 because there we allow FCD (and may be in future FCDA) only.
According to 11.2.2.3 members could be FCD and FCDA only.
Currently a report has to carry the values of ALL DAComponents. In case of AnalogueValue with i and f we could reduce the number of values to be transmitted up to 50 per cent. Therefore it is recommended to constrain the values for reporting (logging, ...) to DataAttributeComponents as well.
Proposal
A. Revise the specification in 14.2.3.2.2.9 to allow to report FCDA
B. Revise the specifications in 10.2.2.4.5 / 11.2.2.3 / 14.2.3.2.2.9 accordingly.
Discussion
Created
Status
Definition of FCDA
A reference of a single DataAttribute of a DATA (or attributes of a control block) having a specific functional constraint (FC) value shall be called functional constrained data attribute (FCDA).
Shall be changed to:
A reference of a single DataAttribute of a DATA or a DataAttributeComponent of a DataAttribute or a attribute of a control block having a specific functional constraint (FC) value shall be called functional constrained data attribute (FCDA).
Therewith, the FCDA definition has been extended. No constrain is needed.
18 Apr 07
Ballot Period
To be discussed with editors ...
15 Feb 07
Discussion (red)
The mapping in 8-1 can support this. It is constrained because of 7-2. We should not be changing this at this time. When this has been discussed in the past, only FCD and FCDA was the decision.
I would rather keep 7-2 unchanged except for allowing SCSMs to allow additional levels (e.g. flattened MMS Named Variables at the "leaf" level could be allowed in 8-1).
14 Sep 06
Triage
Additional note on case A:
Figure 23 (page 86) shows the case of FCDA ... (Pos.stVal, ..) which is what we want. But this is not supported by the definition in the text.
The mapping to MMS does not allow the right example in Figure 23. One member is XCBR1.Pos. According to 61850-8-1 we have always FC in the ObjectReference: XCBR1.ST.Pos, XCBR1.CF., ...
Figure 23 and the text should be revised as well. We should - of course - not update the example using 8-1 constraints! But we may add a note that SCSMs may constrain this behaviour.