Meta Feature Request: Platform request

[odra]

Eclipse S-CORE Platform Request Proposal

Background and Problem Statement

Eclipse S-CORE is raising interest from several platform/OS vendors and these need to be properly on-boarded into the project.

There is no predefined path to request or on-board platforms into S-CORE, while the project tunnel all requirements via feature requests, platform support does not necessarily mean that a feature request (i.e s-core module source code changes) are needed.

New Request Type: Platform Request

I would like to propose a new type of request, a "Platform Request" if you will, that would allow OS/Hypervisor vendors to describe their intent of supporting S-CORE in their platform in a formal process within the project.

This request type would need to be formalized within the project, where platform providers/vendors would need file a request, in a similar way there is one for requesting a new feature within s-core, but indicating what's required to a platform in s-core:

• Impacted areas or modules (Libs, FS operations, RT, Orchestration, etc)
• Platform Family (RTOS, Linux distro, Hypervisor, etc)
• Any supported standards such as POSIX
• Is it a Functional Platform (QM, no AoU) or a Production Platform (provides an AoU)
• ...

S-CORE Premises

I think we also need to have clear definitions and terms about platform types, targets, etc:

• Boundaries of a Platform
• Distinction between Development, Functional and Production platforms
• Platform Architectures (x86, amd, aarch64, etc)

[odra]

@opajonk @qor-lb

[masc2023]

Please check https://eclipse-score.github.io/score/pr-1490/platform_management_plan/change_management.html,
Change Request can include not only new Feature, but also modifications and new/modified Component Requests.

The name platform is already used in our Building Block Model, see here, https://eclipse-score.github.io/process_description//main/general_concepts/score_building_blocks_concept.html, and should not be used for other purposes. If the templates are not fitting, we can discuss to update them.

[opajonk]

@masc2023 This ticket is an outcome of a discussion that is going on for some time (I think since the last F2F Architecture Workshop, maybe longer) and that came up again yesterday (cf. these meeting minutes, "to 3."). The point of the discussion is that there is no defined way to onboard new platforms. While @odra created an FR for AutoSD already some time ago, the discussion went to the point that "supported platforms" are not features (or change requests for existing features) - but still they are "something of high relevance to S-CORE" for sure. Due to this discussion, for example, I refrained from creating a similar FR for EB corbos Linux for Safety Applications. It would not have added much value to the discussion.

The discussion uses the term "platform" in the sense of #1541 (host, target, production platform for S-CORE, i.e. "on which S-CORE stands"). I think the meta-model uses the term platform quite to the opposite (S-CORE being "the platform" that is developed as SEooC, "on which applications stand"). However, also there it has dual use: "[...] for reference hardware platforms.", so I think it is really good that you point out the meta-model. The term seems to be confusing, and therefore it will be very helpful to "have clear definitions and terms about platform". Both usages are valid, but they take different viewpoints.

In addition, I think it will be required to agree on what it means that "S-CORE supports platform X" - and what it does not mean. For example:

• Will we add non-functional requirements such as: compatibility (e.g. a defined set of several compilers)?
• Will we add integration tests which shall pass on "target" and "production" platforms? (again: terms in the sense of docs: sth_req for supported target platforms #1541!)?
• Will we measure and ensure performance on defined hardware platform(s), or is this beyond the capabilities of an open source project?

[pahmann]

Adding some thoughts here triggered in today's process community working slot:

We need to distinguish between two parts:

1. Anything which will be later on integrated into a reference system which is part of the CI. With the feature request for AutoSD, which is also in incubation phase to become an Eclipse SDV project, this becomes an "OS layer" for our reference integration next to QNX
2. Operating system support by S-Core or better Operating Systems to which S-Core gets deployed, which are coming without support*.

An essential element will be the flexibility to adjust/change the compiler or compiler options. Reasoning is that packages of an Operating System distribution typically come with properly compiled packages. While we may have less influence on x86 consumer electronics by using a package which was not originally developed for this specific OS distribution, it is a different case when we are talking about functional safety. Here a match on libary versions and compiler version and settings improve the argument of the SEooC. Of course when re-compiled with different options we need to make sure that artifacts are available again like test reports and nothing is simply taken from S-Core.

This also implies that it may be a limited amount of OS flavors and compiler settings can be supported by the open source S-Core project. Bringing S-Core on top of any specific Operating System flavor may be in the responsibility of distributors or service providers. Of course we should also consider the case that OS providers can become maintainer of a specific flavor in the CI infrastructure of S-Core. However, again it is important to state that S-Core as such is the middleware layer which tries to be OS independent where possible, although this may not be fully possible e.g. due to dependencies to specific math libraries or other libraries.

Looking into an addition to QNX, even if not safety certified, as a development vehicle (or for later production in case a distributor decides so) is a valid and good option. Even with certain license terms of a community edition for person use for QNX a Linux version may be easier as no QNX account need to be created and no specific license terms of use that need to be evaluated before use.

*Note: We are also not promising support on System Level for the reference integration and just are having "best effort" approach also for QNX and

[opajonk]

Agreed. Just to be clear: I see EB corbos Linux for Safety Applications on the "OS layer for our reference integration next to QNX". The integration already works (cf. demo/ proof of concept here, as demonstrated last Monday in the Eclipse S-Core Project Office Hours). As said I simply have refrained from opening yet another ticket as long as the way forward is not clarified.

[odra]

Don't you need to provide an AoU doc or safety manual to claim it can be used as a "production platform"?

[opajonk]

Don't you need to provide an AoU doc or safety manual to claim it can be used as a "production platform"?

Well, the linked PR describes already on a high level what you can / can not do. This gives a good indication what needs to be followed.

[qor-lb]

Proposal: Tiered Platform Integration Process for Eclipse S-CORE

Note

This is a first draft created with @odra @opajonk

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 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), 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)
  • Operational Community (responsible for infrastructure), 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 (due to the potential impact to fulfil the AoUs), safety / security (due to potential impact on the safety & security concept), 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
    • docs: sth_req for supported target platforms #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

  • Meta Feature Request: Platform request #1691
  • docs: sth_req for supported target platforms #1541

Relation to Change management.