| # | Module | Requirement | Question (value to supply) |
|---|
| 1 | comms | REQ-COM-001 | max_tick_ms — The code does not specify a practical maximum; this is a system integration decision (e.g., mission duration, reboot policy). The type permits up to UINT64_MAX. |
| 2 | comms | REQ-COM-009 | execution_order_sequence — The execution order is an integration-level decision made by the main control loop (likely in a module not provided here). The comms module does not self-schedule its submodules. |
| 3 | safety | REQ-SAF-004 | coordinate_frame — The code uses X and Y coordinates from pose but does not specify the coordinate frame (ENU, vehicle, map, etc.). This must be documented in the pose_t interface specification or system architecture. |
| 4 | safety | REQ-SAF-006 | cycle_period_ms — The modules do not control or know their own invocation period. This is a system-level scheduling parameter that must be provided by the integration/scheduling layer. |
| 5 | safety | REQ-SAF-007 | max_faults_limit — The value max_faults is referenced but its definition is in signal_bus.hpp (not provided). This is a system-wide constant defining fault array capacity. |
| 6 | safety | REQ-SAF-007 | max_occurrence_count — The occurrence_count_ field is incremented unbounded (line 98). The maximum is determined by the fault_entry_t.occurrence_count_ field type, which must be specified in signal_bus.hpp. |
| 7 | safety | REQ-SAF-009 | execution_order_aou — The code comment implies fault_memory runs after fault-generating modules, but no explicit AOU-002 reference exists in the source. This assumption must be documented in the system architecture or MODULES.md. |
| 8 | safety | REQ-SAF-009 | estop_injection_caller — The comment indicates simulation/tests call inject_local_estop() but does not specify the production integration entity. This must be defined in the hardware abstraction layer interface specification or AOU-008. |
| 9 | safety | REQ-SAF-009 | estop_injection_aou — The code does not reference AOU-008. The assumption that inject_local_estop() is called before run() must be documented in the system integration specification or assumptions of use document. |
| 10 | supervision | REQ-SUP-006 | supervision_cycle_period_ms — The module code does not and should not hardcode its scheduling period. This is a deployment/integration configuration decision (RTOS tick rate, cyclic executive period, etc.). |
| 11 | command | REQ-COM-004 | yaw_rate_sign_convention — USER DECISION REQUIRED: The code treats yaw rate as a signed value in radians/sec but does not specify the vehicle coordinate frame convention (positive left turn vs. positive right turn). This is a vehicle-level configuration choice. |
| 12 | command | REQ-COM-006 | cycle_jitter_tolerance_ms — USER DECISION REQUIRED: The code assumes exactly 20ms cycles (setpoint_generator.hpp:20) but does not implement jitter detection or tolerance enforcement. Timing tolerance is a scheduler / RTOS configuration decision not enforced by this module. |
| 13 | actuation | REQ-ACT-004 | positive_steering_direction — The code passes steering angle through without interpretation or sign convention enforcement. The physical meaning (left/right) depends on vehicle hardware configuration and is not specified in the actuation module code. This is a system-level convention that must be provided by integration documentation. |
| 14 | actuation | REQ-ACT-005 | emergency_decel_value_mps2 — The emergency deceleration is a calibration parameter (cal_.emergency_decel_mps2_) whose value must be supplied by the customer/integrator via ugv_calibration_t. The code does not hardcode this safety-critical tuning value. |
| 15 | actuation | REQ-ACT-006 | alive_counter_modulo — The wrap-around modulo depends on the data type of alive_counters_[]. The code uses native unsigned integer overflow behavior, but the array element type is not visible in these files. The modulo value (256 for uint8_t, 65536 for uint16_t, etc.) must be determined from the signal_bus_t definition. |
| 16 | actuation | REQ-ACT-007 | actuation_module_id_value — The numeric value of the module_id::actuation enumeration constant is not defined in the provided source files. This must come from the module_id enum definition (likely in app/signal_bus.hpp or app/ugv_config.hpp not provided). |
| 17 | actuation | REQ-ACT-007 | alive_counters_array_size — The size of the alive_counters_ array is not defined in the provided source files. This must come from the signal_bus_t structure definition (not provided in these files). |
| 18 | actuation | REQ-ACT-009 | input_read_phase — The actuation modules read inputs via signal_bus_t& reference, but the code does not enforce or document the timing of when this snapshot is taken relative to the cycle. This is a system-level integration concern determined by the task scheduler/executor, not implemented in the actuation module itself. |
| 19 | actuation | REQ-ACT-009 | output_write_deadline — The code writes all outputs before returning from actuator_interface::run(), but the deadline relative to other system tasks (e.g., before actuator_interface is invoked) is a system-level scheduling constraint not enforced in this module code. |
| 20 | localization | REQ-LOC-006 | staleness_threshold_ms — The staleness threshold is read from calibration parameter cal_.imu_stale_timeout_ms_. This is a tuning parameter that must be supplied by the user/configuration; the code does not hardcode a specific value. |
| 21 | localization | REQ-LOC-006 | nominal_cycle_time_ms — The code computes actual cycle time dynamically from timestamp deltas; no nominal cycle time constant is hardcoded. This is an operational assumption external to the code (depends on scheduler/caller behavior). |
| 22 | motion_control | REQ-MOT-004 | positive_yaw_direction — The code treats yaw rate as a signed scalar but does not specify whether positive is left (CCW) or right (CW). This is a vehicle coordinate frame convention that must be supplied by the integration team or system spec. |
| 23 | motion_control | REQ-MOT-004 | positive_steer_direction — The code treats steering as a signed scalar but does not specify whether positive is left or right. This is a vehicle-specific mechanical convention. |
| 24 | motion_control | REQ-MOT-009 | execution_order_dependency — The motion module source does not contain scheduling logic. The requirement states speed_controller and steering_controller must execute before trajectory_limiter, but the mechanism enforcing this (e.g., explicit sequencing in main.cpp, dependency graph) is not visible in the motion module code. This is a system-level integration detail. |
| 25 | perception | REQ-PER-004 | bearing_sign_convention — The code does not specify whether positive bearing is left/right or clockwise/counterclockwise. This is a coordinate-frame / sensor-mounting decision that must be provided by the integration specification or calibration documentation. |
| 26 | perception | REQ-PER-006 | lidar_stale_timeout_ms — This is a calibration parameter from the ugv_calibration_t structure. The value is application-specific (depends on sensor update rate, latency tolerance, safety margins). The customer/integrator must specify this timeout based on system requirements. |
| 27 | perception | REQ-PER-006 | obstacle_confirmation_cycles — This is a calibration parameter from ugv_calibration_t. The number of consecutive detection cycles required to confirm a track is a tuning decision balancing false-positive suppression vs. detection latency. The customer must specify this based on operational requirements. |
| 28 | perception | REQ-PER-006 | obstacle_deletion_cycles — This is a calibration parameter from ugv_calibration_t. The number of non-detection cycles before deleting a track is a tuning decision balancing memory/clutter vs. track persistence through occlusions. The customer must specify this based on operational requirements. |
| 29 | perception | REQ-PER-006 | run_cycle_period_ms — The module execution period is determined by the application scheduler (not visible in perception source). This is an integration/deployment parameter that the customer must specify based on the control loop design and real-time requirements. |
| 30 | power_management | REQ-PWR-001 | min_physical_voltage_v — The code uses min_voltage_v_ as an undervoltage fault threshold but does NOT implement input validation to reject physically implausible sensor readings. The actual minimum plausible voltage must be supplied by the customer based on sensor specifications and expected operating environment. The fault threshold (min_voltage_v_) may differ from sensor range limits. |
| 31 | power_management | REQ-PWR-001 | max_physical_voltage_v — The code uses max_voltage_v_ as an overvoltage fault threshold but does NOT implement input validation to reject physically implausible sensor readings. The actual maximum plausible voltage must be supplied by the customer based on sensor specifications and expected operating environment. The fault threshold (max_voltage_v_) may differ from sensor range limits. |
| 32 | power_management | REQ-PWR-004 | nominal_voltage_v — The nominal_voltage_v_ is a calibration parameter (cal_.nominal_voltage_v_) used as the default/initialization value for voltage measurements. This is a system design parameter that must be supplied by the customer based on the electrical architecture (e.g., 12V, 24V, 48V system). The code references it but does not define a concrete value. |
| 33 | power_management | REQ-PWR-006 | cycle_period_ms — The execution period of the power management task is a system-level configuration parameter not defined in the power_supply or power_distribution modules. This must be specified in the task scheduler configuration or system integration layer by the customer based on timing requirements. |
| 34 | power_management | REQ-PWR-009 | task_sequence_position — The task execution order is a system-level scheduler configuration not defined within the power_supply or power_distribution modules. The customer must configure the task scheduler to ensure power_supply::run() executes before power_distribution::run() in each cycle. The specific sequence position or priority values depend on the RTOS/scheduler implementation. |
| # | Module | Requirement | Ambiguity |
|---|
| 1 | comms | REQ-COM-008 | initial_link_state — AMBIGUOUS: The code logic produces 'lost' on first cycle if no frame arrives, but the signal_bus_t constructor's initial state for link_status_.state_ is not visible in the provided files. Human must verify signal_bus default initialization. |
| 2 | supervision | REQ-SUP-008 | initial_vehicle_mode — The supervision module does not initialize vehicle_mode_ to init; it assumes this is done by the signal bus or application initialization. This initialization responsibility is ambiguous and should be clarified. |
| 3 | command | REQ-COM-008 | remote_mode_condition — AMBIGUITY: Remote operator is selected based only on plausible_command_.plausible_ (line 26), with NO explicit vehicle_mode_ check. This differs from the requirement pattern which expects a mode check. The code allows remote commands in any mode (other than safe-stop or autonomous), which may be intentional but contradicts the requirement's expectation of a specific remote_mode_condition. |
| 4 | localization | REQ-LOC-008 | initial_confidence — Confidence is computed from scratch each cycle (starting at 1.0, then degraded). There is no explicit initialization of a persistent confidence state. The first output will have confidence based on first-cycle sensor validity (potentially 0.0, 0.5, or 1.0). Ambiguous what 'initial confidence' means: first output value or a persistent initial state. |
| 5 | localization | REQ-LOC-009 | alive_counter_sync — The counter is incremented with plain ++ operator, no std::atomic or mutex protection. If the code is single-threaded this is safe; if multi-threaded this is a data race. The code does not indicate thread safety provisions—requires review of system architecture. |
| 6 | motion_control | REQ-MOT-007 | alive_counter_modulo — The alive counter is incremented but the type of alive_counters_[module_id::motion] is not defined in the provided motion source files. The modulo depends on the underlying type (likely uint8_t -> 256, but must be confirmed from signal_bus definition). |
| 7 | motion_control | REQ-MOT-007 | alive_counter_type — The data type of alive_counters_[module_id::motion] is not visible in the motion module source files. Must be determined from the signal_bus definition. |
| 8 | perception | REQ-PER-008 | ok_status_value — Slot left unresolved by the fill pass; manual review required. |
| 9 | perception | REQ-PER-008 | stale_status_value — Slot left unresolved by the fill pass; manual review required. |
| 10 | perception | REQ-PER-009 | injection_run_ordering — The code is designed expecting inject_scan() before run() (line 14-18 checks injected_ flag), but it is permissive: if inject_scan() was not called, run() uses stale data or marks sensor as failed. There is no explicit error or enforcement of the ordering. The requirement's intent ('required' vs. 'optional') is ambiguous in the implementation. |
| 11 | power_management | REQ-PWR-007 | counter_max_value — The alive_counters_ array element is incremented but its underlying data type is not defined in the provided sources. If uint32_t, the max is 2^32-1 (4294967295). If uint8_t, max is 255. The actual type must be confirmed from signal_bus_t definition to determine the exact maximum value before wraparound. |