# 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.