Fix several spellings

process/folder_templates/platform/features/feature_name/requirements/req_inspection.rst

@@ -45,7 +45,7 @@ Participants
    * moderator: <committer explicitly named here, who is is the safety manager, security manager or quality manager initiating the inspection>
 
 
-.. list-table:: [Feature Name] Requirements Inspection Particpants
+.. list-table:: [Feature Name] Requirements Inspection Participants
     :header-rows: 1
 
     * - Author(s)

process/general_concepts/score_review_concept.rst

@@ -123,7 +123,7 @@ After all requested reviewers are done, the author answers the findings and/or p
 4. Inspection approval
 
 The reviewer(s) re-review and adapt their verdict accordingly (to "Approve").
-In case the author or the reviewer(s) cannot agree on a solution, the safety/security/quality manger
+In case the author or the reviewer(s) cannot agree on a solution, the safety/security/quality manager
 who initiated the inspection will be asked to moderate this.
 After all the required reviewers approved including the CODEOWNER of the work product, the PR is merged.
 
@@ -159,7 +159,7 @@ Inspection Know-How
 ^^^^^^^^^^^^^^^^^^^
 
 For work products with ASIL rating the safety manager shall initiate the inspections,
-for those which are QM but are security related the security manger may request this,
+for those which are QM but are security related the security manager may request this,
 but also the quality manager may ask for inspection for critical QM work products.
 
 Judging if the maturity of a work product is already enough to request an inspection

process/process_areas/architecture_design/architecture_concept.rst

@@ -383,7 +383,7 @@ If an element/view is linked to a "parent" also the version of the parent shall
 
 As this check is included in the docs build as a warning it can be guaranteed that a change of a parent can only be merged if the derived child are also updated accordingly.
 
-All links to and from architecture elements/views as depicted in :ref:`Building Blocks Overwiew <general_concepts_building_blocks>` shall use versioing.
+All links to and from architecture elements/views as depicted in :ref:`Building Blocks Overview <general_concepts_building_blocks>` shall use versioning.
 
 .. _reviews of the architecture:
 

process/process_areas/configuration_management/guidance/configuration_templates.rst

@@ -139,7 +139,7 @@ Branches are used as a means of parallel development. In the <project name> proj
 The "remote" branch is not "local" to the developer but resides on the "remote" version management server.
 
 In <project name> project all configuration items are kept in the version management tool, this means that there only needs to be one baseline for these
-(and not multiple ones for each of the work products which are maintained in seperate tools).
+(and not multiple ones for each of the work products which are maintained in separate tools).
 <Describe how baselines are created by using the version management tool.>
 See also <link to doc__platform_release_management_plan>.
 
@@ -160,7 +160,7 @@ Status and Reporting
 
 This should cover :need:`std_req__aspice_40__SUP-8-BP6` and :need:`std_req__aspice_40__SUP-8-BP7`
 
-Every work product defined in our proceses has a "status" attribute. These are used to communicate to all the stakeholders.
+Every work product defined in our processes has a "status" attribute. These are used to communicate to all the stakeholders.
 The main communication means is a document list containing all documents and workproducts including their status.
 This list is typically part of the Documentation Management Plan <link doc__documentation_mgt_plan> as part of the Platform Management Plan,
 as defined in :need:`gd_guidl__documentation`.

process/process_areas/implementation/implementation_getstrt.rst

@@ -44,7 +44,7 @@ Relevant Documents
 
 Concept Document: :need:`doc_concept__imp_concept` provides a high-level overview of the integration concept.
 
-Implementation Guideline: :need:`gd_guidl__implementation` Details on the implemenation.
+Implementation Guideline: :need:`gd_guidl__implementation` Details on the implementation.
 
 SW Development Plan: :need:`gd_temp__software_development_plan` Process description of SW development including
 

process/process_areas/platform_management/guidance/platform_management_guideline.rst

@@ -96,21 +96,21 @@ The stakeholders/stakeholder groups and organisation are defined. These may incl
 * Information needs of each stakeholder (group)
 * Required competences, skills, knowledge
 
-Communication and reporting pathes are described. These may include:
+Communication and reporting paths are described. These may include:
 
 * E-mails
 * Collaboration tools, like Slack, Teams, etc.
 * Meetings and Meeting Notes
 * Blog
 * Webpages
 
-Escalation pathes are described. These may include:
+Escalation paths are described. These may include:
 
 * Defined mechanisms to report and confirm escalation relevant issues
 * Identifies stakeholders to be included in the escalation path
 * Identifies levels of escalation
 
-Training pathes are described. These may include:
+Training paths are described. These may include:
 
 * Tutorials
 * Training materials

process/process_areas/quality_management/quality_concept.rst

@@ -74,7 +74,7 @@ General Quality Concept
 The Quality Concept is based on the requirements of the standards and were derived into the Quality Performance
 Objectives that are listed in the Quality Management Plan. The Quality shall be continuous
 checked and improved during the development. All tasks are planned within the Quality Management Plan. These
-includes tasks like platform process audit or feature contribution conformance checks which have to be planed to milestones
+includes tasks like platform process audit or feature contribution conformance checks which have to be planned to milestones
 or in a continuous manner. Only 100% compliant work products / releases will be formally delivered to the community.
 
 Every person who contributes shall be trained according to Quality aspects. The committers will help to ensure the Quality

process/process_areas/requirements_engineering/requirements_concept.rst

@@ -181,7 +181,7 @@ Following attributes need to be filled manually for each requirement:
    * - Description
      - In this attribute the content for the requirement will be specified. Please be aware that a note in a requirement is not part of the requirement itself. This means that notes should only be used to give additional explanation or context to the requirement.
    * - Version
-     - Version of the requirement adapted with each significat change, see :ref:`significant_requirement_changes`.
+     - Version of the requirement adapted with each significant change, see :ref:`significant_requirement_changes`.
    * - Rationale / Linkage
      - In either of those attributes the reasoning for the requirement is included.
        For *Stakeholder Requirements* a rationale which provides some more background infos shall be provided.

process/process_areas/safety_management/safety_management_concept.rst

@@ -98,7 +98,7 @@ Apart from the safety plans the main work products of Safety Management are:
 * :need:`Safety Manual <wp__platform_safety_manual>` - defines the requirements for safe usage or integration of the SW platform (or its individual modules)
 * :need:`Formal Document Review Reports <wp__fdr_reports>` - on safety plan, safety package and safety analyses, according to ISO 26262 requirements
 * :need:`Safety Package <wp__platform_safety_package>` - contains the released work products planned in the safety plan, it does not contain the safety argumentation. By this the project ensures it does not take over liability for the SW platform (or its individual modules). But it enables the user to integrate the SW platform (or its individual modules) in their safety case.
-* :need:`SW Component Classification <wp__sw_component_class>` - used for pre-existing software components, to determine their usability for safety funtionalities and the activities needed for its qualification in context of the SW platform. Is used as an input for the planning of SW component qualification documented in :need:`Module Safety Plan <wp__module_safety_plan>`.
+* :need:`SW Component Classification <wp__sw_component_class>` - used for pre-existing software components, to determine their usability for safety functionalities and the activities needed for its qualification in context of the SW platform. Is used as an input for the planning of SW component qualification documented in :need:`Module Safety Plan <wp__module_safety_plan>`.
 
 Safety Management Tooling
 ^^^^^^^^^^^^^^^^^^^^^^^^^

process/process_areas/safety_management/safety_management_workproducts.rst

@@ -130,7 +130,7 @@ Safety Management Work Products
 
    * The Assumed Platform Requirements (Safety related);
    * the safety concept of the SEooC (i.e. which faults are taken care of);
-   * the Assumptions of Use (of the modules's components and of the associated feature);
+   * the Assumptions of Use (of the module's components and of the associated feature);
    * a link to the platform safety manual (containing the general AoUs every user has to obey additionally);
    * a link to the (module) user manual;
    * the reactions of the implemented functions under anomalous operating conditions; and

process/process_areas/security_analysis/guidance/security_analysis_guideline.rst

@@ -157,7 +157,7 @@ The security analysis shall be used to analyze whether the security goals of a f
 Examples for Security Analysis at component level
 =================================================
 
-The security analysis shall be used to analyze whether the vulnerabilities within the component can be exploited. This could be unintended privilege escalation between two sub-components, allowing unauthorized access to senstive data or security-critical functions.
+The security analysis shall be used to analyze whether the vulnerabilities within the component can be exploited. This could be unintended privilege escalation between two sub-components, allowing unauthorized access to sensitive data or security-critical functions.
 
 .. needextend:: "c.this_doc()"
    :+tags: security_analysis

process/process_areas/security_management/security_management_concept.rst

@@ -30,7 +30,7 @@ Key concept
 ***********
 The Security Management Plan establishes a comprehensive strategy for managing all identified security activities throughout the entire project life cycle.
 It ensures that these activities are executed in a systematic, effective, and repeatable manner, providing clear guidance on responsibilities, processes, and control measures.
-This approach supports risk mitigation, regulatory compliance, and continuous improvement, enabling the project team to maintain secrity standards consistently from initiation to completion.
+This approach supports risk mitigation, regulatory compliance, and continuous improvement, enabling the project team to maintain security standards consistently from initiation to completion.
 
 Inputs
 ******

process/process_areas/security_management/security_management_roles.rst

@@ -74,12 +74,12 @@ Roles
 
    Required skills, Knowledge of security standards (ISO 21434), Experience
 
-   * External Auditor comes from organization specialized in secrity audits and assessment, thus sufficient skill should be guaranteed by the sending organization.
+   * External Auditor comes from organization specialized in security audits and assessment, thus sufficient skill should be guaranteed by the sending organization.
    * For performing the formal document reviews also a Security Manager from another Eclipse Safety project can play the role of an external auditor, in this case the same skills apply as for the Security Manager.
 
    Responsibility
 
-   * Performing and reporting of secrity audit
+   * Performing and reporting of security audit
 
    Authority
 

process/process_areas/security_management/security_management_workproducts.rst

@@ -132,7 +132,7 @@ Security Management Work Products
 
    * the assumed platform requirements (security related, including for post-development);
    * the security concept of the OoC (i.e. which attack paths are taken care of);
-   * the assumptions of use (of the modules's components);
+   * the assumptions of use (of the module's components);
    * a link to the user manual;
    * the reactions of the implemented functions under threatened operating conditions; and
    * a description of known vulnerabilities with corresponding workaround measures.

process/standards/process_reqs_list/index.rst

@@ -20,7 +20,7 @@ Process Requirements List
 Automation Status via Process Requirement Table
 ***********************************************
 
-All process requirements should be labelled with the priorization of automation implementation:
+All process requirements should be labelled with the prioritization of automation implementation:
 
 - A label "manual" means nothing to do, because it must be fulfilled manually (e.g. by filling attributes). It can be added a prio (to denote that this req is a must for v0.5 add "prio_1")
 - A label "done_automation" means nothing to do, because it already works. Note that in docs-as-code repository there are tool requirements linking to the process requirements with an "Implemented" attribute.