Fix Safety Analysis Audit findings #560
Description
Not started:
- 6-7.4.10
- 6-7.4.11
- 6-7.4.12
Action_72: The Confirmation Review checklists need to refer to ISO-26262. @aschemmel-tech remark: please do this for the safety_analysis_checklist similar to what was done for safety plan and safety package FDRs in #587
Action_73: The failure mode EX_01_01 defines the internal execution failure (wrong calculation) but refers to message loss / corruption. It shall be explained that this failure mode (wrong calculation) is related to the analysis if e.g. internal safety mechanisms are required (level 2 function, plausibility check of the output, …) because of the size / complexity of the feature. If only testability is defined as mitigation measure, complexity requirements shall be allocated to the feature.
Action_64: For Persistency: The first assumption (handle the unavailability of persistency) and the third assumption (the application may not block persistency (make it available) are inconsistent. - @aschemmel-tech comment: while this was discovered during the audit of requirements process, the root cause lies within the safety analysis. Need to consider changing the safety analysis of persistency to be able to modify also the AoU requirements https://eclipse-score.github.io/score/main/features/persistency/requirements/index.html#aou_req__persistency__error_handling and/or https://eclipse-score.github.io/score/main/features/persistency/requirements/index.html#aou_req__persistency__appl_exec