add aspice 4 ml3 architecture (#702)

* add aspice 4 ml3 things

* add monitoring

* add monitoring checks

* fix review findings

* remove external, because covered by feature architecture view

---------

Signed-off-by: RolandJentschETAS <135332348+RolandJentschETAS@users.noreply.github.com>

Author: RolandJentschETAS

process/process_areas/architecture_design/guidance/architecture_guideline.rst

@@ -25,7 +25,10 @@ Architecture Guideline
               std_req__isopas8926__44412[version==1],
               std_req__iso26262__software_743[version==1],
               std_req__iso26262__software_744[version==1],
-              std_req__iso26262__software_745[version==1]
+              std_req__iso26262__software_745[version==1],
+              std_req__aspice_40__iic-10-50[version==1],
+              std_req__aspice_40__iic-10-51[version==1],
+              std_req__aspice_40__iic-10-52[version==1]
 
 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>`.
 
@@ -56,6 +59,18 @@ For architectural elements, the following checks are defined:
    :colwidths: 50,70
 
 
+Process Monitoring
+------------------
+
+The following process monitoring activities shall be performed:
+
+.. needtable:: Overview of process monitoring
+   :filter: "process_monitoring" in tags and type == "gd_req" and is_external == False
+   :style: table
+   :columns: title; id
+   :colwidths: 50,70
+
+
 Workflow for creating an architectural design
 =============================================
 
@@ -250,6 +265,8 @@ Based on the *feature architecture*, the concept for the *component architecture
 
 For this step, the following guidance is available: :need:`Feature Architecture Template <gd_temp__arch_feature>`. Additionally, you should consult your project's specific guidelines, e.g., for using the version management tooling or architecture element naming conventions, which should be defined (or linked) in the :need:`Project SW development Plan <wp__sw_development_plan>`.
 
+**Reuse of Existing Components:** For proven-in-use components, the architecture documentation may reference the existing documentation instead of re-creating it. In such cases, a delta analysis documenting deviations from the original context and any changes in application conditions shall be provided.
+
 .. _allocate_component_requirements:
 
 Allocate component requirements to architectural elements
@@ -262,7 +279,11 @@ 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 (lower-level) 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 and complexity of the component, it can also be split into multiple (lower-level) components.
+
+**Tailoring for Component Complexity:** For simple components with fewer than 3 internal sub-components, the internal component architecture decomposition may be omitted.
+
+Complexity can be assessed project-specifically (for example by Lines of Code, interface size, decomposition depth, coupling, or control-flow metrics such as McCabe). For default measurement see :need:`Implementation Complexity Analysis <gd_req__impl_complexity_analysis>`.
 
 .. list-table:: Architectural Elements of the Component Architecture
    :header-rows: 1
@@ -321,3 +342,20 @@ Generally dynamic views are expected in the feature view and the component view
 - In case of safety-related calls/communication, the error cases shall also be displayed (see the "alt" boxes in the examples).
 - If there is only a small difference between the feature and the component view, one can be omitted, preferably the feature view.
 - If the described feature or components support multiple use cases (e.g., in different life-cycle phases), these should also be described in multiple dynamic views.
+
+**Tailoring for Safety Classification:** For QM (quality management) components, the dynamic architecture view may be omitted if the static view is sufficient to understand the design. However, safety-relevant components (ASIL B or higher) shall always include both static and dynamic views if they are not trivial.
+
+
+.. _platform_scope_responsibilities:
+
+Scope and Responsibilities
+==========================
+
+Since SCORE provides a middleware platform, the following aspects are explicitly **out of scope** for the platform architecture process and shall be addressed by the user of the middleware:
+
+* System-level architecture integrating the middleware into a target ECU
+* Hardware-Software Interface (HSI) design
+* Application-specific scheduling and task allocation beyond what the platform provides
+* System-level safety architecture (e.g., ASIL decomposition at vehicle level)
+
+Architectural views describing integration aspects at the system level (above platform boundary) are the responsibility of the platform user (system integrator). The platform shall provide Assumptions of Use (AoU) documenting architectural constraints that the platform user must satisfy. These responsibilities shall be communicated to platform users via AoUs associated with the platform and feature architectures.

process/process_areas/architecture_design/guidance/architecture_inspection_checklist.rst

@@ -29,7 +29,9 @@ Architecture Inspection Checklist Template
                std_req__aspice_40__iic-15-51[version==1],
                std_req__aspice_40__SWE-2-BP4[version==1],
                std_req__aspice_40__iic-13-51[version==1],
-               std_req__aspice_40__SWE-2-BP5[version==1]
+               std_req__aspice_40__SWE-2-BP5[version==1],
+               std_req__aspice_40__iic-08-63[version==1], 
+               std_req__aspice_40__iic-03-06[version==1]
 
     For the content see here:
 

process/process_areas/architecture_design/guidance/architecture_process_reqs.rst

@@ -317,3 +317,22 @@ Checks for Architectural Design
    :satisfies: wf__cr_mt_featarch[version==1], wf__cr_mt_comparch[version==1]
 
    It shall be checked if all SW components which are mentioned in the dynamic architecture views are defined in the static architecture.
+
+
+Process Monitoring and Improvement
+----------------------------------
+
+.. gd_req:: Monitor architecture process performance
+   :id: gd_req__arch_process_monitoring
+   :status: valid
+   :tags: manual_prio_2, process_monitoring
+   :complies: std_req__aspice_40__gp-324, std_req__aspice_40__iic-03-06
+   :satisfies: wf__cr_mt_featarch, wf__cr_mt_comparch
+
+   Information about the execution and outcomes of the architecture process shall be collected and analyzed to evaluate the effectiveness and adequacy of the defined process.
+
+   Analysis results shall be made available to affected parties and used to identify and trigger continual improvement actions for the architecture process.
+
+   Monitoring is expected as a periodic, predominantly manual activity (for example as part of quality checks and retrospectives), not as a fully automated check.
+
+   Improvement actions should be handled according to :ref:`pm_monitor_improve_process`.

process/roles/index.rst

@@ -101,6 +101,19 @@ Project Development Roles
 
    (Eclipse) Open Source Role, person(s) who accept(s) possible contribution(s) as pull request(s) to the main line and maintains the product.
 
+   Required skills and knowledge of standards
+
+   * Experience in reviewing architectural designs for correctness, consistency, and completeness
+   * Knowledge of ASPICE SWE.2 base practices
+   * Understanding of traceability requirements between architecture and requirements
+   * Understanding of software design patterns and principles (e.g., SOLID, separation of concerns)
+   * Knowledge of the platform domain (middleware, OS abstraction, communication)
+   * Ability to work with Sphinx-Needs and PlantUML tooling
+   * Understanding of safety/security attributes and their impact on architecture
+   * Knowledge of existing architecture examples in module template
+   * Knowledge of UML notation (component diagrams, sequence diagrams)
+
+
    .. note::
       Defines and enforces processes.