What are the expectations about component error behavior across modes? Specifically, I don't think the standard prevents me from declaring that a component has one error behavior in one mode, and another error behavior is another mode. And these behaviors could have totally different sets of error states. Consider the package below:
package Example
public
annex EMV2 {**
error behavior X
events
InternalFailure: error event;
states
Normal: initial state;
Broken: state;
transitions
t1: Normal -[InternalFailure]-> Broken;
end behavior;
error behavior Y
events
myEvent: error event;
states
A: initial state;
B: state;
C: state;
transitions
t1: A -[myEvent]-> B;
t2: B -[myEvent]-> C;
end behavior;
**};
system S
modes
m1: initial mode;
m2: mode;
annex EMV2 {**
use behavior Example::X;
-- ...
**};
annex EMV2 {**
use behavior Example::Y;
-- ...
**};
end S;
end Example;
System S uses behavior X in mode m1, and behavior Y in mode m2. I have purposely used different error state names in the two behaviors to negate the "name matching" solution.
The standard doesn't say this is not allowed. But it also doesn't say what happens to the error state of a component instance when the operational mode of that instance changes. I've been assuming that the state doesn't change when the mode changes, but that clearly doesn't work in the above situation, because the set of error states is different.
Specific questions that need to answered:
What happens to the current error state when the mode changes but the behavior state machine stays the same?
What happens to the current error state when the mode changes and the behavior state machine changes?
Must pick an error state from the new state machine. But do we always restart at the initial state?
Similarly, do we maintain a current state per mode, per behavior state machine, or per instance? What happens if system S is in mode m1, transitions to mode m2, and then transitions back to mode m1? Does the current state always reset to the initial state of m1, or does it go back to the state it was in before the transition to mode m2?
--
Jerome adds the following comments:
I see no objection to have different error behaviors between modes, a system may be subject to different error types
The mode mapping in EMV2 might be incomplete to fully cover some situations.
What are the expectations about component error behavior across modes? Specifically, I don't think the standard prevents me from declaring that a component has one error behavior in one mode, and another error behavior is another mode. And these behaviors could have totally different sets of error states. Consider the package below:
System
S
uses behaviorX
in modem1
, and behaviorY
in modem2
. I have purposely used different error state names in the two behaviors to negate the "name matching" solution.The standard doesn't say this is not allowed. But it also doesn't say what happens to the error state of a component instance when the operational mode of that instance changes. I've been assuming that the state doesn't change when the mode changes, but that clearly doesn't work in the above situation, because the set of error states is different.
Specific questions that need to answered:
S
is in modem1
, transitions to modem2
, and then transitions back to modem1
? Does the current state always reset to the initial state ofm1
, or does it go back to the state it was in before the transition to modem2
?--
Jerome adds the following comments: