diff --git a/docs/_assets/contribution_guide.svg b/docs/_assets/contribution_guide.svg
index 1f1a3d52da6..9481e43f06c 100644
--- a/docs/_assets/contribution_guide.svg
+++ b/docs/_assets/contribution_guide.svg
@@ -1,4 +1,4 @@
-
\ No newline at end of file
+
diff --git a/docs/contribute/contribution_request/index.rst b/docs/contribute/contribution_request/index.rst
index 74d5af97646..1a7e73145d5 100644
--- a/docs/contribute/contribution_request/index.rst
+++ b/docs/contribute/contribution_request/index.rst
@@ -112,7 +112,7 @@ The figure below shows a simplified workflow for a PR.
Content in general may contain features, requirements, architectural designs, modules, components, detailed designs, implementations and source code, tests, process descriptions, any documentations, guidelines, tutorials, tools, or infrastructure topics and more of the *S-CORE* project. In case of doubt or for any other input we strongly encourage to open a *GitHub Issue* (:need:`doc__issue_guideline`) first.
-The *PR* should provide all required information of the new or changed content. Therefore the *S-CORE* project provides content specific templates, which the contributor (:need:`Contributor `) must use for his *PR* (ToDo link here to the templates overview). Templates may be *PR* templates, *GitHub Issue* templates and also additional document or work product templates.
+The *PR* should provide all required information of the new or changed content. Therefore the *S-CORE* project provides content specific templates, which the contributor (:need:`Contributor `) must use for their *PR* (ToDo link here to the templates overview). Templates may be *PR* templates, *GitHub Issue* templates and also additional document or work product templates.
The content of any *PR* is the commit content and the description as well as the comments given in GitHub and is kept in a versioned repository, their revision history is the historical record of the PR.
diff --git a/docs/features/baselibs/docs/requirements/chklst_req_inspection.rst b/docs/features/baselibs/docs/requirements/chklst_req_inspection.rst
index 20a05105c63..31e26909857 100644
--- a/docs/features/baselibs/docs/requirements/chklst_req_inspection.rst
+++ b/docs/features/baselibs/docs/requirements/chklst_req_inspection.rst
@@ -129,7 +129,7 @@ Requirement Inspection Checklist
-
* - REQ_08_01
- Is the requirement *verifiable*?
- - If at the time of the inspection already tests are created for the requirement, the answer is yes. This can be checked via traces, but also :need:`gd_req__req_attr_test_covered` shows this. In case the requirement is not sufficiently traced to test cases already, a test expert is invited to the inspection to give his opinion whether the requirement is formulated in a way that supports test development and the available test infrastructure is sufficient to perform the test.
+ - If at the time of the inspection already tests are created for the requirement, the answer is yes. This can be checked via traces, but also :need:`gd_req__req_attr_test_covered` shows this. In case the requirement is not sufficiently traced to test cases already, a test expert is invited to the inspection to give their opinion whether the requirement is formulated in a way that supports test development and the available test infrastructure is sufficient to perform the test.
-
-
-
diff --git a/docs/features/communication/ipc/docs/architecture/index.rst b/docs/features/communication/ipc/docs/architecture/index.rst
index 8b75ae5647e..5be0442c214 100644
--- a/docs/features/communication/ipc/docs/architecture/index.rst
+++ b/docs/features/communication/ipc/docs/architecture/index.rst
@@ -144,7 +144,7 @@ Synchronization Algorithm
A slot shall contain all necessary meta-information in order to synchronize data access. This information most certainly needs to include a timestamp to indicate the order of produced data within the slots. Additionally, a use count is needed, indicating if a slot is currently in use by one process. The concrete data is implementation defined and must be covered by the detailed design.
-The main idea of the algorithm is that a producer shall always be able to store one new data sample. If he cannot find a respective slot, this indicates a contract violation, which indicates that a QM process misbehaved. In such a case, a producer should exclude any QM consumer from the communication.
+The main idea of the algorithm is that a producer shall always be able to store one new data sample. If it cannot find a respective slot, this indicates a contract violation, which indicates that a QM process misbehaved. In such a case, a producer should exclude any QM consumer from the communication.
This whole idea builds up on the split of shared memory segments by ASIL levels. This way we can ensure that an QM process will not degrade the ASIL Level for a communication path. In another case, where we already have a QM producer, it is possible for an ASIL B consumer to consume the QM data. In this scenario, there is no separate control data for ASIL B, and they instead interact on the control data for ASIL QM. This is because, the data is QM and it is impossible for the middleware to apply additional checks to enhance the quality of data. This can only be done on application layer level. Hence, separating QM and ASIL consumers holds no benefit.
@@ -200,7 +200,7 @@ Each consumer and the producer owns a corresponding transaction log, which resid
#. Executing the activity in question.
#. Writing a transaction end marker, which annotates, whether the activity in (2) was done or not.
-During the restart of a communication partner, he checks for existing transaction logs in shared memory, which it
+During the restart of a communication partner, it checks for existing transaction logs in shared memory, which it
created in an earlier run, so that it can roll them back.
Two scenarios are possible:
@@ -208,7 +208,7 @@ Two scenarios are possible:
- All transaction log entries are complete (transaction end marker is written).
The communication partner can roll all transactions back and rejoin communication.
- A transaction log entry is incomplete (transaction end marker is missing).
- The communication partner is incapable of rolling back his actions fully.
+ The communication partner is incapable of rolling back its actions fully.
Rejoining the communication would impact other communication partners.
The communication partner is barred from rejoining the communication.
diff --git a/docs/modules/baselibs/result/docs/requirements/chklst_req_inspection.rst b/docs/modules/baselibs/result/docs/requirements/chklst_req_inspection.rst
index 533e473c082..b0d0b224e50 100644
--- a/docs/modules/baselibs/result/docs/requirements/chklst_req_inspection.rst
+++ b/docs/modules/baselibs/result/docs/requirements/chklst_req_inspection.rst
@@ -128,7 +128,7 @@ Requirement Inspection Checklist
- none
* - REQ_08_01
- Is the requirement *verifiable*?
- - If at the time of the inspection already tests are created for the requirement, the answer is yes. This can be checked via traces, but also :need:`gd_req__req_attr_test_covered` shows this. In case the requirement is not sufficiently traced to test cases already, a test expert is invited to the inspection to give his opinion whether the requirement is formulated in a way that supports test development and the available test infrastructure is sufficient to perform the test.
+ - If at the time of the inspection already tests are created for the requirement, the answer is yes. This can be checked via traces, but also :need:`gd_req__req_attr_test_covered` shows this. In case the requirement is not sufficiently traced to test cases already, a test expert is invited to the inspection to give their opinion whether the requirement is formulated in a way that supports test development and the available test infrastructure is sufficient to perform the test.
- YES
- all requirements have test cases implemented
- none
diff --git a/docs/modules/orchestrator/executor/docs/requirements/chklst_req_inspection.rst b/docs/modules/orchestrator/executor/docs/requirements/chklst_req_inspection.rst
index 6431194ff78..51c23f6a8ef 100644
--- a/docs/modules/orchestrator/executor/docs/requirements/chklst_req_inspection.rst
+++ b/docs/modules/orchestrator/executor/docs/requirements/chklst_req_inspection.rst
@@ -130,7 +130,7 @@ Requirement Inspection Checklist
-
* - REQ_08_01
- Is the requirement *verifiable*?
- - If at the time of the inspection already tests are created for the requirement, the answer is yes. This can be checked via traces, but also :need:`gd_req__req_attr_test_covered` shows this. In case the requirement is not sufficiently traced to test cases already, a test expert is invited to the inspection to give his opinion whether the requirement is formulated in a way that supports test development and the available test infrastructure is sufficient to perform the test.
+ - If at the time of the inspection already tests are created for the requirement, the answer is yes. This can be checked via traces, but also :need:`gd_req__req_attr_test_covered` shows this. In case the requirement is not sufficiently traced to test cases already, a test expert is invited to the inspection to give their opinion whether the requirement is formulated in a way that supports test development and the available test infrastructure is sufficient to perform the test.
-
-
-
diff --git a/docs/modules/orchestrator/orchestrator/docs/requirements/chklst_req_inspection.rst b/docs/modules/orchestrator/orchestrator/docs/requirements/chklst_req_inspection.rst
index d6f8cbd3818..ae92b376b13 100644
--- a/docs/modules/orchestrator/orchestrator/docs/requirements/chklst_req_inspection.rst
+++ b/docs/modules/orchestrator/orchestrator/docs/requirements/chklst_req_inspection.rst
@@ -130,7 +130,7 @@ Requirement Inspection Checklist
-
* - REQ_08_01
- Is the requirement *verifiable*?
- - If at the time of the inspection already tests are created for the requirement, the answer is yes. This can be checked via traces, but also :need:`gd_req__req_attr_test_covered` shows this. In case the requirement is not sufficiently traced to test cases already, a test expert is invited to the inspection to give his opinion whether the requirement is formulated in a way that supports test development and the available test infrastructure is sufficient to perform the test.
+ - If at the time of the inspection already tests are created for the requirement, the answer is yes. This can be checked via traces, but also :need:`gd_req__req_attr_test_covered` shows this. In case the requirement is not sufficiently traced to test cases already, a test expert is invited to the inspection to give their opinion whether the requirement is formulated in a way that supports test development and the available test infrastructure is sufficient to perform the test.
-
-
-
diff --git a/docs/requirements/platform_assumptions/index.rst b/docs/requirements/platform_assumptions/index.rst
index c526629d441..67606d19323 100644
--- a/docs/requirements/platform_assumptions/index.rst
+++ b/docs/requirements/platform_assumptions/index.rst
@@ -33,7 +33,7 @@ the operating system, programming language libraries, hypervisor or processing h
For "organizations" two roles are used in the AoU text:
- Supplier: is the provider of an element the S-CORE SW-platform is using but which is developed and maintained externally.
-- System Integrator: uses the S-CORE SW-platform as a part of a system he provides to a customer. The system integrator can be for example a Tier1 providing an electronic control unit to a OEM or an OEM providing a car to his end-customer. S-CORE does not know which.
+- System Integrator: uses the S-CORE SW-platform as a part of a system they provide to a customer. The system integrator can be for example a Tier1 providing an electronic control unit to a OEM or an OEM providing a car to their end-customer. S-CORE does not know which.
To fulfill these assumptions is the responsibility of the mentioned roles.
@@ -113,7 +113,7 @@ It is the level where the S-CORE SW-platform will functionally "work" with the e
:safety: QM
:status: valid
- The system integrator shall run the tests provided by S-CORE (platform, feature, component and Unit level for his selected S-CORE modules) on his selected OS/Hypervisor/HW combination,
+ The system integrator shall run the tests provided by S-CORE (platform, feature, component and Unit level for their selected S-CORE modules) on their selected OS/Hypervisor/HW combination,
or provide equivalent argumentation.
Note1: S-CORE will run these tests for one or more reference OS/Hypervisor/HW combination, if not all passing, remaining issues are documented in release notes. In case the selected combination is equal to a S-CORE reference and the complete S-CORE SW-platform is used, this AoU may be skipped.
@@ -127,7 +127,7 @@ It is the level where the S-CORE SW-platform will functionally "work" with the e
:safety: QM
:status: valid
- The system integrator shall report the bugs found during integration of the S-CORE SW-platform on his selected OS/Hypervisor/HW combination to the external SW element supplier and S-CORE for analysis.
+ The system integrator shall report the bugs found during integration of the S-CORE SW-platform on their selected OS/Hypervisor/HW combination to the external SW element supplier and S-CORE for analysis.
Assumptions on the external SW element integration - Certifiable Level
----------------------------------------------------------------------
@@ -214,7 +214,7 @@ This is the highest level of integraton. This is the level where the S-CORE SW-p
:safety: ASIL_B
:status: valid
- If the system using the SW-platform has safety goals, the system integrator shall perform safety anomaly reporting taking into account also the reporting of all the components he integrates.
+ If the system using the SW-platform has safety goals, the system integrator shall perform safety anomaly reporting taking into account also the reporting of all the components they integrate.
Note: This includes all the modules of the S-CORE SW platform used by the system integrator.
The relevant safety critical bugs or safety anomalies are published by S-CORE as defined in the :need:`doc__platform_problem_resolution_plan`.