Requirements#

The system SHALL implement user-level scheduling for task management so that task switches occur in the nanosecond range.

Rationale: Minimizes overhead compared to conventional thread-based approaches.

Verification: Benchmarking task switching performance.

The system SHALL support cooperative multi-tasking, allowing multiple concurrent tasks to share the same OS thread.

Rationale: Reduces the number of threads and associated context-switch overhead.

Verification: Analysis of thread usage and context-switch statistics.

The system SHALL provide a configurable thread pool for executing concurrent tasks. Additional thread pools MAY be introduced only when necessary (e.g., when tasks differ in criticality or require separation by process boundaries).

Rationale: Optimizes resource utilization and enables parallel execution.

Verification: Configuration tests and runtime profiling.

The programming framework SHALL allow developers to express concurrent and sequential dependencies, conditional branching, timing constraints, and error handling paths while abstracting explicit thread management and complex synchronization.

Rationale: Provides a user-friendly, transparent, and deterministic interface that aids debugging and control flow analysis.

Verification: Code reviews and simulated execution scenarios.

The system SHALL decouple algorithm design from deployment specifics, allowing dynamic updates, upgrades, and new deployments.

Rationale: Facilitates integration of applications from distributed teams without binding to a fixed runtime configuration.

Verification: Integration tests in simulated deployment environments.

The system SHALL provide hooks for tracing and profiling task execution to verify behavior and control flow of the integrated system.

Rationale: Enables effective debugging and validation of the orchestration framework.

Verification: Trace logs analysis and profiling test cases.

The orchestration feature SHALL assume that all code executing within a process is trusted.

Rationale: Reduces the attack surface by focusing security on inter-process interactions.

Verification: Security reviews and threat modeling.

The system SHALL use the approved IPC feature exclusively for all inter-process synchronization.

Rationale: Minimizes the attack surface and leverages a pre-evaluated secure mechanism.

Verification: Code audits and configuration checks.

All tasks within a single process SHALL share the same ASIL level.

Rationale: Prevents mixing of safety-critical and non-safety-critical operations.

Verification: ASIL compliance testing and system safety reviews.

The orchestration feature SHALL include configurable error handling mechanisms that are insulated from the effects of misbehaving tasks (e.g., tasks in an infinite loop).

Rationale: Ensures that system stability is maintained even under error conditions.

Verification: Error injection testing and robustness analysis.

The system SHALL expose hooks for external supervision (e.g., integration with a watchdog) without directly coupling to the watchdog mechanism.

Rationale: Enables integration with external safety monitors while maintaining modularity.

Verification: Integration tests with simulated watchdog behavior.

The system SHALL enforce that all tasks within a thread pool have the same criticality level. Lower-criticality tasks SHALL NOT influence the timing behavior of higher-criticality tasks.

Rationale: Prevents interference across criticality levels, ensuring reliable performance in safety-critical applications.

Verification: Criticality isolation tests and scheduling verification.

The system SHALL implement priority-based preemption between thread pools to ensure that lower-priority programs cannot interfere with higher-priority programs.

Rationale: Maintains deterministic timing behavior for high-criticality tasks.

Verification: Priority scheduling tests and timing analysis.