Define the FFI approach - #3139
Conversation
github-project-automation
Bot
added this to
TLC - Technical Lead Circle and S-CORE Roadmap
|
The created documentation from the pull request is available at: docu-html |
| 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. The |
There was a problem hiding this comment.
I think we should also define what that means for the verification of the component. What is the difference between asil relevant components and qm components in respect to our safety process
There was a problem hiding this comment.
Good overview here, what is required for QM and for ASIL
https://eclipse-score.github.io/score/pr-3139/platform_management_plan/software_verification.html#id1
There was a problem hiding this comment.
added a reference to ASIL and QM Verification methods
| safety lifecycle and shall be developed, verified, and released according to | ||
| the corresponding ASIL process. Components that are not intended to execute | ||
| within an ASIL context may remain QM, provided that freedom from interference | ||
| with the safety context is justified in the respective module safety manual. |
There was a problem hiding this comment.
You may Consider Assumed Requirements, https://eclipse-score.github.io/process_description//main/folder_templates/platform/docs/change/decision_record.html, no mixed ASIL, "The SW-platform safety components running in one POSIX process shall implement the highest ASIL of their assigned functional requirements.", so the platform assumes already within Process all components must have same ASIL, may refer to that
There was a problem hiding this comment.
I'll refer to it in that section, the goal of that section is to further clarify how we can abide by stkh_req__dependability__no_mixed_asil
| 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. The |
There was a problem hiding this comment.
Good overview here, what is required for QM and for ASIL
https://eclipse-score.github.io/score/pr-3139/platform_management_plan/software_verification.html#id1
| 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. | ||
| Where components executing in an ASIL context depend on functionality that has |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
aschemmel-tech
left a comment
aschemmel-tech
left a comment
There was a problem hiding this comment.
Is this the only change within score repository? Please also link to changes in other repositories if planned any?
| safety lifecycle and shall be developed, verified, and released according to | ||
| the corresponding ASIL process. Components that are not intended to execute | ||
| within an ASIL context may remain QM, provided that freedom from interference | ||
| with the safety context is justified in the respective module safety manual. |
There was a problem hiding this comment.
I would have said FFI has nothing to do with the module safety manual. But you can refer to the platform AoU in https://eclipse-score.github.io/score/main/requirements/platform_assumptions/index.html#aou_req__platform__process_isolation
| 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. The | ||
| classification is performed at component level and depends on the intended |
There was a problem hiding this comment.
As we have a "safety" attribute on every work product, I think you cannot say classification is performed on the component level (only).
| 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. The | ||
| classification is performed at component level and depends on the intended |
There was a problem hiding this comment.
It also depends on the allocated (safety) requirements
| 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. |
There was a problem hiding this comment.
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).
| 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. |
There was a problem hiding this comment.
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?
6 participants
The PR defines our approach to handling modules that may contain components that are executed from within safe context in order to maintain FFI
#1122