Update Persistency safety analysis fdr#2873
Update Persistency safety analysis fdr#2873PandaeDo wants to merge 2 commits intoeclipse-score:mainfrom
Conversation
|
|
|
The created documentation from the pull request is available at: docu-html |
PandaeDo
requested review from
AlexanderLanin,
FScholPer,
MaximilianSoerenPollak,
antonkri,
dcalavrezo-qorix,
johannes-esr and
qor-lb
as code owners
aschemmel-tech
left a comment
aschemmel-tech
left a comment
There was a problem hiding this comment.
see findings inline
There was a problem hiding this comment.
The FDR is a formal review for all safety analysis in one module (feature, component, fmea, dfa). According to the folder template it is stored in persistency (module) repo in persistency/doc/safety_mgt as it belongs to safety management iso chapter.
There was a problem hiding this comment.
Agree on the meeting. We might consider if we change the process description https://eclipse-score.github.io/process_description/main/process_areas/safety_analysis/guidance/safety_analysis_checklist.html. We defined FDR for platform, feature and module.
There was a problem hiding this comment.
yes, please change safety analysis process description
|
|
||
| As described in :need:`wf__p_formal_rv`, the formal document review is performed by an "external" safety manager: | ||
|
|
||
| - reviewer: Uwe Maucher, Volker Häussler |
There was a problem hiding this comment.
Has Uwe safety manager skills? If not we should either remove his name from the formal document or state that he is an additional reviewer in his role as module lead.
| - Are the safety analysis performed according to the defined process and templates? See :need:`gd_req__saf_structure` and also :need:`doc__feature_name_fmea` and :need:`doc__feature_name_dfa` | ||
| - YES | ||
| - :need:`[[title]] <std_req__iso26262__analysis_841>` | ||
| - Templates for safety analysis are used and the process is followed. |
There was a problem hiding this comment.
I would add here a link to the evidence: i.e. to the safety analysis documents that were checked.
There was a problem hiding this comment.
@PandaeDo to add "scope" section in process template
| - Is the result of the safety analysis indicate if the safety requirements are complied? | ||
| - YES | ||
| - :need:`[[title]] <std_req__iso26262__analysis_842>` | ||
| - The safety analysis results indicate compliance with the requirements. |
There was a problem hiding this comment.
I would expect some more explanation for example that the reqs are linked to the architecture views and these to the safety analysis? Or we refer to some process description?
| - Are for all not complied safety requirements mitigations defined to resolute the non-compliance? The mitigations shall have a direct influence on the violation by prevention, detection or mitigation to reduce the risk to an acceptable level. | ||
| - YES | ||
| - :need:`[[title]] <std_req__iso26262__analysis_843>` | ||
| - Yes. All non-compliances have defined mitigations. |
There was a problem hiding this comment.
Please elaborate further like: "for this we checked that every feat_saf_fmea/dfa has a mitigation linked"
| - Is the DFA performed in a systematic way to identify the potential dependent failures and their effects? Are the failure effect and the mitigation described? | ||
| - YES | ||
| - :need:`[[title]] <std_req__iso26262__analysis_8410>` | ||
| - The DFA is performed in a systematic way to identify the potential dependent failures and their effects. The failure effect and the mitigation are described. |
There was a problem hiding this comment.
Better: "All initiators were covered ..."
That the failure effect and the mitigation is filled out is actually covered by automated process requirements.
| - Are the fault models suitable and applied for the FMEA? See :need:`gd_guidl__fault_models` and also :need:`gd_req__saf_structure` | ||
| - YES | ||
| - :need:`[[title]] <std_req__iso26262__analysis_846>` | ||
| - The fault models are suitable and have been applied for the FMEA. |
There was a problem hiding this comment.
Better: "The fault models as in :need:gd_guidl__fault_models seem complete and fitting to a SW platform. All fault models were considered and argued as not applicable or documented as faults linking back to the fault model in attribute fault_id."
| - The FMEA is performed in a systematic way to identify the potential failure modes and their effects. The failure effect and the mitigation are described. | ||
|
|
||
| * - 3 | ||
| - Are the templates for FMEA used? See :need:`doc__feature_name_fmea` and also :need:`gd_req__saf_structure` |
There was a problem hiding this comment.
Isn't this question the same as the above in general list "1"
There was a problem hiding this comment.
@PandaeDo to change in process template: template question only in general section
| - Is the FMEA performed in a systmatic way to identify the potential failure modes and their effects? Are the failure effect and the mitigation described? | ||
| - YES | ||
| - :need:`[[title]] <std_req__iso26262__analysis_849>` | ||
| - The FMEA is performed in a systematic way to identify the potential failure modes and their effects. The failure effect and the mitigation are described. |
There was a problem hiding this comment.
Compare similar question in DFA list. Need to define what we consider a "systematic way" (maybe some overlap with the point "2" just above.
There was a problem hiding this comment.
@PandaeDo to change in process template: add a "general answer" which refers our process description.
|
|
||
| As described in :need:`wf__p_formal_rv`, the formal document review is performed by an "external" safety manager: | ||
|
|
||
| - reviewer: Uwe Maucher, Volker Häussler |
There was a problem hiding this comment.
Should Volker be the reviewer? It looks to me, as he also would be the author.
2 participants
Preperation for meeting with @umaucher