vso: create initial draft feature request [#2597]

[basheerFZ]

vso: create initial draft feature request [#2597]

[github-actions]

⚠️ 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]

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

[FScholPer]

please move that to lifecycle and health and change to the type feature modification. OCI is already part the requirements of lifecycle & health: https://eclipse-score.github.io/score/main/features/lifecycle/index.html and sandboxing also

[FScholPer]

@qor-lb how to continue here now?

[FScholPer]

docu looks broken:

[basheerFZ]

docu looks broken:

We have fixed the issue we can see now all the checks have passed, thanks for enabling the copyright check.

[github-actions]

This PR is stale because it has been open for 30 days with no activity. It will be closed in 10 days if no further activity occurs. #magic___^_^___line

[daeyoung-jeong-lge]

This PR is stale because it has been open for 30 days with no activity. It will be closed in 10 days if no further activity occurs. #magic___^_^___line

We are still in discussion regarding this PR.

[masc2023]

We use svg images including drawio model as standard

[basheerFZ]

resolved with basheerFZ@45e11f3

[masc2023]

If this file is new, shall be 2026

[basheerFZ]

resolved with basheerFZ@45e11f3

[qor-lb]

Thank you very much for the substantial feedback. My feedback is at the architectural-fit level, so I'm raising it centrally rather than line-by-line.

The core question is whether VSO's value-add sits at the S-CORE middleware layer, or at the system-integration / application-framework layer - which in practice is OEM-specific. Reading the FR end-to-end, the parts that make VSO valuable (multi-node scenario awareness, scenario/pipeline contract definitions, cross-node determinism budgets, node-health aggregation) are things that, in a real integration, are established outside a single middleware instance. Two points:

1. Node health is built from the system, not from a single middleware instance on the Main Domain. An HPC node is typically composed of a Safety Island (Cortex-R) and a Main Domain (Cortex-A). The SI supervises the MD - which is why lifecycle/health has to be made reachable to the SI (rarely over Ethernet) - and the SI itself is supervised via watchdog. That chain is how the overall health of the "node" is actually established today. The node-level health and safe-placement semantics VSO wants to reason about are produced at the system level.

2. Health aggregation across pipelines spans multiple nodes and therefore multiple MW instances. As I understand it, VSO wants to monitor aggregated health across pipelines that may be deployed across different nodes, which in the real world usually also means across different middleware instances (S-CORE targets the MD, not the SI). The definition of those pipelines/task chains and their health reporting is an application-framework concern, and S-CORE already has e.g. FEO at that layer (task chains, an executor that traces/monitors execution, waypoint/timeout reporting. So my question is: was this cross-node / cross-instance pipeline-health aggregation already considered in the context of the FEO module? If yes, it would help to anchor the VSO discussion there; if no, that gap is worth understanding before introducing a separate VSO module.

To be constructive about direction: I would be supportive of S-CORE defining clean interfaces between Lifecycle, the application-framework layer, and an external scenario/state-orchestration layer - and of collaborating closely with the VSO team on that. What I'm not convinced of is pulling the VSO itself into core S-CORE.
These are genuinely important discussions, but they sit at the system-integration and application-framework level, which is largely OEM-specific - and I don't think they fit the current scope and priority of the platform.
My suggestion would be to pursue VSO as a partner project that showcases one S-CORE deployment, integrating via defined S-CORE interfaces, rather than as a core module. That keeps the collaboration and the learning, without committing the platform to OEM-specific system decisions at this stage.

[daeyoung-jeong-lge]

Thank you very much for the substantial feedback. My feedback is at the architectural-fit level, so I'm raising it centrally rather than line-by-line.

The core question is whether VSO's value-add sits at the S-CORE middleware layer, or at the system-integration / application-framework layer - which in practice is OEM-specific. Reading the FR end-to-end, the parts that make VSO valuable (multi-node scenario awareness, scenario/pipeline contract definitions, cross-node determinism budgets, node-health aggregation) are things that, in a real integration, are established outside a single middleware instance. Two points:

1. Node health is built from the system, not from a single middleware instance on the Main Domain. An HPC node is typically composed of a Safety Island (Cortex-R) and a Main Domain (Cortex-A). The SI supervises the MD - which is why lifecycle/health has to be made reachable to the SI (rarely over Ethernet) - and the SI itself is supervised via watchdog. That chain is how the overall health of the "node" is actually established today. The node-level health and safe-placement semantics VSO wants to reason about are produced at the system level.
2. Health aggregation across pipelines spans multiple nodes and therefore multiple MW instances. As I understand it, VSO wants to monitor aggregated health across pipelines that may be deployed across different nodes, which in the real world usually also means across different middleware instances (S-CORE targets the MD, not the SI). The definition of those pipelines/task chains and their health reporting is an application-framework concern, and S-CORE already has e.g. FEO at that layer (task chains, an executor that traces/monitors execution, waypoint/timeout reporting. So my question is: was this cross-node / cross-instance pipeline-health aggregation already considered in the context of the FEO module? If yes, it would help to anchor the VSO discussion there; if no, that gap is worth understanding before introducing a separate VSO module.

To be constructive about direction: I would be supportive of S-CORE defining clean interfaces between Lifecycle, the application-framework layer, and an external scenario/state-orchestration layer - and of collaborating closely with the VSO team on that. What I'm not convinced of is pulling the VSO itself into core S-CORE. These are genuinely important discussions, but they sit at the system-integration and application-framework level, which is largely OEM-specific - and I don't think they fit the current scope and priority of the platform. My suggestion would be to pursue VSO as a partner project that showcases one S-CORE deployment, integrating via defined S-CORE interfaces, rather than as a core module. That keeps the collaboration and the learning, without committing the platform to OEM-specific system decisions at this stage.

Thank you @qor-lb for the thoughtful architectural feedback.
We agree that external orchestration in an SDV system is largely OEM-specific.

Our point is that S-CORE, as an SDV platform, should still provide orchestration-relevant evidence through a consistent and formalized interface. Today, S-CORE includes many features, but their outputs are heterogeneous in format and semantics; as a result, orchestration-relevant evidence is not yet exposed consistently through a common interface.

From our perspective, VSO can serve as a consistency layer: collecting heterogeneous evidence across features and nodes, normalizing it, and exposing it to the OEM domain through a formal interface, with contract-enabling capabilities on top.

To be clear, we are not prescribing how each OEM should design its orchestration logic. That remains OEM-specific. What we are proposing is a stable S-CORE boundary so OEMs can integrate S-CORE predictably at system level.

If useful, we can align on concrete deliverables for this boundary:
(1) a common evidence model,
(2) clear aggregation semantics, and
(3) a contract/interface definition between S-CORE and OEM orchestration.

[basheerFZ]

Thank you very much for the substantial feedback. My feedback is at the architectural-fit level, so I'm raising it centrally rather than line-by-line.

The core question is whether VSO's value-add sits at the S-CORE middleware layer, or at the system-integration / application-framework layer - which in practice is OEM-specific. Reading the FR end-to-end, the parts that make VSO valuable (multi-node scenario awareness, scenario/pipeline contract definitions, cross-node determinism budgets, node-health aggregation) are things that, in a real integration, are established outside a single middleware instance. Two points:

1. Node health is built from the system, not from a single middleware instance on the Main Domain. An HPC node is typically composed of a Safety Island (Cortex-R) and a Main Domain (Cortex-A). The SI supervises the MD - which is why lifecycle/health has to be made reachable to the SI (rarely over Ethernet) - and the SI itself is supervised via watchdog. That chain is how the overall health of the "node" is actually established today. The node-level health and safe-placement semantics VSO wants to reason about are produced at the system level.
2. Health aggregation across pipelines spans multiple nodes and therefore multiple MW instances. As I understand it, VSO wants to monitor aggregated health across pipelines that may be deployed across different nodes, which in the real world usually also means across different middleware instances (S-CORE targets the MD, not the SI). The definition of those pipelines/task chains and their health reporting is an application-framework concern, and S-CORE already has e.g. FEO at that layer (task chains, an executor that traces/monitors execution, waypoint/timeout reporting. So my question is: was this cross-node / cross-instance pipeline-health aggregation already considered in the context of the FEO module? If yes, it would help to anchor the VSO discussion there; if no, that gap is worth understanding before introducing a separate VSO module.

To be constructive about direction: I would be supportive of S-CORE defining clean interfaces between Lifecycle, the application-framework layer, and an external scenario/state-orchestration layer - and of collaborating closely with the VSO team on that. What I'm not convinced of is pulling the VSO itself into core S-CORE. These are genuinely important discussions, but they sit at the system-integration and application-framework level, which is largely OEM-specific - and I don't think they fit the current scope and priority of the platform. My suggestion would be to pursue VSO as a partner project that showcases one S-CORE deployment, integrating via defined S-CORE interfaces, rather than as a core module. That keeps the collaboration and the learning, without committing the platform to OEM-specific system decisions at this stage.

@qor-lb --> Further to my colleagues response , additionally here is how we are envisaging the VSO as , hopefully this content will be able to give you the required understanding.

[FScholPer]

@basheerFZ I think the doc build is broken: Saving 0 parsed testcases to the cache score_xml_parser_cache.json in _build/.
/home/runner/work/score/score/docs/requirements/stakeholder/index.rst:1068: ERROR: Title overline & underline mismatch.

---

VSO Scenario Evidence Layer
---------------------------- [docutils]
/home/runner/work/score/score/docs/requirements/stakeholder/index.rst:1082: WARNING: Need could not be created: No ID defined, but 'needs_id_required' is set to True. [needs.create_need]
/home/runner/work/score/score/docs/features/vso/index.rst:249: WARNING: Title underline too short.

S-CORE Platform Architecture with VSO Integration
------------------------------------------------ [docutils]
/home/runner/work/score/score/docs/features/vso/index.rst:260: WARNING: Title underline too short.

VSO Architecture Details
----------------------- [docutils]
/home/runner/work/score/score/docs/features/vso/requirements/index.rst:78: WARNING: Need 'feat_req__vso__response_management' has unknown outgoing link 'stkh_req__vso__observability' in field 'satisfies' [needs.link_outgoing]
/home/runner/work/score/score/docs/features/vso/requirements/index.rst:101: WARNING: Need 'feat_req__vso__evidence_package_model' has unknown outgoing link 'stkh_req__vso__state_manager_integration' in field 'satisfies' [needs.link_outgoing]
looking for now-outdated files... none found
pickling environment... done
/home/runner/work/score/score/docs/features/communication/dds_gateway/index.rst: WARNING: document isn't included in any toctree [toc.not_included]
/home/runner/work/score/score/docs/features/vso/_assets/README.md: WARNING: document isn't included in any toctree [toc.not_included]

[basheerFZ]

@basheerFZ I think the doc build is broken: Saving 0 parsed testcases to the cache score_xml_parser_cache.json in _build/. /home/runner/work/score/score/docs/requirements/stakeholder/index.rst:1068: ERROR: Title overline & underline mismatch.

VSO Scenario Evidence Layer ---------------------------- [docutils] /home/runner/work/score/score/docs/requirements/stakeholder/index.rst:1082: WARNING: Need could not be created: No ID defined, but 'needs_id_required' is set to True. [needs.create_need] /home/runner/work/score/score/docs/features/vso/index.rst:249: WARNING: Title underline too short.

S-CORE Platform Architecture with VSO Integration ------------------------------------------------ [docutils] /home/runner/work/score/score/docs/features/vso/index.rst:260: WARNING: Title underline too short.

VSO Architecture Details ----------------------- [docutils] /home/runner/work/score/score/docs/features/vso/requirements/index.rst:78: WARNING: Need 'feat_req__vso__response_management' has unknown outgoing link 'stkh_req__vso__observability' in field 'satisfies' [needs.link_outgoing] /home/runner/work/score/score/docs/features/vso/requirements/index.rst:101: WARNING: Need 'feat_req__vso__evidence_package_model' has unknown outgoing link 'stkh_req__vso__state_manager_integration' in field 'satisfies' [needs.link_outgoing] looking for now-outdated files... none found pickling environment... done /home/runner/work/score/score/docs/features/communication/dds_gateway/index.rst: WARNING: document isn't included in any toctree [toc.not_included] /home/runner/work/score/score/docs/features/vso/_assets/README.md: WARNING: document isn't included in any toctree [toc.not_included]

@FScholPer --> we have resolved the issue

[qor-lb]

@basheerFZ / @daeyoung-jeong-lge I would strongly support using VSO as a use case to evaluate which evidence each S-CORE feature should expose, so that a central collection definition becomes possible. As a driver to validate and standardize what our features output (e.g. a common evidence format), VSO is genuinely useful and I think that part is worth pursuing.

What I am not yet convinced of is that an evidence layer can be defined independently of the evidences it collects. What counts as evidence, how it is correlated, and what constitutes a determinism violation are defined by the pipeline / application framework - e.g. monitoring via FEO task chains and their deadline semantics, the per-scenario contract. I also note an API server in the architecture, which suggests a runtime coupling rather than a framework-independent layer. So while the output interface of S-CORE features looks standardizable, the consolidation and presentation of that evidence still reads as OEM / system / solution / E/E-integration specific to me.

Concretely IMO, that suggests splitting the topic:

• In scope as an S-CORE discussion: a common evidence/output model across existing features, with VSO as the validating use case. This naturally touches lifecycle/health and FEO - which is also why my earlier FEO question stands: was cross-node / cross-instance pipeline-health aggregation already considered there?
• Partner-project / collaboration: the VSO aggregation+consolidation layer itself, integrating with S-CORE via that defined interface.

To be clear, this is my opinion and I am one reviewer, not the whole community - this is a scope and priority call. I would genuinely like to hear other committers/maintainers views on that as well.

[FScholPer]

I would agree that we need details about interfaces / contracts to other modules like lifecycle should provide state information or os should provide cpu usage and so on. My proposal would be to create inc repo to draft some first evidence layer api. @qor-lb whats your opinion?