fix remaining review findings and other issues

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.
 

process/general_concepts/score_building_blocks_concept.rst

@@ -52,7 +52,7 @@ may mitigated by updating the Component Requirements or by the **Component Assum
 as well as the Integration of multiple Units to a Component.
 
 As mentioned above a Software Module is defined as a Component or a set of components realizing a
-Feature of the platform. Features consists of Components and are defined by **Feature Requirements**
+Feature of the platform. Features consists of components and are defined by **Feature Requirements**
 (yellow box, middle, 3rd column) and the **Feature Architecture** (yellow box, middle, 4th column).
 A **Feature Safety Analysis** (yellow box, middle, 6th column) is required to verify the Feature
 Architecture, whereby violations of safety requirements must be documented. Potential

process/general_concepts/score_traceability_concept.rst

@@ -59,7 +59,7 @@ of use. For convenience also the traceability to upper and lower lever requireme
 The next figures sets the focus on the component level and adds the traceability from the
 Component Requirements to the Component Architecture, Component Safety Analysis
 and the Component Assumption of use. Further the traceability to Component Assumptions of use
-from external Components is included.
+from external components is included.
 
 
 .. figure:: _assets/score_traceability_model_cmp_overview_1.drawio.svg

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

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

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:
 

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
 

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.

process/process_areas/change_management/change_management_concept.rst

@@ -26,12 +26,12 @@ including the requirements of the different stakeholders for the Change Manageme
 
 Key concept
 ***********
-A Change Request is the **ONLY** way to contribute new features or to modify the scope
+A *Change Request* is the **ONLY** way to contribute new features or to modify the scope
 of existing features in the project.
-As features are built-up by Components a Change Request is also needed to add new
-Components or to modify the scope of existing Components.
-As a Software Module is defined as the top-level Component, all statements here for
-Components are also valid for Software Modules.
+As features are built-up by components a Change Request is also needed to add new
+components or to modify the scope of existing components.
+As a *Software Module* is defined as the top-level component, all statements here for
+components are also valid for Software Modules.
 
 Inputs
 ******

process/process_areas/change_management/change_management_workproducts.rst

@@ -60,7 +60,7 @@ Work Products Change Management
    |
    | Change Request for a new component or a modification of an existing component,
    | which changes the scope of the component.
-   | Software Modules are also Components (top-level component).
+   | Software Modules are also components (top-level component).
 
 .. needextend:: docname is not None and "process_areas/change_management" in docname
    :+tags: change_management

process/process_areas/safety_analysis/safety_analysis_concept.rst

@@ -110,7 +110,7 @@ The analysis were applied at static and dynamic architecture diagrams. The follo
    Feature Architecture
 
 With the diagrams the dependencies and signal flows are shown. The analysis is done by applying the fault models :need:`gd_guidl__fault_models` in the above example's dynamic view the "flow component 1" to the user realizes a safety requirement. If we apply the fault model we may find the possible failure: "the message is not sent which leads to the user not being able to ..." - this could be mitigated by telling the user in an AoU: "the feature can not guarantee that the message is sent"
-DFA: Here we see in the static view that component 1 uses component 2. If we apply the failure initiators we may find the possible failure: "Component 2 is using up all execution time available to Component 1" which could be avoided by a OS which is reserving time for every component or by running these Components on different processors.
+DFA: Here we see in the static view that component 1 uses component 2. If we apply the failure initiators we may find the possible failure: "Component 2 is using up all execution time available to Component 1" which could be avoided by a OS which is reserving time for every component or by running these components on different processors.
 for FMEA and the failure initiators :need:`gd_guidl__dfa_failure_initiators` for DFA. Some fault models and failure initiators may not be applicable
 for one safety function. In this case the reason shall be documented in the FMEA/DFA documents. So it can be shown that the analysis is completely done.