Repository navigation
Improvement: Define a FFI approach #1122
Description
Important
Make sure to link this issue with the PR for your improvement.
FFI (Freedom From Interference) needs to be guaranteed if mixed criticality components are used. E.g. a Logging library may not have any (Functional) Safety Requirement to fulfill, but it might be used by an ASIL B component.
As we usually have no safety mechanism to guarantee that the lib interferes with its users memory (like it is available for seperate processes via MPU memory protection) there needs to be another measure for this.
This measure is currently not defined. For example this could be ASIL B like development quality or doing unit testing including memory overwrite checks.
We may even consider to add a stakeholder requirement for this.
Metadata
Metadata
Assignees
Labels
No labels
Activity
aschemmel-tech commentedon May 22, 2026
see also discussion https://github.com/orgs/eclipse-score/discussions/2234#discussioncomment-16903496
ANegm-ETAS commentedon Jul 29, 2026
Below is our current approach after aligning with the rest of the team in the S-Core Safety round:
A platform module may contain both safety-relevant and non-safety-relevant components. The criterion for determining whether a component is in scope of the ASIL safety lifecycle is not whether the component itself implements a safety function, but whether it is intended to execute within an ASIL software context and can therefore affect the correct operation of safety-related functionality.
Components executed within the same process, address space, or protection domain as an ASIL software element cannot rely on Freedom From Interference (FFI) through process separation. Such components are considered part of the ASIL software context and shall therefore be developed, verified, and released according to the applicable ASIL development process.
This does not imply that all functional requirements of such components become ASIL safety requirements. Functional requirements that do not contribute to a safety function may remain classified as QM. However, additional safety-related requirements may be derived to ensure that the component cannot adversely affect the safety properties of the enclosing ASIL software element. Examples include requirements related to memory integrity, resource usage and timing behavior.
ANegm-ETAS commentedon Jul 29, 2026
#3139