-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unconfigured lifecycle state management #47
Comments
This is in the context of our exemplary case of the
(from here it is a related but different issue #48)
|
I agree with 1. and 2. This is also a question of timing for the following reason: Any state/mode transition will take some time (miliseconds to seconds, maybe), even in the normal, non-failure case. So it is not entirely clear, when someone (the mode manager? metacontrol?) should decide, that a transition or rule didn't work out and other actions have to be taken. I think this kind of decision, how long to wait for a node to recover or a rule to take effect, is best placed in the metacontrol, since this is probably task-specific. |
Very good point indeed, so far we are not accounting for timing issues.
|
This implies the incorporation of some timestamping and temporal [interval] reasoning. We can incorporate some concepts from e.g. UML2 or UML MARTE. |
I agree. So the current design proposal is that Mode Manager just inform about available and reachable modes, and Metacontrol is responsible for inferring from that about the success of reconfiguration actions.
@rsanz can you point to the specific concepts?
Modelling reqs for reconfiguration actions and timing
We could provide this information in the MROS model of the system (Darko's metamodel) as we are doing with the QAs, but I think it is more related to the specific software components that to the application logic. We could define default values in the MRSO metacontroller to assume when no info is provided. |
Hi again @norro!
Yesterday, I had a meeting with @chcorbato , and we talked about the case where a lifecycle node transits to
ErrorProcessing
.Following the documentation and the lifecycle node diagrams, if a node has an error it transits to
ErrorProcessing
. Then, based on this processing result, it can go to theFinalized
state orUnconfigured
state. Do you think that the system_modes must manage the unconfigured state of the lifecycle nodes? This management covers this situation and the start-up situation, where the nodes are in the unconfigured state.Thank you!
The text was updated successfully, but these errors were encountered: