From f74ae76c3363c8e4cd501678edfa6220fed45b85 Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Thu, 15 Jan 2026 16:35:02 +0100 Subject: [PATCH 1/3] Improvement: Fix audit findings --- .../architecture/chklst_arc_inspection.rst | 2 + .../feature_name/architecture/index.rst | 56 +++++++++------ .../requirements/chklst_req_inspection.rst | 2 + .../architecture/chklst_arc_inspection.rst | 2 + .../docs/architecture/index.rst | 24 +++---- .../chklst_impl_inspection.rst | 2 + .../module_name/component_name/docs/index.rst | 72 +++++++++---------- .../requirements/chklst_req_inspection.rst | 2 + .../safety_mgt/module_safety_analysis_fdr.rst | 2 + .../safety_mgt/module_safety_package_fdr.rst | 2 + .../safety_mgt/module_safety_plan_fdr.rst | 2 + .../stakeholder/chklst_req_inspection.rst | 2 + .../platform_safety_analysis_fdr.rst | 2 + .../component_architecture_dynamic.puml | 4 +- .../architecture_concept.rst | 14 ++-- .../architecture_workproducts.rst | 2 +- .../architecture_modeling_example.rst | 10 +-- .../guidance/architecture_process_reqs.rst | 2 +- .../guidance/change_management_checklist.rst | 2 + .../guidance/documentation_checklist.rst | 2 + .../guidance/implementation_process_reqs.rst | 11 ++- .../guidance/problem_resolution_checklist.rst | 2 + .../guidance/security_analysis_checklist.rst | 2 + ..._management_checklist_security_package.rst | 2 + ...ity_management_checklist_security_plan.rst | 2 + .../guidance/tool_management_checklist.rst | 2 + process/trustable/assertions/assertions.rst | 4 +- 27 files changed, 143 insertions(+), 90 deletions(-) diff --git a/process/folder_templates/features/feature_name/architecture/chklst_arc_inspection.rst b/process/folder_templates/features/feature_name/architecture/chklst_arc_inspection.rst index d22b57719b..bf1fcafedd 100644 --- a/process/folder_templates/features/feature_name/architecture/chklst_arc_inspection.rst +++ b/process/folder_templates/features/feature_name/architecture/chklst_arc_inspection.rst @@ -45,6 +45,8 @@ communication and documentation of architectural decisions to stakeholders. Checklist --------- +Please note that it is mandatory to fill in the "passed" column with "yes" or "no" for each checklist item and additional to add in the remarks why it is passed or not passed. In case of "no" an issue link to the issue tracking system has to be added in the last column. See also :ref:`review_concept` for further information about reviews in general and inspection in particular. + .. list-table:: Architecture Design Review Checklist :header-rows: 1 diff --git a/process/folder_templates/features/feature_name/architecture/index.rst b/process/folder_templates/features/feature_name/architecture/index.rst index de4c9549c1..008ac3bcb8 100644 --- a/process/folder_templates/features/feature_name/architecture/index.rst +++ b/process/folder_templates/features/feature_name/architecture/index.rst @@ -35,16 +35,16 @@ Feature Architecture Overview -------- -Brief summary + Description ----------- -General Description + -Design Decisions - For the documentation of the decision the :need:`gd_temp__change_decision_record` can be used. + -Design Constraints + Requirements ------------ @@ -58,9 +58,17 @@ Requirements :colwidths: 70,30 +.. needtable:: Overview of Feature Requirements + :style: table + :columns: title;id + :filter: search("feat_arch_sta__archdes$", "fulfils_back") + :colwidths: 70,30 + + Rationale Behind Architecture Decomposition ******************************************* -mandatory: a motivation for the decomposition + +Mandatory: A motivation for the decomposition .. note:: Common decisions across features / cross cutting concepts is at the high level. @@ -72,18 +80,18 @@ Static Architecture :security: YES :safety: ASIL_B :status: invalid - :includes: logic_arc_int__feature_name__interface_name - :consists_of: comp__component_name + :includes: logic_arc_int__feature_name__interface_name1 + :consists_of: comp__component_name_template General Feature Description -.. feat_arc_sta:: Static View +.. feat_arc_sta:: Feature Static View :id: feat_arc_sta__feature_name__static_view :security: YES :safety: ASIL_B :status: invalid :fulfils: feat_req__feature_name__some_title - :includes: logic_arc_int__feature_name__interface_name + :includes: logic_arc_int__feature_name__interface_name1 .. needarch:: :scale: 50 @@ -107,7 +115,7 @@ Logical Interfaces ------------------ .. logic_arc_int:: Interface Name - :id: logic_arc_int__feature_name__interface_name + :id: logic_arc_int__feature_name__interface_name1 :security: YES :safety: ASIL_B :status: invalid @@ -125,7 +133,7 @@ Logical Interfaces :security: YES :safety: ASIL_B :status: invalid - :included_by: logic_arc_int__feature_name__interface_name + :included_by: logic_arc_int__feature_name__interface_name1 General Operation Description @@ -135,9 +143,14 @@ Module Viewpoint The following modules are needed to be defined to be able to draw the static feature view. They will be replaced by linking the proper module definitions in the used module's repositories as soon as those exist. -.. mod_view_sta:: Module Name +.. mod:: Module Name + :id: mod__module_name + :includes: comp__component_name_template + + +.. mod_view_sta:: Module Name Static View :id: mod_view_sta__feature_name__module_name - :includes: comp_arc_sta__feature_name__component_name + :includes: comp__component_name_template .. needarch:: :scale: 50 @@ -151,18 +164,19 @@ Used Components The following components are needed to be defined to be able to draw the static feature view. They will be replaced by linking the proper SW component definitions in the used module's repositories as soon as those exist. -.. comp_arc_sta:: Component Name - :id: comp_arc_sta__feature_name__component_name - :safety: ASIL_B - :security: YES - :status: invalid - :fulfils: comp_req__component_name__some_title - :implements: logic_arc_int__feature_name__interface_name +.. code-block:: rst + + .. comp:: Component Name + :id: comp__component_name_template + :safety: ASIL_B + :security: YES + :status: invalid + :implements: logic_arc_int__feature_name__interface_name1 .. note:: Architecture can be split into multiple files, it is an high level architecture design which can be shown without actual c++/rust interfaces and data types - and there will be link to lower level architecture till code to get actual api descriptions. + and there will be link to internal architecture till code to get actual api descriptions. .. attention:: The above directives must be updated according to your feature architecture. diff --git a/process/folder_templates/features/feature_name/requirements/chklst_req_inspection.rst b/process/folder_templates/features/feature_name/requirements/chklst_req_inspection.rst index 1f8a5ddd0e..9149f8e128 100644 --- a/process/folder_templates/features/feature_name/requirements/chklst_req_inspection.rst +++ b/process/folder_templates/features/feature_name/requirements/chklst_req_inspection.rst @@ -47,6 +47,8 @@ Requirement Inspection Checklist **Checklist** + See also :ref:`review_concept` for further information about reviews in general and inspection in particular. + .. list-table:: Feature Requirement Inspection Checklist :header-rows: 1 :widths: 10,30,50,6,6,8 diff --git a/process/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.rst b/process/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.rst index 33b6511530..5c612a3cab 100644 --- a/process/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.rst +++ b/process/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.rst @@ -45,6 +45,8 @@ communication and documentation of architectural decisions to stakeholders. Checklist --------- +Please note that it is mandatory to fill in the "passed" column with "yes" or "no" for each checklist item and additional to add in the remarks why it is passed or not passed. In case of "no" an issue link to the issue tracking system has to be added in the last column. See also :ref:`review_concept` for further information about reviews in general and inspection in particular. + .. list-table:: Architecture Design Review Checklist :header-rows: 1 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 index df79dd20c6..669d78e88f 100644 --- 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 @@ -35,7 +35,7 @@ Component Architecture Overview -------- -Brief summary + Requirements Linked to Component Architecture --------------------------------------------- @@ -51,16 +51,16 @@ Requirements Linked to Component Architecture Description ----------- -General Description + -Design Decisions - For the documentation of the decision the :need:`gd_temp__change_decision_record` can be used. + -Design Constraints + Rationale Behind Architecture Decomposition ******************************************* -Mandatory: a motivation for the decomposition or reason for not further splitting it into lower level components. +Mandatory: A motivation for the decomposition or reason for not further splitting it into internal components. .. note:: Common decisions across components / cross cutting concepts is at the higher level. @@ -71,18 +71,18 @@ The components are designed to cover the expectations from the feature architect (i.e. if already exists a definition it should be taken over and enriched). .. comp:: Component Name - :id: comp__component_name + :id: comp__component_name_template :security: YES :safety: ASIL_B :status: invalid - :implements: logic_arc_int__feature_name__interface_name + :implements: logic_arc_int__feature_name__interface_name1 .. comp_arc_sta:: Component Name (Static View) :id: comp_arc_sta__component_name__static_view :security: YES :safety: ASIL_B :status: invalid - :implements: logic_arc_int__feature_name__interface_name + :implements: logic_arc_int__feature_name__interface_name1 :fulfils: comp_req__component_name__some_title :includes: comp_arc_sta__component_name__2 @@ -117,16 +117,16 @@ Interfaces :fulfils: :language: cpp -Lower Level Components ----------------------- +Internal Components +------------------- -.. comp_arc_sta:: Component Name 2 +.. comp_arc_sta:: Component Name Static View :id: comp_arc_sta__component_name__2 :status: invalid :safety: ASIL_B :security: YES :fulfils: comp_req__component_name__some_title - :implements: logic_arc_int__feature_name__interface_name + :implements: logic_arc_int__feature_name__interface_name1 No architecture but detailed design diff --git a/process/folder_templates/modules/module_name/component_name/docs/detailed_design/chklst_impl_inspection.rst b/process/folder_templates/modules/module_name/component_name/docs/detailed_design/chklst_impl_inspection.rst index 2253721141..2b4a68f7fe 100644 --- a/process/folder_templates/modules/module_name/component_name/docs/detailed_design/chklst_impl_inspection.rst +++ b/process/folder_templates/modules/module_name/component_name/docs/detailed_design/chklst_impl_inspection.rst @@ -43,6 +43,8 @@ by linking to C++ or Rust specific documentation. Checklist --------- +See also :ref:`review_concept` for further information about reviews in general and inspection in particular. + .. list-table:: Implementation Checklist :header-rows: 1 :widths: 10,30,50,6,6,8 diff --git a/process/folder_templates/modules/module_name/component_name/docs/index.rst b/process/folder_templates/modules/module_name/component_name/docs/index.rst index 65c0da2137..6316594fd7 100644 --- a/process/folder_templates/modules/module_name/component_name/docs/index.rst +++ b/process/folder_templates/modules/module_name/component_name/docs/index.rst @@ -46,11 +46,11 @@ Motivation [Clearly explain why the existing platform/project solution is inadequate to address the topic that the CR solves.] - .. note:: - The motivation is critical for CRs that want to change the existing components. - It should clearly explain why the existing solution is inadequate to address the topic that the CR solves. - Motivation may based on criteria as resource requirements, scheduling issues, risks, benefits, etc. - CRs submissions without sufficient motivation may be rejected. +.. note:: + The motivation is critical for CRs that want to change the existing components. + It should clearly explain why the existing solution is inadequate to address the topic that the CR solves. + Motivation may based on criteria as resource requirements, scheduling issues, risks, benefits, etc. + CRs submissions without sufficient motivation may be rejected. @@ -59,10 +59,9 @@ Rationale [Describe why particular design decisions were made.] - - .. note:: - The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. - For the documentation of the decision the :need:`gd_temp__change_decision_record` can be used. +.. note:: + The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. + For the documentation of the decision the :need:`gd_temp__change_decision_record` can be used. Specification ============= @@ -70,10 +69,9 @@ Specification [Describe the requirements, architecture of any new component.] or [Describe the change to requirements, architecture, implementation, documentation of any change request.] - .. note:: - A CR shall specify the component requirements as part of our platform/project. - Thereby the :need:`rl__project_lead` will approve these requirements as part of accepting the CR (e.g. merging the PR with the CR). - +.. note:: + A CR shall specify the component requirements as part of our platform/project. + Thereby the :need:`rl__project_lead` will approve these requirements as part of accepting the CR (e.g. merging the PR with the CR). Backwards Compatibility @@ -87,8 +85,8 @@ Security Impact [How could a malicious user take advantage of this new/modified component?] - .. note:: - If there are security concerns in relation to the CR, those concerns should be explicitly written out to make sure reviewers of the CR are aware of them. +.. note:: + If there are security concerns in relation to the CR, those concerns should be explicitly written out to make sure reviewers of the CR are aware of them. Which security requirements are affected or has to be changed? Could the new/modified component enable new threat scenarios? @@ -96,9 +94,9 @@ Could the new/modified component enable new attack paths? Could the new/modified component impact functional safety? If applicable, which additional security measures must be implemented to mitigate the risk? - .. note:: - Use Security Software Critically Analysis, Vulnerability Analysis. - [Methods will be defined later in Process area Security Analysis] +.. note:: + Use Security Software Critically Analysis, Vulnerability Analysis. + [Methods will be defined later in Process area Security Analysis] Safety Impact @@ -106,24 +104,24 @@ Safety Impact [How could the safety be impacted by the new/modified component?] - .. note:: - If there are safety concerns in relation to the CR, those concerns should be explicitly written out to make sure reviewers of the CR are aware of them. +.. note:: + If there are safety concerns in relation to the CR, those concerns should be explicitly written out to make sure reviewers of the CR are aware of them. Which safety requirements are affected or has to be changed? Could the new/modified component be a potential common cause or cascading failure initiator? If applicable, which additional safety measures must be implemented to mitigate the risk? - .. note:: - Use Dependency Failure Analysis and/or Safety Software Critically Analysis. - [Methods will be defined later in Process area Safety Analysis] +.. note:: + Use Dependency Failure Analysis and/or Safety Software Critically Analysis. + [Methods will be defined later in Process area Safety Analysis] For new feature/component contributions: [What is the expected ASIL level?] [What is the expected classification of the contribution?] - .. note:: - Use the component classification method here to classify your component, if it shall to be used in a safety context: :need:`gd_temp__component_classification`. +.. note:: + Use the component classification method here to classify your component, if it shall to be used in a safety context: :need:`gd_temp__component_classification`. License Impact ============== @@ -136,21 +134,19 @@ How to Teach This [How to teach users, new and experienced, how to apply the CR to their work.] - .. note:: - For a CR that adds new functionality or changes behavior, it is helpful to include a section on how to teach users, new and experienced, how to apply the CR to their work. - - +.. note:: + For a CR that adds new functionality or changes behavior, it is helpful to include a section on how to teach users, new and experienced, how to apply the CR to their work. Rejected Ideas ============== [Why certain ideas that were brought while discussing this CR were not ultimately pursued.] - .. note:: - Throughout the discussion of a CR, various ideas will be proposed which are not accepted. - Those rejected ideas should be recorded along with the reasoning as to why they were rejected. - This both helps record the thought process behind the final version of the CR as well as preventing people from bringing up the same rejected idea again in subsequent discussions. - In a way this section can be thought of as a breakout section of the Rationale section that is focused specifically on why certain ideas were not ultimately pursued. +.. note:: + Throughout the discussion of a CR, various ideas will be proposed which are not accepted. + Those rejected ideas should be recorded along with the reasoning as to why they were rejected. + This both helps record the thought process behind the final version of the CR as well as preventing people from bringing up the same rejected idea again in subsequent discussions. + In a way this section can be thought of as a breakout section of the Rationale section that is focused specifically on why certain ideas were not ultimately pursued. @@ -159,10 +155,10 @@ Open Issues [Any points that are still being decided/discussed.] - .. note:: - While a CR is in draft, ideas can come up which warrant further discussion. - Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. - This helps make sure all issues required for the CR to be ready for consideration are complete and reduces people duplicating prior discussion. +.. note:: + While a CR is in draft, ideas can come up which warrant further discussion. + Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. + This helps make sure all issues required for the CR to be ready for consideration are complete and reduces people duplicating prior discussion. diff --git a/process/folder_templates/modules/module_name/component_name/docs/requirements/chklst_req_inspection.rst b/process/folder_templates/modules/module_name/component_name/docs/requirements/chklst_req_inspection.rst index ee8168c18e..46311c9adb 100644 --- a/process/folder_templates/modules/module_name/component_name/docs/requirements/chklst_req_inspection.rst +++ b/process/folder_templates/modules/module_name/component_name/docs/requirements/chklst_req_inspection.rst @@ -47,6 +47,8 @@ Requirement Inspection Checklist **Checklist** + See also :ref:`review_concept` for further information about reviews in general and inspection in particular. + .. list-table:: Component Requirement Inspection Checklist :header-rows: 1 :widths: 10,30,50,6,6,8 diff --git a/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_analysis_fdr.rst b/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_analysis_fdr.rst index 8ecac1f367..a09f50c384 100644 --- a/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_analysis_fdr.rst +++ b/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_analysis_fdr.rst @@ -38,6 +38,8 @@ The purpose of this Safety Analysis (DFA and FMEA) checklist template is to coll **Checklist** +Please note that it is mandatory to fill in the "passed" column with "yes" or "no" for each checklist item and additional to add in the remarks why it is passed or not passed. In case of "no" an issue link to the issue tracking system has to be added in the last column. See also :ref:`review_concept` for further information about reviews in general and inspection in particular. + .. list-table:: Safety Analysis Checklist :header-rows: 1 :widths: 10,30,30,15,8,8 diff --git a/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_package_fdr.rst b/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_package_fdr.rst index 1b193d074a..9542dbd3b6 100644 --- a/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_package_fdr.rst +++ b/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_package_fdr.rst @@ -40,6 +40,8 @@ The purpose of this review checklist is to report status of the formal review fo **2. Checklist** +See also :ref:`review_concept` for further information about reviews in general and inspection in particular. + .. list-table:: Safety Package Checklist :header-rows: 1 diff --git a/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_plan_fdr.rst b/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_plan_fdr.rst index 5f07cbc94e..bf86f409fa 100644 --- a/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_plan_fdr.rst +++ b/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_plan_fdr.rst @@ -39,6 +39,8 @@ The purpose of this safety plan formal review checklist is to report status of t **2. Checklist** +See also :ref:`review_concept` for further information about reviews in general and inspection in particular. + .. list-table:: Safety Plan Checklist :header-rows: 1 diff --git a/process/folder_templates/platform/requirements/stakeholder/chklst_req_inspection.rst b/process/folder_templates/platform/requirements/stakeholder/chklst_req_inspection.rst index ea98a802a3..462ac3f226 100644 --- a/process/folder_templates/platform/requirements/stakeholder/chklst_req_inspection.rst +++ b/process/folder_templates/platform/requirements/stakeholder/chklst_req_inspection.rst @@ -47,6 +47,8 @@ Stakeholder Requirement Inspection Checklist **Checklist** + See also :ref:`review_concept` for further information about reviews in general and inspection in particular. + .. list-table:: Stakeholder Requirement Inspection Checklist :header-rows: 1 :widths: 10,30,50,6,6,8 diff --git a/process/folder_templates/platform/safety_planning/platform_safety_analysis_fdr.rst b/process/folder_templates/platform/safety_planning/platform_safety_analysis_fdr.rst index 12b4aec91a..e970585690 100644 --- a/process/folder_templates/platform/safety_planning/platform_safety_analysis_fdr.rst +++ b/process/folder_templates/platform/safety_planning/platform_safety_analysis_fdr.rst @@ -38,6 +38,8 @@ The purpose of this Safety Analysis (DFA and FMEA) checklist template is to coll **Checklist** +Please note that it is mandatory to fill in the "passed" column with "yes" or "no" for each checklist item and additional to add in the remarks why it is passed or not passed. In case of "no" an issue link to the issue tracking system has to be added in the last column. See also :ref:`review_concept` for further information about reviews in general and inspection in particular. + .. list-table:: Safety Analysis Checklist :header-rows: 1 :widths: 10,30,30,15,8,8 diff --git a/process/process_areas/architecture_design/_assets/component_architecture_dynamic.puml b/process/process_areas/architecture_design/_assets/component_architecture_dynamic.puml index 0075b0bdf8..1af4705ec1 100644 --- a/process/process_areas/architecture_design/_assets/component_architecture_dynamic.puml +++ b/process/process_areas/architecture_design/_assets/component_architecture_dynamic.puml @@ -29,8 +29,8 @@ @startuml participant "Feature User" as actor -participant "«component» :Lower Level Component 1" as sc1 -participant "«component» :Lower Level Component 3" as sc3 +participant "«component» :Component 1_1" as sc1 +participant "«component» :Component 1_3" as sc3 actor -> sc1: real operation 3 () sc1 -> sc3: real operation 9 () diff --git a/process/process_areas/architecture_design/architecture_concept.rst b/process/process_areas/architecture_design/architecture_concept.rst index d18de894da..bd693653d7 100644 --- a/process/process_areas/architecture_design/architecture_concept.rst +++ b/process/process_areas/architecture_design/architecture_concept.rst @@ -204,7 +204,7 @@ The component architecture contain the following views: Static View ----------- -The *component architecture* describes the implementation of the functionalities in a white-box view. It describes the structural decomposition of the *SW components* into *lower level* SW components. It provides a more detailed information concerning the respective interfaces of a component. If a SW component interacts with a different component it is also included via a *use* relationship in the diagram. An example of the *component architecture* is displayed here: +The *component architecture* describes the implementation of the functionalities in a white-box view. It describes the internal structure of SW components and their decomposition. It provides a more detailed information concerning the respective interfaces of a component. If a SW component interacts with a different component it is also included via a *use* relationship in the diagram. An example of the *component architecture* is displayed here: .. comp_arc_sta:: Component 1 Static View :id: comp_arc_sta__example_feature__archdes_component_concept_1 @@ -220,18 +220,18 @@ The *component architecture* describes the implementation of the functionalities {{ 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. +The decomposition is optional and relies 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 lower level 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 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? +* important use cases: how do the internal components execute them? +* interactions at critical interfaces: how do internal components cooperate with users and neighboring internal components? * operation and administration: launch, start-up, stop * successful use cases * error and exception use cases @@ -487,8 +487,8 @@ The following section is an example, how an `Feature Date: Fri, 16 Jan 2026 07:49:35 +0100 Subject: [PATCH 2/3] fix dynamic picture --- .../_assets/component_architecture_dynamic.puml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/process/process_areas/architecture_design/_assets/component_architecture_dynamic.puml b/process/process_areas/architecture_design/_assets/component_architecture_dynamic.puml index 1af4705ec1..9ccad13da8 100644 --- a/process/process_areas/architecture_design/_assets/component_architecture_dynamic.puml +++ b/process/process_areas/architecture_design/_assets/component_architecture_dynamic.puml @@ -30,10 +30,10 @@ participant "Feature User" as actor participant "«component» :Component 1_1" as sc1 -participant "«component» :Component 1_3" as sc3 +participant "«component» :Component 1_2" as sc3 actor -> sc1: real operation 3 () -sc1 -> sc3: real operation 9 () +sc1 -> sc3: real operation 4 () alt success sc3 --> sc1: success From 2e07ea799d2da35eb73c2e07b8b9176eb495dca1 Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Fri, 16 Jan 2026 07:50:21 +0100 Subject: [PATCH 3/3] change operation --- .../_assets/component_architecture_dynamic.puml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/process_areas/architecture_design/_assets/component_architecture_dynamic.puml b/process/process_areas/architecture_design/_assets/component_architecture_dynamic.puml index 9ccad13da8..0c6f322918 100644 --- a/process/process_areas/architecture_design/_assets/component_architecture_dynamic.puml +++ b/process/process_areas/architecture_design/_assets/component_architecture_dynamic.puml @@ -32,7 +32,7 @@ participant "Feature User" as actor participant "«component» :Component 1_1" as sc1 participant "«component» :Component 1_2" as sc3 -actor -> sc1: real operation 3 () +actor -> sc1: real operation 2 () sc1 -> sc3: real operation 4 () alt success