Skip to content

Commit 1f429ae

Browse files
FScholPerFScholPer
committed
docs: Added Daal Feature request(#864)
Added first initial Feature Request
1 parent 76a92b7 commit 1f429ae

File tree

5 files changed

+247
-1
lines changed

5 files changed

+247
-1
lines changed

‎.gitignore‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -23,3 +23,7 @@ styles/
2323
.venv
2424
__pycache__/
2525
/.coverage
26+
27+
# IDE
28+
/.idea*
29+
/.clwb*

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

Lines changed: 79 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,79 @@
1+
..
2+
# *******************************************************************************
3+
# Copyright (c) 2025 Contributors to the Eclipse Foundation
4+
#
5+
# See the NOTICE file(s) distributed with this work for additional
6+
# information regarding copyright ownership.
7+
#
8+
# This program and the accompanying materials are made available under the
9+
# terms of the Apache License Version 2.0 which is available at
10+
# https://www.apache.org/licenses/LICENSE-2.0
11+
#
12+
# SPDX-License-Identifier: Apache-2.0
13+
# *******************************************************************************
14+
15+
16+
Deterministic App Abstraction Layer
17+
--------------------------------------
18+
.. document:: Deterministic App Abstraction Layer
19+
:id: doc__daal
20+
:status: valid
21+
:safety: ASIL_B
22+
:tags: contribution_request, feature_request
23+
24+
.. toctree::
25+
:maxdepth: 2
26+
:caption: Contents
27+
28+
requirements/index.rst
29+
30+
Feature flag
31+
------------
32+
33+
To activate this feature, use the following feature flag:
34+
35+
``experimental_daal``
36+
37+
Abstract
38+
--------
39+
40+
Provides an application abstraction layer and APIs for testing.
41+
Implements common code and several safety requirements.
42+
43+
44+
Motivation
45+
----------
46+
Currently there is no abstraction layer to make component tests independent from application frameworks like 'Fixed Execution Order Framework'.
47+
With the abstraction layer you can test against different execution frameworks and in different environments (linux & qnx).
48+
49+
Rationale
50+
---------
51+
52+
The lifecycle states are designed like in usual execution frameworks to emulate the same behavior also in testing.
53+
Also error handling and health monitoring is part of the framework for emulation of all aspects.
54+
Different communication frameworks can be plugged in to use in testing.
55+
The idea is also to use the framework as a testing area for our future Autosar process.
56+
57+
58+
Backwards Compatibility
59+
-----------------------
60+
61+
It can have impact in the Feo Framework because we need only one Lifecycle interface.
62+
63+
64+
Open Issues
65+
-----------
66+
67+
[Any points that are still being decided/discussed.]
68+
69+
.. note::
70+
While a CR is in draft, ideas can come up which warrant further discussion.
71+
Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution.
72+
This helps make sure all issues required for the CR to be ready for consideration are complete and reduces people duplicating prior discussion.
73+
74+
75+
76+
Footnotes
77+
---------
78+
79+
[A collection of footnotes cited in the CR, and a place to list non-inline hyperlink targets.]

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

Lines changed: 154 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,154 @@
1+
..
2+
# *******************************************************************************
3+
# Copyright (c) 2025 Contributors to the Eclipse Foundation
4+
#
5+
# See the NOTICE file(s) distributed with this work for additional
6+
# information regarding copyright ownership.
7+
#
8+
# This program and the accompanying materials are made available under the
9+
# terms of the Apache License Version 2.0 which is available at
10+
# https://www.apache.org/licenses/LICENSE-2.0
11+
#
12+
# SPDX-License-Identifier: Apache-2.0
13+
# *******************************************************************************
14+
15+
16+
Deterministic App Abstraction Layer
17+
--------------------------------------
18+
.. document:: Deterministic App Abstraction Layer
19+
:id: doc__daal
20+
:status: valid
21+
:safety: ASIL_B
22+
:tags: contribution_request, feature_request
23+
24+
Feature flag
25+
------------
26+
27+
To activate this feature, use the following feature flag:
28+
29+
``experimental_daal``
30+
31+
Abstract
32+
--------
33+
34+
Provides an application abstraction layer and APIs for testing.
35+
Implements common code and several safety requirements.
36+
37+
38+
Motivation
39+
----------
40+
Currently there is no abstraction layer to make component tests independent from application frameworks like 'Fixed Execution Order Framework'.
41+
With the abstraction layer you can test against different execution frameworks and in different environments (linux & qnx).
42+
43+
Rationale
44+
---------
45+
46+
The lifecycle states are designed like in usual execution frameworks to emulate the same behavior also in testing.
47+
Also error handling and health monitoring is part of the framework for emulation of all aspects.
48+
Different communication frameworks can be plugged in to use in testing.
49+
The idea is also to use the framework as a testing area for our future Autosar process.
50+
51+
52+
Backwards Compatibility
53+
-----------------------
54+
55+
It can have impact in the Feo Framework because we need only one Lifecycle interface.
56+
57+
58+
Requirements
59+
------------
60+
Requirements
61+
############
62+
63+
General
64+
================================
65+
66+
.. feat_req:: Support for Time-based Architecture
67+
:id: feat_req__daal__time_based_arch
68+
:reqtype: Functional
69+
:security: NO
70+
:safety: QM
71+
:satisfies: stkh_req__app_architectures__support_time
72+
:status: valid
73+
74+
The daal framework shall provide Trigger to support a time-based architecture.
75+
76+
.. feat_req:: Lifecycle Interface
77+
:id: feat_req__daal__lifecycle
78+
:reqtype: Functional
79+
:security: NO
80+
:safety: QM
81+
:satisfies: stkh_req__overall_goals__reuse_of_app_soft,stkh_req__execution_model__processes,stkh_req__execution_model__low_power
82+
:status: valid
83+
84+
Lifecycle of executables should use one generic API
85+
86+
.. feat_req:: Execution Environments
87+
:id: feat_req__daal__env
88+
:reqtype: Functional
89+
:security: NO
90+
:safety: QM
91+
:satisfies: stkh_req__functional_req__operating_system
92+
:status: valid
93+
94+
It should be possible to use the framework with all specified os like qnx and linux
95+
96+
97+
98+
.. feat_req:: Communication
99+
:id: feat_req__daal__com
100+
:reqtype: Functional
101+
:security: NO
102+
:safety: QM
103+
:satisfies: stkh_req__app_architectures__support_data
104+
:status: valid
105+
106+
The communication layer should use the IPC Framework
107+
108+
.. feat_req:: Logging
109+
:id: feat_req__daal__log
110+
:reqtype: Functional
111+
:security: NO
112+
:safety: QM
113+
:satisfies: stkh_req__functional_req__logging
114+
:status: valid
115+
116+
Core Logging API should be used
117+
118+
.. feat_req:: Trigger
119+
:id: feat_req__daal__trigger
120+
:reqtype: Functional
121+
:security: NO
122+
:safety: QM
123+
:satisfies: feat_req__ipc__time_based_arch
124+
:status: valid
125+
126+
Singe Shot and Cyclic execution should be possible
127+
128+
.. feat_req:: Health & Error Management
129+
:id: feat_req__daal__health_error
130+
:reqtype: Functional
131+
:security: NO
132+
:safety: QM
133+
:satisfies: stkh_req__execution_model__processes
134+
:status: valid
135+
136+
Error and Health Management should be availability
137+
138+
139+
Open Issues
140+
-----------
141+
142+
[Any points that are still being decided/discussed.]
143+
144+
.. note::
145+
While a CR is in draft, ideas can come up which warrant further discussion.
146+
Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution.
147+
This helps make sure all issues required for the CR to be ready for consideration are complete and reduces people duplicating prior discussion.
148+
149+
150+
151+
Footnotes
152+
---------
153+
154+
[A collection of footnotes cited in the CR, and a place to list non-inline hyperlink targets.]

‎docs/features/frameworks/index.rst‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -19,3 +19,4 @@ Frameworks
1919
.. toctree::
2020

2121
fixed-execution-order/index.rst
22+
daal/index.rst

‎docs/requirements/stakeholder/index.rst‎

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -150,7 +150,15 @@ Functional requirements
150150
:rationale: This allows portability of platform on POSIX compliant operating systems.
151151
:status: valid
152152

153-
The platform shall support operating systems compliant with IEEE Std 1003.1 (2004 Edition or newer)
153+
.. stkh_req:: Logging
154+
:id: stkh_req__functional_req__logging
155+
:reqtype: Functional
156+
:security: NO
157+
:safety: QM
158+
:rationale: This allows portability of platform on POSIX compliant operating systems.
159+
:status: valid
160+
161+
The platform should have one central logging framework
154162

155163
.. stkh_req:: Video subsystem
156164
:id: stkh_req__functional_req__video_subsystem

0 commit comments

Comments
 (0)