1. The computation of Beh.stVal does not take into account LD hierarchies in Part 7-4. The rules for computing the Beh of a child logical device should be made explicit.
2. Further, on page 122, it is stated: "The behaviour of a logical node is therefore a combination of LLN0.Mod and XXXX.Mod and is described in the ”LNBeh” = XXXX.Beh."
This is incorrect. The Beh of XXXX should be the combination of LLN0.Beh (and not Mod) and XXXX.Mod.
3. Additionally, the "combination/dominance" rules for the BehaviourModeKind values should be explicitly stated. For instance, if the root LD is in off mode, setting a child LD into test (through setting Mod) should still have that child LD in off mode (as well as any LN in that child LD). On the other hand, if the root LD is in test mode, then a child LD can be put in off mode.
4. Moreover, as Mod is optional (except for the root LLN0), the rules should take into account the case when Mod is missing (for a child LD and for a domain LN).
Proposal
1. See point 4 below.
2. See point 4 below.
3. Dominance rules could/should be: the higher the int value of the BehaviourModeKind enumeration value, the more dominant. In other words, "on" is the weekest, off is the most dominant. Thus: test "dominates" blocked.
BTW: this has also the advantage that if private extensions are used, i.e., only in the negative range), these will be dominated by the standardized ones.
4. The rule should be divided in two: in case Mod is here and in case Mod is not present: (XXXX is a domain LN below, & is the combination according to dominance rule in 3)
If Mod is present:
root LLN0.Beh ::= root LLN0.Mod
child LLN0.Beh ::= direct_parent LLN0.Beh & child LLN0.Mod
XXXX.Beh ::= sibling LLN0.Beh & child LLN0.Mod
If Mod is not present:
root LLN0.Beh ::= root LLN0.Mod (Mod is always present for root LD)
child LLN0.Beh ::= direct_parent LLN0.Beh
XXXX.Beh ::= sibling LLN0.Beh
Discussion
Created
Status
The proposal to correct the headlines reg. Beh is accepted. Replace in the second column LDMod LLN0.Mod by LDBeh LNN0.Beh.
26 Mar 14
In Force (green)
The description of issue is formally right, but I don't think that there is a bug. Although the issue is already described in the standard (except an editorial error).
1) First of all, I totally disagree to allow private extensions for Mod/Beh. It contradicts interoperability. May be we have to state this somewhere,
2) Dominance rules is wrong. Looking at the Beh-table shows me that there are exclusions of a simple week-most dominant algorithm ( test and on-blocked --> test/blocked, what is more than test).
3)In the equations for the case Mod is present, it must be XXXX.Beh::= sibling LLN0.Beh & XXXX.Mod (not clid LLN0.Mod).
4) If XXXX.Mod or LLN=.Mod (not in the root) is not present, we don't need a additional equation. XXXX.Mod is not present and therefore it cannot have an influence.
5) We have in ed.2.1 to correct the headlines of table reg. Beh by just replacing in the second column LDMod LLN0.Mod with LDBeh LNN0.Beh. Then, in my opinion, the table works as it is.
The text on top of this table can be improved by the one what Klaus-Peter has suggested. I support his proposal.
Please consider also part 7-1 (e.g. fig. 49) and its explanation. Here the equations can be added.
31 Jan 14
Discussion (red)
This error regarding Mod/Beh comes from Ed1 one where the defintions regarding Mod and Beh have been valid since there was only the 2-level hierarchy of LD (LLN0) and the domain LN XXXX. This bug in Ed2 may be fixed most easily by the following "editorial" changes. In the "semantic" clause 6 of Ed2 (refers to clause 7 in Ed2.1) text of Beh has to be replaced by the following text:
(LLN0) Read-only value, describing the behaviour of the logical device. For a root logical device, it is the same as the mode ('LLN0.Mod'). For non-root logical device, it depends on its own current operating mode ('LLN0.Mod'), and the current operating behaviour of the logical device that contains it (containing 'LLN0.Beh').
DomainLN) Read-only value, describing the behaviour of a domain logical node. It depends on its own current operating mode ('DomainLN.Mod'), and the current operating behavior of the logical device that contains it ('LLN0.Beh'). Processing of the quality status ('q') of the received data is the prerequisite for correct interpretation of 'DomainLN.Beh'.
The headline of the Beh table (in clause6 of Ed2, Figure 30 in subclause 7.2.4 in Ed2.1)has to be updated as in the Attachment.