diff --git a/docs/features/analysis-infra/logging/docs/glossary.rst b/docs/features/analysis-infra/logging/docs/glossary.rst index 90647d8db52..dc146bc4127 100644 --- a/docs/features/analysis-infra/logging/docs/glossary.rst +++ b/docs/features/analysis-infra/logging/docs/glossary.rst @@ -26,10 +26,10 @@ Glossary Framework is a structured and extensible foundation for developing specific types of functionality in this case, logging. It supplies a set of default behaviors and configurable options, allowing developers to tailor and extend its capabilities to meet their application and system need. platform - Platform is the execution environment on which S-Core runs. It includes, for example, hardware (HW), operating system (OS), ... + Platform is the execution environment on which S-CORE runs. It includes, for example, hardware (HW), operating system (OS), ... component - Component is a S-Core component + Component is a S-CORE component log level Log Level is the severity of a log message, necessary to categorize logs based on their importance e.g., FATAL, ERROR, WARN, INFO, DEBUG, VERBOSE such as in DLT diff --git a/docs/features/index.rst b/docs/features/index.rst index 086c37767e9..08fe4d199f0 100644 --- a/docs/features/index.rst +++ b/docs/features/index.rst @@ -17,6 +17,10 @@ Features ======== +A **Feature** is the highest-level logical entity, representing a set of interrelated components in respect of the S-CORE software platform. It is the primary unit of the management of these components and contains the belonging feature requirements and feature architecture for them. For further explanation see the `Building blocks concept `_. + +The following features are defined: + .. toctree:: :maxdepth: 1 :glob: diff --git a/docs/features/lifecycle/architecture/launch_manager.rst b/docs/features/lifecycle/architecture/launch_manager.rst index 670c6e8f3b9..4c29c258d78 100644 --- a/docs/features/lifecycle/architecture/launch_manager.rst +++ b/docs/features/lifecycle/architecture/launch_manager.rst @@ -21,7 +21,7 @@ monitoring, and controlling processes based on defined configurations and requirements. As such, it is a central part of the lifecycle management in S-CORE and knows about the state of all processes in the system. -It's foreseen ECU projects will need a custom state management to fulfill ECU-project specific requirements. The S-Core stack will offer a framework to control application lifecycle, but will not specify the State Manager. +It's foreseen ECU projects will need a custom state management to fulfill ECU-project specific requirements. The S-CORE stack will offer a framework to control application lifecycle, but will not specify the State Manager. Overview ======== diff --git a/docs/modules/index.rst b/docs/modules/index.rst index 5b67d461d77..9949b019c7d 100644 --- a/docs/modules/index.rst +++ b/docs/modules/index.rst @@ -17,6 +17,9 @@ Modules ======= +A **Module** is a major architectural building block which is defined as a component or a set of components realizing a :ref:`feature ` of the platform. +It is the physically compiled and packaged unit that results from the build process and is made available for delivery. For further explanation see the `Building blocks concept `_. + .. image:: _assets/module_architecture.drawio.svg :alt: Module Architecture @@ -25,8 +28,6 @@ Modules For now, we store the modules documentation in the modules tree, because multi-repo docs are not yet supported. Once this support becomes available it will be moved to the right repo. - - .. toctree:: :maxdepth: 1 :glob: diff --git a/docs/platform_management_plan/project_management.rst b/docs/platform_management_plan/project_management.rst index ef5c0c3fa63..5dc40f091ca 100644 --- a/docs/platform_management_plan/project_management.rst +++ b/docs/platform_management_plan/project_management.rst @@ -130,13 +130,13 @@ Its current *DoD list* is always documented in the template. The most important Every *Feature Team* should have its own discussion section in the `Feature Teams section `_ of the main *S-CORE* project. -* **Adding a new Team to the main S-Core GitHub project** +* **Adding a new Team to the main S-CORE GitHub project** Every *Feature Team* should be added as a further select option of the "Team" field - in the `main S-Core project `_, so that *Technical Leads* + in the `main S-CORE project `_, so that *Technical Leads* can assign tickets to the team and filter for the tickets of the new team. Additionally, every team is free to create its own GitHub project, but then the team tickets should be still - visible in the main S-Core project. + visible in the main S-CORE project. * **Creation of repository** diff --git a/docs/platform_management_plan/software_verification.rst b/docs/platform_management_plan/software_verification.rst index 062d2ba6b76..ca7fbf69a5b 100644 --- a/docs/platform_management_plan/software_verification.rst +++ b/docs/platform_management_plan/software_verification.rst @@ -126,10 +126,10 @@ There are the following different levels of integration and verification defined **Note:** These three levels translate to the levels of ISO 26262 part 6 clauses 9 to 11. The platform - testing will be executed by the integrator. S-Core project only executes tests on reference hardware. + testing will be executed by the integrator. S-CORE project only executes tests on reference hardware. These tests serve as an optional base for the integrator and will also be part of the :need:`wp__verification_platform_ver_report`, but more on an informative character. The full scope - of clause 11 is tailored out accordingly for S-Core. Practically, this means S-CORE will implement + of clause 11 is tailored out accordingly for S-CORE. Practically, this means S-CORE will implement Platform Integration Test of stakeholder requirements for demonstration, but these are not intended to completely covering all stakeholder requirements. diff --git a/docs/requirements/index.rst b/docs/requirements/index.rst index 9e48d6c3f60..0bf6aee5b54 100644 --- a/docs/requirements/index.rst +++ b/docs/requirements/index.rst @@ -17,6 +17,10 @@ Requirements ============ +Requirements are the formal descriptions of the requested capabilities or characteristics that the software platform or its components must fulfill. For further information see the `requirement concept `_ in the process description. + +The following stakeholder functional and non-functional requirements and platform assumptions describe this for S-CORE. + .. toctree:: stakeholder/index diff --git a/docs/score_releases/index.rst b/docs/score_releases/index.rst index 511b0e3fcac..035bba0399a 100644 --- a/docs/score_releases/index.rst +++ b/docs/score_releases/index.rst @@ -14,6 +14,13 @@ .. _releases: +S-CORE Releases +=============== + +A **Release** is a officially distributed, versioned, and deployable collection of Project artifacts intended for distribution beyond the Project Developers. It brings together the initial set of core modules, reference integrations, and supporting infrastructure needed to build. For further information about the platform releases and module releases see `release documentation `_ in the process description. + +See also the project life cycle within the `Eclipse Development Process `_. + S-CORE Releases Overview ========================