Requirement rephrasing and split-up - #647
TimoSteuerwaldETAS wants to merge 2 commits into
Conversation
GitHub Actions
Waiting
GitHub Actions
Waiting
b89c2f4 to
95de6b2
Compare
GitHub Actions
Waiting
GitHub Actions
Waiting
GitHub Actions
Waiting
GitHub Actions
Waiting
As discussed in weekly lifecyle meeting on 9th and 16th September.
72583db to
47dee1f
Compare
GitHub Actions
Waiting
GitHub Actions
Waiting
| :security: NO | ||
| :safety: ASIL_B | ||
| :derived_from: feat_req__lifecycle__liveliness_detection[version==1] | ||
| :status: valid |
There was a problem hiding this comment.
This thins one should be invalid? Might need some clarification. Stop the process and then what? is it considered active?
There was a problem hiding this comment.
To my understanding, the ones which I kept valid are:
- for switching run targets (comp_req__launch_man__recovery_stop_start)
- for restarting the component (comp_req__launch_man__recovery_relaunch)
- for a switching to a minimal diagnosable state like fallback run target (comp_req__launch_man__recovery_stop)
However I am not entirely sure if my interpretation is correct.
There was a problem hiding this comment.
I think from the meeting minutes
"Proposal is to set at least comp_req__launch_man__recovery_stop to invalid"
Then we shall transform this into the crash recovery "feature"
| :security: NO | ||
| :safety: ASIL_B | ||
| :derived_from: feat_req__lifecycle__liveliness_detection[version==1] | ||
| :status: valid |
There was a problem hiding this comment.
I think this one should also be set to invalid and clarified. I think the requirement should describe what happens with the dependants, do they get restarted?
There was a problem hiding this comment.
Let's clarify in the meeting.
There was a problem hiding this comment.
I think we discussed this a longer time ago once in Score and if I remember correctly dependent processes shall be unaffected by a restarted process (i.e. restart component recovery action).
The assumption is that e.g. IPC communication btw. processes can be reestablished (which is supported in mw::com / ara::com).
SimonKozik
left a comment
SimonKozik
left a comment
There was a problem hiding this comment.
Please add use cases documented in the minutes here: https://github.com/orgs/eclipse-score/discussions/2386#discussioncomment-17825072
Please have a look at the note boxes. What exactly are you missing? |
| ##################################### | ||
|
|
||
| .. note:: | ||
| Requirements which are not planned to be implemented in the version 1.0 of the Launch Manager are set to status **invalid**. |
There was a problem hiding this comment.
Is Score 1.0 release and Launch Manager 1.0 the same thing?
AFAIK valid from field is referring to score release and not to the launch manager release.
| The :term:`Launch Manager` shall be able to react to a process failure by | ||
| stopping the process. | ||
|
|
||
| .. comp_req:: Recovery by stopping the process and starting another process |
There was a problem hiding this comment.
I guess this is not in 1.0 scope
| The :term:`Launch Manager` shall be able to react to a process failure by | ||
| relaunching the process. |
There was a problem hiding this comment.
Maybe something like this:
| The :term:`Launch Manager` shall be able to react to a process failure by | |
| relaunching the process. | |
| When configured, the :term:`Launch Manager` shall be able to react to a | |
| :term:`Component` activation failure by reactivating the failed | |
| :term:`Component` only. |
it clarifies that
- its component activation
- only for the failing comp
- only if configured
| The :term:`Launch Manager` shall be able to react to a process failure by | ||
| triggering :term:`QNX` :term:`Operating System` Device Safe State (:term:`DSS`). |
There was a problem hiding this comment.
| The :term:`Launch Manager` shall be able to react to a process failure by | |
| triggering :term:`QNX` :term:`Operating System` Device Safe State (:term:`DSS`). | |
| When configured, the :term:`Launch Manager` shall be able to react to a :term:`Component` activation failure by | |
| triggering a :term:`QNX` :term:`Operating System` Device Safe State (:term:`DSS`). |
This branch is waiting to be deployed
4 participants
Rephrased and set state accordingly as discussed in weekly lifecyle meeting on 12th August, 9th and 16th September.