Conversation
|
|
aschemmel-tech
force-pushed
the
aschemmel-tech-add-os-integration
branch
from
2c74181 to
778b891
Compare
|
The created documentation from the pull request is available at: docu-html |
aschemmel-tech
requested review from
a team,
FScholPer,
antonkri,
johannes-esr and
qor-lb
as code owners
| :id: doc__os_aou | ||
| :status: draft | ||
| :safety: ASIL_B | ||
| :security: NO |
There was a problem hiding this comment.
Requirements have security set, but not the document header?
| :status: valid | ||
| :safety: ASIL_B | ||
| :implements: logic_arc_int__os__libcpp | ||
| :security: NO |
docs/modules/os/docs/index.rst
Outdated
| Its components are modelled in S-CORE to be able to describe dependencies of S-CORE features to | ||
| this external component. | ||
| As it is external to S-CORE, the (folder/file) structure of the documentation may be different from the other modules. | ||
| Its main content is the POSIX operating system environment (sometimes also already called a "SW platform"). |
There was a problem hiding this comment.
POSIX is not an environment, but an interface.
There was a problem hiding this comment.
removed here, added reference to POSIX in os/docs/requirements/index.rst
| :safety: ASIL_B | ||
| :status: valid | ||
|
|
||
| If the system using the SW-platform has safety goals, the used os module shall offer the following functions in a safe way: |
There was a problem hiding this comment.
What means "safe way" ?
There was a problem hiding this comment.
tried a reformulation
| - filesystem access (data integrity of read-only-memory) | ||
| - DMA | ||
| - IPC communication primitives (shared memory and message passing) | ||
| - C++ standard library (according to Iso 14882) |
| - C++ standard library (according to Iso 14882) | ||
| - C library | ||
| - math library | ||
| - time source |
There was a problem hiding this comment.
time source is unclear. It could be an hardware clock or date/time ... Is this monotonic ?
There was a problem hiding this comment.
reformulated
|
It says that it resolves #536, but I am not sure if we also handle the fact that the Operating System will put requirements and assumptions of use to the platform and the modules. How do we handle this. To my perspective when we put AoUs on the OS and the OS fulfills it, it may indicate wrong impression that we are "safe" as we actually miss the AoUs in the other direction. |
The "expected" generic AoU from any OS to S-CORE are documented in https://eclipse-score.github.io/score/pr-2515/modules/os/docs/requirements/aou_req.html. As we cannot provide the "specific" ones (at least for QNX), this is an AoU to the user: https://eclipse-score.github.io/score/pr-2515/requirements/platform_assumptions/index.html#aou_req__platform__safety_integration |
aschemmel-tech
force-pushed
the
aschemmel-tech-add-os-integration
branch
from
3e8b2b3 to
f970bfc
Compare
aschemmel-tech
force-pushed
the
aschemmel-tech-add-os-integration
branch
from
f970bfc to
bd20942
Compare
|
PR was presented and accepted in the architecture and process community - improvement proposal see next commit |
6 participants
Resolves: #536