Antifurto MBSE 0: il progetto e le specifiche congelate

📍 Fase: Modellazione SysML v2 — qui si costruisce il modello (requisiti, architettura, verifica). La parte tecnica di dettaglio (schematici KiCad, firmware, app, cloud) arriverà nella serie di ingegneria di dettaglio dell’antifurto.

Se vuoi sapere perché ho deciso di costruirmi un antifurto invece di comprarne uno (spoiler: un preventivo, un abbonamento e una pila da tre euro), parti dal preambolo della serie.

Dopo la stazione meteo, un secondo progetto completo da seguire dall’idea al prodotto: un sistema antifurto domestico con controllo accessi contactless. Lo sviluppiamo con lo stesso metodo della serie MBSE: prima il modello con MagicGrid e SysML v2, poi l’ingegneria di dettaglio.

Un antifurto è un caso di studio MBSE ancora più istruttivo della stazione meteo, per tre motivi:

Ha un avversario. La stazione meteo deve solo funzionare; l’antifurto deve funzionare mentre qualcuno cerca di impedirglielo: taglia cavi, smonta lettori, disturba la radio.
Deve degradare con grazia. Blackout, internet assente, telefono scarico: ogni guasto è uno scenario da progettare, non un’eccezione da ignorare.
È un sistema di sistemi. Centrale, sensori cablati e wireless, lettori, console, app, cloud, rete cellulare: le interfacce contano quanto i componenti.

In questo primo articolo fissiamo il punto di partenza: lo schema a blocchi e le specifiche congelate, cioè le decisioni prese prima di iniziare a modellare. Dal prossimo articolo si apre la griglia MagicGrid.

1. L’idea: due livelli di sicurezza

Il principio che guida tutto il progetto è semplice da dire e impegnativo da realizzare: una sicurezza minima deve essere garantita sempre, anche senza corrente, senza internet e senza smartphone. Per questo il sistema è diviso in due livelli:

Sicurezza minima (arancione): sensori cablati, centrale, sirene, alimentazione con batteria, modem cellulare, console in casa e modulo del garage. È la parte che deve rilevare un’intrusione e far suonare l’allarme in qualunque condizione.
Livello connesso (viola, tratteggiato): sensori wireless, lettori contactless, rete locale, cloud e app. Aggiunge comodità e copertura, ma se si guasta il sistema scende in modalità degradata senza restare scoperto.

2. Le specifiche congelate

Prima di modellare abbiamo discusso e fissato le scelte che condizionano tutto il resto. “Congelate” significa che il modello partirà da qui: cambiarle più avanti è possibile, ma richiede di ripercorrere la tracciabilità.

Elemento	Scelta	Perché
Centrale	ESP32-S3 + ESP32-H2, secure element ATECC608	Continuità con la serie ESP32; l’H2 porta la radio 802.15.4; le chiavi non escono mai dal secure element
Sensori cablati	8 zone a doppio bilanciamento con tamper	Distinguono riposo, allarme, taglio e cortocircuito della linea
Sensori wireless	16 nodi Thread (802.15.4) su rete dedicata	Protocollo IP pronto per Matter; rete separata dalla domotica per controllare supervisione e jamming
Accesso	Smartphone BLE, tessera NFC (MIFARE DESFire EV3), PIN in console	Tre alternative equivalenti: ne basta una per l’uso normale
Lettori	2 lettori (porta di casa, garage), espandibili a 4, su bus RS-485 cifrato	Il lettore è all’esterno ed esposto: non contiene chiavi né relè, decide sempre la centrale
Aree	Casa e garage, inseribili separatamente	Il garage (due piani sotto) può restare inserito di notte con la casa disinserita
Garage	Modulo satellite con sirena e batteria, collegato via cavo RS-485 isolato	Due solai di cemento sono troppi per il 2,4 GHz; se il cavo viene tagliato il garage continua a proteggersi e la centrale segnala il guasto
Comunicazioni	LAN/Wi-Fi + Cat-1 sempre connesso, eventi inviati in parallelo	Il cellulare non è un backup da “accendere”: è sempre pronto e supervisionato con un heartbeat
Console in casa	Raspberry Pi CM5 (eMMC, filesystem in sola lettura), touch 7″, Flutter; encoder e tasti ON/OFF su MCU sempre acceso	Stessa interfaccia dell’app; in blackout il Pi si spegne e restano encoder, tasti ed e-paper
Cloud	VPS Contabo: broker MQTT, API, database, notifiche push	Dati sotto il nostro controllo; la centrale apre solo connessioni in uscita, niente porte aperte sul router
Riferimento	EN 50131 grado 2	Usata come guida di progetto (supervisione, antimanomissione, alimentazione), senza puntare alla certificazione

3. Le modalità degradate

Ogni componente del livello connesso può mancare. Per ciascun guasto il sistema ha una risposta prevista già in fase di specifica:

Manca la corrente: centrale, modulo garage e sensori cablati passano a batteria; la console spegne a gradini prima il monitor e poi il Raspberry Pi, lasciando attivi encoder, tasti e display e-paper.
Cade internet: gli eventi arrivano comunque al cloud tramite il Cat-1, già connesso.
Qualcuno disturba la radio: il jamming viene rilevato e diventa esso stesso un allarme; il perimetro cablato resta attivo.
Viene tagliato il cavo del garage: la centrale lo segnala come allarme di supervisione, mentre il garage continua a rilevare e a suonare in autonomia.
Il telefono è scarico o perso: si usa la tessera NFC o il PIN in console.
Il cloud non risponde: allarme, sirene, console e accesso BLE funzionano comunque in locale.

4. Cosa non fa (per ora)

In questa versione il sistema gestisce solo l’allarme: smartphone e tessera inseriscono e disinseriscono, ma la porta si apre con la chiave normale. La serratura motorizzata è prevista come variante futura: il modello la conterrà già come estensione, con margine su bus e alimentazione, e con una regola fissata fin da ora: il comando della serratura starà sempre dal lato interno, mai nel lettore esterno.

5. Il percorso della serie

Seguiremo la griglia MagicGrid come per la stazione meteo, riga per riga:

Problem Domain, black-box: stakeholder needs e system context; poi casi d’uso e misure di efficacia.
Problem Domain, white-box: analisi funzionale e sottosistemi concettuali.
Solution Domain: requisiti di sistema, architettura logica e fisica, interfacce (bus RS-485 sicuro, rete Thread, protocollo MQTT).
Ingegneria di dettaglio: firmware, PCB in KiCad, backend, app e console Flutter.

Come nella serie SW-ALM, i requisiti non resteranno solo negli articoli: li tracciamo anche su ALM Tool, con la cascata Requisiti di Business → Requisiti di Sistema → Requisiti di Sviluppo → Casi di test.

Cosa segue

Nel prossimo articolo apriamo la griglia MagicGrid dalla prima riga: stakeholder needs e system context, con i primi pezzi di modello SysML v2. L’intruso entrerà nel modello come “stakeholder avverso”.