Findings — implementation gaps

Behaviour the spec requires that the code does not implement.

A Finding is a slot the specification asked for but the code does not implement (no clamp, no validation, no fault gating, a defect). It is reported here as an honest gap — not injected into the requirement set. 100 findings across 10 modules.

#	Module	Requirement	Axis	Missing value / behaviour	Evidence
1	comms	`REQ-COM-003`	Saturation / Clamping	`max_latency_clamp_ms` — upper saturation limit for reported latency to prevent overflow artifacts	MISSING: The requirement mandates clamping latency_ms_ to prevent overflow artifacts, but the code performs no upper saturation. A clamp is absent.
2	comms	`REQ-COM-003`	Saturation / Clamping	`max_age_clamp_ms` — upper saturation limit for frame age to prevent overflow artifacts	MISSING: The requirement mandates clamping time_since_last_valid_frame to prevent overflow artifacts, but the code performs no upper saturation. A clamp is absent.
3	comms	`REQ-COM-007`	Resource Limits	`max_window_size` — maximum number of sequence numbers tracked in the sliding window for loss calculation	MISSING: The requirement mandates a bounded sliding window for packet loss estimation, but the code uses unbounded lifetime counters. No window size limit exists.
4	comms	`REQ-COM-007`	Resource Limits	`max_tracked_gaps` — maximum number of sequence gaps that can be tracked simultaneously	MISSING: The requirement mandates bounding the number of tracked gaps, but the code does not maintain a gap collection — it only maintains aggregate counters. No gap tracking structure exists.
5	safety	`REQ-SAF-001`	Input Domain	`min_speed_mps` — Minimum admissible speed value (likely 0.0 m/s)	The code checks pose validity and confidence but does NOT validate speed against a minimum bound. No min_speed check exists in any safety module.
6	safety	`REQ-SAF-001`	Input Domain	`max_speed_mps` — Maximum admissible speed value for validity checking	The code does NOT validate speed against a maximum bound anywhere in the safety modules. Speed validation for admissibility is absent.
7	safety	`REQ-SAF-002`	Output Domain	`min_decel_mps2` — Minimum (least aggressive) deceleration value	The code assigns deceleration values but does NOT validate bus.safe_stop_.target_decel_mps2 against any bounds. No range checking is performed.
8	safety	`REQ-SAF-002`	Output Domain	`max_decel_mps2` — Maximum (most aggressive) deceleration value	The code does NOT validate bus.safe_stop_.target_decel_mps2 against a maximum bound. Range checking is absent.
9	safety	`REQ-SAF-003`	Saturation / Clamping	`min_distance_m` — Minimum distance to boundary (non-negative requirement)	The code computes distance (line 38-43) but does NOT clamp it to a minimum. No clamping operation exists for distance_to_boundary_m.
10	safety	`REQ-SAF-003`	Saturation / Clamping	`min_safe_decel_mps2` — Minimum safe stop deceleration	The code does NOT clamp bus.safe_stop_.target_decel_mps2 to any minimum. No clamping logic exists.
11	safety	`REQ-SAF-003`	Saturation / Clamping	`max_safe_decel_mps2` — Maximum safe stop deceleration	The code does NOT clamp bus.safe_stop_.target_decel_mps2 to any maximum. Clamping is absent.
12	safety	`REQ-SAF-006`	Timing	`standstill_duration_cycles` — Number of cycles vehicle must remain below standstill speed	The E-stop release checks standstill in a single cycle (line 45) without requiring it to persist for multiple cycles. Duration-based debouncing is absent.
13	supervision	`REQ-SUP-001`	Input Domain	`geofence_distance_min_m` — Minimum physically valid distance to geofence boundary (may be negative for breach)	The code does not validate or enforce a minimum value for geofence_.distance_to_boundary_m_. Negative values (breach depth) are implied by the requirement text but not range-checked in the code. This is a missing input validation.
14	supervision	`REQ-SUP-001`	Input Domain	`geofence_distance_max_m` — Maximum physically valid distance to geofence boundary	No maximum bound check on geofence_.distance_to_boundary_m_ is present. The code does not enforce or validate an upper limit.
15	supervision	`REQ-SUP-001`	Input Domain	`speed_max_mps` — Maximum valid vehicle speed from sensor or physical limit	No maximum speed validation is performed on pose_.speed_mps_ or plausible_command_.speed_mps_. The code does not enforce an upper limit.
16	supervision	`REQ-SUP-003`	Saturation / Clamping	`init_cycles_max` — Maximum value for init_cycles_ counter before saturation (e.g., UINT32_MAX or a practical limit)	The requirement calls for saturation of init_cycles_, but the code (line 49) increments without bound. If the system remains in init state indefinitely, init_cycles_ will overflow. No saturation is implemented.
17	supervision	`REQ-SUP-005`	Fault / Error Reaction	`mode_on_invalid_input` — Operating mode to enter on invalid input detection (likely emergency or fault)	The requirement specifies detection and response to invalid/out-of-domain inputs, but no such validation is implemented in the supervision module. This is a missing safety feature.
18	supervision	`REQ-SUP-005`	Fault / Error Reaction	`degradation_on_invalid_input` — Degradation level to set on invalid input detection (likely safe_stop_only)	No degradation response to invalid input is implemented because no input validation exists (see mode_on_invalid_input).
19	supervision	`REQ-SUP-006`	Timing	`standstill_confirmation_cycles` — Number of consecutive low-speed cycles required to confirm standstill state	The requirement asks for standstill confirmation over multiple cycles, but the code evaluates it as a single-cycle boolean condition. No debounce or cycle-counting logic exists.
20	supervision	`REQ-SUP-007`	Resource Limits	`max_monitored_modules_limit` — Maximum number of modules that can be monitored (design or resource constraint)	The code does not enforce or validate a maximum limit on the number of monitored modules. No configuration rejection or resource limit check is present.
21	supervision	`REQ-SUP-008`	State	`init_entry_action` — Action performed on init state entry (reset init_cycles_ to 0 per state machine)	The code increments init_cycles_ but never resets it on init state entry. If the system re-enters init after leaving it, init_cycles_ will retain its old value, breaking the self-test logic. Entry action is missing.
22	command	`REQ-COM-002`	Output Domain	`min_output_speed_mps` — Minimum (most negative) speed setpoint output, corresponding to maximum reverse	DEFECT: motion_setpoint_.target_speed_mps_ is NOT clamped to any range. The setpoint_generator only applies acceleration-based smoothing (lines 17-24) but does not enforce output limits. The value can be any result of the accel/decel banding.
23	command	`REQ-COM-002`	Output Domain	`max_output_speed_mps` — Maximum forward speed setpoint output	DEFECT: motion_setpoint_.target_speed_mps_ is NOT clamped to any range. The setpoint_generator only applies acceleration-based smoothing but does not enforce output limits.
24	command	`REQ-COM-002`	Output Domain	`min_output_yaw_radps` — Minimum (most negative) yaw rate setpoint output	DEFECT: motion_setpoint_.target_yaw_rate_radps_ is passed through directly from arbitrated_command_ with no range limiting. No output clamp is applied.
25	command	`REQ-COM-002`	Output Domain	`max_output_yaw_radps` — Maximum yaw rate setpoint output	DEFECT: motion_setpoint_.target_yaw_rate_radps_ is passed through directly with no range limiting.
26	command	`REQ-COM-006`	Timing	`command_staleness_timeout_ms` — Maximum age of remote_command_ before considered stale	DEFECT: Command staleness detection is NOT implemented. The module checks command_authentic_ and remote_command_.valid_ flags but does not track or enforce any timeout for stale commands. No timestamp comparison or age checking exists.
27	command	`REQ-COM-006`	Timing	`stale_command_plausible_value` — Value of plausible_ flag when command input is stale	DEFECT: Since staleness detection is absent, this value cannot be determined from the code. If staleness were detected, the pattern suggests it would be false (consistent with other fault conditions).
28	actuation	`REQ-ACT-001`	Input Domain	`min_accel_mps2` — Minimum admissible longitudinal acceleration input (typically negative for deceleration)	No input validation or range check is performed on limited_motion_.limited_accel_mps2_. The code silently clamps negative values to zero for drive (line 28) and inverts/clamps for brake (line 17), but does not reject or validate the input range itself. The acceptance range is not enforced.
29	actuation	`REQ-ACT-001`	Input Domain	`max_accel_mps2` — Maximum admissible longitudinal acceleration input	No upper bound validation on limited_accel_mps2 is present. The code accepts any positive value without clamping or rejection. The acceptance range upper limit is not enforced.
30	actuation	`REQ-ACT-001`	Input Domain	`min_steering_input_rad` — Minimum admissible steering angle input (typically negative for left)	No input validation on limited_motion_.limited_steering_rad_ before clamping. The code clamps to ±max_steering_rad_ but does not validate or reject inputs outside an acceptance range. Input validation is absent.
31	actuation	`REQ-ACT-001`	Input Domain	`max_steering_input_rad` — Maximum admissible steering angle input (typically positive for right)	No input validation on limited_motion_.limited_steering_rad_ before clamping. The code clamps to ±max_steering_rad_ but does not validate or reject inputs outside an acceptance range. Input validation is absent.
32	actuation	`REQ-ACT-001`	Input Domain	`min_safe_stop_decel_mps2` — Minimum admissible safe-stop deceleration (typically zero or slightly negative)	No validation on safe_stop_.target_decel_mps2_ is performed. The value is used directly in max() comparison without range checking. Input acceptance range is not enforced.
33	actuation	`REQ-ACT-001`	Input Domain	`max_safe_stop_decel_mps2` — Maximum admissible safe-stop deceleration magnitude	No upper bound validation on safe_stop_.target_decel_mps2_. The value is accepted and used without limit checking. Input acceptance range upper limit is not enforced.
34	actuation	`REQ-ACT-002`	Output Domain	`max_drive_torque_nm` — Maximum motor torque command	No upper limit is applied to motor_torque_nm or drive_torque_request_nm_. The computed torque from unclamped acceleration is passed through without saturation. Output range upper bound is not enforced.
35	actuation	`REQ-ACT-002`	Output Domain	`max_brake_force_n` — Maximum brake force	No upper saturation on brake_force_n. The computed force from unclamped deceleration (including emergency_decel_mps2_ from calibration) is used directly without limit checking. Output range upper bound is not enforced.
36	actuation	`REQ-ACT-003`	Saturation / Clamping	`max_brake_force_limit_n` — Upper saturation limit for brake force command	No saturation limit is applied to brake_force_request_n_ or actuator_command_.brake_force_n_. The requirement specifies a max limit, but the code does not enforce one. This is the same finding as max_brake_force_n.
37	localization	`REQ-LOC-001`	Input Domain	`min_tick_ms` — minimum valid system timestamp in milliseconds	No validation of tick_ms_ bounds is performed. The code reads bus.tick_ms_ and performs arithmetic (subtraction, division) without checking minimum value. Missing input validation for timestamp lower bound.
38	localization	`REQ-LOC-001`	Input Domain	`max_tick_ms` — maximum valid system timestamp in milliseconds (typically uint64_t max or practical system limit)	No validation of tick_ms_ bounds is performed. The code reads bus.tick_ms_ and performs arithmetic without checking maximum value. Missing input validation for timestamp upper bound.
39	localization	`REQ-LOC-001`	Input Domain	`min_encoder_ticks` — minimum valid encoder tick count value	No validation of encoder tick range. inject_ticks() directly assigns left_ticks_ and right_ticks_ without checking bounds. Missing input validation for encoder minimum value.
40	localization	`REQ-LOC-001`	Input Domain	`max_encoder_ticks` — maximum valid encoder tick count value	No validation of encoder tick range. inject_ticks() directly assigns left_ticks_ and right_ticks_ without checking bounds. Missing input validation for encoder maximum value.
41	localization	`REQ-LOC-001`	Input Domain	`min_yaw_rate` — minimum valid IMU yaw rate in radians per second	No validation of IMU yaw rate range. inject_imu() directly assigns latest_ without checking yaw_rate_radps_ bounds. Missing input validation for yaw rate minimum.
42	localization	`REQ-LOC-001`	Input Domain	`max_yaw_rate` — maximum valid IMU yaw rate in radians per second	No validation of IMU yaw rate range. inject_imu() directly assigns latest_ without checking yaw_rate_radps_ bounds. Missing input validation for yaw rate maximum.
43	localization	`REQ-LOC-001`	Input Domain	`min_speed` — minimum valid odometry speed value	No validation of computed speed range. speed_mps_ is computed as ds_m / dt_s and assigned to out.speed_mps_ without checking bounds. Missing output validation for minimum speed.
44	localization	`REQ-LOC-001`	Input Domain	`max_speed` — maximum valid odometry speed value	No validation of computed speed range. speed_mps_ is computed as ds_m / dt_s and assigned to out.speed_mps_ without checking bounds. Missing output validation for maximum speed.
45	localization	`REQ-LOC-002`	Output Domain	`min_x_position` — minimum valid x coordinate in meters	No range specification for x position. x_m_ is integrated via x_m_ += ds_m * std::cos(heading_rad_) and assigned to out.x_m_ without bounds validation. Missing output range constraint.
46	localization	`REQ-LOC-002`	Output Domain	`max_x_position` — maximum valid x coordinate in meters	No range specification for x position. x_m_ is integrated via x_m_ += ds_m * std::cos(heading_rad_) and assigned to out.x_m_ without bounds validation. Missing output range constraint.
47	localization	`REQ-LOC-002`	Output Domain	`min_y_position` — minimum valid y coordinate in meters	No range specification for y position. y_m_ is integrated via y_m_ += ds_m * std::sin(heading_rad_) and assigned to out.y_m_ without bounds validation. Missing output range constraint.
48	localization	`REQ-LOC-002`	Output Domain	`max_y_position` — maximum valid y coordinate in meters	No range specification for y position. y_m_ is integrated via y_m_ += ds_m * std::sin(heading_rad_) and assigned to out.y_m_ without bounds validation. Missing output range constraint.
49	localization	`REQ-LOC-002`	Output Domain	`max_pose_speed` — maximum valid pose speed value	No maximum speed constraint is enforced. pose speed is assigned directly from odometry without clamping. Missing output range constraint for maximum speed.
50	localization	`REQ-LOC-003`	Saturation / Clamping	`clamp_min_x` — lower clamp limit on x position in meters	No clamping of x position is performed. x_m_ is updated via integration and directly assigned to out.x_m_ without any clamp operation. Missing output clamping behavior.
51	localization	`REQ-LOC-003`	Saturation / Clamping	`clamp_max_x` — upper clamp limit on x position in meters	No clamping of x position is performed. x_m_ is updated via integration and directly assigned to out.x_m_ without any clamp operation. Missing output clamping behavior.
52	localization	`REQ-LOC-003`	Saturation / Clamping	`clamp_min_y` — lower clamp limit on y position in meters	No clamping of y position is performed. y_m_ is updated via integration and directly assigned to out.y_m_ without any clamp operation. Missing output clamping behavior.
53	localization	`REQ-LOC-003`	Saturation / Clamping	`clamp_max_y` — upper clamp limit on y position in meters	No clamping of y position is performed. y_m_ is updated via integration and directly assigned to out.y_m_ without any clamp operation. Missing output clamping behavior.
54	localization	`REQ-LOC-006`	Timing	`non_monotonic_tick_behavior` — behavior when tick_ms_ is non-monotonic: clamp dt, skip update, error flag	No validation is performed for non-monotonic tick_ms_. If tick_ms_ decreases, dt will be negative, potentially causing incorrect integration. Missing input validation for timestamp monotonicity.
55	localization	`REQ-LOC-006`	Timing	`validity_debounce_count` — number of consecutive cycles required to confirm sensor validity state change	Sensor validity flags are set/cleared immediately based on current conditions without any debounce counter. No multi-cycle confirmation logic is present. Missing debounce mechanism.
56	localization	`REQ-LOC-007`	Resource Limits	`alive_counter_min_index` — minimum valid index for alive_counters_ array	No bounds validation is performed on the alive_counters_ array access. The code assumes module_id::localization is a valid index but does not verify lower bound. Missing bounds checking.
57	localization	`REQ-LOC-007`	Resource Limits	`alive_counter_max_index` — maximum valid index for alive_counters_ array	No bounds validation is performed on the alive_counters_ array access. The code assumes module_id::localization is a valid index but does not verify upper bound. Missing bounds checking.
58	localization	`REQ-LOC-008`	State	`state_after_first_valid_sensor` — module state after first valid sensor injection (e.g., INITIALIZED, RUNNING)	The code has no explicit state machine or state enumeration. The have_last_ flag (line 24) tracks whether dt can be computed, but no formal state transition occurs after first valid sensor data. Missing state management behavior.
59	localization	`REQ-LOC-008`	State	`state_reset_values` — values to which pose state is reset (x, y, heading, confidence)	No state reset mechanism is implemented. Once initialized, x_m_, y_m_, and heading_rad_ are only updated via integration; no code path resets them to initial or other values. Missing reset capability.
60	localization	`REQ-LOC-008`	State	`state_reset_condition` — condition under which pose state is reset (e.g., external command, prolonged invalidity)	No state reset mechanism is implemented. There is no condition under which pose state is reset. Missing reset trigger logic.
61	motion_control	`REQ-MOT-001`	Input Domain	`min_pose_speed_mps` — Minimum admissible pose speed feedback value	The code does not validate or clamp pose_.speed_mps_. The requirement asks for an 'admissible range' but the implementation accepts any value without range checks. This is a missing input validation.
62	motion_control	`REQ-MOT-001`	Input Domain	`max_pose_speed_mps` — Maximum admissible pose speed feedback value	No upper-bound validation on pose_.speed_mps_. The module does not enforce any admissible range on the feedback signal; it trusts the input unconditionally.
63	motion_control	`REQ-MOT-001`	Input Domain	`min_imu_yaw_rate_radps` — Minimum admissible IMU yaw rate feedback value	The code does not validate or clamp imu_.yaw_rate_radps_. The requirement implies an admissible range, but the implementation does not enforce it.
64	motion_control	`REQ-MOT-001`	Input Domain	`max_imu_yaw_rate_radps` — Maximum admissible IMU yaw rate feedback value	No upper-bound validation on imu_.yaw_rate_radps_. Missing input validation.
65	motion_control	`REQ-MOT-005`	Fault / Error Reaction	`degradation_envelope_formula` — Mapping from degradation level to max_accel, max_decel, max_yaw_rate envelopes	The requirement asks for 'degradation-dependent acceleration and yaw rate envelopes' but the code only adjusts the speed envelope. Acceleration and yaw rate limits remain constant regardless of degradation level. This is a missing feature.
66	motion_control	`REQ-MOT-005`	Fault / Error Reaction	`failsafe_accel_mps2` — Safe acceleration command on invalid input (expected: zero or gentle decel)	The code does not check for invalid input signals (NaN, out-of-range, stale timestamps). No failsafe acceleration value is output on invalid input. This is a missing safety feature.
67	motion_control	`REQ-MOT-005`	Fault / Error Reaction	`failsafe_steering_rad` — Safe steering command on invalid input (expected: zero or hold)	The code does not output a failsafe steering command on invalid input. No input validation is present. This is a missing safety feature.
68	motion_control	`REQ-MOT-005`	Fault / Error Reaction	`invalid_input_condition` — Condition defining invalid inputs (e.g., NaN, out-of-range, stale timestamp)	The code does not define or check for any invalid input condition (NaN, out-of-range, stale timestamp). Input signals are trusted unconditionally. This is a missing safety feature.
69	motion_control	`REQ-MOT-007`	Resource Limits	`speed_integral_min` — Lower bound on speed PID integral accumulator to prevent underflow	The code does not explicitly bound the integral accumulator. Anti-windup prevents further accumulation when saturated, but the integral_ variable itself has no min/max clamp. If the error remains persistently negative before saturation, integral_ can underflow. Missing explicit integral bounds.
70	motion_control	`REQ-MOT-007`	Resource Limits	`speed_integral_max` — Upper bound on speed PID integral accumulator to prevent overflow	No explicit upper bound on the integral accumulator. The anti-windup logic conditionally prevents accumulation but does not clamp the integral term itself. Missing explicit integral bounds.
71	motion_control	`REQ-MOT-007`	Resource Limits	`steer_integral_min` — Lower bound on steering PID integral accumulator to prevent underflow	No explicit lower bound on steering PID integral accumulator. Same finding as speed_integral_min.
72	motion_control	`REQ-MOT-007`	Resource Limits	`steer_integral_max` — Upper bound on steering PID integral accumulator to prevent overflow	No explicit upper bound on steering PID integral accumulator. Same finding as speed_integral_max.
73	perception	`REQ-PER-001`	Input Domain	`min_ego_speed_mps` — minimum admissible ego vehicle speed (expected 0.0 per AOU-003)	No minimum speed validation exists in the code. The module unconditionally uses pose_.speed_mps_ (line 16: 'const float ego_speed = bus.pose_.speed_mps_;') with no lower-bound check. This is a missing input validation requirement.
74	perception	`REQ-PER-001`	Input Domain	`max_ego_speed_mps` — maximum admissible ego vehicle speed for validity check	No maximum speed validation exists in the code. The module unconditionally uses pose_.speed_mps_ with no upper-bound check or clamp. This is a missing input validation requirement.
75	perception	`REQ-PER-001`	Input Domain	`max_tick_backwards_ms` — maximum allowable backwards jump in system timestamp before triggering fault	No tick monotonicity validation exists. The code performs unsigned subtraction (line 28) which will underflow if tick_ms_ goes backwards. No fault is raised for non-monotonic timestamps. This check is absent.
76	perception	`REQ-PER-002`	Output Domain	`max_obstacle_range_m` — maximum LiDAR detection range for obstacles	No maximum range validation. The code accepts any positive range value from the LiDAR scan without an upper limit check. This is a missing sensor-range validation (LiDAR max detection range should be enforced).
77	perception	`REQ-PER-002`	Output Domain	`min_bearing_rad` — minimum bearing angle (likely -π or -π/2)	No bearing range validation. The code uses bearing_rad_ from lidar_point_t without checking if it lies in a valid angular range (e.g., [-π, π]). This is a missing input validation.
78	perception	`REQ-PER-002`	Output Domain	`max_bearing_rad` — maximum bearing angle (likely +π or +π/2)	No bearing range validation. The code uses bearing_rad_ from lidar_point_t without checking if it lies in a valid angular range. This is a missing input validation.
79	perception	`REQ-PER-003`	Saturation / Clamping	`ttc_clamp_max_s` — upper saturation limit for time-to-collision to avoid infinity	No TTC clamping. The code computes ttc and takes the minimum but never clamps to prevent arbitrarily large values when closing_speed is very small. The requirement asks for a max clamp; this is absent.
80	perception	`REQ-PER-003`	Saturation / Clamping	`min_relative_speed_mps` — lower clamp on relative speed (negative = approaching)	No lower clamp on relative_speed. The code computes relative_speed from range deltas (line 113) with no bounds checking. Negative values (approaching) are allowed without limit.
81	perception	`REQ-PER-003`	Saturation / Clamping	`max_relative_speed_mps` — upper clamp on relative speed (positive = receding)	No upper clamp on relative_speed. The code computes relative_speed from range deltas with no bounds checking. Positive values (receding) are allowed without limit.
82	perception	`REQ-PER-005`	Fault / Error Reaction	`imminent_default_on_fault` — safe default value for imminent flag when sensor is faulted	The collision predictor does not gate its outputs on sensor status. It unconditionally processes obstacles regardless of lidar_status_ (failed/stale). There is no safe-default logic for collision_.imminent when the sensor is faulted. This is a missing fault-handling requirement.
83	perception	`REQ-PER-005`	Fault / Error Reaction	`obstacle_list_fault_behavior` — action taken on obstacle list during fault (e.g., 'clear', 'freeze', 'mark_unconfirmed')	The obstacle detector does not check lidar_status_ before processing the scan. When the sensor is failed/stale, it still attempts to cluster and track. There is no fault-gating logic to clear, freeze, or mark obstacles as unconfirmed during sensor faults. This is a missing fault-handling requirement.
84	perception	`REQ-PER-007`	Resource Limits	`overflow_behavior_scan` — action when max_lidar_points reached (e.g., 'truncate', 'reject_scan', 'subsample')	No overflow protection on lidar_scan_. The code copies the injected scan unconditionally (line 26) and processes it without checking against max_lidar_points. If the scan exceeds the expected limit, the code will process all points (subject to clustering capacity limits). There is no truncate/reject/subsample logic for oversized scans.
85	perception	`REQ-PER-009`	Concurrency	`reentrancy_policy` — reentrancy handling (e.g., 'not_reentrant_error', 'not_reentrant_ignored', 'reentrant_safe')	The code has no reentrancy protection. All three perception classes maintain mutable state (tracks_, latest_scan_, injected_, etc.) that would be corrupted by concurrent or reentrant calls to run() or inject_scan(). There is no error detection or handling for reentrancy. This is a missing concurrency safety requirement.
86	power_management	`REQ-PWR-002`	Output Domain	`output_min_voltage_v` — Minimum voltage value reported in power status outputs	The code does NOT bound/clamp the output voltage values in power_main_.voltage_v_ or power_backup_.voltage_v_. The evaluate() function (line 17) directly passes through the input voltage without saturation limits. There is no minimum output voltage constraint implemented.
87	power_management	`REQ-PWR-002`	Output Domain	`output_max_voltage_v` — Maximum voltage value reported in power status outputs	The code does NOT bound/clamp the output voltage values in power_main_.voltage_v_ or power_backup_.voltage_v_. The evaluate() function (line 17) directly passes through the input voltage without saturation limits. There is no maximum output voltage constraint implemented.
88	power_management	`REQ-PWR-003`	Saturation / Clamping	`clamp_min_v` — Lower saturation limit for voltage measurements	The code does NOT implement voltage clamping/saturation. When voltage measurements exceed physical rail limits, the raw values are passed through unchanged to the output. No minimum clamp is applied before fault detection or output publication.
89	power_management	`REQ-PWR-003`	Saturation / Clamping	`clamp_max_v` — Upper saturation limit for voltage measurements	The code does NOT implement voltage clamping/saturation. When voltage measurements exceed physical rail limits, the raw values are passed through unchanged to the output. No maximum clamp is applied before fault detection or output publication.
90	cyclic_scheduler	`REQ-CYC-003`	Saturation / Clamping	`max_registered_tasks` — Maximum number of tasks that can be registered with the scheduler	No upper bound is enforced. The code does not reject registration when a limit is reached; the requirement specifies rejection behavior that is absent.
91	cyclic_scheduler	`REQ-CYC-003`	Saturation / Clamping	`max_tasks_per_tick` — Maximum number of task callbacks executed in a single tick (may equal max_registered_tasks or be separately limited)	No per-tick execution limit is enforced. The code executes all due tasks without limiting the count, contradicting the requirement.
92	cyclic_scheduler	`REQ-CYC-004`	Sign / Units	`hz_to_ms_formula` — Formula to convert frequency in Hz to period in milliseconds (e.g., period_ms = 1000 / freq_hz)	The requirement specifies Hz-to-ms conversion, but the code provides no frequency parameter or conversion logic. Feature is absent.
93	cyclic_scheduler	`REQ-CYC-005`	Fault / Error Reaction	`fault_log_destination` — Destination for logging task callback exceptions (likely faults_ output)	No exception handling exists around task callback invocation. The requirement mandates catching exceptions and logging faults, but this is entirely absent.
94	cyclic_scheduler	`REQ-CYC-005`	Fault / Error Reaction	`task_fault_status` — The status value assigned to a task that has thrown an exception	No status field or fault marking mechanism exists. The required behavior is not implemented.
95	cyclic_scheduler	`REQ-CYC-005`	Fault / Error Reaction	`fault_task_policy` — Policy determining whether a faulted task is skipped once or permanently disabled	No fault handling policy (skip/disable) is implemented because no exception handling exists.
96	cyclic_scheduler	`REQ-CYC-005`	Fault / Error Reaction	`uninitialized_bus_error_code` — Error code returned when run_tick is called with uninitialized signal_bus_t	No error return mechanism exists (void return type) and no bus initialization validation is performed. The required error code cannot be returned.
97	cyclic_scheduler	`REQ-CYC-006`	Timing	`max_tick_execution_time_ms` — Maximum allowed execution time for all tasks in a single tick (per AOU-002)	No timing budget or max execution time enforcement exists. The requirement specifies completion within a deadline, but no such mechanism is implemented.
98	cyclic_scheduler	`REQ-CYC-008`	State	`uninitialized_state` — Initial state before signal_bus_t initialization (per AOU-004)	The requirement specifies state enforcement (uninitialized, registration, running), but no state variable or transitions exist in the scheduler implementation.
99	cyclic_scheduler	`REQ-CYC-008`	State	`registration_state` — State after initialization where task registration is allowed (per AOU-005)	No state tracking or state-based registration gating is implemented.
100	cyclic_scheduler	`REQ-CYC-008`	State	`running_state` — State after first run_tick() where execution occurs and registration is prohibited	No state enforcement preventing registration after execution begins.

Module

Requirement

Axis

Missing value / behaviour

Evidence

comms

REQ-COM-003

Saturation / Clamping

max_latency_clamp_ms — upper saturation limit for reported latency to prevent overflow artifacts

MISSING: The requirement mandates clamping latency_ms_ to prevent overflow artifacts, but the code performs no upper saturation. A clamp is absent.

comms

REQ-COM-003

Saturation / Clamping

max_age_clamp_ms — upper saturation limit for frame age to prevent overflow artifacts

MISSING: The requirement mandates clamping time_since_last_valid_frame to prevent overflow artifacts, but the code performs no upper saturation. A clamp is absent.

comms

REQ-COM-007

Resource Limits

max_window_size — maximum number of sequence numbers tracked in the sliding window for loss calculation

MISSING: The requirement mandates a bounded sliding window for packet loss estimation, but the code uses unbounded lifetime counters. No window size limit exists.

comms

REQ-COM-007

Resource Limits

max_tracked_gaps — maximum number of sequence gaps that can be tracked simultaneously

MISSING: The requirement mandates bounding the number of tracked gaps, but the code does not maintain a gap collection — it only maintains aggregate counters. No gap tracking structure exists.

safety

REQ-SAF-001

Input Domain

min_speed_mps — Minimum admissible speed value (likely 0.0 m/s)

The code checks pose validity and confidence but does NOT validate speed against a minimum bound. No min_speed check exists in any safety module.

safety

REQ-SAF-001

Input Domain

max_speed_mps — Maximum admissible speed value for validity checking

The code does NOT validate speed against a maximum bound anywhere in the safety modules. Speed validation for admissibility is absent.

safety

REQ-SAF-002

Output Domain

min_decel_mps2 — Minimum (least aggressive) deceleration value

The code assigns deceleration values but does NOT validate bus.safe_stop_.target_decel_mps2 against any bounds. No range checking is performed.

safety

REQ-SAF-002

Output Domain

max_decel_mps2 — Maximum (most aggressive) deceleration value

The code does NOT validate bus.safe_stop_.target_decel_mps2 against a maximum bound. Range checking is absent.

safety

REQ-SAF-003

Saturation / Clamping

min_distance_m — Minimum distance to boundary (non-negative requirement)

The code computes distance (line 38-43) but does NOT clamp it to a minimum. No clamping operation exists for distance_to_boundary_m.

safety

REQ-SAF-003

Saturation / Clamping

min_safe_decel_mps2 — Minimum safe stop deceleration

The code does NOT clamp bus.safe_stop_.target_decel_mps2 to any minimum. No clamping logic exists.

safety

REQ-SAF-003

Saturation / Clamping

max_safe_decel_mps2 — Maximum safe stop deceleration

The code does NOT clamp bus.safe_stop_.target_decel_mps2 to any maximum. Clamping is absent.

safety

REQ-SAF-006

Timing

standstill_duration_cycles — Number of cycles vehicle must remain below standstill speed

The E-stop release checks standstill in a single cycle (line 45) without requiring it to persist for multiple cycles. Duration-based debouncing is absent.

supervision

REQ-SUP-001

Input Domain

geofence_distance_min_m — Minimum physically valid distance to geofence boundary (may be negative for breach)

The code does not validate or enforce a minimum value for geofence_.distance_to_boundary_m_. Negative values (breach depth) are implied by the requirement text but not range-checked in the code. This is a missing input validation.

supervision

REQ-SUP-001

Input Domain

geofence_distance_max_m — Maximum physically valid distance to geofence boundary

No maximum bound check on geofence_.distance_to_boundary_m_ is present. The code does not enforce or validate an upper limit.

supervision

REQ-SUP-001

Input Domain

speed_max_mps — Maximum valid vehicle speed from sensor or physical limit

No maximum speed validation is performed on pose_.speed_mps_ or plausible_command_.speed_mps_. The code does not enforce an upper limit.

supervision

REQ-SUP-003

Saturation / Clamping

init_cycles_max — Maximum value for init_cycles_ counter before saturation (e.g., UINT32_MAX or a practical limit)

The requirement calls for saturation of init_cycles_, but the code (line 49) increments without bound. If the system remains in init state indefinitely, init_cycles_ will overflow. No saturation is implemented.

supervision

REQ-SUP-005

Fault / Error Reaction

mode_on_invalid_input — Operating mode to enter on invalid input detection (likely emergency or fault)

The requirement specifies detection and response to invalid/out-of-domain inputs, but no such validation is implemented in the supervision module. This is a missing safety feature.

supervision

REQ-SUP-005

Fault / Error Reaction

degradation_on_invalid_input — Degradation level to set on invalid input detection (likely safe_stop_only)

No degradation response to invalid input is implemented because no input validation exists (see mode_on_invalid_input).

supervision

REQ-SUP-006

Timing

standstill_confirmation_cycles — Number of consecutive low-speed cycles required to confirm standstill state

The requirement asks for standstill confirmation over multiple cycles, but the code evaluates it as a single-cycle boolean condition. No debounce or cycle-counting logic exists.

supervision

REQ-SUP-007

Resource Limits

max_monitored_modules_limit — Maximum number of modules that can be monitored (design or resource constraint)

The code does not enforce or validate a maximum limit on the number of monitored modules. No configuration rejection or resource limit check is present.

supervision

REQ-SUP-008

State

init_entry_action — Action performed on init state entry (reset init_cycles_ to 0 per state machine)

The code increments init_cycles_ but never resets it on init state entry. If the system re-enters init after leaving it, init_cycles_ will retain its old value, breaking the self-test logic. Entry action is missing.

command

REQ-COM-002

Output Domain

min_output_speed_mps — Minimum (most negative) speed setpoint output, corresponding to maximum reverse

DEFECT: motion_setpoint_.target_speed_mps_ is NOT clamped to any range. The setpoint_generator only applies acceleration-based smoothing (lines 17-24) but does not enforce output limits. The value can be any result of the accel/decel banding.

command

REQ-COM-002

Output Domain

max_output_speed_mps — Maximum forward speed setpoint output

DEFECT: motion_setpoint_.target_speed_mps_ is NOT clamped to any range. The setpoint_generator only applies acceleration-based smoothing but does not enforce output limits.

command

REQ-COM-002

Output Domain

min_output_yaw_radps — Minimum (most negative) yaw rate setpoint output

DEFECT: motion_setpoint_.target_yaw_rate_radps_ is passed through directly from arbitrated_command_ with no range limiting. No output clamp is applied.

command

REQ-COM-002

Output Domain

max_output_yaw_radps — Maximum yaw rate setpoint output

DEFECT: motion_setpoint_.target_yaw_rate_radps_ is passed through directly with no range limiting.

command

REQ-COM-006

Timing

command_staleness_timeout_ms — Maximum age of remote_command_ before considered stale

DEFECT: Command staleness detection is NOT implemented. The module checks command_authentic_ and remote_command_.valid_ flags but does not track or enforce any timeout for stale commands. No timestamp comparison or age checking exists.

command

REQ-COM-006

Timing

stale_command_plausible_value — Value of plausible_ flag when command input is stale

DEFECT: Since staleness detection is absent, this value cannot be determined from the code. If staleness were detected, the pattern suggests it would be false (consistent with other fault conditions).

actuation

REQ-ACT-001

Input Domain

min_accel_mps2 — Minimum admissible longitudinal acceleration input (typically negative for deceleration)

No input validation or range check is performed on limited_motion_.limited_accel_mps2_. The code silently clamps negative values to zero for drive (line 28) and inverts/clamps for brake (line 17), but does not reject or validate the input range itself. The acceptance range is not enforced.

actuation

REQ-ACT-001

Input Domain

max_accel_mps2 — Maximum admissible longitudinal acceleration input

No upper bound validation on limited_accel_mps2 is present. The code accepts any positive value without clamping or rejection. The acceptance range upper limit is not enforced.

actuation

REQ-ACT-001

Input Domain

min_steering_input_rad — Minimum admissible steering angle input (typically negative for left)

No input validation on limited_motion_.limited_steering_rad_ before clamping. The code clamps to ±max_steering_rad_ but does not validate or reject inputs outside an acceptance range. Input validation is absent.

actuation

REQ-ACT-001

Input Domain

max_steering_input_rad — Maximum admissible steering angle input (typically positive for right)

actuation

REQ-ACT-001

Input Domain

min_safe_stop_decel_mps2 — Minimum admissible safe-stop deceleration (typically zero or slightly negative)

No validation on safe_stop_.target_decel_mps2_ is performed. The value is used directly in max() comparison without range checking. Input acceptance range is not enforced.

actuation

REQ-ACT-001

Input Domain

max_safe_stop_decel_mps2 — Maximum admissible safe-stop deceleration magnitude

No upper bound validation on safe_stop_.target_decel_mps2_. The value is accepted and used without limit checking. Input acceptance range upper limit is not enforced.

actuation

REQ-ACT-002

Output Domain

max_drive_torque_nm — Maximum motor torque command

No upper limit is applied to motor_torque_nm or drive_torque_request_nm_. The computed torque from unclamped acceleration is passed through without saturation. Output range upper bound is not enforced.

actuation

REQ-ACT-002

Output Domain

max_brake_force_n — Maximum brake force

No upper saturation on brake_force_n. The computed force from unclamped deceleration (including emergency_decel_mps2_ from calibration) is used directly without limit checking. Output range upper bound is not enforced.

actuation

REQ-ACT-003

Saturation / Clamping

max_brake_force_limit_n — Upper saturation limit for brake force command

No saturation limit is applied to brake_force_request_n_ or actuator_command_.brake_force_n_. The requirement specifies a max limit, but the code does not enforce one. This is the same finding as max_brake_force_n.

localization

REQ-LOC-001

Input Domain

min_tick_ms — minimum valid system timestamp in milliseconds

No validation of tick_ms_ bounds is performed. The code reads bus.tick_ms_ and performs arithmetic (subtraction, division) without checking minimum value. Missing input validation for timestamp lower bound.

localization

REQ-LOC-001

Input Domain

max_tick_ms — maximum valid system timestamp in milliseconds (typically uint64_t max or practical system limit)

No validation of tick_ms_ bounds is performed. The code reads bus.tick_ms_ and performs arithmetic without checking maximum value. Missing input validation for timestamp upper bound.

localization

REQ-LOC-001

Input Domain

min_encoder_ticks — minimum valid encoder tick count value

No validation of encoder tick range. inject_ticks() directly assigns left_ticks_ and right_ticks_ without checking bounds. Missing input validation for encoder minimum value.

localization

REQ-LOC-001

Input Domain

max_encoder_ticks — maximum valid encoder tick count value

No validation of encoder tick range. inject_ticks() directly assigns left_ticks_ and right_ticks_ without checking bounds. Missing input validation for encoder maximum value.

localization

REQ-LOC-001

Input Domain

min_yaw_rate — minimum valid IMU yaw rate in radians per second

No validation of IMU yaw rate range. inject_imu() directly assigns latest_ without checking yaw_rate_radps_ bounds. Missing input validation for yaw rate minimum.

localization

REQ-LOC-001

Input Domain

max_yaw_rate — maximum valid IMU yaw rate in radians per second

No validation of IMU yaw rate range. inject_imu() directly assigns latest_ without checking yaw_rate_radps_ bounds. Missing input validation for yaw rate maximum.

localization

REQ-LOC-001

Input Domain

min_speed — minimum valid odometry speed value

No validation of computed speed range. speed_mps_ is computed as ds_m / dt_s and assigned to out.speed_mps_ without checking bounds. Missing output validation for minimum speed.

localization

REQ-LOC-001

Input Domain

max_speed — maximum valid odometry speed value

No validation of computed speed range. speed_mps_ is computed as ds_m / dt_s and assigned to out.speed_mps_ without checking bounds. Missing output validation for maximum speed.

localization

REQ-LOC-002

Output Domain

min_x_position — minimum valid x coordinate in meters

No range specification for x position. x_m_ is integrated via x_m_ += ds_m * std::cos(heading_rad_) and assigned to out.x_m_ without bounds validation. Missing output range constraint.

localization

REQ-LOC-002

Output Domain

max_x_position — maximum valid x coordinate in meters

No range specification for x position. x_m_ is integrated via x_m_ += ds_m * std::cos(heading_rad_) and assigned to out.x_m_ without bounds validation. Missing output range constraint.

localization

REQ-LOC-002

Output Domain

min_y_position — minimum valid y coordinate in meters

No range specification for y position. y_m_ is integrated via y_m_ += ds_m * std::sin(heading_rad_) and assigned to out.y_m_ without bounds validation. Missing output range constraint.

localization

REQ-LOC-002

Output Domain

max_y_position — maximum valid y coordinate in meters

No range specification for y position. y_m_ is integrated via y_m_ += ds_m * std::sin(heading_rad_) and assigned to out.y_m_ without bounds validation. Missing output range constraint.

localization

REQ-LOC-002

Output Domain

max_pose_speed — maximum valid pose speed value

No maximum speed constraint is enforced. pose speed is assigned directly from odometry without clamping. Missing output range constraint for maximum speed.

localization

REQ-LOC-003

Saturation / Clamping

clamp_min_x — lower clamp limit on x position in meters

No clamping of x position is performed. x_m_ is updated via integration and directly assigned to out.x_m_ without any clamp operation. Missing output clamping behavior.

localization

REQ-LOC-003

Saturation / Clamping

clamp_max_x — upper clamp limit on x position in meters

No clamping of x position is performed. x_m_ is updated via integration and directly assigned to out.x_m_ without any clamp operation. Missing output clamping behavior.

localization

REQ-LOC-003

Saturation / Clamping

clamp_min_y — lower clamp limit on y position in meters

No clamping of y position is performed. y_m_ is updated via integration and directly assigned to out.y_m_ without any clamp operation. Missing output clamping behavior.

localization

REQ-LOC-003

Saturation / Clamping

clamp_max_y — upper clamp limit on y position in meters

No clamping of y position is performed. y_m_ is updated via integration and directly assigned to out.y_m_ without any clamp operation. Missing output clamping behavior.

localization

REQ-LOC-006

Timing

non_monotonic_tick_behavior — behavior when tick_ms_ is non-monotonic: clamp dt, skip update, error flag

No validation is performed for non-monotonic tick_ms_. If tick_ms_ decreases, dt will be negative, potentially causing incorrect integration. Missing input validation for timestamp monotonicity.

localization

REQ-LOC-006

Timing

validity_debounce_count — number of consecutive cycles required to confirm sensor validity state change

Sensor validity flags are set/cleared immediately based on current conditions without any debounce counter. No multi-cycle confirmation logic is present. Missing debounce mechanism.

localization

REQ-LOC-007

Resource Limits

alive_counter_min_index — minimum valid index for alive_counters_ array

No bounds validation is performed on the alive_counters_ array access. The code assumes module_id::localization is a valid index but does not verify lower bound. Missing bounds checking.

localization

REQ-LOC-007

Resource Limits

alive_counter_max_index — maximum valid index for alive_counters_ array

No bounds validation is performed on the alive_counters_ array access. The code assumes module_id::localization is a valid index but does not verify upper bound. Missing bounds checking.

localization

REQ-LOC-008

State

state_after_first_valid_sensor — module state after first valid sensor injection (e.g., INITIALIZED, RUNNING)

The code has no explicit state machine or state enumeration. The have_last_ flag (line 24) tracks whether dt can be computed, but no formal state transition occurs after first valid sensor data. Missing state management behavior.

localization

REQ-LOC-008

State

state_reset_values — values to which pose state is reset (x, y, heading, confidence)

No state reset mechanism is implemented. Once initialized, x_m_, y_m_, and heading_rad_ are only updated via integration; no code path resets them to initial or other values. Missing reset capability.

localization

REQ-LOC-008

State

state_reset_condition — condition under which pose state is reset (e.g., external command, prolonged invalidity)

No state reset mechanism is implemented. There is no condition under which pose state is reset. Missing reset trigger logic.

motion_control

REQ-MOT-001

Input Domain

min_pose_speed_mps — Minimum admissible pose speed feedback value

The code does not validate or clamp pose_.speed_mps_. The requirement asks for an 'admissible range' but the implementation accepts any value without range checks. This is a missing input validation.

motion_control

REQ-MOT-001

Input Domain

max_pose_speed_mps — Maximum admissible pose speed feedback value

No upper-bound validation on pose_.speed_mps_. The module does not enforce any admissible range on the feedback signal; it trusts the input unconditionally.

motion_control

REQ-MOT-001

Input Domain

min_imu_yaw_rate_radps — Minimum admissible IMU yaw rate feedback value

The code does not validate or clamp imu_.yaw_rate_radps_. The requirement implies an admissible range, but the implementation does not enforce it.

motion_control

REQ-MOT-001

Input Domain

max_imu_yaw_rate_radps — Maximum admissible IMU yaw rate feedback value

No upper-bound validation on imu_.yaw_rate_radps_. Missing input validation.

motion_control

REQ-MOT-005

Fault / Error Reaction

degradation_envelope_formula — Mapping from degradation level to max_accel, max_decel, max_yaw_rate envelopes

The requirement asks for 'degradation-dependent acceleration and yaw rate envelopes' but the code only adjusts the speed envelope. Acceleration and yaw rate limits remain constant regardless of degradation level. This is a missing feature.

motion_control

REQ-MOT-005

Fault / Error Reaction

failsafe_accel_mps2 — Safe acceleration command on invalid input (expected: zero or gentle decel)

The code does not check for invalid input signals (NaN, out-of-range, stale timestamps). No failsafe acceleration value is output on invalid input. This is a missing safety feature.

motion_control

REQ-MOT-005

Fault / Error Reaction

failsafe_steering_rad — Safe steering command on invalid input (expected: zero or hold)

The code does not output a failsafe steering command on invalid input. No input validation is present. This is a missing safety feature.

motion_control

REQ-MOT-005

Fault / Error Reaction

invalid_input_condition — Condition defining invalid inputs (e.g., NaN, out-of-range, stale timestamp)

The code does not define or check for any invalid input condition (NaN, out-of-range, stale timestamp). Input signals are trusted unconditionally. This is a missing safety feature.

motion_control

REQ-MOT-007

Resource Limits

speed_integral_min — Lower bound on speed PID integral accumulator to prevent underflow

The code does not explicitly bound the integral accumulator. Anti-windup prevents further accumulation when saturated, but the integral_ variable itself has no min/max clamp. If the error remains persistently negative before saturation, integral_ can underflow. Missing explicit integral bounds.

motion_control

REQ-MOT-007

Resource Limits

speed_integral_max — Upper bound on speed PID integral accumulator to prevent overflow

No explicit upper bound on the integral accumulator. The anti-windup logic conditionally prevents accumulation but does not clamp the integral term itself. Missing explicit integral bounds.

motion_control

REQ-MOT-007

Resource Limits

steer_integral_min — Lower bound on steering PID integral accumulator to prevent underflow

No explicit lower bound on steering PID integral accumulator. Same finding as speed_integral_min.

motion_control

REQ-MOT-007

Resource Limits

steer_integral_max — Upper bound on steering PID integral accumulator to prevent overflow

No explicit upper bound on steering PID integral accumulator. Same finding as speed_integral_max.

perception

REQ-PER-001

Input Domain

min_ego_speed_mps — minimum admissible ego vehicle speed (expected 0.0 per AOU-003)

No minimum speed validation exists in the code. The module unconditionally uses pose_.speed_mps_ (line 16: 'const float ego_speed = bus.pose_.speed_mps_;') with no lower-bound check. This is a missing input validation requirement.

perception

REQ-PER-001

Input Domain

max_ego_speed_mps — maximum admissible ego vehicle speed for validity check

No maximum speed validation exists in the code. The module unconditionally uses pose_.speed_mps_ with no upper-bound check or clamp. This is a missing input validation requirement.

perception

REQ-PER-001

Input Domain

max_tick_backwards_ms — maximum allowable backwards jump in system timestamp before triggering fault

No tick monotonicity validation exists. The code performs unsigned subtraction (line 28) which will underflow if tick_ms_ goes backwards. No fault is raised for non-monotonic timestamps. This check is absent.

perception

REQ-PER-002

Output Domain

max_obstacle_range_m — maximum LiDAR detection range for obstacles

No maximum range validation. The code accepts any positive range value from the LiDAR scan without an upper limit check. This is a missing sensor-range validation (LiDAR max detection range should be enforced).

perception

REQ-PER-002

Output Domain

min_bearing_rad — minimum bearing angle (likely -π or -π/2)

No bearing range validation. The code uses bearing_rad_ from lidar_point_t without checking if it lies in a valid angular range (e.g., [-π, π]). This is a missing input validation.

perception

REQ-PER-002

Output Domain

max_bearing_rad — maximum bearing angle (likely +π or +π/2)

No bearing range validation. The code uses bearing_rad_ from lidar_point_t without checking if it lies in a valid angular range. This is a missing input validation.

perception

REQ-PER-003

Saturation / Clamping

ttc_clamp_max_s — upper saturation limit for time-to-collision to avoid infinity

No TTC clamping. The code computes ttc and takes the minimum but never clamps to prevent arbitrarily large values when closing_speed is very small. The requirement asks for a max clamp; this is absent.

perception

REQ-PER-003

Saturation / Clamping

min_relative_speed_mps — lower clamp on relative speed (negative = approaching)

No lower clamp on relative_speed. The code computes relative_speed from range deltas (line 113) with no bounds checking. Negative values (approaching) are allowed without limit.

perception

REQ-PER-003

Saturation / Clamping

max_relative_speed_mps — upper clamp on relative speed (positive = receding)

No upper clamp on relative_speed. The code computes relative_speed from range deltas with no bounds checking. Positive values (receding) are allowed without limit.

perception

REQ-PER-005

Fault / Error Reaction

imminent_default_on_fault — safe default value for imminent flag when sensor is faulted

The collision predictor does not gate its outputs on sensor status. It unconditionally processes obstacles regardless of lidar_status_ (failed/stale). There is no safe-default logic for collision_.imminent when the sensor is faulted. This is a missing fault-handling requirement.

perception

REQ-PER-005

Fault / Error Reaction

obstacle_list_fault_behavior — action taken on obstacle list during fault (e.g., 'clear', 'freeze', 'mark_unconfirmed')

The obstacle detector does not check lidar_status_ before processing the scan. When the sensor is failed/stale, it still attempts to cluster and track. There is no fault-gating logic to clear, freeze, or mark obstacles as unconfirmed during sensor faults. This is a missing fault-handling requirement.

perception

REQ-PER-007

Resource Limits

overflow_behavior_scan — action when max_lidar_points reached (e.g., 'truncate', 'reject_scan', 'subsample')

No overflow protection on lidar_scan_. The code copies the injected scan unconditionally (line 26) and processes it without checking against max_lidar_points. If the scan exceeds the expected limit, the code will process all points (subject to clustering capacity limits). There is no truncate/reject/subsample logic for oversized scans.

perception

REQ-PER-009

Concurrency

reentrancy_policy — reentrancy handling (e.g., 'not_reentrant_error', 'not_reentrant_ignored', 'reentrant_safe')

The code has no reentrancy protection. All three perception classes maintain mutable state (tracks_, latest_scan_, injected_, etc.) that would be corrupted by concurrent or reentrant calls to run() or inject_scan(). There is no error detection or handling for reentrancy. This is a missing concurrency safety requirement.

power_management

REQ-PWR-002

Output Domain

output_min_voltage_v — Minimum voltage value reported in power status outputs

The code does NOT bound/clamp the output voltage values in power_main_.voltage_v_ or power_backup_.voltage_v_. The evaluate() function (line 17) directly passes through the input voltage without saturation limits. There is no minimum output voltage constraint implemented.

power_management

REQ-PWR-002

Output Domain

output_max_voltage_v — Maximum voltage value reported in power status outputs

power_management

REQ-PWR-003

Saturation / Clamping

clamp_min_v — Lower saturation limit for voltage measurements

The code does NOT implement voltage clamping/saturation. When voltage measurements exceed physical rail limits, the raw values are passed through unchanged to the output. No minimum clamp is applied before fault detection or output publication.

power_management

REQ-PWR-003

Saturation / Clamping

clamp_max_v — Upper saturation limit for voltage measurements

The code does NOT implement voltage clamping/saturation. When voltage measurements exceed physical rail limits, the raw values are passed through unchanged to the output. No maximum clamp is applied before fault detection or output publication.

cyclic_scheduler

REQ-CYC-003

Saturation / Clamping

max_registered_tasks — Maximum number of tasks that can be registered with the scheduler

No upper bound is enforced. The code does not reject registration when a limit is reached; the requirement specifies rejection behavior that is absent.

cyclic_scheduler

REQ-CYC-003

Saturation / Clamping

max_tasks_per_tick — Maximum number of task callbacks executed in a single tick (may equal max_registered_tasks or be separately limited)

No per-tick execution limit is enforced. The code executes all due tasks without limiting the count, contradicting the requirement.

cyclic_scheduler

REQ-CYC-004

Sign / Units

hz_to_ms_formula — Formula to convert frequency in Hz to period in milliseconds (e.g., period_ms = 1000 / freq_hz)

The requirement specifies Hz-to-ms conversion, but the code provides no frequency parameter or conversion logic. Feature is absent.

cyclic_scheduler

REQ-CYC-005

Fault / Error Reaction

fault_log_destination — Destination for logging task callback exceptions (likely faults_ output)

No exception handling exists around task callback invocation. The requirement mandates catching exceptions and logging faults, but this is entirely absent.

cyclic_scheduler

REQ-CYC-005

Fault / Error Reaction

task_fault_status — The status value assigned to a task that has thrown an exception

No status field or fault marking mechanism exists. The required behavior is not implemented.

cyclic_scheduler

REQ-CYC-005

Fault / Error Reaction

fault_task_policy — Policy determining whether a faulted task is skipped once or permanently disabled

No fault handling policy (skip/disable) is implemented because no exception handling exists.

cyclic_scheduler

REQ-CYC-005

Fault / Error Reaction

uninitialized_bus_error_code — Error code returned when run_tick is called with uninitialized signal_bus_t

No error return mechanism exists (void return type) and no bus initialization validation is performed. The required error code cannot be returned.

cyclic_scheduler

REQ-CYC-006

Timing

max_tick_execution_time_ms — Maximum allowed execution time for all tasks in a single tick (per AOU-002)

No timing budget or max execution time enforcement exists. The requirement specifies completion within a deadline, but no such mechanism is implemented.

cyclic_scheduler

REQ-CYC-008

State

uninitialized_state — Initial state before signal_bus_t initialization (per AOU-004)

The requirement specifies state enforcement (uninitialized, registration, running), but no state variable or transitions exist in the scheduler implementation.

cyclic_scheduler

REQ-CYC-008

State

registration_state — State after initialization where task registration is allowed (per AOU-005)

No state tracking or state-based registration gating is implemented.

100

cyclic_scheduler

REQ-CYC-008

State

running_state — State after first run_tick() where execution occurs and registration is prohibited

No state enforcement preventing registration after execution begins.