Repository navigation
update problem resoultion to close audit findings - #832
Conversation
|
The created documentation from the pull request is available at: docu-html |
| The title of the Problem Report should reflect the topic accordingly. | ||
|
|
||
| The description should reflect the problem root cause and impact in detail. | ||
| The description should reflect the problem root cause, if known, and its impact. |
There was a problem hiding this comment.
Not sure, but should also side effects of the problem stated somewhere ?
There was a problem hiding this comment.
Addressed in the pushed changes. The problem description now explicitly includes known side effects on other functionality or dependent components.
| To check, if it is sufficient, :need:`Problem Checklist <gd_chklst__problem_cr_review>` may used. | ||
| Further the effectiveness of the implemented measure is confirmed and the availability | ||
| of the required reports, as verification results, if applicable. | ||
| Where measures are implemented, confirm their effectiveness and record the verification |
There was a problem hiding this comment.
Also here my question; Are there any side effects of the solution mentioned somewhere ? Like performance decrease by the measures and so on ?
There was a problem hiding this comment.
Addressed in the pushed changes. The closure guidance now asks to consider and document side effects of the implemented measure, such as reduced performance, and include them in verification as applicable.
3 participants
What
Clarify the Problem Resolution process to address the remaining findings in #557, Actions 66–69, and ISO 26262-2:2018, clauses 5.4.3.3 and 5.4.3.4.
Changes
Define critical review topics and explain how to handle missing information or rejection.
Clarify when notification is needed and what to record in the Problem Report: why, who was notified, when and how.
Distinguish the detection version from affected versions, including versions derived from the faulty version.
Replace undefined “Safety/Security experts” with the existing Safety/Security Manager roles.
Define both closure conditions for problems where Safety affected applies:
An adequate safety measure is implemented and its effectiveness verified.
An evaluation concludes that the problem does not constitute an unreasonable risk.
Require the closure rationale to be documented and reviewed.
Align the template, guideline, requirements and checklist, including clause-specific traceability.
Existing workflows and responsibilities remain unchanged. Workflow reference versions are updated to match the revised guidance.
Changes to GitHub issue forms and SCORE’s management plans are outside this branch’s scope.