Skip to content

Conversation

@aschemmel-tech
Copy link
Contributor

Resolves: #1740

@github-actions
Copy link

⚠️ Docs-as-Code version mismatch detected
Please check the CI build logs for details and align the documentation version with the Bazel dependency.

@github-actions
Copy link

The created documentation from the pull request is available at: docu-html

@aschemmel-tech aschemmel-tech marked this pull request as ready for review October 22, 2025 11:01
This includes to make sure the OS safety functions S-CORE needs matches with the OS provided ones (as in :need:`aou_req__platform__os_safety_functions`)
and to make sure the AoUs relevant for these functions (as in :need:`aou_req__platform__os_safety_aou`) are fulfilled by the S-CORE SW platform.

Note1: A list of OS safety functions needed is compiled by the S-CORE project here (TBD).
Copy link
Contributor

Choose a reason for hiding this comment

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

May refer to aou_req__platform__os_safety_features, there is the same note?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Correct: aou_req__platform__os_safety_features is now a duplicate, missed to delete it.


Note2: The integrator can expect that for the reference OS this AoU is fulfilled by S-CORE SW Platform already.

.. aou_req:: integrator safety anomaly reporting
Copy link
Contributor

Choose a reason for hiding this comment

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

Cosmetic: Start with big letter, Integrator

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok

In this section assumptions are described which need to be fulfilled by the applications running on top of the SW platform.

TBD
.. aou_req:: integrator safety aou
Copy link
Contributor

Choose a reason for hiding this comment

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

Cosmetic: Start with big letter, Integrator

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok


The integrator shall describe in his safety manual (or similar document) the AoUs which need to be covered by the user (applications) for all the components (incl. the OS) he integrates.

Note: The integrator can expect that for the reference OS this AoU is fulfilled by S-CORE SW Platform already.
Copy link
Contributor

Choose a reason for hiding this comment

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

reference OS is mentioned several times, would it be not better to add a link to where is this defined?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok, linked

:status: valid

The OS supplier shall provide all the levels AoUs in a safe way (i.e. the "safety" attribute will be raised to the level in this AoU).
The OS supplier and integrator shall provide all the levels AoUs in a safe way (i.e. the "safety" attribute will be raised to the level in this AoU).
Copy link
Contributor

Choose a reason for hiding this comment

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

do we have any os supplier which gives us the AoUs?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is the AoU on the integrator to ensure that the OS AoUs are followed: aou_req__platform__os_safety_features - he needs to license the OS for commercial use and aquire its Safety Manual.

@aschemmel-tech aschemmel-tech force-pushed the aschemmel-tech-os-integrator-aou branch from 6f9ff74 to 2aee1ae Compare October 23, 2025 09:12
Copy link
Contributor

@qor-lb qor-lb left a comment

Choose a reason for hiding this comment

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

@aschemmel-tech thanks for the update - however, I believe there’s been a misunderstanding of the original intent described in the comment on issue #1691.

The intention was that S-CORE itself performs the OS integration and therefore provides corresponding guarantees for the supported OSes (based on its tier). In the current wording, the responsibility for OS integration and related AoUs is placed on the integrator using S-CORE, which effectively reverses the intended responsibility model.

To clarify the rationale behind this:

  • S-CORE is defined as a SEooC that spans the middleware level. As such, we want to demonstrate that, when placed into context, it adheres to the safety manual of the underlying OS. Therefore, S-CORE itself should perform the integration with the OS as part of its scope, not delegate it outward. This integration establishes the confidence argument that S-CORE behaves correctly when used on the supported OSes (for Tier 1).
  • The functional responsibility for performing and validating this integration lies with S-CORE (for Tier 2 & 1, not for Tier 3).
  • External integrators or customers would only need to demonstrate equivalence or report deviations if they choose a non-reference OS or make local adaptations.

Copy link
Contributor Author

@aschemmel-tech aschemmel-tech left a comment

Choose a reason for hiding this comment

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

Hello @qor-lb : In my last commit I tried to sharpen the AoU descriptions, but I think it (already) matches your intention. For example aou_req__platform__os_safety_matching : "The Integrator shall integrate the SW platform with an OS providing safety functions ... Note2: ... for the safe S-CORE reference OS this AoU is fulfilled by S-CORE SW Platform already"
I would not agree to your statement "S-CORE ... provides corresponding guarantees" - we cannot give guarantees, therefore we also do not "qualify" the SW platform SEooC. This must be done by the integrator "in context".
The work that we in S-CORE do to integrate the OS I think we need to document in a Feature like "OS integration", where we for example also document a decision if we want to have an OS abstraction level. But this I think is rather a topic for the architects community.
In case you cannot approve still, I propose you invite me to a Tech or Project lead circle to discuss.

@aschemmel-tech aschemmel-tech force-pushed the aschemmel-tech-os-integrator-aou branch from 8d1a219 to 486afc6 Compare October 28, 2025 15:48
@aschemmel-tech aschemmel-tech requested a review from ramceb October 31, 2025 07:13
Copy link
Contributor Author

@aschemmel-tech aschemmel-tech left a comment

Choose a reason for hiding this comment

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

Based on a discussion with @ramceb, I will adapt the "roles" used in the AoU.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Change Request: Tiered SW Platform (Operating System) Integration Process for Eclipse S-CORE

5 participants