Skip to content

Development Roadmap

Jump to bottom
David Young edited this page Aug 5, 2025 · 7 revisions

Development Roadmap (Updated August 2025)

This roadmap has been updated to reflect the significant progress made and the strategic decisions taken during the first half of the MSc project. The successful development of an initial UI prototype has clarified the core requirements and validated the need for a dedicated "World Builder." The project is now entering a new phase, focusing on a more robust technology stack for the UI and tackling critical feature implementations and reliability enhancements in the FERS C++ backend.

Guiding Principles for Development:

  • Usability First: The FERS World Builder must be the most intuitive and effective tool for visually configuring complex radar simulations.
  • Decoupled Architecture: The UI (frontend) and FERS (backend) will remain separate applications, communicating via XML files and command-line calls. This ensures modularity and maintainability.
  • Validation and Reliability: All new and existing backend functionality will be rigorously tested against theoretical models and use cases.
  • Feature-Driven Enhancements: Identified bugs and limitations in the core engine will be treated as opportunities to refactor and improve the underlying models, rather than applying simple patches.

Phase 1: Current Core Focus

This phase represents the highest-priority work, focusing on delivering the two flagship components of the MSc research.

[High Priority] Next-Generation FERS World Builder (UI)

The initial Godot-based UI was a successful prototype that proved the concept and value of a visual scenario editor. The project is now pivoting to a more powerful and sustainable technology stack to deliver a production-quality tool.

  • Objective: Develop a standalone desktop application for visually creating, editing, and visualizing FERS simulation scenarios.
  • Technology Stack: React (UI), CesiumJS (3D Globe), and Electron (Desktop Wrapper).
  • Key Features:
    • An interactive, high-fidelity 3D globe for geolocated scenario building.
    • Intuitive tools to add, place, and edit platforms, targets, and their properties.
    • Visualization of motion paths, boresight directions, and antenna coverage hints.
    • Full import/export of FERS XML scenario files.
    • Integrated controls to run the FERS backend directly and manage simulations.

[High Priority] Implement FMCW Radar Simulation Support (#44)

This is the most critical feature addition for the FERS backend, expanding its capabilities to a widely used radar mode.

  • Objective: Add robust, end-to-end support for Frequency-Modulated Continuous Wave (FMCW) radar simulations.
  • Key Tasks:
    • Implement internal de-chirping and mixing in the receiver model (#50).
    • Define and implement a clear XML schema for FMCW configuration (#51).
    • Enhance signal generation to support flexible chirp parameters (#52).
    • Develop a comprehensive validation and testing strategy for the FMCW mode (#53).

Phase 2: Backend Reliability and Core Model Enhancements

Once the primary MSc deliverables are functional, the focus will shift to addressing critical architectural limitations and bugs in the FERS backend. This work is crucial for transforming FERS from a specialized academic tool into a robust, general-purpose engineering simulator. The approach will be to refactor and redesign core components, treating these items as feature enhancements rather than simple bug fixes.

[High Priority] Core Model and Simulation Logic Overhaul

This group of tasks addresses major known issues that impact the physical accuracy and validity of simulation results, particularly in multi-static and CW scenarios.

  • Major Bug: Incorrect Waveform Transformation for Moving Transmitters (#54)

    • The Flaw: The current signal rendering engine simplifies the physics by applying a single total delay and phase shift. This fails to model the critical time-scaling (compression/dilation) of the waveform envelope that occurs on the first leg of a bistatic path (e.g., from a moving transmitter to a target).
    • Impact: This architectural limitation makes the simulation physically inaccurate for scenarios with moving transmitters, as any waveform-dependent processing (like pulse compression) will yield incorrect results.
    • The Fix: This requires a fundamental redesign of the response renderer to correctly model the two-step nature of waveform transformation in a general bistatic environment.

  • Redesign of Oscillator Offset and Noise Features (#56, #55)

    • The Flaw: The random_freq_offset and random_phase_offset features are fundamentally broken. The current implementation fails to maintain phase continuity between pulses, introducing massive spurious signals in the Doppler spectrum. This makes the simulator unreliable for analyzing coherent multi-static systems.
    • The Fix: This requires a complete redesign of how timing and phase offsets are managed and applied, ensuring state is correctly preserved across pulse intervals and simulation time.

  • Refactor Continuous Wave (CW) Mode to Replace 'Long Pulse' Hack (#59)

    • The Flaw: CW mode is currently simulated by treating the signal as a single, extremely long pulse. This is highly inefficient in terms of memory and computation, and it breaks the assumptions of other simulation components.
    • The Fix: Implement a native, algorithm-driven CW signal generation and processing path within the simulation engine that is not dependent on the pulse-centric architecture.

  • Systemic Noise Model and Signal Chain Review

    • The Flaw: The order of operations in the receiver chain is suspect, and the noise models are not considered fully reliable. The incorrect application of thermal noise, receiver gain, and phase noise can lead to inaccurate SNR calculations and untrustworthy performance predictions.
    • The Fix: A systematic review and refactoring of the entire receiver signal chain is needed to ensure all noise sources and impairments are applied in the correct physical order (#58).

  • Resolve Race Condition in Global Random Number Generator (#57)

    • The Flaw: The use of a global, non-thread-safe random number generator creates a race condition in multi-threaded simulations, leading to non-deterministic and potentially correlated noise samples.
    • The Fix: Implement a thread-safe random number generation strategy, likely by providing each thread with its own generator instance.

[Medium Priority] Performance and Codebase Improvements

  • Improve Upsampling and Downsampling Implementations (#18): Replace inefficient FIR filters with optimized polyphase filter banks for multirate signal processing (#19, #20).
  • HDF5 Output Enhancements:
    • Implement incremental chunking to reduce memory usage for large simulations (#49).
    • Rework the rendering pipeline to parallelize processing by window (#48).
  • Noise Model Refinement: Address limitations in the 1/f^alpha noise model, including fixing the refill() double application bug (#23).

Phase 3: Foundational and Long-Term Vision

This phase includes important features and infrastructure work that builds upon a stable and reliable FERS platform.

[Medium Priority] Simulation Capability Extensions

  • Target Model Enhancements: Investigate and implement target polarization scattering effects (#43).
  • Basic Clutter Models: Introduce initial models for simulating environmental clutter.
  • ADC Model Enhancements: Incorporate common real-world ADC impairments.

[Low Priority] Build and Maintainability

  • Investigate Migrating to C++20/23 Modules (#45): Evaluate migrating from traditional headers to improve compilation times and code organization.
  • Overhaul Testing Strategy (#40): Implement a modern unit testing framework (#41) and expand the regression test suite (#42).
  • Improve Project Infrastructure (#35): Implement CI/CD workflows, issue/PR templates, and improve documentation hosting.

Completed / In-Progress

  • KML Visualizer Integration: The standalone KML generator has been successfully refactored and integrated into the FERS backend. It is now available as a command-line export option, providing geodetically-accurate KML files for visualization in tools like Google Earth.
  • Godot UI Prototype: A comprehensive UI prototype was built using the Godot engine. This effort successfully validated the core concepts of a visual "World Builder" and informed the strategic decision to pivot to a more robust web-based technology stack.

Deprioritized / Descoped Features

The following features have been explicitly deprioritized or descoped to align with the project's refined focus on providing a powerful World Builder and a raw signal-level backend.

  • Integrated Post-Processing & Analysis Tools: The UI will not include built-in analysis plots (e.g., Range-Doppler maps). The project's philosophy is to provide raw I/Q data, allowing engineers to use their own preferred post-processing tools.
  • In-Software Asset Creation: The UI will focus on configuring simulation elements, not designing fundamental assets like signal waveforms or complex antenna patterns from scratch. These will continue to be defined in external files.
  • Python Integration: The legacy Python integration will be fully removed from the FERS backend to improve maintainability and eliminate versioning conflicts (#46).

Home

Functionality Overview

Core Simulation Models & Physics
Simulation Engine & Architecture
Input, Output & External Interfaces

Clone this wiki locally