---
# System prepended metadata

title: 'Proposal: Tiered Platform Integration Process for Eclipse S-CORE'

---

# Proposal: Tiered Platform Integration Process for Eclipse S-CORE
## Motivation
* Currently, in Eclipse S-CORE, there is no sufficient answer to these questions
    * Which platforms shall the software created in Eclipse S-CORE run on?
    * Which service level can a consumer (user/integrator) assume for a platform?
    * Which service level is required by a platform provider?
    * How to onboard a new platform?

## Proposed Tier Model 
Use a three-tiered approach simiar to [the Rust Tier model for platform support](https://doc.rust-lang.org/beta/rustc/platform-support.html) to describe the different service and support levels of platforms. The Tiers are consecutive, i.e. you must enter Tier 3 before entering Tier 2. Entering a Tier and staying in a tier has well-defined criteria.

### Tier 3: "In Tree, Best Effort"
* **Purpose:** This is the entry point for new platforms. It has a low entry barrier (for the platform), and a low hurdle to accept (for S-CORE).
* **Description:**
    * An entry point of the platform is linked to from S-CORE, as "Tier 3".
    * Building and running is enabled, but no pro-active support from S-CORE is provided for e.g. build or test problems.
    * No guarantees that S-CORE builds or runs on the platform.
* **Minimal Requirements:**
    * Unique, consistent naming of the platform (e.g. the ["target triple" for Rust compiler](https://doc.rust-lang.org/beta/rustc/platform-support.html)), a Bazel target for this in S-CORE.
    * One responsive representative to reach out to for questions.
    * Avoid legal/licensing issues for the platform. For example, it is not acceptable to effectively require someone in order to even build S-CORE for this platform, "please contact purchasing". The platform must be able to build openly.
    * Documentation how to build for the platform and run tests on the platform must be openly available.
    * The introduction of the platform cannot break higher-Tier platforms. In case of conflicts, higher-Tier platforms are preferred.
        
### Tier 2: "Guaranteed to Work"
* **Purpose:** S-CORE builds consistently for the platform and functionality is ensured via inclusion into the Continuous Integration infrastructure.
* **Description:**
    * Continuous Integration ensures that S-CORE builds for the platform and test suites pass after each change in integration repository (see [DR-002-Infra: Integration Testing in a Distributed Monolith](https://eclipse-score.github.io/score/main/design_decisions/DR-002-infra.html))
    * [Operational Community](https://github.com/orgs/eclipse-score/discussions/categories/operational-community) (responsible for infrastructure), [Architecture Community](https://github.com/orgs/eclipse-score/discussions/categories/architecture-community) and Integration community/team must approve the promotion to Tier 2, since it requires effort on their side to maintain the platform in S-CORE
    * (Maybe also Technical Lead approval? Rationale?)
* **Minimal Requirements:**
    * Components of the latest mainline are passing all integration tests (?)
    * The platform or a good emulation of it must be openly available for S-CORE to execute the CI and tests on. Functional test suites must pass in CI.
    * At least two experts available for the integration team (more than one contact point)
    * Impact analysis of the platform onto S-CORE available
        * Does the platform impact the S-CORE initialization process?
        * Does the platform impact process orchestration?
        * Short: Is there any impact on the existing features? (differentiate between functional and non-functional / quality impact, e.g. performance; i.e. "it works" vs "it works well")

### Tier 1: "Guaranteed to be Certifiable"
* **Purpose:** In addition to Tier 2, the platform and S-CORE have aligned safety/security concepts.
* **Description:**
    * This is the highest level of integration. Documentation is provided showing that S-CORE fulfills the platform’s Assumptions of Use (AoUs).
* **Minimal Requirements:**
    * CI builds **and** full test suite (functional & safety/security relevant) must pass.
    * Analysis of the platform
        * Does a platform contradict any existing AoUs of other Tier 1 platforms?
        * Does the new platform require architectural changes to be supported as Tier 1?
        * Open question: What happens if there are contradicting requirements?
    * Approval by [Architecture Community](https://github.com/orgs/eclipse-score/discussions/categories/architecture-community) (due to the potential impact to fulfil the AoUs), safety / security (due to potential impact on the safety & security concept), [Testing Community](https://github.com/orgs/eclipse-score/discussions/categories/testing-community) (since there may be additional tests required)
    * (Maybe also Technical Lead approval? Rationale?)
 
## Considerations
* We propose to exclude specific hardware from these Tiers for now.
    * It is unclear what this would mean for the Tiers ("Must a Tier X platform run on HW Y? What if the HW supplier does not support this and the vendor of Tier X platform simply cannot support this?"). Who and where HW is hosted? Who does that? Support?
    * Might be something the platform provider to support and bring to the table but is not part of a s-core platform defintion.
    * This may be simply an orthogonal topic.
            
* To a lesser degree: the term platform is already used with at least two meanings:
    * S-CORE being the platform (for downstream consumers to use for creating applications on top of it):
        * https://eclipse-score.github.io/score/main/platform_management_plan/project_management.html#platform-structure
        * https://eclipse-score.github.io/process_description/main/general_concepts/score_building_blocks_concept.html
    * The execution environment (operating system / hardware / ...) that S-CORE runs on being the platform:
        * https://eclipse-score.github.io/score/main/features/analysis-infra/logging/docs/glossary.html#term-platform
        * https://github.com/eclipse-score/score/pull/1541
        * https://github.com/eclipse-score/bazel_platforms
* Use "platform" in only one of the meanings.
    * Proposal is the one that the Glossary uses, since that is the S-CORE-centric view and will likely be used more often in this way; it seems more intuitive. For the consumer point of view, use the term "S-CORE" or "framework" or ...?

* References
    * https://github.com/eclipse-score/score/issues/1691
    * https://github.com/eclipse-score/score/pull/1541


Relation to Change management.