S1005403_RisCC/doc/manual/01_introduzione.md

Capitolo 1: Introduzione

1.1. Scopo dell'Applicazione

Il Radar Target Simulator è un'applicazione software progettata per l'ambiente di sviluppo e test di sistemi radar. Il suo scopo primario è generare e trasmettere dati di traccia sintetici (target simulati) verso un'unità di elaborazione radar (chiamata "server" o "device under test") per verificarne il comportamento e le prestazioni di tracciamento.

L'applicazione consente di:

• Creare scenari complessi: Definire uno o più target, ciascuno con una traiettoria tridimensionale programmabile composta da segmenti di volo (waypoint) e manovre dinamiche.
• Simulare il movimento: Eseguire una simulazione in tempo reale (o accelerato) che aggiorna lo stato cinematico di tutti i target secondo le traiettorie definite.
• Trasmettere i dati: Inviare gli stati dei target al sistema radar tramite diversi protocolli di comunicazione (SFP, TFTP, Seriale).
• Ricevere e visualizzare dati reali: Acquisire i dati di traccia elaborati dal sistema radar e visualizzarli in tempo reale su un Plan Position Indicator (PPI).
• Analizzare le prestazioni: Confrontare i dati "ground truth" della simulazione con i dati ricevuti dal radar per calcolare metriche di errore e valutare l'accuratezza del tracciamento.

L'applicazione è uno strumento fondamentale per il test "hardware-in-the-loop", permettendo di validare algoritmi di tracciamento radar in un ambiente controllato e ripetibile, senza la necessità di asset fisici reali.

1.2. Architettura di Alto Livello

L'applicazione è costruita su un'architettura modulare che separa l'interfaccia utente dalla logica di simulazione e comunicazione. I componenti principali interagiscono come mostrato nel diagramma seguente.

(Placeholder per l'immagine)

Descrizione dell'Immagine: architettura_alto_livello.png Qui ti aspetti di vedere un diagramma a blocchi. Disegna quattro riquadri principali:

1. Un riquadro grande a sinistra etichettato "Interfaccia Utente (GUI - MainView)".
2. Un riquadro a destra etichettato "Motore di Simulazione (SimulationEngine - Thread)".
3. Un riquadro in basso a destra etichettato "Gestore Comunicazione (CommunicatorManager)". Questo blocco si collega a sua volta a blocchi più piccoli per "SFP", "TFTP", "Seriale".
4. Un riquadro centrale, connesso a tutti gli altri, etichettato "Hub Dati di Stato (SimulationStateHub)". Disegna frecce per mostrare le interazioni:

• GUI -> SimulationEngine (Avvia/Ferma Simulazione, Carica Scenario).
• SimulationEngine -> SimulationStateHub (Scrive "Dati Simulati").
• SimulationEngine -> CommunicatorManager (Invia comandi tgtset).
• CommunicatorManager -> SimulationStateHub (Scrive "Dati Reali" ricevuti dal radar).
• SimulationStateHub -> GUI (Fornisce dati per aggiornare PPI, tabelle, etc.).

---

I componenti chiave sono:

• Interfaccia Utente (GUI - MainView): Basata su Tkinter, è il punto di controllo centrale per l'utente. Gira sul thread principale e orchestra tutte le operazioni. È responsabile della visualizzazione dei dati (PPI, log, tabelle) e della cattura degli input utente.

• Motore di Simulazione (SimulationEngine): Un thread separato che gestisce il ciclo di vita della simulazione. A intervalli regolari, calcola il nuovo stato di ogni target attivo e invia gli aggiornamenti al gestore della comunicazione. Funziona in background per non bloccare l'interfaccia utente.

• Hub Dati di Stato (SimulationStateHub): È il "cuore" thread-safe dell'applicazione. Funge da database in memoria che raccoglie e centralizza tutti i dati di stato, sia quelli generati dal simulatore (simulated) sia quelli ricevuti dal radar (real). Tutti gli altri componenti leggono e scrivono da questo hub, garantendo la coerenza dei dati tra i diversi thread.

• Gestore della Comunicazione (CommunicatorManager e interfacce): Un livello di astrazione che gestisce i diversi protocolli di comunicazione. Riceve comandi di alto livello (es. "invia questo scenario") e li traduce in comandi specifici del protocollo selezionato (es. una serie di comandi seriali o un singolo payload JSON su SFP).

Questa architettura disaccoppiata permette di modificare o aggiungere un protocollo di comunicazione senza impattare il motore di simulazione, o di cambiare l'interfaccia grafica senza alterare la logica di calcolo.

1.3. A chi è rivolto questo manuale

Questo documento è stato redatto per un pubblico tecnico:

• Sviluppatori Software: Che necessitano di comprendere il flusso dei dati, le responsabilità di ogni modulo e le convenzioni di codice per manutenere o estendere l'applicazione.
• Ingegneri di Test e Validazione: Che usano l'applicazione per testare sistemi radar e hanno bisogno di comprendere in dettaglio come vengono generati i dati, come configurare scenari complessi e come interpretare i risultati dell'analisi.
• Utenti Avanzati: Che desiderano sfruttare al massimo le funzionalità dell'applicazione, inclusi gli strumenti di debug e la configurazione avanzata.

Questo manuale non è inteso come una guida rapida per l'utente finale, per la quale verrà prodotta una documentazione separata e più sintetica.