Skip to content

RAPS v2.4.0 — Deterministic Safety Hardening

Choose a tag to compare

@dfeen87 dfeen87 released this 24 Dec 16:04
· 62 commits to main since this release
4d42a4b

Previous Version: v2.3.1
Current Version: v2.4.0


Summary

This release strengthens the Deterministic Safety Monitor (DSM) to ensure fail-safe behavior in the presence of corrupted, undefined, or non-finite telemetry inputs.

RAPS now explicitly detects NaN and Inf values and forces a full shutdown rather than continuing evaluation with unsafe internal state. This improves determinism and safety under real-world sensor fault conditions.


Motivation

  • Prevent unsafe evaluation paths when telemetry contains NaN or Inf
  • Ensure the DSM fails safe instead of propagating invalid internal computations
  • Eliminate undefined or misleading calculations caused by corrupted sensor data
  • Improve resilience against faulty sensor channels and upstream data corruption

Changes

Deterministic Safety Monitor Hardening

  • Added hasInvalidInputs() helper using std::isfinite to validate telemetry inputs
  • Short-circuited evaluateSafety() to:
    • Log an alert
    • Activate safing_sequence_active_
    • Return ACTION_FULL_SHUTDOWN immediately when invalid inputs are detected
  • Explicitly validated the following telemetry fields for finiteness:
    • measured_proper_time_dilation
    • measured_oscillatory_prefactor_A_t
    • measured_tcc_coupling_J
    • current_resonance_amplitude

Files Modified

  • include/raps/safety/deterministic_safety_monitor.hpp

Testing

  • No automated tests were executed for this change
  • Logic is deterministic and isolated to input validation
  • Recommended follow-up testing:
    • Unit tests with injected NaN / Inf values
    • Verification that shutdown behavior triggers consistently

Safety Impact

High (Positive)

This release reduces systemic risk by ensuring corrupted telemetry cannot propagate into unsafe control decisions. Fail-safe shutdown is now guaranteed when invalid inputs are detected.


Versioning Rationale

A minor version bump (v2.3.1 → v2.4.0) is appropriate because:

  • No public API was broken
  • Safety behavior was materially strengthened
  • System guarantees were improved beyond a simple bug fix