-
Notifications
You must be signed in to change notification settings - Fork 94
OS tier levels + AutoSD as a community OS #2266
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.
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,25 @@ | ||
| .. | ||
| # ******************************************************************************* | ||
| # Copyright (c) 2025 Contributors to the Eclipse Foundation | ||
| # | ||
| # See the NOTICE file(s) distributed with this work for additional | ||
| # information regarding copyright ownership. | ||
| # | ||
| # This program and the accompanying materials are made available under the | ||
| # terms of the Apache License Version 2.0 which is available at | ||
| # https://www.apache.org/licenses/LICENSE-2.0 | ||
| # | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
| # ******************************************************************************* | ||
|
|
||
| .. _comp_doc_os_certifiable: | ||
|
|
||
| Certifiable Level | ||
| ################# | ||
|
|
||
| These are the certifiable-supported Operating Systems for Eclipse S-CORE. | ||
|
|
||
| See see :ref:`platform_assumptions` for the exact requirements for each level (Tier). | ||
|
|
||
|
|
||
|
|
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,188 @@ | ||
| .. | ||
| # ******************************************************************************* | ||
| # Copyright (c) 2025 Contributors to the Eclipse Foundation | ||
| # | ||
| # See the NOTICE file(s) distributed with this work for additional | ||
| # information regarding copyright ownership. | ||
| # | ||
| # This program and the accompanying materials are made available under the | ||
| # terms of the Apache License Version 2.0 which is available at | ||
| # https://www.apache.org/licenses/LICENSE-2.0 | ||
| # | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
| # ******************************************************************************* | ||
|
|
||
| .. comp:: AutoSD | ||
| :id: comp__os_autosd | ||
| :security: YES | ||
| :safety: QM | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Looks from module cope now strange. QM inside ASIL module.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But it is correct and as intended, as AutoSD applies not for Certifiable level
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My understanding of this would be: "If you integrate S-CORE on AutoSD, at the moment all you can expect is a QM system". Disclaimer: same would be true for EB corbos Linux for Safety Application right now, until we successfully qualify for the highest integration level, as described in the PR. This is a step-by-step process, which is totally reasonable, and not how we start off.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Or it is another module and dont fit into the OS.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As comment above, not a problem, it shows exactly the status and any safety engineer will easily see, that AutoSD can not used currently in safety-critical context
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But it is against our process requirements, so maybe we have an process issue. See gd_req__arch_linkage_safety_trace. The module OS is defined as ASIL_B and is an architectural element (see gd_req__arch_build_blocks). Therefore linking an QM element will be against this requirement.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Your rules does not consider yet https://eclipse-score.github.io/score/pr-2266/requirements/platform_assumptions/index.html#aou_req__platform__integration_assistance, where it is allowed to deviate, if you want only to deliver on Community Level, so that is SCORE specific tailoring of the general process
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure, what "The supplier shall provide a contact point for integration assistance." have to do with this. But it might be another AOU. But nevertheless it would mean, that our docs as code which will implement the enforcement of this rule by sphinx-needs tests have to be modified or deactivated within S-CORE project scope. Right ?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I talked with the docs_as_code colleagues. They will implement the checks (leads to built errors) and there is currently no possibility implemented and anyhow foreseen to overrule that from the project. They follow currently only the process requirements. |
||
| :status: valid | ||
| :implements: aou_req__platform__integration_assistance, aou_req__platform__os_integration_manual, aou_req__platform__bug_interface | ||
|
|
||
| AutoSD | ||
| ###### | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @odra there seems some documentation issue in this file, otherwise for me it looks now fine
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it's showing a warning (future error) for
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure the error is "/home/runner/work/score/score/docs/modules/os/operating_systems/docs/community/autosd.rst:23: WARNING: Duplicate explicit target name: "upstream documentation". [docutils]"
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @masc2023 ok, I fixed it |
||
|
|
||
| AutoSD is the upstream binary distribution that serves as the public, in-development preview and functional precursor | ||
| of the Red Hat In-Vehicle Operating System (OS). | ||
|
|
||
| AutoSD is downstream of CentOS Stream, so it retains most of the CentOS Stream code with a few divergences, | ||
| such as an optimized automotive-specific kernel rather than CentOS Stream's kernel package. | ||
|
|
||
| Red Hat In-Vehicle OS is based on both AutoSD and RHEL, both of which are downstreams of CentOS Stream. | ||
|
|
||
| OS Maintainers/Integration Assistance | ||
| ----------------------------------------- | ||
|
|
||
| GitHub Handles of the target maintainers. | ||
|
|
||
| - Leonardo Rossetti - @odra | ||
|
|
||
| Integration Assistance | ||
| ---------------------- | ||
|
|
||
| The following fulfills :need:`aou_req__platform__integration_assistance` | ||
|
|
||
| +----------------+-----------------------------+ | ||
| | .. centered:: Leonardo Rossetti | | ||
| +----------------+-----------------------------+ | ||
| | Github Handler | @odra | | ||
| +----------------+-----------------------------+ | ||
| | Slack Handler | @lrossett | | ||
| +----------------+-----------------------------+ | ||
|
|
||
|
|
||
| Integration Manual | ||
| ------------------ | ||
|
|
||
| The following fulfills :need:`aou_req__platform__os_integration_manual` | ||
|
|
||
|
|
||
| Supported Architectures | ||
| ^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
|
||
| +----------------------+----------------------------+ | ||
| | Target Architecture | Comments | | ||
| +----------------------+----------------------------+ | ||
| | x86_64 | Native Only | | ||
| +----------------------+----------------------------+ | ||
| | aarch64 | Native Only | | ||
| +----------------------+----------------------------+ | ||
|
|
||
|
|
||
| Build Instructions | ||
| ^^^^^^^^^^^^^^^^^^ | ||
|
|
||
| Building an AutoSD image can be done by using `aib <https://gitlab.com/CentOS/automotive/src/automotive-image-builder>`_. | ||
|
|
||
| Sample usage: | ||
|
|
||
| .. code:: bash | ||
|
|
||
| export OCI_IMAGE=localhost/score:latest | ||
| export AIB_DISTRO=autosd10-sig | ||
|
|
||
| aib build-builder --distro ${AIB_DISTRO} | ||
| aib build --target qemu --distro ${AIB_DISTRO} image.aib.yml ${OCI_IMAGE} | ||
| aib to-disk-image ${OCI_IMAGE} autosd-score.qcow2 | ||
|
|
||
| As an alternative, you can replace the bare metal "aib" usage with a bash script that runs the tool inside an OCI container: | ||
|
|
||
| .. code:: bash | ||
|
|
||
| curl -o auto-image-builder.sh "https://gitlab.com/CentOS/automotive/src/automotive-image-builder/-/raw/main/auto-image-builder.sh" | ||
| chmod +x auto-image-builder.sh | ||
|
|
||
| You can then replace the usage of "aib" with "auto-image-builder.sh" (requires sudo): | ||
|
|
||
| .. code:: bash | ||
|
|
||
| export OCI_IMAGE=localhost/score:latest | ||
| export AIB_DISTRO=autosd10-sig | ||
| # set the container storage to the local "_builder" directory to avoid permissions issues | ||
| export AIB_LOCAL_CONTAINER_STORAGE=$PWD/_build/containers-storage | ||
|
|
||
| sudo -E ./auto-image-builder.sh build-builder --distro ${AIB_DISTRO} | ||
| sudo -E ./auto-image-builder.sh build --target qemu --distro ${AIB_DISTRO} image.aib.yml ${OCI_IMAGE} | ||
| sudo -E ./auto-image-builder.sh to-disk-image ${OCI_IMAGE} autosd-score.qcow2 | ||
|
|
||
| If using QEMU, you can run the image using the following command: | ||
|
|
||
| .. code:: bash | ||
|
|
||
| /usr/bin/qemu-system-x86_64 \ | ||
| -drive file=/usr/share/OVMF/OVMF_CODE_4M.fd,if=pflash,format=raw,unit=0,readonly=on \ | ||
| -drive file=/usr/share/OVMF/OVMF_VARS_4M.fd,if=pflash,format=raw,unit=1,snapshot=on,readonly=off \ | ||
| -enable-kvm \ | ||
| -m 2G \ | ||
| -smp $(nproc) \ | ||
| -machine q35 \ | ||
| -cpu host \ | ||
| -device virtio-net-pci,netdev=n0 \ | ||
| -netdev user,id=n0,hostfwd=tcp::2222-:22 \ | ||
| -daemonize \ | ||
| -display none \ | ||
| -drive file=disk.qcow2,index=0,media=disk,format=qcow2,if=virtio,id=rootdisk,snapshot=off | ||
|
|
||
| Toolchain | ||
| ^^^^^^^^^ | ||
|
|
||
| Refer to the `upstream toolchiain repository <https://github.com/eclipse-score/inc_os_autosd/tree/main/toolchain>`_ for detailed instructions. | ||
|
|
||
| A Bazel toolchain defintion is provided for users to build their Bazel modules and components with AutoSD's tooling (compilers, libraries, etc). | ||
|
|
||
| Sample usage (MODULE.bazel file): | ||
|
|
||
| .. code:: starlark | ||
|
|
||
| # Use local path during development, or git_override for published versions | ||
| local_path_override( | ||
| module_name = "os_autosd", | ||
| path = "/path/to/inc_os_autosd/" | ||
| ) | ||
|
|
||
| bazel_dep(name = "os_autosd", version = "1.0.0") | ||
|
|
||
| # Configure AutoSD 9 GCC toolchain | ||
| autosd_10_gcc = use_extension("@os_autosd//toolchain/autosd_10_gcc:extensions.bzl", "autosd_10_gcc_extension") | ||
| autosd_10_gcc.configure( | ||
| c_flags = ["-Wall", "-Wno-error=deprecated-declarations", "-Werror", "-fPIC"], | ||
| cxx_flags = ["-Wall", "-Wno-error=deprecated-declarations", "-Werror", "-fPIC"], | ||
| ) | ||
|
|
||
| use_repo(autosd_10_gcc, "autosd_10_gcc_repo") | ||
| register_toolchains("@autosd_10_gcc_repo//:gcc_toolchain_linux_x86_64") | ||
|
|
||
| **NOTE:** AutoSD's tooling does not support cross compilation. | ||
|
|
||
| Mixed Critical Orchestration | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
|
||
| Refer to the `upstream CentOS automotive documentation <https://sigs.centos.org/automotive/features-and-concepts/con_mixed-criticality/>`_ for detailed information. | ||
|
|
||
| Mixed Critical Orchestration, aka MCO, can be achieved with the following components: | ||
|
|
||
| * Systemd: the init system that is responsible for workload orchestration | ||
| * Eclise BlueChi: extends Systemd to enable multi-node and multi domain orchestration | ||
| * QM: Quality management environment that is composed of two sub-systems: a dedicated rootfs partition + container isolation | ||
|
|
||
| ASIL and QM connectivity is done either via an IPC socket or shared memory (/dev/shm). | ||
|
|
||
| .. image:: _assets/autosd-mco.png | ||
| :align: center | ||
|
|
||
| Bug Interface | ||
| ------------- | ||
|
|
||
| The following fulfills :need:`aou_req__platform__bug_interface` | ||
|
|
||
| +------------------------------------+---------------------------------------------------------------------------+ | ||
| | | | ||
| +------------------------------------+---------------------------------------------------------------------------+ | ||
| | CentOS SIG Automotive Mailing List | https://lists.centos.org/hyperkitty/list/automotive-sig@lists.centos.org/ | | ||
| +------------------------------------+---------------------------------------------------------------------------+ | ||
| | Gitlab Issue Tracker | https://gitlab.com/CentOS/automotive/sig | | ||
| +------------------------------------+---------------------------------------------------------------------------+ | ||
| | CentOS SIG Matrix Channel | https://app.element.io/#/room/#centos-automotive-sig:fedoraproject.org | | ||
| +------------------------------------+---------------------------------------------------------------------------+ | ||
| | Eclipse SDV Slack Channel | #autosd (https://sdvworkinggroup.slack.com/archives/C0986LJ9EJH) | | ||
| +------------------------------------+---------------------------------------------------------------------------+ | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,27 @@ | ||
| .. | ||
| # ******************************************************************************* | ||
| # Copyright (c) 2025 Contributors to the Eclipse Foundation | ||
| # | ||
| # See the NOTICE file(s) distributed with this work for additional | ||
| # information regarding copyright ownership. | ||
| # | ||
| # This program and the accompanying materials are made available under the | ||
| # terms of the Apache License Version 2.0 which is available at | ||
| # https://www.apache.org/licenses/LICENSE-2.0 | ||
| # | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
| # ******************************************************************************* | ||
|
|
||
| .. _comp_doc_os_community: | ||
|
|
||
| Community Level | ||
| ############### | ||
|
|
||
| .. toctree:: | ||
| :titlesonly: | ||
|
|
||
| autosd.rst | ||
|
|
||
| These are the community-supported Operating Systems for Eclipse S-CORE. | ||
|
|
||
| See see :ref:`platform_assumptions` for the exact requirements for each level (Tier). |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| .. | ||
| # ******************************************************************************* | ||
| # Copyright (c) 2025 Contributors to the Eclipse Foundation | ||
| # | ||
| # See the NOTICE file(s) distributed with this work for additional | ||
| # information regarding copyright ownership. | ||
| # | ||
| # This program and the accompanying materials are made available under the | ||
| # terms of the Apache License Version 2.0 which is available at | ||
| # https://www.apache.org/licenses/LICENSE-2.0 | ||
| # | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
| # ******************************************************************************* | ||
|
|
||
| .. _comp_doc_os_functional: | ||
|
|
||
| Functional Level | ||
| ################ | ||
|
|
||
| These are the functional-supported Operating Systems for Eclipse S-CORE. | ||
|
|
||
| See see :ref:`platform_assumptions` for the exact requirements for each level (Tier). |
|
qor-lb marked this conversation as resolved.
qor-lb marked this conversation as resolved.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please update the codeowners file to include the TLs as intermediate reviewers until all the different representatives from the communities that need to approve have been defined: https://github.com/eclipse-score/score/blob/main/.github/CODEOWNERS#L34C1-L34C81
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,65 @@ | ||
| .. | ||
| # ******************************************************************************* | ||
| # Copyright (c) 2025 Contributors to the Eclipse Foundation | ||
| # | ||
| # See the NOTICE file(s) distributed with this work for additional | ||
| # information regarding copyright ownership. | ||
| # | ||
| # This program and the accompanying materials are made available under the | ||
| # terms of the Apache License Version 2.0 which is available at | ||
| # https://www.apache.org/licenses/LICENSE-2.0 | ||
| # | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
| # ******************************************************************************* | ||
|
|
||
| .. _comp_doc_os: | ||
|
|
||
| Operating Systems | ||
| ================= | ||
|
|
||
| .. toctree:: | ||
| :maxdepth: 2 | ||
| :hidden: | ||
|
|
||
| onboarding/index | ||
| community/index | ||
| functional/index | ||
| certifiable/index | ||
|
|
||
| An operating system is an environment on which S-CORE is integrated and executed. | ||
|
|
||
| In the context of the OS module, **S-CORE acts as the operaring system integrator**: | ||
| S-CORE maintainers integrate and validate specific OS environments as S-CORE | ||
| reference operating systems and document the practical usage for downstream users. | ||
|
|
||
| Operating Systems are categorized into the following **levels**: | ||
|
|
||
| * **Community Level**: integrated on a best-effort basis. S-CORE provides **no guarantees** | ||
| that the operating system builds or runs reliably. | ||
| * **Functional Level**: S-CORE provides **functional guarantees** (build + tests for the | ||
| reference integration). | ||
| * **Certifiable Level**: S-CORE provides **certifiability-oriented guarantees** for the | ||
| reference integration and documents additional safety/security expectations. | ||
|
|
||
| The concrete level requirements are defined in :ref:`platform_assumptions`. | ||
|
|
||
| Roles and Responsibilities | ||
| -------------------------- | ||
|
|
||
| Operating system integrations follow the process requirements defined in: | ||
| :ref:`platform_assumptions`. | ||
|
|
||
| Two roles from the process requirements are relevant: | ||
|
|
||
| * **Supplier**: provides an external SW element (e.g. OS / hypervisor) that S-CORE uses. | ||
| * **System Integrator**: integrates the S-CORE operring system into a system. | ||
|
|
||
| In the S-CORE Software Platforms, these roles map to: | ||
|
|
||
| * **OS Maintainer** (Supplier role): resolves the *supplier* requirements. | ||
| The OS maintainer provides the prerequisites so that the OS can be considered | ||
| for promotion to a level. | ||
|
|
||
| * **S-CORE** (System Integrator role): resolves the *system integrator* requirements. | ||
| Once S-CORE accepts an OS at **Functional** or **Certifiable** level, S-CORE | ||
| must ensure that the accepted guarantees remain valid across all increments. | ||
|
odra marked this conversation as resolved.
|
||

Uh oh!
There was an error while loading. Please reload this page.