Requirements#
Current State Publication
|
status: valid
security: YES
safety: QM
|
||||
The platform shall publish selected runtime state, configuration status, and health indicators in a structured, versioned, and timestamped model, supporting both pull and event-driven update patterns. Only explicitly exposed signals and metadata shall be made available to external systems. |
|||||
Desired State Interface
|
status: valid
security: YES
safety: QM
|
||||
The platform shall provide standardized desired state endpoints for platform components and applications. Desired state updates shall represent target conditions rather than direct low-level actuation commands, and shall be versioned, typed, and associated with explicit preconditions. |
|||||
State Schema and Semantics per Domain
|
status: valid
security: NO
safety: QM
|
||||
Each VECI state domain shall define an expected desired/current state schema, semantic constraints, admission preconditions, safety gates, and convergence acknowledgement/completion semantics. |
|||||
Desired State Acquisition and Freshness
|
status: valid
security: YES
safety: QM
|
||||
The vehicle shall retrieve desired state at its own pace, and shall apply freshness checks based on versioning and timestamps to prevent reconciliation against stale desired state. |
|||||
Policy and Constraint Injection
|
status: valid
security: YES
safety: QM
|
||||
The platform shall accept desired constraints and policy inputs from external systems as proposals only. Injected policies shall pass local policy checks before activation, and shall support explicit validity windows and scoped applicability. |
|||||
Validation and Enforcement Pipeline
|
status: valid
security: YES
safety: QM
|
||||
Every desired state update shall pass through authentication, authorization, schema validation, semantic validation, and policy compliance checks before reconciliation. Reconciliation shall be admitted only if local rules, safety constraints, and current system state permit it. Rejected updates shall produce explicit status codes and diagnostic context. |
|||||
Vehicle-Side Decision Authority
|
status: valid
security: YES
safety: ASIL_B
|
||||
Final admission and execution decisions for any externally provided desired state update or policy shall remain with the vehicle and shall not be delegated to external orchestrators. |
|||||
Reconciliation Execution
|
status: valid
security: NO
safety: QM
|
||||
Accepted desired state updates shall be realized through existing platform lifecycle and orchestration mechanisms, without introducing parallel execution paths. |
|||||
Convergence Status Reporting
|
status: valid
security: NO
safety: QM
|
||||
The platform shall report structured reconciliation status including accepted, progressing, converged, partially converged, rejected, and failed outcomes, along with diagnostic context. |
|||||
Configurable Reconciliation Mode
|
status: valid
security: NO
safety: QM
|
||||
The platform shall support both on-demand (vehicle-initiated) reconciliation per desired state version and continuous reconciliation/monitoring until convergence criteria are met. The active reconciliation mode shall be configurable per vehicle, per state domain, or per deployment profile. |
|||||
Push-Triggered Reconciliation
|
status: valid
security: YES
safety: QM
|
||||
The platform shall support orchestrator-initiated notifications signalling that a new desired state version is available, and shall treat such notifications as triggers to retrieve and reconcile the referenced desired state version subject to local trust, safety, and policy checks. |
|||||
Deterministic Execution
|
status: valid
security: NO
safety: ASIL_B
|
||||
Reconciliation execution shall remain deterministic for predefined operating scenarios and shall degrade gracefully in error conditions. |
|||||
Bounded Failure Handling
|
status: valid
security: NO
safety: ASIL_B
|
||||
The platform shall handle communication loss, invalid policies, reconciliation timeouts, and reconciliation failures through bounded error handling, including rollback or fallback behavior where applicable. |
|||||
Safe State Protection
|
status: valid
security: NO
safety: ASIL_B
|
||||
Desired state reconciliation shall not be allowed to bypass local safety constraints or lifecycle guards. |
|||||
Endpoint Authentication
|
status: valid
security: YES
safety: QM
|
||||
All external endpoints interacting via VECI shall be strongly authenticated prior to interaction, using credentials that are revocable and bound to scoped permissions. |
|||||
Authorization and Least Privilege
|
status: valid
security: YES
safety: QM
|
||||
External desired state updates shall be authorized per capability, context, and policy. Access shall be limited to the explicitly exposed state and policy surfaces. |
|||||
Message Integrity and Replay Protection
|
status: valid
security: YES
safety: QM
|
||||
All VECI interface messages shall be integrity-protected and freshness-validated to prevent tampering and replay attacks. |
|||||
Trust Management
|
status: valid
security: YES
safety: QM
|
||||
The platform shall manage trust relationships with external systems through verifiable identities and revocable credentials, supporting runtime revocation and trust re-establishment without requiring a platform restart. |
|||||
Auditability of Security-Relevant Actions
|
status: valid
security: YES
safety: QM
|
||||
Security-relevant actions shall be auditable end-to-end, recording requester identity, policy context, validation outcomes, and decision results to support post-event analysis and compliance evidence. |
|||||
State Reconciliation Semantics
|
status: valid
security: NO
safety: QM
|
||||
The platform shall implement explicit reconciliation semantics including desired state versioning with monotonic update handling, conflict handling between concurrent updates, partial convergence reporting, and stable final states for accepted or rejected reconciliation attempts. |
|||||
Transport-Agnostic Interface
|
status: valid
security: NO
safety: QM
|
||||
The VECI interface shall be transport-agnostic and shall operate across vehicle-to-cloud, vehicle-to-edge, and hybrid deployment profiles without changes to protocol-level behavior. |
|||||
Interface Versioning and Compatibility
|
status: valid
security: NO
safety: QM
|
||||
VECI interface contracts and data models shall be versioned to support incremental evolution. Backward-compatible extensions shall be preferred; breaking changes shall require explicit version transitions. |
|||||
Additive Integration with Existing Modules
|
status: valid
security: NO
safety: QM
|
||||
VECI shall augment existing S-CORE modules through additive integration points (lifecycle, communication/IPC abstractions, and platform security services) without replacing existing in-vehicle lifecycle, orchestration, or IPC mechanisms. |
|||||