process: include audit remarks

Ref: closes #5

Author: PandaeDo

process/process_areas/safety_analysis/_assets/safety_analysis_component.drawio.svg

@@ -23,7 +23,10 @@ DFA failure initiators
   :complies: std_wp__iso26262__software_751, std_wp__iso26262__software_753
 
 
-:note: Use the failure initiators to ensure a structured analysis. If a failure doesn't apply, please fill in a short description in the violation cause of the analysis so it could be recognized that the analysis is done. If there are additional failure initiators needed, please enlarge the list of fault models.
+.. note:: Use the failure initiators to ensure a structured analysis. If a failure doesn't apply, please fill in a short description in the violation cause of the analysis so it could be recognized that the analysis is done. If there are additional failure initiators needed, please enlarge the list of fault models.
+
+.. note:: A ASIL related message is trustable in that manner that it is not corrupted, repeated, lost, delayed, masqueraded or addressed incorrectly.
+
 
 **Purpose**
 
@@ -35,14 +38,16 @@ DFA failure initiators
 
 2.1 Shared resources
 
-.. list-table:: DFA shared resources
+.. note:: Shared libraries are only than to be considered as a shared resource if the feature and the related safety mechanisms are using this specific library. If the library is not used by the feature or the related safety mechanisms, it is not a shared resource.
+
+.. list-table:: DFA shared resources (used for Platform Feature DFA)
   :header-rows: 1
   :widths: 10,30,30,30
 
   * - ID
     - Violation cause shared resources
     - Simplification
-    - Importance (can be used for priorisation)
+    - Importance (can be used for prioritization)
   * - SR_01_01
     - Reused software modules
     -
@@ -105,7 +110,7 @@ DFA failure initiators
     -
     - Medium
   * - CO_01_05
-    - Asymmetric information sent from a sender to multiple receivers, so that not all defined receivers have the same informations
+    - Asymmetric information sent from a sender to multiple receivers, so that not all defined receivers have the same information's
     -
     - Medium
   * - CO_01_06
@@ -127,7 +132,7 @@ DFA failure initiators
   * - ID
     - Violation cause shared information inputs
     - Simplification
-    - Importance (can be used for priorisation)
+    - Importance (can be used for prioritization)
   * - SI_01_02
     - Configuration data
     -
@@ -155,7 +160,7 @@ DFA failure initiators
   * - ID
     - Violation cause unintended impact
     - Simplification
-    - Importance (can be used for priorisation)
+    - Importance (can be used for prioritization)
   * - UI_01_01
     - Memory miss-allocation and leaks
     -
@@ -210,7 +215,7 @@ DFA failure initiators
 
 :note: Section shall be applied only once to analyse all dependencies of the features. Results shall be checked during of the analysis of new features if this is applicable to the feature.
 
-.. list-table:: DFA development failure initiators
+.. list-table:: DFA development failure initiators (Feature Platform DFA)
   :header-rows: 1
   :widths: 10,30,30,30
 

process/process_areas/safety_analysis/_assets/safety_analysis_feature.drawio.svg

@@ -23,90 +23,94 @@ Fault Models
   | Fault Model for sequence diagrams
 
 
-:note: Use the fault models to ensure a structured analysis. If a fault model doesn't apply, please fill in a short description in the violation cause of the analysis so it could be recognized that the analysis is done. If there are additional fault models needed, please enlarge the list of fault models.
+.. note:: Use the fault models to ensure a structured analysis. If a fault model doesn't apply, please fill in a short description in the violation cause of the analysis so it could be recognized that the analysis is done. If there are additional fault models needed, please enlarge the list of fault models.
 
 
-    .. list-table:: Fault Models for sequence diagrams
-       :header-rows: 1
-       :widths: 15,6,30,30,15
+.. note:: A ASIL related message is trustable in that manner that it is not corrupted, repeated, lost, delayed, masqueraded or addressed incorrectly.
 
-      * - Element
-        - ID
-        - Failure Mode
-        - Simplification
-        - Importance (can be used for priorisation)
-      * - message
-        - MF_01_01
-        - message is not received
-        - MF_01_05
-        - High
-      * - message
-        - MF_01_02
-        - message received too late
-        - relevant only if delay is a realistic fault
-        - Medium
-      * - message
-        - MF_01_03
-        - message received too early
-        - usually not a problem
-        - Low
-      * - message
-        - MF_01_04
-        - message not received correctly by all recipients (different messages or messages partly lost)
-        - only relevant if the same message goes to multiple recipients
-        - High
-      * - message
-        - MF_01_05
-        - message is corrupted
-        -
-        - High
-      * - message
-        - MF_01_06
-        - message is not sent
-        -
-        - High
-      * - message
-        - MF_01_07
-        - message is unintended sent
-        -
-        - High
-      * - duration/time constraint
-        - CO_01_01
-        - minimum constraint boundary is violated
-        -
-        - Medium
-      * - duration/time constraint
-        - CO_01_02
-        - maximum constraint boundary is violated
-        -
-        - High
-      * - execution
-        - EX_01_01
-        - Process calculates wrong result(s)
-        - MF_01_05 or MF_01_04
-        - High
-      * - execution
-        - EX_01_02
-        - processing too slow
-        - relevant only if timing is considered
-        - Medium
-      * - execution
-        - EX_01_03
-        - processing too fast
-        - relevant only if timing is considered
-        - Medium
-      * - execution
-        - EX_01_04
-        - loss of execution
-        -
-        - High
-      * - execution
-        - EX_01_05
-        - processing changes to arbitrary process
-        -
-        - Medium
-      * - execution
-        - EX_01_06
-        - processing is not complete (infinite loop)
-        -
-        - High
+
+Fault Models for sequence diagrams
+  .. list-table:: Fault Models for sequence diagrams
+     :header-rows: 1
+     :widths: 15,6,30,30,15
+
+    * - Element
+      - ID
+      - Failure Mode
+      - Simplification
+      - Importance (can be used for priorisation)
+    * - message
+      - MF_01_01
+      - message is not received
+      - MF_01_05
+      - High
+    * - message
+      - MF_01_02
+      - message received too late
+      - relevant only if delay is a realistic fault
+      - Medium
+    * - message
+      - MF_01_03
+      - message received too early
+      - usually not a problem
+      - Low
+    * - message
+      - MF_01_04
+      - message not received correctly by all recipients (different messages or messages partly lost)
+      - only relevant if the same message goes to multiple recipients
+      - High
+    * - message
+      - MF_01_05
+      - message is corrupted
+      -
+      - High
+    * - message
+      - MF_01_06
+      - message is not sent
+      -
+      - High
+    * - message
+      - MF_01_07
+      - message is unintended sent
+      -
+      - High
+    * - duration/time constraint
+      - CO_01_01
+      - minimum constraint boundary is violated
+      -
+      - Medium
+    * - duration/time constraint
+      - CO_01_02
+      - maximum constraint boundary is violated
+      -
+      - High
+    * - execution
+      - EX_01_01
+      - Process calculates wrong result(s)
+      - MF_01_05 or MF_01_04
+      - High
+    * - execution
+      - EX_01_02
+      - processing too slow
+      - relevant only if timing is considered
+      - Medium
+    * - execution
+      - EX_01_03
+      - processing too fast
+      - relevant only if timing is considered
+      - Medium
+    * - execution
+      - EX_01_04
+      - loss of execution
+      -
+      - High
+    * - execution
+      - EX_01_05
+      - processing changes to arbitrary process
+      -
+      - Medium
+    * - execution
+      - EX_01_06
+      - processing is not complete (infinite loop)
+      -
+      - High

process/process_areas/safety_analysis/_assets/safety_analysis_workflow.drawio.svg

@@ -60,13 +60,19 @@ Checklist for Safety Analysis
         - The cause of the violation is described completely. The cause can be recognized easily.
         - <yes|no>
         -
-      * - REQ_01_05
+      * - REQ_01_06
         - Is the mitigation described completely and in an easily understandable manner?
         -
         - The mitigation is clearly and completely described.
         - <yes|no>
         -
-      * - REQ_01_06
+      * - REQ_01_07
+        - Is the sufficiency of the mitigation described or can it be recognized easily?
+        -
+        - The mitigation shows clearly that a function an their related safety mechanisms cant't be violated by the same failure.
+        - <yes|no>
+        -
+      * - REQ_01_08
         - Is the overall result of the safety analysis described in the report?
         -
         - The results of the safety analysis are described in the report. The report is available :need:`wp__verification__platform_ver_report`.

process/process_areas/safety_analysis/guidance/dfa_failure_initiators.rst

@@ -31,15 +31,15 @@ Detailed description which steps are need for a safety analysis. In general the
 #. Analyse the dependencies between features by performing a **single platform feature DFA** that references all platform feature static architecture diagrams, highlighting potential shared use of modules.
 #. Monitor the results of the platform feature DFA and log any issues in the Issue Tracking system with the ``safety`` label.
 #. Verify the platform feature DFA results by using :need:`gd_chklst__safety_analysis`.
-#. Platform feature DFA are completed when the verification is done, no issues are open and the status is "valid".
+#. Platform feature DFA is completed when the verification is done, no issues are open and the status is "valid". The verification criteria is that it can be proven that a function and the corresponding safety monitoring are not both affected.
 #. To analyse the Feature Architecture a FMEA and a DFA shall be executed. The results of the platform feature DFA shall be used as an input.
 #. Monitor the results of the FMEA and DFA and log any issues in the Issue Tracking system with the ``safety`` label.
 #. Verify the FMEA and DFA results by using :need:`gd_chklst__safety_analysis`..
 #. Feature FMEA and DFA are completed when the verification is done, no issues are open and the status is "valid".
 #. To analyse the Component Architecture a FMEA and a DFA shall be executed. The results of the feature FMEA and DFA shall be used as an input.
 #. Monitor the results of the FMEA and DFA and log any issues in the Issue Tracking system with the ``safety`` label.
-#. Verify the FMEA and DFA results by using :need:`gd_chklst__safety_analysis`..
-#. Component FMEA and DFA are completed when the verification is done, no issues are open and the status is "valid".
+#. Verify the FMEA and DFA results by using :need:`gd_chklst__safety_analysis`.
+#. Component FMEA and DFA are completed when the verification is done, no issues are open and the status is "valid". The verification criteria is that it can be proven that a function and the corresponding safety monitoring are not both affected.
 
 
 A example for the safety analysis (FMEA and DFA) is shown in the :ref:`examples_fmea_dfa`.
@@ -57,7 +57,7 @@ The analysis considers single faults that can mitigate a safety requirement.
 
 * For each dynamic diagram, assign the faults by ID from the fault model and document it as a sphinx-needs directive.
 * Document the resulting failure mode and effect and link to a safety requirement that mitigates the violation.
-* Document safety mitigation to avoid or control the failure.
+* Document safety mitigation to avoid or control the failure. If it can't be shown that a element is completely deterministic and testable, an additional safety mechanisms is needed.
 * The attributes of the template are described in :ref:`process_requirements_safety_analysis_attributes`.
 * Judge if this is sufficient.
 * If not, request to update the diagram and the requirements with additional safety mitigation to come to a sufficient outcome by creating an issue.
@@ -66,6 +66,8 @@ The analysis considers single faults that can mitigate a safety requirement.
 * Continue the analysis until all fault models are checked.
 * The verification is done by applying the FMEA checklist :need:`gd_chklst__safety_analysis`.
 
+.. note:: If there are changes they have to be analysed with a impact analysis :need:`gd_temp__change__impact_analysis`. If needed the safety analysis has to be updated accordingly. Therefore all necessary steps have to be repeated.
+
 Step-by-Step-approach DFA:
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -78,8 +80,10 @@ So it could be shown that the analysis was done and no fault model is applicable
 * For each failure initiator assign the violation by ID from the DFA failure initiators and document it as a sphinx-needs directive.
 * Document the resulting violation causes and effect and link to a safety requirement that mitigates the violation.
 * The attributes of the template are described in :ref:`process_requirements_safety_analysis_attributes`.
-* Judge if the mitigation is sufficient. If not, request to update the requirements with additional safety mitigation to come to a sufficient outcome.
+* Judge if the mitigation is sufficient. If not, request to update the requirements with additional safety mitigation to come to a sufficient outcome.  If it can't be shown that a element is completely deterministic and testable, an additional safety mechanisms is needed.
 * The analysis is finished, if for each identified violation a mitigation exists.
 * Unless the attribute "sufficient" is "yes", mitigation and argument attribute can be still empty.
 * Continue the analysis until all failure initiators are checked.
 * The verification is done by applying the safety analysis checklist :need:`gd_chklst__safety_analysis`.
+
+.. note:: If there are changes they have to be analysed with a impact analysis :need:`gd_temp__change__impact_analysis`. If needed the safety analysis has to be updated accordingly. Therefore all necessary steps have to be repeated.