[Archimede] 2 progetti Open Source: antifurto e controllo accessi

ladro

Questo mese ospitiamo nuovamente Archimede, questa volta al lavoro su due esempi applicativi molto utili e realizzabili grazie al solo kit base: un controllo accessi ed un antifurto. E sono davvero impressionanti. Leggete questo articolo, lasciatevi incuriosire dalle potenzialità del kit e tenendo a mente che il kit è in palio nel montepremi del nostro Review4U 2.0 e disponibile in offerta sul relativo sito.

Come avete letto nell'introduzione, le applicazioni che vi stiamo presentando vi mostreranno il kit Archimede al lavoro su ben due distinti esempi di applicazioni reali. Esse costituiscono una buona base di partenza per tutti coloro che intendono implementarsi il loro proprio controllo accessi e/o antifurto.
Le due applicazioni differiscono tra loro, come avrete modo di vedere tra poco, solo per una minima parte di codice e per il differente utilizzo degli I/O della scheda, segno evidente di quanto la scheda si dimostri versatile. Dal momento che queste differenze sono minime, inoltre, gran parte del firmware risulterà utile anche per la seconda delle due applicazioni. Sarà, quindi, volendo, anche possibile combinare le due in una unica soluzione di controllo accessi/antifurto con un minimo intervento sul codice. Tenete presente, comunque, che, in questo caso, avrete la necessità di dotare la scheda di I/O aggiuntivi (che potrete trovare sul sito).

Controllo degli Accessi

In questa applicazione, oltre al kit base di Archimede è coinvolto il seguente hardware (non fornito nel kit):
  • 1 testa di lettura di chiavi i-button;
  • 1 pulsante;
  • 1 LED con relativa resistenza per la limitazione della corrente;
  • 1 micro sd-card (per il salvataggio persistente delle chiavi);
  • 1 serratura elettrica;

Schema di cablaggio

Funzionamento

Lo scopo di un controllo accessi è, naturalmente, quello di limitare l'accesso ad una zona ad un gruppo più o meno ristretto di persone. Per la nostra applicazione supporremo un numero abbastanza limitato di persone abilitate, in quanto le strategie adottate per l'immagazzinamento dei dati relativi alle abilitazioni sono state rese appositamente semplici al fine di mantenere una certa efficienza e nel contempo una certa comprensibilità del codice.
Il funzionamento è piuttosto semplice:
  1. tramite una procedura descritta in seguito vengono memorizzati i codici delle chiavi abilitate (un file residente sull'SD-card)
  2. durante il funzionamento normale, quando una chiave viene appoggiata sulla testa di lettura (normalmente collocata vicino alla porta da controllare) questa viene letta, il codice viene ricercato tra quelli memorizzati e, se presente, viene generato un impulso sul relè al quale è collegata una serratura elettrica che apre la porta. In caso contrario, non accade nulla e la porta non si apre.

Il software

In questa sezione descriviamo la struttura del software che “anima” questa applicazione, rimandando i dettagli al lettore che beneficerà sicuramente del gran numero di commenti presenti nel codice.
L'applicazione principale (funzione Main) crea le istanze di tutte le risorse hardware necessarie e poi entra in un loop infinito (ciclo di idle dell'applicazione) nel quale vien fatto lampeggiare il LED RUN della scheda madre e si esegue il poll su due oggetti:
  • il componente che si occupa di leggere l'eventuale chiave presente sulla testa di lettura (OneWireKeyReader)
  • il componente che si occupa di gestire la programmazione della lista delle chiavi abilitate (KeyList)
Tutto il resto è gestito negli eventi relativi ai vari oggetti istanziati nel Main. 
 

Il lettore di chiavi

Per questa applicazione viene utilizzato soltanto l'evento OnKeyDetected dell'oggetto lettore di chiavi (OneWireKeyReader). Tale evento viene generato una sola volta per ogni evento di lettura della chiave sulla testa di lettura.
Analizzando un po' più nel dettaglio ciò che viene fatto in questa funzione si capisce come funziona  il cuore del sistema:
private static void KeyReaderOnKeyDetected(object sender, KeyEventArgs e)
{
      Debug.Print(e.ROMCode);
      // Verifico che la chiave sia abilitata
      if (_keyList.Status == KeyList.ProgrammingStates.Idle)
      {
          if (_keyList.Contains(e.ROMCode))
          {
              // Se la chiave è abilitata genero un impulso di 1 secondo sul relè
              Debug.Print("Chiave abilitata");
               _relay.On(1000);
           }
           else
           {
               Debug.Print("Chiave non abilitata");
            }
       }
}
Come si può vedere la prima cosa che viene verificata è lo stato in cui si trova la lista delle chiavi abilitate. Se esso risulta Idle significa che la lista delle chiavi è nella sua condizione standard. Se si trova in qualsiasi altro stato, vuol dire che è in corso la programmazione delle chiavi (vedi enumerativo KeyList.ProgrammingStates per maggiori dettagli).
Verificato lo stato della lista si prosegue semplicemente controllando che la lista (_keyList) contenga il codice ricevuto come argomento della chiamata (e.ROMCode), nel qual caso si attiva il relè per 1 secondo (_relay.On(1000)).

Gestione della programmazione delle chiavi

Tutta la programmazione delle chiavi è demandata a _keyList un oggetto di tipo KeyList (vedi sorgenti). Il vero cuore di questo oggetto è il metodo Poll il quale richiama una macchina a stati definita internamente che si occupa di gestire la programmazione delle chiavi il cui funzionamento può essere sintetizzato come segue:
  • Viene monitorato l'ingresso a cui è collegato un pulsante;
  • Se viene rilevata una pressione che dura più a lungo di 4 secondi, si entra in modalità programmazione altrimenti si torna alla modalità normale;
  • Se la pressione persiste e si superano i 10 secondi, nel momento del rilascio del pulsante l'intera lista delle chiavi abilitate verrà cancellata e poi si passa nuovamente alla modalità programmazione;
  • Nella modalità programmazione basta appoggiare una chiave sulla testa di lettura per leggerla e memorizzarla nella lista (internamente viene controllato che la chiave non sia già presente, nel qual caso non verrà memorizzata nuovamente). Entrati nella modalità programmazione si ha al massimo 1 minuto di tempo tra la lettura di una chiave ed un'altra, trascorso il quale intervallo il sistema tornerà nella modalità standard;
  • Per uscire dalla modalità programmazione, senza aspettare il minuto di timeout, basta ri-premere il pulsante in qualsiasi momento.

L'indicatore LED

Viene sfruttato il secondo canale 1-wire per pilotare un LED (max 50mA); esso viene utilizzato per dare indicazioni visive riguardo il funzionamento della scheda e andrebbe portato vicino alla testa di lettura 1-wire in modo da essere visibile quando si opera con la chiave.
In condizioni normali, l'indicatore lampeggia alla frequenza di 1Hz. Quando si passa in modalità programmazione il lampeggio si interrompe ad indicare l'attesa di una chiave. Quando essa viene letta correttamente si verificano 3 lampeggi veloci.
Nel caso in cui si passi prima dalla cancellazione chiavi, al rilascio del pulsante (dopo quei 10 secondi) verranno emessi 6 lampeggi veloci per indicare l'avvenuta cancellazione. Successivamente  il LED resterà spento (sarà in modalità programmazione). Chiusa la fase di programmazione, il LED tornerà a lampeggiare normalmente.
 
Il funzionamento di questo indicatore è stato “astratto” nella classe LedIndicator la quale incapsula un oggetto di tipo OutputPort e ne codifica i funzionamenti ON, OFF e Lampeggio. Una volta creato un oggetto di tipo LedIndicator si interagirà con esso tramite le sue due proprietà Mode e BlinkFrequency: la prima indica la modalità di funzionamento (ON, OFF e Lampeggio), l'altra la frequenza del lampeggio.
 

L'antifurto

Vi avevamo accennato che i progetti sarebbero stati 2 ed eccoci al secondo caso applicativo. Questa volta oltre al kit base di Archimede è coinvolto il seguente hardware (non fornito nel kit):
  • 1 testa di lettura di chiavi i-button;
  • 1 pulsante;
  • 1 LED con relativa resistenza per la limitazione della corrente;
  • 1 micro sd-card (per il salvataggio persistente delle chiavi);
  • 1 sensore di vibrazione o contatto (Es. sensore di vibrazione HAA15);
  • 1 sirena;

Schema di cablaggio

Funzionamento

Lo scopo di un antifurto, come ben si sa, è funzionare da deterrente contro i malintenzionati. I moderni antifurto sono formati da una moltitudine di sensori collegati alla centralina il cui scopo è quello di interpretare e decidere se e quando far scattare la sirena, mandare SMS, attivare luci e così via dicendo.
Questa applicazione è stata realizzata appositamente per essere semplice, comprensibile e, volendolo, facilmente ampliabile. Sono, quindi, state fatte due assunzioni:
un solo sensore collegato al secondo optoisolatore della scheda (l'altro è utilizzato per la programmazione delle chiavi abilitate). Ovviamente aggiungendo maggiori I/O alla scheda fornita nel kit base è possibile espandere il sistema per gestire un maggior numero di sensori;
supporremo un numero abbastanza limitato di persone abilitate ad armare/disarmare l'antifurto in quanto le strategie adottate per l'immagazzinamento dei dati relativi alle abilitazioni sono state rese semplici proprio al fine di mantenere una certa efficienza e nel contempo una certa comprensibilità del codice.
 
Il funzionamento è piuttosto semplice e può essere sintetizzato in 2 diversi stati in cui l'antifurto può trovarsi:
  • Funzionamento normale (non armato), l'antifurto è disabilitato
  • Armato: l'antifurto è armato e se cambia l'ingresso del sensore scatta il relè su scheda, a cui sarà collegata una sirena.

Programmazione

Vedi quanto detto nel controllo accessi.

Il software

Come vi avevamo accennato, la struttura del software necessario in questa applicazione è quasi totalmente identica a quella del controllo accessi e pertanto verranno descritte soltanto le differenze.
Come per il controllo accessi l'applicazione principale (funzione Main) crea le istanze di tutte le risorse hardware necessarie e poi entra in un loop infinito (ciclo di idle dell'applicazione) nel quale si fa lampeggiare il LED RUN della scheda madre e si esegue il poll sui due oggetti precedentemente descritti, con la sola eccezione che la chimata al metodo Poll della lista delle chiavi abilitate viene fatta solo se l'antifurto non è attivo. Ciò significa che non sarà possibile programmare la lista delle chiavi quando l'antifurto è armato (d'altronde sarebbe davvero insensato il contrario, non trovate?!).
 
Anche qui tutto il resto viene gestito all'interno dei gestori degli eventi. In questo caso l'evento OnKeyDetected servirà soltanto a commutare il flag _armed che indica lo stato dell'antifurto.
Sull'ingresso optoisolato, a cui è collegato il sensore dell'antifurto (di tipo InterruptPort), è stato “collegato” l'evento OnInterrupt su entrambi i fronti del segnale.
…
    _doorSensor = new InterruptPort(HardwareMapping.DoorSensorPin, true, [...]
    [...] Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeBoth);
    _doorSensor.OnInterrupt += OnDoorSensorInterrupt;
…
Quindi andremo a gestire nell'opportuna sezione di codice l'attivazione della sirena
private static void OnDoorSensorInterrupt(uint port, uint data, DateTime time)
       {
           if (data == 0 && _armed)
           {
               // Attivo l'allarme 
               Debug.Print("scattato l'allarme!");
               _relay.On();
           }
           Debug.Print(data.ToString());
       }

L'indicatore LED

Anche in questa applicazione viene utilizzato il LED per dare indicazione visiva dello stato del sistema. Qui, l'unica differenza rispetto al caso precedente è il lampeggio del LED che avverrà a frequenze diverse a seconda se l'antifurto è armato oppure no.
Lampeggio veloce a 5 Hz = antifurto armato
Lampeggio lento a 1 Hz = antifurto disarmato
Per ogni altra indicazione luminosa vale quanto detto per il controllo accessi.

Idee e proposte

Per rendere le cose semplici, una volta innescata, la sirena continua a suonare fino a che un utente abilitato non disarma l'antifurto. Naturalmente in un caso reale sarà necessario far suonare la sirena per un certo periodo di tempo, poi azzittirla ma tenere l'allarme attivo e così via ciclicamente.
Unificare controllo accessi con antifurto espandendo la scheda e realizzando, in definitva, un progetto più completo.
Grazie alla programmazione ad oggetti e agli oggetti già fatti e forniti nell'SDK di Archimede, si può realizzare un tele-allarme GSM in modo che l'antifurto mandi un SMS in caso di allarme e lo stato dell'allarme possa essere resettato sempre tramite un SMS.
Il team di sviluppo in merito al progetto dichiara: "Lavoriamo ad  altre idee e all'espansione di questi esempi  per condividerle con il mondo".
Nel frattempo, però, tutti noi attendiamo le vostre idee ed opinioni. Che ne pensate?
Questo articolo vi ha reso più interessante questo premio in palio?

Leave a Reply