Merge branch 'eclipse-score:main' into philippartsch_improve_detail_design

Author: PhilipPartsch

MODULE.bazel

@@ -13,7 +13,7 @@
 
 module(
     name = "score_process",
-    version = "1.3.2",
+    version = "1.4.0",
     compatibility_level = 1,
 )
 

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

@@ -162,3 +162,23 @@ Checklist
       -
       -
       -
+    * - ARC_04_01
+      - If software partitioning (different operating system processes) is used to implement freedom from interference between the processes with different rating (QM/ASIL), is effectiveness evidence generated during integration and verification tests?
+
+        Note: see ISO 26262-6, 7.4.9 and Annex D for partitioning
+      - manual
+      -
+        a) the usage of shared resources (cpu time, shared memory, ...) are checked in a way that freedom from interference between the processes is ensured,
+        b) check if the operating system supports freedom from interference between the processes
+      -
+      -
+      -
+    * - ARC_04_02
+      - Is an upper estimation of the required resources (RAM, ROM, non volatile memory, communication) available and documented?
+
+        Note: see ISO 26262-6, 7.4.11
+      - manual
+      -
+      -
+      -
+      -

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

@@ -94,12 +94,6 @@ Requirement Inspection Checklist
         -
         -
       * - REQ_03_01
-        - For stakeholder requirements: Is the *rationale* correct?
-        - Rationales explain why the top level requirements were created. Do those cover the requirement?
-        -
-        -
-        -
-      * - REQ_03_02
         - 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.
         -
@@ -130,7 +124,7 @@ Requirement Inspection Checklist
         -
         -
       * - REQ_07_02
-        - Is the attribute *security* set correctly?
+        - Is the *security* attribute set correctly?
         - 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>`.
         -
         -
@@ -142,12 +136,6 @@ 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 requirements are covering safety mechanisms coming from :need:`gd_chklst__safety_analysis`
-        -
-        -
-        -
-      * - REQ_09_02
         - 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/features/feature_name/safety_planning/index.rst

@@ -14,8 +14,8 @@
 
 .. _feature_safety_wp_template:
 
-Safety Planning
-###############
+Feature Safety Work Products List
+#################################
 
 .. document:: [Your Feature Name] Safety WPs
    :id: doc__feature_name_safety_wp
@@ -52,78 +52,71 @@ Safety Work products List
     * - Work product Id
       - Link to process
       - Process status
-      - Link to issue
       - Link to WP
-      - WP/doc status
 
     * - :need:`wp__feat_request`
       - :need:`gd_temp__change_feature_request`
       - :ndf:`copy('status', need_id='gd_temp__change_feature_request')`
-      - <link to issue>
       - :need:`doc__feature_name`
-      - :ndf:`copy('status', need_id='doc__feature_name')`
 
     * - :need:`wp__requirements_feat`
       - :need:`gd_temp__req_feat_req`
       - :ndf:`copy('status', need_id='gd_temp__req_feat_req')`
-      - <link to issue>
       - :need:`doc__feature_name_requirements`
-      - doc :ndf:`copy('status', need_id='doc__feature_name_requirements')` & WP below
 
     * - :need:`wp__requirements_feat_aou`
       - :need:`gd_temp__req_aou_req`
       - :ndf:`copy('status', need_id='gd_temp__req_aou_req')`
-      - <link to issue>
       - :need:`doc__feature_name_requirements`
-      - doc :ndf:`copy('status', need_id='doc__feature_name_requirements')` & WP below
 
     * - :need:`wp__feature_arch`
       - :need:`gd_temp__arch_feature`
       - :ndf:`copy('status', need_id='gd_temp__arch_feature')`
-      - <link to issue>
       - :need:`doc__feature_name_architecture`
-      - doc :ndf:`copy('status', need_id='doc__feature_name_architecture')` & WP below
 
     * - :need:`wp__feature_fmea`
       - :need:`gd_temp__feat_saf_fmea`
       - :ndf:`copy('status', need_id='gd_temp__feat_saf_fmea')`
-      - <link to issue>
       - :need:`doc__feature_name_fmea`
-      - doc :ndf:`copy('status', need_id='doc__feature_name_fmea')` & WP below
 
     * - :need:`wp__feature_dfa`
       - :need:`gd_temp__feat_saf_dfa`
       - :ndf:`copy('status', need_id='gd_temp__feat_saf_dfa')`
-      - <Link to issue>
       - :need:`doc__feature_name_dfa`
-      - doc :ndf:`copy('status', need_id='doc__feature_name_dfa')` & WP below
 
     * - :need:`wp__requirements_inspect`
       - :need:`gd_chklst__req_inspection`
       - :ndf:`copy('status', need_id='gd_chklst__req_inspection')`
-      - <link to issue>
       - :need:`doc__feature_name_req_inspection`
-      - :ndf:`copy('status', need_id='doc__feature_name_req_inspection')`
 
     * - :need:`wp__sw_arch_verification`
       - :need:`gd_chklst__arch_inspection_checklist`
       - :ndf:`copy('status', need_id='gd_chklst__arch_inspection_checklist')`
-      - <link to issue>
       - :need:`doc__feature_name_arc_inspection`
-      - :ndf:`copy('status', need_id='doc__feature_name_arc_inspection')`
 
     * - :need:`wp__verification_feat_int_test`
       - :need:`gd_guidl__verification_guide`
       - :ndf:`copy('status', need_id='gd_guidl__verification_guide')`
-      - <link to issue>
       - <Link to WP>
-      - <automated>
 
 .. attention::
     The above table must be updated according to your feature safety planning.
 
-    - Create and link the issues to plan the work products (according to :need:`gd_guidl__saf_plan_definitions`)
-    - Fill the work producs links and add their status (also possible below) to create the safety package (according to :need:`gd_guidl__saf_package`)
+    - Fill the work producs links
+
+Feature Safety Package
+======================
+
+To create the safety package (according to :need:`gd_guidl__saf_package`) the following
+documents and work products status have to go to "valid" (after the relevant verification were performed).
+
+Feature Documents Status
+------------------------
+
+For all the work product documents the status can be seen by following the "Link to WP".
+A summary of the status is also documented in the project's documentation management plan.
+
+See <add here the section reference to the documentation management plan>
 
 Feature Requirements Status
 ---------------------------
@@ -153,7 +146,7 @@ Feature Architecture Status
 ---------------------------
 
 .. needtable::
-   :filter: "feature_name" in docname and "requirements" in docname and docname is not None
+   :filter: "feature_name" in docname and "architecture" in docname and docname is not None
    :style: table
    :types: feat_arc_sta; feat_arc_dyn
    :tags: feature_name

process/folder_templates/modules/module_name/component_name/docs/detailed_design/chklst_impl_inspection.rst

@@ -0,0 +1,101 @@
+..
+   # *******************************************************************************
+   # Copyright (c) 2025 Contributors to the Eclipse Foundation
+   #
+   # See the NOTICE file(s) distributed with this work for additional
+   # information regarding copyright ownership.
+   #
+   # This program and the accompanying materials are made available under the
+   # terms of the Apache License Version 2.0 which is available at
+   # https://www.apache.org/licenses/LICENSE-2.0
+   #
+   # SPDX-License-Identifier: Apache-2.0
+   # *******************************************************************************
+
+.. document:: [Your Component Name] Implementation Inspection Checklist
+   :id: doc__component_name_impl_inspection
+   :status: draft
+   :safety: ASIL_B
+   :security: YES
+   :realizes: wp__sw_implementation_inspection
+   :tags: template
+
+.. attention::
+    The above directive must be updated according to your Component.
+
+    - Modify ``Your Component Name`` to be your Component Name
+    - Modify ``id`` to be your Component Name in lower snake case preceded by ``doc__`` and followed by ``_impl_inspection``
+    - Adjust ``status`` to be ``valid``
+    - Adjust ``safety``, ``security`` and ``tags`` according to your needs
+
+Implementation Inspection Checklist
+===================================
+
+Purpose
+-------
+
+The purpose of this checklist is to collect the topics to be checked during implementation,
+i.e. in the detailed design and the source code of the units.
+
+The checklist shall be agnostic to which programming language is used. Differences shall be treated
+by linking to C++ or Rust specific documentation.
+
+Checklist
+---------
+
+.. list-table:: Implementation Checklist
+   :header-rows: 1
+   :widths: 10,30,50,6,6,8
+
+   * - Review ID
+     - Acceptance Criteria
+     - Guidance
+     - Passed
+     - Remarks
+     - Issue link
+   * - IMPL_01_01
+     - Is the design according to guidelines?
+     - see :need:`gd_temp__detailed_design` and :need:`doc_concept__imp_concept`
+       (e.g. are the views done with the proposed UML diagrams)
+     -
+     -
+     -
+   * - IMPL_01_02
+     - Is the implementation according to specification?
+     - Check if the linked component requirements are fulfilled
+       and detailed design also matches architecture description.
+     -
+     -
+     -
+   * - IMPL_01_03
+     - Are the design decisions and constraints documented?
+     - Check also for plausibility of these.
+     -
+     -
+     -
+   * - IMPL_01_04
+     - Are all external libraries used by the component specified in the detailed design?
+     - Check the automated dependency analysis.
+       Also make sure ASIL rated units also only use ASIL rated libraries.
+     -
+     -
+     -
+   * - IMPL_02_01
+     - Are the static and dynamic code analysis reports verified for violations?
+     - All violations in ASIL related code must be justified. This includes the checks of coding guidelines.
+     -
+     -
+     -
+   * - IMPL_02_02
+     - Do manual checks, that are derived from the coding guideline, find no safety critical error?
+     - Check this for the programming language used (e.g. C++ <link_to_checks_list>, Rust <link_to_checks_list>)
+     -
+     -
+     -
+   * - IMPL_02_03
+     - Are detailed design and source code consistent?
+     - Check if the static and dynamic design descriptions match the code (e.g. naming of elements)
+       and that the respective traceability is established
+     -
+     -
+     -

process/folder_templates/modules/module_name/component_name/docs/index.rst

@@ -178,6 +178,7 @@ Footnotes
    architecture/chklst_arc_inspection.rst
    component_classification.rst
    detailed_design/index.rst
+   detailed_design/chklst_impl_inspection.rst
    requirements/index.rst
    requirements/chklst_req_inspection.rst
    safety_analysis/fmea.rst

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

@@ -94,12 +94,6 @@ Requirement Inspection Checklist
         -
         -
       * - REQ_03_01
-        - For stakeholder requirements: Is the *rationale* correct?
-        - Rationales explain why the top level requirements were created. Do those cover the requirement?
-        -
-        -
-        -
-      * - REQ_03_02
         - 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.
         -
@@ -142,12 +136,6 @@ Requirement Inspection Checklist
         -
         -
       * - REQ_09_01
-        - 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
         - 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/safety_mgt/index.rst

@@ -21,3 +21,4 @@ Safety Management
    module_safety_plan
    module_safety_plan_fdr
    module_safety_package_fdr
+   module_safety_analysis_fdr