Initial version of logging Feature Request

docs/features/analysis-infra/index.rst

@@ -16,4 +16,8 @@ Analysis Infrastructure
 #######################
 
 .. toctree::
+   :titlesonly:
+   :maxdepth: 1
+
    logging/index.rst
+   tracing/index.rst

docs/features/analysis-infra/logging/index.rst

@@ -12,9 +12,11 @@
    # SPDX-License-Identifier: Apache-2.0
    # *******************************************************************************
 
-Logging
-#######
+.. Logging
+.. #######
 
 .. toctree::
-   console-output/index.rst
-   mw-log-api/index.rst
+   :titlesonly:
+   :maxdepth: 1
+
+   ./mw-fr_logging.rst

docs/features/analysis-infra/logging/mw-fr_logging.rst

@@ -0,0 +1,174 @@
+..
+   # *******************************************************************************
+   # Copyright (c) 2024 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
+   # *******************************************************************************
+
+Logging
+#######
+
+.. document:: Logging
+   :id: DOC_Logging
+   :status: draft
+   :safety: ASIL_D
+   :tags: feature_request
+
+
+Feature flag
+============
+
+To activate this feature, use the following feature flag:
+
+``experimental_Logging``
+
+Abstract
+========
+
+This feature request proposes the development of a safe, efficient and robust logging framework for embedded systems.
+
+
+Motivation
+==========
+
+- currently no solution availible in the score platform
+
+Rationale
+=========
+
+Logging provides the possibility to understand the running system by capturing detailed information about system events.
+
+Specification
+=============
+
+[Describe the requirements, architecture of any new feature.] [or]
+[Describe the change to requirements, architecture, implementation, process, documentation, infrastructure of any change request.]
+
+   .. note::
+      A Feature Request shall specify the stakeholder requirements as part of our platform/project.
+      Thereby the :need:`RL_technical_lead` will approve these requirements as part of accepting the Feature Request (e.g. merging the PR with the Feature Request).
+
+Functionality
+-------------
+
+Logging has to support the following features:
+- Timestamping
+- Log/serverity levels
+- Log priorisation in case of ressource conflicts
+- logging of early startup envents
+- log filtering
+- message loss detection
+- Component specific log level activation ???
+
+Log Sources
+-----------
+
+- raw sensor data e.g. video streams
+- user application
+- component features & platform
+
+Log Sinks
+---------
+
+- console
+- File system
+  -- local
+  -- external mounted PCIe Drive
+  -- Cloud native drive via network
+- Network (incl. second dedicated Ethernet Channel)
+- Logs shall appear on stdout when running unit tests
+
+Configuration
+-------------
+
+- Log level
+- Log Sinks
+- Buffer size
+- Storage size
+- Permission settings
+- log filter
+-
+
+Error handling
+--------------
+
+- reboot/reset
+- On logging errors, the framework should continue if recoverable; otherwise, deactivate silently and set an error state reported on shutdown.
+- The user application should not be affected by logging framework errors.
+
+Context
+-------
+
+- Supported operating system: QNX, Linux (encapsulation via OSAL)
+- Supported programming languages: C++, Rust, Python (e.g. for tests)
+
+Ressource consumtion
+--------------------
+
+- Storage
+- Communication Channel
+- Runtime ressources
+- Low impact on overall performance ---> QoS for handling overflows/dropping log messages
+
+Norms/Standards
+---------------
+
+
+Backwards Compatibility
+=======================
+\-
+
+Security Impact
+===============
+
+- only authorized users should be able to access the log files
+
+Safety Impact
+=============
+
+- The interface should support the ASIL level of the user function.
+- Dependent on the Safety concept of the over all system, the logging should be classified accordingly.
+  That could be the case if the logging informations are part of the verification strategy..
+
+License Impact
+==============
+
+- not kwown
+
+How to Teach This
+=================
+
+How to Use: Logging Guideline
+
+
+Definitions
+===========
+
+Logging
+-------
+
+Write out some message
+General progress description (incl. Context)
+- state changes
+- Infos
+- errors
+
+When logging from a library, it shall be possible to easily associate the logs to the library. A solution could be to provide contexts.
+
+Tracing
+-------
+
+Example - User need to correlate kernel traces to user traces for debugging , analysing etc
+Follow the control flow (on function call basis)of the application.
+
+Recompute
+---------
+
+All data to recompute a module (Input, Output, States)

docs/features/analysis-infra/logging/console-output/index.rst → docs/features/analysis-infra/tracing/index.rst

@@ -12,5 +12,11 @@
    # SPDX-License-Identifier: Apache-2.0
    # *******************************************************************************
 
-Console Output
-##############
+.. Tracing
+.. #######
+
+.. toctree::
+   :titlesonly:
+   :maxdepth: 1
+
+   ./mw-fr_tracing.rst

docs/features/analysis-infra/tracing/mw-fr_tracing.rst

@@ -0,0 +1,122 @@
+..
+   # *******************************************************************************
+   # Copyright (c) 2024 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
+   # *******************************************************************************
+Tracing
+#######
+
+.. document:: Tracing
+   :id: DOC__Your_Feature_Name
+   :status: draft
+   :safety: ASIL_D
+   :tags: contribution_request, feature_request
+
+.. attention::
+    The above directive must be updated according to your Feature.
+
+    - Modify ``name`` to be your Feature Name
+    - Modify ``id`` to be your Feature Name in upper snake case preceded by ``DOC_``
+    - Adjust ``status`` to be ``valid``
+    - Adjust ``asil`` according to your needs
+    - Extend ``tags`` according to your needs, but please keep two default tags there
+
+
+Feature flag
+============
+
+To activate this feature, use the following feature flag:
+
+``experimental_Tracing``
+
+    .. note::
+     The feature flag must reflect the feature name in snake_case. Further, it is prepended with ``experimental_``, as
+     long as the feature is not yet stable.
+
+
+Abstract
+========
+
+[A short (~200 word) description of the contribution being addressed.]
+
+
+Motivation
+==========
+
+[Clearly explain why the existing platform/project solution is inadequate to address the topic that the Feature Request solves.]
+
+    .. note::
+     The motivation is critical for Feature Requests that want to change the existing features or infrastructure.
+     It should clearly explain why the existing solution is inadequate to address the topic that the Feature Request solves.
+     Feature Request submissions without sufficient motivation may be rejected.
+
+
+Rationale
+=========
+
+[Describe why particular design decisions were made.]
+
+
+   .. note::
+      The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
+
+
+Specification
+=============
+
+[Describe the requirements, architecture of any new feature.] or
+[Describe the change to requirements, architecture, implementation, process, documentation, infrastructure of any change request.]
+
+   .. note::
+      A Feature Request shall specify the stakeholder requirements as part of our platform/project.
+      Thereby the :need:`RL_technical_lead` will approve these requirements as part of accepting the Feature Request (e.g. merging the PR with the Feature Request).
+
+
+Backwards Compatibility
+=======================
+
+[Describe potential impact (especially including safety and security impacts) and severity on pre-existing platform/project elements.]
+
+
+Security Impact
+===============
+
+[How could a malicious user take advantage of this new feature?]
+
+   .. note::
+      If there are security concerns in relation to the Feature Request, those concerns should be explicitly written out to make sure reviewers of the Feature Request are aware of them.
+
+
+
+Safety Impact
+=============
+
+[How could the safety be impacted by the new feature?]
+
+   .. note::
+      If there are safety concerns in relation to the Feature Request, those concerns should be explicitly written out to make sure reviewers of the Feature Request are aware of them.
+      ToDo - Link to the Safety Impact Method
+
+[What is the expected ASIL level?]
+[What is the expected classification of the contribution?]
+
+   .. note::
+      Use the component classification method here to classfiy your component, if it shall to be used in a safety context: (TODO: add link to component classification).
+
+
+License Impact
+==============
+
+[How could the copyright impacted by the license of the new contribution?]
+
+
+How to Teach This
+=================