908   ARIS.StrSeq - transient

Created: 24 Aug 2012

Status: In Force (green)

Part: Part 7-4 (2010; Edition 2)

Links:

Page:

Clause: 5.4.4

Paragraph:

Category: Issue for edition 2 of this part

Issue

In the LN ARIS (Resistor control) the DO StrSeq (Start sequence)(SPC) should be transient because the falling edge makes no sense.

Proposal

Specify as transient. Adapt in the description: "(controllable) Operating with value true initiates the start of the resistor switching sequence; operating with value false is ignored. The change of its status value is a local issue."

Discussion Created Status
Final proposal would be:
Specify as transient. Adapt in the description: "(controllable) Operating with value true initiates the start of the resistor switching sequence; operating with value false is ignored.
Data object stVal shall become TRUE when the sequence is started (output to the process). 		10 Oct 12 Ballot Period
Generally, we support the proposal that for each data object of a CDC SPC, it shall be explained if the related stVal is:
- the feedback from the process (never Transient)
- the output to the process - if started the value is TRUE; if finished the value is FALSE. If we can not determine the finish, the Data Object shall be declared as Transient.

This needs to be done for all DOs of CDC SPC (similar to DOs with CDC APC)

In this specific case described in the TISSUE, stVal shall become TRUE when the sequence is started and the DO shall be Transient. 		27 Sep 12 Discussion (red)
I am not sure if we always can generalize explanations. If we want to do that, we may need to introduce new common data classes (it is somehow similar to the discussion about APC and ASG).

We may have several cases:

(a) objects, that directly control something in the process; e.g. you switch on and off a light with a SPC. In that case, the stVal is the result of the activity - i.e. if the light is on or off.

(b) something like a switching sequence that you start and that is then running for a certain time; but the result is something completly decoupled from the DO that is used to start the switching sequence (e.g. it can be many different status values that change). In that case we can generalize the status value such that it shall change to the value true when the switching sequence has been started and that it shall change back to false when the sequence has been tterminated (i.e. the last output has been generated or the last activity has been terminated; we need to agree on one of these two options)

(c) Something that you start, but that does not have a duration. In that case the explanation for the status would be that it shall change to the value true when the action has been started and the DO would be transient. 		28 Aug 12 Discussion (red)
In the UML TF, we spend long hours to agree on documentation of DOs, as per their type (CDC), and we landed with the common "template" for SPCTransient-s as above. So,
- if the documentation of all SPCTransient-s ("local issue") is not right, please provide the fix for all concerned CDCs, we have to change it uniformly;
- if this specific DO should stay just SPC (not transient), please let me know how to document the meaning of ctlVal=false. This was, by the way, the test to see whether an SPC data object should be transient (if "false" makes no sense) or not (we clearly can say what ctlVal=false means). 		28 Aug 12 Discussion (red)
I disagree with the statement: "The change of the status value is a local issue". Our experience with IEC 61850 so far has shown, that whenever we had a statement like "is a local issue" in the specification, that created sooner or later interoperability issues. So we should learn and improve our specifications.

I suggest the following to replace the last sentence (The change of its status value is a local issue.): "The status shall chage to the value true when the switching sequence has been started."

Since we declare it as transient, we do not need to specify anything about when the status shall go back to false (this is indeed a local issue by definition of transient status signals).

With that, I assume that we have another data object indicating, when the switching sequence has terminated. Otherwise I would suggest NOT to declare the signal as transient and deactivate the status when the switching sequence has terminated. 		24 Aug 12 Discussion (red)
According to the decision of the UML TF - accepted. Will be considered in the next version of 7-4. 24 Aug 12 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1