eclipse-score · arkjedrz · Nov 20, 2025
diff --git a/docs/index.rst b/docs/index.rst
@@ -12,25 +12,22 @@
    # SPDX-License-Identifier: Apache-2.0
    # *******************************************************************************
 
-Base Libraries - Rust
-=============================
+Rust Base Libraries
+===================
 
-This documentation describes the Rust base libraries.
+.. toctree::
+   :maxdepth: 1
+   :glob:
+   :titlesonly:
 
-.. contents:: Table of Contents
-   :depth: 2
-   :local:
+   module_docs/index
+   module/*/index
 
 Overview
 --------
 
 Foundational Rust libraries providing common functionality for S-CORE modules.
 
-Requirements
-------------
-
-- TODO: add requirements once available.
-
 Project Layout
 --------------
 

diff --git a/docs/module/log/architecture/index.rst b/docs/module/log/architecture/index.rst
@@ -0,0 +1,97 @@
+..
+   # *******************************************************************************
+   # Copyright (c) 2025 Contributors to the Eclipse Foundation
+   #
+   # See the NOTICE file(s) distributed with this work for additional
+   # information regarding copyright ownership.
+   #
+   # This program and the accompanying materials are made available under the
+   # terms of the Apache License Version 2.0 which is available at
+   # https://www.apache.org/licenses/LICENSE-2.0
+   #
+   # SPDX-License-Identifier: Apache-2.0
+   # *******************************************************************************
+
+.. _component_architecture_log:
+
+Component Architecture
+======================
+
+.. document:: Log Architecture
+   :id: doc__log_architecture
+   :status: draft
+   :safety: QM
+   :security: NO
+   :realizes: wp__component_arch
+   :tags: log
+
+
+Overview
+--------
+
+Document describes Log component architecture.
+
+
+Description
+-----------
+
+TODO: description
+
+
+Rationale Behind Architecture Decomposition
+*******************************************
+
+TODO: decomposition rationale
+
+Static Architecture
+-------------------
+
+TODO: static architecture
+
+.. .. comp_arc_sta:: Log (Static View)
+..    :id: comp_arc_sta__log__static_view
+..    :security: YES
+..    :safety: QM
+..    :status: invalid
+..    :implements: logic_arc_int__log__interface_name
+..    :fulfils:
+..    :includes:
+
+..    .. uml:: _assets/TODO.puml
+
+
+Dynamic Architecture
+--------------------
+
+TODO: dynamic architecture
+
+.. .. comp_arc_dyn:: Dynamic View
+..    :id: comp_arc_dyn__log__dynamic_view
+..    :security: YES
+..    :safety: QM
+..    :status: invalid
+..    :fulfils: comp_req__log__some_title
+
+.. .. uml:: _assets/TODO.puml
+
+
+Interfaces
+----------
+
+TODO: put log interfaces.
+
+.. .. code-block:: rst
+
+..    .. real_arc_int:: mw_log
+..       :id: real_arc_int__log__interface
+..       :security: NO
+..       :safety: QM
+..       :fulfils:
+..       :language: rust
+
+..    .. uml:: _assets/TODO.puml
+
+Lower Level Components
+----------------------
+
+TODO: remove section if unused
diff --git a/docs/module/log/component_classification.rst b/docs/module/log/component_classification.rst
@@ -0,0 +1,188 @@
+..
+   # *******************************************************************************
+   # Copyright (c) 2025 Contributors to the Eclipse Foundation
+   #
+   # See the NOTICE file(s) distributed with this work for additional
+   # information regarding copyright ownership.
+   #
+   # This program and the accompanying materials are made available under the
+   # terms of the Apache License Version 2.0 which is available at
+   # https://www.apache.org/licenses/LICENSE-2.0
+   #
+   # SPDX-License-Identifier: Apache-2.0
+   # *******************************************************************************
+
+Component Classification
+========================
+
+
+.. document:: Log Component Classification
+   :id: doc__log_comp_class
+   :status: draft
+   :safety: QM
+   :security: NO
+   :realizes: wp__sw_component_class
+   :tags: log
+
+
+| Classification of <component>
+|
+| <Link to OSS component source (e.g. in github) including the selected version>
+|
+| Additional documentation considered:
+| <list of documentation links>
+
+
+Step 1: Determine (P): the uncertainty of the Processes applied
+---------------------------------------------------------------
+
+| Apply the process measures to determine (P).
+| The result of a process measure shall have as outcome [HE, PE, NE]
+| - HE: High Evidence
+| - PE: Partly Evidence but Manageable
+| - NE: No Evidence
+
+.. list-table:: Determine (P)
+        :header-rows: 1
+
+        * - Id
+          - Indicator for applying process
+          - Result
+          - Rationale for result
+
+        * - 1
+          - Are rules, state-of-the art processes applied for the design, implementation and verification?
+          - <HE|PE|NE>
+          - <Rationale for result>
+
+        * - 2
+          - Are requirements available?
+          - <HE|PE|NE>
+          - <Rationale for result>
+
+        * - 3
+          - Are specifications for functionalities and properties available (architecture)?
+          - <HE|PE|NE>
+          - <Rationale for result>
+
+        * - 4
+          - Are design specifications available?
+          - <HE|PE|NE>
+          - <Rationale for result>
+
+        * - 5
+          - Are configuration specification and data available, if applicable?
+          - <HE|PE|NE>
+          - <Rationale for result>
+
+        * - 6
+          - Are verification measures including tests and reports available?
+          - <HE|PE|NE>
+          - <Rationale for result>
+
+
+| (P=1) shall be selected when none of the determined process measures indicate PE or NE.
+| (P=2) shall be selected when at least one of the determined process measures indicate PE or NE, but the gaps evaluated are acceptable, means
+|       the risk of systematic faults due to these gaps is sufficiently low or manageable by mitigating the gaps.
+| (P=3) in all other cases.
+
+<component name> is determined as P=<1|2|3>
+
+
+Step 2: Determine (C): the uncertainty of finding systematic faults based on the Complexity
+-------------------------------------------------------------------------------------------
+
+| Apply the complexity measures to determine (C).
+| The result of a complexity measure shall have as outcome [NH, HM, NM]
+| - NH: Not High
+| - HM: High but Manageable
+| - NM: high and Not Manageable
+|
+| **Complexity measure for programming language: <C++ or RUST>**
+
+<select the correct table below (table for C++ is TBD)>
+
+.. list-table:: Determine (C) for RUST
+    :header-rows: 1
+
+    * - Id
+      - Indicator for high Complexity
+      - Complexity measure Tool
+      - Result
+      - Number
+
+    * - 1
+      - High amount of Lines of Code
+      - Lines of Code (without comments) (generated code is excluded, e.g. ProtoCmpl)
+      - <NH|HM|NM>
+      - <Number>
+
+    * - 2
+      - Unsafe code used / total unsafe code
+      - Count:
+            * LoUC+N: lines of unsafe code with safety note
+            * LoUC  : lines of unsafe code, no safety note
+      - <NH|HM|NM>
+      - <Number>
+
+    * - 3
+      - | Test exists / Coverage (Function, Line)
+        | (maybe better: testability, but how to measure?)
+      - Existing Tests Coverage
+      - <NH|HM|NM>
+      - <Number>
+
+    * - 4
+      - High amount of public function interfaces
+      - Number of public function interfaces
+      - <NH|HM|NM>
+      - <RNumber>
+
+    * - 5
+      - High amount of function parameters
+      - Number of parameters
+      - <NH|HM|NM>
+      - <Number>
+
+
+| (C=1) shall be selected when none of the determined complexity measures indicate HM or NM.
+| (C=2) shall be selected when at least one of the determined complexity measures indicate HM or NM, but the gaps evaluated are acceptable, means
+|       the risk of systematic faults due to these gaps is sufficiently low in the context of the project or manageable by mitigating the gaps.
+| (C=3) in all other cases.
+|
+
+<component name> is determined as C=<1|2|3>
+
+
+Step 3: Determine (CLAS_OUT): the classification outcome
+--------------------------------------------------------
+
+| Select CLAS_OUT depending on the determined values of (C) and (P)
+
++-------+-----------------------+
+| ( C ) | ( P )                 |
++-------+-------+-------+-------+
+|       |  1    |  2    |  3    |
++=======+=======+=======+=======+
+| 1     |  Q    |  Q    | QR    |
++-------+-------+-------+-------+
+| 2     |  QR   | QR    | QR    |
++-------+-------+-------+-------+
+| 3     |  QR   | QR    | NQ    |
++-------+-------+-------+-------+
+
+<component name> is classified as CLAS_OUT=<Q|QR|NQ>
+
+
+Step 4: Document all results and rationale for choosing (P) and (C) and (CLAS_OUT)
+----------------------------------------------------------------------------------
+This document
+
+
+Step 5: Based on (CLAS_OUT) select the activities
+-------------------------------------------------
+
+| As soon as the change request containing this is in status "Accepted", the module safety plan for the component development is adapted based on the following: (select according to above result)
+| - Q: Follow the processes for qualification of software components in a safety context.
+| - QR: Follow the process for pre-existing software architectural elements
+| - NQ: Do no use this element in safety context
diff --git a/docs/module/log/detailed_design/index.rst b/docs/module/log/detailed_design/index.rst
@@ -0,0 +1,72 @@
+..
+   # *******************************************************************************
+   # Copyright (c) 2025 Contributors to the Eclipse Foundation
+   #
+   # See the NOTICE file(s) distributed with this work for additional
+   # information regarding copyright ownership.
+   #
+   # This program and the accompanying materials are made available under the
+   # terms of the Apache License Version 2.0 which is available at
+   # https://www.apache.org/licenses/LICENSE-2.0
+   #
+   # SPDX-License-Identifier: Apache-2.0
+   # *******************************************************************************
+
+.. _component_detailed_design_log:
+
+Detailed Design
+###############
+
+.. document:: Log Detailed Design
+   :id: doc__log_detailed_design
+   :status: draft
+   :safety: QM
+   :security: NO
+   :realizes: wp__sw_implementation
+   :tags: log
+
+
+Detailed Design for Component: Log
+==================================
+
+Description
+-----------
+
+| Design Decisions - For the documentation of the decision the :need:`gd_temp__change_decision_record` can be used.
+| Design Constraints
+
+Rationale Behind Decomposition into Units
+******************************************
+| mandatory: a motivation for the decomposition into one or more units.
+
+.. note:: Reason for split into multiple units could be-
+	    - Based on design principles like SOLID,DRY etc
+	    - Based on design pattern's etc.
+
+Static Diagrams for Unit Interactions
+-------------------------------------
+.. code-block:: rst
+
+   .. dd_sta:: <Title>
+      :id: dd_sta__<Feature>__<Title>
+      :security: <YES|NO>
+      :safety: QM
+      :status: <valid|invalid>
+      :implements: <link to component requirement id>
+      :satisfies: <link to component architecture id>
+
+        .. image:: <link to drawio image> or .. uml:: <link to plantuml>
+
+Dynamic Diagrams for Unit Interactions
+--------------------------------------
+.. code-block:: rst
+
+   .. dd_dyn:: <Title>
+      :id: dd_dyn__<Feature>__<Title>
+      :security: <YES|NO>
+      :safety: QM
+      :status: <valid|invalid>
+      :implements: <link to component requirement id>
+      :satisfies: <link to component architecture id>
+
+        .. image:: <link to drawio image> or .. uml:: <link to plantuml>