Esame di Stato II Prova Istituti Tecnici Informatica - Sistemi e Reti (2024

Proviamo a fornire una soluzione delle traccia della seconda prova di indirizzo degli esami di stato con la materia scelta Sistemi e Reti uscita, alla sessione suppletiva dell’anno scolastico 2023/24.

Indice dei contenuti

Traccia

Il candidato svolga la prima parte della prova e due tra i quesiti proposti nella seconda parte.
PRIMA PARTE
Gestione eventi con grandi folle
Una città italiana di interesse turistico internazionale ha deciso di sperimentare un nuovo sistema di monitoraggio del flusso delle persone in occasione di grandi eventi (culturali, artistici, sportivi). A tali eventi, che si svolgono in un preciso luogo della città, si potrà accedere unicamente mediante biglietti a pagamento o anche gratuiti.
Nell’intera area del comune saranno presenti punti di informazione automatici (totem), basati su touch screen, dove l’utente potrà informarsi su uno o più eventi e acquistare il biglietto in autonomia.
Per la gestione del sistema di monitoraggio del flusso delle persone in occasione di un evento, viene messa a disposizione una sede operativa composta da due piani; al primo piano sarà presente un’area dedicata all’assistenza pre- e post- vendita dei biglietti, dove gli operatori potranno svolgere le loro mansioni; al secondo piano sarà presente la sala di controllo dove il personale addetto, attraverso telecamere di sorveglianza, potrà visionare le immagini in diretta dei luoghi interessati dagli eventi. Uno degli obiettivi è quello di ridurre il sovraffollamento nelle aree critiche e poter intervenire con prontezza in caso di necessità.
In punti strategici della città, verranno infatti collocate telecamere di monitoraggio e dispositivi azionabili a distanza (per esempio semafori, barriere a scomparsa, pannelli informativi o altro) che permetteranno di gestire al meglio il flusso di persone verso il luogo dell’evento, anche con l’ausilio di personale in loco. I dispositivi, azionabili a distanza, verranno gestiti attraverso un server HTTP interno al dispositivo stesso, accessibile da remoto.
Nell’area circostante l’evento (ad esempio un concerto) sarà presente personale addetto alla validazione degli ingressi all’evento, all’assistenza e al pronto intervento. Per lo svolgimento delle proprie mansioni, il personale in loco sarà dotato di un dispositivo mobile con il quale può comunicare con la sede operativa ed essere costantemente aggiornato sullo stato dei dispositivi azionabili a distanza sopra citati.
Il candidato analizzi la realtà di riferimento e, formulate le opportune ipotesi aggiuntive, svolga i seguenti punti:

sviluppi una descrizione di massima, anche supportata da uno schema grafico che presenti il sistema (organizzazione della rete informatica della sede operativa, modalità di connessione con le telecamere per il monitoraggio e i dispositivi remoti e loro attivazione e gestione), e ne ponga in evidenza i vari componenti hardware e software necessari, motivando le scelte effettuate;
descriva in modo dettagliato le possibili modalità di comunicazione tra la sede operativa ed il personale in loco dedicato alla gestione del flusso delle persone partecipanti all’evento, anche in relazione alla validazione dei biglietti di ingresso;
definisca le tecnologie di comunicazione tra la sede operativa e i punti di informazione (totem) dislocati sull’intera area del comune;
descriva la modalità attraverso le quali sarà possibile evitare interruzioni di servizio.

SECONDA PARTE
I. In relazione al tema proposto nella prima parte, si consideri la gestione dei filmati e delle immagini che vengono trasmessi dalle telecamere per il monitoraggio, e si propongano soluzioni per il relativo salvataggio all’interno dell’infrastruttura della sede centrale oppure nel cloud, definendone vantaggi e svantaggi.
II. In relazione al tema proposto nella prima parte, si discuta come possono essere attivati e gestiti i dispositivi remoti dotati di server HTTP interno, utilizzando i metodi propri di questo protocollo, fornendo opportune esemplificazioni.
III. Il candidato illustri caratteristiche e possibili campi di applicazione di due tecnologie di comunicazione wireless a corto raggio quali, ad esempio, sistemi basati su RFID, NFC, Bluetooth Low Energy (BLE), IEEE 802.15.4.
IV. In una rete locale è presente un host con la seguente configurazione:
hostname: pcserverlab
IP address: 192.168.1.15/24
Default Gateway: 192.168.1.1
DNS1: 192.168.1.2
DNS2: 212.14.128.1
Effettuando da un altro PC della rete il ping all’ IP Address di tale host, con il comando
C:\Users\admin>ping 192.168.1.15
si ottiene in risposta
Esecuzione di Ping 192.168.1.15 con 32 byte di dati:
Risposta da 192.168.1.15: byte=32 durata=41ms TTL=56
Risposta da 192.168.1.15: byte=32 durata=32ms TTL=56
Risposta da 192.168.1.15: byte=32 durata=52ms TTL=56
Risposta da 192.168.1.15: byte=32 durata=38ms TTL=56
…
mentre effettuando il comando
C:\Users\admin>ping pcserverlab
si ottiene in risposta
Impossibile trovare l’host pcserverlab. Verificare che il nome sia corretto e riprovare.
Inoltre, effettuando il comando
C:\Users\admin>ping www.istruzione.it
si ottiene la risposta
Risposta da 92.123.181.19: byte=32 durata=20ms TTL=49
Risposta da 92.123.181.19: byte=32 durata=26ms TTL=49
Risposta da 92.123.181.19: byte=32 durata=214ms TTL=49
Risposta da 92.123.181.19: byte=32 durata=18ms TTL=49
…
Il candidato discuta le possibili cause di tale anomalia; ipotizzando di essere il responsabile dell’infrastruttura di rete, discuta quali passi successivi compirebbe per identificare il problema e porvi rimedio.

Soluzione prima parte

Come sempre, queste prove presentano un testo molto articolato e generico in cui bisogna ravvisare gli elementi di interesse su cui fare delle considerazioni per poter gestire eventuali soluzioni hardware/software. Nel nostro caso, ad esempio, sapere che ci siano eventi di un tipo piuttosto che un altro, ha poco interesse.

Premesse iniziali

Il fatto che gli eventi siano dislocati in un certo punto della città che può essere lontano dalla centrale operativa ci obbliga a fare delle considerazioni iniziali sullo stato pregresso della rete cittadina. Ad esempio suppongo ci sia una copertura ramificata ed articolata di connessioni in fibra ottica di operatori di telefonia pubblica o assimilabile. La procedure di gestione e controllo nella sede operativa presupponiamo utilizzino soluzioni in-house o meglio detta on-premise con budget adeguati alla gestione e manutenzione dell’infrastruttura così come del personale necessario. Scartiamo invece la soluzione con gestione in outsourcing. Motivazione tecnica di tale scelta si può trovare nella risposta al quesito uno della seconda parte. Gli eventi possono essere largamente partecipati anche con cifre che spaziano dai 10.000 ai 100.000 partecipanti in caso di gradi concerti/raduni. Non conosciamo le dimensioni della città ma possiamo ipotizzare ci siano 30/50 totem informativi in giro per la città. Le telecamere sono sicuramente in numero maggiore, stimabile dell’ordine di 100/200 dispositivi per l’annesso sistema di video sorveglianza.

Schema di massima

Proviamo a dare uno schema delle componenti indicate nel testo. (L’alunno non si spaventi: possono occorre più versioni e cancellature per creare una mappa completa e dettagliata.)

Andiamo a dettagliare gli elementi dello schema di massima.

I totem

I totem sono dispositivi fissi assimilabili a dei sistemi tipo smart tv o smartphone con schermi touch. Possono essere composti da minipc anche basati su chip ARM meno costosi o cpu di vecchia generazione ma a basso consumo o celeron della generazione N5000 o J1300, con una piccola dotazione di ram di pochi gigabyte e hard disk minimali, rispettivamente 2/4GByte e 128GByte, s.o. android o custom linux. Interessante la connettività perché possiamo dotarli di schede di rete ethernet cablate a cui aggiungere come linea di fail over anche una sim 4G/5G. Accessori aggiuntivi, oltre i monitor touch sono spesso mini casse audio integrate nell’involucro, tastierini numerici, lettori di QR code, ministampanti termiche, sistemi NFC per pagamenti contactless.

Cabine

I totem possono essere distribuiti in qualsiasi punto del territorio; tuttavia, la rete in fibra ottica cittadina non sempre riesce a raggiungere con precisione ogni zona di installazione, a causa dei vincoli legati agli scavi. È quindi necessario prevedere, all’interno o in prossimità delle cabine terminali della rete in fibra, dei router industriali in grado di ricevere il segnale in fibra e ridistribuirlo via Ethernet fino al totem, tramite apposite canaline. Questa soluzione è al tempo stesso più flessibile ed economica.

Il router industriale può essere dotato di più porte Ethernet — fino a 8 — oppure supportato da uno switch industriale con porte aggiuntive, per collegare dispositivi IoT, telecamere e qualsiasi altro apparato da pilotare o monitorare da remoto. Il dispositivo integra inoltre le funzionalità di connettività con l’operatore ISP designato, firewall e VPN.

L’aggettivo “industriale” non indica soluzioni speciali o di nicchia, bensì sistemi comuni e consolidati, caratterizzati però da una maggiore robustezza costruttiva: involucri protetti da pioggia, umidità, temperature estreme e polvere, a tutela dell’hardware interno.

In figura è riportato un esempio di router industriale con dissipazione passiva e scocca in lamiera robusta, dotato di porte in fibra e supporto a VPN e Firewall, supporto anche per sim 5G. A solo titolo di esempio il modello è Moxa EDR-G9010-VPN-2MGSFP-HV, dal costo indicativo di circa 4.000 €.

Dispositivi IoT

I dispositivi quali telecamere di monitoraggio e dispositivi azionabili a distanza (per esempio semafori, barriere a scomparsa, pannelli informativi o altro) possono essere classici sistemi già in commercio o sistemi già dotati di connettività. Nel primo caso, penso ad una sbarra o un semaforo, potremmo predisporre un attuatore, classici motorini elettrici, pilotato da una scheda microcontrollore stile Arduino o meglio PCB RaspBerry che permette di integrare una scheda di rete wifi o ethernet da accoppiare alle cabine già descritte. La stessa serie Arduino, oltre ai dispositivi didattici, prevede versioni più professionali e complete per questo genere di applicazione commerciale come la serie Opta che è a tutti gli effetti un PLC industriale.

Le applicazioni in questione vengono dette IoT e sempre più aziende integrano già all’interno del singolo dispositivo le schede di rete e tutto quello che serve per il pilotaggio remoto. (Basta ormai pensare ai condizionatori di casa, le lavatrici o altri elettrodomestici pilotabili comodamente da app. In questo caso abbiamo applicazioni simili.)

Dispositivi mobili

I vari addetti al controllo biglietti devono essere dotati di dispositivi mobili per la registrazione dei dati. Qui siamo già abituati a vederli in giro dispositivi come tablet o sistemi palmari industriali dedicati con schermi touch e/o pennini, fotocamere per la scansione rapida di QR-code o barcode 2D, schede 4G/5G per la connettività. Non servono caratteristiche hardware spinte per il genere di attività da svolgere. Basta dei processori ARM Snapdragon o processori di fascia media analoghi, 4/6 GB di ram, con 64/128Gb di harddisk, batteria da almeno 6000 mAh per consentire le operazioni senza ulteriore ricarica, schermo da 6 o 7 pollici con refresh rate standard (non si consigliano schermi grandi perché poco pratici da reggere con una mano). Sistema operativo Android di ultima generazione per supportare l’app di validazione dei biglietti.

Sede operativa

La sede operativa è descritta essere disposta su due piani. Qui possiamo proporre un classico cablaggio strutturato prevedendo una zona server al piano terra con accesso ristretto, sistema anticendio e opportunamente climatizzata. Qui troviamo i server che accetteranno le richieste GET/POST con modalità RestFull di totem e tablet, avendo cura di avere un server Apache o NGinx capace di supportare un software php o un server tomcat se il sistema viene realizzato con backend in Java. Saranno supportati da un sistema DB di prestazione adeguate con relativo DMBS. In questa circostanza la mole di dati e connessioni rende adeguato anche un tradizionale DB relazionale come MySQL o PostGRE.

Nella centrale il router di confine avrà capacità VPN per accettare le connessioni dei router dei totem. Contemplata quindi la zona DMZ, sarà opportunamente divisa dalla rete interna LAN con firewall. Nella rete interna avremo armadi di piano e un congruo numero di switch che possono servire i vari impiegati. Si suggerisce di indirizzare almeno due VLAN per suddividere logicamente la rete di chi si occupa della biglietteria e chi della gestione/controllo dei dispositivi IoT remoti.

Modalità di comunicazione

Abbiamo già fatto cenno alle modalità di comunicazione dei dispositivi. Siamo di fatto davanti a dispositivi digitali che possono usufruire del protocollo HTTP e la sua versione sicuro HTTPS. I totem, avranno app o interfacce web che possono quindi perfettamente andare a sfruttare tale protocollo. Gli stessi dispositivi IoT possono interfacciarsi in modo analogo inviando richieste GET/POST con modalità REST per abilitare o meno alcuni comandi remoti direttamente sui dispositivi microcontrollori. I tablet e l’app di validazione può anche essa far riferimento ad opportune API per registrare o controllare i dati dei biglietti, con un opportuna area riservata previo login dell’operatore. Le API vanno opportunamente gestiti con strumenti come OpenID Connect o Toket JWT. I router possono avere interfaccia con VPN per garantire ulteriormente un tunnel preferenziale tra due punti totem e sede operativa.

Resilienza

Quando siamo di fronte ad un servizio online, fondamentale è la connettività. Già nei totem abbiamo individuato la possibilità di dotarli oltre che di cavo fisico, anche di una scheda GSM. Questa necessità è ancora più forte per la sede operativa. Il router di confine andrebbe raddoppiato con almeno una linea di fail over WiMax o 4G/5G.

I server non ci si attende abbiano un traffico elevato in simultanea ma si può valutare di raddoppiare il server inserendo un terzo nodo di load balancing per suddividere il carico delle richieste e mitigare eventuali attacchi DDos. Il database per avere prestazioni e affidabilità potrebbe montare più dischi con modalità un paio di dischi in Raid 1 e tre in Raid 5 per le performance. Tutte le macchine andrebbero messe sotto opportuno UPS. Va previsto un piano di manutenzione e aggiornamento software e hardware sia dei dispositivi della sede centrale che dei totem.

Soluzione seconda parte

Risposta 1

La gestione dei video richiede risorse onerose in termine di spazio per il salvataggio. I video streaming che provengono dalle periferiche posate esternamente inviano flussi dati piuttosto consistenti che richiedono oltre ad una rete con banda larga anche spazio di archiviazione considerevole. L’investimento iniziale per la soluzione interna “On-Premise” sarà quindi elevato per l’acquisto di server ad alte prestazioni con processori Xeon, schede di rete ad alte prestazioni e soprattutto dischi da configurare nella varie modalità RAID. I costi di manutenzione saranno però relativamente contenuti e personale addetto alla gestione sarà di fatto l’unico costo vivo, assieme ai costi per la gestione della sicurezza fisica degli ambienti e dispositivi. Il vantaggio della soluzione in-house però è la rapidità di reperimento del materiale senza aggravi sulla banda di rete e la gestione e controllo completo del materiale. La soluzione in cloud con un fornitore di archiviazione terzo non ha costi iniziali per l’acquisto dei server o del personale interno, ma solo costi vivi degli abbonamenti. In questo caso l’azienda garantisce standard di sicurezza, affidabilità, reperimento sostanzialmente alti ma a fronte di abbonamenti spesso molto onerosi. Svantaggio enorme sarà il non controllo dei dati e la necessità di una banda adeguata quando si vuole reperire un file: se la rete non c’è o è satura, non possiamo accedere al materiale. Sul lungo periodo i canoni possono essere poi più gravosi. Soluzione smart potrebbe essere quella di investire alcuni fondi per una macchina server dove catalogare una parte dei dati sul breve periodo, ad esempio 10 giorni per operazioni sulla raccolta di statistica o indagini di polizia, in caso di accesso o reperimento rapido, mentre su sistemi cloud meno performanti destinare l’archiviazione sul lungo periodo qualora necessario.

Risposta 2

Questo è uno dei quesiti forse più complessi che tocca argomenti spesso poco approfonditi. Un esempio lo affronto in geenre con un piccolo server REST su ESP8266 per inviare richieste HTTP per pilotare un semplice led =>qui. Se le telecamere smart possiedono un server HTTP interno è possibile governarle con un sistema di chiamate REST e le primitive GET, ad esempio per reperire informazioni sullo stato della telecamera o i file di configurazioni es. se la telecamera è mappata con IP 192.168.1.100, una chiamata GET potrebbe assomigliare alla seguente

GET http://192.168.1.100/config/status

In modo analogo potrei inviare dei comandi o configurazioni con le primitive POST o PUT inviando dati immersi nel corpo del messaggio o addirittura un intero file JSON o XML se i dati dovessero essere articolati.

POST http://192.168.1.100/config/ con un JSON del tipo:

{ 
    "azione": "muovi", 
    "direzione": "sinistra", 
    "angolo": 45,
    "risoluzione": 720 
}

Risposta 3

Queste tecnologie le abbiamo già trattate ampiamente in =>questo articolo. Fa eccezione, con mio stupore la citazione dello standard IEEE 802.15.4 solitamente assente nella stragrande maggioranza dei manuali scolastici e che nel mio articolo è citato indirettamente con la tecnologia ZigBee che sostanzialmente è un protocollo per aree personali PAN con bassi consumi, piccola banda, costi contenuti, piccola distanza operativa. In questo caso il candidato poteva dilungarsi sulle NFC, RFID e BLE ben spiegate.

Risposta 4

Un interessante quesito sul troubleshooting che richiede un pizzico di attenzione da parte dell’alunno. Il pc pinga un altro utilizzando l’indirizzo IP. Il risultato positivo ci indica che il protocollo ICMP ha funzionato appieno a livello di rete. Non ci sono anomalie di configurazione fisica sui cablaggi, ne su indirizzi o maschere di rete. Nno sembra esserci a livello IP alcun blocco o ACL di un ipotetico firewall. Il pc non è raggiungibile usando il nome, mentre esternamente possiamo accedere a nomi di server. C’è una anomalia quindi nel DNS che internamente non risolve i nomi mentre esternamente segue il sistema classico di funzionamento probabilmente affidandosi al secondo dei DNS 212… Va aggiunto un record Host nel DNS interno 192.168.1.2. L’alunno probabilmente potrebbe affrontare un esercizio simile su Cisco Packet Tracer aggiungendo un A record come in figura.

*Configurazione di un Record A in Cisco Packet Tracer*

Un elemento interessante sono i TTL, TIME TO LIVE, 56 ci fa capire che il dispositivo è diviso da un numero discreto di apparati interni, probabilmente 8 se supponiamo i pc linux che hanno di default un valore 64 – 56 = 8. Verso l’esterno il TTL peggiora ma addirittura assistiamo ad un pacchetto anomalo con una durata di 214ms, probabilmente frutto di una congestione di rete in qualche punto.

Ultima modifica 20 Giugno 2026