Home
Accesso / Registrazione
 di 

Serratura elettronica comandata da Smartwatch/Smartphone

Serratura elettronica comandata da Smartwatch/Smartphone

Una serratura elettronica consente l’apertura di una porta (o l’attivazione/disattivazione di un dispositivo) a chi è in possesso del corretto codice, così come una chiave consente l’apertura di una serratura “tradizionale”. Esistono differenti tipi di serrature elettroniche, catalogabili in base al modo in cui viene fornito il codice. Le più semplici prevedono una tastiera, quelle più complicate la rilevazione di dati biometrici (p.e. l’impronta digitale), passando da tutte le serrature basate su tecnologie a radiofrequenza, in cui si utilizza un badge o un portachiavi dotato di trasponder. Tutte queste serrature richiedono però la presenza di un elemento visibile attivo (tastiera, lettore biometrico, …) che può essere oggetto di atti di vandalismo, o passivo (badge, portachiavi, …) che può essere sottratto/rubato/smarrito o persino dimenticato. Perché non realizzare una serratura elettronica che possa essere comandata da un oggetto che si porta più facilmente con sé, come un orologio o un telefono? Utilizziamo uno Smartwatch od un qualsiasi Smartphone per inviare tramite Bluetooth il codice di sblocco alla serratura, realizzata con una scheda XMC2Go di Infineon.

Schema di principio

Il progetto può essere schematizzato nel modo seguente:

Schema a blocchi

Analizziamo ogni sezione approfondendone il funzionamento.

Alimentazione

Lo stadio di alimentazione fornisce la corretta tensione a tutte le altre sezioni. Possiamo pensare di utilizzare un alimentatore da 220V a 5V con connettore di uscita micro USB, facilmente reperibile in commercio, per alimentare direttamente la scheda XMC2Go: questa ci fornirà poi un’alimentazione a 3.3V che potremo utilizzare eventualmente per gli altri stadi. Per quelli che richiedono una potenza superiore, come lo stadio degli attuatori, conviene utilizzare direttamente l’alimentazione di 5V.

Interfaccia Bluetooth

L’interfaccia Bluetooth verrà realizzata con un modulo totalmente integrato reperibile sul mercato. Questo ci consentirà di non dover omologare la parte a radiofrequenza, utilizzando quella già effettuata dal produttore; inoltre, come avremo modo di approfondire nella spiegazione del funzionamento, il modulo Bluetooth consentirà di semplificare il firmware, che si occuperà solo della parte funzionale vera e propria, senza doversi prendere carico della gestione dello stack di comunicazione radio.

CPU (XMC2Go)

Il cuore dell’applicazione è la scheda XMC2Go. Il firmware residente sul microcontrollore gestirà il funzionamento della serratura elettronica ricevendo e trasmettendo i dati via Bluetooth ed interfacciandosi con gli attuatori.

USB

Possiamo prevedere di utilizzare la porta USB (in configurazione VCP, porta seriale virtuale) per programmare alcuni parametri di funzionamento (p.e. la durata dell’eccitazione del relais, il codice di sblocco, i dispositivi autorizzati …). Una porta seriale è infatti facilmente gestibile da un PC, con qualsiasi sistema operativo, ricorrendo anche ad applicazioni preesistenti (quindi senza dover scrivere un programma apposito).

Attuatori

La sezione attuatori consente alla serratura elettronica di interagire col mondo esterno, attivando la serratura elettromeccanica. In prima istanza, nel modello più semplice di serratura che si può realizzare, è sufficiente un relais. Possiamo inoltre utilizzare i due LED a bordo scheda per effettuare alcune segnalazioni: un LED potrebbe lampeggiare con cadenza fissa per segnalare che la serratura è in funzione, mentre l’altro potrebbe indicare lo stato di attivazione del relais.

Logica di funzionamento

Il modello più semplice di serratura che possiamo realizzare prevede:

  • la presenza nella memoria del microcontrollore del codice di sblocco
  • la ricezione via Bluetooth di un codice di sblocco da confrontare con quello in memoria
  • l’attivazione per un tempo prefissato del relais, nel caso in cui i codici coincidano

Il codice di sblocco potrebbe essere inserito direttamente nel firmware, ma questo ci impedirebbe di poterlo cambiare senza programmare la scheda ex-novo. Utilizzando la porta USB, che viene mostrata ad un PC come porta seriale virtuale, potremmo invece inviare dei semplici comandi utilizzando un programma terminale (p.e. TeraTerm, Hyperterminal, …) con cui cambiare il codice tutte le volte che vogliamo.

Un po’ più complessa è la gestione del Bluetooth: le risorse di memoria (soprattutto RAM) messe a disposizione dalla scheda XMC2Go non sono sufficienti per poter gestire lo stack di protocollo contemporaneamente all’applicazione; a questo va aggiunta la necessità di omologare il dispositivo come compatibile con lo standard Bluetooth, ed il pagamento delle royalties relative. Per risolvere il problema possiamo ricorrere al modulo SPP eUniStone di Infineon: questo è un dispositivo integrato che espone un’interfaccia Bluetooth con il profilo Serial Port (da cui SPP, Serial Port Profile), controllabile dall'XMC2Go via porta seriale mediante comandi in stile AT. Questo ci consente di semplificare il firmware, dal punto di vista della gestione della comunicazione, ed anche l’applicazione lato smartwatch/smartphone, che dovrà limitarsi ad inviare e ricevere dati su una porta seriale. Questa semplificazione, inoltre, facilita anche il debugging del firmware, perché per inviare i comandi è possbile utilizzare direttamente un PC dotato di interfaccia Bluetooth, senza dover scrivere subito l'App per Android.

La parte di attuazione della scheda, nella versione più semplice, è formata da un relais controllato dalla scheda XMC2Go tramite un transistor. L’attivazione del relais, a seguito della ricezione del corretto codice di sblocco, può essere effettuata per un tempo fisso, eventualmente modificabile via USB.

Quick-look algoritmi

Possiamo pensare così strutturato il firmware sull’XMC2Go:

Diagramma di flusso firmware

Vista la semplicità dell’applicazione possiamo pensare di scrivere un’applicazione monolitica, che non faccia uso di un sistema operativo realtime (RTOS). All’accensione il firmware si occuperà di inizializzare opportunamente la scheda (clock, periferiche attive e configurazione dei pin di I/O, inclusi quelli utilizzati come periferiche speciali), le variabili di gestione interne (code dei comandi, stato attuatore/i, …) ed il modulo Bluetooth.

A questo punto si attiva un loop in cui vengono analizzate le code dei comandi che arrivano dalle periferiche (seriale collegata al modulo Bluetooth e seriale virtuale USB); in funzione di ciò che viene elaborato da queste code, lo stato interno del dispositivo viene aggiornato ed il relais attivato o disattivato.

Due routine di interrupt raccolgono i dati provenienti dalle seriali e li inseriscono nelle code per l’analisi ed elaborazione; è possibile pensare di attivare un ulteriore interrupt su un timer per ottenere una temporizzazione precisa.

Applicazione Android

L'App per il dispositivo Android, Smartwatch o Smartphone, dovrà effettuare il pairing con la serratura via Bluetooth. A pairing attivo sarà disponibile al sistema operativo una porta seriale virtuale, con la quale sarà possibile comunicare in modo bidirezionale con il firmware presente sull'XMC2Go. A seconda del livello di sicurezza che si intende ottenere è possibile scrivere l'applicazione in modo che invii il codice di sblocco in automatico, oppure che presenti una tastiera per immetterlo.

Evoluzioni possibili

È possibile aggiungere diverse funzionalità alla serratura, per aumentare sicurezza ed efficienza:

  • un algoritmo di criptazione come AES può essere inserito nel protocollo seriale, così da rendere indecifrabili i comandi che viaggiano tra smartwatch e la serratura. PolarSSL (https://polarssl.org/) è una libreria adatta a questo scopo
  • la presenza di un orologio RTC collegato su bus SPI e dotato di batteria tampone può consentire di gestire delle fasce orarie di funzionamento, in cui non è possibile sbloccare la serratura o in cui la stessa si sblocca o blocca automaticamente
  • collegando una E2PROM/FLASH su bus SPI possiamo pensare di memorizzare i MAC addresses di dispositivi Bluetooth considerati “sicuri”, dai quali quindi è consentito inviare il codice di sblocco; un dispositivo non contenuto all’interno della lista non verrebbe considerato e quindi non potrebbe comandare l’apertura
  • possiamo gestire l’apertura con un algoritmo di rolling code, in modo che il codice di sblocco cambi ad ogni utilizzo (in questo caso l'applicazione Android invierà automaticamente il codice alla serratura, senza che l'utente lo debba introdurre)
  • possiamo aggiungere un secondo relais come uscita ausiliaria che assuma diverse funzioni:
    • nel caso in cui il codice ricevuto non sia corretto, oppure a seguito di un certo numero di tentativi di accesso non andati a buon fine, potrebbe comandare l’accensione di un allarme;
    • potrebbe essere attivata da un secondo codice, ad esempio per comandare l’accensione di luci di cortesia (in questo caso la durata dell’attivazione del relais potrebbe essere differente dal primo)
    • potrebbe attivarsi contestualmente all’attivazione del primo relais, ma con una durata differente (sempre per l’accensione di luci di cortesia, o come consenso alla videoregistrazione da parte di un impianto di video sorveglianza)
  • possiamo aggiungere degli ingressi (optoisolati) per rilevare condizioni aggiuntive allo sblocco della serratura, come la presenza di una persona all’uscio (tramite rivelatore infrarosso passivo o sensore di pressione posto sul pavimento)

L’applicazione in sé può inoltre essere adattata a funzionare anche per altri scopi, come ad esempio accensione/spegnimento di carichi via Bluetooth (presa radiocomandata).

 

 

Scrivi un commento all'articolo esprimendo la tua opinione sul tema, chiedendo eventuali spiegazioni e/o approfondimenti e contribuendo allo sviluppo dell'argomento proposto. Verranno accettati solo commenti a tema con l'argomento dell'articolo stesso. Commenti NON a tema dovranno essere necessariamente inseriti nel Forum creando un "nuovo argomento di discussione". Per commentare devi accedere al Blog
ritratto di Piero Boccadoro

Uno dei motivi per cui questo

Uno dei motivi per cui questo progetto ha vinto la nostra selezione è il fatto che si propone come complesso ma di elementi semplici che possono essere gestiti ed organizzati in maniera molto intelligente.
Sebbene si tratti di una singola applicazione, questo progetto risulta al tempo stesso, variegato.
Una vera e propria sfida che ci auguriamo vada in porto il prima possibile e della quale, ne siamo sicuri, sentiremo ancora parlare.
Complimenti ancora.

ritratto di Boris L.

mi è piaciuto molto di più

mi è piaciuto molto di più quello della settimana scorsa sui farmaci però anche questo sembra carino.
Quali sono gli altri che hanno vinto?

ritratto di gfranco78

Una domanda sulle aggiunte:

Una domanda sulle aggiunte: perchè gli ingressi di cui si parla è specificato che devono essere optoisolati? Che vantaggio c'è?

ritratto di Stefano.Bettega

Perchè optoisolare gli ingressi

Ciao,
optoisolare gli ingressi ha due vantaggi principalmente:
- proteggere l'elettronica da problemi che possono arrivare dal mondo esterno (p.e. corto circuiti)
- effettuare una traslazione del livello di tensione per adattare i livelli logici provenienti da sistemi differenti (p.e. le uscite di un PLC a 12/24V oppure segnali in corrente alternata)
Ovvio, non è un requisito fondamentale, tutto sta a dove si intende portare l'applicazione. Su un portone di ingresso o un cancello posto all'esterno, dove magari gli ingressi provengono da un circuito distante dalla scheda, può essere una scelta intelligente e conservativa.

ritratto di gfranco78

Non ti seguo: perchè

Non ti seguo: perchè conservativa? che c'entra che la scheda è lontana?

ritratto di Stefano.Bettega

Perché optoisolare

Se la scheda XMC2Go e gli opto sono lontani dal punto in cui viene generato il segnale di consenso, è molto più probabile che possano avvenire inconvenienti. Per farti un esempio che mi è capitato di vedere di recente: i corrugati degli impianti elettrici dei soffitti una volta venivano fatti passare nella soletta del piano superiore e non nei tavolati; se il vicino del piano di sopra rifaceva il pavimento, capitava spesso che i muratori, inconsapevolmente, tagliassero col flessibile tubo e cavi a quello del piano di sotto. Ma ancora peggio: per portare i cavi alla parte mobile dei cancelli si usano sempre tubi flessibili che sono sempre in movimento; anche lì porrebbero avvenire corto circuiti, addirittura un conoscente ha dovuto ricablare il cancello più volte perché il cane si divertiva a strappare tutto.
Nei miei progetti preferisco sempre usare un opto quando non son certo della provenienza del segnale: facilita l'interfacciamento e tiene lontani molti problemi; il costo non è elevato, anche perché (salvo casi eccezionali) è possibile utilizzare opto non particolarmente veloci.
Spero di aver fatto chiarezza, se hai dubbi sono sempre a disposizione.

 

 

Login   
 Twitter Facebook LinkedIn Youtube Google RSS

Chi è online

Ci sono attualmente 36 utenti e 67 visitatori collegati.

Ultimi Commenti