# Capitolo 1: Introduzione e Overview del Sistema

[← Torna all'Indice](00_INDEX.md) | [Prossimo: Architettura Software →](02_Architettura_Software_e_Moduli.md)

---

## 1.1 Scopo del Progetto

Il **GRIFO M-PBIT Test Environment** è un sistema di test automatizzato progettato per validare il comportamento del radar GRIFO durante l'esecuzione del **PBIT (Power-On Built-In Test)** - un test diagnostico critico che verifica l'integrità funzionale del sistema radar all'accensione.

### Obiettivi Principali

1. **Automazione Completa**: Eliminare l'intervento manuale nei test ripetitivi
2. **Validazione Estensiva**: Eseguire centinaia di test in sequenza per identificare failure intermittenti
3. **Tracciabilità**: Generare report dettagliati (PDF, CSV, JSON) per ogni esecuzione
4. **Flessibilità**: Supportare sia test su hardware reale che simulazioni senza hardware
5. **Monitoraggio Real-Time**: Interfaccia grafica per visualizzare lo stato dei test durante l'esecuzione

### Contesto Operativo

Il radar GRIFO è un sistema complesso che comunica tramite:
- **Bus 1553**: Messaggi di comando/controllo e telemetria
- **Seriale RS-232**: Output diagnostici, log eventi, messaggi di errore
- **Power Control**: Gestione accensione/spegnimento tramite BrainBox

Il PBIT è un test critico che:
- Verifica l'integrità dei sottosistemi interni
- Rileva failure hardware (processori, memorie, sensori)
- Produce messaggi diagnostici sul bus 1553 e seriale
- Deve completarsi entro ~20 secondi dall'accensione

## 1.2 Architettura Generale

Il sistema è composto da tre layer principali:

```
┌─────────────────────────────────────────────────────────────┐
│                    Test Script Layer                         │
│  ┌───────────────────────────────────────────────────────┐  │
│  │       GRIFO_M_PBIT.py (Main Test Script)             │  │
│  │  - Workflow orchestration                             │  │
│  │  - Scenario management                                │  │
│  │  - Statistics aggregation                             │  │
│  │  - Report generation                                  │  │
│  └───────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                  Framework Layer (env/)                      │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐      │
│  │ leo_grifo_   │  │ leo_grifo_   │  │ leo_grifo_   │      │
│  │ 1553.py      │  │ terminal.py  │  │ io_box.py    │      │
│  │ (1553 bus)   │  │ (Serial)     │  │ (Power)      │      │
│  └──────────────┘  └──────────────┘  └──────────────┘      │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐      │
│  │ leo_grifo_   │  │ test_common_ │  │ leo_grifo_   │      │
│  │ core.py      │  │ function.py  │  │ test_report  │      │
│  │ (Helpers)    │  │ (API)        │  │ .py (PDF)    │      │
│  └──────────────┘  └──────────────┘  └──────────────┘      │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│              Hardware Abstraction Layer                      │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐      │
│  │ interpreter  │  │ pySerial     │  │ BrainBox     │      │
│  │ (SWIG 1553)  │  │ (Serial)     │  │ (Power Ctrl) │      │
│  └──────────────┘  └──────────────┘  └──────────────┘      │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                   Physical Layer                             │
│         [GRIFO Radar Hardware] ←→ [1553 / Serial]           │
└─────────────────────────────────────────────────────────────┘
```

### Separazione Hardware/Simulazione

Un aspetto chiave dell'architettura è la possibilità di eseguire test **con o senza hardware**:

- **Modalità Hardware** (`--target`): Comunica con radar reale via 1553/seriale
- **Modalità Simulazione** (`--simulate`): Usa mock objects che emulano risposte hardware

Questo è possibile grazie al **monkey patching** dei singleton globali:
```python
# In modalità simulate, i singleton reali vengono sostituiti
theGrifo1553 = MockGrifo1553Interface()  # Invece del vero 1553
theBrainBox = MockBrainBox()             # Invece del vero power control
```

## 1.3 Componenti Principali

### 1.3.1 Script di Test (`TestEnvironment/scripts/`)

- **GRIFO_M_PBIT.py**: Script principale di test
- **GRIFO_M_PBIT_mock.py**: Implementazione mock per simulazione
- **GRIFO_M_PBIT_gui.py**: Interfaccia grafica real-time

### 1.3.2 Framework di Test (`TestEnvironment/env/`)

Moduli che implementano l'interfaccia hardware:

| Modulo | Responsabilità | Singleton |
|--------|----------------|-----------|
| `leo_grifo_1553.py` | Comunicazione bus 1553 | `theGrifo1553` |
| `leo_grifo_terminal.py` | Parsing messaggi seriali | N/A |
| `leo_grifo_io_box.py` | Controllo alimentazione | `theBrainBox` |
| `leo_grifo_core.py` | Utilities e recorder | `theRecorder` |
| `test_common_function.py` | API check/get/set | N/A |
| `leo_grifo_test_report.py` | Generazione PDF | `testReport` |

### 1.3.3 Bindings Hardware (`PlatformSimulator/bin/`)

- **interpreter.py**: Wrapper Python SWIG per libreria 1553 C++
- **_interpreter.pyd**: Libreria nativa compilata (Windows DLL)

### 1.3.4 Launcher Scripts

- `run_target.bat`: Esecuzione su hardware reale
- `run_simulate.bat`: Esecuzione in simulazione (Python embedded)
- `run_simulate_simple.bat`: Simulazione con Python di sistema

## 1.4 Requisiti di Sistema

### Hardware (per modalità target)

- **PC Windows** con porte seriali (USB-to-Serial supportato)
- **Scheda 1553** compatibile con libreria interpreter
- **BrainBox** (opzionale) per controllo automatico alimentazione
- **Radar GRIFO** connesso

### Software

- **Python 3.7+** (3.8 raccomandato)
- **Librerie Python**:
  - `pyserial` (comunicazione seriale)
  - `reportlab` (generazione PDF)
  - `tkinter` (GUI - incluso in Python standard)
- **Embedded Python**: Incluso in `PlatformSimulator/bin/` per esecuzioni standalone

### Filesystem

- **Spazio disco**: ~50MB per installazione base + ~10MB per 100 run di test
- **Permessi**: Lettura/scrittura in `TestEnvironment/pdf_reports/`, `TestEnvironment/LOG/`

## 1.5 Flusso di Utilizzo Tipico

### Scenario 1: Test Rapido in Simulazione

```bash
# Dalla root del repository
.\run_simulate_simple.bat
```

**Risultato**: Esegue 10 run di test simulati in ~2 minuti, genera PDF/CSV/JSON in `TestEnvironment/pdf_reports/`

### Scenario 2: Test su Hardware Reale

```bash
# Configurare COM port in test, poi:
.\run_target.bat
```

**Risultato**: Esegue test su radar connesso, controlla alimentazione, genera report

### Scenario 3: Test Custom con GUI

```python
python TestEnvironment/scripts/GRIFO_M_PBIT.py --simulate --runs 50 --scenario random
```

**Risultato**: 50 run con scenario "Random Component Failures", GUI real-time attiva

## 1.6 Vantaggi del Sistema

### Per Sviluppatori

- **Debug Rapido**: Simulazione locale senza hardware
- **Regression Testing**: Validazione automatica dopo modifiche codice
- **Coverage**: Test estensivi su scenari rari (intermittent failures)

### Per Test Team

- **Automazione**: Nessun intervento manuale durante esecuzione
- **Tracciabilità**: Report dettagliati per ogni run
- **Visualizzazione**: GUI mostra progresso in tempo reale

### Per Quality Assurance

- **Ripetibilità**: Test identici eseguibili infinite volte
- **Scenari Configurabili**: Simulazione di failure specifici
- **Statistiche Aggregate**: CSV per analisi trend su centinaia di run

## 1.7 Limitazioni e Considerazioni

### Simulazione vs Hardware Reale

- **Simulazione**: Veloce, deterministico, ma non sostituisce test su hardware
- **Hardware Reale**: Cattura problemi timing-dependent, race conditions, failure intermittenti

### Copertura dei Test

Il sistema valida:
- ✅ Funzionalità PBIT (test diagnostici B6/B8)
- ✅ Messaggi seriali e log eventi
- ✅ Rilevamento target (scenario TgtGen)

Non valida:
- ❌ Funzionalità radar operative (tracking, modalità operative)
- ❌ Performance real-time in missione
- ❌ Integrazione con sistemi di piattaforma

### Manutenzione

- **Known Failures**: Lista failure noti va mantenuta aggiornata
- **ICD Changes**: Modifiche al protocollo 1553 richiedono aggiornamenti codice
- **Mock Updates**: Mock objects devono riflettere comportamento hardware reale

---

[← Torna all'Indice](00_INDEX.md) | [Prossimo: Architettura Software →](02_Architettura_Software_e_Moduli.md)
