Έστω ότι έχουμε έναν αισθητήρα, το οποίον αποκαλούμε sensor node. Αυτός ο αισθητήρας είναι μέρος, ενός ευρύτερου δικτύου αισθητήρων. Έστω τώρα ότι θέλουμε να ανακτήσουμε τα δεδομένα αυτού του αισθητήρα. Έχουν αναπτυχθεί συστήματα τα οποία "βλέπουν" κάθε sensor node σαν μια μικρή πηγή δεδομένων, και το προαναφερόμενο δίκτυο, σαν μια μεγάλη κατανεμημένη βάση δεδομένων. Όταν έχουμε όμως μια κατανεμημένη βάση δεδομένων, μας νοιάζει τι υπάρχει από κάτω; Όχι...κάνουμε SQL queries και απλά ανακτούμε τα αποτελέσματα χωρίς ιδιαίτερη αγωνία για το τι υπάρχει από κάτω. Κάπως έτσι γίνεται και με ένα δίκτυο αισθητήρων.
Ας εξηγήσω πως δουλεύει αυτός ο μηχανισμός. Έστω ότι έχω έναν υπολογιστή και ένα δίκτυο αισθητήρων και θέλω να κάνω ένα query, πώς γίνεται η επικοινωνία με τους αισθητήρες; Ανάμεσα στο δίκτυο και στον υπολογιστή, υπάρχει ένα ειδικός κόμβος-gateway που λειτουργεί ως μεσάζοντας σε αυτήν την επικοινωνία. Στέλνω εγώ μια αίτηση και εκείνος είναι υπεύθυνος να την δρομολογήσει hop-by-hop στο δίκτυο αισθητήρων. Αυτή είναι η φάση της ανάλυσης επερώτησης. Στην συνέχεια έχουμε την ανάκτηση αποτελέσματος η οποία είναι παρόμοια με την πρώτη διαδικασία αλλά σε αντίστροφη πορεία. Τόσο απλό!!!! (εχμ μάλλον δεν είναι τόσο απλό, γιατί κάπου εδώ μπαίνει η επιστήμη. Αυτή η διαδικασία πρέπει να μελετηθεί με μαθηματική ακρίβεια διότι πρέπει να πετύχουμε τη μικρότερη δυνατή κατανάλωση ενέργειας, αλλά λεπτομερής ανάλυση δεν είναι ο σκοπός μου).
Πάμε να πούμε μερικά παραδείγματα επερωτήσεων τώρα. Σε αυτούς λοιπόν τους αισθητήρες, θέλω να κάνω δύο τύπους επερωτήσεων. Κάποιες επερωτήσεις τις κάνω μια φορά (on demand) και κάποιες θέλω να τις κάνω ανα τακτα χρονικά διαστήματα. Η πρώτη κατηγορία είναι απλή και μπορούμε να σκεφτούμε πολλά παραδείγματα. Στην δεύτερη κατηγορία, για παράδειγμα, εμπίπτουν περιβαλλοντολογικές εφαρμογές. Θα θεωρήσουμε ότι έχουμε αισθητήρες θερμοκρασίας, οι οποίοι είναι τοποθετημένοι σε μια δασική έκταση. Για να ελέγχω εγώ αν υπάρχει ένδειξη αύξησης θερμοκρασίας (φωτιά), πρέπει να ελέγχω συνεχώς για μετρήσεις. Πχ σε SQL - like γλώσσα θα είχα κάτι τέτοιο
SELECT sensorId, temperature FROM sensors EVERY 30 sec
Βέβαια από εκεί και πέρα μπορούμε να παίζουμε με τα queries ώστε να παίρνουμε είτε raw data είτε αποτελέσματα με τις MIN, MAX, SUM, COUNT και AVG. Επίσης μπορούμε να παίξουμε με τα events. Αν ανιχνεύαμε φωτιά και θέλαμε να επεξεργαστούμε τα δεδομένα περαιτέρω μπορούσαμε πχ να τρέξουμε κάτι τέτοιο:
ON EVENT ret.temperature > 60 SELECT nodeId, nodeLocation, temperature FROM sensors
Έστω λοιπόν ότι γράψαμε το query μας. Ανάλογα με το τι περιγράφει η επερώτησή μας η προαναφερόμενη gateway αναλαμβάνει να το μεταδώσει καταλλήλως. Αν για παράδειγμα είχαμε και ένα WHERE στο query μας τότε αυτό θα δρομολογηθεί στον συγκεκριμένο κόμβο αντί να είχαμε broadcast (Εδω παίζουν αλγόριθμοι αναζήτησης σε γράφους που είμαι σίγουρος ότι μάθατε σε κάποιο μάθημα πολυπλοκότητας και θεωρούσατε ότι "τι μας τα λένε αυτά τώρα, αφού δεν πρόκειτε να τα χρειαστούμε...".... σιγά σιγά με έκπληξη θα καταλάβετε ότι όλα χρειάζονται :))
Τι γίνεται όμως όταν έχουμε έναν aggregation operator οπως τον SUM...Τότε τα πράγματα δυσκολεύουν. Και αν θέλαμε μέση τιμή από κάποια περιοχή; Τότε τα πράγματα δυσκολεύουν ακόμα πιο πολύ. Οι κόμβοι μεταξύ τους έχουν πληροφορίες για το ποιος είναι ο πατέρας κόμβος, ποια είναι τα παιδιά, ποια είναι τα αδέρφια κτλ. Η πληροφορία πρέπει να ταξιδέψει ανάμεσα από αυτούς τους κόμβους με τα μικρότερα μονοπάτια ανάμεσα στις παραπάνω σχέσεις. Για παράδειγμα. Στην περίπτωση του SUM δείτε το παρακάτω σχηματάκι
A B C
D E F
G H I
Έστω ότι θέλω το άθροισμα των τιμών των A,B,C αισθητήρων και η gateway είναι το G. Δείτε το λίγο.
Αν η αθροιστική πληροφορία πάει από C στο B, μετά C+B στο B και μετά A+B+C στο A και από εκεί στο D και μετά στο G έχουμε μία καλή λύση. Δεν είναι λίγοτερα μηνύματα από το να μεταφέρονταν παράλληλα οι μετρήσεις C->I, B->H , A->G και να άθροιζαν στο επίπεδο G, H, I??
Κάπως έτσι γίνεται η επερώτηση σε ένα δίκτυο αισθητήρων. Βέβαια αν πάω τώρα και πάρω ένα βιβλίο για WSN's (Wireless Sensor Networks) είμαι σίγουρος ότι έκανα την γενίκευση της τάξης των 1500 σελίδων ++... :D Αλλά γενικά, η βασική ιδέα αυτή είναι.
Τώρα για τον προγραμματιστή πραγματική σημασία έχει μόνο το πρώτο στάδιο. Αυτό που κάνει απλές επερωτήσεις στην γλώσσα του δικτύου (για απλά δίκτυα η SQL είναι η πιο κοινά χρησιμοποιούμενη γλώσσα). Οπότε αν έχετε μια εφαρμογή και θέλετε να δοκιμάσετε κάποια δεδομένα από αισθητήρες, πείτε το super duper "Έστω οτι..." και θεωρήστε ότι έχετε μια βάση με πραγματικά δεδομένα.
Enjoy science!
Διαβάζοντας το Learning from Data Streams: Processing Techniques in Sensor Networks (* springerlink), είδα κατενθουσιασμένος πως στο τελευταίο κεφάλαιο είχε αναφορά στο NXT robot της Lego (Το γνωστό ρομποτάκι που χειριζόμασταν με ενα χειριστήριο XBOX στην dte 2007, στο περίπτερο του stugu). Ο γνωστός τρόπος χειρισμού είναι μέσω του Microsoft Robotics Studio. Από ότι είδα όμως, από την παραπάνω συλλογή από papers, το να ασχολείται κάποιος με τέτοια robotakia είναι η καλύτερη εισαγωγή στο κόσμο των Wireless Sensor Networks.
Στο κεφάλαιο αυτό, λοιπόν, είχε μια περιγραφή στο robot, στον μικροελεγκτή που χρησιμοποιεί, στους διάφορους αισθητήρες που μπορούν να εφαρμοστούν πάνω του και πολλά άλλα. Το Tiny OS που αναφέρει όμως τι είναι; To tinyOS είναι αυτό που μου προκάλεσε το κύριο ενδιαφέρον , καθώς είναι κάτι που το έχω ακούσει μόνο σε περιβάλλοντα κανονικών ασύρματων δικτύων με αισθητήρες και είναι ένα ενσωματωμένο λειτουργικό σύστημα γραμμένο στην nesC. Το tinyOS είναι ανοικτού κώδικα και έτσι σκέφτηκαν ότι, τι καλύτερο να το ενσωματώσουν και σε NXT για εκπαιδευτικούς σκοπούς!!! Έτσι από αυτό το πάντρεμα, της τεχνολογίας του NXT με το TinyOS βγήκε το ΝΧΤΜΟΤΕ.
Και φυσικά το θέμα είναι εντελώς software, το τι θα κάνετε με όλες τις μετρήσεις που θα πέρνεται,αλλά αυτό είναι άλλο κεφάλαιο.
Enjoy Science 
* Τα παραπάνω links, που δείχνουν στην Springerlink είναι προσβάσιμες μόνο μέσω του δικτύου Healink (συνδρομή που έχουν σχεδόν όλα τα Ελληνικά Πανεπιστήμια. Δεν μπορώ να δώσω τα κείμενα αυτά καθεαυτά για λόγους δικαιωμάτων).
