Skip to content

Define the FFI approach #3139

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ANegm-ETAS wants to merge 7 commits into
base: main
Choose a base branch
from
Open

Define the FFI approach #3139

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
7739198
Add FFI approach to platform safety manual
AdhamN861 Jul 23, 2026
92758d7
Update FFI Approach
AdhamN861 Jul 29, 2026
422afea
Add reference to No Mixed ASIL stakeholder requirement
AdhamN861 Jul 30, 2026
8772719
Add reference to ASIL/QM verification methods
AdhamN861 Jul 30, 2026
545128b
Fix Build Build Warnings
AdhamN861 Jul 30, 2026
48b2ae7
Fix Build Build Warning
AdhamN861 Jul 30, 2026
6915802
Fix Broken references
AdhamN861 Jul 30, 2026
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
2 changes: 1 addition & 1 deletion docs/features/lifecycle/architecture/launch_manager.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -362,7 +362,7 @@ Dynamic architecture
:status: valid
:version: 1
:safety: ASIL_B
:fulfils: feat_req__lifecycle__monitoring_processes[version==1], feat_req__lifecycle__polling_interval[version==1], , feat_req__lifecycle__failure_detect[version==1]
:fulfils: feat_req__lifecycle__monitoring_processes[version==1], feat_req__lifecycle__polling_interval[version==1], feat_req__lifecycle__failure_detect[version==1]
:includes:
:belongs_to: feat__lifecycle[version==1]

Expand Down
18 changes: 9 additions & 9 deletions docs/features/lifecycle/requirements/index.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ Launching Processes
:security: NO
:safety: ASIL_B
:derived_from: stkh_req__execution_model__processes[version==1]
:status: invalid
:status: valid
:version: 1
:valid_from: v1.0.0

Expand Down Expand Up @@ -384,7 +384,7 @@ Conditional Launching
:security: NO
:safety: ASIL_B
:derived_from: stkh_req__execution_model__processes[version==1]
:status: invalid
:status: valid
:version: 1
:valid_from: v1.0.0

Expand Down Expand Up @@ -650,7 +650,7 @@ Run targets
:security: NO
:safety: ASIL_B
:derived_from: stkh_req__execution_model__processes[version==1]
:status: invalid
:status: valid
:version: 1
:valid_from: v1.0.0

Expand All @@ -662,7 +662,7 @@ Run targets
:security: NO
:safety: ASIL_B
:derived_from: stkh_req__execution_model__processes[version==1]
:status: invalid
:status: valid
:version: 1
:valid_from: v1.0.0

Expand Down Expand Up @@ -802,7 +802,7 @@ Control Interface
:security: NO
:safety: ASIL_B
:derived_from: stkh_req__execution_model__processes[version==1]
:status: invalid
:status: valid
:version: 1
:valid_from: v1.0.0

Expand Down Expand Up @@ -844,7 +844,7 @@ Control Interface
:security: NO
:safety: ASIL_B
:derived_from: stkh_req__execution_model__processes[version==1]
:status: invalid
:status: valid
:version: 1
:valid_from: v1.0.0

Expand Down Expand Up @@ -942,7 +942,7 @@ Monitoring, Notification and Recovery
:security: NO
:safety: ASIL_B
:derived_from: stkh_req__execution_model__processes[version==1]
:status: invalid
:status: valid
:version: 1
:valid_from: v1.0.0

Expand All @@ -955,7 +955,7 @@ Monitoring, Notification and Recovery
:security: NO
:safety: ASIL_B
:derived_from: stkh_req__execution_model__processes[version==1]
:status: invalid
:status: valid
:version: 1
:valid_from: v1.0.0

Expand All @@ -968,7 +968,7 @@ Monitoring, Notification and Recovery
:security: NO
:safety: ASIL_B
:derived_from: stkh_req__execution_model__processes[version==1]
:status: invalid
:status: valid
:version: 1
:valid_from: v1.0.0

Expand Down
2 changes: 1 addition & 1 deletion docs/modules/lifecycle/index.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ Lifecycle
.. comp_req:: Lifecycle
:id: comp_req__lifecycle__launch
:reqtype: Functional
:status: invalid
:status: valid
:version: 1
:security: NO
:safety: ASIL_B
Expand Down
2 changes: 2 additions & 0 deletions docs/platform_management_plan/software_verification.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -149,6 +149,8 @@ There are the following different levels of integration and verification defined
Practically, this means S-CORE will implement Platform Integration Tests for stakeholder requirements for demonstration,
but these are not intended to completely covering all stakeholder requirements.

.. _verification-methods:

Verification Methods
--------------------

Expand Down
28 changes: 28 additions & 0 deletions docs/safety/platform_safety_manual.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,17 @@ Assumptions of Use which are relevant for all users of any platform module.
The specific Assumptions of Use relevant only for the users of a specific module are documented in the module's safety manual.
That means that the platform safety manual always has to be read together with all its modules safety manuals.

A platform module may contain both ASIL-relevant and QM components, see :ref:`verification-methods`
for an overview of what is required for ASIL and QM components. The
classification is performed at component level and depends on the intended

@aschemmel-tech aschemmel-tech Jul 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we have a "safety" attribute on every work product, I think you cannot say classification is performed on the component level (only).

@aschemmel-tech aschemmel-tech Jul 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It also depends on the allocated (safety) requirements

execution context rather than on the module as a whole. Components that are
intended to execute within an ASIL context are in scope of the applicable ASIL
safety lifecycle and shall be developed, verified, and released according to
the corresponding ASIL process, see :need:`stkh_req__dependability__no_mixed_asil`.
Components that are not intended to executewithin an ASIL context may remain QM,
provided that freedom from interference with the safety context is justified in
the respective module safety manual.

Assumed Platform Safety Requirements
------------------------------------

Expand Down Expand Up @@ -93,6 +104,23 @@ The S-CORE SW platform has no safety concept additional to its module's safety c
The expectations towards the execution environment are described in the respective AoU, this is mainly that a safe posix operating system
integrated into a target hardware which includes safety mechanisms which cover hardware related errors.

The platform allows ASIL and QM components to coexist within the same module.

@aschemmel-tech aschemmel-tech Jul 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same information as above line 37, but not quite correct, as the "module" is only a container for documentation and source code but not a architectural element (as this sentence sounds).

Where components executing in an ASIL context depend on functionality that has

@masc2023 masc2023 Jul 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As Assumed here, https://eclipse-score.github.io/score/pr-3139/platform_management_plan/software_verification.html#id1
there is already a requirement, if the concept requires components used as part of safety context, is must be ASIL, can directly derived from that stakeholder requirement

@ANegm-ETAS ANegm-ETAS Jul 30, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not exactly a new requirement but an attempt to clarify how to apply that requirement in the context of a module that may contain components with different ASIL levels all while maintaining freedom from interference

@masc2023 masc2023 Jul 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, then it is more a safety concept to apply FFI on modules, which are QM, but also to be used from safety relevant component. The Safety Concept means, that the part for interacting with QM part shall be developed according to the required ASIL and run in the same context, etc.

no direct safety purpose, freedom from interference shall be ensured between
the safety-relevant and non-safety-relevant parts. This may require additional
safety requirements to be allocated to components that otherwise only provide
QM functionality. Such requirements exist to preserve the integrity of the
safety context and are applied in addition to the component's functional
requirements.

For example, the ``mw::log`` frontend is linked into and executed within an
ASIL-B application. Although logging functionality itself may only provide QM
services, the frontend forms part of the ASIL execution context and therefore
must fulfil additional safety requirements derived from the need to maintain
freedom from interference. In contrast, the ``datarouter`` daemon executes as a
separate process and may remain QM, provided that the required freedom from
interference is justified in the module safety manual.

@aschemmel-tech aschemmel-tech Jul 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

already justified in platform safety manual by https://eclipse-score.github.io/score/main/requirements/platform_assumptions/index.html#aou_req__platform__process_isolation
or do you mean that additionally the communication between frontend and daemon must be defined as allowing FFI?



Safety Anomalies
----------------
Expand Down
Loading