docs: Added Daal Feature request(#864)

.gitignore

@@ -23,3 +23,7 @@ styles/
 .venv
 __pycache__/
 /.coverage
+
+# IDE
+/.idea*
+/.clwb*

docs/features/frameworks/daal/index.rst

@@ -0,0 +1,79 @@
+..
+   # *******************************************************************************
+   # 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
+   # *******************************************************************************
+
+
+Deterministic App Abstraction Layer
+--------------------------------------
+.. document:: Deterministic App Abstraction Layer
+   :id: doc__daal
+   :status: valid
+   :safety: ASIL_B
+   :tags: contribution_request, feature_request
+
+.. toctree::
+   :maxdepth: 2
+   :caption: Contents
+
+   requirements/index.rst
+
+Feature flag
+------------
+
+To activate this feature, use the following feature flag:
+
+``experimental_daal``
+
+Abstract
+--------
+
+Provides an application abstraction layer and APIs for testing.
+Implements common code and several safety requirements.
+
+
+Motivation
+----------
+Currently there is no abstraction layer to make component tests independent from application frameworks like 'Fixed Execution Order Framework'.
+With the abstraction layer you can test against different execution frameworks and in different environments (linux & qnx).
+
+Rationale
+---------
+
+The lifecycle states are designed like in usual execution frameworks to emulate the same behavior also in testing.
+Also error handling and health monitoring is part of the framework for emulation of all aspects.
+Different communication frameworks can be plugged in to use in testing.
+The idea is also to use the framework as a testing area for our future Autosar process.
+
+
+Backwards Compatibility
+-----------------------
+
+It can have impact in the Feo Framework because we need only one Lifecycle interface.
+
+
+Open Issues
+-----------
+
+[Any points that are still being decided/discussed.]
+
+   .. note::
+       While a CR is in draft, ideas can come up which warrant further discussion.
+       Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution.
+       This helps make sure all issues required for the CR to be ready for consideration are complete and reduces people duplicating prior discussion.
+
+
+
+Footnotes
+---------
+
+[A collection of footnotes cited in the CR, and a place to list non-inline hyperlink targets.]

docs/features/frameworks/daal/requirements/index.rst

@@ -0,0 +1,108 @@
+..
+   # *******************************************************************************
+   # 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
+   # *******************************************************************************
+Requirements
+############
+
+General
+================================
+
+.. feat_req:: Support for Time-based Architecture
+   :id: feat_req__daal__time_based_arch
+   :reqtype: Functional
+   :security: NO
+   :safety: QM
+   :satisfies: stkh_req__app_architectures__support_time
+   :status: valid
+
+   The daal framework shall provide Trigger to support a time-based architecture.
+
+.. feat_req:: Lifecycle Interface
+   :id: feat_req__daal__lifecycle
+   :reqtype: Functional
+   :security: NO
+   :safety: QM
+   :satisfies: stkh_req__overall_goals__reuse_of_app_soft,stkh_req__execution_model__processes,stkh_req__execution_model__low_power
+   :status: valid
+
+   Lifecycle of executables should use one generic API
+
+.. feat_req:: Execution Environments
+   :id: feat_req__daal__env
+   :reqtype: Functional
+   :security: NO
+   :safety: QM
+   :satisfies: stkh_req__functional_req__operating_system
+   :status: valid
+
+   It should be possible to use the framework with all specified os like qnx and linux
+
+
+
+.. feat_req:: Communication
+   :id: feat_req__daal__com
+   :reqtype: Functional
+   :security: NO
+   :safety: QM
+   :satisfies: stkh_req__app_architectures__support_data
+   :status: valid
+
+   The communication layer should use the IPC Framework
+
+.. feat_req:: Logging
+   :id: feat_req__daal__log
+   :reqtype: Functional
+   :security: NO
+   :safety: QM
+   :satisfies: stkh_req__functional_req__logging
+   :status: valid
+
+   Core Logging API should be used
+
+.. feat_req:: Trigger
+   :id: feat_req__daal__trigger
+   :reqtype: Functional
+   :security: NO
+   :safety: QM
+   :satisfies: stkh_req__execution_model__processes
+   :status: valid
+
+   Singe Shot and Cyclic execution should be possible
+
+.. feat_req:: Health & Error Management
+   :id: feat_req__daal__health_error
+   :reqtype: Functional
+   :security: NO
+   :safety: QM
+   :satisfies: stkh_req__execution_model__processes
+   :status: valid
+
+   Error and Health Management should be availability
+
+
+Open Issues
+-----------
+
+[Any points that are still being decided/discussed.]
+
+   .. note::
+       While a CR is in draft, ideas can come up which warrant further discussion.
+       Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution.
+       This helps make sure all issues required for the CR to be ready for consideration are complete and reduces people duplicating prior discussion.
+
+
+
+Footnotes
+---------
+
+[A collection of footnotes cited in the CR, and a place to list non-inline hyperlink targets.]

docs/features/frameworks/index.rst

@@ -18,4 +18,5 @@ Frameworks
 
 .. toctree::
 
-   feo/index.rst
+   fixed-execution-order/index.rst
+   daal/index.rst

docs/requirements/stakeholder/index.rst

@@ -150,7 +150,15 @@ Functional requirements
    :rationale: This allows portability of platform on POSIX compliant operating systems.
    :status: valid
 
-   The platform shall support operating systems compliant with IEEE Std 1003.1 (2004 Edition or newer)
+.. stkh_req:: Logging
+   :id: stkh_req__functional_req__logging
+   :reqtype: Functional
+   :security: NO
+   :safety: QM
+   :rationale: This allows portability of platform on POSIX compliant operating systems.
+   :status: valid
+
+   The platform should have one central logging framework
 
 .. stkh_req:: Video subsystem
    :id: stkh_req__functional_req__video_subsystem