Update Safety Analysis Template#669
Conversation
|
The created documentation from the pull request is available at: docu-html |
ANegm-ETAS
requested review from
PandaeDo,
aschemmel-tech,
masc2023 and
pahmann
as code owners
masc2023
left a comment
masc2023
left a comment
There was a problem hiding this comment.
Did you add process requirements for the attributes in the safety analysis process area and mark them as optional?
|
yes, added in the PR below |
This is maybe an misunderstanding, I wrote process requirements, has to be added here |
you're right i thought you were talking about docs-as-code requirements I'll update this PR |
aschemmel-tech
left a comment
aschemmel-tech
left a comment
There was a problem hiding this comment.
In addition to the process requirements it should be also taken over in the guideline (https://eclipse-score.github.io/process_description/main/process_areas/safety_analysis/guidance/safety_analysis_guideline.html#step-by-step-approach-fmea) how these optional attributes should be used. In my current analysises I put the information about the root cause in the rationale section of the failure mode list.
masc2023
left a comment
masc2023
left a comment
There was a problem hiding this comment.
My comments have been resolved
PandaeDo
left a comment
PandaeDo
left a comment
There was a problem hiding this comment.
As discussed I don't see the benefits of the failure_root_cause. If there is a weak description in the failure effect, another field will not cover this. So I would prefer to add additional description(s), example(s) and/or checklist.
If we would agree on your approach, please update also the examples in the guidelines accroding to your approach.
The idea was to make it less likely to be overlooked by the development team. the examples in the guidelines are updated here |
The example in the guideline is updated . |
aschemmel-tech
left a comment
aschemmel-tech
left a comment
There was a problem hiding this comment.
see inline comments
| :id: feat_saf_dfa__<Feature>__<Element descriptor> | ||
| :failure_id: <ID from DFA failure initiators :need:`gd_guidl__dfa_failure_initiators`> | ||
| :failure_effect: "description of failure effect of the failure initiator on the element" | ||
| :safety_relevant: <yes|no> |
There was a problem hiding this comment.
What would be the consequence of setting :safety_relevant: no ? No need to set :mitigated_by:, :mitigation_issue: and :sufficient: ? Would also need a check updated.
There was a problem hiding this comment.
in case of :safety_relevant: no, i would say the threshold to be :sufficient: yes is lower, for example simply planning an issue would be sufficient. If you agree on this approach, i can update the Safety Analysis Attribute Requirements to make it clearer.
Would also need a check updated.
Do you mean to add a point in the Safety Analysis Checklist ?
| #. Replace the placeholders in the "id" attribute with the name of the feature or component and a short description of the element so that it can be easily identified. | ||
| #. Document the fault ID from the fault model :need:`gd_guidl__fault_models` that applies to the element in the "fault_id" attribute. | ||
| #. Describe the failure effect of the fault model on the element in the "failure_effect" attribute. Use the failure mode description and enlarge the if it's applicable to the considered element. | ||
| #. Document the root cause of the failure in the "failure_root_cause" attribute. |
There was a problem hiding this comment.
please document also here that this is optional. E.g. "You may document ...". Same in next line.
There was a problem hiding this comment.
updated to a more suggestive terms
| #. Document the fault ID from the fault model :need:`gd_guidl__fault_models` that applies to the element in the "fault_id" attribute. | ||
| #. Describe the failure effect of the fault model on the element in the "failure_effect" attribute. Use the failure mode description and enlarge the if it's applicable to the considered element. | ||
| #. Document the root cause of the failure in the "failure_root_cause" attribute. | ||
| #. Indicate whether the analysed failure is safety relevant using the "safety_relevant" attribute (<yes> or <no>). |
There was a problem hiding this comment.
It is not clear what is done if safety_relevant == no. Still needs mitigation?
There was a problem hiding this comment.
discussion on this point is in the above comment, whatever measure we reach will be applied here as well.
5 participants
relevant docs-as-code PR
eclipse-score/docs-as-code#517