57 lines
5.2 KiB
Markdown
57 lines
5.2 KiB
Markdown
# 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. |