Add time slave component requirements

score/time_slave/docs/detailed_design/chklst_impl_inspection.rst

@@ -0,0 +1,125 @@
+..
+   # *******************************************************************************
+   # Copyright (c) 2026 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
+   # *******************************************************************************
+
+.. document:: Time Slave Implementation Inspection Checklist
+  :id: doc__time_slave_impl_inspection
+  :status: draft
+  :version: 1
+  :safety: ASIL_B
+  :security: YES
+  :realizes: wp__sw_implementation_inspection
+  :tags: time_slave
+
+.. note::
+   Work in progress: structure, titles, and needs IDs only. Content and req/comp/feat traceability links to follow in later PRs.
+
+.. attention::
+    The above directive must be updated according to your Component.
+
+    - Adjust ``status`` to be ``valid``
+    - Adjust ``safety``, ``security`` and ``tags`` according to your needs
+
+Implementation Inspection Checklist
+===================================
+
+Purpose
+-------
+
+The purpose of this checklist is to collect the topics to be checked during implementation,
+i.e. in the detailed design and the source code of the units.
+
+The checklist shall be agnostic to which programming language is used. Differences shall be treated
+by linking to C++ or Rust specific documentation.
+
+Conduct
+-------
+
+As described in the concept :need:`doc_concept__wp_inspections` the following "inspection roles" are expected to be filled:
+
+- content responsible (author): <contributor/committer explicitly named here, who is the main author, as can be seen in config mgt tooling>
+- reviewer: <contributor/committer explicitly named here, who is the main content reviewer, must be different from content responsible>
+- moderator: <committer explicitly named here, who is is the safety manager, security manager or quality manager initiating the inspection>
+
+Checklist
+---------
+
+It is mandatory to fill in the "passed" column with "yes" or "no" for each checklist item and additionally to add in the remarks why it is passed or not passed.
+In case of "no" an issue link to the issue tracking system has to be added in the last column (if not solved in the same issue).
+See also :need:`doc_concept__wp_inspections` for further information about reviews in general and inspection in particular.
+
+.. list-table:: Implementation Checklist
+   :header-rows: 1
+   :widths: 10,30,50,6,6,8
+
+   * - Review ID
+     - Acceptance Criteria
+     - Guidance
+     - Passed
+     - Remarks
+     - Issue link
+   * - IMPL_01_01
+     - Is the design according to guidelines?
+     - see :need:`gd_temp__detailed_design` and :need:`doc_concept__imp_concept`
+       (e.g. are the views done with the proposed UML diagrams)
+     -
+     -
+     -
+   * - IMPL_01_02
+     - Is the implementation according to specification?
+     - Check if the linked component requirements are fulfilled
+       and detailed design also matches architecture description.
+     -
+     -
+     -
+   * - IMPL_01_03
+     - Are the design decisions and constraints documented?
+     - Check also for plausibility of these.
+     -
+     -
+     -
+   * - IMPL_01_04
+     - Are all external libraries used by the component specified in the detailed design?
+     - Check the automated dependency analysis.
+       Also make sure ASIL rated units also only use ASIL rated libraries.
+     -
+     -
+     -
+   * - IMPL_02_01
+     - Are the static and dynamic code analysis reports verified for violations?
+     - All violations in ASIL related code must be justified. This includes the checks of coding guidelines.
+     -
+     -
+     -
+   * - IMPL_02_02
+     - Do manual checks, that are derived from the coding guideline, find no safety critical error?
+     - Check this for the programming language used (e.g. C++ <link_to_checks_list>, Rust <link_to_checks_list>)
+     -
+     -
+     -
+   * - IMPL_03_01
+     - Do the UID of the interface in component documentation match the implemented interface names of the unit?
+     - Compare interface UIDs (which contains the interface name) in component architecture/detailed design documentation
+       with public interfaces in source code (e.g. API headers, traits, public types/functions).
+     -
+     -
+     -
+   * - IMPL_03_02
+     - Are detailed design and source code consistent and is the respective traceability established ?
+     - Check if available static and dynamic design diagrams and the textual descriptions match the code
+       (e.g. naming of interfaces, units, functions/operations/messages, data types).
+       Check if the folder/file names of the units and its source code matches the intended functionality.
+       For example if a unit is named "communication" it should not contain code for "data processing".
+     -
+     -
+     -

score/time_slave/docs/detailed_design/detailed_design.rst

@@ -0,0 +1,96 @@
+..
+   # *******************************************************************************
+   # Copyright (c) 2026 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
+   # *******************************************************************************
+
+.. _time_slave_detailed_design:
+
+Time Slave Detailed Design
+===========================
+
+.. document:: Time Slave Detailed Design
+   :id: doc__time_slave_detailed_design
+   :status: draft
+   :version: 1
+   :safety: ASIL_B
+   :security: NO
+   :realizes: wp__sw_implementation
+   :tags: time_slave
+
+.. note::
+   Work in progress: structure, titles, and needs IDs only. Content and req/comp/feat traceability links to follow in later PRs.
+
+.. attention::
+    The above directive must be updated according to your Component.
+
+    - Adjust ``status`` to be ``valid``
+    - Adjust ``safety`` and ``tags`` according to your needs
+
+Detailed Design for Time Slave
+===============================
+
+Description
+-----------
+
+| Design Decisions - For the documentation of the decision the :need:`gd_temp__change_decision_record` can be used.
+| Design Constraints
+
+Example:
+
+ - component is split into two units unit1 and unit2 based on single responsibility principle.
+ - unit2 is injected to unit1 one via dependency injection for testability.
+
+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
+-------------------------------------
+
+A static view provides an overview of the units and their relationships using
+UML 2.0 notations (e.g. class diagrams, component diagrams). Use ``.. uml::``
+or ``.. image::`` directives to include the diagram.
+
+.. uml:: dd_example_ex_sta.puml
+
+Dynamic Diagrams for Unit Interactions (optional)
+--------------------------------------------------
+
+A dynamic view illustrates how the units within a component interact over their
+interfaces to fulfill a specific use case or functionality. It is optional when the
+component's behaviour is straightforward and can be understood from the static view
+and interface documentation alone.
+
+Use standard UML behavioural diagrams (sequence diagrams, state machine diagrams)
+with ``.. uml::`` or ``.. image::`` directives.
+
+.. uml:: dd_example_ex_dyn.puml
+
+Units within the Component
+--------------------------
+
+The relationship between a unit and its parent component is established implicitly
+through the file path. Each component has its own directory, and units residing
+within that directory belong to it. The unit's attributes and behaviour are documented
+in the source code itself. A separate static diagram per unit is not required.
+
+Interface documentation of a software unit is part of the source code (e.g. public
+API headers, trait definitions, or documented function signatures).
+
+Example:
+
+- unit1: implements the main logic (see source code for details)
+- unit2: injected into unit1 via dependency injection for testability

score/time_slave/docs/detailed_design/index.rst

@@ -0,0 +1,45 @@
+..
+   # *******************************************************************************
+   # Copyright (c) 2026 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
+   # *******************************************************************************
+
+.. _time_slave_detailed_design_index:
+
+Detailed Design
+###############
+
+.. note::
+   Work in progress: page structure only, content to follow in later PRs.
+
+.. attention::
+
+   The detailed design document is optional and should be created if the design of the component is complex and cannot be easily understood from the architecture documentation and interface documentation alone.
+   But the inspection checklist for the implementation is mandatory.
+
+
+Detail design example
+---------------------
+
+An example of documenting detailed design can be found in:
+
+   .. toctree::
+
+      detailed_design_example
+
+Inspection Checklist
+--------------------
+
+The checklist for verification of the detailed design and code can be found here:
+
+.. toctree::
+
+   chklst_impl_inspection

score/time_slave/docs/index.rst

@@ -12,16 +12,59 @@
    # SPDX-License-Identifier: Apache-2.0
    # *******************************************************************************
 
-time_slave Component
-====================
+.. _time_slave:
+
+Time Slave
+##########
+
+.. document:: Time Slave
+   :id: doc__time_slave
+   :status: valid
+   :version: 1
+   :safety: QM
+   :security: NO
+   :realizes: wp__cmpt_request
+   :tags: time_slave
+
+.. comp:: Time Slave
+   :id: comp__time_slave
+   :security: NO
+   :safety: QM
+   :status: valid
+   :implements: comp_req__time_slave__gptp_slave, comp_req__time_slave__time_publishing, comp_req__time_slave__sync_state, comp_req__time_slave__phc_sync, comp_req__time_slave__error_reporting, comp_req__time_slave__efficient_access
+   :belongs_to: feat__time[version==1]
+
+
+Abstract
+========
+
+This component implements a gPTP (IEEE 802.1AS) time synchronization slave daemon that receives time synchronization data from network and publishes it to IPC for client applications.
+
+Specification
+=============
+
+The component provides gPTP slave functionality with network message processing and IPC publishing:
+
+* :need:`comp_req__time_slave__gptp_slave`
+* :need:`comp_req__time_slave__time_publishing`
+* :need:`comp_req__time_slave__sync_state`
+* :need:`comp_req__time_slave__phc_sync`
+* :need:`comp_req__time_slave__error_reporting`
+* :need:`comp_req__time_slave__efficient_access`
+
+Footnotes
+=========
+
+Further Documentation of the component can be found in the following sections:
+
+Component Detail Information
+============================
 
 .. toctree::
    :maxdepth: 1
 
-   component_classification
-   architecture/index
    detailed_design/index
    requirements/index
-   manuals/index
-   safety_analysis/index
-   security_analysis/index
+   safety_analysis/dfa
+   safety_analysis/fmea
+   safety_analysis/aou_requirements