same spelling

Author: RolandJentschETAS

process/general_concepts/score_building_blocks_concept.rst

@@ -52,7 +52,7 @@ may mitigated by updating the Component Requirements or by the **Component Assum
 as well as the Integration of multiple Units to a Component.
 
 As mentioned above a Software Module is defined as a Component or a set of components realizing a
-Feature of the platform. Features consists of Components and are defined by **Feature Requirements**
+Feature of the platform. Features consists of components and are defined by **Feature Requirements**
 (yellow box, middle, 3rd column) and the **Feature Architecture** (yellow box, middle, 4th column).
 A **Feature Safety Analysis** (yellow box, middle, 6th column) is required to verify the Feature
 Architecture, whereby violations of safety requirements must be documented. Potential

process/general_concepts/score_traceability_concept.rst

@@ -59,7 +59,7 @@ of use. For convenience also the traceability to upper and lower lever requireme
 The next figures sets the focus on the component level and adds the traceability from the
 Component Requirements to the Component Architecture, Component Safety Analysis
 and the Component Assumption of use. Further the traceability to Component Assumptions of use
-from external Components is included.
+from external components is included.
 
 
 .. figure:: _assets/score_traceability_model_cmp_overview_1.drawio.svg

process/process_areas/architecture_design/architecture_concept.rst

@@ -213,7 +213,7 @@ The second viewpoint is named as *component architecture* and describes the impl
       {{ 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.
-In all views the Components which are marked as ASIL_B related are drawn in red color.
+In all views the components which are marked as ASIL_B related are drawn in red color.
 
 Dynamic View
 ------------

process/process_areas/change_management/change_management_concept.rst

@@ -26,12 +26,12 @@ including the requirements of the different stakeholders for the Change Manageme
 
 Key concept
 ***********
-A Change Request is the **ONLY** way to contribute new features or to modify the scope
+A *Change Request* is the **ONLY** way to contribute new features or to modify the scope
 of existing features in the project.
-As features are built-up by Components a Change Request is also needed to add new
-Components or to modify the scope of existing Components.
-As a Software Module is defined as the top-level Component, all statements here for
-Components are also valid for Software Modules.
+As features are built-up by components a Change Request is also needed to add new
+components or to modify the scope of existing components.
+As a *Software Module* is defined as the top-level component, all statements here for
+components are also valid for Software Modules.
 
 Inputs
 ******

process/process_areas/change_management/change_management_workproducts.rst

@@ -60,7 +60,7 @@ Work Products Change Management
    |
    | Change Request for a new component or a modification of an existing component,
    | which changes the scope of the component.
-   | Software Modules are also Components (top-level component).
+   | Software Modules are also components (top-level component).
 
 .. needextend:: docname is not None and "process_areas/change_management" in docname
    :+tags: change_management

process/process_areas/safety_analysis/safety_analysis_concept.rst

@@ -110,7 +110,7 @@ The analysis were applied at static and dynamic architecture diagrams. The follo
    Feature Architecture
 
 With the diagrams the dependencies and signal flows are shown. The analysis is done by applying the fault models :need:`gd_guidl__fault_models` in the above example's dynamic view the "flow component 1" to the user realizes a safety requirement. If we apply the fault model we may find the possible failure: "the message is not sent which leads to the user not being able to ..." - this could be mitigated by telling the user in an AoU: "the feature can not guarantee that the message is sent"
-DFA: Here we see in the static view that component 1 uses component 2. If we apply the failure initiators we may find the possible failure: "Component 2 is using up all execution time available to Component 1" which could be avoided by a OS which is reserving time for every component or by running these Components on different processors.
+DFA: Here we see in the static view that component 1 uses component 2. If we apply the failure initiators we may find the possible failure: "Component 2 is using up all execution time available to Component 1" which could be avoided by a OS which is reserving time for every component or by running these components on different processors.
 for FMEA and the failure initiators :need:`gd_guidl__dfa_failure_initiators` for DFA. Some fault models and failure initiators may not be applicable
 for one safety function. In this case the reason shall be documented in the FMEA/DFA documents. So it can be shown that the analysis is completely done.