Qualche tempo fa il mio ex istituto superiore mi aveva chiesto di fare una piccola lezione presso i loro studenti sulle potenzialità del sistema GNU/Linux. Io ho subito accettato ed ho creato per loro, insieme al mio «socio» Massimiliano Rossi, anche lui ex studente, una piccola demo su come poter realizzare un semplice ma funzionante sistema di monitoraggio remoto di una stazione di rilevazione; il quale permetta poi di controllare l’evoluzione delle grandezze trattate via Web.

Tutta la catena veniva realizzata intieramente con prodotti liberi e girava naturalmente su di un sistema GNU/Linux. In più, ogni applicazione veniva scritta con un linguaggio sempre diverso in modo da poter presentare le diverse possibilità di programmazione che una macchina GNU/Linux offre.

Spero però che questo lavoro sia utile se non altro come punto di partenza per realizzare piccoli progetti a livello scolastico e non. In tal caso mi piacerebbe avere dei feedback!

Prima di proseguire dico subito che i codici che verranno riportati nel seguito sono pubblicati, insieme ad un po’ di documentazione, all’indirizzo https://www.enneenne.com/projects/demolinux.

Rimango poi a disposizione di chiunque abbia bisogno di chiarimenti al mio solito indirizzo di posta rodolfo.giometti@consulenti-ict.it.

La struttura

La struttura di tutto il sistema di monitoraggio è molto semplice e può essere rappresentata in figura 1.

 

 

nello specifico abbiamo:

• Un embedded satellite il quale si occupa di rilevare direttamente nell’ambiente le grandezze da monitorare (temperatura e peso nel nostro caso) e quindi di trasferirle ai successivi sistemi di elaborazione.
  In un sistema di monitoraggio complesso di queste macchine, generalmente, ce ne sono più di una e sono dislocate spazialmente in prossimità delle grandezze che vogliamo tenere sotto controllo, da questo il nome di embedded (“incassato”, in Italiano).
• Un data base main server che si occupa di organizzare in un data base (MySQL nel nostro caso) tutte le grandezze che vengono rilevate dall’embedded satellite.
  Nel nostro esempio abbiamo un solo sistema ma, anche in questo caso, di queste macchine ve ne può essere più di una, infatti è importante che, globalmente, essa sia sufficientemente potente da gestire una molteplicità di richieste in istanti anche molto ravvicinati.
  Questa macchina inoltre deve essere in grado di soddisfare le richieste di analisi dei dati che arrivano dai vari querying system i quali richiedo spesso delle elaborazioni ulteriori dei dati immagazzinati, come ad esempio aggregazioni e/o selezioni dei dati immagazzinati.
• Un querying system che permetta agli utenti del sistema di monitoraggio di richiedere le informazioni notevoli raccolte. Questo permette di avere una visualizzazione particolare dei dati che ci aiuta meglio a capire se il sistema monitorato sta funzionando come deve o meno (generalmente questo viene fatto creando dei grafici o con degli indicatori/allarmi).

Sempre dalla figura 1 su riportata si evidenziano quali sono le applicazioni notevoli che girano su ogniuno dei tre sistemi e quali sono i vari tipi di collegamento fra di esse.

Nei paragrafi che seguono cercherò, da un lato, di illustrare come queste applicazioni funzionino e come sia possibile installarle su di una macchina di prova. Quindi farò vedere come sia possibile verificare che tutti i sistemi siano correttamente attivi semplicemente utilizzando i normali tool che ogni sistema GNU/Linux ci mette a disposizione.

Purtroppo non ho spazio per riportare il codice, ma esso è ben documentato e semplice, che sono sicuro non presenti alcuna difficoltà a chi ha già progranmato almeno un poco.

Prima di tutto però vediamo come si compila il tutto. Una volta scaricato il tarball esplodiamolo e quindi usiamo il solito:

giometti@zaigor:~/demolinux$ make
make -C sensor all
make[1]: Entering directory `/home/giometti/demolinux/sensor’
make -C /lib/modules/2.6.22-rc4/build SUBDIRS=/home/giometti/demolinux/sensor modules
make[2]: Entering directory `/usr/src/linux-2.6.22-rc4′
Building modules, stage 2.
MODPOST 1 modules
make[2]: Leaving directory `/usr/src/linux-2.6.22-rc4′
make[1]: Leaving directory `/home/giometti/demolinux/sensor’
make -C reader all
make[1]: Entering directory `/home/giometti/demolinux/reader’
cc -Wall -O2 -D_GNU_SOURCE reader.c -o reader
make[1]: Leaving directory `/home/giometti/demolinux/reader’

Nell’esempio qui riportato il driver per i sensori, denominato sensor, è stato compilato per la versione 2.6 di Linux, se voi avete la 2.4 dovete specificare KERNELVER=2.4 nella linea di comando di make. In quel caso otterrete però il file sensor.o.

Ricordo anche, che per compilare il driver occorrono i sorgenti di Linux, i quali possono anche essere specificati direttamente a make aggiungendo KERNELDIR=/path/to/source sempre alla linea di comando.

L’embedded satellite

Vediamo ora come installare l’embedded satellite e verificare che questo funzioni correttamente.

Come già detto su questo sistema sono presenti un driver, che interfaccia i sensori verso lo spazio utente, e due applicazioni, che esportano le informazioni lette dai sensori verso l’esterno.

Il driver è riportato nella directory sensor, mentre le altre applicazioni sono il superserver inetd ed un programmino chiamato reader, riportato nella directory omonima.

Il compito dell’embedded satellite è quello di rilevare le nostre grandezze notevoli (temperatura e peso) interrogando il driver sensor, quindi le formatta opportunamente, grazie all’applicazione reader, e trasferisce il tutto al data base main server utilizzando il superserver inetd.

Il driver sensor

Non sto qua ad entrare nel dettaglio di come questo driver sia realizzato (il lettore curioso veda come si scriver un driver) ma voglio solo accennare ai principi di funzionamento.

Il driver si presenta al sistema come due semplici char device ogniuno dei quali è collegato ad un sensore. Nello specifico il sensore 0 è il sensore di temperatura mentre il sensore 1 è quello di peso.

Poiché non abbiamo fisicamente tali sensori ho optato per simulare tali dispositivi con un generatore di numeri casuali. La scelta non è delle più felici ma raggiunge lo scopo; in pratica ogni volta che si legge in uno dei due sensori si ottiene un valore che può essere associato a grandezze di peso e/o temperatura.

Per installare tale driver e verificare che funzioni correttamente possiamo usare i seguenti comandi:

giometti@zaigor:~/demolinux/sensor$ sudo ./load
Password:
Loading sensor device driver (./sensor.ko)……… done

che carica nel sistema il driver e crea i file associati nella directory `/dev/’:

giometti@zaigor:~/demolinux/sensor$ ls -l /dev/sensor?
crw-rw-rw- 1 root root 254, 0 Aug 5 18:33 /dev/sensor0
crw-rw-rw- 1 root root 254, 1 Aug 5 18:33 /dev/sensor1

A questo punto per verificare che i sensori ci restituiscano qualcosa possiamo utilizzare i seguenti comandi:

giometti@zaigor:~/demolinux/sensor$ od -v -tx1 -N16 < /dev/sensor0
0000000 35 34 33 33 34 33 35 37 36 34 33 35 35 36 35 37
0000020
giometti@zaigor:~/demolinux/sensor$ od -v -tx1 -N16 < /dev/sensor1
0000000 17 3d 48 4d 27 2d 1c 40 23 33 3c 42 30 3a 20 44
0000020

ognuno dei due comandi legge 16 valori (byte) dai dispositivi e ne ritorna la codifica esadecimale.

Il programma reader

Questa applicazione non fa altro che rendere un po’ più semplice interrogare i sensori, non solo, si preoccupa anche di applicare una marca temporale alle grandezze rilevate.

Questa operazione di applicare la marca temporale al dato letto è molto importante in tutti i sistemi di monitoraggio perché è fondamentale sapere in che istante una certa grandezza ha assunto un determinato valore. Poichè, di solito, non è compito del driver restituire una marca temporale ai dati che esso restituisce questo deve essere fatto da una applicazione esterna.

Per verificare che reader funziona correttamente basta lanciarlo ed impartire alcuni semplici comandi come segue:

giometti@zaigor:~/demolinux/reader$ ./reader
Remote sensor manager v1.00. Please submit a command.
help
Valid commands are: help temperature weigh exit
Current time is: 2007/08/05 18:38:24
temperature
Current temperature is 27.5C at time 2007/08/05
18:38:30
weigh
Current weigh is 32.5Kg at time 2007/08/05 18:38:33

Come si vede, ogni volta che viene letto un valore da un sensore questo viene anche formattato e gli viene applicata la marca temporale. Il risultato è una stringa che per noi esseri umani è molto più comprensibile che del dato grezzo ottenibile dal driver (come visto sopra).

Esportiamo il tutto via rete

A questo punto è il momento di rendere la nostra applicazione disponibile in rete.

L’embedded satellite è collegato via rete con il data base main server e quindi occorre poter creare un collegamento fra di essi.

Il problema che di per se potrebbe risultare complesso in realtà ha una soluzione abbastanza banale, a patto di utilizzare il superserver inetd!

Questo server è molto importante perché permette di remotizzare in maniera molto banale una qualsiasi applicazione che di per se i socket non sa nemmeno cosa sono!

Si faccia riferimento alla figura 2.

 

 

In pratica egli non fa altro che mettersi in ascolto su una porta TCP/IP ed ogni qual volta gli arriva una richiesta di connessione la gestisce e quindi manda in esecuzione la applicazione da remotizzare, con l’accortezza però di collegare lo stdin e lo stdout dell’applicazione stessa con il socket in questione. In questo modo l’applicazione pensa sempre di riceve ed inviare dati in locale ma, in realtà, questi viaggiano via rete!

Vediamo come questo si traduce con il comando reader.

Innanzi tuto scegliamo una porta TCP/IP da utilizzare per la connessione remota, ad esempio possiamo usare la porta 12346 (verificate che sul vostro sistema questa porta sia libera), quindi occorre aggiungere la linea:

sensor 12346/tcp # demolinux remote sensor

al file /etc/services. Quindi aggiungiamo questa linea al file di configurazione di inetd che è /etc/inetd.conf:

sensor stream tcp nowait root /usr/sbin/tcpd /usr/local/bin/reader

Quello che abbiamo fatto in questo modo è di dire al superserver che ogni qual volta abbiamo una connessione alla porta TCP/IP 12346 (servizio sensor) egli deve invocare il programma /usr/local/bin/reader; è chiaro allora che occorre anche copiare il nostro programmino reader in tale posizione:

giometti@zaigor:~/demolinux/reader$ cp reader
/usr/local/bin/reader

una volta fatto ripartire il superserver se tutto è andato bene dovremmo avere:

giometti@zaigor:~/demolinux/reader$ netstat -ln | grep 12346
tcp 0 0 0.0.0.0:12346 0.0.0.0:* LISTEN

Ecco che inetd sta ascoltando (LISTEN) una richiesta di connessione alla porta 12346.

Per verificare però che il tutto funziona correttamente possiamo utilizzare il programma telnet in questo modo:

giometti@zaigor:~/demolinux/reader$ telnet 127.0.0.1 12346
Trying 127.0.0.1…
Connected to 127.0.0.1.
Escape character is ‘^]’.
Remote sensor manager v1.00. Please submit a command.
help
Valid commands are: help temperature weigh exit
Current time is: 2007/08/05 18:59:15
temperature
Current temperature is 26.0C at time 2007/08/05 18:59:18
weigh
Current weigh is 33.5Kg at time 2007/08/05 18:59:21
exit
Bye
Connection closed by foreign host.

Io ho utilizzato l’indirizzo dell’interfaccia di loopback (127.0.0.1) ma il tutto funziona anche specificando un indirizzo IP di una macchina remota.

Come allora potete vedere il tutto funziona come prima quando avevamo lanciato reader in locale!

Il data base main server

Bene, passiamo ora a configurare il data base main server. Questo sistema generalmente è una macchina diversa dell’embedded satellite ma nel nostro esempio possiamo anche semplificare la cosa utilizzando sempre la stessa macchina.

Il data base main server ha diversi compiti: da un lato deve interrogare l’embedded satellite per acquisire i valori letti dai sensori, mentre dall’altro deve rispondere alle richieste dei querying system.

Il primo compito è espletato dal programma collector e dal database MySQL, mentre per il secondo compito il tutto è rimandato sempre a MySQL ma con l’aiuto del web server Apache.

Configuriamo dapprima il database MySQL.

Una volta che avete installato MySQL (il che dipende dalla distribuzione che utilizzate) utilizzate il seguente comando per creare le tabelle che verranno popolate dai dati acquisiti:

giometti@zaigor:~/demolinux/database$ mysql -u root < created

A questo punto installiamo i file per Apache che creano il nostro sito Web che dovrà poi mostrarci i dati che abbiamo acquisito, dovrà cioè creare i così detti «report».

giometti@zaigor:~/demolinux/repgen$ sudo mkdir /var/www/demolinux
Password:
giometti@zaigor:~/demolinux/repgen$ sudo cp *.php /var/www/demolinux/

Sul mio sistema ho installato Apache in modo tale che la directory radice esportata sul Web corrisponda alla directory /var/www/, quindi ho installato i file per i report nella directory /var/www/demolinux/.

Per verificare che sia i file di report sia il Web server Apache siano correttamente configurati basta puntare il vostro browser preferito all’URL https://localhost/demolinux/test.php. Se tutto funziona come si deve otterrete quanto riportato in figura 3.

 

 

Se non ottenete questo risultato (o uno similare) verificate di aver correttamente copiato i file e di aver scritto l’indirizzo giusto (io ho sempre usato come indirizzo il nome dell’interfaccia di loopback). Altra verifica da fare è quella di controllare che il vostro server Apache supporti correttamente le pagine di tipo PHP.

Bene, ora il nostro database e il server Web stanno funzionando correttamente e quindi è il momento di popolare il nostro database con i dati che leggiamo dai sensori. Per fare ciò utilizziamo l’applicativo collector.

Questo applicativo è scritto in TCL ed utilizza il plugin mysqltcl che ne estende le funzionalità per accedere ad un data base MySQL (occorre perciò che installiate pure quello). Vediamo come funziona:

giometti@zaigor:~/demolinux/collector$ ./collector
usage: ./collector host port interval

Lanciandolo senza parametri egli ci dice che occorre specificare un host e una porta (port). Come avrete intuito questi parametri servono per indicare a collector le specifiche di connessione verso l’embedded satellite da interrogare; nel nostro caso quindi utilizzeremo i parametri localhost e 12346. Per quanto riguarda il parametro interval esso specifica ogni quanto tempo, in secondi, interrogare lembedded satellite.

Un comando possibile per eseguire il programma è quindi:

giometti@zaigor:~/demolinux/collector$ ./collector localhost 12346 5
./collector: submitting command “temperature”
./collector: got replay “Current temperature is 26.5C at time 2007/08/05 20:13:20”
./collector: submitting temperature data on DB
./collector: submitting command “weigh”
./collector: got replay “Current weigh is 21.0Kg at time 2007/08/05 20:13:20”
./collector: submitting weigh data on DB
./collector: sleep at time Tue Apr 05 20:13:20 CEST 2005
./collector: submitting command “temperature”
./collector: got replay “Current temperature is 26.5C at time 2007/08/05 20:13:25”
./collector: submitting temperature data on DB
./collector: submitting command “weigh”
./collector: got replay “Current weigh is 23.5Kg at time 2007/08/05 20:13:25”
./collector: submitting weigh data on DB

Come si vede allora il programma collector inizia subito ad interrogare l’embedded satellite specificato e quindi salva i dati rilevati nel database. Il tutto si ripete ogni 5 secondi.

Visualizzare i dati

Bene, siamo quasi in fondo, ora passiamo alla visualizzazione dei dati rilevati. Per fare ciò basta puntare il vostro browser preferito all’URL https://localhost/demolinux/repgen.php dal vostro querying system.

Oramai avrete capito che anche in questo caso il querying system non è una macchina remota ma è sempre la stessa macchina su cui gira tutto il resto del nostro sistema di monitoraggio.

Se tutto va come deve otterrete quanto riportato in figura 4.

 

 

Il report che genereremo è molto semplice e si basa essenzialmente sul visualizzare le grandezze rilevate in un certo intervallo di tempo. Ad esempio se impostiamo l’intervallo “2005-04-05 20:00:00″,”2005-04-05 21:00:00” si ottiene quanto riportato in figura 5.

 

 

I valori sono molto ballerini a causa del fatto che sono stati generati con dei numeri casuali, è ovvio che se i sensori fossero stati reali questo non sarebbe accaduto.

Bene, a questo punto non vi resta che creare un data base vostro e quindi divertirvi a provare la visualizzazione di diversi intervalli temporali.

Da parte mia spero solo di aver stuzzicato la vostra immaginazione! 😉