From 96b98971cd5d38906cd1d88773f991089f3900ff Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Fri, 12 Jun 2026 14:19:14 +0200 Subject: [PATCH 1/5] add aspice 4 ml3 things --- .../guidance/architecture_guideline.rst | 25 +++++++++++++++++-- .../architecture_inspection_checklist.rst | 2 +- process/roles/index.rst | 13 ++++++++++ 3 files changed, 37 insertions(+), 3 deletions(-) diff --git a/process/process_areas/architecture_design/guidance/architecture_guideline.rst b/process/process_areas/architecture_design/guidance/architecture_guideline.rst index d207130cd9..475b4872b2 100644 --- a/process/process_areas/architecture_design/guidance/architecture_guideline.rst +++ b/process/process_areas/architecture_design/guidance/architecture_guideline.rst @@ -20,7 +20,7 @@ Architecture Guideline .. gd_guidl:: Architectural Design Guideline :id: gd_guidl__arch_design :status: valid - :complies: std_req__isopas8926__44411, std_req__isopas8926__44412, std_req__iso26262__software_743, std_req__iso26262__software_744, std_req__iso26262__software_745 + :complies: std_req__isopas8926__44411, std_req__isopas8926__44412, std_req__iso26262__software_743, std_req__iso26262__software_744, std_req__iso26262__software_745, std_req__aspice_40__iic-10-50, std_req__aspice_40__iic-10-51, std_req__aspice_40__iic-10-52 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]] `. @@ -245,6 +245,8 @@ Based on the *feature architecture*, the concept for the *component architecture For this step, the following guidance is available: :need:`Feature Architecture Template `. 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 `. +**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 @@ -257,7 +259,9 @@ 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. However, the external interface view is always mandatory and must be documented. .. list-table:: Architectural Elements of the Component Architecture :header-rows: 1 @@ -316,3 +320,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. diff --git a/process/process_areas/architecture_design/guidance/architecture_inspection_checklist.rst b/process/process_areas/architecture_design/guidance/architecture_inspection_checklist.rst index b56cdddf18..4ef76830cc 100644 --- a/process/process_areas/architecture_design/guidance/architecture_inspection_checklist.rst +++ b/process/process_areas/architecture_design/guidance/architecture_inspection_checklist.rst @@ -21,7 +21,7 @@ Architecture Inspection Checklist Template :id: gd_chklst__arch_inspection_checklist :status: valid :tags: architecture_design - :complies: std_req__iso26262__software_647, std_req__iso26262__software_743, std_req__iso26262__software_749, std_req__iso26262__software_7413, std_req__aspice_40__iic-15-51, std_req__aspice_40__SWE-2-BP4, std_req__aspice_40__iic-13-51, std_req__aspice_40__SWE-2-BP5 + :complies: std_req__iso26262__software_647, std_req__iso26262__software_743, std_req__iso26262__software_749, std_req__iso26262__software_7413, std_req__aspice_40__iic-15-51, std_req__aspice_40__SWE-2-BP4, std_req__aspice_40__iic-13-51, std_req__aspice_40__SWE-2-BP5, std_req__aspice_40__iic-08-63, std_req__aspice_40__iic-03-06 For the content see here: diff --git a/process/roles/index.rst b/process/roles/index.rst index c6355f959f..fe6ea8f227 100644 --- a/process/roles/index.rst +++ b/process/roles/index.rst @@ -96,6 +96,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 + * Review of existing architecture examples in module template + * Knowledge of UML/SysML notation (component diagrams, sequence diagrams) + + .. note:: Defines and enforces processes. From c7e6b9989b338bae819ee48e5e1af008c91f32bf Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Fri, 12 Jun 2026 16:42:58 +0200 Subject: [PATCH 2/5] add monitoring --- .../guidance/architecture_process_reqs.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst b/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst index 13f9df5991..7ac11d8b32 100644 --- a/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst +++ b/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst @@ -290,3 +290,20 @@ Checks for Architectural Design :satisfies: wf__cr_mt_featarch, wf__cr_mt_comparch 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_1 + :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. + + Improvement actions should be handled according to :ref:`pm_monitor_improve_process`. From cb0cf5a7fc63fc2d1c7d0db0f49fa3c85a0c3beb Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Fri, 12 Jun 2026 16:56:18 +0200 Subject: [PATCH 3/5] add monitoring checks --- .../guidance/architecture_guideline.rst | 12 ++++++++++++ .../guidance/architecture_process_reqs.rst | 2 +- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/process/process_areas/architecture_design/guidance/architecture_guideline.rst b/process/process_areas/architecture_design/guidance/architecture_guideline.rst index 475b4872b2..90c03e5c13 100644 --- a/process/process_areas/architecture_design/guidance/architecture_guideline.rst +++ b/process/process_areas/architecture_design/guidance/architecture_guideline.rst @@ -51,6 +51,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 ============================================= diff --git a/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst b/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst index 7ac11d8b32..7ddf11e8b7 100644 --- a/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst +++ b/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst @@ -298,7 +298,7 @@ Process Monitoring and Improvement .. gd_req:: Monitor architecture process performance :id: gd_req__arch_process_monitoring :status: valid - :tags: manual_prio_1 + :tags: manual_prio_1, 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 From 673127b7c302bc58c697ba8f0f569b3a4a96d997 Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Mon, 15 Jun 2026 16:29:55 +0200 Subject: [PATCH 4/5] fix review findings --- .../architecture_design/guidance/architecture_guideline.rst | 5 ++++- .../guidance/architecture_process_reqs.rst | 4 +++- process/roles/index.rst | 4 ++-- 3 files changed, 9 insertions(+), 4 deletions(-) diff --git a/process/process_areas/architecture_design/guidance/architecture_guideline.rst b/process/process_areas/architecture_design/guidance/architecture_guideline.rst index 90c03e5c13..3b4abe58c4 100644 --- a/process/process_areas/architecture_design/guidance/architecture_guideline.rst +++ b/process/process_areas/architecture_design/guidance/architecture_guideline.rst @@ -273,7 +273,10 @@ 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 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. However, the external interface view is always mandatory and must be documented. +**Tailoring for Component Complexity:** For simple components with fewer than 3 internal sub-components, the internal component architecture decomposition may be omitted. +However, the external interface view (to interfaces from other modules) is always mandatory and must be documented. + +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 `. .. list-table:: Architectural Elements of the Component Architecture :header-rows: 1 diff --git a/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst b/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst index 7ddf11e8b7..857a2830e8 100644 --- a/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst +++ b/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst @@ -298,7 +298,7 @@ Process Monitoring and Improvement .. gd_req:: Monitor architecture process performance :id: gd_req__arch_process_monitoring :status: valid - :tags: manual_prio_1, process_monitoring + :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 @@ -306,4 +306,6 @@ Process Monitoring and Improvement 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`. diff --git a/process/roles/index.rst b/process/roles/index.rst index fe6ea8f227..d9d8469756 100644 --- a/process/roles/index.rst +++ b/process/roles/index.rst @@ -105,8 +105,8 @@ Project Development Roles * 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 - * Review of existing architecture examples in module template - * Knowledge of UML/SysML notation (component diagrams, sequence diagrams) + * Knowledge of existing architecture examples in module template + * Knowledge of UML notation (component diagrams, sequence diagrams) .. note:: From 9f744ea96c098e3dbd987edbd9e40e467c027b6c Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Tue, 16 Jun 2026 16:40:24 +0200 Subject: [PATCH 5/5] remove external, because covered by feature architecture view --- .../architecture_design/guidance/architecture_guideline.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/process/process_areas/architecture_design/guidance/architecture_guideline.rst b/process/process_areas/architecture_design/guidance/architecture_guideline.rst index 52093746bd..71ff8068fa 100644 --- a/process/process_areas/architecture_design/guidance/architecture_guideline.rst +++ b/process/process_areas/architecture_design/guidance/architecture_guideline.rst @@ -26,8 +26,8 @@ Architecture Guideline std_req__iso26262__software_743[version==1], std_req__iso26262__software_744[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-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]] `. @@ -282,7 +282,6 @@ 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 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. -However, the external interface view (to interfaces from other modules) is always mandatory and must be documented. 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 `.