Διπλωματική Εργασία του φοιτητή του Τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών της Πολυτεχνικής Σχολής του Πανεπιστημίου Πατρών

Transcript

1 ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΑΤΡΩΝ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΤΕΧΝΟΛΟΓΙΑΣ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ: ΗΛΕΚΤΡΟΝΙΚΗΣ & ΥΠΟΛΟΓΙΣΤΩΝ ΕΡΓΑΣΤΗΡΙΟ ΣΥΣΤΗΜΑΤΩΝ ΥΠΟΛΟΓΙΣΤΩΝ Διπλωματική Εργασία του φοιτητή του Τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών της Πολυτεχνικής Σχολής του Πανεπιστημίου Πατρών Ευαγγέλου Τσιάτσιου του Παναγιώτη Αριθμός Μητρώου: Θέμα «Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων (ΙοΤ): Σύνθεση υπηρεσιών με την χρήση Node-RED» Επιβλέπων Θραμπουλίδης Κλεάνθης Αριθμός Διπλωματικής Εργασίας: Πάτρα, Μάρτιος 2018

2 ΠΙΣΤΟΠΟΙΗΣΗ Πιστοποιείται ότι η Διπλωματική Εργασία με θέμα «Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων (ΙοΤ): Σύνθεση υπηρεσιών με την χρήση Node-RED» Του φοιτητή του Τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών Ευαγγέλου Τσιάτσιου του Παναγιώτη Αριθμός Μητρώου: Παρουσιάστηκε δημόσια και εξετάστηκε στο Τμήμα Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών στις 06/03/2018 Ο Επιβλέπων Κλεάνθης Θραμπουλίδης Καθηγητής Ο Διευθυντής του Τομέα Ευθύμιος Χούσος Καθηγητής

3 Αριθμός Διπλωματικής Εργασίας: Θέμα: «Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων (ΙοΤ): Σύνθεση υπηρεσιών με την χρήση Node-RED» Φοιτητής: Τσιάτσιος Ευάγγελος Επιβλέπων: Θραμπουλίδης Κλεάνθης Περίληψη Η εργασία αυτή αποτελεί μια μελέτη πάνω στην ανάπτυξη Ιnternet of Things (ΙοΤ) υπηρεσιών (Mashup) και στην χρήση τους στον τομέα των βιομηχανικών αυτοματισμών. Ειδικότερα γίνεται μελέτη του εργαλείου Node-RED και της πλατφόρμας στην οποία στηρίζεται, την Node.js. Σε πρώτο στάδιο, γίνεται μια σύντομη αναφορά σε βασικούς όρους και τεχνολογίες που χρησιμοποιούνται στον τομέα του IoT, όπως τα πρωτόκολλα επικοινωνίας και τα διαθέσιμα εργαλεία για την σύνθεση υπηρεσιών. Έπειτα αναλύεται η δομή και λειτουργία της πλατφόρμας Node.js, καθώς και το εργαλείο Node-RED. Για την μελέτη της σύνθεσης των υπηρεσιών (development) χρησιμοποιείται το case study Liqueur Plant, το οποίο και υλοποιείται σε αυτήν την εργασία. Αρχικά χρησιμοποιώντας το Node-RED και την Node.js σχεδιάζεται και υλοποιείται η διεργασία της παραγωγής Liqueur η οποία συμπεριφέρεται ως Light Weight Machine to Machine Server (LWM2M). Σε συνέχεια δημιουργούνται τα ανάλογα LWM2M nodes διαχείρισης των σιλό που απαρτίζουν το Liqueur Plant. Τέλος, κατασκευάζονται οι δύο διαφορετικές υπηρεσίες παραγωγής Liqueur του case study, οι Type A και Type B process, για τις οποίες δίνονται πολλαπλές εκδόσεις, σχεδιασμένες με διαφορετικές αρχιτεκτονικές προς αναζήτηση της βέλτιστης.

4 Abstract This thesis is a study of the development of Internet of Things (IoT) services (Mashups) and their use in the industrial automation domain. Specifically, there is a focus on the tool Node-RED and the platform that it is based on Node.js. In the first place, basic terminology and technologies are established, such as the communication protocols of the IoT domain and the available tools for developing mashups. Subsequently, there is a detailed analysis of the structure and functionality of Node.js and the tool Node-RED. To study the development of IoT Mashups, the Liquor Plant case study is established. Initially, with the use of the tool Node-RED and Node.js the Liqueur generation process is designed and developed, which acts as a Light Weight Machine to Machine Server (LWM2M). Further, the development of the LWM2M nodes that control the different silos of the Liqueur Plant was performed. Finally, the two Liqueur generation services, Type A and Type B, are developed with multiple versions in search of the best one.

5 ΠΡΟΛΟΓΟΣ Στην παρούσα διπλωματική εργασία γίνεται έρευνα και παρουσίαση της ενσωμάτωσης του Διαδικτύου Αντικειμένων στον τομέα της βιομηχανικής αυτοματοποίησης. Αυτό επιτυγχάνεται μέσω της μελέτης περίπτωσης του Liqueur Plant, του οποίου οι υπηρεσίες κατασκευάζονταισυνθέτονται με σκοπό την μελέτη, κατανόηση και βελτίωση της συνθετικής αυτής διαδικασίας. Η εκπόνηση της διπλωματικής εργασίας πραγματοποιήθηκε στο εργαστήριο «Συστημάτων Υπολογιστών», υπό την καθοδήγηση του κ. Κλεάνθη Θραμπουλίδη τον οποίο θα ήθελα να ευχαριστήσω θερμά για την υπομονή και καθοδήγηση που προσέφερε κατά την διάρκεια εκπόνησης αυτής της διπλωματικής εργασίας. Αναμφίβολα, χωρίς την καθοριστική συνδρομή του στην επεξήγηση της δομής μίας υπηρεσίας, των πρωτοκόλλων επικοινωνίας, αλλά και υποστήριξη σε κάθε δυσκολία που εμφανίστηκε, θα ήταν αδύνατη η κατασκευή του Mashup. Επίσης η τεράστια επιρροή του στην θεματολογία του τομέα του Internet of Things, με έφερε σε μεγάλη επαφή με έναν τομέα με τον οποίο ήμουν άπειρος, δημιουργώντας μου εναύσματα για μελλοντική ενασχόληση. Ακόμα η δεκτικότητα του στην χρήση νέων τεχνολογιών, με οδήγησε στην χρήση και κατανόηση διαφορετικών αρχιτεκτονικών κώδικα, στοιχείο που διεύρυνε τους ορίζοντές μου. Τέλος θα ήθελα να ευχαριστήσω τους συμφοιτητές μου Πάνο Μπόχαλη και Γιάννη Μπουλούμπαση για την ανάπτυξη και παροχή των προσομοιωμένων αλλά και πραγματικών συσκευών που χρησιμοποιήθηκαν σε αυτή τη διπλωματική εργασία καθώς και για την συνεχή υποστήριξη που προσέφεραν.

6 ΠΕΡΙΕΧΟΜΕΝΑ 1 ΕΙΣΑΓΩΓΗ Δομή της διπλωματικής εργασίας ΔΙΑΔΙΚΤΥΟ ΑΝΤΙΚΕΙΜΕΝΩΝ ΚΑΙ RESTFUL ΥΠΗΡΕΣΙΕΣ ΙΣΤΟΥ Συσκευές Διαδικτύου Aντικειμένων Machine to Machine Communication Hypertext Transfer Protocol (HTTP) Message Queue Telemetry Transport (MQTT) Constrained Application Protocol (COAP) OMA Light Weight Machine to Machine (LWM2M) Αρχιτεκτονική REST ΣΥΝΘΕΣΗ ΥΠΗΡΕΣΙΩΝ Υπηρεσίες Ιστού Υπηρεσίες Διαδικτύου Αντικειμένων ΤΕΧΝΟΛΟΓΙΕΣ ΑΙΧΜΗΣ Υπηρεσίες Σύννεφου Microsoft Azure Amazon Web Services ThingSpeak DeviceHub.Net Πλατφόρμες Δεδομένων (Data Platforms) Xively Global Sensor Networks Γραφικά Εργαλεία Προγραμματισμού Wotkit Node-RED Losant NODE.JS & NODE-RED Node.js Η μηχανή απόδοσης Javascript: V Προγ/σμός χειρισμού γεγονότων και το ασύγχρονο μοντέλο λειτουργίας... 25

7 5.1.3 Το Event Loop της Node.js Node-RED Δημιουργία εφαρμογών με Node-RED Nodes Flows ΣΥΝΘΕΣΗ ΥΠΗΡΕΣΙΩΝ ΔΙΑΔΙΚΑΣΙΑΣ ΠΑΡΑΓΩΓΗΣ ΜΕ ΤΗΝ ΧΡΗΣΗ NODE-RED Μελέτη Περίπτωσης: Liqueur Plant Λειτουργικές Προδιαγραφές του Συστήματος Εργαλεία Ανάπτυξης ΑΝΑΠΤΥΞΗ ΤΟΥ LWM2M ΔΙΑΚΟΜΙΣΤΗ ΓΙΑ NODE-RED Λειτουργικές Προδιαγραφές O διακομιστής coap-shepherd Ο διακομιστής lwm2m-node-lib ΕΠΕΚΤΑΣΗ ΤΟΥ NODE-RED ΜΕ ΤΑ LWM2M NODES Προδιαγραφές Λειτουργίας Η ενσωμάτωση του LWM2M-Server Η βιβλιοθήκη node-coap Η υλοποίηση των LWM2M-Node H συλλογή node: Dispatcher ΣΧΕΔΙΑΣΜΟΣ ΕΦΑΡΜΟΓΩΝ MASHUP Ανάπτυξη της υπηρεσίας Tύπου Α (1 η έκδοση) Ανάπτυξη της υπηρεσίας Tύπου Β (1 η έκδοση) Ανάπτυξη των υπηρεσιών Tύπου Α & Β (2 η έκδοση) Αποτελέσματα ΣΥΜΠΕΡΑΣΜΑΤΑ & ΠΡΟΤΑΣΕΙΣ ΓΙΑ ΜΕΛΛΟΝΤΙΚΗ ΕΡΕΥΝΑ Συμπεράσματα Προτάσεις για μελλοντική έρευνα ΑΝΑΦΟΡΕΣ... 68

8

9 1 ΕΙΣΑΓΩΓΗ Η διπλωματική εργασία μελετά τη χρήση ΙοΤ συσκευών στον τομέα της βιομηχανίας και αυτοματοποίησης (Industrial Automation) καθώς και την σύνθεση των υπηρεσιών που εκμεταλλεύονται αυτές τις συσκευές, με απώτερο σκοπό την απλούστευση της βιομηχανικής αυτοματοποίησης. Ειδικότερα αναλύεται ο τρόπος σύνθεση υπηρεσιών και Mashups με σκοπό την αυτοματοποίηση βιομηχανικών διαδικασιών, μέσω του Liqueur Plant case study[81]. Το Liqueur Plant είναι μία μελέτη περίπτωσης η οποία αφορά ένα εργοστάσιο παραγωγής λικέρ. Το εργοστάσιο αυτό διαθέτει τέσσερα σιλό τα οποία δέχονται, εξάγουν, θερμαίνουν και αναμειγνύουν λικέρ, καθώς και ένα κοινό σωλήνα για την μεταφορά του λικέρ μεταξύ των σιλό αλλά και έναν μετρητή κατανάλωσης ρεύματος κατά την ανάμειξη. Το λικέρ παράγεται από δύο διαδικασίες παραγωγής (Α και Β) οι οποίες λειτουργούν παράλληλα και καλούνται να μοιραστούν τον κοινό σωλήνα καθώς και την κατανάλωση ρεύματος κατά την ανάμειξη. Μέσω της τεχνολογίας των μικροϋπολογιστών και ευρύτερα των συσκευών Διαδικτύου των Αντικειμένων γίνεται έκκληση για την αυτοματοποίηση της παραπάνω διαδικασίας, με την ανάπτυξη εφαρμογής εκτέλεσης και ελέγχου των δύο διαδικασιών καθώς και των συσκευών που ελέγχουν τα τέσσερα σιλό. Η συγκεκριμένη μελέτη παρουσιάζει ιδιαίτερο ενδιαφέρον καθώς μεταφέρει το πρόβλημα κατανομής των κοινών πόρων (σωλήνας, μετρητής κατανάλωσης ρεύματος) στο επίπεδο δικτυακής επικοινωνίας μεταξύ ΙοΤ συσκευών. Η συνεχής επαφή με τον τομέα του Διαδικτύου Αντικειμένων (ΙοΤ) στο εργαστήριο των «Συστημάτων Υπολογιστών» αποτέλεσε το έναυσμα για την εις βάθος μελέτη των διαφορετικών πτυχών στον εν λόγο τομέα. Ο μεγάλος βαθμός ελευθερίας στον έλεγχο και προγραμματισμό των συσκευών προσφέρει άπειρες δυνατότητες εκμετάλλευσης, στοιχείο που αποτέλεσε και το βασικό κίνητρο αυτής της διπλωματικής εργασίας. Με αφορμή τα παραπάνω έγινε μελέτη του τρόπου λειτουργίας των συσκευών ΙοΤ, των πρωτοκόλλων επικοινωνίας τους όπως τα Coap και MQTT, και τελικώς της αρχιτεκτονικής REST με απώτερο στόχο την πλήρη κατανόηση των δυνατοτήτων αλλά και των τρόπων αξιοποίησης μίας συσκευής ΙοΤ. Προς την κατανόηση της σύνθεσης, δημιουργίας και δόμησης υπηρεσιών μελετήθηκαν τόσο οι υπηρεσίες ιστού όσο και οι υπηρεσίες του Διαδικτύων Αντικειμένων. Η σύγκριση των διαφορετικών ειδών υπηρεσιών κατέστησε την μετάβαση από τις πιο παραδοσιακές υπηρεσίες ιστού σε αυτές του τομέα ΙοΤ, ομαλή και απροβλημάτιστη. Με αφορμή την αναζήτηση του βέλτιστου τρόπου σύνθεσης υπηρεσιών έγινε εκτεταμένη έρευνα πάνω στις διαθέσιμες τεχνολογίες σύνθεσης υπηρεσιών οι οποίες εκμεταλλεύονται Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

10 2 συσκευές Διαδικτύου Αντικειμένων. Βασικές υπηρεσίες που εξετάστηκαν είναι οι υπηρεσίες σύννεφου των εταιριών Microsoft (Azure) και Amazon (AWS) καθώς και το γραφικό εργαλείο ανάπτυξης εφαρμογών και υπηρεσιών της IBM, Node-RED. Οι υπηρεσίες αυτές παρέχουν μία σουίτα από εργαλεία ή μικρότερες διαδικτυακές υπό-υπηρεσίες οι οποίες προσφέρουν την δυνατότητα στον χρήστη να συνδέσει, ελέγξει και επικοινωνήσει με τις ΙοΤ συσκευές του. Κατά επέκταση προσφέρεται η δυνατότητα σύνθεσης υπηρεσιών οι οποίες εκμεταλλεύονται τις λειτουργικές δυνατότητες των συνδεδεμένων συσκευών. Ιδιαίτερη σημασία δόθηκε στην ευκαιρία εκμετάλλευσης των εργαλείων και τεχνολογιών από φοιτητικούς συλλόγους και όχι από εταιρίες της βιομηχανίας, στοιχείο που επηρέασε σημαντικά την επιλογή των εργαλείων για την εκπόνηση της διπλωματικής εργασίας. Εξαιτίας των παραπάνω περιορισμών το εργαλείο Node-RED και κατά επέκταση η πλατφόρμα στην οποία βασίζεται, Node.js, επιλέχθηκαν για λεπτομερέστερη ανάλυση. Το εργαλείο Node- RED είναι ένα γραφικό εργαλείο δημιουργίας εφαρμογών και υπηρεσιών το οποίο προσφέρει δυνατότητες επέκτασης των λειτουργιών του καθώς και μεγάλη ευελιξία στην επιλογή συσκευών εκτέλεσης των εφαρμογών του. Η Node.js είναι μια πλατφόρμα που προσφέρει εύκολη και γρήγορη δημιουργία κλιμακούμενων εφαρμογών. Με την μελέτη της πλατφόρμας αυτής έγινε κατανοητός ο τρόπος λειτουργίας του ασύγχρονο μοντέλου της αλλά και του μοντέλου χειρισμού γεγονότων της όπως επίσης και του βασικού πυρήνα της, το Event Loop. Επίσης κατανοήθηκε ο τρόπος ανάπτυξης επεκτάσεων για το εργαλείο Node-RED αλλά και οι δυνατότητες που προσφέρει για την σύνθεση υπηρεσιών. Καθώς το αντικείμενο μελέτης της εργασίας είναι και η ενσωμάτωση των ΙοΤ συσκευών στο περιβάλλον της βιομηχανίας και αυτοματοποίησης, για την μελέτη περίπτωσης του Liqueur Plant σχεδιάστηκε και αναπτύχθηκε υλικό αλλά και λογισμικό. Ειδικότερα με στόχο την σύνθεση υπηρεσιών που να παράγουν Liqueur αναπτύχθηκε διακομιστής διαχείρισης των ΙοΤ συσκευών συμβατός με Node-RED, καθώς και τα απαραίτητα nodes ελέγχου λειτουργίας τους. Παράλληλα οι συσκευές που χρησιμοποιήθηκαν τόσο σε επίπεδο πραγματικού υλικού όσο και σε επίπεδο προσομοίωσης αποτελούν προϊόν τρίτης διπλωματικής εργασίας του εργαστηρίου «Συστημάτων Υπολογιστών». Τελικώς, έγινε ανάπτυξη και σύνθεση των υπηρεσιών που απαρτίζουν την μελέτη περίπτωσης υπό το πρίσμα διαφορετικών αρχιτεκτονικών και αξιολογήθηκαν με βάση την δομή τους. Η εργασία αυτή παρείχε την δυνατότητα κατανόησης εις βάθους της μεθόδου κατασκευής υπηρεσιών χρησιμοποιώντας πτυχές του προγραμματισμού χειρισμού γεγονότων. Με την ανάπτυξη των υπηρεσιών της μελέτης περίπτωσης έγιναν σαφής οι πραγματικές δυνατότητες των συσκευών Διαδικτύου Αντικειμένων καθώς και οι επιμέρους αδυναμίες των πρωτοκόλλων που διέπουν την επικοινωνία μεταξύ τους. Τέλος, έγινε προφανής η δυνατότητα εύκολης χρήσης του γραφικού εργαλείου Node-RED για την δημιουργία υπηρεσιών ή εφαρμογών ακόμα και από μη εξειδικευμένους, με τον προγραμματισμό, χρήστες. 1.1 Δομή της διπλωματικής εργασίας Στο κεφάλαιο 1 γίνεται μια σύντομη εισαγωγή στον χώρο του Διαδικτύου των Αντικειμένων καθώς και στο περιεχόμενο της διπλωματικής εργασίας. Στο κεφάλαιο 2 δίνονται βασικοί όροι σχετικά με τον χώρο του Internet of Things. Παράλληλα παραθέτοντας τα πρωτόκολλα επικοινωνίας μεταξύ των ΙοΤ συσκευών. Τέλος γίνεται επεξήγηση της REST αρχιτεκτονικής στο επίπεδο υπηρεσιών. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

11 ΕΙΣΑΓΩΓΉ 3 Στο κεφάλαιο 3 γίνεται αναφορά στην σύνθεση υπηρεσιών και ειδικότερα στα Web Mashups και στα Internet of Things Mashups. Κάθε είδος χρησιμοποιεί διαφορετικές τεχνολογίες και εργαλεία για την δημιουργία του Mashup, με σκοπό πάντα μία νέα υπηρεσία με μεγαλύτερη χρηστικότητα από τις μικρότερες υπηρεσίες που την απαρτίζουν. Στο κεφάλαιο 4, γίνεται μια αναλυτική μελέτη των διαθέσιμων τεχνολογιών για την συγγραφή και δημιουργία ΙοΤ Mashups. Αφού κατηγοριοποιηθούν τα εργαλεία σε: cloud platforms, γραφικά εργαλεία και data platforms, αναλύονται τα επιμέρους εργαλεία κάθε κατηγορίας. Στο κεφάλαιο 5, γίνεται λεπτομερής ανάλυση του εργαλείου Node-RED καθώς και τις πλατφόρμας στην οποία στηρίζεται, την Node.js. Γίνεται ανάλυση του threading μοντέλου της Node.js καθώς και των βασικών τρόπων συγγραφής κώδικα με αυτή, δηλαδή του τρόπου λειτουργίας του event driven κώδικα της. Ύστερα ακολουθεί επεξήγηση των επιμέρους στοιχείων που απαρτίζουν το Node-RED, όπως των nodes και flows, αλλά και του τρόπου κατασκευής τους. Στο κεφάλαιο 6, γίνεται αναφορά στο case study της διπλωματικής εργασίας. Δηλαδή περιγράφεται το Liqueur Plant Case Study, των επιμέρους συσκευών που το απαρτίζουν, τις λειτουργίες τους, καθώς και τον τρόπο που πρέπει να συνδυαστούν για την συγγραφή του Mashup. Στο κεφάλαιο 7, γίνεται αναφορά στην αναζήτηση και δημιουργία ενός Light Weight Machine to Machine Server τον οποίο μπορούμε να χρησιμοποιήσουμε σε Node.js & Node- RED για την επικοινωνία με τις Leshan-compliant συσκευές. Στο κεφάλαιο 8, γίνεται περιγραφή της διαδικασίας ανάπτυξης των node LWM2M που χρησιμοποιούνται στα flows των Mashup. Γίνεται λεπτομερή επεξήγηση των βημάτων ανάπτυξης για όλες τις εκδόσεις, καθώς και της λογικής ορισμένων χαρακτηριστικών που επηρεάζουν την ομαλή λειτουργία των flows. Στο κεφάλαιο 9, περιγράφουμε την τελική κατασκευή των Mashup για όλες τις διαδικασίες του case study, δηλαδή των Type A και Type B process. Γίνεται αναφορά στα σχεδιαστικά προβλήματα που αντιμετωπίστηκαν καθώς και στην υλοποίηση διαφορετικών σχεδιαστικά εκδόσεων για τις ίδιες υπηρεσίες. Στο κεφάλαιο 10 γίνεται αναφορά στα συμπεράσματα που εξήχθησαν κατά τη διάρκεια της διπλωματικής εργασίας καθώς και ιδέες για μελλοντική έρευνα βασισμένες πάνω στην συγκεκριμένη εργασία. Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

12 4 2 ΔΙΑΔΙΚΤΥΟ ΑΝΤΙΚΕΙΜΕΝΩΝ ΚΑΙ RESTFUL ΥΠΗΡΕΣΙΕΣ ΙΣΤΟΥ Σε αυτό το κεφάλαιο γίνεται λεπτομερής ανάλυση στις βασικές έννοιες που διέπουν τον χώρο του Internet of Things (IoT) και των RESTful υπηρεσιών. Ειδικότερα γίνεται περιγραφή του τρόπου λειτουργίας των πρωτοκόλλων για Machine to Machine Communication, καθώς και αναφορά στις βασικές αρχές που χαρακτηρίζουν μια διαδικτυακή υπηρεσία ως RESTful. 2.1 Συσκευές Διαδικτύου Aντικειμένων Το Internet of Things (IoT) είναι η δικτύωση φυσικών συσκευών οι οποίες περιέχουν ενσωματωμένα ηλεκτρονικά, λογισμικό, αισθητήρες, διακόπτες και δυνατότητα επικοινωνίας με το διαδίκτυο. Σύνηθες όροι αναφοράς στις συσκευές είναι connected devices ή smart devices [1]. Σκοπός των συσκευών είναι η προσφορά καλύτερης λειτουργικότητας και αυτοματοποίησης στους χρήστες, για την βελτίωση του βιοτικού επιπέδου. Μια ΙοΤ συσκευή συνήθως αποτελείται από έναν μικροεπεξεργαστή (πχ. Raspberry), και ένα πλήθος αισθητήρων και διακοπτών. Αυτά τα εξαρτήματα, σε συνδυασμό με το λογισμικό είναι που δημιουργούν την «έξυπνη συσκευή». Συνδυάζοντας την παραπάνω δυνατότητα με δικτυακή σύνδεση, η εκμετάλλευση και προσαρμογή των συσκευών στις απαιτήσεις του χρήστη καθίσταται αρκετά πιο αποτελεσματική. Ειδικότερα, οι συσκευές έχουν την ικανότητα να συλλέγουν δεδομένα χρήσης, και να προσαρμόζονται στις απαιτήσεις του χρήστη βασιζόμενες πάνω στα δεδομένα αυτά. Η σύνδεση με τοπικό δίκτυο ή το διαδίκτυο, επιτρέπει στον χρήστη τον απομακρυσμένο έλεγχο της συσκευής, δημιουργώντας πολλούς τρόπους αξιοποίησης των δυνατοτήτων τις τεχνολογίας ΙοΤ. Αρκεί κανείς να φανταστεί το πιο απλό παράδειγμα ενός Smart ψυγείου. Το ψυγείο έχει την δυνατότητα να ελέγχει τα barcodes των προϊόντων για αναζήτηση της ημερομηνίας λήξης τους online, και τελικώς την ενημέρωση του χρήστη τοπικώς (μέσω μίας οθόνης) ή απομακρυσμένα (αποστολή μηνύματος στο κινητό του χρήστη) για τα ποια προϊόντα πρέπει να αντικαταστήσουν. Σήμερα το Internet of Things είναι ιδιαίτερα δημοφιλές στην βιομηχανία (αυτόματη παραγωγή), στον τομέα της ιατρικής (βηματοδότες), στο home automation (έξυπνα φώτα, συσκευές κουζίνας) καθώς και στα ενδυματολογικά είδη (smart watch). 2.2 Machine to Machine Communication Ο όρος Machine to Machine (M2M) Communication αναφέρεται στην απευθείας επικοινωνία μεταξύ συσκευών μέσω οποιουδήποτε καναλιού επικοινωνίας (πχ. Ενσύρματο ή ασύρματο) [2]. Η επικοινωνία Μ2Μ έχει ιδιαίτερη απήχηση στον τομέα του Internet of Things, όπου πλήθος συσκευών καλείται να επικοινωνήσει μεταξύ τους για την ανταλλαγή, ζωτικών για την λειτουργία τους, δεδομένων. Για την υποστήριξη του Μ2Μ έχουν δημιουργηθεί οργανώσεις Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

13 ΔΙΑΔΊΚΤΥΟ ΑΝΤΙΚΕΙΜΈΝΩΝ ΚΑΙ RESTFUL ΥΠΗΡΕΣΊΕΣ ΙΣΤΟΎ 5 που το υποστηρίζουν με τις δικές τους υλοποιήσεις. Πιο γνώστες οργανώσεις είναι το Eclipse machine to machine working group [3], η OASIS MQTT[4], η XMPP[5] και η Open Mobile Alliance[6]. Για την υλοποίηση του Machine to Machine Communication μπορούν να χρησιμοποιηθεί μια πληθώρα από πρωτόκολλα επικοινωνίας. Σε αυτό το κεφάλαιο θα γίνει μια παρουσίαση των πιο συνηθισμένα χρησιμοποιημένων πρωτοκόλλων, το HTTP, το MQTT, το COAP και το LWM2M Hypertext Transfer Protocol (HTTP) To Hypertext Transfer Protocol ή αλλιώς HTTP, είναι ένα application protocol, το οποίο αποτελεί την βάση του διαδικτύου σήμερα. Σκοπός του είναι η εύκολη μεταφορά hypertext[7]. To Hypertext είναι δομημένο κείμενο το οποίο χρησιμοποιεί λογικές συνδέσεις (hyperlinks) μεταξύ κόμβων (nodes) οι οποίοι περιέχουν κείμενο. Το HTTP χρησιμοποιεί το request-response μοντέλο, δηλαδή ένας client (συνήθως ο χρήστης) αποστέλλει μια αίτηση (request) σε ένα server για την λήψη κείμενου, οπτικού υλικού ή εκτέλεση λειτουργίας, και έπειτα ο server «απαντά» με το κατάλληλο περιεχόμενο (response). Η αντιστοίχιση του απαιτούμενου υλικού από τον χρήστη γίνεται μέσω των Uniform Resource Locator (URL), τα οποία χρησιμοποιούν το μοντέλο Uniform Resource Identifier (URI). To HTTP σήμερα βασίζεται πάνω στο reliant protocol TCP, αλλά υπάρχουν και υλοποιήσεις πάνω στο non-reliant protocol UDP [7]. Σήμερα, η νεότερη έκδοση του HTTP (HTTP/2) υποστηρίζει ένα πλήθος εντολών που δείχνουν στον server την κατάλληλη δράση που πρέπει να λάβει, όπως αντικατοπτρίζεται στην εικόνα 2.1. Ένας HTTP Server πρέπει οπωσδήποτε να υποστηρίζει τις εντολές GET και HEAD. Ειδικότερα οι εντολές είναι: GET: Η εντολή GET, προσδιορίζει την απαίτηση για την παρουσίαση ενός συγκεκριμένου resource. Η εντολή πρέπει αποκλειστικά να λαμβάνει δεδομένα χωρίς καμία άλλη επίπτωση. HEAD: Η εντολή HEAD, είναι όμοια με την GET, αλλά έχει την διαφορά ότι δεν μεταφέρει υλικό. Χρησιμοποιείται συνήθως στην λήψη meta-data χωρίς την λήψη και του ανάλογου περιεχόμενου. POST: Η εντολή POST, δίνει οδηγία στον server να δεχτεί το επισυναπτόμενο περιεχόμενο μέσα στο body του μηνύματος. Το επισυναπτόμενο υλικό μπορεί να είναι δεδομένα προς εισαγωγή σε μια βάση δεδομένων, φωτογραφικό υλικό ή οποιαδήποτε άλλη πληροφορία. PUT: Η εντολή PUT, προσδιορίζει στον server πως το επισυναπτόμενο περιεχόμενο, πρέπει να αποθηκευτεί στο συγκεκριμένο Uniform Resource Identifier. Αν το resource υπάρχει ήδη, τότε τροποποιείται ώστε να περιέχει και τα νέα δεδομένα. DELETE: Η εντολή DELETE, διαγράφει το resource στο ζητούμενο URI. TRACE: Η μέθοδος TRACE, παρέχει την δικτυακή διαδρομή του μηνύματος, ώστε ο δέκτης να μάθει αν μεσολαβήσαν αναμεταδόσεις ή τροποποιήσεις από ενδιάμεσους, στην επικοινωνία server. OPTIONS: H εντολή OPTIONS, επιστρέφει στον client, το πλήθος από τις υποστηριζόμενες εντολές server side, για το συγκεκριμένο URL. Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

14 6 CONNECT: Η εντολή CONNECT, μετατρέπει την σύνδεση σε ένα transparent TCP/IP tunnel, συνήθως για την υποστήριξη SSL κωδικοποιημένης επικοινωνίας μέσω μη κρυπτογραφημένων proxy. PATCH: Η εντολή PATCH, δίνει εντολή για τροποποίηση των δεδομένων σε ένα συγκεκριμένο URI. Εικόνα 2.1: Δομή και λειτουργικές πληροφορίες των εντολών HTTP [7] Message Queue Telemetry Transport (MQTT) Το Message Queue Telemetry Transport (MQTT) [8], είναι ένα πρωτόκολλο επικοινωνίας το οποίο ενσωματώνει το publish subscribe μοντέλο. Είναι ελαφρύ δικτυακά, και χρησιμοποιεί το TCP/IP. Συνήθως χρησιμοποιείται σε εφαρμογές που έχουν περιορισμένο network bandwidth. Για την υποστήριξη του publish subscribe μοντέλου απαιτείται ένας διαμεσολαβητής μηνυμάτων (broker). O broker είναι υπεύθυνος για την διανομή των μηνυμάτων στους κατάλληλους clients, ανάλογα με το topic στο οποίο έχουν κάνει subscribe. Πιο συγκεκριμένα, κάθε client, κάνει subscribe σε κάποια συγκεκριμένα topic. Κάθε μεταδιδόμενο μήνυμα, φέρει και αυτό ένα topic, και μεταδίδεται (push) στον broker από έναν publisher. Όταν το μήνυμα φτάσει στον broker, αυτός ελέγχει ποιοι clients έχουν κάνει subscribe στο συγκεκριμένο topic και τους μεταδίδει το μήνυμα. Κάθε client έχει την δυνατότητα να είναι ταυτόχρονα και Publisher και Subscriber, όπως φαίνεται στην εικόνα 2.2. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

15 ΔΙΑΔΊΚΤΥΟ ΑΝΤΙΚΕΙΜΈΝΩΝ ΚΑΙ RESTFUL ΥΠΗΡΕΣΊΕΣ ΙΣΤΟΎ 7 Εικόνα 2.2: Γραφική Απεικόνιση του πρωτοκόλλου MQTT[9] To MQTT προσδιορίζει ένα πλήθος εντολών που μπορεί να εκτελέσει κάθε client. Ειδικότερα: Connect: Ο client περιμένει για αποδοχή της σύνδεσης από τον server. Disconnect: O client τερματίζει οποιεσδήποτε εντολές εκτελούσε και τερματίζει την σύνδεση με τον server. Subscribe: O client δηλώνει την συνδρομή του στον broker για ένα συγκεκριμένο topic. Έπειτα έχει την δυνατότητα να δεχτεί κάθε μήνυμα το οποίο φέρει το συγκεκριμένο topic. Unsubscribe: O client δηλώνει την διαγραφή της συνδρομής του σε ένα συγκεκριμένο topic, και ο broker παύει να του μεταδίδει μηνύματα που φέρουν το συγκεκριμένο topic. Publish: O client μεταδίδει ένα μήνυμα, υπό συγκεκριμένο topic, στον broker. To MQTT χρησιμοποιείται σήμερα από πολλές δημοφιλής εφαρμογές και υπηρεσίες όπως το Facebook Messenger, Amazon Web Services, Adafruit Cloud Services και Microsoft Azure. Ακόμα αποτελεί βάση για την υλοποίηση των πρωτοκόλλων Apache ActiveMQ, RabbitMQ, Advanced Message Queuing Protocol (AMQP) και Streaming Text Oriented Messaging Protocol (STOMP) [8] Constrained Application Protocol (COAP) Το Constrained Application Protocol (CoAP)[10] είναι ένα πρωτόκολλο επικοινωνίας για συσκευές περιορισμένων δυνατοτήτων. Προσδίδει την δυνατότητα στις συσκευές να επικοινωνήσουν με το ευρύτερο διαδίκτυο χρησιμοποιώντας ένα όμοιο πρωτόκολλο επικοινωνίας με αυτό των κλασσικών διασυνδεδεμένων συσκευών. Το CoAP είναι σχεδιασμένο ώστε η λειτουργία του να μεταφράζεται εύκολα σε λειτουργίες HTTP, υποστηρίζοντας παράλληλα όλα τα απαιτούμενα στοιχεία για την χρήση του στο τομέα του IoT και M2M. Η επικοινωνία χρησιμοποιεί URL και URI όπως και το HTTP. Το πρωτόκολλο βασίζεται πάνω στην επικοινωνία UDP. Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

16 8 To CoAP ενσωματώνει σχεδόν τις ίδιες εντολές με το HTTP, με ελάχιστες αλλαγές και προσθήκες. Ειδικότερα: GET: Η εντολή GET, προσδιορίζει την απαίτηση για την παρουσίαση ενός συγκεκριμένου resource. Η εντολή πρέπει αποκλειστικά να λαμβάνει δεδομένα χωρίς καμία άλλη επίπτωση. HEAD: Η εντολή HEAD, είναι όμοια με την GET, αλλά έχει την διαφορά ότι δεν μεταφέρει υλικό. Χρησιμοποιείται συνήθως στην λήψη meta-data χωρίς την λήψη και του ανάλογου περιεχόμενου. POST: Η εντολή POST, δίνει οδηγία στον server να δεχτεί το επισυναπτόμενο περιεχόμενο μέσα στο body του μηνύματος. Το επισυναπτόμενο υλικό μπορεί να είναι δεδομένα προς εισαγωγή σε μια βάση δεδομένων, φωτογραφικό υλικό ή οποιαδήποτε άλλη πληροφορία. PUT: Η εντολή PUT, προσδιορίζει στον server πως το επισυναπτόμενο περιεχόμενο, πρέπει να αποθηκευτεί στο συγκεκριμένο Uniform Resource Identifier. Αν το resource υπάρχει ήδη, τότε τροποποιείται ώστε να περιέχει και τα νέα δεδομένα. DELETE: Η εντολή DELETE, διαγράφει το resource στο ζητούμενο URI. TRACE: Η μέθοδος TRACE, παρέχει την δικτυακή διαδρομή του μηνύματος, ώστε ο δέκτης να μάθει αν μεσολαβήσαν αναμεταδόσεις ή τροποποιήσεις από ενδιάμεσους, στην επικοινωνία server. OPTIONS: H εντολή OPTIONS, επιστρέφει στον client, το πλήθος από τις υποστηριζόμενες εντολές server side, για το συγκεκριμένο URL. CONNECT: Η εντολή CONNECT, μετατρέπει την σύνδεση σε ένα transparent TCP/IP tunnel, συνήθως για την υποστήριξη SSL κωδικοποιημένης επικοινωνίας μέσω μη κρυπτογραφημένων proxy. PATCH: Η εντολή PATCH, δίνει εντολή για τροποποίηση των δεδομένων σε ένα συγκεκριμένο URI. OBSERVE: Η εντολή OBSERVE, δίνει εντολή στον server για παρακολούθηση ενός συγκεκριμένου resource και αναμετάδοση του περιεχομένου του σε περίπτωση τροποποίησης του, σε όλους τους clients που έχουν κάνει observe για το συγκεκριμένο resource. To CoAP είναι ιδιαίτερα δημοφιλές στον τομέα του IoT, όπου το πλήθος των αισθητήρων και διακοπτών μιας έξυπνης συσκευής περιορισμένης δικτύωσης, μπορεί να απεικονίσει τις πληροφορίες μέσω URI για εύκολη οργάνωση και πρόσβαση OMA Light Weight Machine to Machine (LWM2M) Το OMA Light Weight Machine to Machine (OMA LWM2M) πρωτόκολλο[11], είναι δημιουργημένο από την Open Mobile Alliance, με σκοπό την χρήση του στο τομέα του IoT device management και Μ2Μ. Το πρωτόκολλο επιτρέπει την εύκολη επικοινωνία μεταξύ συσκευών LWM2M και server. Παρέχεται η δυνατότητα για πλήρη διαχείριση των συσκευών, μετάδοση δεδομένων αλλά και εύκολη επεκτασιμότητα για την προσαρμογή στις απαιτήσεις Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

17 ΔΙΑΔΊΚΤΥΟ ΑΝΤΙΚΕΙΜΈΝΩΝ ΚΑΙ RESTFUL ΥΠΗΡΕΣΊΕΣ ΙΣΤΟΎ 9 οποιασδήποτε εφαρμογής. Η υλοποίηση του πρωτοκόλλου συνήθως γίνεται με CoAP, αλλά υπάρχουν εκδόσεις που βασίζονται στο MQTT. To LWM2M προσδιορίζει ένα πλήθος εντολών για την εύκολη διαχείριση των resources των συσκευών. Ειδικότερα: READ: Λαμβάνει τα περιεχόμενα ενός συγκεκριμένου resource της συσκευής. WRITE: Τροποποιεί τα δεδομένα του περιεχομένου ενός συγκεκριμένου resource της συσκευής. CREATE: Δημιουργεί ένα resource στο συγκεκριμένο URI. DELETE: Διαγράφει το συγκεκριμένο resource και URI από την συσκευή. DISCOVER: Βρίσκει όλα τα resources και sub resources που ανήκουν σε ένα URI EXECUTE: Εκτελεί μια λειτουργία της συσκευής. OBSERVE: Ανάλογο με το Observe του CoAP, «παρακολουθεί» και διαβάζει όλες τις αλλαγές σε ένα resource της συσκευής. Παράλληλα με τις εντολές λειτουργίας για LWM2M enabled devices, παρέχονται και εντολές για την διαχείριση των συσκευών. Πιο συγκεκριμένα ο LWM2M Server διαθέτει μια registry με όλες τις συνδεδεμένες συσκευές. Η διατήρηση της σύνδεσης ελέγχεται με ένα χρονοδιακόπτη που ανά συγκεκριμένο χρόνο ελέγχει αν η θύρα της διεύθυνσης CoAP είναι ακόμα ανοιχτή. Η λειτουργία αυτή είναι συχνά αναφερόμενη και ως heartbeat. Οι βασικότερες εντολές διαχείρισης των συσκευών είναι: Register: Εκτελείται κατά την σύνδεση της συσκευής με τον Server, και αποθηκεύει τα στοιχεία τις συσκευής στην registry. Update Register: Εκτελείται μαζί με τον έλεγχο heartbeat και τροποποιεί την registry, ενημερώνονται τα στοιχεία της συσκευής. Unregister: Διαγράφει την συσκευή από την registry και απαγορεύει την επικοινωνία μαζί της ως ότου ξαναγίνει Register. Το πρωτόκολλο LWM2M υλοποιείται από λίγες γλώσσες αυτή τη στιγμή. Πιο συγκεκριμένα το Eclipse Leshan Project το υλοποιεί σε Java, το project Wakaama σε C, και το ARM mbed σε C Αρχιτεκτονική REST Η Representational State Transfer αρχιτεκτονική[12], ή αλλιώς REST, είναι μία αρχιτεκτονική επικοινωνίας μεταξύ υπολογιστών στο διαδίκτυο. Ένα Web Service το οποίο χρησιμοποιεί την REST χαρακτηρίζεται και ως REST API. Η χρήση της, αποσκοπεί στην καλύτερη απόδοση και ταχύτερη λειτουργία, την ικανότητα για ευκολότερη επέκταση, και αξιοπιστία. Η αρχιτεκτονική REST επιτρέπει στα συστήματα να διαβάζουν Web Resources, χρησιμοποιώντας έναν ενοποιημένο τρόπο και συγκεκριμένες προκαθορισμένες stateless εντολές. Τα Web Resources, χαρακτηρίζονται από το URL και URI τους, και μπορούν να περιέχουν διάφορα είδη περιεχομένου όπως JSON, HTML, XML κτλ. Σύμφωνα με τους περιορισμούς της αρχιτεκτονικής, επηρεάζονται και αναγνωρίζονται τα ακόλουθα χαρακτηριστικά που την καθιστούν χρήσιμή: Καλή απόδοση. Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

18 10 Κλιμακωσιμότητα για την υποστήριξη μεγάλου αριθμού στοιχείων αλλά και αλληλεπιδράσεων μεταξύ τους. Απλό και ενοποιημένο τρόπο επικοινωνίας Εύκολη τροποποίηση των στοιχείων για την προσαρμογή στις συνεχώς αυξανόμενες απαιτήσεις. Portability Αξιοπιστία Για την απόκτηση των παραπάνω χαρακτηριστικών σε ένα RESTful Web Service καθορίζονται οι παρακάτω πέντε προδιαγραφές/περιορισμοί. Αυτοί οι περιορισμοί επηρεάζουν τον τρόπο με τον οποίο ένας server επεξεργάζεται και ανταποκρίνεται στους client. Client Server Αρχιτεκτονική: Γίνεται διαχωρισμός ευθυνών (separation of concerns) μεταξύ του user interface και της διαχείρισης των δεδομένων. Με αυτό τον τρόπο επιτυγχάνεται portability και κλιμακωσιμότητα στο σύστημα, αφού client και server αναπτύσσονται σαν διαφορετικές οντότητες. Statelessness: Η επικοινωνία μεταξύ client και server δεν περιορίζεται από κάποια κατάσταση για αυτή την επικοινωνία μεταξύ των διαφόρων request. Δηλαδή κάθε request από τον client περιλαμβάνει όλα τα απαραίτητα δεδομένα για την διαχείριση και απόκριση του server. Δυνατότητα χρήσης Cache: Οι απαντήσεις πρέπει να μπορούν να γίνουν cache, ή τα resources να καθορίζουν αν επιτρέπουν να γίνονται cache ώστε να περιοριστεί ο αριθμός των εντολών επεξεργασίας και πάντα να επιστρέφονται στον client τα κατάλληλα δεδομένα τάχιστα και με ακρίβεια. Αυτό το στοιχείο αυξάνει την απόδοση και την κλιμακοσιμότητα. Σύστημα «Στρώσεων»: Ο client δεν μπορεί να γνωρίζει εάν συνδέεται απευθείας με τον server ή σε κάποιο μεσάζοντα server. Συνήθως χρησιμοποιούνται μεσάζοντες server ως διαχειριστές φορτίου (load balancers) ή ως ανταποκριτές για κοινά διαμοιρασμένη cache μεταξύ των μεσαζόντων server και του κανονικού. Τέλος προσθήκη μεσαζόντων server αποτελεί ένα σημαντικό μέτρο για την προστασία του server. Ενοποιημένο Interface: Αυτός ο περιορισμός είναι και ο πιο σημαντικός και είναι που διαμορφώνει την αρχιτεκτονική. Πιο συγκεκριμένα κάνει πιο απλή και ανεξάρτητη την ανάπτυξη στοιχείων για το σύστημα. Αποτελείται από τέσσερις περιορισμούς. Ταυτοποίηση resource κατά το request: Κάθε resource χαρακτηρίζεται ανεξάρτητα από ένα URI, και η απεικόνιση τους στον client μπορεί να διαφέρει από το μοντέλο απεικόνισης στον server. (πχ ο server να διαθέτει xml, αλλά να αποστέλλεται ως html στον client). Διαχείριση των resources μέσω των απεικονίσεων: Εάν ο client διαθέτει μία απεικόνιση ενός resource, συμπεριλαμβανομένων των metadata, τότε έχει την ικανότητα να τροποποιήσει ή να διαγράψει το περιεχόμενο του resource. Αυτό-εξηγούμενα μηνύματα: Κάθε μήνυμα που ανταλλάσσεται μεταξύ client και server περιέχει όλες τις απαραίτητες πληροφορίες για την σωστή επεξεργασία του άπτον ανάλογο φορέα. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

19 ΣΎΝΘΕΣΗ ΥΠΗΡΕΣΙΏΝ 11 Hypermedia as the engine of application state (HATEOAS): Ο client δεν πρέπει να διαθέτει κώδικα για συγκεκριμένες λειτουργίες πάνω σε συγκεκριμένα resources του server. Αντιθέτως μπορεί να απαιτεί πληροφορίες από τον server σχετικά με τα διαθέσιμα resources και τις ανάλογα διαθέσιμες εντολές γι αυτά. Αντίστοιχα πρέπει και ο server να υποστηρίζει αυτή τη λειτουργία. 3 ΣΥΝΘΕΣΗ ΥΠΗΡΕΣΙΩΝ Service Composition ονομάζουμε την ορθή δόμηση και δημιουργία υπηρεσιών προς κατανάλωση από χρήστες ή άλλες υπηρεσίες. Οι υπηρεσίες παρέχουν διακριτή λειτουργικότητα, μπορούν να αποτελούνται από άλλες υπηρεσίες, και έχουν συγκεκριμένο σκοπό. Ο τρόπος αλληλεπίδρασης με τον χρήστη (καταναλωτή) τις καθιστά μαύρα κουτιά, δηλαδή για δεδομένη είσοδο παρατηρείται μόνο η έξοδος αντί των ενδιάμεσων μηχανισμών που την συνθέτουν. Σε αυτό το κεφάλαιο αναλύουμε την συγγραφή δύο ειδών υπηρεσιών, τα Web Mashups και τα IoT Mashups. 3.1 Υπηρεσίες Ιστού Ένα Web Mashup είναι μια υπηρεσία η οποία έχει δημιουργηθεί από τον συνδιασμό δύο ή περισσότερων υπηρεσιών ιστού. Η νέα υπηρεσία ενώ βασίζεται πάνω στην λειτουργικότητα των συνδιαζόμενων υπηρεσιών προσθέτει νέες λειτουργίες, διαφοροποιώντας τις αρχικές, ώστε το αποτέλεσμα να μην είναι ένας απλός αθροιστικός συνδυασμός. Αντιθέτως το τελικό Web Mashup διαθέτει τις δικές του μοναδικές λειτουργίες, καθιστώντας το μοναδικό. Με την άνοδο της δημοφιλίας των Web API στον χώρο των διαδικτυακών υπηρεσιών, τα Web Mashups είναι πιο δημοφιλή από ποτέ. Για την ευκολία της συγγραφής των υπηρεσιών, έχουν δημιουργηθεί εργαλεία τα οποία καθιστούν τον συνδυασμό και την εκμετάλλευση άλλων υπηρεσιών απλή. Πιο συγκεκριμένα τα εργαλεία συχνά δεν απαιτούν προγραμματιστική ικανότητα απ τον χρήστη τους, αλλά παρέχουν κάποιου είδους γραφικής λειτουργικότητας (πχ. Widgets) για την συγγραφή των υπηρεσιών. Τα Web Mashups κατηγοριοποιούνται σε τρείς κατηγορίες[13]: Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

20 12 Καταναλωτή (Consumer): Με τον συνδυασμό δεδομένων από πολλαπλές δημόσιες πηγές, προβάλλονται τα δεδομένα μέσω του περιηγητή ιστού του χρήστη οργανωμένα, για ευκολότερη κατανάλωση. Δεδομένων (Data): Συλλογή και απεικόνιση όμοιων τύπου δεδομένων από πολλές πηγές σε μία «εφαρμογή». Επειδή ο συνδυασμός των δεδομένων γίνεται σε μια νέα εφαρμογή, έχει δημιουργηθεί ένα νέο Web Service το οποίο παρέχει υπηρεσίες που καμία απ τις προηγούμενες πηγές δεν παρείχε. Αυτή είναι και η βασική διαφορά μεταξύ Web Mashups τύπου consumer και τύπου data. Enterprise: Εφαρμογές οι οποίες συνδυάζουν τα δικά τους δεδομένα και υπηρεσίες με εξωτερικές υπηρεσίες του διαδικτύου. Τέτοιου είδους Mashup είναι αρκετά ασφαλές και αποτελούν οπτικά πλούσιες εφαρμογές και παρέχουν σημαντικές πληροφορίες προς κατανάλωση για το όφελος της εταιρίας που τις καταναλώνει. Κατά τη δημιουργία ενός Web Mashup, αντιμετωπίζεται ένας αριθμός προβλημάτων. Ειδικότερα αυτά τα προβλήματα συμψηφίζονται σε: Ασυμβατότητα κειμένου και δεδομένων: Δεδομένα τα οποία έχουν εισαχθεί στις υπηρεσίες στην γλώσσα που μιλούν οι άνθρωποι είναι συχνά αόριστα και δύσκολα επεξεργάσιμα από τους υπολογιστές. Οργάνωση και ταυτότητα δεδομένων: Διαφορετικές πληροφορίες οργανώνονται με διαφορετικό τρόπο σε κάθε υπηρεσία. Κατά τον συνδυασμό των πληροφοριών από δύο διαφορετικές υπηρεσίες, ο συγγραφέας του Mashup καλείται να λύσει το πρόβλημα της κατάλληλης οργάνωσης των πληροφοριών κατά τον συνδυασμό τους, για την ευκολότερη κατανάλωση. Επίπεδο Αοριστίας: Οι συνδυαζόμενες υπηρεσίες παρέχουν τα δεδομένα τους σε διαφορετικά επίπεδα αοριστίας, στοιχείο που δυσκολεύει τον σωστό συνδυασμό τους. Ένα παράδειγμα αυτού του προβλήματος είναι αν μια υπηρεσία παρέχει δεδομένα για όλες τις χώρες της Ευρωπαϊκής Ένωσης συνολικά, ενώ μια άλλη υπηρεσία τα παρέχει σε επίπεδο χώρας. Ποιότητα των δεδομένων: Καθώς τα δεδομένα τρίτων υπηρεσιών δεν ελέγχονται απευθείας από τον δημιουργό του Mashup τίθεται πάντα το ερώτημα της ακεραιότητας των πληροφοριών. Επίσης υπάρχει πάντα ο κίνδυνος ακόμα και αν οι συνδυαζόμενες πληροφορίες είναι ακέραιες, το αποτέλεσμα τους να είναι λάθος. Προς την αντιμετώπιση αυτού του προβλήματος απαραίτητοι είναι μηχανισμοί εξακρίβωσης της ακρίβειας και ακεραιότητας των δεδομένων που διακινούνται απ το Mashup. Παράδειγμα ενός Web Mashup αποτελεί ο ειδικευμένος χάρτης αγγελιών Cragislist. Αποτελείται από δύο υπηρεσίες, το Google Maps και το Craigslist. Το Google Maps είναι μία διαδικτυακή εφαρμογή χαρτών. Ο χρήστης έχει την ικανότητα να προβάλει δρόμους, τοποθεσίες, διευθύνσεις κτλ. Η υπηρεσία Craigslist, είναι μία ιστοσελίδα ανάρτησης αγγελιών για αγοραπωλησίες και ενοικιάσεις, ιδιαίτερα δημοφιλής στις Η.Π.Α. Αυτές οι δύο υπηρεσίες συνδυάστηκαν, με τέτοιο τρόπο ώστε να παρέχεται στον χρήστη ένας χάρτης με όλες τις αγγελίες σημειωμένες γεωγραφικά πάνω στον χάρτη. Με αυτό τον τρόπο διευκολύνεται ο χρήστης στην αναζήτηση τοπικών αγγελιών σε περιοχές τις οποίες γνωρίζει καλά. Ακόμα η άμεση γεωγραφική πληροφόρηση περί αγγελιών σε άγνωστες για τον χρήστη περιοχές, βοήθα αρκετά και πωλητή και αγοραστή, καθώς απαλλάσσονται απ το βήμα της έρευνας για την καθοδήγηση τους στο σημείο της αγγελίας. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

21 ΣΎΝΘΕΣΗ ΥΠΗΡΕΣΙΏΝ Υπηρεσίες Διαδικτύου Αντικειμένων Όμοια με τα Web Mashups λειτουργούν και τα IoT Mashups. Στη συγκεκριμένη περίπτωση, αντί της άντλησης πληροφοριών και λειτουργιών από διαδικτυακές υπηρεσίες, χρησιμοποιούνται συσκευές ΙοΤ. Με την αλλαγή της πηγής των δεδομένων, δημιουργούνται νέα προβλήματα κατά τη σύνθεση Mashup. Αρχικά η υπηρεσία πρέπει να επικοινωνεί απευθείας με συσκευές. Επειδή οι συσκευές μπορεί να διαφέρουν σε επίπεδο υλικού αλλά και σε επίπεδο λογισμικού, τα πρωτόκολλα επικοινωνίας κάθε συσκευής δύναται να διαφέρουν. Επομένως γίνεται προσπάθεια για χρήση πρωτοκόλλων τα οποία καθιστούν την επικοινωνία ανεξαρτήτως της συσκευής όπως το CoaP και το MQTT. Συχνή είναι και η χρήση Gateways σε περίπτωση που χρησιμοποιούνται άγνωστα, device specific, πρωτόκολλα. Ένα gateway αποτελεί πρακτικά έναν μεσάζοντα για μία ομάδα συσκευών κατά την επικοινωνία προς και από της υπηρεσίας. Ένα νέο πρόβλημα που δημιουργείται στη συγκεκριμένη κατηγορία Mashup, είναι αυτό της κλιμάκωσης. Συχνά ο αριθμός των συσκευών που χρησιμοποιούνται στις υπηρεσίες είναι αρκετά μεγάλος, κάτι το οποίο ισοδυναμεί με την ανάγκη για την μαζική διαχείριση και συντήρηση αυτών των συσκευών. Κατ επέκταση τα δημιουργούμενα εργαλεία για την σύνθεση υπηρεσιών είναι αρκετά πιο περίπλοκα από αυτά των Web Mashup, καθώς καλούνται να συμπεριλάβουν μια πληθώρα λειτουργιών παραπάνω, που μπορεί να μην σχετίζονται άμεσα με την συγγραφή και λειτουργία της υπηρεσίας. Παρ όλα αυτά τα εργαλεία συγγραφής, κινούνται στο ίδιο πνεύμα με αυτά των Web Mashup, δηλαδή υπάρχει μια εμφανής προτίμηση σε γραφικά εργαλεία τα οποία απαλλάσσουν τον χρήστη από την χρήση κώδικα, όπως γίνεται και στα Web Mashup. Καθώς η λειτουργίες των ΙοΤ συσκευών μπορούν να διαφέρουν σε μεγάλο βαθμό, τα Mashups είναι αρκετά πιο ειδικευμένα από αυτά των διαδικτυακών υπηρεσιών. Χαρακτηριστικό παράδειγμα ενός IoT Mashup είναι η συλλογή δεδομένων από μεγάλο αριθμών συσκευών ΙοΤ που φέρουν την ικανότητα μέτρησης ατμοσφαιρικών στοιχείων όπως την θερμοκρασία, υγρασία κτλ. Σε επόμενο στάδιο αυτά τα δεδομένα κατόπιν επικοινωνίας τους στην υπηρεσία, οργανώνονται και προβάλλονται στον καταναλωτή για άμεση ενημέρωση για τις καιρικές συνθήκες σε διάφορες περιοχές του κόσμου. Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

22 14 4 ΤΕΧΝΟΛΟΓΙΕΣ ΑΙΧΜΗΣ Σε αυτό το κεφάλαιο αναλύεται η έρευνα πάνω στις διαθέσιμες τεχνολογίες για την συγγραφή εφαρμογών Mashup. Τα εργαλεία και οι πλατφόρμες διαχωρίζονται σε τρείς διακριτές κατηγορίες ανάλογα με το κυρίαρχο στοιχείο τους. Ειδικότερα, γίνεται διάκριση στις κατηγορίες: Cloud πλατφόρμες, πλατφόρμες δεδομένων (data platforms) και γραφικά εργαλεία (visual programming tools). Η παραπάνω διάκριση δεν συνεπάγεται την ανεξαρτησία μεταξύ τους, καθώς είναι δυνατό να συνδυαστούν δυο ή παραπάνω υπηρεσίες μαζί για την δημιουργία μιας εφαρμογής. 4.1 Υπηρεσίες Σύννεφου Οι πλατφόρμες σύννεφου ή αλλιώς Cloud Platforms, προσφέρουν μια ολοκληρωμένη λύση στην ανάπτυξη και διανομή της mashup εφαρμογής. Συνήθως συνοδεύονται από το δικό τους εργαλείο ανάπτυξης ή SDK και προσφέρουν την δυνατότητα για online hosting στην ίδια την πλατφόρμα. Με αυτόν τον τρόπο η εφαρμογή του χρήστη βρίσκεται πάντα στο διαδίκτυο, και η συντήρηση του δικτύου περνά αποκλειστικά στον πάροχο της πλατφόρμας. Σε αυτή τη κατηγορία υπηρεσιών συμπεριλαμβάνονται οι: Microsoft Azure, Amazon Web Services, Thingspeak, Devicehub.net Microsoft Azure Το Microsoft Azure είναι ένα Cloud Computing Service, δημιουργημένο από την Microsoft, με σκοπό την δημιουργία, εκτέλεση και διαχείριση εφαρμογών και υπηρεσιών, που τρέχουν πάνω στο σύννεφο[14]. Ένα από τα προσφερόμενα στοιχεία της πλατφόρμας είναι το Azure IoT Suite το οποίο περιέχει προγραμματιστικές βιβλιοθήκες και framework για την σύνδεση και διαχείριση IoT συσκευών. Στην εικόνα 4.1 παραθέτουμε ένα παράδειγμα της τοπολογίας για την σύνδεση συσκευών στο Microsoft Azure. Πιο συγκεκριμένα το Azure IoT Suite περιέχει τα παρακάτω στοιχεία[15]: Azure IoT Hub: πλατφόρμα για την σύνδεση, παρακολούθηση και διαχείριση τον IoT συσκευών. Event Hubs: Πλατφόρμα διαχείρισης εισερχόμενων δεδομένων από τις συσκευές ως events. Είναι εύκολα κλιμακώμενη και μπορεί αν επεξεργασθεί δεδομένα από χιλιάδες συσκευές ταυτόχρονα. Ο συνδυασμός της με άλλα κομμάτια του IoT Suite, άλλα και της ευρύτερης πλατφόρμας Azure, καθιστά την δημιουργία εφαρμογών εύκολη. Stream Analytics: Εργαλείο σύγχρονης επεξεργασίας εισερχόμενων δεδομένων από τις συσκευές Machine Learning: Εργαλεία πρόβλεψης και συντήρησης των συσκευών βάση συλλεγόμενων δεδομένων Notifications Hub: Σύστημα ενημέρωσης χρηστών με την ικανότητα μαζικής αποστολής πληθώρας μηνυμάτων. Στο επίπεδο του Cloud, η πλατφόρμα προσφέρει την δυνατότητα ανάπτυξης και εκτέλεση εφαρμογών στις γλώσσες Java, Node.js, C#.Net. Για την ανάπτυξη παρέχονται framework από την Microsoft[16]. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

23 ΤΕΧΝΟΛΟΓΊΕΣ ΑΙΧΜΉΣ 15 Όσο αφορά τον κώδικα των ΙοΤ συσκευών, προσφέρονται SDK στις γλώσσες: Java, C, Python, Node.js, C#.Net[17]. Οι εφαρμογές και οι υπηρεσίες δημιουργημένες για την υπηρεσία σύννεφου της Microsoft, δεν έχουν την δυνατότητα να τρέξουν σε κάποιον τοπικό υπολογιστή, στοιχείο που καθιστά απαραίτητη την σύνδεση των συσκευών με το διαδίκτυο. Ακόμα η πλατφόρμα δεν είναι open source, αλλά παρέχει δωρεάν χρήση περιορισμένου κόστους σε φοιτητές[18]. Δυστυχώς στο φοιτητικό πρόγραμμα δεν διατίθεται η Azure IoT Suite. Εικόνα 4.1: Τοπολογία δικτύωσης συσκευών-σύννεφου[19] Προς την προσπάθεια τοπικής λειτουργίας της πλατφόρμας, για χρήση χωρίς σύνδεση στο διαδίκτυο, αναπτύσσεται το Microsoft Azure Stack, το οποίο αποτελεί έναν κλώνο της online πλατφόρμας αλλά σε τοπική τοποθεσία. Βρίσκεται σε στάδιο POC (proof of concept) και σύμφωνα με τις ανακοινώσεις, δεν υπάρχουν σχέδια για την ενσωμάτωση του Azure IoT Suite κατά την πρώτη διάθεση της πλατφόρμας[20] Amazon Web Services Η Amazon Web Services (AWS) είναι μια πλατφόρμα σύννεφου, η οποία δεν απευθύνεται αποκλειστικά στον τομέα του ΙοΤ. Προσφέρει ένα πλήθος υπηρεσιών για την συγγραφή, διανομή και συντήρηση διαδικτυακών εφαρμογών και υπηρεσιών[21]. Οι ολοκληρωμένες λύσεις που διαθέτει για την ανάπτυξη εφαρμογών ΙοΤ είναι οι: AWS Greengrass, AWS IoT Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

24 16 Platform, AWS IoT Button[22]. Καθώς το AWS IoT Button αναφέρεται μόνο σε ειδικευμένο hardware, θα αναφερθούμε μόνο στα πρώτα δύο στοιχεία. Το AWS IoT Platform είναι αρκετά όμοιο με την λύση της Microsoft. Είναι μια online πλατφόρμα που επιτρέπει σε ΙοΤ συσκευές να συνδεθούν στο σύννεφο και να επικοινωνήσουν μεταξύ τους ή με κάποια εφαρμογή ή υπηρεσία που τρέχει στο ίδιο σύννεφο[23], όπως φαίνεται στην εικόνα 4.2. Για την ανάπτυξη των εφαρμογών στις συσκευές προσφέρονται SDK στις γλώσσες C, Javascript, Java, Python, ios, Android και Arduino Yen.[24,25] Η σύνδεση του IoT Platform, με άλλα κομμάτια του AWS είναι που καθιστά την υπηρεσία ιδιαιτέρως επιτυχημένη. Εικόνα 4.2: Παράδειγμα Mashup τοπολογίας με κομμάτια της AWS[23] Αντιθέτως με το AWS IoT Platform που τρέχει μονίμως στο σύννεφο, παρέχεται και το AWS Greengrass. Σκοπός του είναι να δράσει σαν τοπικός μεσάζοντας μεταξύ του σύννεφου και τον συσκευών, ώστε να εξασφαλισθεί η ομαλή λειτουργία των συσκευών και κατ επέκταση της εφαρμογής, σε περίπτωση που διακοπεί η σύνδεση με της διαδικτυακές υπηρεσίας της Amazon. Παράδειγμα της αντίστοιχης δικτυακής τοπολογίας διακρίνουμε στην εικόνα 4.3. Εικόνα 4.3: Παράδειγμα τοπολογίας διασύνδεσης Greengrass[26] Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

25 ΤΕΧΝΟΛΟΓΊΕΣ ΑΙΧΜΉΣ 17 Προς την επιτυχία των παραπάνω στόχων, η Amazon υποστηρίζει offline χρήση της εφαρμογής, ασφάλεια στην επικοινωνία των συσκευών, παρεχόμενη και σχεδόν σύγχρονη ανταπόκριση στα δεδομένα των συσκευών και όμοια μοντέλα ανάπτυξης εφαρμογών και υπηρεσιών με αυτά τις online πλατφόρμας. Οι υπηρεσίας της Amazon, δεν είναι δωρεάν. Διατίθεται μια δοκιμαστική περίοδος δώδεκα μηνών στην οποία υπάρχει ένα όριο στο συνολικό αριθμό μηνυμάτων που μπορούν να μεταδοθούν στις υπηρεσίες της ανά μηνά[27,28] ThingSpeak Η πλατφόρμα Thingspeak είναι μια υπηρεσία σύννεφου που επιτρέπει την σύνδεση ΙοΤ συσκευών και την συλλογή πληροφοριών από αυτές [29]. Για την δημιουργίας της εφαρμογής γίνεται εκμετάλλευση των triggers, δηλαδή κανόνων συμπεριφοράς οι οποίοι βασίζονται πάνω στα συλλεγόμενα δεδομένα. Η επικοινωνία σύννεφου και συσκευής υλοποιείται μέσω της αρχιτεκτονικής για την οποία η πλατφόρμα παρέχει το δικό της RESTful API. Δεν διαθέτει visualizer για την γραφική απεικόνιση συμπεριφοράς ή δεδομένων. Υποστηρίζεται ένα πλήθος συσκευών όπως τα Arduino και RasberryPi[30]. Διατίθενται framework στις γλώσσες προγραμματισμού Ruby και Python για την ανάπτυξη του κώδικα στις συσκευές[31], ενώ η επεξεργασία των δεδομένων γίνεται σε MATLAB[30]. Η Thingspeak έχει χρησιμοποιηθεί με επιτυχία στους τομείς της συγκοινωνίας, την παρατήρηση και ανάλυση καιρικών φαινομένων και της διασκέδασης[30]. Η πλατφόρμα διατίθεται δωρεάν για ακαδημαϊκή χρήση, και προσφέρει πακέτα χρέωσης ανάλογα με τον ρυθμό και συνολικό αριθμό μεταδιδόμενων δεδομένων[32] DeviceHub.Net Η Devicehub.Net είναι μια πλατφόρμα δημιουργίας εφαρμογών με στόχο ΙοΤ συσκευές[33]. Τα δεδομένα που μεταδίδονται από κάθε συσκευή στο σύννεφο αναγνωρίζονται ως ξεχωριστά data streams τα οποία μπορεί ο προγραμματιστής να διαχειριστεί και επεξεργασθεί με τον ενσωματωμένο data manager ή να απεικονίσει γραφικώς μέσω του παρεχόμενου visualizer[34]. H επικοινωνία συσκευής σύννεφου υλοποιείται με την REST αρχιτεκτονική και του παρεχόμενου, API, με σκοπό την Μ2Μ επικοινωνία. Προσφέρεται υποστήριξη για δημοφιλής συσκευές ΙοΤ όπως το Arduino, RasberryPi και Intel Galileo, με την διάθεση SDK στις γλώσσες Python και C++[35]. Η πλατφόρμα έχει χρησιμοποιηθεί επιτυχώς στον τομέα του Industrial Automation, Home Automation, στις συγκοινωνίες αλλά και σε Ιατρικές εφαρμογές[33]. Η πλατφόρμα προσφέρει ένα δωρεάν πρόγραμμα χρέωσης με περιορισμούς στον αριθμό των συσκευών, τον ρυθμό μετάδοσης δεδομένων και τον χρόνο αποθήκευσης αυτών στο σύννεφο. Δεν παρέχεται κάποιο ακαδημαϊκό πρόγραμμα[36]. 4.2 Πλατφόρμες Δεδομένων (Data Platforms) Οι πλατφόρμες δεδομένων, συνήθως αποτελούν διαδικτυακές λύσεις. Κύριος σκοπός τους είναι η συλλογή και επεξεργασία δεδομένων από ΙοΤ συσκευές και όχι ο ίδιος ο έλεγχος της συσκευής. Αυτό επιτρέπει την δημιουργία mashup διαφορετικού είδους από τα τυπικά τα οποία συνδυάζουν λειτουργικότητα από πολλαπλές συσκευές. Σε αυτή τη κατηγορία συμπεριλαμβάνονται οι υπηρεσίες Xively και Global Sensor Networks. Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

26 Xively Η Xively είναι μια πλατφόρμα σύννεφου, η οποία παρέχει πλήθος εργαλείων για την αλληλεπίδραση και συλλογή δεδομένων από ΙοΤ συσκευές[37]. Για την επικοινωνία με τις συσκευές παρέχεται REST API. Κύριος σκοπός της πλατφόρμας είναι η αποκλειστική συλλογή δεδομένων και η απεικόνιση τους, δηλαδή δεν διαθέτει κάποια μηχανή κανόνων για ενεργοποίηση λειτουργιών στις συσκευές, η κάποιο τρόπο μηχανικής αλληλεπίδρασης με την συσκευή. Αποτέλεσμα αυτού, είναι τα mashups να πλησιάζουν περισσότερο την μορφή ενός κλασσικού Web Mashup παρά τα πλαίσια του ΙοΤ Mashup. Η πλατφόρμα δεν είναι δωρεάν, αλλά συνεργάζεται με πελάτες on demand[38] Global Sensor Networks Είναι μια πλατφόρμα με σκοπό την αποκλειστική συλλογή δεδομένων από ΙοΤ συσκευές. Πρακτικά είναι ένα JAVA περιβάλλον, το οποίο τρέχει σε έναν ή περισσότερους υπολογιστές που απαρτίζουν το δίκτυο όπως παραθέτουμε στην εικόνα 4.4. Τα δεδομένα που μεταδίδονται από τις συσκευές μορφοποιούνται στην γλώσσα XML, και αποστέλλονται στο δίκτυο[39]. Με την κατάλληλη XML επεξεργασία στο περιβάλλον, οι πληροφορίες διαχωρίζονται και φιλτράρονται, και έπειτα αποστέλλονται στις προγραμματιζόμενες υπηρεσίες που περιμένουν τα δεδομένα (πχ. Μια ιστοσελίδα, ή μια βάση δεδομένων αποθήκευσης μετρήσεων). Το ισχυρό στοιχείο της πλατφόρμας, σύμφωνα με τους δημιουργούς, είναι πως είναι platform-agnostic, δηλαδή μπορεί να αλλάξει κάποιος τους sensors, και το πρόγραμμα θα συνεχίσει να τρέχει χωρίς καμία αλλαγή στον κώδικα[39]. Εικόνα 4.4: Παράδειγμα τοπολογίας σύνδεσης GSM[39] 4.3 Γραφικά Εργαλεία Προγραμματισμού Τα γραφικά εργαλεία συνήθως είναι αυτόνομα προγραμματιστικά περιβάλλοντα, τα οποία δεν είναι απαραίτητο να διατίθενται σε κάποια online πλατφόρμα ή να συνοδεύονται από ενσωματωμένη λειτουργικότητα για ΙοΤ. Προσφέρουν ένα γραφικό περιβάλλον, και ένα σύστημα διαχείρισης εντολών μέσω μίας γραφικής απεικόνισης, ώστε η λειτουργία του τελικού προγράμματος να είναι εύκολα διακριτή στον αναγνώστη. Η μέθοδος προγραμματισμού είναι συχνά αναφερόμενη και ως flow programming, καθώς μεταφέρεται πληροφορία από μία γραφική απεικόνιση της εντολής στην επόμενη. Η λειτουργικότητα μπορεί να επεκταθεί εύκολα, και η εφαρμογή μπορεί να τρέξει σε πλήθος συσκευών αφού συνήθως το περιβάλλον συνηθίζεται να βασίζεται πάνω σε μια γλώσσα. Υπό το πρίσμα αυτής της εργασίας, μελετώνται τα εργαλεία τα οποία είναι τα πιο σχετικά στην βιομηχανία του ΙοΤ. Σε αυτή τη κατηγορία περιλαμβάνονται τα εργαλεία Wotkit, Node-RED και Losant. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

27 ΤΕΧΝΟΛΟΓΊΕΣ ΑΙΧΜΉΣ Wotkit Το Wotkit είναι μια υπηρεσία που επιτρέπει στον χρήστη να λάβει και επεξεργασθεί δεδομένα από sensors και εξωτερικά συστήματα σε πραγματικό χρόνο. Είναι υλοποιημένο σε Java χρησιμοποιώντας το Spring framework και κάνει χρήση του Java Concurrency framework στην μηχανή επεξεργασίας του. Διαθέτει έναν browser based γραφικό περιβάλλον. Ο χρήστης καλείται να δημιουργήσει εφαρμογές (pipes) τα οποία αποτελούνται από modules και ενώνονται με wires, όπως φαίνεται στην εικόνα 4.5. Εικόνα 4.5: Παράδειγμα Pipe στο Wotkit[40,41] Η υπηρεσία χρησιμοποιεί έναν multi-threaded execution scheduler για την παράλληλη επεξεργασία των εισερχόμενων δεδομένων όπως διαφαίνεται στην εικόνα 4.6. Χρησιμοποιώντας τα input modules και συνδέοντας με εξωτερικά συστήματα (πχ. Sensors) δημιουργούνται tasks, τα οποία απαρτίζονται από ένα instance του module και τα δεδομένα σε μορφή μηνύματος, και τοποθετούνται σε μια queue. O scheduler περιμένει να τοποθετηθούν tasks στην queue και τα επεξεργάζεται, μέσω της μεθόδου process που είναι κομμάτι του instanced module του task[40]. Η υπηρεσία διαθέτει input και output modules, ένα monitor module για debugging, ένα actuator module για τον έλεγχο των συσκευών και ένα function module για την επεξεργασία των εισερχόμενων δεδομένων. Επίσης ο προγραμματιστής μπορεί να επεκτείνει την λειτουργικότητα της υπηρεσίας δημιουργώντας δικά του modules με την γλώσσα Java ή Python. Τα τελικά προγράμματα αποθηκεύονται υπό την μορφή JSON αρχείου τοπικά[40]. Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

28 Node-RED Εικόνα 4.6: Το execution μοντέλο του Wotkit[40,42] Το Νode-RED είναι ένα visual εργαλείο προγραμματισμού με σκοπό την εύκολη διασύνδεση συσκευών, API, και διαδικτυακών υπηρεσιών. Διαθέτει ένα browser based γραφικό περιβάλλον για την δημιουργία εφαρμογών (flows). Για την δημιουργία των εφαρμογών χρησιμοποιούνται nodes, αυτόνομα instances ενός script, τα οποία πάντα υλοποιούν μία καλά καθορισμένη λειτουργία. Για την μεταφορά πληροφορίας από ένα node στο άλλο χρησιμοποιούνται wires τα οποία υποδηλώνουν την ροή της πληροφορίας γραφικώς [43], όπως διαφαίνεται στην εικόνα 4.7. Εικόνα 4.7: Παράδειγμα flow σε Node-RED[43] Το εργαλείο είναι γραμμένο σε Javascript και Node.js και χρησιμοποιεί το threading μοντέλο της Node.js, όπως παραθέτουμε στην εικόνα 4.8. Το Node-RED δεν είναι δημιουργημένο Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

29 ΤΕΧΝΟΛΟΓΊΕΣ ΑΙΧΜΉΣ 21 αποκλειστικά με σκοπό την δημιουργία mashup για ΙοΤ, αλλά αποσκοπεί στην δημιουργία web mashup ευρύτερα. Παρόλα αυτά, διαθέτει node για MQTT και HTTP που κάνει την επικοινωνία με συσκευές ΙοΤ αρκετά εύκολη. Μαζί με το εργαλείο περιλαμβάνονται πολλά nodes για διαφορετικές χρήσεις, με τα κυριότερα να αφορούν την επικοινωνία HTTP, MQTT, function nodes για την άμεση επεξεργασία δεδομένων και debug node για debugging. Επίσης έχει δημιουργηθεί ένα μεγάλο ευρετήριο με open source nodes δημιουργημένα από το community. Εικόνα 4.8: To execution μοντέλο του Node-RED[44] Ο προγραμματιστής μπορεί εύκολα να επεκτείνει την λειτουργικότητα του εργαλείου δημιουργώντας τα δικά του nodes σε Javascript και Node.js. Οι εφαρμογές αποθηκεύονται τοπικά σε μορφή JSON. Το Node-RED είναι open source και δωρεάν προς χρήση[43] Losant To Losant είναι μία πλατφόρμα σύννεφου η οποία χρησιμοποιεί ένα γραφικό περιβάλλον όμοιο του Node-RED για την δημιουργία εφαρμογών. Η πλατφόρμα επεκτείνει την ιδέα του Node-RED συνδυάζοντας το με άλλα γραφικά εργαλεία όπως visualizers για την απεικόνιση δεδομένων και πληροφοριών[46]. Παράδειγμα της δικτυακής τοπολογίας παραθέτουμε στην εικόνα 4.9. Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

30 22 Εικόνα 4.9: Τοπολογία δικτύου σε Losant[45] Το Losant χρησιμοποιεί και αυτό ένα σύστημα σαν τα nodes, όπου κάθε γραφική απεικόνιση αναπαριστά μια καλά καθορισμένη λειτουργία, και η χρήση wires υποδηλώνει την μεταφορά πληροφορίας, όπως φαίνεται στην εικόνα Σε αντίθεση με το Node-RED όμως δεν φαίνεται να επιτρέπει την επέκταση του εργαλείου, αλλά διαθέτει ένα μεγαλύτερο εύρος λειτουργιών. Υποστηρίζεται επικοινωνία με MQTT και HTTP, εργαλεία για την δημιουργία dashboards (γραφικά περιβάλλοντα απεικόνισης πληροφοριών) αλλά και αυξημένα μέτρα ασφαλείας για τους προγραμματιστές και το deployment των εφαρμογών. Η πλατφόρμα διαθέτει SDK για Arduino και συσκευές που τρέχουν Node.js[47]. H πλατφόρμα διαθέτει ένα δωρεάν πρόγραμμα με περιορισμό συσκευών και μηνυμάτων, χωρίς να αναφέρεται η πιθανότητα για κάποιο ακαδημαϊκό πρόγραμμα[46]. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

31 NODE.JS & NODE-RED 23 Εικόνα 4.10: Παράδειγμα εφαρμογής σε Losant[45] 5 NODE.JS & NODE-RED Για την ορθή χρήση του γραφικού εργαλείου Node-RED, με σκοπό τον σχεδιασμό υπηρεσιών απαιτείται κατανόηση των βασικών αρχών που απαρτίζουν το εργαλείο. Πιο συγκεκριμένα απαιτείται κατανόηση της λειτουργίας του Node.js, δηλαδή του threading μοντέλου του καθώς και του event driven κώδικα του. Για τη χρήση του Node-RED ακόμα αναγκαία είναι η γνώση των επιμέρους στοιχείων του, δηλαδή των nodes, flows και τον τρόπο δημιουργίας Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

32 24 τους. Σε αυτό το κεφάλαιο γίνεται ανάλυση κάθε απαραίτητου τμήματος για την ευκολότερη συγγραφή υπηρεσιών με το Node-RED. 5.1 Node.js Η Node.js[47] είναι μία πλατφόρμα υλοποιημένη πάνω στην Javascript Runtime Engine, Google V8 Engine η οποία συνοδεύεται με την πλατφόρμα. Σκοπός της, είναι η εύκολη δημιουργία γρήγορα εκτελέσιμων και κλιμακούμενων εφαρμογών. Η πλατφόρμα χρησιμοποιεί Event Driven programming με non-blocking I/O μοντέλο, στοιχείο που την καθιστά «ελαφριά» και αποδοτική σε εφαρμογές που εκτελούνται σε κατανεμημένες συσκευές. Η Node.js είναι Open Source, και cross platform[48], δηλαδή μπορεί να εκτελεστεί σε Microsoft Windows, Apple OS και Linux. Χρησιμοποιούμενη γλώσσα προγραμματισμού είναι η Javascript. Μαζί με την Node.js συνοδεύονται modules για την διευκόλυνση της δημιουργίας εφαρμογών. Σήμερα, η πλατφόρμα χρησιμοποιείται κυρίως για τον προγραμματισμό web server καθώς και desktop εφαρμογών μέσω του Electron Framework[49]. Η Node.js χωρίζεται στα παρακάτω τμήματα, όπως φαίνεται και στην εικόνα 5.1 [50]: Node.js Core: Τμήμα με τις βασικές λειτουργίες που προσφέρει η πλατφόρμα στον προγραμματιστή, γραμμένα σε Javascript. Τα τμήματα αυτά εμπεριέχουν βασικές εντολές Ι/Ο και διαχείρισης του περιβάλλοντος της Node.js. Node.js Bindings: Τμήμα με την λειτουργία επικοινωνίας μεταξύ του κώδικα της μηχανής V8 τα οποία έχουν προγραμματισθεί με την γλώσσα C++. Google V8: Τμήμα εκτέλεσης λειτουργιών σχετικές με το rendering της Javascript. Γραμμένη σε C++, εδώ συναντάμε την Javascript Engine, τον optimizer και τον Just in Time Compiler (JIT). Libuv: Βιβλιοθήκη γραμμένη σε C, η οποία διαχειρίζεται το ασύγχρονο non blocking I/O μοντέλο της πλατφόρμας, με την κατάλληλη και αυτόματη δημιουργία και καταστροφή νημάτων (threads) για την εκτέλεση των blocking εντολών. Εικόνα 5.1: Γραφική απεικόνιση της δομής της Node.js[50] Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

33 NODE.JS & NODE-RED Η μηχανή απόδοσης Javascript: V8 Η Javascript rendering engine[51], γνωστή ως Chrome V8 (ή αλλιώς V8) αποτελεί προϊόν του The Chromium Project [51] με σκοπό την χρήση της στον περιηγητή Google Chrome. Δημιουργήθηκε από τον Lars Βak[52] και την ομάδα του Chromium Project, και δημοσιεύθηκε για πρώτη φορά στις 2 Σεπτεμβρίου 2008[51], μαζί με την δημοσίευση του περιηγητή Google Chrome. Η μηχανή V8 κάνει compile Javascript κώδικα απευθείας σε γλώσσα μηχανής[51] πριν την εκτέλεση του. Έπειτα ο δημιουργούμενος κώδικας μηχανής, γίνεται optimize δυναμικώς κατά την εκτέλεση, χρησιμοποιώντας heuristics από το προφίλ εκτέλεσης του[51]. Άλλες rendering μηχανές που συναντώνται σήμερα στην αγορά είναι: Η Chakra[53] που χρησιμοποιείται από τον περιηγητή Internet Explorer και Edge[53], η Spidermonkey που χρησιμοποιείται στον Mozilla Firefox[53] και η Nitro που υλοποιείται στον Safari[53]. Αξιοσημείωτο είναι το γεγονός ότι η Node.js είναι συμβατή μόνο με την μηχανή V Προγραμματισμός χειρισμού γεγονότων και το ασύγχρονο μοντέλο λειτουργίας Η Node.js χρησιμοποιεί το Event Driven μοντέλο σε συνδυασμό με την βιβλιοθήκη Libuv[54] για την εξασφάλιση ασύγχρονης εκτέλεσης και concurrency. Πιο συγκεκριμένα, ο κύριος τρόπος γραφής κώδικα είναι μέσω events. Για να επιτευχθεί αυτό, παρέχεται η Event Emitter Class[55], με την οποία μπορούμε να δημιουργήσουμε διαφόρων τύπων events. Κάθε δημιουργούμενο event προέρχεται από αυτή τη class, παράδειγμα του οποίου παραθέτουμε στην εικόνα 5.2. Εικόνα 5.2: Παράδειγμα δημιουργίας ενός Event στην Node.js[61] Η βιβλιοθήκη Libuv παρέχει την σημαντική λειτουργία διαχείρισης νημάτων για την εκτέλεση blocking εντολών εκτός του κυρίου νήματος[54,56,57]. Η λειτουργικότητά της, περιλαμβάνει την προσφορά και διαχείριση ενός δυναμικού thread pool[54,56,57], στο οποίο ο προγραμματιστής μπορεί να ορίσει τον μέγιστο αριθμό νημάτων, αλλά δεν μπορεί να επέμβει στον τρόπο διαχείρισης του. Επομένως κάθε φόρα που αναγνωρίζεται κάποια I/O εντολή στον κώδικα του προγραμματιστή(πχ. διάβασμα αρχείου, εντολές networking κτλ.), η εντολή δεν εκτελείται στο κύριος νήμα (main thread) αλλά σε ένα από τα ελεύθερα νήματα που παρέχει η Libuv. Όταν ολοκληρωθεί η εκτέλεση του κώδικα τα αποτελέσματα δηλώνονται μέσω μιας callback σε μία Event Loop. Η λειτουργία αναλύεται γραφικά στην εικόνα 5.3. Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

34 26 Εικόνα 5.3: Διάγραμμα μετάβασης από Javascript σε C++ Libuv εκτέλεση[62] Το Event Loop της Node.js Το Event Loop[58] της Node.js αποτελεί το κυριότερο κομμάτι της πλατφόρμας. Είναι το στοιχείο που επιτρέπει στον προγραμματιστή να εκτελέσει non blocking I/O κώδικα παρά το γεγονός ότι η γλώσσα Javascript τρέχει αποκλειστικά σε ένα thread. Το Event Loop αποτελείται από 6 φάσεις όπως διακρίνονται και στην εικόνα 5.4. Κάθε μία από αυτές αποτελείται από μια λίστα η οποία πληροί το First in First out σενάριο, δηλαδή το πρώτο αντικείμενο που καταχωρείται στην λίστα είναι και το πρώτο που θα επεξεργασθεί.[58] Στην Node.js αυτές οι λίστες περιέχουν callbacks από κομμάτια κώδικα τα οποία έχουν εκτελεσθεί ασύγχρονα και πρέπει να τελειώσει η επεξεργασία τους. Όταν το Event Loop βρίσκεται σε μία από τις έξι φάσεις, εκτελεί σύγχρονα κατά σειρά προτεραιότητας τις δηλωμένες callbacks ως ότου εκτελεσθούν όλες, ή εκτελεσθεί το μέγιστο όριο του αριθμού των επιτρεπόμενων callbacks[58]. Κάθε μία από τις φάσεις έχει ευθύνη για την εκτέλεση διαφορετικού είδους callback, στοιχείο που διαχωρίζεται από το είδος του κώδικα που καλεί αυτή τη callback. Πιο συγκεκριμένα: Timers Φάση: Εκτελεί callbacks η οποίες αφορούν χρονικά προγραμματισμένες εντολές, (π.χ. εκτέλεση μετά από 15 δευτερόλεπτα). Συνήθως αυτές οι callbacks καλούνται από τις εντολές SetInterval και SetTimeout[58]. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

35 NODE.JS & NODE-RED 27 I/O Callbacks Φάση: Σε αυτή τη φάση εκτελούνται όλες οι callbacks οι οποίες πηγάζουν από σφάλματα του συστήματος.[49] Idle,Prepare Φάση: Χρησιμοποιείται μόνο εσωτερικά στη πλατφόρμα[58]. Poll Φάση: Σε αυτή τη φάση γίνεται η λήψη νέων I/O events callbacks[58]. Check Φάση: Εκτελούνται callbacks που καλέστηκαν από την εντολή setimmediate[58]. Close Callbacks Φάση: Εδώ εκτελούνται όλες οι callbacks που είναι δηλωμένες και καλεσμένες από κάποιο close event[58]. Πριν την εκτέλεση του Event Loop κάθε φορά, η πλατφόρμα ψάχνει, εάν αναμένονται αποτελέσματα από κάποιο I/O event ή χρονόμετρο. Σε περίπτωση που δεν αναμένεται, διακόπτεται η λειτουργία της και τερματίζεται το πρόγραμμα[57]. Εικόνα 5.4: Οι έξι φάσεις λειτουργίας της Event Loop[60] Για να εισάγουμε callbacks στην Event Loop, αρκεί να χρησιμοποιήσουμε ένας από τους παρακάτω τρόπους[4]. Ορίζοντας callback στις εντολές settimeout ή setinterval. Αυτές οι callbacks θα εισαχθούν στην λίστα της φάσης Timers. Ορίζοντας callback στην εντολή process.nexttick. Ορίζοντας callback σε κάποια ασύγχρονη I/O εντολή μέσω του API της Libuv. Ορίζοντας callback στην εντολή process.nexttick. Με αυτή την εντολή όλες οι εντολές που ορίστηκαν στην callback εκτελούνται σύγχρονα στο τέλος του Event Loop και πριν την επόμενη επανάληψη της εκτέλεσής του. Μέσω Promises (microtasks). Κάθε άλλος κώδικας ο οποίος δεν είναι δομημένος ώστε να εκτελεστεί ασύγχρονα, εκτελείται σύγχρονα από το κυρίως νήμα της Node.js. Τελικώς, για να εκτελεστεί το Event Loop θα πρέπει να έχουν ολοκληρωθεί όλες οι σύγχρονες εντολές του κύριου νήματος[57,58]. Αυτό Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

36 28 μπορούμε να το επιβεβαιώσουμε, εκτελώντας σύγχρονα μια blocking εντολή στο κυρίως νήμα. Θα παρατηρήσουμε πως όλο το πρόγραμμα είναι blocked, και για να προχωρήσει πρέπει να ολοκληρωθεί η παραπάνω blocking εντολή. Αυτό μπορεί εύκολα να αιτιολογηθεί στο γεγονός πως η Javascript είναι single threaded και το Event Loop, επομένως, τρέχει και αυτό στο κυρίως νήμα. Επομένως από τα παραπάνω μπορούμε εύκολα να κατανοήσουμε την σειρά εκτέλεσης εντολών καθώς και αν θα εκτελεσθούν στο κύριο νήμα ή σε κάποιο νήμα της Libuv. 5.2 Node-RED Το Νode-Red είναι ένα visual εργαλείο προγραμματισμού με σκοπό την εύκολη διασύνδεση συσκευών, API, και διαδικτυακών υπηρεσιών[63]. Διατίθεται δωρεάν από την IBM[64] και την οργάνωση JS Foundation [65] ως open-source software[66]. Για την δημιουργία των εφαρμογών χρησιμοποιείται flow based programming, δηλαδή η αναπαράσταση των λειτουργιών ως ένα μαύρο κουτί, ή αλλιώς nodes όπως τα ονομάζει το Node-RED. Κάθε node, παρέχει μια συγκεκριμένη και καλά καθορισμένη λειτουργία, δηλαδή δεδομένου εισερχόμενων δεδομένων σε ένα node, αυτά επεξεργάζονται και προωθούνται στο επόμενο node. Το συγκεκριμένο καθιστά την δημιουργία εφαρμογών ευκολότερη από παραδοσιακές τεχνικές, καθώς ο χρήστης δίνει περισσότερη έμφαση στην διασύνδεση λειτουργιών παρά την παραγωγή κώδικα. Επίσης η γραφική απεικόνιση των λειτουργιών καθιστά την ανάγνωση και κατανόηση μιας εφαρμογής αρκετά πιο εύκολη από την ανάγνωση πολλών σελίδων κώδικα. Το Node-RED έχει υλοποιηθεί πάνω στο Node.js, και επομένως διατίθεται ως πακέτο του δημοφιλή packet manager NPM Δημιουργία εφαρμογών με Node-RED Για την δημιουργία εφαρμογών χρησιμοποιούνται τα flows. Κάθε flow περιέχει μια σειρά από nodes, που αναπαριστούν ξεχωριστές λειτουργίες. Αυτά τα nodes συνδέονται γραφικώς με καλώδια για να δηλώσουν την κατεύθυνση πληροφορίας. Σε αυτό το κεφάλαιο γίνεται αναφορά στις underlying λειτουργίας των nodes,wires και flows Nodes Η δομή του κάθε node απαρτίζεται από 2 αρχεία. Ένα αρχείο HTML το οποίο δημιουργεί την γραφική απεικόνιση στον editor, και ένα αρχείο Javascript με την λειτουργία του. Για την δημιουργία τις λειτουργίας του node, αρχικά πρέπει να γίνει wrap του κώδικα ως ένα Node.js module. Χρησιμοποιώντας ως παράμετρο το RED για την δημιουργούμενη μέθοδο, αποκτάμε πρόσβαση στο Node-RED runtime API. Επόμενο βήμα είναι ο ορισμός της πρακτικής λειτουργίας του node. Πρώτα πρέπει να ορίσουμε τα βασικά στοιχεία του node μέσω της εντολής RED.nodes.createNode. Ύστερα μπορούμε να χρησιμοποιήσουμε τα βασικά στοιχεία ενός node για να διαμορφώσουμε την συμπεριφορά του. Πιο συγκεκριμένα ορίζουμε ένα eventlistener στο event input με μια callback, δηλαδή δηλώνουμε πως όταν το node μας δεχτεί ένα μήνυμα, θα εκτελέσει την λειτουργία τις callback. Τελικώς το μόνο που έμεινε για την ολοκλήρωση του αρχείου, είναι η δήλωση του στο Node-RED Runtime. Αυτό γίνεται με την εντολή RED.nodes.registerType( name,function), οπού name είναι το όνομα με το οποίο δηλώνουμε το node, και function, η μέθοδος εκτελεί το node όταν καλεστεί. Παράδειγμα για την ανάπτυξη ενός απλού node φαίνεται στην εικόνα 5.5. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

37 NODE.JS & NODE-RED 29 Εικόνα 5.5: Παράδειγμα δημιουργίας του Javascript αρχείου του Lower Case Node[67] Για να εμφανίσουμε την node στον editor και να το χρησιμοποιήσουμε στα flow μας, πρέπει ακόμα να ορίσουμε το HTML αρχείο του. Σημαντικό είναι να χρησιμοποιήσουμε στην δήλωση του node στο HTML το ίδιο όνομα, με αυτό που χρησιμοποιήθηκε στο Javascript αρχείο, ώστε να γίνει σύνδεση των δυο αρχείων όπως φαίνεται στην εικόνα 5.6. Εικόνα 5.6: Παράδειγμα δημιουργίας του HTML αρχείου του Lower Case Node[67] Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

38 30 Τέλος για την οριστικοποίηση του node, πρέπει να δηλώσουμε κατάλληλα το node μας στο αρχείο package.json. Αυτό το αρχείο είναι που δηλώνει στο runtime, ποια είναι τα αρχεία που αντιστοιχούν στο node που δημιουργήσαμε ώστε να τα αναζητήσει και να τα εκτελέσει. Παράδειγμα ενός τέτοιου αρχείου παρατίθεται στην εικόνα 5.7. Ο χρήστης πέρα από την ανάπτυξη των δικών του nodes, έχει στην διάθεσή του ένα πλήθος από έτοιμα nodes από το community μέσω του packet manager NPM. Εικόνα 5.7: Παράδειγμα δημιουργίας του package.json αρχείου του Lower Case Node[67] Flows Για την δημιουργία flows γίνεται χρήση του browser editor. Εκτελώντας την εντολή node-red στο command line prompt, μπορούμε να βρούμε τον editor στην τοποθεσία localhost:1880. Στον editor εύκολα διακρίνουμε τα παρακάτω εργαλεία, ο οποίος απεικονίζεται στην εικόνα Διαθέσιμα για χρήση Nodes 2. Flow Tabs: κάθε tab περιέχει το δικό του flow. 3. Info Tab: Στοιχεία του επιλεγμένου node. Συνήθως περιλαμβάνει πεδία για την εισάγει παραμέτρων, καθώς και βασικές οδηγίες χρήσης. 4. Debug Tab: Κονσόλα με όλα τα μηνύματα που εκτυπώνονται από Debug Node. 5. Deploy Button: Το κουμπί με το οποίο εκτελούμε τα flows. 6. Options Menu. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

39 NODE.JS & NODE-RED 31 Εικόνα 5.8: Γραφικό περιβάλλον του Node-RED Για να εισάγουμε ένα node στο flow μας, αρκεί να επιλέξουμε και να σύρουμε το node που επιθυμούμε. Άμεσα διακρίνουμε δύο άσπρες βούλες στα άκρα αυτού. Η αριστερή βούλα υποδηλώνει την είσοδο, και η δεξιά την έξοδο. Για το παράδειγμά μας, ας εισάγουμε ένα inject node, ένα function node, και ένα debug node. Ύστερα με κλικ την έξοδο του inject μπορούμε να το ενώσουμε με το function node, και την έξοδο του function node με το debug node. Το παράδειγμα παρατίθεται και στην εικόνα Εικόνα 5.9: Παράδειγμα Flow σε Node-RED To inject node, εκτελείται με το deploy, και στέλνει στην έξοδο του ένα μήνυμα με περιεχόμενο το timestamp της χρονικής στιγμής εκτέλεσης. Το function node μας δίνει την δυνατότητα να εκτελέσουμε δικό μας κώδικα (σε περίπτωση που δεν θέλουμε να αναπτύξουμε ένα δικό μας node από την αρχή) και το debug node εκτυπώνει τα μηνύματα που λαμβάνει στην κονσόλα. Πατώντας το κουμπί deploy διαπιστώνουμε την εκτύπωση του μηνύματος timestamp στην κονσόλα. Ειδικότερα κατά την εκτέλεση, έγινε instantiation των nodes μέσω των δηλωμένων μεθόδων, και για τα nodes με είσοδο (στην περίπτωση μας function node και debug node) ορίστηκαν eventlisteners στο input event. Όταν το μήνυμά Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

40 32 μας έφτασε σε ένα από τα nodes (γραφικώς μέσω του καλωδίου ένωσης) εκτελέστηκε η callback του event. Για την υλοποίηση των καλωδίων η Node-RED χρησιμοποιεί μια λίστα μηνυμάτων, και υλοποιεί το publish subscribe pattern, για την ενημέρωση των καταλλήλων nodes. Ο χρήστης δεν έχει πρόσβαση σε αυτή τη λίστα. Αξιοσημείωτο είναι πως για να σταματήσουμε την εκτέλεση της εφαρμογής πρέπει να κάνουμε deploy ένα κενό flow ή να κλείσουμε την εφαρμογή node-red από το command prompt. Επίσης υπάρχει η δυνατότητα για απομακρυσμένου deploy ενός flow μέσω παρεχόμενου REST API. 6 ΣΥΝΘΕΣΗ ΥΠΗΡΕΣΙΩΝ ΔΙΑΔΙΚΑΣΙΑΣ ΠΑΡΑΓΩΓΗΣ ΜΕ ΤΗΝ ΧΡΗΣΗ NODE-RED 6.1 Μελέτη Περίπτωσης: Liqueur Plant Σκοπός του συστήματος είναι η παραγωγή Liqueur[81] σύμφωνα με οδηγίες του χρήστη. Για να επιτευχθεί αυτό, το σύστημα διαθέτει 4 σιλό, το καθένα με τις δικές του λειτουργίες. Αυτά τα σιλό μεταφέρουν Liqueur μέσω ενός κοινού σωλήνα (pipe) κατά την επεξεργασία. Επίσης διατίθεται ένας μετρητής κατανάλωσης ενέργειας στην περίπτωση που γίνεται ανάμειξη(mix) Liqueur από κάποιο σιλό[83,84]. Κάθε σιλό διαθέτει και μπορεί να εκτελέσει συγκεκριμένες λειτουργίες[83,84]. Ειδικότερα: Το σιλό 1 (Silo1): μπορεί να γεμίσει και να αδειάσει τα περιεχόμενα του. Το σιλό 2 (Silo2): μπορεί να γεμίσει, να αδειάσει και να θερμάνει μέχρι μίας συγκεκριμένης θερμοκρασίας, τα περιεχόμενά του. Το σιλό 3 (Silo3): μπορεί να γεμίσει, να αδειάσει, και να αναμείξει για συγκεκριμένο χρόνο τα περιεχόμενα του. Το σιλό 4 (Silo4): μπορεί να γεμίσει, να αδειάσει, να αναμείξει για συγκεκριμένο χρόνο, και να θερμάνει μέχρι μίας συγκεκριμένες θερμοκρασίας, τα περιεχόμενά του. Κάθε σιλό διαθέτει δύο βαλβίδες οι οποίες ελέγχουν την ροή του Liqueur στην είσοδο και έξοδο του. Επίσης χρησιμοποιούνται δυο αισθητήρες που ελέγχουν αν το σιλό θεωρείται γεμάτο ή άδειο. Για τα σιλό που έχουν την ικανότητα να θερμάνουν τα περιεχόμενα του, Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

41 ΣΎΝΘΕΣΗ ΥΠΗΡΕΣΙΏΝ ΔΙΑΔΙΚΑΣΊΑΣ ΠΑΡΑΓΩΓΉΣ ΜΕ ΤΗΝ ΧΡΉΣΗ NODE-RED 33 διατίθενται αντιστάσεις, ενώ για τα σιλό που μπορούν να αναμείξουν, υπάρχει ένα μίξερ εγκατεστημένο. Η λειτουργίας που μελετάται στο Case Study είναι: Το Silo1 γεμίζει και μεταφέρει το Liqueur στο Silo4, στο οποίο το Liqueur αναμιγνύεται και θερμαίνεται. Αφού ολοκληρωθεί αυτή η διεργασία, το σιλό αδειάζει τα περιεχόμενα του και ολοκληρώνεται η διαδικασία παραγωγής του Type A Liqueur. Παράλληλα, εκτελείται και η παραγωγή Type B Liqueur. Σε αυτή τη διαδικασία, αρχικά το Silo2 γεμίζει, και θερμαίνει τα περιεχόμενά του μέχρι μιας παρεχόμενης θερμοκρασίας. Ύστερα μεταφέρει το Liqueur στο Silo3, όπου γίνεται ανάμειξη των περιεχομένων και έπειτα άδειασμα, ολοκληρώνοντας την διαδικασία παραγωγής του Type B Liqueur. Περιορισμοί του συστήματος συναντώνται στων σωλήνα μεταφοράς και στον μετρητή κατανάλωσης ενέργειας. Μέσω του σωλήνα μπορεί να μεταφέρεται μόνο ένα είδος Liqueur κάθε φορά. Επίσης, μόνο ένα σιλό μπορεί να εκτελεί ανάμειξη κάθε φορά σύμφωνα με τον μετρητή κατανάλωσης. Ακολουθεί γραφική απεικόνιση του προβλήματος στην εικόνα 6.1. Εικόνα 6.1: Διάγραμμα διασύνδεσης των σιλό του Liqueur Plant[68] Τα smart silo υλοποιούνται με την χρήση microcontrollers (πχ. Raspberry Pi, Arduino κ.α.) και δύναται να εκμεταλλευτούν πλήρως τα φυσικά στοιχεία (actuators & switches) των silo, και να τα ελέγξουν κατά βούληση. Μια έκδοση υλικού έχει υλοποιηθεί ως μέρος του project UML4IOT [69]. Η έκδοση αυτή διαθέτει[70] : Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

42 34 Απεικόνιση 2 ψηφίων για την ένδειξη της θερμοκρασίας Μετρητή πληρότητας για την απεικόνιση της κατάστασης full & empty Λάμπες LED για την ένδειξη των καταστάσεων των InValve & outvalve LED για την απεικόνιση λειτουργίας του Heater LED για την απεικόνιση λειτουργίας του Mixer Buzzer για την ηχητική απεικόνιση λειτουργίας του Mixer Στην εικόνα 6.2 μπορεί να παρατηρηθεί με λεπτομέρεια η παραπάνω υλοποίηση. Εικόνα 6.2: Αναπαράσταση της hardware υλοποίησης του silo.[70] Στο case study γίνεται η υπόθεση πως η απόσταση των σιλό μεταξύ τους αλλά και των σιλό με το hardware που τρέχει την εφαρμογή των δύο διαδικασιών, είναι αρκετά μεγάλη, τέτοια ώστε κρίνεται απαραίτητη η χρήση ενός δικτύου για την επικοινωνία τους[71,83,84]. Στην εικόνα 6.3 αποτυπώνεται ένα use case για την προαναφερόμενη υλοποίηση, το οποίο εκμεταλλεύεται το διαδίκτυο και το «σύννεφο». Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

43 ΣΎΝΘΕΣΗ ΥΠΗΡΕΣΙΏΝ ΔΙΑΔΙΚΑΣΊΑΣ ΠΑΡΑΓΩΓΉΣ ΜΕ ΤΗΝ ΧΡΉΣΗ NODE-RED 35 Εικόνα 6.3: Διάγραμμα πλήρης δικτύωσης του Liqueur Plant μέσω internet & cloud.[71,85] 6.2 Λειτουργικές Προδιαγραφές του Συστήματος Αρχικά η εφαρμογή που θα ελέγχει και εκτελεί την παραγωγή Liqueur πρέπει να τρέχει στο ίδιο δίκτυο με τα σιλό, δηλαδή τοπικά. Για λόγους ασφαλείας είναι σημαντικό η επικοινωνία τους να μην γίνεται μέσω του διαδικτύου. Επίσης σημαντική είναι η δυνατότητα να γίνεται έλεγχος της διεργασίας εκτός του τοπικού δικτύου, για την διευκόλυνση της εξυπηρέτησης παραγγελιών χωρίς την παρουσία κάποιου χρήστη να τις εισάγει και εκτελεί χειροκίνητα. Όσον αφορά το process λειτουργίας είναι σημαντικό κάθε σιλό να μπορεί να εκτελέσει της λειτουργίες του ανεξάρτητα το στάδιο επεξεργασίας των υπολοίπων σιλό. Δηλαδή αν το Silo1 είναι άδειο, ενώ το Silo4 επεξεργάζεται τα περιεχόμενα του, το Silo1 πρέπει να έχει την δυνατότητα να γεμίζει. Η συμπεριφορά που ζητείται μπορεί να παρατηρηθεί σε μεγαλύτερη λεπτομέρεια στις εικόνες 6.4 και 6.5. Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

44 36 Εικόνα 6.4: UML διάγραμμα καταστάσεων της διαδικασίας Type A Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

45 ΣΎΝΘΕΣΗ ΥΠΗΡΕΣΙΏΝ ΔΙΑΔΙΚΑΣΊΑΣ ΠΑΡΑΓΩΓΉΣ ΜΕ ΤΗΝ ΧΡΉΣΗ NODE-RED 37 Εικόνα 6.5: UML διάγραμμα καταστάσεων της διαδικασίας Type B Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

46 38 Η συσκευές που ελέγχουν τα σιλό τρέχουν Leshan clients και αποτελούν προϊόν τρίτης διπλωματικής εργασίας[82]. Το Leshan είναι ένα implementation του πρωτόκολλου OMA light weight machine to machine σε Java. Επομένως απαραίτητο είναι το πρόγραμμα μας να ενσωματώνει το παραπάνω πρωτόκολλο για την σωστή επικοινωνία με τις συσκευές. 6.3 Εργαλεία Ανάπτυξης Σύμφωνα με την προηγούμενη έρευνα, καθώς και τις προδιαγραφές λειτουργίας επιλέχτηκε η πλατφόρμα Node.js σε συνδυασμό με το Node-RED Framework. Το Node-RED διευκολύνει την δημιουργία εφαρμογών, καθώς η δυνατότητα για γραφική απεικόνιση των λειτουργιών δύναται να οδηγήσει σε μια μορφή που πλησιάζει αρκετά την αρχικώς σχεδιασμένη μορφή του UML διαγράμματος. Ακόμα η δυνατότητα για εύκολη επεκτασιμότητα των λειτουργιών του συνεπάγεται την δυνατότητα δημιουργίας και ενσωμάτωσης του πρωτοκόλλου επικοινωνίας. Το Node-RED μας δίνει την ικανότητα να κάνουμε απομακρυσμένο deploy του προγράμματος μέσω του REST API του, στοιχείο που καθιστά την γεωγραφικά τοπική διαχείριση του συστήματος, μη απαραίτητη. Τέλος η πλατφόρμα μπορεί να λειτουργήσει πλήρως τοπικά και αυτόνομα, είτε σε έναν υπολογιστή ή σε έναν μικροϋπολογιστή (πχ. Raspberry Pi), στοιχείο που το καθιστά ασφαλές για την λειτουργίας του συστήματος, αφού δεν είναι απαραίτητη η σύνδεση με το διαδίκτυο. 7 ΑΝΑΠΤΥΞΗ ΤΟΥ LWM2M ΔΙΑΚΟΜΙΣΤΗ ΓΙΑ NODE-RED Σε αυτό το κεφάλαιο γίνεται πλήρης ανάλυση των βημάτων ανάπτυξης του LWM2M Server προς χρήση στην τελική εφαρμογή. Αρχικά γίνεται αναφορά στις ελάχιστες απαραίτητες λειτουργίες του server, και ύστερα αναλύεται η διαδικασία έρευνας και ανάπτυξης του προς ικανοποίηση της εφαρμογής μας. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

47 ΑΝΆΠΤΥΞΗ ΤΟΥ LWM2M ΔΙΑΚΟΜΙΣΤΉ ΓΙΑ NODE-RED Λειτουργικές Προδιαγραφές Ο server αρχικά πρέπει να μπορεί να λειτουργεί στο Node.js περιβάλλον για την ευκολότερη ενσωμάτωση με το Node-RED framework. Ακόμα απαραίτητη είναι η υποστήριξη του πρωτόκολλου LWM2M, το ίδιο spec με αυτό που τρέχουν τα Leshan devices ώστε να εξασφαλιστεί η ομαλή επικοινωνία με τις συσκευές. Με βάση αυτών ορίστηκαν ως οι ελάχιστες απαραίτητες λειτουργίες οι παρακάτω: Υποστήριξη OMA LWM2M Spec[72]. Διάθεση Registry για την σύνδεση και διαχείριση των συσκευών κατά την σύνδεση και διάρκεια λειτουργίας τους. Πρώτο βήμα, πριν ξεκινήσουμε να γράφουμε κώδικα, ήταν η έρευνα για κάποιο open source project που είχε τον ίδιο σκοπό με μας. Κατόπιν της αναζήτησης, βρέθηκαν τα project lw2mnode-lib[73] και coap-shepherd[74]. To επόμενο βήμα ήταν να εξετάσουμε την συμβατότητα τους με τις συσκευές Leshan, και σε περίπτωση ασυμβατότητες, η ανάλυση πιθανών διορθώσεων στον κώδικα ώστε να εξασφαλιστεί η ομαλή λειτουργία. Για τον έλεγχο της σωστής λειτουργίας, χρησιμοποιήσαμε τα Leshan Demo Client[75] και προσπαθήσαμε να ελέγξουμε τα παρακάτω στοιχεία: Αναγνώριση: Εάν η ο server αναγνώριζε την συσκευή χωρίς εντολή αναζήτησης της μέσω συγκεκριμένου coap url. Αυτόματη σύνδεση: Εάν ο η συσκευή συνδεόταν στον server και παρείχε σωστά και χωρίς απώλειες τα στοιχεία της (δηλαδή όνομα, port, url). Έλεγχος αποσύνδεσης: Ο server χρειάζεται να έχει την δυνατότητα να ελέγχει αν η συσκευή έχει αποσυνδεθεί ανά τακτά χρονικά διαστήματα ώστε να διαγράφεται από την λίστα συνδεδεμένων συσκευών. Ενημέρωση Κατάστασης: Ανά τακτά χρονικά διαστήματα ο server πρέπει να μπορεί να ελέγχει την συσκευή για τυχόν ενημερώσεις στα στοιχεία της. Επανασύνδεση: Ο server χρειάζεται να έχει την δυνατότητα να αναγνωρίζει μια επανασυνδεόμενη συσκευή σε περίπτωση που αυτή διέκοψε απρόσκοπτα την επικοινωνία της. 7.2 O διακομιστής coap-shepherd Το coap-shepherd project, είναι μια προσπάθεια για υποστήριξη και υλοποίηση του πρωτοκόλλου LWM2M μέσω coap, για Node.js, γραμμένο από τον χρήστη Github PeterEB. Χωρίζεται σε 2 sub projects, το coap-shepherd το οποίο περιέχει τον server κώδικα για την LWM2M διασύνδεση, και το node-coap το οποίο είναι μια βιβλιοθήκη για LWM2M clients. Σύμφωνα με το επίσημο documentation του project, υποστηρίζεται πλήρως το πρωτόκολλο LWM2M, όπως φαίνεται στην εικόνα 7.1. Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

48 40 Εικόνα 7.1: Η δικτύωση του coap-shepherd project[74] Αρχικά, ελέγξαμε τον τρόπο λειτουργίας και των δύο βιβλιοθηκών μεταξύ τους. Ειδικότερα, τρέξαμε τα demo που παρέχονται μαζί με τον κώδικα. Η σύνδεση ήταν επιτυχής, και όλες οι εντολές επικοινωνίας λειτούργησαν ομαλά χωρίς κανένα ίχνος προβλήματος. Επόμενο μας βήμα ήταν ο έλεγχος της επικοινωνίας Leshan Device με coap-shepherd server. Σε αυτό το σημείο η συμπεριφορά του προγράμματος δεν κύλησε ομαλά. Η συσκευή Leshan δεν αναγνωριζόταν καθόλου από τον server παρά τις όποιες προσπάθειες για την επικοινωνία τους. Αποφασίσαμε να ελέγξουμε τον source κώδικα, με σκοπό την εύρεση του προβλήματος και αποκατάστασης της σωστής διασύνδεσης. Το πρόβλημα αρχικά έδειχνε να οφείλεται στην μη υποστήριξη των ίδιων content-formats μεταξύ διακομιστή και συσκευής. Διορθώνοντας το περιεχόμενο επικοινωνίας το πρόβλημα δεν λύθηκε. Κατόπιν λεπτομερής ανάγνωσης του κώδικα, διαπιστώθηκε πως η υποστήριξη του πρωτοκόλλου LWM2M ήταν ελλιπής σύμφωνα με το επίσημο specification, στοιχείο που καθιστούσε αδύνατη την επικοινωνία συσκευής και διακομιστή. Για την σωστή ενσωμάτωση, θα χρειαζόταν αναδιαμόρφωση μεγάλου μέρους του κώδικα, στοιχείο το οποίο απέκλεισε την χρήση του server στα πλαίσια αυτής της διπλωματικής. 7.3 Ο διακομιστής lwm2m-node-lib Το project lwm2m-node-lib είναι ένα project, δημιουργημένο από τον χρήστη Github telefonicaid. Προφέρει βιβλιοθήκες για την ανάπτυξη και χρήση LWM2M διακομιστών και συσκευών για Node.js. Σύμφωνα με το επίσημο documentation, υποστηρίζει το πρωτόκολλο LWM2M μέσω coap. Η παρεχόμενη υλοποίηση δεν είναι feature-complete, δηλαδή δεν έχουν υλοποιηθεί όλα τα στοιχεία του LWM2M, αλλά μόνο τα βασικά, όπως καταγράφεται στην εικόνα 7.3. Μαζί με τον κώδικα διανέμεται και demo. O server τρέχει σαν command line εφαρμογή και προσφέρει ένα εύρος εντολών για την διαχείριση του server, όπως παραθέτουμε στην εικόνα 7.2. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

49 ΑΝΆΠΤΥΞΗ ΤΟΥ LWM2M ΔΙΑΚΟΜΙΣΤΉ ΓΙΑ NODE-RED 41 Εικόνα 7.2: Command Line API του lwm2m-node-lib server[73] Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

50 42 Εικόνα 7.3: Υποστηριζόμενες λειτουργίες του lwm2m-node-lib[73] Εκτελώντας τον κώδικα για την τα demo διαπιστώσαμε την σωστή διασύνδεση και επικοινωνία διακομιστή και συσκευής, γεγονός αναμενόμενο. Η πραγματική πρόκληση ήταν η σωστή σύνδεση Leshan συσκευής με τον διακομιστή, την οποία ελέγξαμε και έπειτα. Πιο συγκεκριμένα κατά την πρώτη σύνδεση της συσκευής, το device registration γινόταν επιτυχώς. Η συσκευή εντασσόταν ομαλά στην device registry και είχαμε την δυνατότητα αποστολής εντολών. Δυστυχώς όμως, η συσκευή αποσυνδεόταν στον πρώτο έλεγχο σύνδεσης και ενημέρωσης (first heartbeat), καθιστώντας την συνεχής επικοινωνία με την συσκευή αδύνατη. Μέσω σχετικής έρευνας του κώδικα αλλά και των δηλωμένων προβλημάτων στην σελίδα υποστήριξης στο Github, βρήκαμε πως η αιτία αποσύνδεσης ήταν η ασυμβατότητα του πρωτοκόλλου (πρόβλημα #106 [76]). Πιο συγκεκριμένα επειδή η ανάπτυξη της βιβλιοθήκης είχε πάψει για πάνω από ένα έτος (κατά την διάρκεια συγγραφής της διπλωματικής εργασίας), το LWM2M spec είχε αλλάξει τον τρόπο διαχείρισης των ενημερώσεων. Κατά την προτεινόμενη λύση (εικόνα 7.4), αλλάξαμε την εντολή ενημέρωσης από coap PUT σε coap POST. Με την αλλαγή αυτή η συσκευή έμενε αναγνωρισμένη από τον server και όλες η λειτουργίες της registry δουλέψαν ομαλά. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

51 ΑΝΆΠΤΥΞΗ ΤΟΥ LWM2M ΔΙΑΚΟΜΙΣΤΉ ΓΙΑ NODE-RED 43 Εικόνα 7.4: Διόρθωση κώδικα για την ενημέρωση των συσεκυών στην registry[76] Επόμενο βήμα ήταν ο έλεγχος της σωστής επικοινωνίας συσκευής και διακομιστή όσο αφορά την ανταλλαγή δεδομένων. Εδώ παρουσιάστηκαν μεγαλύτερα προβλήματα. Σύμφωνα με το αρχείο ρυθμίσεων του διακομιστή, υποστηριζόταν η επικοινωνία με JSON, PLAIN TEXT και TLV. Τα επιστρεφόμενα δεδομένα όμως δεν αποκωδικοποιούνταν σωστά, στοιχείο που υπονοούσε προβλήματα στην υλοποίηση. Ερευνώντας τον κώδικα της βιβλιοθήκης παρατηρήσαμε πως η λεγόμενη υποστήριξη content-format, δεν είχε υλοποιηθεί κατάλληλα. Συγκεκριμένα απουσίαζε πλήρως η αποκωδικοποίηση TLV περιεχομένου, ενώ δεν είχε εισαχθεί ούτε η υποστήριξη JSON παρά το γεγονός ότι αποτελεί κομμάτι της Node.js core. Κανονικά, παρά τις παραπάνω ελλείψεις θα έπρεπε η επικοινωνία να έκανε default σε PLAIN TEXT. Για λόγο τον οποίο δεν γνωρίζουμε διαπιστώθηκε πως η Leshan συσκευές απαντούν πάντα με TLV, εκτός αν λάβουν συγκεκριμένη οδηγία για κάποιο άλλο content-format. Δηλαδή το content matching είναι ανύπαρκτο, και είναι στα χέρια του προγραμματιστή να ορίσει το περιεχόμενο χειροκίνητα σε κάθε εντολή. Προσθέτοντας σε κάθε εντολή την παράμετρο Accept: text/plain (εικόνα 7.5) και ορίζοντας το content format σε text/plain στο αρχείο ρυθμίσεων διορθώθηκε το πρόβλημα και τα δεδομένα αποκωδικοποιούνταν και απεικονίζονταν σωστά. Εικόνα 7.5: Παράδειγμα αλλαγής κώδικα για την σωστή υποστήριξη plaintext format Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

52 44 Έχοντας εξασφαλίσει την λειτουργία του server και της demo Leshan συσκευής, αποφασίσαμε να ελέγχουμε την συμβατότητα με τις δικές μας Leshan συσκευές. Με μια πρώτη ματιά, η λειτουργία ήταν ομαλή. Η σύνδεση όμως των συσκευών με άλλη σειρά δημιουργούσε προβλήματα ταυτότητας. Συγκεκριμένα ο server ήταν γραμμένος ώστε το αναγνωριστικό μιας συσκευής να είναι το id στην registry. Ο τρόπος υλοποίησης σήμαινε πως το id αυξανόταν σύμφωνα με την σειρά σύνδεσης των συσκευών, γεγονός που θα ανάγκαζε τον προγραμματιστή να γνωρίζει πληροφορίες για τον server που δεν θα είχε ποτέ πρόσβαση. Ακόμα, αν μια εφαρμογή χρησιμοποιούσε μια συσκευή και για κάποιο λόγο η συσκευή επανασυνδεόταν το id άλλαζε και η εφαρμογή δεν θα μπορούσε να την βρει. Προς επίλυση αυτού του προβλήματος, αποφασίσαμε να κρατήσουμε την χρήση των id για εσωτερική επικοινωνία των λειτουργιών του server με την registry του, και να δώσουμε την ικανότητα της αναζήτησης συσκευής στην registry μέσω του ονόματός της. Έτσι υλοποιήθηκε η συνάρτηση GetByName (εικόνα 7.6) και αντικατέστησε την προηγουμένως χρησιμοποιούμενη GetById. Με την αλλαγή αυτή, εξασφαλίστηκε η σωστή ταυτοποίηση της στοχεύομενης, από την εντολή, συσκευής και εξαλείφθηκαν τα προβλήματα δημιουργούμενα από την επανασύνδεσης συσκευών. Εικόνα 7.6: Υλοποίηση της μεθόδου getbyname Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

53 ΕΠΈΚΤΑΣΗ ΤΟΥ NODE-RED ΜΕ ΤΑ LWM2M NODES 45 8 ΕΠΕΚΤΑΣΗ ΤΟΥ NODE-RED ΜΕ ΤΑ LWM2M NODES Για την ορθή δόμηση των βασικών λειτουργιών του Mashup service, είναι απαραίτητη η δημιουργία nodes τα οποία υποστηρίζουν την αποστολή και λήψη δεδομένων με τις Leshan συμβατές συσκευές. Επομένως απαραίτητη είναι η εύρεση ή δημιουργία ενός node συμβατού με τα LWM2M specifications που χρησιμοποιεί και ο Leshan-compliant client. Σε αυτό το κεφάλαιο γίνεται περιγραφή της σχετικής έρευνας για κάποια community λύση, τα προβλήματα που αντιμετωπίστηκαν κατά τη διάρκεια της ανάπτυξης, και τελικώς στην ανάπτυξη των εκδόσεων του δικού μας node προς λύση του προβλήματος. 8.1 Προδιαγραφές Λειτουργίας Κάθε δημιουργούμενο Node, πρέπει να είναι καλά καθορισμένο. Δηλαδή, είναι απαραίτητο να εκτελεί μια καλά αποσαφηνισμένη λειτουργία, να είναι απλό στην χρήση αλλά και αρκετά ειδικευμένο ώστε να ταιριάζει στις απαιτήσεις του case study. Ακόμα αναγκαία είναι η ομαλή επικοινωνία με τις Leshan-συμβατές συσκευές. Κάθε συσκευή απαρτίζεται από συγκεκριμένα resources, τα οποία περιγράφονται σε ένα JSON αρχείο, αντικατοπτρίζοντας το URIPath που χρειαζόμαστε για την εκτέλεση λειτουργιών αλλά και τον έλεγχο μεταβλητών. Στην εικόνα 8.1 παρατηρούμε την δομή και οργάνωση του JSON αρχείου που χρησιμοποιείται στο case study μας. Κάθε resource απαρτίζεται από συγκεκριμένα πεδία (fields) τα οποία χαρακτηρίζονται από το id τους. Ακόμα περιλαμβάνει ένα όνομα για το resource, το είδος της διεργασίας (operation) και τα δεδομένα που δύναται να χρησιμοποιηθούν ως παράμετροι της εντολής. Εικόνα 8.1: Κομμάτι του JSON Resource αρχείου των Leshan συσκευών Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

54 46 Το Leshan υποστηρίζει format περιεχόμενου επικοινωνίας (content format) με τρείς τρόπους: Plaintext, JSON και TLV[77]. Κάθε ένα από αυτά φέρει τα δικά του πλεονεκτήματα. Επιλέξαμε να λειτουργήσουμε με Plaintext στο πρώτο στάδιο ανάπτυξης, καθώς θέλαμε να πετύχουμε γρηγορότερη απόκριση στο επίπεδο της εφαρμογής (οι μετατροπές, προς και από, JSON είναι αργές), ενώ το TLV δεν υποστηρίζεται ενδογενώς από την Node.js. Για να είναι το node και η λειτουργία του,lwm2m συμβατή, αναγκαίο είναι να πληροί συγκεκριμένες λειτουργικές προδιαγραφές. Πιο συγκεκριμένα πρέπει να ενσωματώνει μια σειρά εντολών, τις READ,WRITE,DELETE,OBSERVE,EXECUTE. Σχετικά με την εμφάνιση του Node, πρέπει να επιλέξουμε μια διακριτή ομαδοποιημένη εμφάνιση, στοιχείο που να υποδηλώνει οπτικά: Κατηγορία χρήσης: Είναι απαραίτητο ένας χρήστης της πλατφόρμας να μπορεί νοητικά να συνδέει την χρωματική εμφάνιση των nodesμας με ένα συγκεκριμένο πακέτο, ώστε εάν αλλάξει τα ονόματα των nodesνα είναι ακόμα εύκολα κατανοητό από ποια ομάδα προήλθε. Συμπεριφορά: Στην περίπτωση που το nodeμας, διαθέτει κάποια συμπεριφορά η οποία μπορεί να αλλάξει δυναμικά με την προτίμηση του χρήστη, πρέπει αυτή να φαίνεται στην απεικόνιση. Αυτό βοηθάει τον αναγνώστη της εφαρμογής να αποφεύγει την διερεύνηση όλων των παραθύρων επιλογών για κάθε node. Σαφείς οδηγίες χρήσης: Κάθε node διαθέτει ένα κομμάτι του παραθύρου των επιλογών του σε οδηγίες χρήσης. Πρέπει όλες οι επιλογές να είναι σαφείς, και η περιγραφή της λειτουργίας ακριβής, ώστε ο προγραμματιστής να διευκολυνθεί στην χρήση του node. Έχοντας ορίσει όλες τις παραπάνω λειτουργικές προδιαγραφές, μπορούμε οργανωμένα και μεθοδευμένα να αρχίσουμε την υλοποίηση των ίδιων των node. 8.2 Η ενσωμάτωση του LWM2M-Server Με τα παραπάνω χαρακτηριστικά αποφασίσαμε πρώτα να δημιουργήσουμε ένα LWM2M- Node, το οποίο στηρίζεται πάνω στον προαναφερόμενο LWM2M-Server. Ερευνώντας τον κώδικα του LWM2M-Server, παρατηρήσαμε πως οι εντολές για την εκτέλεση των βασικών λειτουργιών LWM2M που αναζητούσαμε υπήρχαν ήδη, απλά ο σκοπός τους ήταν χρήση τους σε εφαρμογές κονσόλας και όχι στο περιβάλλον του Node-RED. Επόμενο μας βήμα ήταν να δημιουργήσουμε νέες μεθόδους καθώς και να αναδιαμορφώσουμε τον ήδη υπάρχοντα κώδικα ώστε να μπορούμε να τον χρησιμοποιήσουμε στα nodes μας. Πιο συγκεκριμένα ο LWM2M-Server υποστήριζε τις εντολές: read, write, update, observe, delete, create, discover. Κάθε μια από αυτές αποτελεί και ένα Coap Request. Στην εικόνα 8.2 μπορούμε να παρατηρήσουμε μια πλήρη λίστα με τις υποστηριζόμενες εντολές. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

55 ΕΠΈΚΤΑΣΗ ΤΟΥ NODE-RED ΜΕ ΤΑ LWM2M NODES 47 Είκονα 8.2: Υποστηριζόμενες εντολές από τον LWM2M-Server[78] Οι παραπάνω εντολές είχαν διαμορφωθεί ώστε να χρησιμοποιηθούν σε εφαρμογή κονσόλας (console application), επομένως η εμφάνιση των περιεχομένων των response γινόταν με την εκτύπωση τους στην οθόνη. Χρησιμοποιώντας callbacks, αναδιαμορφώσαμε (refactor) τις εντολές για την χρήση τους στο LWM2M node. Εικόνα 8.3: Παράδειγμα αναδιαμόρφωσης κώδικα του LWM2M-Server για της εντολές του LWM2MRequest Στην εικόνα 8.3 παραθέτουμε ένα παράδειγμα της αναδιαμόρφωσης του κώδικα. Εύκολα παρατηρούμε τα εξής: επεκτάθηκε η υπογραφή της μεθόδου (method signature) ώστε να δέχεται ακόμα μία παράμετρο, μια callback μέθοδο (γραμμές 106,113,118). Με αυτόν τον τρόπο μπορούμε τώρα να ορίσουμε μια callback μέσα στον κώδικα του LWM2M-Node, η Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

56 48 οποία θα είναι και η τελική διαχείριση των αποτελεσμάτων του Read Request όπως παραθέτουμε στην εικόνα 8.4. Εικόνα 8.4: Παράδειγμα κώδικα για την περίπτωση της εντολής READ του LWM2M-Node. Ομοίως υλοποιήθηκαν και οι υπόλοιπες υποστηριζόμενες εντολές. Για τον ορισμό των παραμέτρων των εντολών στο γραφικό επίπεδο του node, ορίστηκαν τα κατάλληλα πεδία στο HTML αρχείο. Στις εικόνες 8.5 και 8.6 παραθέτουμε την εμφάνιση του του lwm2mrequest στο Node-RED editor, καθώς και την λεπτομερή απεικόνιση των παραμέτρων του. Εικόνα 8.5: Απεικόνιση του lwm2mrequest-node στον Node-RED editor Εικόνα 8.6: Παράθυρο παραμέτρων του lwm2mrequest-node στον Node-RED editor Μετά την δημιουργία του node, δημιουργήσαμε δοκιμαστικά flows, για να ελέγξουμε την ομαλή λειτουργία τους στο περιβάλλον του Node-RED. Σε αυτό το στάδιο παρατηρήθηκε πως υπήρχαν προβλήματα με τον τρόπο διαχείρισης των δεδομένων που επιστρέφονταν από την μέθοδο observe. Πιο συγκεκριμένα ένα κομμάτι του κώδικα, στο χαμηλότερο επίπεδο του Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

57 ΕΠΈΚΤΑΣΗ ΤΟΥ NODE-RED ΜΕ ΤΑ LWM2M NODES 49 LWM2M-Server, το informationreporting.js αρχείο, δηλαδή η βάση υλοποίησης των Observe Request, μπλόκαρε το Event Loop της Node.js σε εξαιρετικές περιπτώσεις, κάνοντας την εφαρμογή μας να παύει την λειτουργία χωρίς κάποιο error. Επειδή το πρόβλημα αυτό βρισκόταν σε αρκετά χαμηλό επίπεδο της ιεραρχίας του κώδικα, ο χρόνος για τον εντοπισμό του bug και τη διόρθωσή του ήταν μεγάλος. Ακόμα θα χρειαζόταν να ξαναγραφεί ένα σημαντικό μέρος του αρχικού κώδικα του LWM2M-Server για την υποστήριξη της διόρθωσης. Επομένως αποφασίσαμε να εξετάσουμε άλλες διόδους για την υλοποίηση ενός LWM2M-Node. 8.3 Η βιβλιοθήκη node-coap To Node-Coap είναι μια open-source βιβλιοθήκη, δημιουργημένη από τον χρήστη Github mcollina. Είναι γραμμένη για Node.js και ακολουθεί το μοντέλο του native http module της Node.js[76]. Το open-source node, το οποίο επιτρέπει την επικοινωνία μέσω του πρωτόκολλου coap ονομάζεται node-red-contrib-coap[80] και βασίζεται πάνω σε αυτήν την βιβλιοθήκη. Η βιβλιοθήκη ακολουθεί τα συγκεκριμένα specificationsγια την υποστήριξη του πρωτοκόλλου coap[79]: Coap Draft-18 Observe-11 Block-14 Για την χρήση της βιβλιοθήκης διατίθεται ένα καλά documented API, το οποίο βρίσκεται στο readmeαρχείο του Github. Στην εικόνα 8.7 παραθέτονται οι βασικές εντολές του API της βιβλιοθήκης. Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

58 50 Εικόνα 8.7: API της βιβλιοθήκης node-coap[80]. Η πιο σημαντική εντολή σε αυτό το API, η οποία αποτελεί και την βάση για κάθε είδους επικοινωνία στο επίπεδο του COAP, είναι η coap.request(). Η συγκεκριμένη εντολή δέχεται ένα αντικείμενο το οποίο διαθέτει όλες της παραμέτρους για το request, και επιστρέφει το εξερχόμενο request ως αντικείμενο. Διαθέτοντας το επιστρεφόμενο αντικείμενο, έχουμε την δυνατότητα να ορίσουμε events για την διαχείριση των δεδομένων. Πιο συγκεκριμένα χρησιμοποιώντας το coap.request.on( response,func) μπορούμε να επεξεργαστούμε το response χρησιμοποιώντας μια callback μέθοδο στην θέση της func. Στην περίπτωση που το request είναι για εντολή που διαθέτει bodypayload, διατίθεται η request.write(payload) με την οποία περνάμε στο bodypayloadτ ου request τα δεδομένα προς αποστολή. Τέλος για την εκτέλεση του request διατίθεται η εντολή request.end. Στην περίπτωση που στις παραμέτρους του request έχουμε ορίσει να γίνει observe, μαζί με το response επιστρέφεται και ένα stream, στο οποίο καταγράφονται και μεταδίδονται όλες οι αλλαγές στο Observed-Resource. Για να διαχειριστούμετα δεδομένα υπάρχει το event data το οποίο μας επιτρέπει επεξεργασία και διαχείριση για κάθε επιστρεφόμενο από το stream, δεδομένο. 8.4 Η υλοποίηση των LWM2M-Node Για την δημιουργία του νέου LWM2M-Node, πρώτα δημιουργήσαμε αρχικά ένα LWM2Mrequestnode, βασιζόμενο πάνω στην βιβλιοθήκη nodecoap. Το ονομάσαμε Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

59 ΕΠΈΚΤΑΣΗ ΤΟΥ NODE-RED ΜΕ ΤΑ LWM2M NODES 51 coaprequest και αποτέλεσε το καθοριστικό στοιχείο μας, για το αν η λειτουργία της βιβλιοθήκης θα εξυπηρετούσε τους στόχους μας στα πλαίσια του mashup. Για την υλοποίηση των εντολών ήταν απαραίτητη, η λήψη βασικών πληροφορίων για την συσκευή, όπως τη διεύθυνσή της. Αυτές οι πληροφορίες είναι αποθηκεύμενες στον LWM2M- Server και δημιουργήθηκαν κατά την πρώτη σύνδεση της συσκευής σε αυτόν, ενώ ανανεώνονται ανά τακτά χρονικά διαστήματα, πιο συγκεκριμένα σε κάθε heartbeat έλεγχο. Οι πληροφορίες που χρειαζόμαστε βρίσκονται αποθηκευμένες στα πεδία με όνομα deviceaddress και deviceport. Βάσει αυτού δημιουργήσαμε στον LWM2M-Server την εντολή gbn (ακρώνυμο για Get By Name). Αυτή η εντολή δέχεται ένα όνομα και μια callback σαν παραμέτρους και αναζητεί και επιστρέφει τα στοιχεία της συσκευής από την registry. Η callback χρησιμοποιείται για μια ακόμη φορά ως τρόπος επεξεργασίας των δεδομένων επιστροφής στο επίπεδο του node. Λαμβάνοντας τα στοιχεία της συσκευής, η δημιουργία και εκτέλεση ενός request αποτελεί απλά μια τυποποιημένη διαδικασία χρήσης του node-coap API. Στην εικόνα 8.8 παρατίθεται ένα κομμάτι του κώδικα του coaprequestnode, με έμφαση να δίνεται στην δομή των παραμέτρων (γραμμές 25-32) καθώς και η χρήση της gbn εντολής για την λήψη των στοιχείων της συσκευής από τον LWM2M-Server (γραμμές 34-41). Στην εικόνα 8.9 παρατηρούμε τις διαθέσιμες προς εισαγωγή παραμέτρους από το γραφικό περιβάλλον του Node-RED editor. Εικόνα 8.8: Κομμάτι κώδικα υλοποίησης του coap request node. Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

60 52 Εικόνα 8.9: Παράθυρο παραμέτρων του coap request node στον node-red editor. Με την ολοκλήρωση της υλοποίησης τρέξαμε τα ίδια δοκιμαστικά Flow με το LWM2M request node για να διαπιστώσουμε την σωστή λειτουργία του. Αυτή τη φόρα δεν συναντήθηκαν τα προβλήματα τα οποία αντιμετωπίσαμε νωρίτερα. Αντιθέτως, δημιουργήθηκαν νέα προβλήματα, τα οποία πήγαζαν από τον σχεδιασμό των nodes.πιο συγκεκριμένα: Το node μας χρειαζόταν αλλαγές ώστε να είναι ένα LWM2Mrequest, και όχι ένα coaprequestnode. Η διαχείριση του observereques tκαι του observerstream γινόταν στο ίδιο node, στοιχείο που το καθιστούσε δύσκολο στον σχεδιασμό ενός ευανάγνωστου flow. Οι παράμετροι που δεχόταν το node, ήταν γενικές, δηλαδή δεν ήταν αυστηρώς περιορισμένες στα πλαίσια του Μashup και των Liqueur-Plant συσκευών. Για αυτό τον σκοπό αποφασίσαμε την δημιουργία ενός set από nodes τα οποία βασίζονται σε αυτές τις διορθώσεις. Πιο συγκεκριμένα δημιουργήθηκε η node-red-contrib-plant συλλογή από nodes. Αυτή η συλλογή διαθέτει ένα node για κάθε λειτουργία(fill,heat,mix,empty) των σιλό, για κάθε σιλό (silo1, silo2, silo3, silo4). Ακόμα διαχωρίστηκε το observerequest με την διαχείριση του observestream σε δυο διαφορετικά nodes. Τώρα πια, τα nodes εντολών μπορούν να διαχειριστούν τα observestreams, ενώ η εντολή διαχείρισης του observation μπορεί να γίνει προηγουμένως σε άλλη φάση του flow. Για τον παραπάνω διαχωρισμό, υλοποιήθηκε μια λίστα από observerstreams με χαρακτηριστικό idτο resourceid/deviceport. Κάθε φορά που μια εντολή χρειάζεται να διαχειριστεί δεδομένα από ένα observestream, μπορεί αν ανατρέξει στην λίστα με όλα τα streams και να αξιοποιήσει κάποιο από αυτά. Η λίστα βρίσκεται στον server με το όνομα Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

61 ΕΠΈΚΤΑΣΗ ΤΟΥ NODE-RED ΜΕ ΤΑ LWM2M NODES 53 observerlist, και οι μέθοδοι διαχείρισης της είναι η addobserver και getobserver, την υλοποίηση των οποίων παραθέτουμε στην εικόνα Εικόνα 8.10: Εντολές διαχείρισης της λίστας observerlist Όσο αφορά το observenode, δέχεται το devicename και το resource path για observation και το stream επιστρεφόμενο στο response προστίθεται στην λίστα observerlist. Επόμενο βήμα, ήταν η υλοποίηση των εντολών για την διαχείριση των σιλό. Ειδικότερα δημιουργήσαμε μόνο τις απαραίτητες εντολές για την υλοποίηση των TypeA και TypeB process. Στο πίνακα 8.1 παραθέτουμε τις διαθέσιμες εντολές για κάθε σιλό. Silo1 Silo2 Silo3 Silo4 Pipe Power Fill Empty Stop Emptying Fill Empty Heat Stop Emptying Fill Empty Mix Stop Filling Fill Empty Heat Mix Stop Filling Acquire Release Acquire Release Πίνακας 8.1: Υλοποιημένες εντολές για κάθε συσκευή Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

62 54 Σημαντική διαφορά με την προηγούμενη έκδοση, είναι η συμπεριφορά των nodes. Ειδικότερα, επειδή κάθε node διαχειρίζεται το observerstream, μπορεί να στείλει νέα μηνύματα ακόμα και όταν περιμένουμε η λειτουργία του flow να βρίσκεται σε κάποιο άλλο στάδιο. Χαρακτηριστικό παράδειγμα είναι η περίπτωση που χρησιμοποιούμε το ίδιο node παραπάνω από μία φορές. Για αυτό το λόγο προστέθηκε η επιλογή για παρεμπόδιση μετάδοσης μηνυμάτων. Το συγκεκριμένο χαρακτηριστικό καθιστά τον χαρακτηρισμό των node μας ως δυναμικά, στοιχείο που αποφασίσαμε να αποσαφηνίσουμε μέσω του μόβ χρώματος του node όπως φαίνεται στην εικόνα Κάθε δυναμικό node διαθέτει τρεις λειτουργίες: BlockFirst: Εμποδίζει την μετάδοση μόνο του πρώτου μηνύματος επιστροφής από το stream BlockAfterFirst: Εμποδίζει την μετάδοση όλων των μηνυμάτων πέραν του πρώτου. Default: Σε περίπτωση που δεν έχει επιλεχθεί κάποια από τις δυο παραπάνω επιλογές, το nodeδιαθέτει την defaultσυμπεριφορά του, όπου όλα τα επιστρεφόμενα μηνύματα από το streamμεταδίδονται. Στην εικόνα 8.11 παραθέτουμε παράδειγμα του κώδικα της υλοποίησης των τριών αυτών λειτουριών στο fill silo1 node. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

63 ΕΠΈΚΤΑΣΗ ΤΟΥ NODE-RED ΜΕ ΤΑ LWM2M NODES 55 Εικόνα 8.11: Κώδικας διαχείρισης του observer stream και της αποστολής των μηνυμάτων. Εικόνα 8.12: Εμφάνιση του FillSilo1 Node στον Node-RED editor. Υλοποιώντας τα nodes για κάθε εντολή, παρατηρήσαμε πώς θα μπορούσαμε να διευκολύνουμε τον προγραμματιστή, κάνοντας τα nodes, device-agnostic, δηλαδή η συσκευή στην οποία αποστέλλεται η εντολή να είναι μέρος των παραμέτρων εισαγωγής από τον προγραμματιστή αντί της predefined κωδικοποίησης τους. Για την υλοποίηση αυτής της Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

64 56 αλλαγής, δημιουργήσαμε ένα νέο σετ από nodes, τα οποία προστέθηκαν στην συλλογή nodered-contrib-plant, τα οποία φέρουν αυτή τη συμπεριφορά. 8.5 H συλλογή node: Dispatcher Για την υλοποίηση μίας δεύτερης έκδοσης του Mashup, η οποία χρησιμοποιεί έναν dispatcher, οδηγηθήκαμε σε δεύτερη συλλογή από nodes, τα οποία ακολουθούν μια διαφορετική συμπεριφορά. Πιο συγκεκριμένα, αυτή τη φορά τα nodes των εντολών δεν διαχειρίζονται τα ολοκληρωμένα events (πχ. Fillingcompleted). Αντιθέτως, αυτή η συμπεριφορά έχει περάσει στο dispatchernode, το οποίο αποφασίζει ποια εντολή πρέπει να εκτελεστεί σε κάθε στάδιο ανάλογα με το ολοκληρωμένο event. Με αυτόν τον τρόπο, τα nodes των εντολών μας είναι αρκετά πιο απλά σε κώδικα, δεν έχουν κάποια δυναμική συμπεριφορά και αποκλειστική τους ευθύνη είναι η σωστή αποστολή των μηνυμάτων εκτέλεσης εντολών στις συσκευές. Στην εικόνα 8.13 καταγράφεται ο κώδικας δημιουργίας του coap-request της νέας έκδοσης του Fill Silo1 node. Εικόνα 8.13: Παράδειγμα του απλοποιημένου κώδικα για το FillSilo1 node. Η νέα έκδοση του Mashup χρησιμοποιεί και μία νέα έκδοση των Leshan-compliant συσκευών. Πιο συγκεκριμένα, οι συσκευές, αντί να διαθέτουν ένα resource για κάθε είδος event, διαθέτουν ένα resource που επιστρέφει το πιο πρόσφατο εκτελούμενο event σε JSON. Επομένως, ο Dispatcher μας πρέπει να κάνει parse το JSON μήνυμα από το observer stream του resource και να λάβει την κατάλληλη απόφαση για ποια εντολή πρέπει να εκτελεστεί στην συνέχεια. Αυτή η υλοποίηση καθιστά την ανάγνωση του κώδικα του Dispatcher node αρκετά πιο περίπλοκη καθώς το συγκεκριμένο node διαχειρίζεται όλα τα events που Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

65 ΣΧΕΔΙΑΣΜΌΣ ΕΦΑΡΜΟΓΏΝ MASHUP 57 εκτελούνται σε ένα Liqueur Generation Process, κομμάτι του κώδικα υλοποίησης του οποίου παραθέτουμε στην εικόνα Τα νέα αυτά nodes, προστέθηκαν σε μια νέα συλλογή, την node-red-contrib-plantv2. Εικόνα 8.14: Παράδειγμα διαχείρισης events από το Dispatcher node για το Silo1 9 ΣΧΕΔΙΑΣΜΟΣ ΕΦΑΡΜΟΓΩΝ MASHUP Σε αυτό το κεφάλαιο, γίνεται ανάλυση της διαδικασίας ανάπτυξης της τελικής mashup εφαρμογής, καθώς και λεπτομερής εξήγηση για αποφάσεις σχεδιασμού των flow. Γίνεται αναφορά σε δύο κύριες διαφορετικές υλοποιήσεις καθώς και στα στάδια των εκδόσεων της εφαρμογής τα οποία οδηγούν στην τελική μορφή της εφαρμογής. Σκοπός μας ήταν η δημιουργία μίας λειτουργικής εφαρμογής Mashup η οποία παράλληλα πλησιάζει την ευανάγνωστη μορφή των UML διαγραμμάτων. Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

66 Ανάπτυξη της υπηρεσίας Tύπου Α (1 η έκδοση) Η πρώτη έκδοση που αναπτύξαμε, ήταν πιστή στο πνεύμα σχεδιασμού της UML. Χρησιμοποιήσαμε την συλλογή node-red-contrib-plant την οποία αναπτύξαμε σε προηγούμενο στάδιο και χρησιμοποιήσαμε τον προηγουμένως διαμορφωμένο server από την βιβλιοθήκη lwm2m-node-lib. Η τελική μορφή για τα flow διαγράμματα παρατηρούνται στις εικόνες 9.1 και Η εφαρμογή αρχίζει στο deploy του flow μέσω του Node-RED editor. Για να λειτουργήσει σωστά η εφαρμογή πρέπει ο server να τρέχει και οι συσκευές να έχουν ήδη συνδεθεί. Σε περίπτωση που μια από αυτές τις δυο συνθήκες δεν πληρείται, η εφαρμογή δεν θα λειτουργήσει σωστά και θα ενημερώσει τον προγραμματιστή για την μη εύρεση των συσκευών στην registry του server. Χρησιμοποιώντας το node inject με παράμετρο just once εξασφαλίζουμε ότι η εφαρμογή θα αρχίσει την εκτέλεση της κατά το deploy, αποστέλλοντας ένα μήνυμα στα οχτώ observer nodes (ένα observer node για κάθε resource που περιλαμβάνει απαραίτητα δεδομένα για την παρατήρηση της ολοκλήρωσης εκτέλεσης των εντολών προς τις συσκευές). Επειδή τα observer nodes θα εκτελεστούν σε τυχαία σειρά και χρειαζόμαστε και τα οχτώ notification streams διαθέσιμα, έχουμε προσθέσει το function node με όνομα Wait for Observers. Η λειτουργία του είναι να περιμένει να ολοκληρωθούν επιτυχώς όλες οι observe εντολές και ύστερα να στείλει μήνυμα επιτυχίας στο επόμενο node για την συνέχεια της εκτέλεσης της εφαρμογής. Εικόνα 9.1: Κομμάτι με την εκτέλεση των Observe Nodes του Type A V1 Flow. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

67 ΣΧΕΔΙΑΣΜΌΣ ΕΦΑΡΜΟΓΏΝ MASHUP 59 Εικόνα 9.2: Κώδικας του Wait for Observers Function Node Επόμενο βήμα είναι το node Set Vars το οποίο απλά ορίζει αρχικές τιμές σε μερικές μεταβλητές, όπως πόσες φορές θα παράγουμε Liqueur. Έπειτα εκτελείται η εντολή Fill_S1 η οποία στέλνει μήνυμα στην συσκευή Silo1 να γεμίσει. Χρησιμοποιώντας το notification stream για το filling completed event της σου σιλό, το node περιμένει να λάβει ότι η διαδικασία ολοκληρώθηκε. Με την ολοκλήρωση του γεμίσματος, το node στέλνει εξερχόμενο μήνυμα στο node Aquire_Pipe_S1 το οποίο με την σειρά του στέλνει στην συσκευή Pipe μήνυμα για εκτέλεση της λειτουργίας Aquire με δεδομένα το Silo1 όνομα. Εάν το notification stream του Pipe επιστρέψει Silo1, σημαίνει πώς ο έλεγχος του σωλήνα βρίσκεται στο Silo1 και Silo4 και μπορεί να αρχίσει η διαδικασία μεταφοράς Liqueur από το silo1 στο silo4. Εκτελώντας παράλληλα τα nodes Empty_S1 και Fill_S4 περιμένουμε μία από τις δυο διαδικασίες να ολοκληρωθεί πρώτη (καθώς τα σιλό δεν είναι του ίδιου μεγέθους). Για αυτόν τον λόγο τα συνδέουμε με το Check first node το οποίο ελέγχει ποιο μήνυμα ολοκλήρωσης ήρθε πρώτο από τις εξόδους των προηγούμενων δύο. Για να ελέγξουμε την πηγή του κάθε μηνύματος χρησιμοποιούμε το πεδίο topic, το οποίο δηλώνει το node το οποίο έστειλε το μήνυμα. Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

68 60 Εικόνα 9.3: Κομμάτι Transfer Liqueur του Flow. Αναγνωρίζοντας το πρώτο μήνυμα λήψης, περνάμε στο στάδιο όπου σταματάει η μεταφορά του Liqueur με τα nodes Stop_Filling_S4 και Stop_Emptying_S1 όπως παρατηρούμε στην εικόνα Σε κάθε κύκλο εκτέλεσης εκτελείται μόνο ένα από τα δυο nodes. Περνώντας στην επόμενη φάση τα καλώδια των δύο nodes ενώνονται σε ένα node, για την ευκολότερη διασύνδεση των επόμενων nodes. Σε αυτό το σημείο, πρέπει να εκτελεστούν τρία κομμάτια κώδικα (εικόνα 9.4): 1. Πρέπει οπωσδήποτε να απελευθερωθεί ο σωλήνας από τον Silo1 ιδιοκτήτη. 2. Πρέπει η εφαρμογή να ελέγξει εάν πρέπει να παραχθεί και άλλο Liqueur και επομένως να ξαναγεμίσει το Silo1. 3. Πρέπει να συνεχιστεί η επεξεργασία του Liqueur στο Silo4. Εικόνα 9.4: Κομμάτι διακλάδωσης Flow. Προς αυτόν τον σκοπό, διακλαδώσαμε την έξοδο του merge node, σε τρείς ροές. Η πρώτη ροή ακολουθεί την διαδικασία επανάληψης του γεμίσματος του Silo1 με σε περίπτωση ανάγκης παραγωγής και άλλου Liqueur. Η δεύτερη ροή απελευθερώνει τον σωλήνα, ενώ η τρίτη περιλαμβάνει την διαδικασία επεξεργασίας του Liqueur στο Silo4. Για την επεξεργασία στο Silo4, εκτελείται πρώτα η θέρμανση του περιεχομένου με το node Heat_S4, και έπειτα, αποστέλλεται εντολή απόκτησης του Power Meter από το Silo4 (Aquire_Power_S4). Όταν το notification stream επιστρέψει πως ο ιδιοκτήτης είναι το Silo4, αποστέλλεται εντολή για μίξη του Liqueur. Όταν αυτό ολοκληρωθεί (πάλι με ειδοποίηση από το ανάλογο notification stream), η ροή διακλαδώνεται πάλι ώστε να απελευθερωθεί το Power Meter(Release_Power) από το Silo4 και παράλληλα να αρχίσει το Silo4 να αδειάζει τα Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

69 ΣΧΕΔΙΑΣΜΌΣ ΕΦΑΡΜΟΓΏΝ MASHUP 61 περιεχόμενα του(empty_s4). Όταν ολοκληρωθεί το άδειασμα του Silo4, αυτό με την σειρά του στέλνει μήνυμα στο node Wait for both. To node Wait for both περιμένει να λάβει δύο μηνύματα. Ένα μήνυμα ολοκλήρωσης από το node Empty_S4 και ένα από το node Fill_S1. Όταν γίνει λήψη και των δύο σημαίνει πώς το Silo1 είναι γεμάτο, και το Silo4 είναι άδειο. Επομένως στέλνει μήνυμα στο node More2Produce το οποίο με ελέγχει αν χρειάζεται να παραχθεί και άλλο Liqueur και περνά την εφαρμογή στην φάση απόκτησης του σωλήνα για το Silo1 ή τερματίζει (εάν δεν απαιτείται περεταίρω παραγωγή). Σημαντικό στοιχείο για το συγκεκριμένο flow είναι πως η επιλογή Block after first είναι ενεργοποιημένη στο πρώτο node Fill_S1, όπως παρατίθεται στην εικόνα Αυτό έγινε διότι, όταν ολοκληρωθεί το γέμισμα του Silo1, αποστέλλεται notification και στα δύο nodes ότι ολοκληρώθηκε η διαδικασία. Εάν δεν είχαμε επιλέξει αυτή τη συμπεριφορά, τότε η εφαρμογή θα έτρεχε και το Aquire_Pipe_S1 node, δημιουργώντας προβλήματα στην λειτουργία. Επομένως η παραπάνω επιλογή είναι ιδιαίτερα σημαντική για την διατήρηση της σωστής σειράς εκτέλεσης των εντολών στην mashup εφαρμογή μας. Εικόνα 9.5: Επιλογή Block After First για το Fill_S1 Node. Για την εύκολη παρακολούθηση της εκτλέλεσης της εφαρμογής δημιουργήσαμε ένα απλό γραφικό περιβάλλον (εικόνα 9.6) με την συλλογή node-red-contrib-ui[] και χρησιμοποιώντας τα observer streams για το resource Status των συσκευών Silo1, Silo4, Power,Pipe μπορούμε εύκολα να δούμε τι κάνει η κάθε συσκευή ανά πάσα στιγμή. Στην εικόνα 9.7 προβάλλεται το πλήρες διάγραμμα του flow για την διαδικασία Type A Process. Εικόνα 9.6: Το User Interface παρακολούθησης των state των συσκευών. Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

70 62 Εικόνα 9.7: Ολοκληρωμένο Διάγραμμα της Type A Process (Version 1) 9.2 Ανάπτυξη της υπηρεσίας Tύπου Β (1 η έκδοση) Ομοίως με την Type A Process αναπτύξαμε και την Type B. Ειδικότερα, η εφαρμογή αρχίζει με το Inject Node το οποίο εκτελείται κατά το Deploy. Εκτελούνται οι οχτώ observe εντολές και στέλνουν μήνυμα ολοκλήρωσης στο Wait for Observers node. Στην συνέχεια αρχικοποιούνται η μεταβλητές και εκτελείται το Fill_S2 node, το στέλνει στο Silo2 εντολή να γεμίσει. Όταν ολοκληρωθεί το γέμισμα, η πληροφορία μεταδίδεται μέσω του κατάλληλου notification stream και στην συνέχεια εκτελείται το node Heat_S2. Με την ίδια λογική κατά την ολοκλήρωσή του, εκτελείται η λειτουργία του Aquire_Pipe_S2 και ύστερα η μεταφορά του Liqueur απτό Silo2 στο Silo4. Ολόκληρη η διαδικασία για την εκτέλεση του Type B είναι ίδια με αυτή του Type A, με την μόνη διαφορά ότι ακολουθείται η σειρά εντολών που ορίζεται από το Type B Process specification. Παρατηρούμε και εδώ πως τα πρώτα nodes Fill_S2 και Heat_S2 έχουν ενεργοποιημένη την επιλογή Block After First ενώ τα ίδια nodes, Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

71 ΣΧΕΔΙΑΣΜΌΣ ΕΦΑΡΜΟΓΏΝ MASHUP 63 υπάρχουν και στην διακλάδωση επανάληψης της επεξεργασίας του Silo2 εάν χρειάζεται η παραγωγή περισσότερου Liqueur. Στην εικόνα 9.8 προβάλλεται το πλήρες διάγραμμα για το flow της διαδικασίας Type B Process. Εικόνα 9.8: Ολοκληρωμένο Διάγραμμα της Type B Process (Version 1) 9.3 Ανάπτυξη των υπηρεσιών Tύπου Α & Β (2 η έκδοση) Παράλληλα με την έκδοση 1 του Liqueur Plant αναπτύξαμε μία δεύτερη έκδοση της εφαρμογής (εικόνες 9.9 και 9.10). Σκοπός μας ήταν να απομακρυνθούμε από το μοντέλο της UML σχεδίασης και να εξετάσουμε μια διαφορετική εκδοχή. Κατόπιν μελέτης, αποφασίστηκε η σχεδίαση του flow με το μοντέλο ενός Dispatcher. Δηλαδή, ο έλεγχος της λειτουργίας απομακρύνεται από τα nodes εντολών, και τώρα υπάρχει ένας Dispatcher, που διαθέτει και όλα τα observer notification stream. Με αυτόν τον τρόπο ο Dispatcher, μπορεί να ελέγξει ποιο event ολοκληρώνεται και να στείλει μήνυμα εκτέλεσης εντολής στο κατάλληλό node. Με την σειρά του, αυτό το node θα στείλει μήνυμα εκτέλεσης εντολής στην συσκευή. Τελικώς ο Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων

72 64 Dispatcher ελέγχει αν η εντολή έχει ολοκληρωθεί και επαναλαμβάνει την διεργασία με νέα εντολή. Όπως αναφέρθηκε και σε προηγούμενο κεφάλαιο για την υποστήριξη αυτής της έκδοσης αναπτύξαμε μια νέα συλλογή από nodes η οποία εκτός των βασικών nodes εντολών περιλαμβάνει και τα δύο (ένα για κάθε type process) Dispatcher nodes. Εικόνα 9.9: Ολοκληρωμένο διάγραμμα flow της Type A Process V2 Η λογική λειτουργίας των flow, είναι όμοια με πριν. Με το deploy του flow, εκτελείται το inject node το οποίο στέλνει μήνυμα στα, αυτή τη φόρα, τέσσερα observe nodes (όπως αναφέρθηκε ήδη σε προηγούμενο κεφάλαιο αναδομήσαμε και τα resources των συσκευών). Κάθε φορά που ένα observation ολοκληρώνεται, το node στέλνει μήνυμα στο wait for observers node, και αυτό καταγράφει μηνύματα ολοκλήρωσης μέχρι τα τέσσερα. Έπειτα, στέλνει μήνυμα εκτέλεσης στον Dispatcher, και το Dispatcher_TypeA node αρχίζει την εκτέλεση του. Ομοίως λειτουργεί και το Type B Process V2. Διπλωματική Εργασία Ευάγγελος Τσιάτσιος Π.Π. 2018

73 ΣΧΕΔΙΑΣΜΌΣ ΕΦΑΡΜΟΓΏΝ MASHUP 65 Εικόνα 9.10: Ολοκληρωμένο διάγραμμα flow της Type Β Process V2 9.4 Αποτελέσματα Η ανάπτυξη των δύο εφαρμογών, έγινε σε στάδια. Αν και ο αρχικός στόχος ήταν ένα flow όσο το δυνατόν πιο κοντά στην φιλοσοφία της UML, προηγήθηκαν υλοποιήσεις οι οποίες ξέφευγαν απτό πνεύμα της UML. Ειδικότερα, οι υλοποιήσεις ομοίαζαν περισσότερο το Dispatcher μοντέλο, όπου ένα κεντρικό node, δεχόταν πληροφορίες και αποφάσιζε ποια θα είναι η επόμενη εντολή προς εκτέλεση. Τα μοντέλα αυτού του τύπου σίγουρα παράγουν αρκετά πιο μικρά διαγράμματα, αποκρύπτουν όμως την πλειονότητα της λογικής. Αν εξετάσουμε οποιοδήποτε από τα Version 2 flows, παρατηρούμε πως η εφαρμογή μπορεί να εκτελέσει ένα πλήθος εντολών, καθώς αυτές είναι ευδιάκριτες. Αν εξετάσουμε με περισσότερη λεπτομέρεια θα παρατηρήσουμε πως δεν μπορούμε να διακρίνουμε εύκολα την σειρά ή χρονική στιγμή εκτέλεσης των πιθανών αυτών εντολών. Η συγκεκριμένη υλοποίηση, είναι αρκετά δύσκολη και για να κατανοήσει πλήρως ο χρήστης τη λογική του προγράμματος, είναι απαραίτητη η ανάγνωση του κώδικα του Dispatcher Node. Αυτό οδηγεί σε αρκετά προβλήματα, καθώς οι χρήστες γραφικών εργαλείων δεν είναι πάντα εξειδικευμένη προγραμματιστές στην χρησιμοποιούμενη γλώσσα, και απλά αναζητούν ένα εργαλείο ανάπτυξης που να διευκολύνει το έργο τους. Το μοντέλο του Dispatcher Node, επεκτείνει το χάσμα της φιλοσοφίας των γραφικών εργαλείων και του flow programming, καθώς παραβιάζει βασικές αρχές σχεδιασμού των nodes. Σε καμία περίπτωση, δεν είναι το node απλό, ή ξεκάθαρο στις λειτουργίες τους. Δεν είναι απλό στην χρήση και προϋποθέτει μια σειρά από προηγούμενες εντολές οι οποίες εξασφαλίζουν την σωστή και ομαλή λειτουργία του. Στο ίδιο πρόβλημα βρίσκονται και τα nodes για την Version 1 έκδοση, στοιχείο που μας οδηγεί στο συμπέρασμα ότι οι προηγούμενες εντολές (π.χ. observe request) είναι αναγκαίες. Παρόλα αυτά, ο μεγάλος βαθμός αοριστίας του Dispatcher Node, στο βαθμό που όντως αποτελεί ένα μαύρο κουτί, με την πλήρη απουσία ευχρηστίας και λειτουργικότητας είναι που το κάνουν μια κακή επιλογή για τον σχεδιασμό και την ανάπτυξη εφαρμογών. Αντιθέτως εξετάζοντας την πρώτη έκδοση, Version 1, της εφαρμογής και τα ανάλογα flows, ο χρήστης μπορεί στην αρχή να αποθαρρυνθεί από το μέγεθος του διαγράμματος. Όμως είναι Το RESTful παράδειγμα αρχιτεκτονικής σε εφαρμογές Διαδικτύου Αντικειμένων