fix remaining review findings and other issues

RolandJentschETAS · RolandJentschETAS · commit 3499a00795a7 · 2025-11-26T14:47:31.000+01:00
diff --git a/process/folder_templates/modules/module_name/component_name/docs/architecture/index.rst b/process/folder_templates/modules/module_name/component_name/docs/architecture/index.rst
@@ -59,7 +59,8 @@ Design Constraints
 
 Rationale Behind Architecture Decomposition
 *******************************************
-mandatory: a motivation for the decomposition or reason for not further splitting it into sub components.
+
+Mandatory: a motivation for the decomposition or reason for not further splitting it into lower level components.
 
 .. note:: Common decisions across components / cross cutting concepts is at the higher level.
 
diff --git a/process/process_areas/architecture_design/architecture_concept.rst b/process/process_areas/architecture_design/architecture_concept.rst
@@ -40,26 +40,26 @@ Use Cases which require architectural information
 
    * *Dependent Failure Analysis*
 
-      * the interaction of the components with each other
+     * the interaction of the components with each other
 
    * *Qualitative safety analysis*
 
-      * decomposition of the architectural element under analysis
-      * interfaces within the architectural element under analysis (including their AoUs)
-      * usage of the components (interface of the component under analysis itself)
-      * allocate safety requirements to architectural elements
+     * decomposition of the architectural element under analysis
+     * interfaces within the architectural element under analysis (including their AoUs)
+     * usage of the components (interface of the component under analysis itself)
+     * allocate safety requirements to architectural elements
 
 #. **Security Analysis**
 
-   * TBD
+   * The architecture created to fulfill the requirements does not introduce possible vulnerabilities
 
 #. **Safety Planning**
 
    * Decomposition into modules and components for the safety planning
 
-#. **Security Planing**
+#. **Security Planning**
 
-   * TBD
+   * The architecture serves as the foundational framework for cybersecurity planning by enabling systematic asset identification, threat analysis, attack path modeling, and the structured derivation of cybersecurity goals and requirements
 
 #. **Platform SW Development**
 
@@ -94,9 +94,9 @@ Requirements based on standards
 
 Additionally also standards specify requirements towards the architectural design:
 
-* ISO26262
-* ASPICE
-* ISO21434
+* :ref:`ISO 26262<standard_iso26262>`
+* :ref:`ASPICE<standard_aspice_pam4>`
+* :ref:`ISO 21434<standard_isosae21434>`
 
 Their requirements are linked via the guidances.
 
@@ -137,12 +137,12 @@ The first viewpoint is named as *feature architecture*. It displays the SW modul
 
       {{ draw_feature(need(), needs) }}
 
-In all views the Components which are marked as ASIL_B related are drawn in blue color.
+In all views, the components which are marked as ASIL_B related are drawn with red borders.
 
 Dynamic View
 ------------
 
-The next chart shows the dynamic behavior of the feature including the interaction of its modules with the user. Following scenarios should be included:
+The next chart shows the *dynamic behavior* of the feature including the interaction of its modules with the user. Following scenarios should be included:
 
 *  important use cases or features: how do components execute them?
 *  interactions at critical external interfaces: how do components cooperate with users and neighboring components?
@@ -213,11 +213,20 @@ The second viewpoint is named as *component architecture* and describes the impl
       {{ draw_component(need(), needs) }}
 
 The *lower level components* are optional and rely on the complexity of the component. Thus there is no graphic representation required for it.
+In all views the Components which are marked as ASIL_B related are drawn in red color.
 
 Dynamic View
 ------------
 
-The dynamic view of the component architecture shows the order of the interactions between the respective components. It is displayed via relations to the interface operations which are provided or used by each component.
+The *dynamic view* of the component architecture shows the order of the interactions between the respective lower level components. It is displayed via relations to the interface operations which are provided or used by each component.
+
+Following scenarios should be included:
+
+*  important use cases: how do lower level components execute them?
+*  interactions at critical interfaces: how do lower level components cooperate with users and neighboring lower level components?
+*  operation and administration: launch, start-up, stop
+*  successful use cases
+*  error and exception use cases
 
 .. uml:: _assets/component_architecture_dynamic.puml
    :align: center
@@ -257,7 +266,7 @@ Specification of the architectural design
 *****************************************
 
 The architectural design shall be modeled with the help of static, dynamic and interfaces at each defined level.
-For the description a natural language, diagrams or a semi-formal language *(UML)* shall be used.
+For the description a natural language, diagrams or a semi-formal language (*UML*, see :ref:`uml_diagram_selection`) shall be used.
 
 The architectural elements itself including their correlations shall be modeled in a database like approach. Therefore following architectural elements shall be used:
 
@@ -298,7 +307,7 @@ Dynamic view
 
 The *dynamic view* describes the concrete behavior and interactions of the *building blocks* in form of use cases which were described above.
 
-The dynamic view shall be modeled partly in Sphinx Needs and PlantUML. The components itself shall be generated from the sphinx needs model into the PlantUML diagram. The dynamic relations between the component and the interfaces shall be modeled in PlantUML as it would be a huge effort to model the dynamic behavior in sphinx needs and would not provide any additional benefit.
+The dynamic view shall be modeled partly in Sphinx Needs and PlantUML. The components itself shall be used from the sphinx needs model in the PlantUML diagram. The dynamic relations between the component and the interfaces shall be modeled in PlantUML as it would be a huge effort to model the dynamic behavior in sphinx needs and would not provide any additional benefit.
 
 .. list-table:: Definition of the dynamic architectural elements
    :header-rows: 1
diff --git a/process/process_areas/architecture_design/architecture_getstrt.rst b/process/process_areas/architecture_design/architecture_getstrt.rst
@@ -35,7 +35,7 @@ General Workflow
 
    Architecture Design Workflow
 
-:numref:`architecture_workflow_fig` shows all steps which are required to create an architectural design. In this getting started only a short overview is given. A more detailed description of all the step is provided in the :need:`guideline <gd_guidl__arch_design>`
+:numref:`architecture_workflow_fig` shows all steps which are required to create an architectural design. In this getting started only a short overview is given. A more detailed description of all the step is provided in the :need:`guideline <gd_guidl__arch_design>`.
 
 Tooling support
 ***************
@@ -80,7 +80,7 @@ To generate a UML diagram, use the *needarch* directive in your Sphinx-Needs doc
 
       {{ draw_feature(need(), needs) }}
 
-It's also possible to manually extend the drawing. For an example, check out :ref:`manual_addition_uml`
+It's also possible to manually extend the drawing. For an example, check out :ref:`manual_addition_uml`.
 
 Available Drawing Classes
 -------------------------
@@ -110,7 +110,7 @@ Here are some excerpts of UML diagrams made from the requirements of that file.
 Feature Architecture
 ^^^^^^^^^^^^^^^^^^^^
 
-The following section is an example, how an `Feature <https://eclipse-score.github.io/score/main/features/index.html>`_ looks like and how the architecture of an Feature is described. Please notice, that in the diagram components with an safety rating to "ASIL_B" is drawn with an red border (see "Component 1" as example).
+The following section is an example, how an `Feature <https://eclipse-score.github.io/score/main/features/index.html>`_ looks like and how the architecture of an Feature is described. Please note that components with an "ASIL_B" safety rating are highlighted with red borders in the diagram (e.g., "Component 1").
 
 .. feat_arc_sta:: Feature Getting Started
       :id: feat_arc_sta__example_feature__archdes_getstrt
diff --git a/process/process_areas/architecture_design/architecture_roles.rst b/process/process_areas/architecture_design/architecture_roles.rst
@@ -19,10 +19,10 @@ For architecture design no additional roles need to be defined.
 
 Contributing Roles:
 
-   * :need:`Contributor <rl__contributor>`
-   * :need:`Committer <rl__committer>`
-   * :need:`Safety Manager <rl__safety_manager>`
-   * :need:`Security Manager <rl__security_manager>`
+* :need:`Contributor <rl__contributor>`
+* :need:`Committer <rl__committer>`
+* :need:`Safety Manager <rl__safety_manager>`
+* :need:`Security Manager <rl__security_manager>`
 
 A detailed overview of the responsibility for the steps of the architecture design process is listed here:
 
diff --git a/process/process_areas/architecture_design/architecture_workproducts.rst b/process/process_areas/architecture_design/architecture_workproducts.rst
@@ -37,7 +37,7 @@ Architecture Workproducts
 
    Component Architecture linked to Component Requirements
 
-   * Static view (Sphinx Needs) - Component interfaces (to outside of Component) and interfaces between own (sub) components
+   * Static view (Sphinx Needs) - Component interfaces (to outside of Component) and interfaces between own (lower level) components
    * Dynamic view (UML) - Sequences of components interactions and components states
    * Interface view (Sphinx Needs) - Overview of used and provided interfaces
 
diff --git a/process/process_areas/architecture_design/guidance/architecture_guideline.rst b/process/process_areas/architecture_design/guidance/architecture_guideline.rst
@@ -22,7 +22,7 @@ Architecture Guideline
    :status: valid
    :complies: std_req__isopas8926__44411, std_req__isopas8926__44412
 
-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>`
+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>`.
 
 General Hints
 =============
@@ -127,12 +127,12 @@ Based on the concept description a model of the feature architecture should be d
      - logic_arc_int_op
      - logic_arc_int_op_t
 
-The relations of the static elements are described in :numref:`metamodel_architectural_design`.
+The relations of the static elements are described in :ref:`metamodel_architectural_design`.
 
 .. note::
    For the modeling of the architecture a sphinx extension is available: :ref:`arch_gen_sphinx`
 
-   An example for modeling the architecture can be found :ref:`here <definition_architectural_design>`
+   An example for modeling the architecture can be found :ref:`here <definition_architectural_design>`.
 
 .. _allocate_feature_requirements:
 
@@ -143,7 +143,7 @@ In the next step the already derived feature requirements shall be allocated to
 
 If needed also additional feature requirements, which may arise due to architectural decisions, should be created and allocated to the feature architecture itself.
 
-Those links shall be established from architectural elements to feature requirements via the attribute *fulfils*
+Those links shall be established from architectural elements to feature requirements via the attribute *fulfils*.
 
 .. _review_architectural_design:
 
@@ -183,7 +183,7 @@ In this step the component requirements shall be derived (see :need:`[[title]] <
 Model component architecture
 ----------------------------
 
-According to the architecture design description the model for the component architecture shall be created. It shall consist of components, real interfaces and real interface operations. Depending on the size of the component it can also be split into multiple (sub) components.
+According to the architecture design description the model for the component architecture shall be created. It shall consist of components, real interfaces and real interface operations. Depending on the size of the component, it can also be split into multiple (lower level) components.
 
 .. list-table:: Architectural Elements of the Component Architecture
    :header-rows: 1
@@ -202,7 +202,7 @@ According to the architecture design description the model for the component arc
      - real_arc_int_op
      - real_arc_int_op_t
 
-The relations of the static elements are described in :numref:`metamodel_architectural_design`
+The relations of the static elements are described in :ref:`metamodel_architectural_design`.
 
 .. _review_component_architecture:
 
@@ -221,6 +221,8 @@ For the review process a checklist template is available:
 
 :need:`[[title]] <gd_chklst__arch_inspection_checklist>`
 
+.. _uml_diagram_selection:
+
 UML diagram selection
 =====================
 
@@ -245,4 +247,4 @@ Generally dynamic views are expected in the feature view and the component view
 - In case of safety related calls/communication also the error cases shall be displayed (see the "alt" boxes in the examples).
 - If there would be only small difference between the feature and the component view, one can be omitted, preferrably the feature view.
 - If the described feature or components support multiple use cases (e.g. in different life cycle phases).
-  these should be described also in multiple dynamic views.
+  These should be described also in multiple dynamic views.
