Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions docs/components/datarouter/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -13,8 +13,8 @@
# *******************************************************************************


Data Router Documentation
=========================
Data Router Component
=====================

This section is reserved for data router-specific documentation.

Expand Down
91 changes: 91 additions & 0 deletions docs/components/mw/log/architecture/component_architecture.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,91 @@
..
# *******************************************************************************
# 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
# *******************************************************************************

.. _component_architecture:

Component Architecture Documentation
====================================

.. document:: Logging Backend Architecture
:id: doc__logging_backend_architecture
:status: draft
:version: 1
:safety: ASIL_B
:security: NO
:realizes: wp__component_arch

Overview
--------

Supports logging on several backends (file,slog,remote,custom)

Description
-----------

<General Description>

<Design Decisions - For the documentation of the decision the :need:`gd_temp__change_decision_record` can be used.>

<Design Constraints>

Rationale Behind Architecture Decomposition
*******************************************

Mandatory: A motivation for the decomposition or reason for not further splitting it into internal components.

.. note:: Common decisions across components / cross cutting concepts is at the higher level.

Static Architecture
-------------------

The components are designed to cover the expectations from the feature architecture
(i.e. if already exists a definition it should be taken over and enriched).

A component can optional also consist of lower level components to further structure the architecture. The component and its static views can also optionally use interfaces provided by other components.

.. comp:: Logging Backend
:id: comp__logging_backend
:security: YES
:safety: ASIL_B
:status: valid
:implements: logic_arc_int__logging__logging
:belongs_to: feat__logging

This is the logging component library responsible for selecting the appropriate log sinks based on configuration at runtime. It can perform tasks such as log formatting, filtering, and composite backend selection based on runtime context and configuration. The logging component is designed to be extensible, allowing for custom logging backend to be added as needed.


.. comp_arc_sta:: Logging Backend (Static View)
:id: comp_arc_sta__log__sv
:security: YES
:safety: ASIL_B
:status: valid
:version: 1
:belongs_to: comp__logging_backend
:fulfils: comp_req__log__local_allocation_strategy

.. needarch::
:scale: 50
:align: center

{{ draw_component(need(), needs) }}

Dynamic Architecture
--------------------

not needed

Interfaces
----------

not needed
20 changes: 20 additions & 0 deletions docs/components/mw/log/architecture/index.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
..
# *******************************************************************************
# 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
# *******************************************************************************

Component Architecture
======================

.. toctree::

component_architecture
115 changes: 115 additions & 0 deletions docs/components/mw/log/detailed_design/chklst_impl_inspection.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,115 @@
..
# *******************************************************************************
# 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:: Logging Backend Implementation Inspection Checklist
:id: doc__logging_backend_impl_inspection
:status: draft
:version: 1
:safety: ASIL_B
:security: YES
:realizes: wp__sw_implementation_inspection

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".
-
-
-
37 changes: 37 additions & 0 deletions docs/components/mw/log/detailed_design/index.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
..
# *******************************************************************************
# 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
# *******************************************************************************


Detailed Design
###############

.. 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
-------------

`DD mw/log <https://github.com/eclipse-score/logging/blob/main/score/mw/log/design/backend/file_output_backend.md>`_

Inspection Checklist
--------------------

The checklist for verification of the detailed design and code can be found here:

.. toctree::

chklst_impl_inspection
58 changes: 44 additions & 14 deletions docs/components/mw/log/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -13,24 +13,54 @@
# *******************************************************************************


Logging Documentation
=====================
Logging Backend Component
#########################

This section is reserved for middleware-specific documentation.

.. comp:: Logging Component
:id: comp__mw_logging
:security: YES
.. document:: Logging Backend
:id: doc__logging_backend
:status: draft
:version: 1
:safety: ASIL_B
:status: valid
:implements: logic_arc_int__logging__logging
:belongs_to: feat__logging
:security: NO
:realizes: wp__cmpt_request

Abstract
========

Supports logging on several backends (file,slog,remote,custom)


Specification
=============

see :need:`doc__logging_backend_requirements`


How to Teach This
=================

[How to teach users, new and experienced, how to apply the CR to their work.]

.. note::
For a CR that adds new functionality or changes behaviour, it is helpful to include a section on how to teach users, new and experienced, how to apply the CR to their work.

Footnotes
=========

[A collection of footnotes cited in the CR, and a place to list non-inline hyperlink targets.]


Further Documentation of the component can be found in the following sections:

This is the logging component library responsible for selecting the appropriate log sinks based on configuration at runtime. It can perform tasks such as log formatting, filtering, and composite backend selection based on runtime context and configuration. The logging component is designed to be extensible, allowing for custom logging backend to be added as needed.
Component Detail Information
============================

.. toctree::
:titlesonly:
:maxdepth: 1
:glob:

*
architecture/index
detailed_design/index
requirements/index
safety_analysis/dfa
safety_analysis/fmea
safety_analysis/aou_requirements
Loading
Loading