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?

[basheerFZ]

@FScholPer @qor-lb --> How should we proceed from the current Context, what should we do to move to next action ,
Is there any further discussions expected with the Architecture community committers/maintainers as well. Please let us your plans for the same.

[FScholPer]

@qor-lb anything you already discusssed? If not I would just create an inc repo to start the work

[qor-lb]

@basheerFZ @FScholPer On the where: I would reserve incubation repos for accepted S-CORE features. VSO isn't there yet - the feature proposal isn't accepted. Any public repo (e.g. on the VSO side) is enough to draft a first evidence-layer API and keep the collaboration open, without pre-committing the platform.

@basheerFZ on next steps: I think the key is broader input/buy-in from the Architecture Community - bringing the evidence-exposure use case there so committers/maintainers can weigh in on scope, priority, and whether there is wider support for taking it into the platform. That should be the natural path to move the feature forward, in parallel with drafting the API in a public repo.

[FScholPer]

Okay got it. But to have a clear picture can you bring the topic up again in the architecture community. This pr is from February. We have July now. Same for dds. No clear decision yet. #3007

[basheerFZ]

@basheerFZ @FScholPer On the where: I would reserve incubation repos for accepted S-CORE features. VSO isn't there yet - the feature proposal isn't accepted. Any public repo (e.g. on the VSO side) is enough to draft a first evidence-layer API and keep the collaboration open, without pre-committing the platform.

@basheerFZ on next steps: I think the key is broader input/buy-in from the Architecture Community - bringing the evidence-exposure use case there so committers/maintainers can weigh in on scope, priority, and whether there is wider support for taking it into the platform. That should be the natural path to move the feature forward, in parallel with drafting the API in a public repo.

@qor-lb --> We would like to know the following based on the discussions and conversations that we had till now:

1. We would like to know if you checked the SCORE VSO Explanation slides attached in comments - Suggesting why we are proposing VSO for FR proposal ?
2. we have captured how we Position VSO as Non differentiating area and OEM -differentiating areas in the slides, - Is that not convincing enough to be considered for FR acceptance ?
3. ** Since VSO is not FR accepted yet ?**, so, How do you see the support for enabling Multi Node Orchestration from an OEM side, currently whatever S-Core is providing via Lifecycle you think that is sufficient ? Please Correct us if our assumptions are wrong.

we see that currently - Score provides only the below information

• Lifecycle Management
• Health Monitoring
• Process Supervision
• Recovery Triggering
• Orchestration Foundations

However, it does not provide a standardized way to answer questions such as:

What is the ASIL level of this workload?

Can this workload be migrated?

Is redundancy available?

Has the system entered degraded mode?

Will migration violate safety assumptions?

What safety goals are impacted by a failure?

But for the OEMs , we see that they need the following to make decisions.

-SafetyStateChanged- System enters known safe behavior or based on mode transitions such as --> NORMAL -->DEGRADED -->FAIL SAFE
-ASILViolationDetected-Execution environment no longer satisfies ASIL assumptions. or Required partition unavailable
-FFIBreachDetected - Protected isolation assumptions are violated.
-SafeStateActivated
-SafeFallbackRequired -when Recovery impossible, Migration unsafe, Risk unacceptable

4. we see that the core value proposition of the VSO is:
   The orchestration engine should never continuously poll hundreds of signals and make decisions every millisecond. Instead, these components generate meaningful events when something relevant changes.

we feel the OEM should take informed decisions based on the criterias of S-Core for eg like :
Am I allowed to do this? and Should I do this now?
we believe this decisions should be shared and suggested by Score to OEM to take Safe decisions. But once again we understand these cannot be forced to OEMs.

5. Why It Should NOT Be 100% OEM - for the above

If every OEM implements its own:

• Safety/Semantics Evidence/Context API
• Safety State Model
• Orchestration Metadata
• Resource Semantics
• Evidence Format

then we get:

OEM A -> Format A
OEM B -> Format B
OEM C -> Format C

and middleware vendors cannot build reusable tooling.

6. We are proposing for a Semantic Evidence Framework with S-Core enabled safety context only -not Semantic Decision Logic as they are OEM specific , also Allow orchestration decisions based on safety information rather than only resource information.
   so we are proposing for

• Standard Data Model
• Standard APIs
• Standard Events
• Extension Points

by doing so we believe The framework does not implement OEM safety policies. Instead it provides Common Safety Language for the entire S-CORE ecosystem.
By converting Signals in to Evidences for eg like instead of Providing machine-readable safety semantics such as "Process A running" we will be informing the following: what we need to inform can be finetuned and adjusted if it does not fit with S-CORE framework.
-Process A
-ASIL-B
-Braking Domain
-Safe State Available
-Migration Allowed

So with this, we are seeing VSO as a prospective Feature Request, Now we are wondering what we should do to make this "Feature Request Acceptable". we believe Our proposal is in right context only, if not we need proper guidance and suggestions as to how we should go with making this feature request acceptable.

Note :- we understand the above 6 Points can also be taken for discussions with architecture community for their understandings and decisions.