Merge branch 'eclipse-score:main' into philippartsch_improve_detail_design

Author: PhilipPartsch

MODULE.bazel

@@ -50,4 +50,4 @@ bazel_dep(name = "buildifier_prebuilt", version = "8.2.0.2")
 ###############################################################################
 bazel_dep(name = "aspect_rules_lint", version = "1.5.3")
 bazel_dep(name = "score_tooling", version = "1.0.2")
-bazel_dep(name = "score_docs_as_code", version = "2.0.3")
+bazel_dep(name = "score_docs_as_code", version = "2.2.0")

process/folder_templates/features/feature_name/architecture/chklst_arc_inspection.rst

@@ -59,7 +59,7 @@ Checklist
       - Is the traceability from software architectural elements to requirements, and other level architectural
         elements (e.g. component to interface) established according to the "Relations between the architectural elements" as described in :need:`doc_concept__arch_process`?
       - automated
-      - Trace should be checked by Sphinx. Will be removed from checklist once requirement is implemented.
+      - Trace should be checked automatically by tool support in the future. It will be removed from the checklist once the requirement (:need:`Correlations of the architectural building blocks <gd_req__arch_build_blocks_corr>`) is implemented. Refer to `Tool Requirements <https://eclipse-score.github.io/docs-as-code/main/internals/requirements/requirements.html>`_ for the current status.
       -
       -
       -
@@ -74,8 +74,8 @@ Checklist
     * - ARC_01_03
       - Is the architectural element traceable to the lower level artifacts as defined by the workproduct traceability?
       - automated
-      - Will be removed from checklist once requirement is implemented by automated tool check.
-        Details of possible linking can be depicted from `traceability concept <https://eclipse-score.github.io/process_description/main/general_concepts/score_traceability_concept.html>`_
+      - Will be removed from checklist once the requirement (:need:`Correlations of the architectural building blocks <gd_req__arch_build_blocks_corr>`) is implemented by automated tool check. See `Tool Requirements <https://eclipse-score.github.io/docs-as-code/main/internals/requirements/requirements.html>`_.
+        Details of possible linking can be depicted from :ref:`traceability concept <general_concepts_traceability>`.
       -
       -
       -

process/folder_templates/features/feature_name/requirements/chklst_req_inspection.rst

@@ -100,7 +100,7 @@ Requirement Inspection Checklist
         -
         -
       * - REQ_03_02
-        - For feature/component requirements: Is the *linkage to the parent requirement* correct?
+        - Is the *linkage to the parent requirement* correct?
         - Linkage to correct levels and ASIL attributes is checked automatically, but it needs checking if the child requirement implements (at least) a part of the parent requirement.
         -
         -
@@ -131,7 +131,7 @@ Requirement Inspection Checklist
         -
       * - REQ_07_02
         - Is the attribute *security* set correctly?
-        - Stakeholder requirements security attribute should be set based on Threat Analysis and Risk Assessment (TARA) (process is TBD). For feature/component requirements this checklist item is supported by automated check: "Every requirement which satisfies a requirement with security attribute set to YES inherits this". But the feature/component requirements/architecture may additionally also be subject to a Software Security Criticality Analysis (process is TBD).
+        - For feature requirements this checklist item is supported by automated check: "Every requirement which satisfies a stakeholder requirement with security attribute set to YES inherits this". But the feature requirements/architecture may additionally also be subject to a :ref:`Software Security Analysis <security_analysis>`.
         -
         -
         -
@@ -143,12 +143,12 @@ Requirement Inspection Checklist
         -
       * - REQ_09_01
         - For stakeholder requirements: Do those cover assumed safety mechanisms needed by the hardware and system?
-        - Note that stakeholder requirements covering safety mechanisms come from rationales, whereas feature/component requirements are covering safety mechanisms coming from :need:`gd_chklst__safety_analysis`
+        - Note that stakeholder requirements covering safety mechanisms come from rationales, whereas feature requirements are covering safety mechanisms coming from :need:`gd_chklst__safety_analysis`
         -
         -
         -
       * - REQ_09_02
-        - For feature/component requirements: Do the requirements defining a safety mechanism contain the error reaction leading to a safe state?
+        - Do the feature requirements defining a safety mechanism contain the error reaction leading to a safe state?
         - Alternatively to the safe state there could also be "repair" mechanisms. Also do not forget to consider REQ_05_01 for these.
         -
         -

process/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.rst

@@ -59,7 +59,7 @@ Checklist
       - Is the traceability from software architectural elements to requirements, and other level architectural
         elements (e.g. component to interface) established according to the "Relations between the architectural elements" as described in :need:`doc_concept__arch_process`?
       - automated
-      - Trace should be checked by Sphinx. Will be removed from checklist once requirement is implemented.
+      - Trace should be checked automatically by tool support in the future. Will be removed from the checklist once the requirement (:need:`Correlations of the architectural building blocks <gd_req__arch_build_blocks_corr>`) is implemented. Refer to `Tool Requirements <https://eclipse-score.github.io/docs-as-code/main/internals/requirements/requirements.html>`_ for the current status.
       -
       -
       -
@@ -74,8 +74,8 @@ Checklist
     * - ARC_01_03
       - Is the architectural element traceable to the lower level artifacts as defined by the workproduct traceability?
       - automated
-      - Will be removed from checklist once requirement is implemented by automated tool check.
-        Details of possible linking can be depicted from `traceability concept <https://eclipse-score.github.io/process_description/main/general_concepts/score_traceability_concept.html>`_
+      - Will be removed from checklist once the requirement (:need:`Correlations of the architectural building blocks <gd_req__arch_build_blocks_corr>`) is implemented by automated tool check. See `Tool Requirements <https://eclipse-score.github.io/docs-as-code/main/internals/requirements/requirements.html>`_.
+        Details of possible linking can be depicted from :ref:`traceability concept <general_concepts_traceability>`.
       -
       -
       -

process/folder_templates/modules/module_name/component_name/docs/requirements/chklst_req_inspection.rst

@@ -100,7 +100,7 @@ Requirement Inspection Checklist
         -
         -
       * - REQ_03_02
-        - For feature/component requirements: Is the *linkage to the parent requirement* correct?
+        - Is the *linkage to the parent feature/component requirement* correct?
         - Linkage to correct levels and ASIL attributes is checked automatically, but it needs checking if the child requirement implements (at least) a part of the parent requirement.
         -
         -
@@ -131,7 +131,7 @@ Requirement Inspection Checklist
         -
       * - REQ_07_02
         - Is the attribute *security* set correctly?
-        - Stakeholder requirements security attribute should be set based on Threat Analysis and Risk Assessment (TARA) (process is TBD). For feature/component requirements this checklist item is supported by automated check: "Every requirement which satisfies a requirement with security attribute set to YES inherits this". But the feature/component requirements/architecture may additionally also be subject to a Software Security Criticality Analysis (process is TBD).
+        - For component requirements this checklist item is supported by automated check: "Every requirement which satisfies a feature requirement with security attribute set to YES inherits this". But the component requirements/architecture may additionally also be subject to a :ref:`Software Security Analysis <security_analysis>`..
         -
         -
         -
@@ -142,13 +142,13 @@ Requirement Inspection Checklist
         -
         -
       * - REQ_09_01
-        - For stakeholder requirements: Do those cover assumed safety mechanisms needed by the hardware and system?
-        - Note that stakeholder requirements covering safety mechanisms come from rationales, whereas feature/component requirements are covering safety mechanisms coming from :need:`gd_chklst__safety_analysis`
+        - Note that stakeholder requirements covering safety mechanisms come from rationales, whereas component requirements are covering safety mechanisms coming from :need:`gd_chklst__safety_analysis`
+        -
         -
         -
         -
       * - REQ_09_02
-        - For feature/component requirements: Do the requirements defining a safety mechanism contain the error reaction leading to a safe state?
+        - Do the requirements that define a safety mechanism specify the error reaction leading to a safe state?
         - Alternatively to the safe state there could also be "repair" mechanisms. Also do not forget to consider REQ_05_01 for these.
         -
         -

process/folder_templates/modules/module_name/docs/manual/safety_manual.rst

@@ -66,7 +66,7 @@ List of AoUs expected from the environment the platform / module runs on:
 
 Assumptions on the User
 ^^^^^^^^^^^^^^^^^^^^^^^
-| As there is no assumption on which specific OS and HW is used, the integration testing of the stakeholder and feature requirements is expected to be performed by the user of the platform SEooC. Tests covering all stakeholder and feature requirements performed on a reference platform (tbd link to reference platform specification), reviewed and passed are included in the platform SEooC safety case.
+| As there is no assumption on which specific OS and HW is used, the integration testing of the stakeholder and feature requirements is expected to be performed by the user of the platform SEooC. Tests covering all stakeholder and feature requirements performed on a reference platform (tbd link to reference platform specification), reviewed and passed are included in the platform SEooC safety package.
 | Additionally the components of the platform may have additional specific assumptions how they are used. These are part of every module documentation: <link to add>. Assumptions from components to their users can be fulfilled in two ways:
 | 1. There are assumption which need to be fulfilled by all SW components, e.g. "every user of an IPC mechanism needs to make sure that he provides correct data (including appropriate ASIL level)" - in this case the AoU is marked as "platform".
 | 2. There are assumption which can be fulfilled by a safety mechanism realized by some other project platform component and are therefore not relevant for an user who uses the whole platform. But those are relevant if you chose to use the module SEooC stand-alone - in this case the AoU is marked as "module". An example would be the "JSON read" which requires "The user shall provide a string as input which is not corrupted due to HW or QM SW errors." - which is covered when using together with safe project platform persistency feature.

process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_plan_fdr.rst

@@ -58,7 +58,7 @@ The purpose of this safety plan formal review checklist is to report status of t
           - <Rationale for result>
 
         * - 3
-          - Does the safety plan define all needed activities for safety management (incl. Confirmation review and Safety Audit)?
+          - Does the safety plan define all needed activities for safety management (incl. formal document review and Safety Audit)?
           - [YES | NO ]
           - <Rationale for result>
 

process/process_areas/architecture_design/guidance/architecture_guideline.rst

@@ -20,7 +20,7 @@ Architecture Guideline
 .. gd_guidl:: Architectural Design
    :id: gd_guidl__arch_design
    :status: valid
-   :complies: std_req__isopas8926__44411, std_req__isopas8926__44412
+   :complies: std_req__isopas8926__44411, std_req__isopas8926__44412, std_req__iso26262__software_745
 
 The guideline focuses on the steps which need to be performed in order to create the architectural design. The concept behind those steps is described in the :need:`[[title]] <doc_concept__arch_process>`.
 

process/process_areas/architecture_design/guidance/architecture_process_reqs.rst

@@ -127,7 +127,7 @@ Attributes of Architectural Elements
    :id: gd_req__arch_attr_safety
    :status: valid
    :tags: manual_prio_1, attribute, mandatory
-   :complies: std_req__iso26262__support_6421, std_req__iso26262__support_6425
+   :complies: std_req__iso26262__support_6421, std_req__iso26262__support_6425, std_req__iso26262__software_746
    :satisfies: wf__cr_mt_featarch, wf__cr_mt_comparch
 
    Each architectural element shall have a automotive safety integrity level (ASIL) identifier:

process/process_areas/change_management/change_management_workproducts.rst

@@ -38,6 +38,7 @@ Change Management Work Products
    | Safety anomaly: Conditions that deviate from expectations and that can lead to harm.
    | The documentation of a change request shall contain the list of changed work products,
    | the details of the change and the planned date of deployment of the change.
+   | In case a anomaly cannot be closed it shall be escalated to the :need:`Project Lead <rl__project_lead>`.
 
 .. workproduct:: Feature Request
    :id: wp__feat_request