The last paragraph states: “For the identifier source, the higher level of the multiple client-server relationship shall dominate over the lower level.”
My interpretation of it would be that in case an XCBR.Pos gets substituted, the related processing functions, like a CSWI, will still provide the CSWI.Pos with the quality.source information "process", because the substitution was made on a lower level.
I think this is the right interpretation but it is nowhere written, even worse this interpretation gets confused in the following chapter 6.2.8. There the propagation of the quality.source is described from lower level to upper level. My interpretation is that we have here the description of a proxy implementation, even this is not indicated. In case of a proxy approach the chapter 6.2.8 and the related examples would be right.
(In edition 2.1 this part is moved as an Annex of 7.2)!
Because we had to clarify this topic repeatedly I think we should make it clear in the standard. Otherwise we will end up with different interpretations and implementations.
Proposal
Clarify that in chapter 6.2.8 a proxy approach is described.
In this case all quality attributes (including source) shall be propagated from the lower level to the higher level.
Add a chapter (6.2.9) For a non-proxy relationship (like between an XCBR and CSWI or YLTC and ATCC or TCTR and PTOC or XCBR and CILO) new information will be provided based on computation of information received. The quality information of such computed information have no 1:1 relation to each other (CSWI.Pos is not a proxy of XCBR.Pos).
The quality.source.substituted shall be indicated only on the level where the substitution was made (and thus not propagated, e.g., from XCBR.Pos.q.source to CSWI.Pos.q.source).
Discussion
Created
Status
Topic is treated in Part 5.
This Tissue is put onHold
26 Apr 18
Future Improvement
The examples should also show the expected client side behaviour. Combining substitution information from different sources (e.g. XCBR and CSWI) will make the system more complex and less reliable. The CSWI value and quality cannot be trusted no longer.
26 Aug 15
Discussion (red)
An updated and completed set of examples illustrating the rules is given in attachment ("Inheritance of quality between logical nodes extended.docx").
Besides the XCBR/CSWI examples, it has some TCTR/MMXU and TCTR/PTOC/PTRC examples.
21 Jul 15
Discussion (red)
The NC Germany (DKE AK952.0.10) has discussed the proposed resolution from the last WG10 meeting. They don't agree with the formulation and may be also with the content (seems too general and not always correct). The resolution of the tissue shall be illustrated by different examples (propagation based of communication failures already exists in 7-3, but different application might show different behavior). The tissue shall be kept as red. It impacts edition2.1.
18 Jun 15
Discussion (red)
Decision at WG10 meeting in Regina: general rules on quality propagation.
If DO belongs to a proxy/mirror LN, then its quality shall be the same as the origin as long as the proxy/mirror LN.Beh=on. Notes:
- the quality in the proxy/mirror can be substituted, in which case it might not be the same as in the origin.
- If the proxy/mirror LN.Beh <> on, special rules 1 and 2 below apply.
Otherwise (DO does not belong to a proxy/mirror LN):
1. If the (receiving) LN.Beh=off => for all q in the LN, quality.validity = invalid; other quality attributes are then irrelevant.
Regardless of the quality of incoming messages.
2. If the (receiving) LN.Beh={test, test/blocked}, for all q in the LN, quality.test=true
Regardless of the quality of incoming messages.
3. Quality.source is never propagated.
4. Quality.operatorBlocked is never propagated.
5. Quality.detailedQuality is never propagated.
6. Quality.validity is never propagated within an LN (i.e., from input signal to LN to output DO of LN), however:
- For “computed/process state” DOs (e.g., CSWI.Pos, MMXU.TotW, ATCC.TapPos/TapChg): Quality.validity cannot be better than the source quality.validity, except if higher quality information can be derived from other sources (redundant data, using measurements, etc.).
- For “action” DOs (Op*, TapOp*, Tr, Blk, *Str, …): quality.validity shall be good even though the input signal’s quality is not good.
Note: quality can also be substituted (e.g., with automatic function or subQ + subEna)
11 Jun 15
Discussion (red)
The discussion in the last WG10-meeting in Tokyo came to the following results:
The explanation of substituted values shall be improved by differentiating between client-server connections and automatic functions (e.g. aggregation of CB position in XCBR, propagation of substituted value in CILO etc.).
It has to be clarified in general what is the quality of calculated value if inputs have different qualities.