Requirements#
Common Fields Requirements#
REQ-COMMON_FIELDS-001
|
status: valid
security: NO
safety: ASIL_B
|
||||
Each interface (data or parameter) shall define the following attributes: Type, Default value, Datatype, Min and Max range limits, Unit, Description, and ASIL level. |
|||||
REQ-COMMON_FIELDS-002
|
status: valid
security: NO
safety: ASIL_B
|
||||
Error interface extensions shall include fields for Datatype, Maturation time, Severity, Reset time, Reset condition, Description, and Dependencies (optional). |
|||||
REQ-COMMON_FIELDS-003
|
status: valid
security: NO
safety: ASIL_B
|
||||
Safety reaction extensions shall include fields for Datatype, Error list, and Description. |
|||||
REQ-COMMON_FIELDS-004
|
status: valid
security: NO
safety: ASIL_B
|
||||
Mode interface extensions shall include a Datatype definition. |
|||||
REQ-COMMON_FIELDS-005
|
status: valid
security: NO
safety: ASIL_B
|
||||
Scheduling interface extensions shall include detailed execution and supervision attributes. |
|||||
Data Requirements#
REQ-DATA-001
|
status: valid
security: NO
safety: ASIL_B
|
||||
Standardization of interfaces shall also include coordinate system (ISO, SAE), vehicle reference point (virtual sensor mounting point, e.g. for velocity and accelerations), kinematic/kinetic value (e.g. for accelerations), and signal properties such as sample rate, accuracy, precision, under-/over-estimated, and integrity. |
|||||
Dependency Requirements#
REQ-DEPENDENCY-001
|
status: valid
security: NO
safety: ASIL_B
|
||||
The system shall allow explicit declaration of interface dependencies (e.g. error dependencies and safety reaction dependencies). |
|||||
REQ-DEPENDENCY-002
|
status: valid
security: NO
safety: ASIL_B
|
||||
If an interface depends on another, the dependency chain shall be documented within the VSS model. |
|||||
REQ-DEPENDENCY-003
|
status: valid
security: NO
safety: ASIL_B
|
||||
Circular dependencies between interfaces shall be automatically flagged during validation. |
|||||
Error Handling Requirements#
REQ-ERROR_HANDLING-001
|
status: valid
security: NO
safety: ASIL_B
|
||||
The system shall provide standardized error interfaces that enable applications to send error log requests and error reset requests to BSW failure/fault management components. |
|||||
REQ-ERROR_HANDLING-002
|
status: valid
security: NO
safety: ASIL_B
|
||||
The naming convention for error interfaces shall follow the format: FunctionName_ErrorName_ErrorSts. |
|||||
REQ-ERROR_HANDLING-003
|
status: valid
security: NO
safety: ASIL_B
|
||||
Each error interface shall define the following attributes: Datatype, Maturation time, Severity, Reset time, Reset condition, Description, and Dependencies (optional). |
|||||
REQ-ERROR_HANDLING-004
|
status: valid
security: NO
safety: ASIL_B
|
||||
The system shall support consistent error handling and logging practices across platforms to ensure interoperability. |
|||||
Extensibility and Maintainability Requirements#
REQ-EXTENSIBILITY_MAINTAINABILITY-001
|
status: valid
security: NO
safety: ASIL_B
|
||||
The system shall support adding new error or safety reaction types without requiring redefinition of existing interfaces. |
|||||
REQ-EXTENSIBILITY_MAINTAINABILITY-002
|
status: valid
security: NO
safety: ASIL_B
|
||||
The VSS extension schema shall support optional fields that can be populated by OEM-specific requirements. |
|||||
REQ-EXTENSIBILITY_MAINTAINABILITY-003
|
status: valid
security: NO
safety: ASIL_B
|
||||
Deprecated fields shall be marked clearly, and backward compatibility shall be maintained for at least two release cycles. |
|||||
Generic Requirements#
REQ-GENERIC-001
|
status: valid
security: NO
safety: ASIL_B
|
||||
Possible example interfaces that can be standardized across the systems. |
|||||
REQ-GENERIC-002
|
status: valid
security: NO
safety: ASIL_B
|
||||
Thermal management interfaces shall be standardized for coolant, oil, and
component temperatures under |
|||||
REQ-GENERIC-003
|
status: valid
security: NO
safety: ASIL_B
|
||||
Compute resource interfaces shall be standardized:
|
|||||
REQ-GENERIC-004
|
status: valid
security: NO
safety: ASIL_B
|
||||
Network link interfaces shall be standardized for CAN, LIN, and Ethernet status, error counters, and link speed. |
|||||
REQ-GENERIC-005
|
status: valid
security: NO
safety: ASIL_B
|
||||
Localization fix quality shall be standardized:
|
|||||
REQ-GENERIC-005
|
status: valid
security: NO
safety: ASIL_B
|
||||
OTA/software state shall be standardized:
|
|||||
REQ-GENERIC-007
|
status: valid
security: NO
safety: ASIL_B
|
||||
Variant and feature-coding information shall be standardized:
|
|||||
Interoperability Requirements#
REQ-INTEROPERABILITY-001
|
status: valid
security: NO
safety: ASIL_B
|
||||
Interfaces shall be designed to remain platform-independent, supporting reuse across multiple ECU architectures. |
|||||
REQ-INTEROPERABILITY-002
|
status: valid
security: NO
safety: ASIL_B
|
||||
The VSS extension shall provide mapping guidelines to AUTOSAR ports/signals for seamless integration. |
|||||
Mode Management Requirements#
REQ-MODE_MANAGEMENT-001
|
status: valid
security: NO
safety: ASIL_B
|
||||
The system shall provide mode management interfaces to convey system or functional mode information. |
|||||
REQ-MODE_MANAGEMENT-002
|
status: valid
security: NO
safety: ASIL_B
|
||||
The naming convention for mode management interfaces shall follow the
format: |
|||||
REQ-MODE_MANAGEMENT-003
|
status: valid
security: NO
safety: ASIL_B
|
||||
Mode management interfaces shall support adaptation of applications to diverse operational states. |
|||||
REQ-MODE_MANAGEMENT-004
|
status: valid
security: NO
safety: ASIL_B
|
||||
Each mode management interface shall define a Datatype for the mode signal. |
|||||
Parameters Requirements#
REQ-PARAMETERS-001
|
status: valid
security: NO
safety: ASIL_B
|
||||
Config parameters shall include validation constraints and effectiveRangeContext tied to variant/market. |
|||||
REQ-PARAMETERS-002
|
status: valid
security: NO
safety: ASIL_B
|
||||
Service-only parameters shall be protected by role-based access and audit logging. |
|||||
REQ-PARAMETERS-003
|
status: valid
security: NO
safety: ASIL_B
|
||||
Calibration artifacts shall declare calibrationId, calibrationDate, and expiry and be referenced by providers. |
|||||
Safety Reaction Requirements#
REQ-SAFETY_REACTION-001
|
status: valid
security: NO
safety: ASIL_B
|
||||
The system shall provide safety reaction interfaces to communicate critical error or safety events from BSW failure management to the application layer. |
|||||
REQ-SAFETY_REACTION-002
|
status: valid
security: NO
safety: ASIL_B
|
||||
The naming convention for safety reaction interfaces shall follow the
format: |
|||||
REQ-SAFETY_REACTION-003
|
status: valid
security: NO
safety: ASIL_B
|
||||
Each safety reaction interface shall define the following attributes: Datatype, Error list (causing the condition), and Description. |
|||||
REQ-SAFETY_REACTION-004
|
status: valid
security: NO
safety: ASIL_B
|
||||
Safety reaction interfaces shall ensure that applications can respond appropriately to safety conditions according to standardized protocols. |
|||||
Scheduling Requirements#
REQ-SCHEDULING-001
|
status: valid
security: NO
safety: ASIL_B
|
||||
The system shall provide scheduling interfaces as function calls instead of signal-based communication. |
|||||
REQ-SCHEDULING-002
|
status: valid
security: NO
safety: ASIL_B
|
||||
Scheduling interfaces shall be defined using the following mandatory
functions: |
|||||
REQ-SCHEDULING-003
|
status: valid
security: NO
safety: ASIL_B
|
||||
Each scheduling interface shall include the following attributes, where applicable: Run type, Cycle time, Description, Initial execution offset (optional), Priority (optional), Function scheduling mechanism, Debounce time (optional), Implemented ASIL level, Previous runnable (optional), Supervision type, Alive limits (optional), Deadline limits (optional), Logical check (optional), and Stack size (optional). |
|||||
REQ-SCHEDULING-004
|
status: valid
security: NO
safety: ASIL_B
|
||||
Scheduling interfaces shall support watchdog supervision in the BSW, where required by safety-critical functions. |
|||||
REQ-SCHEDULING-005
|
status: valid
security: NO
safety: ASIL_B
|
||||
Scheduling interfaces shall allow functions to declare memory requirements for integration purposes. |
|||||
REQ-SCHEDULING-006
|
status: valid
security: NO
safety: ASIL_B
|
||||
Components shall implement |
|||||
REQ-SCHEDULING-007
|
status: valid
security: NO
safety: ASIL_B
|
||||
|
|||||
REQ-SCHEDULING-008
|
status: valid
security: NO
safety: ASIL_B
|
||||
|
|||||
Security and Safety Requirements#
REQ-SECURITY_SAFETY-001
|
status: valid
security: NO
safety: ASIL_B
|
||||
Each interface shall include a mandatory ASIL classification. |
|||||
REQ-SECURITY_SAFETY-002
|
status: valid
security: NO
safety: ASIL_B
|
||||
Safety-related interfaces shall define fault containment regions (FCRs) they belong to. |
|||||
REQ-SECURITY_SAFETY-003
|
status: valid
security: NO
safety: ASIL_B
|
||||
Each interface extension shall include cybersecurity attributes, such as authentication requirements or data integrity checks, if applicable. |
|||||
REQ-SECURITY_SAFETY-004
|
status: valid
security: NO
safety: ASIL_B
|
||||
Error and safety reaction interfaces shall define fallback behavior when the receiving application is unresponsive. |
|||||
Timing and Performance Requirements#
REQ-TIMING_PERFORMANCE-001
|
status: valid
security: NO
safety: ASIL_B
|
||||
Each interface extension shall define latency requirements (maximum acceptable delay in ms). |
|||||
REQ-TIMING_PERFORMANCE-002
|
status: valid
security: NO
safety: ASIL_B
|
||||
Cyclic scheduling interfaces shall define worst-case execution time (WCET) per cycle. |
|||||
REQ-TIMING_PERFORMANCE-003
|
status: valid
security: NO
safety: ASIL_B
|
||||
Mode and error interfaces shall support time-stamping to ensure chronological traceability. |
|||||
Tools and Validation Requirements#
REQ-TOOLS_AND_VALIDATION-001
|
status: valid
security: NO
safety: ASIL_B
|
||||
A validation tool shall check whether all VSS extensions conform to naming conventions and mandatory fields. |
|||||
REQ-TOOLS_AND_VALIDATION-002
|
status: valid
security: NO
safety: ASIL_B
|
||||
Interface definitions shall be exportable to commonly used formats (e.g. JSON, YAML, ARXML). |
|||||
REQ-TOOLS_AND_VALIDATION-003
|
status: valid
security: NO
safety: ASIL_B
|
||||
Simulation/test stubs shall be automatically generatable for each scheduling function and interface type. |
|||||
REQ-TOOLS_AND_VALIDATION-004
|
status: valid
security: NO
safety: ASIL_B
|
||||
A static validator shall check naming conventions, mandatory fields, and mapping coverage of all VSS nodes. |
|||||
REQ-TOOLS_AND_VALIDATION-005
|
status: valid
security: NO
safety: ASIL_B
|
||||
Endianness and serialization format shall be declared per topic when binary transports are used. |
|||||
Architecture Requirements#
REQ-ARCHITECTURE-0001
|
status: valid
security: NO
safety: ASIL_B
|
||||
Concept overview of VAPI and VSS coexistence and use cases explaining the architecture layering of the concept. |
|||||
REQ-ARCHITECTURE-002
|
status: valid
security: NO
safety: ASIL_B
|
||||
The architecture shall separate concerns into Application, VAPI Abstraction Devices, Basic Services, and Platform layers with defined interfaces and no cross-layer shortcut dependencies. |
|||||
REQ-ARCHITECTURE-003
|
status: valid
security: NO
safety: ASIL_B
|
||||
All northbound interfaces to the Application shall be expressed as VSS nodes or VSS-backed APIs to ensure a uniform data model. |
|||||
REQ-ARCHITECTURE-004
|
status: valid
security: NO
safety: ASIL_B
|
||||
Southbound provider integrations shall be implemented as plug-ins loaded by the Abstraction Device layer via a stable provider API. |
|||||
REQ-ARCHITECTURE-005
|
status: valid
security: NO
safety: ASIL_B
|
||||
Cross-cutting concerns (time, logging, security, configuration) shall be provided only through Basic Services and not duplicated in providers. |
|||||
REQ-ARCHITECTURE-006
|
status: valid
security: NO
safety: ASIL_B
|
||||
The system shall support late binding: providers may be selected or replaced at deployment without changing application code. |
|||||
REQ-ARCHITECTURE-007
|
status: valid
security: NO
safety: ASIL_B
|
||||
The architecture shall support multiple providers for the same VSS node with a deterministic arbitration policy. |
|||||
REQ-ARCHITECTURE-008
|
status: valid
security: NO
safety: ASIL_B
|
||||
A declarative configuration file shall describe which providers populate which VSS nodes as per vehicle/ECU variant. |
|||||
REQ-ARCHITECTURE-009
|
status: valid
security: NO
safety: ASIL_B
|
||||
Abstraction Devices shall expose capability discovery including sensor type, supported sampling modes, ranges, units, and data quality attributes. |
|||||
REQ-ARCHITECTURE-010
|
status: valid
security: NO
safety: ASIL_B
|
||||
Abstraction Devices shall publish data via a common producer API with QoS hints (rate, latency budget, burst limit). |
|||||
REQ-ARCHITECTURE-011
|
status: valid
security: NO
safety: ASIL_B
|
||||
Providers shall report per-sample metadata: timestampSource, freshnessMs, qualityCode, and sourceId. |
|||||
REQ-ARCHITECTURE-012
|
status: valid
security: NO
safety: ASIL_B
|
||||
Providers shall surface health state and degradationMode and map them to error/safety reaction interfaces. |
|||||
REQ-ARCHITECTURE-013
|
status: valid
security: NO
safety: ASIL_B
|
||||
Providers shall support configuration via typed parameters with validation against schema and range constraints. |
|||||