La soluzione completa dei quesiti 1 e 2 della simulazione di Sistemi e Reti 2026 sul tema smart-road, con ipotesi progettuali e architettura di rete.
Sei alla ricerca dello svolgimento completo della simulazione della seconda prova di Maturità 2026? In questo articolo trovi la soluzione dettagliata per la materia Sistemi e Reti, incentrata sul progetto smart-road.
Analizziamo nel dettaglio il Quesito 1 e il Quesito 2 della seconda parte, applicando le corrette ipotesi aggiuntive per la progettazione dell'infrastruttura di rete e del database.
📄 Scarica il PDF completo della soluzione — tutti i passaggi e i grafici, pronti da stampare.
🗂️ File sorgente della prova: pagina 1 · pagina 2
Vuoi risolvere la tua prova così? Prova il Risolutore Prove AI.
Seconda parte
PROPOSTA DI SOLUZIONE — Seconda Prova di Maturità
Sistemi e Reti, 2026
Svolgimento di due quesiti della Seconda Parte (Quesito 1 e Quesito 2) relativi al progetto smart-road.
Ipotesi aggiuntive:
* Si assume che l'identificazione spaziale delle stazioni avvenga tramite l'identificativo dell'autostrada e la progressiva chilometrica.
* Si assume che i punti di ricarica siano caratterizzati da una potenza nominale espressa in kW.
* Si assume che l'autenticazione dell'APP mobile avvenga tramite token (es. standard JWT) trasmesso negli header HTTP, omettendo la fase di login dalla presente trattazione per concentrarsi sulle funzionalità core.
Quesito 1
Progettazione a livello logico del database relazionale per la gestione dello stato e delle prenotazioni dei punti di ricarica.
Si procede alla modellazione dei dati definendo le entità principali: Stazione, Punto_Ricarica, Utente e Prenotazione.
erDiagram
STAZIONE ||--o{ PUNTO_RICARICA : "ospita"
UTENTE ||--o{ PRENOTAZIONE : "effettua"
PUNTO_RICARICA ||--o{ PRENOTAZIONE : "riceve"
STAZIONE {
INT id_stazione PK
VARCHAR nome
VARCHAR autostrada
DECIMAL km
}
PUNTO_RICARICA {
INT id_punto PK
INT id_stazione FK
INT potenza_kw
VARCHAR stato_operativo
}
UTENTE {
INT id_utente PK
VARCHAR email
VARCHAR targa_veicolo
}
PRENOTAZIONE {
INT id_prenotazione PK
INT id_utente FK
INT id_punto FK
DATETIME orario_arrivo
INT durata_minuti
VARCHAR stato_prenotazione
}
Dallo schema concettuale si deriva il seguente schema logico relazionale. Le chiavi primarie sono indicate con PK (Primary Key) e sottolineate, le chiavi esterne con FK (Foreign Key) e in corsivo.
- STAZIONE (id_stazione, nome, autostrada, km)
- PUNTO_RICARICA (id_punto, potenza_kw, stato_operativo, id_stazione)
- UTENTE (id_utente, email, targa_veicolo)
- PRENOTAZIONE (id_prenotazione, orario_arrivo, durata_minuti, stato_prenotazione, id_utente, id_punto)
Dizionari dei dati e vincoli:
* $stato\_operativo$: dominio ristretto ai valori {'DISPONIBILE', 'OCCUPATO', 'GUASTO', 'IN_MANUTENZIONE'}.
* $stato\_prenotazione$: dominio ristretto ai valori {'ATTIVA', 'COMPLETATA', 'ANNULLATA'}.
* Vincolo di integrità referenziale: $PUNTO\_RICARICA.id\_stazione \subseteq STAZIONE.id\_stazione$.
* Vincolo di integrità referenziale: $PRENOTAZIONE.id\_utente \subseteq UTENTE.id\_utente$.
* Vincolo di integrità referenziale: $PRENOTAZIONE.id\_punto \subseteq PUNTO\_RICARICA.id\_punto$.
Quesito 2
Individuazione della tecnologia di comunicazione a livello applicativo e documentazione del protocollo per l'interazione tra APP e database nazionale.
Si individua come tecnologia di comunicazione l'architettura REST (Representational State Transfer) su protocollo HTTPS (Hypertext Transfer Protocol Secure). Il formato di interscambio dati scelto è JSON (JavaScript Object Notation). Questa soluzione garantisce interoperabilità, leggerezza nei payload (ideale per dispositivi mobili) e sicurezza crittografica del canale.
Si definisce il Base URL dell'API: https://api.smartroad.it/v1
Di seguito si documenta un estratto del protocollo applicativo (Web API) per le due operazioni fondamentali richieste: la verifica dello stato e l'inserimento di una prenotazione.
1. Verifica dello stato dei punti di ricarica di una stazione
* Endpoint: /stazioni/{id_stazione}/punti-ricarica
* Metodo HTTP: GET
* Descrizione: Restituisce l'elenco dei punti di ricarica associati a una specifica stazione e il loro stato in tempo reale.
* Request: Nessun body.
* Response (Successo - Status Code $200$ OK):
json
[
{
"id_punto": 101,
"potenza_kw": 150,
"stato_operativo": "DISPONIBILE"
},
{
"id_punto": 102,
"potenza_kw": 350,
"stato_operativo": "OCCUPATO"
}
]
2. Inserimento di una nuova prenotazione
* Endpoint: /prenotazioni
* Metodo HTTP: POST
* Descrizione: Crea una nuova prenotazione per un punto di ricarica specifico.
* Request Body (JSON):
json
{
"id_utente": 4582,
"id_punto": 101,
"orario_arrivo": "2026-06-15T14:30:00Z",
"durata_minuti": 45
}
* Response (Successo - Status Code $201$ Created):
json
{
"id_prenotazione": 98765,
"stato_prenotazione": "ATTIVA",
"messaggio": "Prenotazione confermata con successo."
}
* Response (Errore - Status Code $409$ Conflict): Restituito qualora il punto di ricarica risulti già prenotato per la fascia oraria richiesta.
json
{
"errore": "Punto di ricarica non disponibile per l'orario selezionato."
}
Quesito 1
PROPOSTA DI SOLUZIONE — Seconda Prova di Maturità
Sistemi e Reti, 2026
Progetto dell'infrastruttura tecnologica e informatica per il sistema smart-road.
Ipotesi aggiuntive:
Per il dimensionamento e la scelta delle tecnologie, si assumono le seguenti ipotesi:
1. Ogni Centro di Controllo gestisce un tratto autostradale di lunghezza $L = 50 \text{ km}$, comprendente pertanto $50$ smart-gate.
2. L'ente gestore dispone di un cavidotto proprietario lungo l'infrastruttura autostradale per la posa di portanti fisici (fibra ottica) e linee di alimentazione elettrica.
3. Le stazioni di ricarica sono distribuite nelle aree di servizio con una densità media di una ogni $30 \text{ km}$.
Punto a)
Il progetto richiede di definire l'architettura della rete e le caratteristiche dei sistemi di elaborazione nei vari nodi, motivandone tipologia e collocazione.
Si adotta un'architettura gerarchica distribuita basata sul paradigma Edge-Fog-Cloud, ideale per sistemi IoT su larga scala che richiedono bassa latenza per decisioni locali e grande capacità di archiviazione centralizzata.
1. Livello Edge: Smart-Gate (Collocazione: ogni $1 \text{ km}$ lungo la tratta)
Essendo richiesto che gli smart-gate elaborino localmente le informazioni e impostino autonomamente la segnaletica, è necessario dotare ogni nodo di capacità computazionale (Edge Computing).
* Sistema di elaborazione: Industrial IoT Gateway / Edge PC. Si scelgono dispositivi "rugged" (privi di ventole, resistenti a vibrazioni e ad ampi range di temperatura, es. $-40^\circ\text{C} \dots +70^\circ\text{C}$). Devono essere dotati di acceleratori hardware (NPU/GPU) per l'elaborazione in tempo reale dei flussi video delle telecamere (riconoscimento targhe e tipologia veicoli tramite reti neurali) senza saturare la banda di rete verso il centro di controllo.
* Motivazione: L'elaborazione locale riduce drasticamente la latenza di intervento (es. avviso immediato di veicolo contromano o nebbia) e minimizza la quantità di dati grezzi da trasmettere sulla dorsale.
2. Livello Fog: Centro di Controllo (Collocazione: uno per ogni tratta sperimentale, es. ogni $50 \text{ km}$)
* Sistema di elaborazione: Cluster di server in alta affidabilità (HA) e workstation grafiche per gli operatori umani.
* Motivazione: Funge da aggregatore locale. Riceve i metadati dagli smart-gate (es. "traffico intenso", "targa XYZ rilevata") e i flussi video solo su richiesta dell'operatore. Permette la supervisione umana e l'override manuale delle decisioni prese dagli algoritmi Edge. La collocazione zonale garantisce la continuità operativa del tratto anche in caso di isolamento dalla rete nazionale.
3. Livello Cloud: Rete Nazionale e Database (Collocazione: Datacenter centralizzato / Cloud Provider)
* Sistema di elaborazione: Infrastruttura Cloud (IaaS/PaaS) comprendente server per l'ingestion dei dati, cluster per database relazionali/NoSQL (Big Data) e server applicativi (API Gateway).
* Motivazione: Necessario per aggregare i dati di tutti i centri di controllo, eseguire algoritmi di data-analysis su base storica, gestire lo stato globale delle stazioni di ricarica e fornire un backend scalabile per l'APP mobile rivolta agli utenti.
4. Nodi esterni: Stazioni di Ricarica
* Sistema di elaborazione: Controller embedded all'interno delle colonnine, interfacciati con un gateway locale dell'area di servizio.
flowchart TD
subgraph Livello_Nazionale [Livello Core / Cloud Nazionale]
DB[(Database Nazionale\nData Analysis)]
API[API Gateway]
GestioneRicariche[Server Gestione Ricariche]
end
subgraph Livello_Zonale [Livello Fog / Centro di Controllo]
CC_Server[Server Aggregazione Tratta]
Operatore[Workstation Operatore]
end
subgraph Livello_Edge [Livello Edge / Smart-Gate]
EdgePC[Industrial Edge PC]
Cam[Telecamere AI]
Sens[Sensori Meteo/Traffico]
Screen[Maxi-Schermi]
end
subgraph Utenti [End Users]
App[APP Guidatori]
EV[Stazioni di Ricarica]
end
Cam -->|Video/Dati| EdgePC
Sens -->|Telemetria| EdgePC
EdgePC -->|Comandi| Screen
EdgePC <-->|Metadati / Override| CC_Server
CC_Server <--> Operatore
CC_Server <-->|Dati aggregati| DB
GestioneRicariche <--> DB
API <--> DB
App <-->|HTTPS / REST| API
EV <-->|Stato/Prenotazioni| GestioneRicariche
Punto b)
Il progetto richiede di dettagliare le tecnologie e le modalità di comunicazione intra-nodo (all'interno dello smart-gate) e inter-nodo (tra i vari livelli dell'architettura).
1. Comunicazione Intra-nodo (All'interno dello Smart-Gate)
L'Edge PC funge da centro stella per i dispositivi del singolo gate.
* Telecamere $\leftrightarrow$ Edge PC: Si utilizza lo standard Ethernet (IEEE 802.3) su cavo in rame UTP/STP Cat. 6. Si implementa la tecnologia PoE (Power over Ethernet, IEEE 802.3at/bt) per fornire alimentazione e connettività dati con un singolo cavo. Protocolli: $IP$, $RTSP$ per lo streaming video.
* Sensori $\leftrightarrow$ Edge PC: Per sensori industriali si prediligono bus di campo cablati per immunità ai disturbi elettromagnetici. Si utilizza RS-485 con protocollo $Modbus RTU$, oppure connessioni Ethernet con protocollo $MQTT$ o $CoAP$ per sensori nativamente IoT.
* Edge PC $\leftrightarrow$ Maxi-schermi: Connessione Ethernet. Il PC invia i dati da visualizzare tramite protocolli applicativi proprietari o standard (es. $TCP/IP$ con payload $JSON$ o $XML$).
2. Comunicazione Inter-nodo (Tra i nodi della rete)
* Smart-Gate $\leftrightarrow$ Centro di Controllo:
* Tecnologia fisica: Rete in Fibra Ottica monomodale posata lungo l'autostrada. Si progetta una topologia ad anello (es. anello $10 \text{ Gigabit Ethernet}$) basata su protocolli di ridondanza come $ERP$ (Ethernet Ring Protection) per garantire il funzionamento anche in caso di trancio del cavo in un punto.
* Modalità: Trasmissione dati basata su stack $TCP/IP$. I dati telemetrici e gli allarmi viaggiano tramite protocollo di messaggistica publish/subscribe come MQTT (leggero e asincrono).
* Centro di Controllo $\leftrightarrow$ Livello Nazionale:
* Tecnologia fisica: Connessioni WAN ad alta capacità. Si implementa una soluzione SD-WAN (Software-Defined WAN) che aggrega connessioni in fibra ottica fornite da ISP nazionali, con backup su rete cellulare $5G$.
* Modalità: Tunnel VPN $IPsec$ per garantire la confidenzialità e l'integrità dei dati in transito su reti pubbliche.
* Stazioni di Ricarica $\leftrightarrow$ Livello Nazionale:
* Tecnologia fisica: Connessione cablata in fibra o rete cellulare $4G/5G$ dall'area di servizio.
* Modalità: Si utilizza il protocollo standard di settore OCPP (Open Charge Point Protocol) su WebSocket/TLS per la trasmissione dello stato delle colonnine e la gestione delle prenotazioni.
* APP Guidatori $\leftrightarrow$ Livello Nazionale:
* Tecnologia fisica: Rete radiomobile pubblica ($4G/5G$) degli smartphone degli utenti.
* Modalità: Architettura Client-Server. L'APP comunica con l'API Gateway nazionale tramite chiamate RESTful su protocollo HTTPS (porta $443$), scambiando dati in formato $JSON$ per ottenere informazioni in tempo reale su traffico, segnaletica e disponibilità delle stazioni di ricarica.
Quesito 4
PROPOSTA DI SOLUZIONE — Seconda Prova di Maturità
Sistemi e Reti, 2026
Risoluzione del Quesito 4: Funzioni hash crittografiche (scopo, caratteristiche e applicazioni).
Scopo delle funzioni hash crittografiche
Le funzioni hash crittografiche sono algoritmi matematici che accettano in input un blocco di dati $m$ (messaggio) di dimensione arbitraria e restituiscono in output una stringa di bit di dimensione fissa $h$, denominata message digest, checksum o impronta digitale.
Lo scopo fondamentale di tali algoritmi è garantire l'integrità dei dati. Fornendo una rappresentazione compatta e univoca dell'informazione originale, permettono di verificare che un messaggio o un file non abbia subito alterazioni, siano esse accidentali (errori di trasmissione) o intenzionali (manomissioni da parte di un attaccante).
Caratteristiche fondamentali
Affinché una funzione hash (indicata con $H$) sia considerata crittograficamente sicura e idonea all'impiego nei protocolli di rete, deve soddisfare i seguenti requisiti formali:
- Unidirezionalità (Resistenza alla pre-immagine): Dato un valore hash $h$, deve essere computazionalmente impossibile risalire al messaggio originale $m$ tale per cui $H(m) = h$. La funzione non è invertibile.
- Resistenza alla seconda pre-immagine: Dato un messaggio specifico $m_1$, deve essere computazionalmente impossibile trovare un secondo messaggio $m_2$ (con $m_1 \neq m_2$) tale che produca lo stesso digest, ovvero $H(m_1) = H(m_2)$.
- Resistenza alle collisioni: Deve essere computazionalmente impossibile trovare una qualsiasi coppia di messaggi distinti $m_1$ e $m_2$ che generino il medesimo hash ($H(m_1) = H(m_2)$).
- Effetto valanga (Avalanche effect): La modifica di un singolo bit nel messaggio di input $m$ deve provocare un cambiamento drastico e del tutto imprevedibile nel digest risultante (statisticamente circa il $50\%$ dei bit dell'output deve variare).
- Determinismo ed efficienza: L'algoritmo deve produrre sempre lo stesso output a fronte del medesimo input. Inoltre, il calcolo di $H(m)$ deve essere rapido e richiedere risorse computazionali limitate.
- Dimensione fissa dell'output: Indipendentemente dalla lunghezza dell'input (che sia una password di 8 caratteri o un file video di 2 GB), la lunghezza dell'output è costante (ad esempio, 256 bit per l'algoritmo SHA-256).
Applicazioni nei protocolli di rete e nella sicurezza informatica
Le funzioni hash sono componenti primitive essenziali in numerosi ambiti della sicurezza:
- Firma digitale: Per ragioni di efficienza computazionale, gli algoritmi a chiave asimmetrica (come RSA) non vengono applicati all'intero documento. Il mittente calcola il digest del documento $h = H(m)$ e cifra esclusivamente $h$ con la propria chiave privata. Il destinatario verifica la firma decifrando l'hash e confrontandolo con un nuovo hash calcolato localmente sul documento ricevuto.
- Codici di autenticazione dei messaggi (HMAC): Nei protocolli di rete sicuri (come IPsec, TLS/SSL, SSH), le funzioni hash vengono combinate con una chiave crittografica simmetrica segreta condivisa tra le parti. Questo garantisce simultaneamente l'integrità del payload e l'autenticazione del mittente, prevenendo attacchi di tipo man-in-the-middle.
- Memorizzazione sicura delle credenziali: I sistemi di autenticazione non memorizzano le password degli utenti in chiaro nei database, ma registrano unicamente il loro hash. Spesso viene concatenato un valore casuale (denominato salt) alla password prima dell'hashing per mitigare gli attacchi basati su dizionario o rainbow tables.
- Verifica dell'integrità dei file e del software: I distributori di software pubblicano i valori hash (es. MD5, SHA-1, SHA-256) dei file scaricabili. L'utente, dopo il download, ricalcola l'hash del file locale per accertarsi che corrisponda a quello dichiarato, confermando l'assenza di corruzione o iniezioni di malware.
- Tecnologie Blockchain: Le funzioni hash sono utilizzate per incatenare crittograficamente i blocchi (l'hash del blocco precedente è incluso nell'intestazione del blocco successivo) e costituiscono la base degli algoritmi di consenso, come la Proof of Work.
flowchart TD
A[Dati di Input m <br> Lunghezza arbitraria] -->|Elaborazione| B(Funzione Hash Crittografica H <br> es. SHA-256, SHA-3)
B -->|Output| C[Message Digest h <br> Lunghezza fissa]
C --> D{Applicazioni Principali}
D --> E[Firma Digitale <br> Cifratura asimmetrica dell'hash]
D --> F[Memorizzazione Password <br> Hashing + Salt]
D --> G[HMAC <br> Integrità e Autenticazione in TLS/IPsec]
D --> H[Integrità Dati <br> Checksum file e Blockchain]
Quesito 3
PROPOSTA DI SOLUZIONE — Seconda Prova di Maturità
Sistemi e Reti, 2026
Soluzione relativa alle tecnologie per la continuità di servizio e la sicurezza dell'infrastruttura (indicata nella consegna come Quesito 3 / Punto 3 della Prima Parte).
Ipotesi aggiuntive:
* Si assume che lungo la rete autostradale sia posata una dorsale in fibra ottica di proprietà della società di gestione.
* Si assume che il Database Nazionale sia ospitato presso un Data Center di livello almeno $\text{Tier III}$, in grado di garantire un uptime del $99.982\%$.
* Si assume che gli smart-gate siano dotati di apparati di rete di tipo "industrial", capaci di operare in condizioni ambientali estreme (temperature, vibrazioni).
1. Continuità di Servizio (High Availability e Fault Tolerance)
Per garantire che il sistema smart-road rimanga operativo anche in caso di guasti hardware, interruzioni di rete o blackout elettrici, si implementano le seguenti soluzioni suddivise per livello architetturale.
Livello Edge (Smart-Gate)
* Alimentazione: Ogni smart-gate è dotato di un gruppo di continuità (UPS) locale e, ove possibile, di un pannello solare con batteria tampone per garantire il funzionamento di telecamere e sensori anche in assenza di alimentazione di rete.
* Ridondanza di Rete: Gli switch degli smart-gate (distanti $1\text{ km}$ l'uno dall'altro) sono collegati in una topologia ad anello fisico utilizzando la fibra ottica. A livello logico, si implementa il protocollo $\text{ERPS}$ (Ethernet Ring Protection Switching, standard ITU-T G.8032) o $\text{RSTP}$ (Rapid Spanning Tree Protocol) per garantire tempi di convergenza inferiori a $50\text{ ms}$ in caso di tranciatura di un cavo.
Livello Intermedio (Centri di Controllo)
* Connettività WAN: I centri di controllo dispongono di un doppio collegamento verso la rete nazionale: un collegamento primario in fibra ottica e un collegamento di backup basato su rete cellulare radiomobile ($5\text{G}/\text{LTE}$) configurato in modalità failover.
* Alimentazione: Presenza di UPS centralizzati e gruppi elettrogeni diesel ad avvio automatico.
Livello Core (Database Nazionale e Servizi Centrali)
* Clustering: I server che ospitano il database nazionale e le logiche applicative operano in un cluster in modalità Active-Active o Active-Passive, supportati da bilanciatori di carico (Load Balancer).
* Storage: I dati sono memorizzati su SAN (Storage Area Network) con configurazione $\text{RAID 10}$ o $\text{RAID 6}$ per tollerare la rottura multipla dei dischi.
* Disaster Recovery (DR): Si prevede un sito di Disaster Recovery geograficamente distante dal Data Center primario. La replica dei dati avviene in modalità sincrona o asincrona (a seconda della distanza) per minimizzare il $\text{RPO}$ (Recovery Point Objective) e il $\text{RTO}$ (Recovery Time Objective).
2. Sicurezza dell'Infrastruttura (Cybersecurity)
La protezione dell'infrastruttura deve garantire la confidenzialità, l'integrità e la disponibilità dei dati, prevenendo accessi non autorizzati e attacchi informatici.
Sicurezza Fisica e Controllo Accessi di Rete (NAC)
* Anti-tampering: Gli armadi di permutazione (cabinet) degli smart-gate sono dotati di sensori anti-effrazione.
* Autenticazione delle porte: Sugli switch degli smart-gate è implementato lo standard $\text{IEEE 802.1X}$. Qualsiasi dispositivo collegato fisicamente a una porta deve autenticarsi tramite un server $\text{RADIUS}$; in caso di fallimento, la porta viene disabilitata o assegnata a una VLAN isolata (Guest/Quarantine VLAN).
Sicurezza Perimetrale e Segmentazione
* VLAN: Il traffico è logicamente separato tramite VLAN distinte per tipologia di dato (es. VLAN Telecamere, VLAN Sensori, VLAN Pannelli Informativi, VLAN Management).
* Firewall NGFW: Presso i Centri di Controllo e il Data Center Nazionale sono installati Next-Generation Firewall (NGFW) operanti a livello applicativo (Livello 7 del modello ISO/OSI). Essi integrano funzionalità di $\text{IDS/IPS}$ (Intrusion Detection/Prevention System) per bloccare traffico anomalo o firme di attacchi noti.
Sicurezza dei Dati in Transito (Crittografia)
* VPN Site-to-Site: Le comunicazioni tra i Centri di Controllo e il Data Center Nazionale avvengono esclusivamente tramite tunnel $\text{IPsec}$ crittografati (es. algoritmo $\text{AES-256}$), garantendo l'integrità e la confidenzialità dei dati di traffico.
* Protocolli Sicuri: L'interazione tra l'APP dei guidatori, le stazioni di ricarica e il Database Nazionale avviene tramite API REST protette dal protocollo $\text{HTTPS}$ (con $\text{TLS 1.3}$).
* Management Sicuro: L'amministrazione remota degli apparati è consentita solo tramite protocolli sicuri come $\text{SSHv2}$ e $\text{SNMPv3}$, disabilitando protocolli in chiaro come Telnet o HTTP.
Sicurezza degli Accessi Logici (Identity Management)
* MFA (Multi-Factor Authentication): Gli operatori umani nei centri di controllo devono autenticarsi ai terminali e ai cruscotti di monitoraggio utilizzando l'autenticazione a più fattori.
* RBAC (Role-Based Access Control): I permessi di modifica della segnaletica sui maxi-schermi sono regolati da policy stringenti basate sul ruolo dell'operatore, limitando i privilegi al principio del least privilege.
Diagramma dell'Architettura di Sicurezza e Continuità
flowchart TD
subgraph Edge ["Livello Edge (Smart-Gates)"]
SG1["Smart-Gate N"]
SG2["Smart-Gate N+1"]
SG3["Smart-Gate N+2"]
SG1 <-->|Fibra - Anello ERPS| SG2
SG2 <-->|Fibra - Anello ERPS| SG3
SG3 <-->|Fibra - Anello ERPS| SG1
noteEdge["Sicurezza: 802.1X, Sensori fisici\nContinuità: UPS locale"]
end
subgraph Controllo ["Centri di Controllo (Regionali)"]
CC1["Centro di Controllo A"]
FW1["Firewall NGFW + IPS"]
CC1 --> FW1
noteCC["Sicurezza: MFA, RBAC\nContinuità: UPS, Generatore, Link 5G Backup"]
end
subgraph Core ["Livello Core (Nazionale)"]
FW2["Firewall NGFW + WAF"]
LB["Load Balancer"]
DB1[("DB Nazionale (Attivo)")]
DB2[("DB Nazionale (Passivo/Replica)")]
FW2 --> LB
LB --> DB1
LB --> DB2
DB1 -.->|Replica Sincrona| DB2
end
subgraph Esterno ["Utenti e Servizi Esterni"]
APP["APP Guidatori"]
EV["Stazioni di Ricarica"]
end
%% Connessioni
SG2 <==>|Traffico Segmentato VLAN| CC1
FW1 <==>|Tunnel VPN IPsec (AES-256)| FW2
APP <-->|HTTPS / TLS 1.3| FW2
EV <-->|HTTPS / TLS 1.3| FW2
classDef secure fill:#e1f5fe,stroke:#0288d1,stroke-width:2px;
classDef core fill:#fff3e0,stroke:#f57c00,stroke-width:2px;
class Edge,Controllo secure;
class Core core;
PRIMA PARTE
PROPOSTA DI SOLUZIONE — Seconda Prova di Maturità
Sistemi e Reti
Svolgimento della Prima Parte: Progetto di un'infrastruttura di rete per smart-road.
Ipotesi aggiuntive:
Per procedere al dimensionamento rigoroso della rete e al piano di indirizzamento, si assumono i seguenti parametri non specificati dalla traccia:
* Si considerano $N = 10$ tratti autostradali sperimentali a livello nazionale.
* Ogni tratto sperimentale ha una lunghezza $L = 50$ km, comportando l'installazione di $50$ smart-gate per tratto.
* Ogni smart-gate contiene i seguenti dispositivi IP: $1$ Edge Router/Gateway, $2$ telecamere IP, $3$ sensori IoT (meteo, asfalto, inquinamento), $1$ controller per maxi-schermo. Totale: $7$ host IP per gate.
* Ogni tratto presenta $2$ stazioni di ricarica (una per senso di marcia).
* Il Centro di Controllo di ogni tratto ospita $1$ router, $1$ switch core, $5$ postazioni operatore e $2$ server locali.
Punto 1) Progetto dell'infrastruttura tecnologica e informatica
a. Architettura della rete e sistemi di elaborazione
Si adotta un'architettura gerarchica distribuita su tre livelli (Edge, Fog, Cloud) per garantire bassa latenza nelle decisioni locali e scalabilità a livello nazionale.
- Livello Edge (Smart-Gate):
- Collocazione: A bordo carreggiata, ogni chilometro.
- Sistemi: Si impiega un Edge Computer industriale (rugged, resistente a escursioni termiche) che funge da gateway IoT.
- Motivazione: L'elaborazione locale (Edge Computing) dei flussi video (riconoscimento targhe/traffico) evita di saturare la banda verso il centro di controllo. Il gateway prende decisioni autonome (es. avviso di nebbia sul maxi-schermo) con latenza minima.
- Livello Fog/Aggregation (Centro di Controllo):
- Collocazione: In prossimità del tratto autostradale di competenza.
- Sistemi: Server locali per l'aggregazione dei dati dei $50$ gate, storage temporaneo per i flussi video e workstation per gli operatori umani.
- Motivazione: Permette il monitoraggio in tempo reale del singolo tratto senza dipendere dalla connettività verso il datacenter nazionale, garantendo operatività anche in caso di isolamento della rete geografica (WAN).
- Livello Cloud/Core (Nazionale):
- Collocazione: Datacenter centralizzato (o infrastruttura Cloud pubblica/ibrida).
- Sistemi: Cluster di database relazionali/NoSQL per lo storico dei dati, Application Server per l'erogazione delle API REST destinate all'APP mobile e al sistema di prenotazione delle stazioni di ricarica.
- Motivazione: Centralizzazione necessaria per l'analisi dei big data, la visione globale del traffico e l'interfacciamento con gli utenti finali (guidatori).
b. Tecnologie e modalità di comunicazione
* Intra-nodo (all'interno dello smart-gate): Si utilizza lo standard Ethernet (IEEE 802.3) con switch industriali PoE (Power over Ethernet) per alimentare telecamere e sensori direttamente tramite cavo di rete (UTP Cat 6).
* Tra Smart-Gate e Centro di Controllo: Si prevede la posa di una dorsale in fibra ottica lungo l'autostrada con topologia ad anello (Ring Ethernet) o tecnologia PON (Passive Optical Network). Garantisce l'elevata larghezza di banda necessaria per la trasmissione dei metadati e dei flussi video su richiesta.
* Tra Centri di Controllo, Stazioni di Ricarica e Livello Nazionale: Connettività WAN basata su SD-WAN su linee in fibra ottica dedicate, con backup su rete radiomobile 5G per garantire ridondanza.
* Tra APP mobile e Database Nazionale: Comunicazione wireless tramite reti cellulari (4G/5G) utilizzando il protocollo applicativo HTTPS per garantire la cifratura dei dati in transito.
Punto 2) Configurazione dei dispositivi e piano di indirizzamento
Si adotta l'indirizzamento IPv4 privato (RFC 1918). Si assegna l'intero blocco 10.0.0.0/8 all'infrastruttura nazionale.
Si suddivide lo spazio assegnando una subnet /16 a ciascun tratto autostradale e al livello nazionale.
- Livello Nazionale:
10.0.0.0/16 - Tratto Sperimentale 1:
10.1.0.0/16 - Tratto Sperimentale 2:
10.2.0.0/16(e così via).
Focalizziamo il piano di indirizzamento sul Tratto Sperimentale 1 (10.1.0.0/16).
Calcoliamo le subnet necessarie:
1. Centro di Controllo: Richiede circa $10$ host. Si alloca una /24 per scalabilità futura.
$$ \text{Host utili} = 2^{32-24} - 2 = 254 $$
2. Smart-Gate: Ogni gate ha $7$ host. Si alloca una /28 per ciascun gate.
$$ \text{Host utili} = 2^{32-28} - 2 = 14 $$
3. Stazioni di Ricarica: Si alloca una /24 dedicata.
Per calcolare l'indirizzo di rete della $k$-esima subnet /28 (con $k$ da $1$ a $50$) a partire da 10.1.1.0, si utilizza l'offset in base al numero di indirizzi per subnet ($16$):
$$ \text{Offset} = (k - 1) \times 16 $$
Per la Subnet $50$:
$$ \text{Offset} = (50 - 1) \times 16 = 49 \times 16 = 784 $$
Convertendo $784$ in ottetti (divisione per $256$):
$$ 784 = 3 \times 256 + 16 $$
L'offset corrisponde a 0.0.3.16. Sommandolo all'indirizzo di base 10.1.1.0, si ottiene l'indirizzo di rete 10.1.4.16.
Tabella di Subnetting (Tratto 1):
| Sottorete | Destinazione | CIDR | Network | Broadcast | Range Host Utili |
|---|---|---|---|---|---|
| Subnet 0 | Centro di Controllo | /24 |
10.1.0.0 |
10.1.0.255 |
10.1.0.1 - 10.1.0.254 |
| Subnet 1 | Smart-Gate 1 | /28 |
10.1.1.0 |
10.1.1.15 |
10.1.1.1 - 10.1.1.14 |
| Subnet 2 | Smart-Gate 2 | /28 |
10.1.1.16 |
10.1.1.31 |
10.1.1.17 - 10.1.1.30 |
| Subnet 3 | Smart-Gate 3 | /28 |
10.1.1.32 |
10.1.1.47 |
10.1.1.33 - 10.1.1.46 |
| ... | ... | ... | ... | ... | ... |
| Subnet 50 | Smart-Gate 50 | /28 |
10.1.4.16 |
10.1.4.31 |
10.1.4.17 - 10.1.4.30 |
| Subnet 254 | Stazioni Ricarica | /24 |
10.1.254.0 |
10.1.254.255 |
10.1.254.1 - 10.1.254.254 |
Verifica sovrapposizione: Le reti /28 degli smart-gate (da 10.1.1.0 a 10.1.4.31) non si sovrappongono né alla /24 del Centro di Controllo (10.1.0.0) né a quella delle stazioni di ricarica (10.1.254.0). Il piano è coerente.
Punto 3) Tecnologie e soluzioni per continuità di servizio e sicurezza
Continuità di servizio (High Availability & Fault Tolerance):
1. Alimentazione Elettrica: Installazione di UPS (Uninterruptible Power Supply) in ogni smart-gate e Centro di Controllo. Per i Centri di Controllo e il Datacenter Nazionale si impongono gruppi elettrogeni diesel ad avvio automatico.
2. Ridondanza di Rete: La dorsale in fibra ottica autostradale è configurata ad anello chiuso. L'impiego di protocolli come RSTP (Rapid Spanning Tree Protocol) o ERPS (Ethernet Ring Protection Switching) garantisce tempi di convergenza inferiori a $50$ ms in caso di tranciatura del cavo. I gateway dispongono di modulo 5G per il failover della connettività WAN.
3. Disaster Recovery: Il Database Nazionale è replicato in tempo reale (sincronamente) in un sito di Disaster Recovery geograficamente distante per prevenire perdite di dati in caso di evento catastrofico nel datacenter primario.
Sicurezza dell'infrastruttura (Cybersecurity):
1. Sicurezza Perimetrale ed End-to-End: Implementazione di Next-Generation Firewall (NGFW) presso i Centri di Controllo e il Datacenter Nazionale. Tutte le comunicazioni tra gli Edge Router degli smart-gate e i server centrali avvengono tramite tunnel VPN IPsec, garantendo confidenzialità e integrità dei dati.
2. Controllo degli Accessi (NAC): Poiché gli smart-gate sono fisicamente esposti, si abilita il protocollo IEEE 802.1X sulle porte degli switch industriali. Qualsiasi dispositivo estraneo collegato fisicamente al cavo di rete non otterrà l'accesso alla VLAN di gestione.
3. Sicurezza Applicativa: L'interfaccia esposta verso l'APP dei guidatori è protetta da un WAF (Web Application Firewall) per mitigare attacchi di tipo DDoS, SQL Injection e Cross-Site Scripting (XSS). Le API utilizzano token JWT (JSON Web Token) per l'autenticazione delle richieste.
flowchart TD
subgraph Livello_Nazionale ["Livello Cloud / Nazionale"]
DB[(Database Nazionale)]
AppServer[Application Server API]
FW_Nat[Firewall Perimetrale]
AppServer <--> DB
FW_Nat <--> AppServer
end
subgraph Rete_WAN ["Rete Geografica (SD-WAN / Internet)"]
WAN((WAN / 5G))
end
subgraph Tratto_Sperimentale ["Centro di Controllo (Livello Fog)"]
FW_CC[Firewall / Router Edge]
SW_CC[Switch Core]
Server_Loc[Server Aggregazione]
Op[Postazioni Operatori]
FW_CC <--> SW_CC
SW_CC <--> Server_Loc
SW_CC <--> Op
end
subgraph Smart_Gate_1 ["Smart-Gate 1 (Livello Edge)"]
Edge_GW[Edge Computer / Switch PoE]
Cam[Telecamere IP]
Sens[Sensori IoT]
Display[Maxi-schermo]
Edge_GW <--> Cam
Edge_GW <--> Sens
Edge_GW <--> Display
end
subgraph Stazione_Ricarica ["Stazione di Ricarica"]
Controller_EV[Controller Colonnine]
end
%% Connessioni esterne
Utente((APP Guidatori)) <-->|HTTPS / 5G| WAN
WAN <--> FW_Nat
WAN <--> FW_CC
WAN <--> Controller_EV
%% Connessione Fibra Autostradale
FW_CC <-->|Fibra Ottica| Edge_GW
Quesito 2
PROPOSTA DI SOLUZIONE — Seconda Prova di Maturità
Sistemi e Reti, 2026
Svolgimento del Quesito 2 (Prima Parte): Progetto del piano di indirizzamento e configurazione dei dispositivi di rete per l'infrastruttura smart-road.
Ipotesi aggiuntive
Poiché la traccia non specifica le dimensioni esatte dell'infrastruttura, si assumono i seguenti parametri per il dimensionamento della rete:
* L'infrastruttura nazionale è suddivisa in $10$ tratti autostradali sperimentali.
* Ogni tratto autostradale ha una lunghezza di $50 \text{ km}$ e comprende $50$ smart-gate (uno per chilometro).
* Ogni smart-gate contiene $10$ dispositivi IP (1 switch layer 3, 1 maxi-schermo, 4 telecamere, 4 sensori).
* Ogni tratto autostradale fa capo a un Centro di Controllo locale che richiede $50$ host (operatori e server locali).
* Le stazioni di ricarica per veicoli elettrici di un tratto sono raggruppate in una sottorete dedicata che richiede $100$ host.
* I $50$ smart-gate di un tratto sono interconnessi al router del Centro di Controllo tramite un anello in fibra ottica (Backbone di transito) che richiede un indirizzo IP per ogni nodo ($51$ IP totali).
Piano di Indirizzamento IP
Si adotta un indirizzamento privato IPv4 basato sulla classe A $10.0.0.0/8$ (RFC 1918), strutturato in modo gerarchico per facilitare il routing OSPF.
Gerarchia di allocazione:
* Datacenter Nazionale: $10.0.0.0/16$
* Tratti Autostradali: Si assegna un blocco $/16$ a ciascun tratto (es. Tratto 1: $10.1.0.0/16$, Tratto 2: $10.2.0.0/16$).
* Collegamenti WAN: Blocco $10.255.255.0/24$ suddiviso in sottoreti $/30$.
Calcolo del Subnetting interno al Tratto 1 ($10.1.0.0/16$):
La formula per il calcolo degli host utili è:
$$ H = 2^{32-n} - 2 $$
dove $n$ è la lunghezza del prefisso CIDR.
-
Centro di Controllo 1 ($50$ host richiesti):
Si impone $2^{32-n} - 2 \ge 50$. Per scalabilità si adotta $n = 24$:
$$ 2^{32-24} - 2 = 2^8 - 2 = 256 - 2 = 254 \text{ host utili} $$
Rete assegnata: $10.1.0.0/24$. Maschera: $255.255.255.0$. -
Stazioni di Ricarica EV ($100$ host richiesti):
Si impone $2^{32-n} - 2 \ge 100$. Si adotta $n = 24$:
$$ 2^{32-24} - 2 = 254 \text{ host utili} $$
Rete assegnata: $10.1.1.0/24$. Maschera: $255.255.255.0$. -
Backbone Fibra Tratto 1 ($51$ host richiesti per i link punto-multipunto):
Si impone $2^{32-n} - 2 \ge 51$. Si adotta $n = 24$:
$$ 2^{32-24} - 2 = 254 \text{ host utili} $$
Rete assegnata: $10.1.2.0/24$. Maschera: $255.255.255.0$. -
Smart-gate 1 LAN ($10$ host richiesti):
Si impone $2^{32-n} - 2 \ge 10$:
$$ 2^{32-n} \ge 12 \implies 32-n = 4 \implies n = 28 $$
$$ 2^{32-28} - 2 = 2^4 - 2 = 16 - 2 = 14 \text{ host utili} $$
Rete assegnata: $10.1.10.0/28$. Maschera: $255.255.255.240$.
Range IP utili: da $10.1.10.1$ a $10.1.10.14$. Broadcast: $10.1.10.15$.
Tabella Subnet (Estratto per Datacenter, WAN e Tratto 1)
| Sottorete | CIDR | Indirizzo di Rete | Primo IP Utile | Ultimo IP Utile | Indirizzo Broadcast | Host Utili |
|---|---|---|---|---|---|---|
| Centro Controllo 1 | $/24$ | $10.1.0.0$ | $10.1.0.1$ | $10.1.0.254$ | $10.1.0.255$ | $254$ |
| Ricarica EV Tratto 1 | $/24$ | $10.1.1.0$ | $10.1.1.1$ | $10.1.1.254$ | $10.1.1.255$ | $254$ |
| Backbone Fibra T1 | $/24$ | $10.1.2.0$ | $10.1.2.1$ | $10.1.2.254$ | $10.1.2.255$ | $254$ |
| Smart-gate 1.1 LAN | $/28$ | $10.1.10.0$ | $10.1.10.1$ | $10.1.10.14$ | $10.1.10.15$ | $14$ |
| Smart-gate 1.2 LAN | $/28$ | $10.1.10.16$ | $10.1.10.17$ | $10.1.10.30$ | $10.1.10.31$ | $14$ |
| WAN Link HQ-Tratto1 | $/30$ | $10.255.255.0$ | $10.255.255.1$ | $10.255.255.2$ | $10.255.255.3$ | $2$ |
Configurazione dei Dispositivi di Rete
Si riportano le configurazioni logiche (sintassi Cisco IOS) per i nodi principali del Tratto 1.
1. Router del Centro di Controllo 1 (R-TRATTO-1)
Il router gestisce il traffico locale e lo instrada verso il Datacenter Nazionale e verso gli Smart-gate tramite OSPF.
```text
! Configurazione Interfaccia WAN verso Datacenter Nazionale
interface GigabitEthernet0/0
description Link to National HQ
ip address 10.255.255.2 255.255.255.252
no shutdown
! Configurazione Interfaccia LAN Centro di Controllo
interface GigabitEthernet0/1
description LAN Centro Controllo 1
ip address 10.1.0.1 255.255.255.0
no shutdown
! Configurazione Interfaccia verso Backbone Fibra Smart-gates
interface GigabitEthernet0/2
description Transit Link to Smart-gates Tratto 1
ip address 10.1.2.1 255.255.255.0
no shutdown
! Configurazione Routing OSPF
router ospf 1
router-id 10.1.0.1
network 10.1.0.0 0.0.0.255 area 1
network 10.1.1.0 0.0.0.255 area 1
network 10.1.2.0 0.0.0.255 area 1
network 10.255.255.0 0.0.0.3 area 0
```
2. Switch Layer 3 dello Smart-gate 1 (SW-GATE-1)
Lo switch opera a livello 3 per instradare il traffico della propria LAN locale ($/28$) verso il Backbone in fibra ($/24$).
```text
! Abilitazione routing IP
ip routing
! Creazione VLAN locale per i dispositivi del Gate 1
vlan 10
name SMART_GATE_1_LAN
! Configurazione interfaccia virtuale (SVI) per la LAN locale
interface Vlan10
ip address 10.1.10.1 255.255.255.240
no shutdown
! Assegnazione porta di accesso (es. Telecamera 1)
interface FastEthernet0/1
description Telecamera 1
switchport mode access
switchport access vlan 10
spanning-tree portfast
! Configurazione porta routed di uplink verso il Backbone Fibra
interface GigabitEthernet0/1
description Uplink to Backbone Tratto 1
no switchport
ip address 10.1.2.2 255.255.255.0
no shutdown
! Configurazione Routing OSPF
router ospf 1
router-id 10.1.10.1
network 10.1.10.0 0.0.0.15 area 1
network 10.1.2.0 0.0.0.255 area 1
```
Topologia Logica della Rete
flowchart TD
subgraph Livello_Nazionale ["Livello Nazionale (10.0.0.0/16)"]
DB[(Database Nazionale)]
APP[Server APP / Web]
R_HQ[Router Core Nazionale]
DB --- R_HQ
APP --- R_HQ
end
subgraph Rete_WAN ["Backbone WAN (10.255.255.0/24)"]
R_HQ <-->|Link /30| R_T1
R_HQ <-->|Link /30| R_T2
end
subgraph Tratto_1 ["Tratto Autostradale 1 (10.1.0.0/16)"]
R_T1[Router Centro Controllo 1\nIP: 10.1.2.1]
SW_CC1[Switch Centro Controllo]
EV_SW[Switch Stazioni Ricarica EV]
R_T1 ---|10.1.0.0/24| SW_CC1
R_T1 ---|10.1.1.0/24| EV_SW
subgraph Backbone_Fibra ["Backbone Fibra (10.1.2.0/24)"]
direction LR
R_T1_Link --- SW_G1_Uplink
end
R_T1 --- Backbone_Fibra
subgraph Smart_Gate_1 ["Smart-Gate 1 LAN (10.1.10.0/28)"]
SW_G1[Switch L3 Gate 1\nIP: 10.1.2.2]
CAM1[Telecamera]
SENS1[Sensori Meteo]
MON1[Maxi-schermo]
SW_G1 --- CAM1
SW_G1 --- SENS1
SW_G1 --- MON1
end
Backbone_Fibra --- SW_G1
end
subgraph Tratto_2 ["Tratto Autostradale 2 (10.2.0.0/16)"]
R_T2[Router Centro Controllo 2]
end
Vuoi la soluzione della tua prova?
Carica la tua prova scritta (PDF o foto) sul Risolutore Prove AI: risolve tutti i quesiti con grafici e ti consegna il PDF completo.