From 0e7ded5b0bab43452e0b19dc7ba0e52cd5044fdc Mon Sep 17 00:00:00 2001 From: pandaedo Date: Mon, 2 Feb 2026 12:32:30 +0100 Subject: [PATCH 1/6] fix typos --- .vscode/settings.json | 11 ++++++++++- .../features/feature_name/safety_planning/index.rst | 2 +- .../guidance/architecture_guideline.rst | 4 ++-- .../guidance/architecture_modeling_example.rst | 4 ++-- .../guidance/problem_resolution_reqs.rst | 2 +- .../problem_resolution_workflow.rst | 4 ++-- .../safety_management/safety_management_concept.rst | 4 ++-- 7 files changed, 20 insertions(+), 11 deletions(-) diff --git a/.vscode/settings.json b/.vscode/settings.json index a3c7371a85..dca4be6a4a 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -32,5 +32,14 @@ "python.testing.unittestEnabled": false, "python.testing.pytestEnabled": true, "bazel.lsp.command": "bazel", - "bazel.lsp.args": ["run", "//:starpls_server"] + "bazel.lsp.args": [ + "run", + "//:starpls_server" + ], + "cSpell.words": [ + "docname", + "needarch", + "toctree", + "workproduct" + ] } diff --git a/process/folder_templates/features/feature_name/safety_planning/index.rst b/process/folder_templates/features/feature_name/safety_planning/index.rst index c815a87537..50b6df2985 100644 --- a/process/folder_templates/features/feature_name/safety_planning/index.rst +++ b/process/folder_templates/features/feature_name/safety_planning/index.rst @@ -102,7 +102,7 @@ Safety Work products List .. attention:: The above table must be updated according to your feature safety planning. - - Fill the work producs links + - Fill the work products links Feature Safety Package ====================== diff --git a/process/process_areas/architecture_design/guidance/architecture_guideline.rst b/process/process_areas/architecture_design/guidance/architecture_guideline.rst index 44da5a86c2..f2ccdfc9f3 100644 --- a/process/process_areas/architecture_design/guidance/architecture_guideline.rst +++ b/process/process_areas/architecture_design/guidance/architecture_guideline.rst @@ -226,8 +226,8 @@ for the static architecture a UML component diagram is expected (and supported b Dynamic architecture -------------------- The :need:`doc_concept__arch_process` shows the usage of UML sequence diagrams to describe dynamic -behaviour. This is also the expected default diagram. Alternatively, state machine diagrams can be used -to describe stateful behaviour. Other types like the activity diagram are not encouraged to use, +behavior. This is also the expected default diagram. Alternatively, state machine diagrams can be used +to describe stateful behavior. Other types like the activity diagram are not encouraged to use, if an activity diagram is used instead of a sequence diagram, this has to be argued as part of the architecture description. diff --git a/process/process_areas/architecture_design/guidance/architecture_modeling_example.rst b/process/process_areas/architecture_design/guidance/architecture_modeling_example.rst index 4cdb4cd5a4..76fac543e8 100644 --- a/process/process_areas/architecture_design/guidance/architecture_modeling_example.rst +++ b/process/process_areas/architecture_design/guidance/architecture_modeling_example.rst @@ -185,7 +185,7 @@ Module Viewpoint {{ draw_module(need(), needs) }} -Component Architecure File(s) +Component Architecture File(s) ============================= .. comp:: Component 1 @@ -254,7 +254,7 @@ Component Architecure File(s) :safety: ASIL_B :security: NO -Requierements for the Example +Requirements for the Example ============================= .. Requirements diff --git a/process/process_areas/problem_resolution/guidance/problem_resolution_reqs.rst b/process/process_areas/problem_resolution/guidance/problem_resolution_reqs.rst index 2e6c54eb32..a770206e02 100644 --- a/process/process_areas/problem_resolution/guidance/problem_resolution_reqs.rst +++ b/process/process_areas/problem_resolution/guidance/problem_resolution_reqs.rst @@ -70,7 +70,7 @@ Problem Attributes problem. .. gd_req:: Problem attribute: analysis results - :id: gd_req__problem_attr_anaylsis_results + :id: gd_req__problem_attr_analysis_results :status: valid :tags: manual_prio_1, problem_resolution, attribute, mandatory :satisfies: wf__problem_create_pr, wf__problem_analyze_pr, wf__problem_initiate_monitor_pr, wf__problem_close_pr diff --git a/process/process_areas/problem_resolution/problem_resolution_workflow.rst b/process/process_areas/problem_resolution/problem_resolution_workflow.rst index c3ea2fdc1f..9d6eda8c8f 100644 --- a/process/process_areas/problem_resolution/problem_resolution_workflow.rst +++ b/process/process_areas/problem_resolution/problem_resolution_workflow.rst @@ -70,11 +70,11 @@ For a detailed explanation of workflows and their role within the process model, The Problem Resolution is implemented and monitored. - This may require Change Requests or other activities, inlcuding creating ISSUEs and PRs. + This may require Change Requests or other activities, including creating ISSUEs and PRs. These are linked to the Problem and monitored until closure. The Problem Resolution is done, if all linked activities has been closed and confirmed. - Before closing the Problem Resoultion, :need:`Committer ` must check the + Before closing the Problem Resolution, :need:`Committer ` must check the correctness. The :need:`Committer ` may still reject it, thus the status is set to "rejected". diff --git a/process/process_areas/safety_management/safety_management_concept.rst b/process/process_areas/safety_management/safety_management_concept.rst index 6de327cf19..87c76e0d97 100644 --- a/process/process_areas/safety_management/safety_management_concept.rst +++ b/process/process_areas/safety_management/safety_management_concept.rst @@ -43,11 +43,11 @@ Stakeholders * Main responsible to ensure ISO 26262 compliance in the project * Create/Maintain Safety Plan - * Perform Formal Reviews (for safety work products not in his resposibility area) + * Perform Formal Reviews (for safety work products not in his responsibility area) * Approve Component Classification * Approve Safety Package * Approve Safety Audit - * Approve Formal Reviews (for safety work products in his resposibility area) + * Approve Formal Reviews (for safety work products in his responsibility area) * Approve Safety Manual * Monitor/Verify Safety * Impact Analysis of Change Request From 43470449143d4ec6afc933418c98e6bcd04ba17b Mon Sep 17 00:00:00 2001 From: pandaedo Date: Mon, 2 Feb 2026 12:39:07 +0100 Subject: [PATCH 2/6] fix underline --- .../guidance/architecture_modeling_example.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/process_areas/architecture_design/guidance/architecture_modeling_example.rst b/process/process_areas/architecture_design/guidance/architecture_modeling_example.rst index 76fac543e8..d66574cb70 100644 --- a/process/process_areas/architecture_design/guidance/architecture_modeling_example.rst +++ b/process/process_areas/architecture_design/guidance/architecture_modeling_example.rst @@ -186,7 +186,7 @@ Module Viewpoint {{ draw_module(need(), needs) }} Component Architecture File(s) -============================= +============================== .. comp:: Component 1 :id: comp__component_example_1 From 5a0676b71e5a8ee6ae2036ec7c39a1248b91f52c Mon Sep 17 00:00:00 2001 From: pandaedo Date: Wed, 11 Feb 2026 12:33:56 +0100 Subject: [PATCH 3/6] fix typo --- process/standards/iso26262/iso26262.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/standards/iso26262/iso26262.rst b/process/standards/iso26262/iso26262.rst index 6e5a4293bf..6ca57c7288 100644 --- a/process/standards/iso26262/iso26262.rst +++ b/process/standards/iso26262/iso26262.rst @@ -1351,7 +1351,7 @@ Part 8: Supporting processes :status: valid - .. std_wp:: support_8522 + .. std_wp:: support_852 :id: std_wp__iso26262__support_852 :status: valid From 7ff61fd0a29d039bdb409d42fb87cc4b46d4ba35 Mon Sep 17 00:00:00 2001 From: pandaedo Date: Wed, 11 Feb 2026 12:41:00 +0100 Subject: [PATCH 4/6] change ae to be --- .../architecture/chklst_arc_inspection.rst | 2 +- .../folder_templates/features/feature_name/index.rst | 2 +- .../docs/architecture/chklst_arc_inspection.rst | 2 +- .../modules/module_name/component_name/docs/index.rst | 2 +- .../architecture_design/architecture_concept.rst | 6 +++--- .../guidance/architecture_guideline.rst | 4 ++-- .../implementation/implementation_concept.rst | 7 +++---- .../requirements_engineering/requirements_concept.rst | 4 ++-- .../safety_analysis/safety_analysis_concept.rst | 2 +- .../verification/guidance/verification_methods.rst | 10 +++++----- .../verification/verification_concept.rst | 4 ++-- process/standards/aspice_40/aspice.rst | 2 +- process/standards/aspice_40/iic/iic-04.rst | 2 +- process/standards/aspice_40/iic/iic-17.rst | 6 +++--- process/standards/aspice_40/swe/swe.2.rst | 8 ++++---- process/standards/aspice_40/swe/swe.3.rst | 6 +++--- process/standards/aspice_40/swe/swe.5.rst | 8 ++++---- 17 files changed, 38 insertions(+), 39 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 28a7b6b9ca..5dcb72506a 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 @@ -105,7 +105,7 @@ Please note that it is mandatory to fill in the "passed" column with "yes" or "n * - ARC_02_04 - Are the interfaces between the software architectural element and other architectural elements well defined? - manual - - Check if the interface handles undefined behavior or errors; can established protocols be used; are the interfaces for inputs, outputs, and error codes documented; is loose coupling considered and only limited exposure; can unit or integration tests be written against the interface; data amount transferred; ensure no sensitive data is exposed; + - Check if the interface handles undefined behaviour or errors; can established protocols be used; are the interfaces for inputs, outputs, and error codes documented; is loose coupling considered and only limited exposure; can unit or integration tests be written against the interface; data amount transferred; ensure no sensitive data is exposed; - - - diff --git a/process/folder_templates/features/feature_name/index.rst b/process/folder_templates/features/feature_name/index.rst index 35e3f88d62..4171a1d9d1 100644 --- a/process/folder_templates/features/feature_name/index.rst +++ b/process/folder_templates/features/feature_name/index.rst @@ -149,7 +149,7 @@ 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. + For a CR that adds new functionality or changes behaviour, it is helpful to include a section on how to teach users, new and experienced, how to apply the CR to their work. 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 653a976fc0..a72c28f84d 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 @@ -107,7 +107,7 @@ Please note that it is mandatory to fill in the "passed" column with "yes" or "n * - ARC_02_04 - Are the interfaces between the software architectural element and other architectural elements well-defined? - manual - - Check if the interface reacts on non-defined behavior or errors; can established protocols be used; are the + - Check if the interface reacts on non-defined behaviour or errors; can established protocols be used; are the interfaces for inputs, outputs, error codes documented; is loose coupling considered and only limited exposure; can unit or integration test be written against the interface; data amount transferred; no sensitive data exposure; 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 6316594fd7..0128aefb13 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 @@ -135,7 +135,7 @@ 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. + For a CR that adds new functionality or changes behaviour, 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 ============== diff --git a/process/process_areas/architecture_design/architecture_concept.rst b/process/process_areas/architecture_design/architecture_concept.rst index c0bac46111..3ecfc456d5 100644 --- a/process/process_areas/architecture_design/architecture_concept.rst +++ b/process/process_areas/architecture_design/architecture_concept.rst @@ -147,7 +147,7 @@ See :ref:`uml_diagram_selection` in guideline for further information about the Dynamic View ------------ -This view shows the *dynamic behavior* of the feature including the interaction of its components with the user. Following scenarios should be included: +This view shows the *dynamic behaviour* of the feature including the interaction of its components 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? @@ -309,9 +309,9 @@ To represent the CI build tool module (for example a `Bazel Modules //! //! This implements the .... - diff --git a/process/process_areas/requirements_engineering/requirements_concept.rst b/process/process_areas/requirements_engineering/requirements_concept.rst index 261ae4a7f8..3242dcbe20 100644 --- a/process/process_areas/requirements_engineering/requirements_concept.rst +++ b/process/process_areas/requirements_engineering/requirements_concept.rst @@ -113,7 +113,7 @@ i.e. the assumption on what content is needed, which shall be matched by the use Feature Requirements ==================== -The *Feature Requirements* derived from stakeholder requirements address mainly the integration level of SW modules and components. These shall describe the behavior of the feature on platform level shall be described including the correlations of the integrated components. They serves mainly as an input for (SW + Safety) Architects, Testers, Integrators and are derived from the *Stakeholder Requirements*. To provide an example +The *Feature Requirements* derived from stakeholder requirements address mainly the integration level of SW modules and components. These shall describe the behaviour of the feature on platform level shall be described including the correlations of the integrated components. They serves mainly as an input for (SW + Safety) Architects, Testers, Integrators and are derived from the *Stakeholder Requirements*. To provide an example .. code-block:: text @@ -124,7 +124,7 @@ However the detailed interaction of the underlying components itself which is re Component Requirements ====================== -The lowest abstraction level is represented by the *component requirements*. They are derived from *feature requirements* and describe component specific implementation details. It is described which behavior a component itself needs to fulfil in the context of the feature, e.g. +The lowest abstraction level is represented by the *component requirements*. They are derived from *feature requirements* and describe component specific implementation details. It is described which behaviour a component itself needs to fulfil in the context of the feature, e.g. .. code-block:: text diff --git a/process/process_areas/safety_analysis/safety_analysis_concept.rst b/process/process_areas/safety_analysis/safety_analysis_concept.rst index e94281bb59..a200bc741c 100644 --- a/process/process_areas/safety_analysis/safety_analysis_concept.rst +++ b/process/process_areas/safety_analysis/safety_analysis_concept.rst @@ -144,7 +144,7 @@ The Safety Analysis (DFA and FMEA) shall consider the architectural elements on 1. **Platform Level**: At this level, the focus is on the overall feature architecture to analyse if there are failures that effects more than one feature. - | **Example DFA:** Dependencies between features shall be analysed. This could be the usage of modules by different features, shared libraries or shared services. A common cause failure could be a erroneous signal that effects the behavior of several functions. + | **Example DFA:** Dependencies between features shall be analysed. This could be the usage of modules by different features, shared libraries or shared services. A common cause failure could be a erroneous signal that effects the behaviour of several functions. 2. **Feature Level**: This level involves a more detailed analysis of individual components within the feature. The analysis shall consider the internal structure of components and their interactions with other components in the feature. diff --git a/process/process_areas/verification/guidance/verification_methods.rst b/process/process_areas/verification/guidance/verification_methods.rst index 6779cd4b51..44cd5aee71 100644 --- a/process/process_areas/verification/guidance/verification_methods.rst +++ b/process/process_areas/verification/guidance/verification_methods.rst @@ -261,7 +261,7 @@ The following perspectives are included in ``equivalence-classes``: - **Improve Test Coverage** By testing at least one value from each partition, you ensure that you've covered all the - different behaviors of the software. + different behaviours of the software. - **Address Different Input Types** EP is applicable to various input types, including numerical ranges, enumerated values, @@ -298,7 +298,7 @@ How to perform the analysis: Classes that contain invalid input values (out of range, incorrect data type, etc.). - **Special Cases** - Classes representing specific or unusual input values that might trigger special behavior + Classes representing specific or unusual input values that might trigger special behaviour in the software. **3. Define Test Values** @@ -324,7 +324,7 @@ Fuzzy Testing Fuzzy Testing, often called Fuzz Testing, is a software testing technique that involves providing invalid, unexpected, or random data as inputs to a component or system to detect defects. The goal of fuzzy testing is to expose unhandled exceptions, memory leaks, assertion failures, and other -critical issues by generating semi-random inputs and observing the system's behavior. +critical issues by generating semi-random inputs and observing the system's behaviour. The following perspectives are included in ``fuzz-testing``: @@ -359,8 +359,8 @@ How to perform fuzzy testing: **3. Generate Fuzzy Inputs** Create inputs that are slightly malformed or unexpected, either through complete randomization or by mutating valid inputs. - **4. Monitor System Behavior** Execute the system with fuzzy inputs and monitor for crashes, - hangs, memory leaks, or other unexpected behaviors. + **4. Monitor System behaviour** Execute the system with fuzzy inputs and monitor for crashes, + hangs, memory leaks, or other unexpected behaviours. **5. Analyze and Fix Issues** When a problem is detected, analyze the input that caused it and fix the underlying issue in the code. diff --git a/process/process_areas/verification/verification_concept.rst b/process/process_areas/verification/verification_concept.rst index 541f13321c..1643dc639a 100644 --- a/process/process_areas/verification/verification_concept.rst +++ b/process/process_areas/verification/verification_concept.rst @@ -160,10 +160,10 @@ tests or component tests. This linking is done using metatags. This is also true integration tests linking to the component requirements and architecture. Traceability of feature integration tests shall be established through linking those test cases to -feature requirements and architecture as features describe the integrated behavior of all components. +feature requirements and architecture as features describe the integrated behaviour of all components. Traceability of platform integration tests shall be established through linking those test cases to -stakeholder requirements as stakeholder requirements describe the platform behavior. +stakeholder requirements as stakeholder requirements describe the platform behaviour. Note that all the above tests shall only link to requirements of type "Functional" and "Interface". The verification of requirements of types "Process" and "Non-Functional" will be done via Analysis, diff --git a/process/standards/aspice_40/aspice.rst b/process/standards/aspice_40/aspice.rst index 8caa666d6b..7a9329927b 100644 --- a/process/standards/aspice_40/aspice.rst +++ b/process/standards/aspice_40/aspice.rst @@ -369,7 +369,7 @@ Process attribute achievements 2. Assignment of persons necessary for performing the defined process to roles is performed and communicated. 3. Required education, training and experience is ensured and monitored for the person(s) assigned to the roles. 4. Required resources for performing the defined process are made available, allocated, and maintained. -5. Appropriate information is collected and analyzed as a basis for understanding the behavior of the process. +5. Appropriate information is collected and analyzed as a basis for understanding the behaviour of the process. Generic practices diff --git a/process/standards/aspice_40/iic/iic-04.rst b/process/standards/aspice_40/iic/iic-04.rst index 6abc315387..e4d035194f 100644 --- a/process/standards/aspice_40/iic/iic-04.rst +++ b/process/standards/aspice_40/iic/iic-04.rst @@ -28,7 +28,7 @@ Software Architecture may have the following characteristics: - A justifying rationale for the chosen architecture. - - Individual functional and non-functional behavior of the software + - Individual functional and non-functional behaviour of the software component - Settings for application parameters (being a technical implementation solution for configurability-oriented requirements) diff --git a/process/standards/aspice_40/iic/iic-17.rst b/process/standards/aspice_40/iic/iic-17.rst index 42411be9d6..b33acc3ddc 100644 --- a/process/standards/aspice_40/iic/iic-17.rst +++ b/process/standards/aspice_40/iic/iic-17.rst @@ -49,7 +49,7 @@ - lifetime and mission profile, lifetime robustness - maximum price - storage and transportation requirements - - functional behavior of analog or digital circuits and logic + - functional behaviour of analog or digital circuits and logic - quiescent current, voltage impulse responsiveness to crank, startstop, drop-out, load dump - temperature, maximum hardware heat dissipation - power consumption depending on the operating state such as @@ -114,5 +114,5 @@ Needs are derived from Work Breakdown structure and schedule -.. needextend:: "c.this_doc()" - :+tags: aspice40_iic17 +.. needextend:: "c.this_doc()" + :+tags: aspice40_iic17 diff --git a/process/standards/aspice_40/swe/swe.2.rst b/process/standards/aspice_40/swe/swe.2.rst index 1e2283417c..3744cdc8e3 100644 --- a/process/standards/aspice_40/swe/swe.2.rst +++ b/process/standards/aspice_40/swe/swe.2.rst @@ -58,7 +58,7 @@ Base practices Specify and document the dynamic aspects of the software architecture with respect to the functional and non- - functional software requirements, including the behavior of the software components and their + functional software requirements, including the behaviour of the software components and their interaction in different software modes, and concurrency aspects. .. note:: @@ -68,7 +68,7 @@ Base practices .. note:: - Examples for behavioral descriptions are natural language or semi-formal notation (e.g, + Examples for behavioural descriptions are natural language or semi-formal notation (e.g, SysML, UML). @@ -137,5 +137,5 @@ Base practices architecture to all affected parties. -.. needextend:: "c.this_doc()" - :+tags: aspice40_swe2 +.. needextend:: "c.this_doc()" + :+tags: aspice40_swe2 diff --git a/process/standards/aspice_40/swe/swe.3.rst b/process/standards/aspice_40/swe/swe.3.rst index 5fdbb8f799..be571fd00f 100644 --- a/process/standards/aspice_40/swe/swe.3.rst +++ b/process/standards/aspice_40/swe/swe.3.rst @@ -46,7 +46,7 @@ Base practices :links: std_req__aspice_40__iic-04-05;std_req__aspice_40__iic-11-05 For each software component - specify the behavior of its software units, their static structure and relationships, their interfaces + specify the behaviour of its software units, their static structure and relationships, their interfaces including - valid data value ranges for inputs and outputs (from the application domain perspective), @@ -90,11 +90,11 @@ Base practices Specify and document the dynamic aspects of the detailed design with respect to the software architecture, including the - interactions between relevant software units to fulfill the component’s dynamic behavior. + interactions between relevant software units to fulfill the component’s dynamic behaviour. .. note:: - Examples for behavioral descriptions are natural language or semi-formal notation (e.g, + Examples for behavioural descriptions are natural language or semi-formal notation (e.g, SysML, UML). diff --git a/process/standards/aspice_40/swe/swe.5.rst b/process/standards/aspice_40/swe/swe.5.rst index 361bf8f0de..888fb503d5 100644 --- a/process/standards/aspice_40/swe/swe.5.rst +++ b/process/standards/aspice_40/swe/swe.5.rst @@ -30,7 +30,7 @@ Process outcomes of, and interactions between, the software components. 2. Verification measures for software components are specified to provide evidence for compliance of the software components with the - software components’ behavior and interfaces. + software components’ behaviour and interfaces. 3. Software elements are integrated up to a complete integrated software. 4. Verification measures are selected according to the release scope @@ -79,13 +79,13 @@ Base practices interfaces or simulation environments (e.g, Software-in-the-Loop-Simulation). -.. std_req:: SWE.5.BP2: Specify verification measures for verifying software component behavior +.. std_req:: SWE.5.BP2: Specify verification measures for verifying software component behaviour :id: std_req__aspice_40__SWE-5-BP2 :status: valid :links: std_req__aspice_40__iic-08-60 Specify verification measures for software component verification against the defined software - components’ behavior and their interfaces in the software architecture, including + components’ behaviour and their interfaces in the software architecture, including - techniques for the verification measures, - entry and exit criteria for verification measures, - pass/fail criteria for verification measures, and @@ -149,7 +149,7 @@ Base practices :links: std_req__aspice_40__iic-03-50;std_req__aspice_40__iic-15-52 Perform the selected verification - measures for verifying software component behavior. Record the verification results including + measures for verifying software component behaviour. Record the verification results including pass/fail status and corresponding verification measure data. .. note:: From a699ebeaee41a6719cbd8165cff55d8afd7070b6 Mon Sep 17 00:00:00 2001 From: pandaedo Date: Wed, 11 Feb 2026 14:23:32 +0100 Subject: [PATCH 5/6] rechange typo in original documents --- process/standards/aspice_40/iic/iic-04.rst | 2 +- process/standards/aspice_40/iic/iic-17.rst | 2 +- process/standards/aspice_40/swe/swe.2.rst | 4 ++-- process/standards/aspice_40/swe/swe.3.rst | 6 +++--- process/standards/aspice_40/swe/swe.5.rst | 8 ++++---- 5 files changed, 11 insertions(+), 11 deletions(-) diff --git a/process/standards/aspice_40/iic/iic-04.rst b/process/standards/aspice_40/iic/iic-04.rst index e4d035194f..6abc315387 100644 --- a/process/standards/aspice_40/iic/iic-04.rst +++ b/process/standards/aspice_40/iic/iic-04.rst @@ -28,7 +28,7 @@ Software Architecture may have the following characteristics: - A justifying rationale for the chosen architecture. - - Individual functional and non-functional behaviour of the software + - Individual functional and non-functional behavior of the software component - Settings for application parameters (being a technical implementation solution for configurability-oriented requirements) diff --git a/process/standards/aspice_40/iic/iic-17.rst b/process/standards/aspice_40/iic/iic-17.rst index b33acc3ddc..41a3505615 100644 --- a/process/standards/aspice_40/iic/iic-17.rst +++ b/process/standards/aspice_40/iic/iic-17.rst @@ -49,7 +49,7 @@ - lifetime and mission profile, lifetime robustness - maximum price - storage and transportation requirements - - functional behaviour of analog or digital circuits and logic + - functional behavior of analog or digital circuits and logic - quiescent current, voltage impulse responsiveness to crank, startstop, drop-out, load dump - temperature, maximum hardware heat dissipation - power consumption depending on the operating state such as diff --git a/process/standards/aspice_40/swe/swe.2.rst b/process/standards/aspice_40/swe/swe.2.rst index 3744cdc8e3..c70b19a3c0 100644 --- a/process/standards/aspice_40/swe/swe.2.rst +++ b/process/standards/aspice_40/swe/swe.2.rst @@ -58,7 +58,7 @@ Base practices Specify and document the dynamic aspects of the software architecture with respect to the functional and non- - functional software requirements, including the behaviour of the software components and their + functional software requirements, including the behavior of the software components and their interaction in different software modes, and concurrency aspects. .. note:: @@ -68,7 +68,7 @@ Base practices .. note:: - Examples for behavioural descriptions are natural language or semi-formal notation (e.g, + Examples for behavioral descriptions are natural language or semi-formal notation (e.g, SysML, UML). diff --git a/process/standards/aspice_40/swe/swe.3.rst b/process/standards/aspice_40/swe/swe.3.rst index be571fd00f..5fdbb8f799 100644 --- a/process/standards/aspice_40/swe/swe.3.rst +++ b/process/standards/aspice_40/swe/swe.3.rst @@ -46,7 +46,7 @@ Base practices :links: std_req__aspice_40__iic-04-05;std_req__aspice_40__iic-11-05 For each software component - specify the behaviour of its software units, their static structure and relationships, their interfaces + specify the behavior of its software units, their static structure and relationships, their interfaces including - valid data value ranges for inputs and outputs (from the application domain perspective), @@ -90,11 +90,11 @@ Base practices Specify and document the dynamic aspects of the detailed design with respect to the software architecture, including the - interactions between relevant software units to fulfill the component’s dynamic behaviour. + interactions between relevant software units to fulfill the component’s dynamic behavior. .. note:: - Examples for behavioural descriptions are natural language or semi-formal notation (e.g, + Examples for behavioral descriptions are natural language or semi-formal notation (e.g, SysML, UML). diff --git a/process/standards/aspice_40/swe/swe.5.rst b/process/standards/aspice_40/swe/swe.5.rst index 888fb503d5..361bf8f0de 100644 --- a/process/standards/aspice_40/swe/swe.5.rst +++ b/process/standards/aspice_40/swe/swe.5.rst @@ -30,7 +30,7 @@ Process outcomes of, and interactions between, the software components. 2. Verification measures for software components are specified to provide evidence for compliance of the software components with the - software components’ behaviour and interfaces. + software components’ behavior and interfaces. 3. Software elements are integrated up to a complete integrated software. 4. Verification measures are selected according to the release scope @@ -79,13 +79,13 @@ Base practices interfaces or simulation environments (e.g, Software-in-the-Loop-Simulation). -.. std_req:: SWE.5.BP2: Specify verification measures for verifying software component behaviour +.. std_req:: SWE.5.BP2: Specify verification measures for verifying software component behavior :id: std_req__aspice_40__SWE-5-BP2 :status: valid :links: std_req__aspice_40__iic-08-60 Specify verification measures for software component verification against the defined software - components’ behaviour and their interfaces in the software architecture, including + components’ behavior and their interfaces in the software architecture, including - techniques for the verification measures, - entry and exit criteria for verification measures, - pass/fail criteria for verification measures, and @@ -149,7 +149,7 @@ Base practices :links: std_req__aspice_40__iic-03-50;std_req__aspice_40__iic-15-52 Perform the selected verification - measures for verifying software component behaviour. Record the verification results including + measures for verifying software component behavior. Record the verification results including pass/fail status and corresponding verification measure data. .. note:: From a3585db1484f2d686d5c5d4cd495c2d3ce23bb43 Mon Sep 17 00:00:00 2001 From: pandaedo Date: Wed, 11 Feb 2026 15:09:08 +0100 Subject: [PATCH 6/6] rechange typo correction --- process/standards/aspice_40/aspice.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/standards/aspice_40/aspice.rst b/process/standards/aspice_40/aspice.rst index 7a9329927b..8caa666d6b 100644 --- a/process/standards/aspice_40/aspice.rst +++ b/process/standards/aspice_40/aspice.rst @@ -369,7 +369,7 @@ Process attribute achievements 2. Assignment of persons necessary for performing the defined process to roles is performed and communicated. 3. Required education, training and experience is ensured and monitored for the person(s) assigned to the roles. 4. Required resources for performing the defined process are made available, allocated, and maintained. -5. Appropriate information is collected and analyzed as a basis for understanding the behaviour of the process. +5. Appropriate information is collected and analyzed as a basis for understanding the behavior of the process. Generic practices