ΧΑΡΟΚΟΠΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

Transcript

1 ΧΑΡΟΚΟΠΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΣΧΟΛΗ ΨΗΦΙΑΚΗΣ ΤΕΧΝΟΛΟΓΙΑΣ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΚΑΙ ΤΗΛΕΜΑΤΙΚΗΣ ΔΙΑΧΥΣΗ ΓΝΩΣΗΣ ΑΝΑΜΕΣΑ ΣΕ ΑΥΤΟΝΟΜΟΥΣ ΚΟΜΒΟΥΣ ΝΕΦΕΛΩΜΑΤΟΣ ΣΥΣΤΗΜΑΤΩΝ ΙοΤ ENHANCING AWARENESS IN AUTONOMOUS FOG NODES FOR IoT SYSTEMS Πτυχιακή εργασία Βορεάκου Μαρία ECTORAS protocol Αθήνα, 2019

2 ΧΑΡΟΚΟΠΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΣΧΟΛΗ ΨΗΦΙΑΚΗΣ ΤΕΧΝΟΛΟΓΙΑΣ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΚΑΙ ΤΗΛΕΜΑΤΙΚΗΣ Τριμελής Εξεταστική Επιτροπή Νικολαΐδη Μάρα (Επιβλέπουσα) Πρύτανης Χαροκοπείου Πανεπιστημίου Τσερπές Κωνσταντίνος Επίκουρος Καθηγητής τμήματος Πληροφορικής & Τηλεματικής Χαροκοπείου Πανεπιστημίου Καμαλάκης Θωμάς Επίκουρος Καθηγητής τμήματος Πληροφορικής & Τηλεματικής Χαροκοπείου Πανεπιστημίου

3 Η Βορεάκου Μαρία Δηλώνω υπεύθυνα ότι: 1) Είμαι ο κάτοχος των πνευματικών δικαιωμάτων της πρωτότυπης αυτής εργασίας και από όσο γνωρίζω η εργασία μου δε συκοφαντεί πρόσωπα, ούτε προσβάλει τα πνευματικά δικαιώματα τρίτων. 2) Αποδέχομαι ότι η ΒΚΠ μπορεί, χωρίς να αλλάξει το περιεχόμενο της εργασίας μου, να τη διαθέσει σε ηλεκτρονική μορφή μέσα από τη ψηφιακή Βιβλιοθήκη της, να την αντιγράψει σε οποιοδήποτε μέσο ή/και σε οποιοδήποτε μορφότυπο καθώς και να κρατά περισσότερα από ένα αντίγραφα για λόγους συντήρησης και ασφάλειας.

4 Στο πιο γλυκό και χαρούμενο σκύλο που έχω ζήσει στη ζωή μου, η έμπνευση μου για όλη τη πτυχιακή. Στον Έκτορα [1]

5 Ευχαριστίες Η πτυχιακή αυτή, δεν θα μπορούσε να τελειοποιηθεί χωρίς την βοήθεια των ανθρώπων που μου στάθηκαν δίπλα μου σε όλη τη διάρκεια σπουδών μου. Αρχικά θα ήθελα να ευχαριστήσω τον σύντροφο μου, που παρόλες τις αντίξοες συνθήκες σε όλα τα χρόνια σπουδών μου, πίστευε σε μένα και στις ικανότητες μου. Δεν θα ήταν εφικτό να φτάσω ως εδώ, δίχως την ψυχολογική βοήθεια του αλλά και τη μεταλαμπάδευση γνώσεων που μου προσέφερε. Πρέπει επίσης να ευχαριστήσω την πρύτανη του Χαροκοπείου Πανεπιστημίου, την Κ. Νικολαΐδη Μάρα, που δέχθηκε αρχικά να είναι επιβλέπουσα της πτυχιακής μου, παρά το τεράστιο καθημερινό της πρόγραμμα, λόγω της θέσης της, και να μου δώσει υπέροχες ιδέες όσο αφορά την ανάπτυξη της πτυχιακής μου. Επιπλέον, έχω την ανάγκη να την ευχαριστήσω, διότι στάθηκε δίπλα μου, και ας μην το έχει συνειδητοποιήσει. Ευχαριστώ επίσης τον Έκτορα μου, το κατοικίδιο που για μένα είναι μέλος της οικογένειας, που ακόμη και όταν ήμουν αρκετά πιεσμένη, ήταν εκεί με μόνο σκοπό να μου δώσει χαρά και αγάπη. Ήταν ένας σημαντικός παράγοντας, σε όλη την ανάπτυξη της πτυχιακής μου. Στο τέλος αφήνω όλους όσους ήταν δίπλα μου, όπου ο καθένας με το δικό του τρόπο, μου προσέφερε εμπειρίες στην επαγγελματική και καθημερινή ζωή μου, αλλά και σε όλους όσους βρέθηκαν στη ζωή μου αυτά τα χρόνια, και με έκαναν να συνειδητοποιήσω ότι πρέπει να φιλτράρω το οτιδήποτε στη ζωή μου. [2]

6 Περίληψη Σε αυτή τη πτυχιακή εργασία γίνεται μελέτη στα συστήματα IoT και ειδικότερα στην αρχιτεκτονική των κόμβων νεφελώματος (fog nodes) που διαχειρίζονται τις IoT συσκευές. Καθώς το μέγεθος των ΙοΤ συστημάτων επεκτείνεται, αποτελεί καθοριστικό παράγοντα για την αποδοτική λειτουργία τους η αυτόνομη λειτουργία κόμβων νεφελώματος που διαχειρίζονται μέρος των ΙοΤ συσκευών και συνεργάζονται αρμονικά με τους γειτονικούς κόμβους. Έμφαση δίδεται στη διάχυση γνώσης ανάμεσα σε αυτόνομους κόμβους, που αφορά την κατάσταση που βρίσκεται ο καθένας από αυτούς, ώστε να εξασφαλίζεται η αρμονική συνεργασίας τους και επομένως η αδιάλειπτη λειτουργία του νεφελώματος. Καθώς γίνεται ανάλυση σε όλες τις βασικές αρχιτεκτονικές, μοντέλα και πρότυπα επικοινωνίας που χρησιμοποιούνται στα συστήματα ΙοΤ, προτείνεται ένα προσαρμοσμένο μοντέλο ως πρωτόκολλο επικοινωνίας ανάμεσα σε αυτόνομους κόμβους νεφελώματος για συστήματα ΙοΤ. Το προτεινόμενο πρωτόκολλο, που βασίζεται σε άλλα υπάρχοντα, ονομάζεται ECTORAS και παρουσιάζεται αναλυτικά στην εργασία. Μία πρωτότυπη υλοποίηση, που συμπεριλαμβάνεται σε ένα σύστημα διαχείρισης έξυπνου κτιρίου, περιλαμβάνεται επίσης ως παράδειγμα περίπτωσης για την επιβεβαίωση της διακίνησης και μετάλλαξης της γνώσης ανάμεσα σε αυτόνομους κόμβους νεφελώματος. Λέξεις κλειδιά: [Συστήματα ΙοΤ, Αυτόνομοι κόμβοι νεφελώματος, Πρωτόκολλα Επικοινωνίας, Διάχυση Γνώσης, Αρχιτεκτονική Συστήματος] [3]

7 Abstract In this thesis research is conducted in IoT systems, and specifically in fog node architecture that manage the IoT devices. Since the size of IoT systems is expanding, autonomous function of fog nodes that manage IoT devices, and their harmonious cooperation with neighboring fog nodes is a decisive factor. Emphasis is also given on knowledge diffusion among autonomous nodes, with regards to the status of each node, so as to ensure the harmonious cooperation among them and the unceasing function of the fog. Deep analysis is conducted in all basic architectures, models, and communication standards used in IoT systems, and in turn a modified model as a communication protocol for autonomous fog nodes for IoT systems is proposed. The proposed protocol, is based on other preexisting ones, is named ECTORAS and is extensively presented in the thesis. An original implementation, which is encompassed in a Smart Building Management System, is also included as a case study, for the verification of knowledge sharing and mutation, among the autonomous fog nodes. Keywords: [IoT Systems, Autonomous Fog Nodes, Communication Protocols, Knowledge Diffusion, System of Systems Architecture] [4]

8 Περιεχόμενα Ευχαριστίες... 2 Περίληψη... 3 Abstract... 4 Κατάλογος Εικόνων... 7 Κατάλογος Πινάκων... 8 Κεφάλαιο 1: Εισαγωγή... 9 Κεφάλαιο 2: Βιβλιογραφική Επισκόπηση Τι είναι IoT (Internet of Things) Η εξέλιξη του IoT Τι είναι Συστήματα IoT Smart Factory Smart Home Smart Health Smart Cities Smart Cars Τι είναι Web Services SoA (Service-Oriented Architecture) RoA (Resource-Oriented Architecture) Βασικές αρχές του REST design Βασικοί στόχοι του REST design RESTful API Κεφάλαιο 3: Fog Computing και Edge Computing Fog Computing & Cloud Edge Computing & Cloud [5]

9 3.3 Πρωτόκολλα Επικοινωνίας Request/Response Protocols Publish/Subscribe Protocols Κατανεμημένο Publish/Subscribe πρότυπο (DDS) Κεφάλαιο 4: The Autonomous Fog Node Concept Autonomous Fog Node Units Autonomous Fog Node Policies Κεφάλαιο 5: Καθορισμός του πρωτοκόλλου επικοινωνίας των Autonomous Fog Nodes Σημασιολογική ανάλυση του συστήματος Στόχοι Πρωτοκόλλου προς ανάπτυξη Μοντελοποίηση πρωτοκόλλου ECTORAS (Efficient Communication Technology Over REST Architecture Systems) Θεωρητικό υπόβαθρο Ανάλυση υψηλού επιπέδου του ECTORAS protocol Κεφάλαιο 6: Υλοποίηση πρωτοκόλλου ECTORAS Περιγραφή των URIs και Error Handling PoC (Proof of Concept) πρωτοκόλλου ECTORAS σε Migration Policy Κεφάλαιο 7: Μελλοντική Έρευνα Προεκτάσεις που προτείνονται Τρόπος λειτουργίας των μελλοντικών προεκτάσεων Πλεονεκτήματα των μελλοντικών προεκτάσεων Επίλογος Αναφορές [6]

10 Κατάλογος Εικόνων Εικόνα 1: Χρονοδιάγραμμα σημαντικών στιγμών του IoT [6] Εικόνα 2: IoT - Υπηρεσίες, τεχνολογίες και έννοιες [4] Εικόνα 3: Ενσωματωμένος εξοπλισμός και συσκευές [4] Εικόνα 4: Έξυπνες πόλεις [17] Εικόνα 5: Επικοινωνία Vehicle-to-Vehicle [20] Εικόνα 6: Βασικές Αρχές Web Services [27] Εικόνα 7: Διάγραμμα ροής με Αρχιτεκτονική RoA [33] Εικόνα 8: Βασική απεικόνιση του Cloud Computing [38] Εικόνα 9: Αρχιτεκτονική Fog Computing Εικόνα 10: Αρχιτεκτονική Edge Computing Εικόνα 11: Μοντέλα Request/Response (CoAP, HTTP) [35] Εικόνα 12: Μοντέλο διάδρασης REST HTTP Request/Response [35] Εικόνα 13: AMQP με RabbitMQ Broker [41] Εικόνα 14: Μοντέλο διάδρασης Publish/Subscribe MQTT [35] Εικόνα 15: Επίπεδα της Αρχιτεκτονικής DDS [42] Εικόνα 16: DDS - Τα δεδομένα στο κέντρο Εικόνα 17: SoA για συστήματα IoT πολλών πυρήνων [43] Εικόνα 18: Αρχιτεκτονική του Autonomous Aggregator σύμφωνα με το [43] Εικόνα 19: Κατάτμηση του υλισμικού του Autonomous Fog Node Εικόνα 20: Διάχυση γνώσης και διενέργειες μεταξύ των Fog Nodes Εικόνα 21: Απλουστευμένο παράδειγμα επικοινωνίας Fog Node με Registry Unit Εικόνα 22: Subscription των Fog Nodes στα Topics Εικόνα 23: Peer-to-Peer επικοινωνία μεταξύ των Fog Nodes Εικόνα 24: REST API Calls ενός Fog Node για το Subscribe του σε ένα Topic Εικόνα 25: Λίστα με τα διαθέσιμα Topics σε μορφή JSON Εικόνα 26: Απεικόνιση του POST Request που δημιουργεί το Fog Node προς τη Registry Εικόνα 27: Δομή κλήσης Subscribe σε ένα Topic Εικόνα 28: Δομή κλήσης Unsubscribe από ένα Topic Εικόνα 29: Δομή κλήσης Participants και η απάντηση JSON από τη Registry [7]

11 Εικόνα 30: Απεικόνιση μη έγκυρης δημιουργίας ενός Topic Εικόνα 31: HTTP Error μη έγκυρο ID του Fog Node Εικόνα 32: HTTP Error μη έγκυρο Topic ID Εικόνα 33: HTTP Error λάθος URI Path / Ελλιπείς Παράμετροι Εικόνα 34: Επικοινωνία Fog Nodes μέσω διαύλου Κατάλογος Πινάκων Πίνακας 1: HTTP verbs [34] Πίνακας 2: Αξιοπιστία μεθόδων HTTP Πίνακας 3: Παραδείγματα κλήσεων σε RESTful API [37] Πίνακας 4: Πρωτόκολλα επικοινωνίας IoT Πίνακας 5: URIs για τη δημιουργία, εγγραφή, απεγγραφή και λίστα των Topics Πίνακας 6: Δημιουργία Topic και Subscription του Fog Node σε Topic Πίνακας 7: Ανταλλαγή πληροφοριών με Peer-to-Peer επικοινωνία σε σχετικά Topics Πίνακας 8: Αλληλουχία ενεργειών για Migration [8]

12 Κεφάλαιο 1: Εισαγωγή Σε αυτή τη πτυχιακή εργασία γίνεται μελέτη στα συστήματα IoT και στα πρωτόκολλα επικοινωνίας που χρησιμοποιούν οι IoT συσκευές. Στο Κεφάλαιο 2 γίνεται βιβλιογραφική επισκόπηση στην εξέλιξη των συστημάτων ΙοΤ και τις κατηγορίες συστημάτων ΙοΤ που είναι διαθέσιμες αυτή τη στιγμή. Επιπλέον γίνεται αναφορά στα Web Services και στις τεχνολογίες που χρησιμοποιούνται κατά κόρον στα συστήματα ΙοΤ. Στο Κεφάλαιο 3 γίνονται πλέον γνωστές οι έννοιες του Cloud, Fog και Edge Computing και τι σημαντικές διαφορές έχουν μεταξύ τους τα προηγούμενα. Επίσης γίνεται μία σημαντική κατηγοριοποίηση και ανάλυση των πρωτοκόλλων επικοινωνίας που χρησιμοποιούνται στα συστήματα ΙοΤ, στις βασικές διαφορές του, καθώς και στα πλεονεκτήματα/μειονεκτήματα του εκάστου πρωτοκόλλου. Στο Κεφάλαιο 4 γίνεται μία σημαντική ανάλυση του συστήματος που επιλέχθηκε για μελέτη. Γίνεται ανάλυση στην έννοια των αυτόνομων κόμβων νεφελώματος και που εξυπηρετεί ένα τέτοιου είδους σύστημα. Επιπλέον αναλύεται η αρχιτεκτονική του συστήματος, από τι μονάδες αποτελείται και τι σημαίνει η έννοια των Policies στους αυτόνομους κόμβους νεφελώματος. Στο Κεφάλαιο 5 γίνεται η ανάλυση των απαιτήσεων που έχει το σύστημα που μελετώ, και βάσει των συμπερασμάτων που έβγαλα από τις κατηγορίες και τα είδη πρωτοκόλλων, προτείνω σε θεωρητικό βαθμό, ένα προσαρμοσμένο πρωτόκολλο επικοινωνίας, με σύνθεση ορισμένων τεχνολογιών. Σε αυτό το πρωτόκολλο επικοινωνίας (ECTORAS), ορίζονται οι στόχοι του, γίνεται η μοντελοποίηση του, καθώς και ανάλυση του σε υψηλό επίπεδο. Στο Κεφάλαιο 6 χρησιμοποιούνται όλες οι θεωρίες που προτάθηκαν στο Κεφάλαιο 5, για το πρωτόκολλο ECTORAS, ώστε να πραγματοποιηθεί η ανάπτυξη του σαν PoF (Proof of Concept). Αναλύονται οι τρόποι δόμησης των μηνυμάτων επικοινωνίας, και τα Requests/Responses που λαμβάνουν χώρα, μέσα στο σύστημα. Τέλος, στο Κεφάλαιο 7, γίνεται μία μελλοντική έρευνα σε προτεινόμενο Concept, όπου ενδεχομένως, θα είχε νόημα προς συζήτηση και ανάπτυξη του στο εγγύς μέλλον, χρησιμοποιώντας τεχνολογίες που θα «γεννηθούν» τα επόμενα χρόνια. [9]

13 Κεφάλαιο 2: Βιβλιογραφική Επισκόπηση 2.1 Τι είναι IoT (Internet of Things) To IoT βρίσκεται στη καθημερινότητα του κάθε ανθρώπου και κάθε εταιρείας/οργανισμού, σε τεχνολογικά ανεπτυγμένες χώρες, για αρκετά χρόνια, πριν ακόμη εδραιωθεί ο ορισμός IoT. Όπως αναφέρεται και στο ακρωνύμιο, το Internet of Things είναι ένα σύνολο ηλεκτρονικών συσκευών, οι οποίες παρέχουν πληροφορίες που τις διαμοιράζονται αργότερα στο Internet. Όπως έχει αναφερθεί από τον Kevin Ashton, συνιδρυτής και Executive director στην Auto-ID Center και έναν από τους πρώτους ανθρώπους που όρισε το IoT, «Θα μπορούσα να κάνω λάθος, αλλά είμαι αρκετά σίγουρος ότι η φράση "Internet of Things" ξεκίνησε ως τίτλος μιας παρουσίασης που έκανα στο Procter & Gamble (P & G) το 1999.» [1]. Πιο συγκεκριμένα, δέκα χρόνια μετά, το 2009, ο ίδιος ανέφερε ότι «Πρέπει να ενισχύσουμε τους υπολογιστές με τα δικά τους μέσα συγκέντρωσης πληροφοριών, ώστε να μπορούν να δουν, να ακούσουν και να μυρίσουν τον κόσμο» [1]. Βλέποντας επιπλέον αναφορές για το IoT, όπως αναφέρεται σε Ελληνική διπλωματική εργασία, «Το Internet of Things είναι μία έννοια που αφορά τα αντικείμενα της καθημερινότητας μας από βιομηχανικές μηχανές μέχρι wearable συσκευές που χρησιμοποιούν ενσωματωμένους αισθητήρες για τη συλλογή δεδομένων & την ανάληψη κάποιας δράσης σε αυτά μέσα σε ένα δίκτυο.» [2]. Όπως επίσης μπορεί να χρησιμοποιηθεί και ο ορισμός «Το Internet of Things είναι ένα όραμα στο διαδίκτυο που επεκτείνεται στην καθημερινότητά μας μέσω ενός δικτύου ασύρματων δικτύων μοναδικά αναγνωρίσιμων "αντικειμένων" ή "πραγμάτων".» [3]. Όπως λαμβάνοντας υπόψη το ευρύ υπόβαθρο και τις απαιτούμενες τεχνολογίες, από την αίσθηση της συσκευής, το υποσύστημα επικοινωνίας, την συνάθροιση δεδομένων και την προεπεξεργασία στην εκδοχή του αντικειμένου και τέλος την παροχή υπηρεσιών, η δημιουργία ενός σαφούς ορισμού του "Internet of Things" είναι μη τετριμμένη [4]. Το IoT έχει ως στόχο να προσφέρει σε επιχειρήσεις και τελικούς χρήστες σε μαζική κλίμακα, ετερογενείς, διαλειτουργικές και ευαισθητοποιημένες για το περιβάλλον, και απλουστευμένες δυνατότητες ανάπτυξης εφαρμογών στον τομέα της ανάπτυξης [5]. Οι συσκευές IoT χωρίζονται σε δύο βασικές κατηγορίες, στις συσκευές που χρησιμοποιεί ο καταναλωτής και τις βιομηχανικές συσκευές. Οι συσκευές καταναλωτή περιέχουν όλες τις μικροσυσκευές που χρησιμοποιεί ο οποιοσδήποτε χρήστης καθημερινά, όπως Wearables, Smart TVs, Smart Speakers, Smart ψυγεία [10]

14 κ.α. Αυτές οι συσκευές, συνηθώς συνδέονται μέσω των πρωτοκόλλων Bluetooth και Wi-Fi. Αντίστοιχα, οι βιομηχανικές συσκευές είναι προσαρμοσμένες με τις ανάγκες της κάθε επιχείρησης. Χρησιμοποιούνται κυρίως αισθητήρες για διαχείριση μηχανημάτων και συνδέονται με πρωτόκολλα όπως LAN, Bluetooth, Wi-Fi, κ.α. [6] 2.2 Η εξέλιξη του IoT Χρονολογικά ο όρος IoT υπάρχει αρκετά χρόνια σε δοκιμαστικό επίπεδο. Παρακάτω φαίνεται η προσπάθεια του ανθρώπου να εντάξει «εξυπνάδα» σε οτιδήποτε χρησιμοποιούσε, είτε σε προσωπικό επίπεδο, είτε σε επαγγελματικό. Από τις πρώτες καταγεγραμμένες προσπάθειες, που αρχίζουν πριν τον 19 ο αιώνα, με τον Baron Schilling στη Ρωσία (1832) και αργότερα με τους Carl Friedrich Gauss και Wilhelm Weber (1833), που δημιούργησαν ηλεκτρομαγνητικό τηλέγραφο με δικό τους κώδικα ώστε να επικοινωνούν σε απόσταση 1200m. [7] Αρκετά χρόνια αργότερα, το 1926, ο Nikola Tesla απαντώντας σε συνέντευξη στο τότε περιοδικό Colliers, κάνει αναφορά στο πως φανταζόταν τον κόσμο - «Όταν το ασύρματο εφαρμοστεί τέλεια, ολόκληρη η γη θα μετατραπεί σε έναν τεράστιο εγκέφαλο, που στην πραγματικότητα είναι, όλα τα σωματίδια ενός πραγματικού και ρυθμικού συνόλου... και τα μέσα μέσω των οποίων θα να είναι σε θέση να το κάνει αυτό θα είναι εκπληκτικά απλό σε σύγκριση με το σημερινό μας τηλέφωνο.» [8]. Το 1970, στο πανεπιστήμιο CMU, λόγω της μεγάλης κατανάλωσης Coca Colas σε αυτόματο πωλητή της, οι φοιτητές συχνά έφταναν στο μηχάνημα το οποίο κάποιες φορές ήταν άδειο. Για την αποφυγή αυτού, μέλη του τμήματος πληροφορικής του CMU, αποφάσισαν να δημιουργήσουν micro switches ώστε να μπορούν να ελέγξουν μέσω δικτύου ARPANET, τη διαθεσιμότητα μπουκαλιών από τον υπολογιστή τους χρησιμοποιώντας την εντολή finger coke@cmua. Αργότερα, έκαναν ακόμη πιο «έξυπνη» τη συσκευή τους, χρησιμοποιώντας συνθήκες (εάν άνοιξε το φως στον αυτόματο πωλητή, με τι συχνότητα ανάβει το φως) ώστε να μπορέσουν να καταλάβουν πότε είναι κρύα η Coca Cola και πότε ζεστή. [9] Σημαντικό επίσης επίτευγμα, ήρθε το 1990 από τον John Romkey, με την IoT συσκευή τοστιέρα για το συνέδριο INTEROP τον Οκτώβριο του '89, που θα μπορούσε να ενεργοποιηθεί και να απενεργοποιηθεί μέσω του Διαδικτύου. [7]. Όπως επίσης, σημαντική στιγμή θεωρείται το 1991, όταν η πρώτη Διαδικτυακή σελίδα από τον Tim Berners-Lee [10] πλέον είναι διαθέσιμη και το IoT μπορεί πλέον να έχει καθοριστικό ρόλο στην εξέλιξη της τεχνολογίας και των «έξυπνων συσκευών». [11]

15 Το 1999 ιδρύεται το Auto-ID Labs [11] και αναπτύσσει το Ηλεκτρονικό κώδικα Προϊόντος (EPC), ένα σύστημα αναγνώρισης στοιχείων βασισμένο σε παγκόσμιο RFID το οποίο προορίζεται να αντικαταστήσει το UPC Bar Code [7]. Ένα χρόνο μετά, η LG Electronics παρουσιάζει το πρώτο «έξυπνο» ψυγείο (μοντέλο R-S73CT), το όποιο έχει δυνατότητα σύνδεσης στο Internet μέσω LAN. Περιλαμβάνει επίσης μία οθόνη LCD που λειτουργεί με ηλεκτρονική πένα, σημειώσεις δεδομένων, ανταλλαγή βίντεο μηνυμάτων αλλά και παρεχόμενες πληροφορίες, όπως η εσωτερική θερμοκρασία, η φρεσκάδα των αποθηκευμένων τροφίμων, οι πληροφορίες διατροφής και οι συνταγές. Άλλο χαρακτηριστικό ήταν μία κάμερα που χρησιμοποιήθηκε ως σαρωτής για τη παρακολούθηση του ψυγείο στον εσωτερικό του χώρο. [12]. Το 2005, αρχίζει πλέον το IoT να εμφανίζεται συχνότερα σε ενότητες σε συνέδρια, και περιοδικά, και συγκεκριμένα, η Διεθνής Ένωση Τηλεπικοινωνιών, στην ετήσια αναφορά της, έχει ως κύρια ενότητα το IoT αναφέροντας ότι «οποιαδήποτε στιγμή, σε οποιαδήποτε σύνδεση για οποιονδήποτε, θα έχουμε τώρα συνδεσιμότητα για το οτιδήποτε» [13]. Έπειτα το 2009, το IoT ορίστηκε επισήμως και σύμφωνα με τη CISCO ο αριθμός των συσκευών που συνδεόταν με το διαδίκτυο υπερέβαινε τον αριθμό των ανθρώπων στον κόσμο. [6] Εικόνα 1: Χρονοδιάγραμμα σημαντικών στιγμών του IoT [6] Όπως παρουσιάζεται και στο χρονοδιάγραμμα (Εικόνα 1), μετά το 2009, αυξάνεται ραγδαίως ο όρος IoT, δημιουργούνται νέες συσκευές όπως το Raspberry Pi που θα γίνει αναφορά παρακάτω, και από το 2012 εώς και σήμερα, το IoT πλέον είναι στη καθημερινότητα κάθε χρήστη. Στην εικόνα 2, εμφανίζεται η απλή λογική του IoT, τι χρησιμοποιεί για την υλοποίηση του (Αισθητήρες, Δίκτυα, Επεξεργαστές) αλλά και τι εφαρμογές και υπηρεσίες προσφέρει. [12]

16 Εικόνα 2: IoT - Υπηρεσίες, τεχνολογίες και έννοιες [4] 2.3 Τι είναι Συστήματα IoT Έχοντας δώσει τον ορισμό του IoT, μπορεί να εξηγηθεί πλέον το Σύστημα IoT. Οι τεχνολογίες Cloud Computing [14] έχουν αξιοποιηθεί εκτεταμένα στην ανάπτυξη και τη διαχείριση των συστημάτων IoT μεγάλης κλίμακας επειδή θεωρητικά το cloud προσφέρει απεριόριστες δυνατότητες αποθήκευσης, υπολογισμών και δικτύων για την ενσωμάτωση διαφόρων τύπων συσκευών IoT και την παροχή ελαστικής υποδομής χρόνου εκτέλεσης για συστήματα IoT. [15] Smart Factory Ένα σύστημα IoT που μπορεί να περιγραφθεί, μπορεί να προσαρμοστεί σε ένα εργοστάσιο το οποίο θα γίνει «έξυπνο», και θα έχει τη δυνατότητα να εισάγει αρκετών κατηγοριών αισθητήρες και συσκευές, όπου θα μπορούσε να κυμαίνεται από τη σύνδεση του εργοστασίου με το έξυπνο [13]

17 δίκτυο, την κατανομή της εγκατάστασης παραγωγής ως υπηρεσία ή την παροχή μεγαλύτερης ευελιξίας και ευελιξίας στα ίδια τα συστήματα παραγωγής [4] Smart Home Ένα σύστημα IoT μπορεί επίσης να χρησιμοποιηθεί για τη δημιουργία «έξυπνων» σπιτιών. Χρησιμοποιώντας συσκευές IoT για οικιακή χρήση, όπως αισθητήρες (θερμοκρασίας, υγρασίας, φωτισμού κ.α.) και «έξυπνες» συσκευές (ψυγεία, ηλιακοί θερμοσίφωνες, Air Condition κ.α.) ένα σπίτι μπορεί να γίνει διαχειρίσιμο από προσωπικές συσκευές (Smartphones, Tablets, PCs) και να επιτρέπει στους χρήστες να χρησιμοποιούν μια ενιαία συσκευή για τον έλεγχο όλων των οικιακών και γενικότερα ηλεκτρονικών συσκευών του σπιτιού. Οι λύσεις επικεντρώνονται κυρίως στην παρακολούθηση του περιβάλλοντος, στην ενεργειακή διαχείριση, στην υποβοηθούμενη διαβίωση, στην άνεση και στη συνείδηση προς το περιβάλλον. [4]. Εικόνα 3: Ενσωματωμένος εξοπλισμός και συσκευές [4] Smart Health Ένα σύστημα ΙοΤ μπορεί να χρησιμοποιηθεί στην κλινική περίθαλψη όπου οι νοσοκομειακοί ασθενείς των οποίων η φυσιολογική κατάσταση απαιτεί στενή προσοχή μπορούν να παρακολουθούνται συνεχώς χρησιμοποιώντας διαφανή παρακολούθηση μέσω IoT συσκευών. [14]

18 Επιπλέον, η τεχνολογία μπορεί να χρησιμοποιηθεί και για απομακρυσμένη παρακολούθηση χρησιμοποιώντας μικρές, ασύρματες λύσεις συνδεδεμένες μέσω του IoT Smart Cities Ένα σύστημα IoT μεγάλου βεληνεκούς, μπορεί επίσης να χρησιμοποιηθεί και σε μία ολόκληρη πόλη. Η δημιουργία «έξυπνων» πόλεων θα βελτιώσει την επίλυση προβλημάτων και την καινοτομία με χρήση νοημοσύνης ευφυΐας, η οποία προσδιορίζεται ανάλογα με τους Πολίτες, τα συνεργαζόμενα συστήματα, τη γενικότερη ψηφιακή υποδομή και τα εργαλεία που μια κοινότητα είναι σε θέση να προσφέρει στους Πολίτες της. [16] Η διαχείριση αφορά και συστήματα IoT οδικών δικτύων που θα έχουν τη δυνατότητα να προσφέρουν υπηρεσίες παρακολούθησης οδικού δικτύου, αποφυγή κυκλοφοριακής συμφόρησης, αποφυγή ατυχημάτων (εφόσον στο σύστημα συνεργάζονται και «έξυπνα» αυτοκίνητα κ.α.). Εικόνα 4: Έξυπνες πόλεις [17] [15]

19 2.3.5 Smart Cars Από τα πιο γνωστά συστήματα IoT που χρησιμοποιούνται στη καθημερινότητα μας, είναι τα «Έξυπνα» αυτοκίνητα. Η σημερινή γενιά των οχημάτων είναι ήδη εξοπλισμένη με πολλά διαφορετικά είδη αισθητήρων, επεξεργαστές, συστήματα λογισμικού και δυνατότητες επικοινωνίας [18]. Για παράδειγμα, η αυτοκινητοβιομηχανία Mercedes-Benz, πρόσφατα, δημιούργησε ένα σύστημα IoT, το Mercedes me, το οποίο παρέχει λειτουργίες όπως, Remote Parking Assist (απομακρυσμένη βοήθεια για παρκάρισμα-ξεπαρκάρισμα), Remote Online (ενημέρωση για πληροφορίες του οχήματος, μέσω του Smartphone), In-Car-Office (λειτουργίες γραφείου, όπως συναντήσεις και υπενθυμίσεις), Mercedes-Benz emergency call system (άμεση κλήση βοήθειας όταν συμβεί ατύχημα), όπως και πολλές λειτουργίες Assist, που εξυπηρετούν στη καθημερινότητα του οδηγού [19]. Επιπλέον, γίνονται έρευνες για να ενταχθεί τεχνολογία που να επιτρέπει την επικοινωνία μεταξύ των οχημάτων. Όπως αναφέρεται και στο παρακάτω δημοσιευμένο άρθρο, Το πραγματικό σημάδι της ενσωμάτωσης κάθε τεχνολογίας και της χρησιμότητάς της είναι όταν οι άνθρωποι προσαρμόζονται διαισθητικά σε αυτήν. Οι τεχνολογικές πρωτοβουλίες όχημα με όχημα (Vehicle-to-Vehicle) και όχημα με υποδομή (Vehicle-to- Infrastructure) προσπαθούν να παράσχουν ένα πλαίσιο που βοηθά τους χρήστες να μεταβαίνουν στο μέλλον της οδήγησης όσο το δυνατόν πληρέστερα και πιο διαισθητικά [20]. Εικόνα 5: Επικοινωνία Vehicle-to-Vehicle [20] [16]

20 2.4 Τι είναι Web Services Τα Web Services παρέχουν ένα μέσο για επικοινωνία μεταξύ εφαρμογών, διαφορετικού λογισμικού, τρέχοντας σε μία ποικιλία από πλατφόρμες και πλαίσια εργασίας. [21]. Τα Web Services έχουν σχεδιαστεί για να παρέχουν διαλειτουργικότητα μεταξύ διαφόρων εφαρμογών. Η πλατφόρμα και οι ανεξάρτητες από τη γλώσσα διεπαφές των Web Services επιτρέπουν την εύκολη ενσωμάτωση ετερογενών συστημάτων. Η πρωτοβουλία των Web Services προσθέτει αποτελεσματικά υπολογιστικά αντικείμενα σε αυτή τη στατική πληροφορία και ως αυτό προσφέρει μια κατανεμημένη δυνατότητα παροχής υπηρεσιών μέσω ενός δικτύου. Τα Web Services θα δημιουργήσουν νέα παραδείγματα τόσο για την προσφορά δυνατοτήτων λογισμικού όσο και για τα μοντέλα με τα οποία οι επιχειρήσεις που δραστηριοποιούνται στο δίκτυο θα διαπραγματεύονται [22]. Το αντικείμενο των Web Services είναι τεράστιο και εξαιρετικά πολύπλοκο, καλύπτοντας πολλές έννοιες, πρωτόκολλα και τεχνολογίες που εντοπίζουν την προέλευσή τους σε κλάδους όπως τα κατανεμημένα υπολογιστικά συστήματα, τη δικτύωση υπολογιστών, τις αρχιτεκτονικές υπολογιστών και το Middleware, το Software Engineering, τις γλώσσες προγραμματισμού, τα συστήματα βάσεων δεδομένων, και την αναπαράσταση της γνώσης, τα οποία είναι συνυφασμένα με περίπλοκο τρόπο. Τα Web Services υπόσχονται ότι μπορούν να ξεπεράσουν την απλή ανταλλαγή πληροφοριών τον κυρίαρχο μηχανισμό για την ενσωμάτωση εφαρμογών σήμερα στην έννοια της πρόσβασης, του προγραμματισμού και της ενοποίησης των Application Services που ενσωματώνουν νέες και υπάρχουσες τεχνολογίες. Αυτό σημαίνει ότι οι οργανισμοί θα μπορούν όχι μόνο να μετακινούν τις πληροφορίες από εφαρμογή σε εφαρμογή, αλλά και να δημιουργούν πολύπλοκες και προσαρμοσμένες εφαρμογές, αξιοποιώντας οποιουσδήποτε αριθμούς συστημάτων τεχνολογίας Back-End και παλαιότερων τεχνολογιών (παλαιού τύπου) που βρίσκονται σε τοπικές ή απομακρυσμένες εφαρμογές [23]. Τα Web Services παρέχουν ένα αφηρημένο επίπεδο πάνω από τα υπάρχοντα συστήματα λογισμικού, και λειτουργούν σε τέτοιο αφηρημένο επίπεδο, παρόμοιο με του διαδικτύου. Τα Web Services είναι ικανά να γεφυρώσουν οποιοδήποτε λειτουργικό σύστημα, Hardware ή γλώσσα προγραμματισμού [24]. [17]

21 2.4.1 SoA (Service-Oriented Architecture) Για την επικοινωνία των Web Services, υπάρχουν αρκετοί διαφορετικοί τρόποι για την υλοποίηση τους. Πιο συγκεκριμένα, για την υλοποίηση των Web Services, έχουν δημιουργηθεί αρχιτεκτονικές, πρωτόκολλα αλλά και γλώσσες επικοινωνίας. Η βάση των γλωσσών επικοινωνίας για τα Web Services είναι η WSDL (Web Services Description Language). Η WSDL είναι γλώσσα βασισμένη σε XML που παρέχει ένα μοντέλο για τη περιγραφή των SOAP-Based Web Services [25] που θα αναφερθούν παρακάτω. Στο WSDL οι λειτουργίες και τα μηνύματα περιγράφονται αφηρημένα και στη συνέχεια δεσμεύονται σε συγκεκριμένο πρωτόκολλο δικτύου και συγκεκριμένη μορφή μηνύματος για τον ορισμό αργότερα σε ένα endpoint. Συναφή και συγκεκριμένα endpoints συνδυάζονται σε πιο αφηρημένα endpoints (υπηρεσίες). Το WSDL είναι επεκτάσιμο για να επιτρέψει την περιγραφή των endpoints και των μηνυμάτων τους ανεξάρτητα από τις μορφές μηνυμάτων ή τα πρωτόκολλα δικτύου που χρησιμοποιούνται για την επικοινωνία [26]. Εικόνα 6: Βασικές Αρχές Web Services [27] [18]

22 Όπως εμφανίζεται στην Εικόνα 5, για την υλοποίηση ενός Web Service (Αποστολή ενός μηνύματος στον Server, και λήψη απάντησης από αυτόν), χρειαζόμαστε τεχνολογίες όπως WSDL και SOAP (Simple Object Access Protocol) όπου είναι ένα από τα πιο διαδεδομένα πρωτόκολλα και βασίζεται επίσης σε XML [28] για μηνύματα και κλήσεις απομακρυσμένης διαδικασίας (RPCs). Αντί να οριστεί ένα νέο πρωτόκολλο μεταφοράς, το SOAP λειτουργεί σε υπάρχουσες μεταφορές, όπως HTTP, SMTP και MQSeries [29]. Στον πυρήνα του, ένα μήνυμα SOAP έχει απλή δομή XML και περιέχει ένα Child Element που είναι η κεφαλίδα και ένα Child Element ακόμη, που είναι όλο το υπόλοιπο σώμα. Τα περιεχόμενα της σελίδας και τα στοιχεία του σώματος του SOAP μηνύματος, είναι αυθαίρετα XML. Εκτός από τη βασική δομή μηνυμάτων, οι προδιαγραφές του SOAP ορίζουν ένα μοντέλο που υπαγορεύει τον τρόπο με τον οποίο οι παραλήπτες θα πρέπει να επεξεργάζονται τα μηνύματα SOAP. Το μοντέλο μηνυμάτων περιλαμβάνει επίσης φορείς, οι οποίοι υποδεικνύουν ποιος θα πρέπει να επεξεργαστεί το μήνυμα. Ένα μήνυμα μπορεί να εντοπίσει συντελεστές που υποδεικνύουν μια σειρά από ενδιάμεσους που επεξεργάζονται τα μέρη του μηνύματος που προορίζονται γι αυτούς και μεταφέρουν τα υπόλοιπα [29]. Μία άλλη σημαντική τεχνολογία για τα Web Services είναι η UDDI (Universal Description, Discovery and Integration) registry. Η UDDI registry είναι χρήσιμη ως μέσο ανίχνευσης των Web Services με χρήση WSDL. Η ιδέα είναι ότι η UDDI registry μπορεί να αναζητηθεί με διάφορους τρόπους για να αποκτήσει πληροφορίες επικοινωνίας και τα διαθέσιμα Web Services για διάφορους οργανισμούς. Ακόμη και χωρίς το κομμάτι ανακάλυψης πληροφοριών, η UDDI registry είναι σημαντική για την ενημέρωση των Web Services που χρησιμοποιεί η κάθε εταιρεία/οργανισμός αυτή τη στιγμή [27]. Το UDDI κωδικοποιεί τρεις τύπους πληροφοριών σχετικά με τις υπηρεσίες Web, τις πληροφορίες των «λευκών σελίδων», που περιλαμβάνουν το όνομα και τα στοιχεία επικοινωνίας, τις πληροφορίες των «κίτρινων σελίδων», που παρέχουν μια κατηγοριοποίηση βασισμένη σε τύπους επιχειρήσεων και υπηρεσιών και τις πληροφορίες για τις «πράσινες σελίδες», που περιλαμβάνουν τεχνικά δεδομένα σχετικά με τις υπηρεσίες [29]. Η αρχιτεκτονική που χρησιμοποιείται για το παραπάνω είδος Web Service είναι η SoA (Service-Oriented Architecture), η οποία βασίζεται στη λογική ότι οι λειτουργίες των διαφόρων συστημάτων παρέχονται μέσω δικτύου (ή Διαδικτύου) σε άλλα συστήματα με τη μορφή Υπηρεσιών Ιστού. Η SoA αποτελείται από όλες τις τεχνολογίες που αναφέρθηκαν παραπάνω (WSDL, UDDI, SOAP) και το σύνολο τους, σε πολλές πηγές αναφέρεται ως «SoA Triangle» (λόγω του τρόπου [19]

23 επικοινωνίας τους, όπως φαίνεται ξεκάθαρα στην εικόνα 5). Ως αφηρημένη έννοια θα μπορούσε να θεωρηθεί ότι η SoA βασίζεται στην λογική ότι οποιοδήποτε μεγάλο πρόβλημα μπορεί να επιμεριστεί και να διαχειριστεί καλύτερα εάν το σπάσουμε σε μικρότερα προβλήματα τα οποία το συνθέτουν [21]. Όπως αναφέρεται και από την IBM, η SoA μπορεί να έχει χαρακτηριστικά όπως: Διαχείριση μιας επιχειρηματικής διαδικασίας όπως ο υπολογισμός μιας προσφοράς ασφάλισης ή η διανομή ηλεκτρονικού ταχυδρομείου. χειρισμός ενός τεχνικού καθήκοντος, όπως πρόσβαση σε μια βάση δεδομένων ή ακόμη και παροχή επιχειρηματικών δεδομένων και τεχνικών λεπτομερειών για την κατασκευή γραφικών διεπαφών. Μπορεί να έχει πρόσβαση σε άλλη υπηρεσία. Με την κατάλληλη τεχνολογία χρόνου εκτέλεσης, μπορεί να έχει πρόσβαση σε ένα παραδοσιακό πρόγραμμα και να ανταποκρίνεται σε διαφορετικά είδη αιτούντων, όπως εφαρμογές ιστού. Είναι σχετικά ανεξάρτητο από άλλο λογισμικό. Οι αλλαγές σε έναν αιτούντα απαιτούν λίγες ή καθόλου αλλαγές στην υπηρεσία. Οι αλλαγές στην εσωτερική λογική μιας υπηρεσίας απαιτούν λίγες ή καθόλου αλλαγές στον αιτούντα. Η σχετική ανεξαρτησία της υπηρεσίας και του άλλου λογισμικού ονομάζεται χαλαρή σύζευξη [30] RoA (Resource-Oriented Architecture) To RoA όπως αναφέρεται και στο ακρωνύμιο, είναι μία αρχιτεκτονική βασισμένη σε Resources. Συνήθως ένα Resource είναι κάτι που μπορεί να αποθηκευτεί σε έναν υπολογιστή και να είναι μία αναπαραγωγή ενός stream από bits (ένα έγγραφο, μία εγγραφή σε μία Βάση Δεδομένων ή ακόμα και το αποτέλεσμα ενός αλγορίθμου) [31]. Η RoA δεν έχει συγκεκριμένη κατανομή στο σύστημα της, και μπορεί να ακολουθήσει οποιαδήποτε τοπολογία, ανάλογα με το σύστημα που έχει υλοποιηθεί. Αυτό βασίζεται κυρίως στο ότι χρησιμοποιεί κατά βάση Resources. Στην RoA είναι βασισμένο το REST (REpresentational State Transfer) όπου πλέον, οι περισσότεροι αναφέρονται σε αυτό σαν αρχιτεκτονική, αλλά το REST δεν είναι μια αρχιτεκτονική: είναι ένα σύνολο κριτηρίων σχεδιασμού. Μπορεί να ειπωθεί ότι μια αρχιτεκτονική πληροί αυτά τα κριτήρια καλύτερα από ένα άλλο, αλλά δεν υπάρχει μία «αρχιτεκτονική REST» [31]. Η κεντρική ιδέα του REST περιστρέφεται γύρω από την έννοια του Resource ως οποιοδήποτε στοιχείο μιας εφαρμογής που πρέπει να χρησιμοποιηθεί ή να αντιμετωπιστεί. Τα Resources μπορούν να περιλαμβάνουν φυσικές αντικειμενικές (π.χ. αισθητήρες θερμοκρασίας) αφηρημένες έννοιες, όπως συλλογές αντικειμένων, αλλά και δυναμικές και παροδικές έννοιες όπως η κατάσταση του διακομιστή ή συναλλαγές [32]. [20]

24 Εικόνα 7: Διάγραμμα ροής με Αρχιτεκτονική RoA [33] Βασικές αρχές του REST design Οι βασικές αρχές του REST [34] είναι οι παρακάτω: Οτιδήποτε μπορεί να είναι Resource, δηλαδή οτιδήποτε μπορεί να υπάρξει στο διαδίκτυο, που μπορεί να περιγραφθεί σε μορφή αρχείου, μπορεί να ονομαστεί Resource (για παράδειγμα, JPEG εικόνες, MPEG Videos, HTML, XML, έγγραφα κειμένων κ.α.) Καθένα Resource μπορεί να αναγνωριστεί με ένα μοναδικό αναγνωριστικό. Δεδομένου ότι το Διαδίκτυο περιέχει τόσα πολλά διαφορετικά Resources, όλα θα πρέπει να είναι προσβάσιμα μέσω URI και θα πρέπει να αναγνωρίζονται μοναδικά. Επίσης, τα URI μπορούν να είναι σε μορφή αναγνώσιμη από άνθρωπο, παρά το γεγονός ότι η χρήση τους είναι πιο πιθανό να είναι από προγράμματα λογισμικού, παρά από κοινούς ανθρώπους. Χρήση των καθιερωμένων μεθόδων του HTTP (GET, PUT, POST, DELETE), όπως φαίνεται στον πίνακα (Εικόνα 7). Τα Resources μπορούν να έχουν πολλαπλές παραστάσεις, δηλαδή, μπορεί να αποθηκεύονται με συγκεκριμένη μορφή (για παράδειγμα JSON), αλλά μπορεί να [21]

25 χρησιμοποιείται σε διαφορετική μορφή, ανάλογα με αυτή που ζητείται. Όσο η αποθηκευμένη μορφή υποστηρίζεται, το REST-enabled endpoint, θα μπορεί να το χρησιμοποιεί. Επικοινωνία με ιδιότητα Stateless. Το REST μπορεί να λειτουργήσει με τον ίδιο τρόπο που λειτουργεί ένα HTTP Request. Αυτή είναι και μία από τις σημαντικές αρχές του REST, καθώς δεν χρειάζεται να έχει συνεχώς ίδια κατάσταση ο Client με τον Server. Πίνακας 1: HTTP verbs [34] Ο συνδυασμός του REST με το πρωτόκολλο HTTP συνίσταται διότι, οι συσκευές μπορούν εύκολα να κάνουν διαθέσιμες τις πληροφορίες κατάστασης τους (State Information), λόγω του τυποποιημένου τρόπου, αποκαλούμενος ως CRUD Operations (Create, Read, Update, Delete Δημιουργία, Ανάγνωση, Ενημέρωση, Διαγραφή). Σύμφωνα με αυτήν την χαρτογράφηση, οι λειτουργίες για τη δημιουργία, την ενημέρωση, την ανάγνωση και τη διαγραφή των Resources αντιστοιχούν στις μεθόδους POST, GET, PUT και DELETE του HTTP πρωτοκόλλου [35], όπως περιγράφεται και στην εικόνα 8. Το REST χρησιμοποιώντας τη χαρτογράφηση CRUD του HTTP, έχει [22]

26 ως αποτέλεσμα να δημιουργεί ευκολία στους προγραμματιστές, διότι έχουν την δυνατότητα να δημιουργούν μοντέλο REST, για διαφορετικές συσκευές IoT [35] Βασικοί στόχοι του REST design Οι βασικοί στόχοι του REST όπως αναλύονται από τον [34] είναι οι παρακάτω: Διαχωρισμός του Resource και της αναπαράστασης. Ένα Resource είναι απλώς ένα σύνολο πληροφοριών, που μπορεί να αποτελείται από πολλές αναπαραστάσεις, όπως αναφέρθηκε στις αρχές που βασίζεται το REST. Ωστόσο, η κατάσταση του Resource είναι ατομική. Είναι στο χέρι του καλούντος να καθορίσει τον τύπο του περιεχομένου της κεφαλίδας ενός HTTP Request και είναι πάνω στο χέρι στην εφαρμογή του Server να χειριστεί την αναπαράσταση αυτή (Representation) και να επιστρέψει HTTP Status Code. Ορατότητα. Το REST έχει σχεδιαστεί ώστε να είναι ορατό και απλό. Η ορατότητα της υπηρεσίας σημαίνει ότι κάθε πτυχή της πρέπει να είναι περιγραφική μόνη τη, και να ακολουθεί τη φυσική γλώσσα HTTP σύμφωνα με τις αρχές που ακολουθεί το REST. Αξιοπιστία. Για να υπάρχει αξιοπιστία στο REST design, θα πρέπει να αναφερθεί ότι δεν είναι ασφαλή όλοι οι HTTP μέθοδοι που χρησιμοποιούνται. Πιο συγκεκριμένα, μία μέθοδος HTTP θεωρείται ασφαλής, όταν δεν επηρεάζει, τροποποιεί ή προκαλεί παρενέργειες στο Resource. Αντίστοιχα οι μέθοδοι HTTP που θεωρούνται ασφαλείς είναι αυτοί, που ανεξάρτητα από το πόσες φορές γίνεται κάποιο Request, η απάντηση θα είναι πάντα ίδια. Αναλυτικότερα στον παρακάτω πίνακα φαίνονται οι πιο συχνοί μέθοδοι που χρησιμοποιούνται. HTTP Method Safe Idempotent GET Yes Yes POST No No PUT No Yes DELETE No Yes Πίνακας 2: Αξιοπιστία μεθόδων HTTP Ευελιξία και απόδοση. Η ευελιξία αφορά την εξυπηρέτηση όλων των πελατών σε ένα αποδεκτό χρονικό διάστημα, και η βασική ιδέα της είναι να κρατήσει την εφαρμογή σε [23]

27 λειτουργία, καθώς και να αποτρέψει ένα DDoS (Denial of Service) που μπορεί να προκληθεί, από ένα τεράστιο όγκο εισερχομένων Requests RESTful API Εφόσον είναι πλέον κατανοητό τι είναι το REST design, πρέπει να γίνει αναφορά στα RESTful APIs. Η διαφορά του REST με του RESTful API είναι ότι το REST θεωρείται ένας αρχιτεκτονικός ρυθμός (ή σχεδιασμός) ενώ τα RESTful APIs είναι τα αντικείμενα που είναι βασισμένα στο REST [36]. Συχνά, μπορεί να υπάρχουν RESTful APIs σε πολλά Web Services, όμως, αυτό δεν τα καθιστά ότι έχουν σχεδιασμό REST. Πιο συγκεκριμένα, λόγω ότι ο σχεδιασμός REST πλέον είναι πολύ διαδεδομένος στα Web Services, υπάρχει μία αυξανόμενη ανησυχία και συζήτηση σχετικά με τον τρόπο σχεδιασμού των RESTful Web Services (RESTful API) με τον κατάλληλο τρόπο. Το πρόβλημα αποδίδεται στην έλλειψη ενός τυπικού μοντέλου και γλώσσας για να γίνει η περιγραφή ενός RESTful API που σέβεται όλους τους περιορισμούς, όπως αναφέρθηκε παραπάνω, στις αρχές και στους στόχους που βασίζεται το REST design, και ως αποτέλεσμα, πολλά Web Services ισχυρίζονται ότι χρησιμοποιούν RESTful API [36]. Στον παρακάτω πίνακα, εμφανίζονται κλήσεις API από έναν Agent, προς έναν Fog Node, και ο Fog Node με τη σειρά του, απαντάει το αποτέλεσμα, ανάλογα με το request του Agent. API Call fog nodeip:8181/sensors fog nodeip:8181/sensor/id fog nodeip:8181/sensor/id/light aggregatorip:8181/sensor/id/temp fog nodeip:8181/sensor/id/switch Result returns a list of sensors available returns data of specific sensor with id = ID returns data about light temperature of specific sensor with id = ID toggles the switch available on the sensor node and returns the state of the sensor node as if fog nodeip:8181/sensor/id was called Πίνακας 3: Παραδείγματα κλήσεων σε RESTful API [37] [24]

28 Κεφάλαιο 3: Fog Computing και Edge Computing 3.1 Fog Computing & Cloud Το Fog Computing ορίζεται ως μία System-level αρχιτεκτονική που κατανέμει τις λειτουργίες υπολογιστικής δύναμης, αποθήκευσης, ελέγχου και δικτύωσης, πιο κοντά στους χρήστες και κατά μήκος ενός συνεχούς Cloud-To-Thing [38]. Πιο συγκεκριμένα το Fog Computing είναι μία επέκταση «σύννεφο» του Cloud Computing, όπου δίνεται η δυνατότητα οι υλοποιήσεις των εφαρμογών να ανήκουν σε πολλαπλά επίπεδα στη τοπολογία του δικτύου [38]. Όταν το Fog Computing, σαν έννοια, ακόμη δεν υπήρχε, τα συστήματα IoT βασίζονταν στο Cloud Computing, δηλαδή, ότι όλες οι συσκευές IoT συνδέονταν μέσω εφαρμογών στο Cloud, δίχως να υπάρχει κάποιο Middleware, όπως φαίνεται παρακάτω, στην εικόνα 10. Εικόνα 8: Βασική απεικόνιση του Cloud Computing [38] Οι αρχιτεκτονικές προσεγγίσεις χωρίς εμπόδια, όπως υφίστανται στο Cloud Computing, δεν μπορούν να διατηρήσουν τις προβλεπόμενες απαιτήσεις ταχύτητας και όγκου δεδομένων της εκάστοτε IoT συσκευής ή του εκάστοτε συστήματος IoT. Όπως όρισε η Consortium OpenFog με μία δική της αρχιτεκτονική πάνω στο Fog Computing, για να διατηρηθεί η δυναμική που χρειάζεται ένα σύστημα IoT με βάση την αντιμετώπιση των προκλήσεων υποδομής και συνδεσιμότητας, να δίνει έμφαση στην επεξεργασία πληροφοριών και στην ευφυΐα στο λογικό άκρο [38]. Το Fog Computing [25]

29 αλλάζει τα «παραδοσιακά» συστήματα του Cloud Computing και δημιουργεί εξαρτημένα συστήματα, τα οποία συμπληρώνουν, καθώς και αποτελούν την επέκταση του Cloud Computing. Το μοντέλο του Fog Computing μεταφέρει τις υπολογιστικές απαιτήσεις πλησιέστερα στην άκρη (Edge) και ταυτόχρονα πάνω ακριβώς από τις συσκευές IoT (Sensors και Actuators) [38]. Σύμφωνα με δημοσίευση στην ΙΕΕΕ, το Fog Computing εξυπηρετεί στην αποφυγή του αρκετά κεντρικοποιημένου Cloud Computing προς το πιο διευρυμένο κατανεμημένο Fog-Cloud Computing, όπως και στην αποφυγή των μεγάλων και μακρινών Clouds, σε μικρότερα -αλλά και υπολογιστικά πιο κοντά στους Sensors, Actuators και χρήστες- Clouds [39]. Εικόνα 9: Αρχιτεκτονική Fog Computing Όσο οι προκλήσεις του IoT αυξάνονται, τόσο απαιτούνται και νέες αρχιτεκτονικές στο IoT. Πιο συγκεκριμένα, οι M. Chiang και T. Zhang, το 2016, αναφέρουν έξι σημαντικές προκλήσεις που θα μπορούσαν να αντιμετωπιστούν από τις τεχνολογίες Fog Computing και Edge Computing. Αυστηρότερες απαιτήσεις στο Latency Περιορισμοί σε Network Bandwidth [26]

30 Συσκευές περιορισμένης χρήσης πόρων Κυβερνο-Φυσικά Συστήματα Αδιάκοπες υπηρεσίες με διακοπτόμενη συνδεσιμότητα στο Cloud Νέες προκλήσεις στο Security [39] Τα βασικά χαρακτηριστικά του Fog Computing, όπως αναφέρονται στη παραπάνω δημοσίευση, είναι 4, και δίδονται με το ακρωνύμιο CEAL (Cognition, Efficiency, Agility, Latency) [39]. Σύμφωνα όμως με το OpenFog RA (Reference Architecture), το Fog Computing προσφέρει ένα παραπάνω πλεονέκτημα σε σχέση με άλλες προσεγγίσεις, και για την διευκόλυνση τους, το ονόμασαν SCALE (Security, Cognition, Agility, Latency, Efficiency) [38]. 3.2 Edge Computing & Cloud Όσο χρήσιμο είναι το Fog Computing για την ανάπτυξη των IoT συστημάτων, τόσο επίσης σημαντικό θεωρείται και το Edge Computing (ή διαφορετικά MEC, Mobile Edge Computing). Η αρχική ιδέα ότι οι εφαρμογές και οι υπηρεσίες εκτελούνται στην άκρη (Edge) των δικτύων εξελίχθηκε σταδιακά. Το Σεπτέμβριο του 2014, προτάθηκε η δημιουργία μιας νέας Ομάδας Προδιαγραφών Βιομηχανίας (ISG) στο Ευρωπαϊκό Ινστιτούτο Τηλεπικοινωνιακών Προτύπων (ETSI), προκειμένου να δημιουργηθούν προδιαγραφές του κλάδου Mobile Edge Computing (MEC), η οποία υποστηρίχθηκε από την Huawei, την IBM, Nokia Networks, NTT DoCoMo, Vodafone και άλλες εταιρείες [40]. Το Fog Computing και το Edge Computing διαφέρουν σε ένα κύριο σημείο. Η αρχιτεκτονική του Edge Computing τοποθετεί τους Fog Nodes μαζί με το επίπεδο των Sensors, και γίνεται άμεσα το Monitoring και το Control της κάθε IoT συσκευής. Αντίθετα στο Fog Computing, το Monitoring και Control γίνεται από μία επιπλέον συσκευή, και οι Sensors παρέχουν μόνο πληροφορία, την οποία επεξεργάζεται το παραπάνω επίπεδο. Μερικές φορές ο όρος Fog χρησιμοποιείται εναλλακτικά με τον όρο Edge, αν και το Fog είναι ευρύτερο από την τυπική έννοια του Edge. Η συνάφεια του Fog/Edge έχει τις ρίζες του τόσο στην ανεπάρκεια του «παραδοσιακού» Cloud όσο και στην εμφάνιση νέων ευκαιριών για το IoT, το 5G, και την ενσωματωμένη τεχνητή νοημοσύνη [39]. [27]

31 Εικόνα 10: Αρχιτεκτονική Edge Computing 3.3 Πρωτόκολλα Επικοινωνίας Τα συστήματα IoT χρησιμοποιούν ποικίλα πρωτόκολλα για την επικοινωνία μεταξύ των συστημάτων IoT και των Cloud, Fog, αλλά και Edge Computing. Ο συνεχόμενα αυξανόμενος αριθμός των IoT συσκευών, επιταχύνει και την έρευνα πάνω σε νέες λύσεις για τη περαιτέρω δυνατότητα κλιμάκωσης των Cloud Services [35]. Σύμφωνα με το [35], έχουν δημιουργηθεί αρκετές αρχιτεκτονικές και πρωτόκολλα, όσο αφορά την επικοινωνία με το Cloud Computing, και είναι βασισμένες στις ανάγκες αλλά και απαιτήσεις που υπάρχουν σε κάθε σύστημα IoT. Σε γενικές γραμμές, τα πρωτόκολλα επικοινωνίας, που αναλύθηκαν στο [35], διαφέρουν στα μοντέλα αλληλεπίδρασης τους, όπως για παράδειγμα μοντέλα πρωτοκόλλων request- response και publishsubscribe. Το request-reply είναι σημαντικό μοντέλο, στο οποίο βασίζονται το REST HTTP και CoAP. Η διαφορά των δύο request-reply μοντέλων, εμφανίζεται στην εικόνα 13. Τα πρωτόκολλα επικοινωνίας είναι κατηγοριοποιημένα με βάση το επίπεδο στο οποίο γίνεται η χρήση (IoT-to-Fog, IoT-to-Cloud) στο [35], αλλά ταυτόχρονα κατηγοριοποιημένα στις 2 [28]

32 βασικές κατηγορίες request-response και publish-subscribe. Ο πίνακας δίνει μία γενική εικόνα στη χρήση πρωτοκόλλων, ανάλογα με το μοντέλο που χρησιμοποιούν, αλλά και στο επίπεδο που χρησιμοποιούνται. IoT-to-Cloud IoT-to-Fog Request-Response HTTP, REST CoAP Publish-Subscribe DDS, AMQP MQTT, XMPP, Πίνακας 4: Πρωτόκολλα επικοινωνίας IoT Εικόνα 11: Μοντέλα Request/Response (CoAP, HTTP) [35] Request/Response Protocols Το πρωτόκολλο HTTP, είναι το βασικό μοντέλο Client-Server που χρησιμοποιείται καθημερινά από προγραμματιστές, και ένα από τα πιο συμβατά πρωτόκολλα για την υπάρχουσα υποδομή δικτύου [35]. Η επικοινωνία μεταξύ ενός Client και ενός Server πραγματοποιείται μέσω μίας αλληλουχίας request/response μηνυμάτων. Σε αυτή την αλληλουχία, ο Client αποστέλλει ένα αίτημα HTTP, και ο Server επιστρέφει ένα response μήνυμα, το οποίο περιέχει το αιτούμενο resource, εάν το request έχει γίνει δεκτό. Το πρωτόκολλο HTTP πλέον, είναι άμεσα συνδεδεμένο με τον σχεδιασμό REST [35], όπως έχει αναφερθεί στο κεφάλαιο Η παρουσίαση των δεδομένων δεν είναι προκαθορισμένη στο HTTP, και για αυτό το λόγο, χρησιμοποιούνται διάφορες markup languages όπως JSON και XML. Είναι σύνηθες να βλέπουμε υλοποιήσεις συστημάτων IoT με HTTP και JSON [35]. [29]

33 Το HTTP χρησιμοποιεί για πρωτόκολλο μεταφοράς το TCP. Το TCP ενώ παρέχει παράδοση μεγάλων ποσοτήτων δεδομένων με αξιοπιστία, άρα και πλεονέκτημα σε συνδέσεις που χρειάζονται αυστηρές απαιτήσεις latency, δημιουργεί προκλήσεις σε περιβάλλοντα περιορισμένων Resources [35]. Χρησιμοποιώντας TCP, αυξάνεται η αποστολή σποραδικών μικρών ποσοτήτων δεδομένων και επιπλέον, δημιουργώντας μία σύνδεση TCP, απαιτείται χρόνος και περιττά έξοδα. Για το QoS, το HTTP δεν παρέχει επιπλέον επιλογές, αλλά λόγω του ότι βασίζεται στο TCP, παρέχει αξιοπιστία στην επιτυχή παράδοση του μηνύματος, αρκεί η σύνδεση μεταξύ Client και Server να μη διακόπτεται [35]. Όσο αφορά το μηχανισμό ασφάλειας, το HTTP, χρησιμοποιεί το πλέον γνωστό TLS, ώστε να ενεργοποιεί ένα ασφαλές κρυπτογραφημένο κανάλι επικοινωνίας. Χρησιμοποιώντας το TLS, το HTTP ονομάζεται και ως HTTPS. Συνοψίζοντας, το REST HTTP, δεν επαρκεί για την IoT-Cloud επικοινωνία, λόγω της πολυπλοκότητάς του, των μεγάλων πεδίων κεφαλίδας (Headers) και της υψηλής κατανάλωσης ενέργειας του HTTP [35]. Εικόνα 12: Μοντέλο διάδρασης REST HTTP Request/Response [35] Το πρωτόκολλο CoAP (Constrained Application Protocol) είναι ένα παρόμοιο πρωτόκολλο με το HTTP, και ένα από τα πιο καθοριστικά του χαρακτηριστικά είναι η χρήση του δοκιμασμένου και αποδεκτού σχεδιασμού REST. Χρησιμοποιώντας το REST design, το CoAP υποστηρίζει ακριβώς το ίδιο πρότυπο request/response όπως το REST HTTP, και ειδικότερα πλέον, σε περιορισμένα περιβάλλοντα. Το CoAP θεωρείται ελαφρύ πρωτόκολλο, επειδή τα Headers, οι μέθοδοι και τα Status Codes είναι όλα σε δυαδική κωδικοποιημένη μορφή, μειώνοντας έτσι τα γενικά «έξοδα» του πρωτοκόλλου σε σχέση με πολλά άλλα πρωτόκολλα [35]. Στο επίπεδο μεταφοράς, χρησιμοποιεί [30]

34 ένα ακόμη λιγότερο σύνθετο πρωτόκολλο από το TCP, το UDP, που έχει ως αποτέλεσμα, να μειώνει ακόμη παραπάνω τα γενικά «έξοδα». Ωστόσο η χρήση του UDP, αυξάνει την αναξιοπιστία της επικοινωνίας client/server διότι υπάρχει η πιθανότητα να χαθούν μηνύματα. Ταυτόχρονα, με το UDP αυξάνεται η ευελιξία, λόγω της ασύγχρονης επικοινωνίας που έχει μεταξύ client/server. Αυτό έχει ως αποτέλεσμα τη μείωση κατανάλωσης Resources, όπου είναι μία σημαντική ιδιότητα για τα ενσωματωμένα συστήματα, που έχουν εξ ορισμού μειωμένα Resources. Η δημιουργός του CoAP, IETF, δημιούργησε ένα πρόσθετο έγγραφο, προτείνοντας στο πρωτόκολλο CoAP να τρέχει πάνω από TCP, το οποίο μέχρι στιγμής είναι σε ερευνητικό επίπεδο [35]. Στο σχεδιασμό του CoAP έχουν χρησιμοποιηθεί δύο επίπεδα, εκ των οποίων το ένα είναι παρόμοιο με το REST HTTP, χρησιμοποιώντας τα HTTP verbs στο request του client αλλά και στο response του Server. Εκτός των μεθόδων αυτών, χρησιμοποιείται και ένα token, το οποίο αντιστοιχίζει, λόγω της ασύγχρονης επικοινωνίας, το request του client με το response που δίνει ο server. Λόγω της αναξιοπιστίας που παρέχεται από το UDP, στο CoAP δημιουργήθηκε ένα δεύτερο επίπεδο, το message Layer, το οποίο είναι υπεύθυνο για την αναμετάδοση χαμένων πακέτων/μηνυμάτων. Πιο συγκεκριμένα, το message Layer, ορίζεται από 4 τύπους μηνυμάτων, CON (Confirmable), NON (non-confirmable), ACK (Acknowledgement), and RST (reset), τα οποία εξυπηρετούν στην αναγνώριση της κατάστασης της επικοινωνίας. Όσο αφορά το μηχανισμό ασφάλειας, το CoAP χρησιμοποιεί DTLS, στη κορυφή του επιπέδου μεταφοράς UDP. Είναι βασισμένο στο πρωτόκολλο TLS, με κάποιες σημαντικές αλλαγές, ώστε να λειτουργεί πάνω από μία αναξιόπιστη σύνδεση [35]. Το DTLS εξυπηρετεί στην αποφυγή Denial-Of-Service επιθέσεις, όπως και να παρέχει ανταλλαγή κλειδιών για τη χρήση κρυπτογραφίας. Παρόλ αυτά το DTLS, με τη συγκεκριμένη υλοποίηση, δεν είναι το βέλτιστο πρωτόκολλο επιπέδου μεταφοράς για τη χρήση του σε IoT συσκευές, ωστόσο βρίσκεται σε ερευνητικό στάδιο [35], ώστε να χρησιμοποιηθεί σε μελλοντικά συστήματα IoT Publish/Subscribe Protocols Τα πρωτόκολλα τύπου publish/subscribe βασίζονται στην αρχή εγγραφής Clients σε θέματα συζήτησης (Topics). Κάθε Client έχει δικαίωμα να δημιουργήσει ένα καινούριο θέμα συζήτησης, καθώς και να εγγραφεί σε ήδη υπάρχοντα θέματα, τα οποία είναι κοινοποιημένα, συνήθως, σε έναν Βroker. Κάθε φορά που κάποιος Client έχει μία καινούρια πληροφορία σχετική με κάποιο topic, φροντίζει να ενημερώσει, είτε μέσω του Βroker είτε με άλλες μεθόδους, όπως peer-to-peer [31]

35 communications, όλους τους συνδρομητές του συγκεκριμένου topic. Με αυτόν τον τρόπο όλοι οι Clients είναι ταυτόχρονα ενήμεροι για όλες τις πληροφορίες που αφορούν ένα συγκεκριμένο θέμα, από τη στιγμή της συνδρομής τους στο θέμα και μετά. Ένα από τα πρωτόκολλα τα οποία ακολουθούν την αρχή του Publish/Subscribe, είναι το AMQP (Advanced Message Queuing Protocol). Το AMQP είναι σχεδιασμένο να επιτρέπει τη διαλειτουργικότητα μεταξύ πολλών διαφορετικών εφαρμογών και συστημάτων, ανεξάρτητα από τις εσωτερικές αρχιτεκτονικές τους [35], δηλαδή μπορεί να εφαρμόζεται σε διαφορετικές πλατφόρμες που εφαρμόζουν διαφορετικές γλώσσες προγραμματισμού, και να υπάρχει η δυνατότητα ανταλλαγής μηνυμάτων. Χρησιμοποιώντας το AMQP, θα πρέπει να γίνει και επιλογή ενός Broker, ανάλογα με τις ανάγκες του συστήματος. Παρατηρώντας την Εικόνα 13, φαίνεται ο ενδιάμεσος κόμβος (Broker), ο οποίος είναι υπεύθυνος για την μετακίνηση του μηνύματος στον σωστό Subscriber (Receiver) ανάλογα με τα topics που έχει επιλέξει. Το AMQP χωρίζει σε 3 διαφορετικά επίπεδα το QoS (Quality-Of-Service). Το QoS 0 παραδίδει το μήνυμα στον Subscriber με τη καλύτερη δυνατή προσπάθεια, χωρίς όμως την επιβεβαίωση της λήψης μηνύματος στον Subscriber. Το επίπεδο QoS 1, επιβεβαιώνει ότι το μήνυμα θα παραδοθεί, οπότε είναι απαραίτητη και η επιβεβαίωση λήψης μηνύματος. Αντίστοιχα, το QoS 2 έχει την ευθύνη να παραληφθεί το μήνυμα ακριβώς μία φορά και χωρίς διπλότυπα, στον Subscriber [35]. Δεδομένων των περιορισμένων Resources των συσκευών σε συστήματα IoT, προτείνεται η χρήση του QoS 0, διότι είναι μεγαλύτερης σημασίας η επίτευξη επικοινωνίας σε σχέση με την αξιοπιστία της επικοινωνίας. Συνοψίζοντας, το AMQP με τα χαρακτηριστικά που προσφέρει, έχει αρκετές απαιτήσεις Resources (ισχύς, μνήμη), καθιστώντας το, ένα μάλλον βαρύ πρωτόκολλο για συστήματα IoT [35]. Εικόνα 13: AMQP με RabbitMQ Broker [41] [32]

36 Ένα αντίστοιχο πρωτόκολλο επικοινωνίας, που βασίζεται σε Publish/Subscribe μορφή, είναι το MQTT. Το MQTT δεν διαφέρει πολύ από το AMQP. Συγκεκριμένα, το MQTT είναι ένα από τα lightweight Message Protocols, γεγονός που το καθιστά κατάλληλο για συσκευές περιορισμένης πρόσβασης (Συσκευές IoT) και για μη ιδανικές συνθήκες σύνδεσης στο δίκτυο (χαμηλό Bandwidth, υψηλό Latency) [35]. Χρησιμοποιώντας μικρά Headers και αρκετά απλουστευμένο μήνυμα, το MQTT συνίσταται συχνά ως επιλογή για λύση επικοινωνίας σε συσκευές IoT. Στο επίπεδο μεταφοράς, το MQTT χρησιμοποιεί πρωτόκολλο TCP, το οποίο εξασφαλίζει αξιοπιστία. Μπορεί να γίνει σύγκριση του MQTT με πρωτόκολλα όπως το HTTP, όσο αφορά την αξιοπιστία του, αλλά με τη διαφορά ότι το MQTT χρειάζεται λιγότερες απαιτήσεις σε Resources, καθιστώντας το ως ένα από τις σημαντικές λύσεις πρωτοκόλλων σε περιορισμένα συστήματα [35]. Η αρχιτεκτονική του MQTT όμως σε σχέση με ένα πρωτόκολλο HTTP, διαφέρει αρκετά, διότι στην περίπτωση του MQTT, το σύστημα χρειάζεται Broker, όπως φαίνεται στην Εικόνα 14, ενώ στη περίπτωση του HTTP, το σύστημα μπορεί να ακολουθήσει οποιαδήποτε κατανομή χρειάζεται. Εικόνα 14: Μοντέλο διάδρασης Publish/Subscribe MQTT [35] Δεδομένου ότι το MQTT σχεδιάστηκε ως μία lightweight επιλογή, δεν παρέχει ασφάλεια με κρυπτογράφηση. Τα δεδομένα μεταφέρονται ως ένα απλό κείμενο, το οποίο είναι προφανές ένα ζήτημα από άποψη ασφάλειας [35]. Η κρυπτογράφηση παρόλ αυτά μπορεί να εφαρμοστεί ως ξεχωριστή λειτουργία στο υπάρχον πρωτόκολλο, με χρήση TLS, αλλά αυτό ταυτόχρονα, αυξάνει το Overhead. Μία άλλη επιλογή για την παροχή ασφάλειας στο MQTT, είναι η αυθεντικοποίηση μέσω του Broker, όπου και σε αυτή τη περίπτωση αυξάνεται το Overhead, αλλά είναι στη κρίση του προγραμματιστή και των αναγκών του συστήματος, με ποιον τρόπο θα υλοποιηθεί το σύστημα. [33]

37 3.3.3 Κατανεμημένο Publish/Subscribe πρότυπο (DDS) Το DDS (Data Distribution Service) είναι ένα πρότυπο διαλειτουργικότητας που βασίζεται σε real-time δεδομένα, το οποίο έχει οριστεί από την OMG (Object Management Group). Το DDS είναι ένα αποκεντρωμένο σύστημα επικοινωνίας και χρησιμοποιεί Publish/Subscribe μοντέλο, χωρίς την ανάγκη του Broker, παρά μόνο την peer-to-peer επικοινωνία του Publisher με τον Subscriber [35]. Επιπλέον έχει την ιδιότητα, οι Publishers και οι Subscribers να μπορούν να επικοινωνούν ως peers μέσω του δίαυλου δεδομένων, επιτρέποντας την ασύγχρονη ανταλλαγή δεδομένων με βάση τα ενδιαφέροντά τους (topics). Η απουσία των Brokers δημιουργούν ένα ακόμη πιο αξιόπιστο πρότυπο επικοινωνίας. Εικόνα 15: Επίπεδα της Αρχιτεκτονικής DDS [42] [34]

38 Μία από τις βασικές ιδιότητες του DDS είναι το dynamic discovery, το οποίο δίνει περαιτέρω δυνατότητες κλιμάκωσης. Το DDS παρέχει ένα πρωτόκολλο ανεύρεσης (discovery protocol), το οποίο επιτρέπει στους Subscribers, να βρουν ποιοι Publishers είναι παρόντες και να καθορίσουν τις πληροφορίες για τις οποίες ενδιαφέρονται, καθώς και το QoS που τους ενδιαφέρει [35]. Μία ακόμη σημαντική ιδιότητα του DDS, είναι η διαβεβαίωση ότι οι κατάλληλοι κόμβοι Publish και Subscribe, θα είναι μεταξύ τους συνδεδεμένοι, και η επικοινωνία τους θα είναι σε real-time. Ο μηχανισμός ασφάλειας που παρέχει το DDS, βασίζεται σε διάφορες λύσεις. Στη περίπτωση που το σύστημα βασίζεται σε TCP, τότε χρησιμοποιεί TLS πρωτόκολλο. Αντίστοιχα στη περίπτωση που βασίζεται σε UDP, τότε γίνεται η χρήση του DTLS πρωτοκόλλου. Όπως το TLS, έτσι και το DTLS, φέρουν πολύ μεγάλο Overhead για περιορισμένα συστήματα. Για την αντιμετώπιση αυτού, έχουν προταθεί κάποιοι πιο εξελιγμένοι μηχανισμοί. Η OMG, για παράδειγμα, στο DDS Security Specification, αναλύει ένα εκτενές μοντέλο ασφάλειας, καθώς και μία αρχιτεκτονική τύπου Service Plugin Interface (SPI), σχεδιασμένα για υλοποιήσεις DDS σε συστήματα IoT [35]. Εικόνα 16: DDS - Τα δεδομένα στο κέντρο [35]

39 Κεφάλαιο 4: The Autonomous Fog Node Concept Έχοντας ήδη περιγράψει τις έννοιες των IoT, Web Services, συμπεριλαμβανομένων εκτενών αναλύσεων των κυρίαρχων αρχιτεκτονικών τους, καθώς και τις έννοιες του Fog και Edge Computing, μπορούμε πλέον να μελετήσουμε και αναλύσουμε το σύστημα με το οποίο θα ασχοληθούμε στο επόμενο της εργασίας. Η μελέτη θα γίνει σε ένα σύστημα IoT που βασίζεται σε αυτόνομους κόμβους νεφελώματος (Fog Nodes) [43] με επίγνωση πληροφορίας (Context Awareness). Ως αυτόνομος (autonomous) ορίζεται ένας κόμβος όταν τα δεδομένα που συλλέγονται, γίνονται με ικανότητες ανίχνευσης ή παρακολούθησης και χρησιμοποιούνται σε μία γενική αυτόνομη διαδικασία λήψης αποφάσεων [44]. Επίγνωση πληροφορίας έχει ο κόμβος όταν τα δεδομένα τα οποία συλλέγει είναι πλήρη και επικαιροποιημένα, καθώς και κατανοητά για τον κόμβο. Όταν το σύνολο των παραδοχών ισχύουν για έναν κόμβο, τότε μπορούμε να πούμε πως ο κόμβος έχει επίγνωση πληροφορίας. Συγκεκριμένα το σύστημα, που παρουσιάζεται εκτενώς στο [43], αποτελείται από αισθητήρες (Θερμοκρασίας, υγρασίας, καπνού, φωτός, κ.α.), οι οποίοι είναι συνδεδεμένοι στο παραπάνω επίπεδο με τους Fog Nodes, που είναι υπεύθυνοι για την λήψη πληροφορίας, τη μεταφορά πληροφορίας αλλά και τη λήψη απόφασης με βάση τις πολιτικές που μπορεί να έχει ο Fog Node. Έπειτα ο Fog Node με τη σειρά του, μεταφέρει τη πληροφορία σε user-friendly μορφή, ώστε να μπορεί να αναγνωσθεί από ένα Service Component (User, PC κτλ.). Οι Fog Nodes λειτουργούν ως Middleware μεταξύ των αισθητήρων και των Service Components του IoT, και η αρχιτεκτονική που ακολουθεί το σύστημα στο δίκτυο του είναι SoA. Το ειδικό Hardware και Software που έχει ένας Fog Node, επιτρέπει την επικοινωνία με ποικίλα WSNs (Wireless Sensor Networks), βασισμένα σε διαφορετικές τεχνολογίες, ενώ ταυτόχρονα τα APIs των αισθητήρων (από εδώ και στο εξής θα αναφερόμαστε σε αυτούς με τη λέξη Sensors), αποτελούν ένα σύνολο από REST Services, που θα χρησιμοποιηθούν από υπηρεσίες ενός χρήστη [43]. [36]

40 4.1 Autonomous Fog Node Units Εικόνα 17: SoA για συστήματα IoT πολλών πυρήνων [43] Το σύστημα του αυτόνομου Fog Node βασίζεται σε ένα σύνολο διαφορετικών μονάδων, για τη λειτουργία του ως Middleware στο σύστημα IoT, όπως προτείνονται στο [43]. Πιο συγκεκριμένα αποτελείται από τις 5 διαφορετικές αυτόνομες μονάδες (Control Unit, Service Provision Unit, Sensors Communications Unit, Monitoring Unit & Decision Making Unit) και 1 κοινή μονάδα, τη Shared Memory (οι μονάδες από εδώ και πέρα θα αναφέρονται ως Units), που προτάθηκαν στο [43], καθώς και μία ακόμα, που εισάγεται για τη διάχυση γνώσης ανάμεσα στους Fog Nodes, ώστε να ενισχύσει την αυτοεπίγνωση τους (Self-Awareness) για το περιβάλλον στο οποίο λειτουργούν. Οι υπάρχουσες μονάδες περιγράφονται επιγραμματικά στη συνέχεια: Αρχικά υπάρχει το Control Unit, όπου είναι υπεύθυνο για τη σωστή λειτουργία του Fog Node. Το Control Unit είναι υπεύθυνο για την αρχικοποίηση όλων των Units στο σύστημα και επιπλέον έχει κάποιο βασικό έλεγχο στο σύνολο του Fog Node. Μπορεί επίσης να δημιουργήσει Requests Execution Threads, τα οποία λαμβάνονται μέσω HTTP πρωτοκόλλου από το Service Provision Unit και μπορεί επιπλέον να λαμβάνει μηνύματα απευθείας από το Sensors Communications Unit, που είναι υπεύθυνο για το χειρισμό των Sensors [43]. [37]

41 Το Service Provision Unit παρέχει ένα JSON REST API για την εξυπηρέτηση των παρακάτω: Εξυπηρέτηση Requests για διάδραση με τους Sensors, τα οποία διαβιβάζονται στο WSN. Εξυπηρέτηση Requests περιγραφής, τα οποία παρέχουν τη περιγραφή του παρεχόμενου Service. Εξυπηρέτηση των Requests που παρέχουν τη λίστα των Sensors, για τους διαθέσιμους επί του παρόντος Sensors. Εξυπηρέτηση των Requests λίστας, τα οποία είναι ομαδοποιημένα (δωμάτια) που εξυπηρετούνται από αυτόν τον Fog Node και τα παρεχόμενα Services τους [43]. Όλα τα Requests περιέχουν και ένα Criticality level (από 1 ως 5), το οποίο θα αναλυθεί παρακάτω. Το Sensor Communications Unit είναι το μόνο Unit στον Fog Node, το οποίο εξαρτάται από τους Sensors. Είναι υπεύθυνο για την επικοινωνία του με το αντίστοιχο WSN, και ως εκ τούτου, για κάθε διαφορετικό τύπο WSN με διαφορετικούς Sensors, πρέπει να γίνει ανάπτυξη αντίστοιχων βιβλιοθηκών διαχείρισης και επικοινωνίας με τον Fog Node [43]. Το Shared Memory Unit, παρέχει τη διαχείριση μεταβλητών παρακολούθησης (από και στο εξής θα αναφέρονται ως Monitoring Variables), περιγράφοντας την κατάσταση των Resources που διαχειρίζεται ο Fog Node και τις πολιτικές (από και στο εξής θα αναφέρονται ως Policies) που εφαρμόζονται για τη διαχείριση τους. Τα στατιστικά δεδομένα σχετίζονται με τα συνολικά Service Requests, με επίκεντρο τα δεδομένα που σχετίζονται με το Criticality Level, όπου επίσης διατηρούνται στη μνήμη. Τα Monitoring Variables παρέχουν πληροφορίες για τον Fog Node σε όλες τις μονάδες του, και προσφέρουν ένα γενικό πλαίσιο που επιτρέπει: Το Decision Making Unit να επιβάλλει Management Policies Το Monitoring Unit να παρακολουθεί το status όλων των Resources Το Monitoring Unit παρακολουθεί τις μετρήσεις που βοηθούν στη συνολική διαχείριση ενός Fog Node. Επικαλείται σε προκαθορισμένα χρονικά διαστήματα για παρακολούθηση, και καθορίζει κατά πόσο η κατάσταση του Fog Node έχει αλλάξει εντός του τελευταίου διαστήματος. Εάν έχει υπάρξει αλλαγή, καλεί το Decision Making Unit να προτείνει αλλαγές στο Configuration του Fog Node, όπως για παράδειγμα turn on/off ένα Core του συστήματος. [38]

42 Το Decision Making Unit είναι υπεύθυνο για να προτείνει αλλαγές στο Configuration του συστήματος, σύμφωνα όμως με τα Policies που υπάρχουν σε κάθε Fog Node. Για την πραγματοποίηση όμως αυτών των αλλαγών, είναι υπεύθυνο το Control Unit όπως αναφέρθηκε παραπάνω. Τα Policies εφαρμόζονται μέσα στο Decision Making Unit με τη μορφή event-action εντολών. Εικόνα 18: Αρχιτεκτονική του Autonomous Aggregator σύμφωνα με το [43] [39]

43 Στην αρχιτεκτονική της προηγούμενης εικόνας δεν εξασφαλίζεται η επικοινωνία και η διάχυση της γνώσης ανάμεσα στους αυτόνομους κόμβους. Οι κόμβοι μπορούν να αποφασίζουν μόνοι τους για την καλύτερη διαχείριση των πόρων τους και των ΙοΤ συσκευών που ελέγχουν, λαμβάνοντας υπόψη τον φόρτο που πρέπει να εξυπηρετήσουν. Η προτεινόμενη αρχιτεκτονική μπορεί να γίνει πιο αποδοτική εφόσον οι αυτόνομοι κόμβοι αποκτήσουν επίγνωση της κατάστασης των γειτόνων τους με τους οποίους μπορούν να συνεργαστούν, εφόσον το αποφασίζουν [33] [43]. Για το σκοπό αυτό, προτείνεται η προσθήκη μίας ακόμα αυτόνομης μονάδας με σκοπό της διάχυση γνώσης ανάμεσα στους αυτόνομους κόμβους. Η γνώση αυτή μπορεί να αφορά Γνώση για συνεργασία μεταξύ των κόμβων Γνώση περί πολιτικών μεταξύ των κόμβων Γνώση για την κατάσταση των γειτονικών Fog Nodes Μπορεί να αξιοποιηθεί από κάθε αυτόνομο κόμβο, εφόσον το αποφασίσει, χωρίς όμως αυτό να είναι υποχρεωτικό. Για το σκοπό αυτό, θα πρέπει να καθοριστεί πρωτόκολλο επικοινωνίας ανάμεσα στους αυτόνομους κόμβους. Επομένως η αρχιτεκτονική του αυτόνομου Fog Node διαμορφώνεται όπως φαίνεται στην παρακάτω εικόνα. Εικόνα 19: Κατάτμηση του υλισμικού του Autonomous Fog Node [40]

44 4.2 Autonomous Fog Node Policies Η σημαντικότερη ιδιότητα του Autonomous Fog Node είναι η αυτονομία του. Ένας Autonomous Fog Node είναι μία αυτόνομη οντότητα στο περιβάλλον, και για την επίτευξη της αυτονομίας, ο Autonomous Fog Node θα πρέπει να είναι σε θέση να παίρνει αποφάσεις, τέτοιες ώστε το αποτέλεσμά τους να βελτιώνουν την λειτουργία και απόδοση του [43]. Η αυτονομία των Fog Nodes, με βάση το σύστημα που έχουμε επιλέξει, μπορεί να επιτευχθεί χρησιμοποιώντας πολιτικές σε κάθε Fog Node (οι πολιτικές θα αναφέρονται ως Policies από εδώ και στο εξής). Τα Policies είναι κανόνες οι οποίοι εφαρμόζονται σε κάθε Autonomous Fog Node ξεχωριστά. Σε ένα δίκτυο με Autonomous Fog Nodes, κάθε Fog Node μπορεί να έχει διαφορετικά Policies. Για παράδειγμα κάθε Fog Node σε ένα εργοστάσιο μπορεί να ενημερώνεται για άλλες μετρικές με άλλες συνθήκες και βάσει διαφορετικών κανόνων να λαμβάνει διαφορετικές αποφάσεις. Ένας φούρνος Εργοστασίου είναι φυσιολογικό να λειτουργεί στους 300 βαθμούς Κελσίου, ενώ ένα Ψυγείο όχι, άρα η πληροφορία θερμοκρασίας πρέπει να διαχειριστεί διαφορετικά, καθώς στη μία περίπτωση δηλώνει φυσιολογική λειτουργία, αλλά στην έταιρη μάλλον πυρκαγιά. Στο προαναφερόμενο παράδειγμα, τα Policies, εξυπηρετούν, διότι κάθε Fog Node μπορεί να βρίσκεται σε διαφορετικό χώρο, και να υπάρχει ανάγκη διαφορετικής θερμοκρασίας στον έκαστο χώρο. Τα Policies εξυπηρετούν στο να υπάρχει ένα δίκτυο Fog Nodes το οποίο να μην έχει απαιτήσεις να ακολουθούνται ίδιες πολιτικές [43]. Τα Policies που έχουν προταθεί, κατηγοριοποιούνται ως εξής: Self-configuration policies Criticality level management policy Resource management Fog Node service QoS preservation Self-adaptation Policies o Sensor Communication Mode Self-healing Policies (Concept) o Erroneous Data Filtering o Sensor Health Monitoring [43] Παρακάτω υπάρχει ανάλυση σε κάποια από τα ήδη προτεινόμενα, από τους δημιουργούς, Policies τα οποία είναι υψηλής σημασίας, για την αποτελεσματικότερη και πιο ποιοτική λειτουργία του αυτόνομου αυτού συστήματος. [41]

45 Criticality level management policy: Σε αυτό το Policy, ορίζεται το επίπεδο κρισιμότητας ενός αιτήματος, ώστε να διασφαλιστεί, ότι τα αιτήματα υψηλότερης κρισιμότητας, θα εξυπηρετηθούν ταχύτερα από τα χαμηλότερα. Το Policy αυτό, ορίζεται με Criticality Levels, όπως έχουν αναφέρει οι δημιουργοί, και όσο μεγαλύτερο ο αριθμός (Level 5), τόσο υψηλότερης κρισιμότητας και το αίτημα αυτού [33]. Resource management: Το Policy αυτό στοχεύει στην ελαχιστοποίηση της ενέργειας κάθε Fog Node. Πιο συγκεκριμένα, ενεργοποιεί και απενεργοποιεί τα Cores του επεξεργαστή, ελέγχοντας κλιμακωτά, το φόρτο των Cores. Κάθε Core, χαρακτηρίζεται σε χρήση, υπέρ-φορτωμένο και υπολειτουργούμενο. Τα υπολειτουργούμενα Cores απενεργοποιούνται για τη διατήρηση της ενέργειας, και ξανά-ενεργοποιούνται όταν ο Fog Node ελέγχει ότι τη συγκεκριμένη χρονική στιγμή, όλα τα ενεργά Cores του, είναι υπερφορτωμένα [33]. Fog Node service QoS preservation: Το Policy αυτό είναι υπεύθυνο για τη διασφάλιση ποιότητας υπηρεσιών που παρέχει ο Fog Node. Χρησιμοποιώντας το συγκεκριμένο Policy, γίνεται η μεταφορά των αισθητήρων σε έναν κατάλληλο Fog Node, όταν ο Overloaded Fog Node δεν μπορεί να διαχειριστεί τους Sensors, λόγω μειωμένων Resources που έχει (Overload, ελάχιστη μπαταρία, κτλ.). Ο Overloaded Fog Node επιλέγει κάποιον γειτονικό Fog Node που λαμβάνει τα λιγότερα Requests. Στη περίπτωση που ο Fog Node που επιλέχθηκε, δεν είναι συμβατός με τους Sensors που θα λάβει, τότε ο Overloaded Fog Node είναι υπεύθυνος για την αποστολή των απαραίτητων πληροφοριών (για παράδειγμα Drivers των Sensors) στον νέο Fog Node. Επιπλέον, στη περίπτωση που για οποιοδήποτε λόγο, ο Overloaded Fog Node με τον επιλεγμένο Receiver δεν συμφωνήσουν, τότε ο Overloaded Fog Node, ξανά-προσπαθεί να βρει άλλον διαθέσιμο Fog Node ώστε να μεταφέρει τους Sensors. Χρησιμοποιώντας το Policy αυτό, επιτυγχάνεται η ποιότητα της λειτουργίας του συστήματος, καθώς οτιδήποτε και αν συμβεί, οι Sensors θα λειτουργούν, και θα μπορεί να υπάρχει η πληροφορία που χρειάζεται στο σύστημα [33]. Η υλοποίηση της πολιτικής αυτής προϋποθέτει την γνώση της κατάστασης των γειτονικών Fog Nodes και δεν μπορεί να υλοποιηθεί η λειτουργία του Knowledge Diffusion Unit. Η υλοποίηση της θα μας απασχολήσει και στο επόμενο κεφάλαιο. Τα Policies είναι επεκτάσιμα ανάλογα με τις απαιτήσεις και τις ανάγκες του εκάστοτε συστήματος και τα προαναφερόμενα είναι υλοποίηση τύπου Proof Of Concept από τους δημιουργούς του συστήματος. Επιπλέον, μπορούν να υλοποιηθούν πολλά και διαφορετικά Policies, [42]

46 τα οποία να ξεφεύγουν από τις παραπάνω 3 βασικές κατηγορίες. Η δημιουργία των Policies στο σύστημα, γίνεται με χειροκίνητους τρόπους μέχρι στιγμής, χρησιμοποιώντας κώδικα με γλώσσα προγραμματισμού Java [33], και με απώτερο σκοπό μελλοντικά να περιγράφονται με ένα σημασιολογικό μοντέλο, και να εφαρμόζονται αυτόματα. Ως εκ τούτου, στην τρέχουσα υλοποίηση του συστήματος, οι Autonomous Fog Nodes έχουν αυτονομία χρησιμοποιώντας τα εσωτερικά Units του Fog Node, αλλά αυτό δεν τους καθιστά αυτόνομους στον εξωτερικό κόσμο, ώστε να εκμεταλλευτούν δυνατότητα της μετάλλαξης και της δυναμικής δημιουργίας Policies, χρησιμοποιώντας τεχνικές μηχανικής μάθησης και επικοινωνίας μεταξύ αυτών. Έτσι, ο στόχος της μελέτης βασίζεται στη μοντελοποίηση ενός πρωτοκόλλου με φορμαλιστικό τρόπο, για την καλύτερη αυτοματοποίηση των διαδικασιών στους Fog Nodes, αλλά και την επίτευξη πλήρους αυτονομίας και αυτόματης δημιουργίας Policies, οι οποίες θα οδηγήσουν σε ένα ακόμη «εξυπνότερο» σύστημα. [43]

47 Κεφάλαιο 5: Καθορισμός του πρωτοκόλλου επικοινωνίας των Autonomous Fog Nodes 5.1 Σημασιολογική ανάλυση του συστήματος Το σύστημα των Autonomous Fog Nodes χρησιμοποιεί, εξωτερικά στο δίκτυο, αρχιτεκτονική SoA, και ταυτόχρονα αρχιτεκτονική RoA στη μεταξύ επικοινωνία των Autonomous Fog Nodes με τους Sensors. Επιπλέον, το σύστημα είναι βασισμένο σε σχεδιασμό REST για την επικοινωνία των Autonomous Fog Nodes με τους Agents, χρησιμοποιώντας HTTP μεθόδους για τα Requests/Responses. Αναφερόμενοι στις τεχνολογίες Cloud Computing, το προαναφερόμενο σύστημα των Autonomous Fog Nodes, μπορεί να βασιστεί σε Fog αλλά και σε Edge Computing, ανάλογα με τους τρόπους υλοποίησης του. Συγκεκριμένα, μπορεί να θεωρηθεί ότι βασίζεται σε Edge Computing, αλλά υπό τη συνθήκη ότι κάθε σύνολο Sensors, συνδέεται μόνο με έναν Autonomous Fog Node ώστε να υφίσταται ένα μικρό-σύστημα από μόνο του, και ο Fog Node εξωτερικά να «φαίνεται» σαν ένα Smart Device με ένα σύνολο από Sensors. Λόγω όμως της αυτονομίας που έχουν οι Fog Nodes, θα θεωρήσουμε ότι το σύστημα βασίζεται σε Fog Computing, καθώς οι Fog Nodes, κάθε διακριτή χρονική στιγμή, μπορούν να έχουν υπό την επιρροή τους διαφορετικό αριθμό, και διαφορετικού είδους Sensors. 5.2 Στόχοι Πρωτοκόλλου προς ανάπτυξη Όπως είναι εμφανές από [33], [43], τα συστήματα που δημιουργούνται στο Future Internet Era (FI) αποτελούνται κατά κόρον από αυτόνομους Agents που λειτουργούν σαν Fog Nodes ή Edge Nodes. Οι Agents αυτοί δημιουργούν μεταξύ τους ad-hoc δίκτυα τα οποία μεταλλάσσονται συνεχώς. Ως μετάλλαξη εννοούμε τη μη-σταθερότητα στη δομή τους (συμμετέχοντες, δίαυλοι, κλπ.) στον χρόνο. Αυτό έχει ως αποτέλεσμα την ανάγκη δημιουργίας ενός μη κεντρικοποιημένου συστήματος επικοινωνίας, καθώς θα ήταν φαινομενικά αδύνατο να ορίσουμε κεντρικοποιημένη δομή σε ένα συνεχώς μεταλλασσόμενο σύστημα που να εξυπηρετεί -την μεταξύ των Nodesσυνεργασία. [44]

48 Οι Βασικοί στόχοι της ανάπτυξης πρωτοκόλλου είναι η διάχυση της γνώσης μεταξύ των Fog Nodes και οι διενέργειες μεταξύ αυτών. Η διάχυση της γνώσης μεταξύ των Fog Nodes αποτελείται από τα παρακάτω: Οριοθέτηση Συνεργασίας μεταξύ των Fog Nodes. Ένας από τους πιο σημαντικούς στόχους του πρωτοκόλλου που θέλω να αναπτύξω είναι η πιο φορμαλιστική και σωστά μοντελοποιημένη επικοινωνία μεταξύ των Autonomous Fog Nodes. Προς την επίτευξη αυτού του στόχου, το πρωτόκολλο θα παρέχει ένα σύνολο από Θέματα Συζήτησης (Topics) τα οποία θα δημιουργούν τα ίδια τα Fog Nodes, βάσει των Policies τους, επί των οποίων θεμάτων τα υπόλοιπα Fog Nodes μπορούν να συνδράμουν. Διαμοιρασμός γνώσης και Policies. Επίσης σημαντικός στόχος για μένα είναι και ο διαμοιρασμός της γνώσης και των Policies. Χρησιμοποιώντας το διαμοιρασμό γνώσης μεταξύ των Fog Nodes, επιτυγχάνουμε τη μεταφορά οποιασδήποτε σημαντικής πληροφορίας μεταξύ των Fog Nodes. Αντίστοιχα, διαμοιράζοντας τα Policies μεταξύ τους, τα Fog Nodes γίνονται ακόμη εξυπνότερα και αυτό-εξελισσόμενα. Διαχείριση Resources των Fog Nodes. Η μέχρι τώρα υλοποίηση του συστήματος που μελετάμε, αναφέρεται σε επικοινωνία μεταξύ των Fog Nodes με μία απλοποιημένη μορφή του Policy service QoS preservation. Το πρωτόκολλο επικοινωνίας που θέλω να αναπτύξω, έχει επίσης ως σκοπό, την μεταφορά των Resources (Sensors) που διαχειρίζεται ένα Fog Node, σε κάποιο άλλο Fog Node, με έναν πιο έξυπνο και φορμαλιστικό τρόπο. Ο δεύτερος βασικός στόχος της ανάπτυξης πρωτοκόλλου είναι οι διενέργειες μεταξύ των Fog Nodes. Στο σύστημα [33], η επικοινωνία μεταξύ των Fog Nodes αλλά και μεταξύ ενός Fog Node και μίας Registry, γίνεται με ένα Custom πρωτόκολλο, το Multipurpose Unified JSON API, το οποίο ορίζει έναν συγκεκριμένο τρόπο δόμησης του Path των Requests, για την αυτοματοποίηση και ευκολότερη επέκταση των δυνατοτήτων του συστήματος. Όμως το συγκεκριμένο πρωτόκολλο, δεν επεκτάθηκε ως προς τη δόμηση του στα API Calls, παρά μόνο στη δόμηση του Path. Όπως αναφέρθηκε και στον πρώτο στόχο (στην οριοθέτηση συνεργασίας μεταξύ των Fog Nodes), αυτό που θέλω να πετύχω, είναι η επικοινωνία αλλά και οι ενέργειες που μπορούν να διαπραχθούν μεταξύ των Fog Nodes, να είναι δομημένες με έναν απλουστευμένο τρόπο, και γρήγορα αναγνώσιμες από το κάθε Fog Node. Το πρωτόκολλο επικοινωνίας, θέλω επίσης να είναι επεκτάσιμο, ώστε να μπορούν να δημιουργηθούν διαφορετικού είδους ενέργειες (Actions), και να [45]

49 μπορεί να καλύψει διαφορετικές ανάγκες επικοινωνίας των Fog Nodes, ανάλογα με το κάθε σύστημα ΙοΤ. Εικόνα 20: Διάχυση γνώσης και διενέργειες μεταξύ των Fog Nodes Στην Eικόνα 20, παρατηρούμε την επικοινωνία μεταξύ των Fog Nodes, ανάλογα με το είδος των Resources που διαχειρίζονται. Στην κάθε επικοινωνία γίνεται διαμοιρασμός γνώσης μεταξύ των Fog Nodes, με απώτερο σκοπό την οριοθέτηση συνεργασίας μεταξύ αυτών και την ανταλλαγή των Resources εφόσον το συμφωνήσουν. 5.3 Μοντελοποίηση πρωτοκόλλου ECTORAS (Efficient Communication Technology Over REST Architecture Systems) Θεωρητικό υπόβαθρο Έχοντας πλέον γνώση στις αρχιτεκτονικές που χρησιμοποιούνται στα Fog και Edge Computing, καθώς και στα είδη πρωτοκόλλων επικοινωνίας, επέλεξα μία σύνθεση τεχνολογιών για [46]

50 την ανάπτυξη του πρωτοκόλλου ECTORAS με απώτερο σκοπό το -όσο ιδανικό γίνεται- πρωτόκολλο επικοινωνίας για συστήματα ΙοΤ με Autonomous Fog Nodes. Όσον αφορά το τρόπο επικοινωνίας των Fog Nodes, το πρωτόκολλο ECTORAS θα βασίζεται, στο πρότυπο DDS όπου παρέχει μία Publish/Subscribe επικοινωνία, δημιουργώντας Topics. Τα Topics θα δημιουργούνται με βάση τις ανάγκες του συστήματος, δηλαδή είτε μπορεί να δημιουργηθούν Topics χωροταξικού περιεχομένου, είτε Topics με συγκεκριμένα Policies κ.ο.κ.. Χρησιμοποιώντας DDS πρότυπο, έχουμε Publish/Subscribe μοντέλο, χωρίς την απαίτηση Broker, αλλά με επικοινωνία peer-to-peer, όπου αυτό δημιουργεί μία πιο αξιόπιστη επικοινωνία. Επιπλέον τα δημιουργημένα Topics, θα αποθηκεύονται στην ήδη υπάρχουσα Registry του συστήματος, και στο κάθε topic, θα γίνεται αποθήκευση και των Subscribers που το ακολουθούν. Η χρήση των Topics εξυπηρετεί στη κατηγοριοποίηση των Fog Nodes ανάλογα με τα ενδιαφέροντα που έχουν, όπως επίσης και στη μείωση του φόρτου του δικτύου, καθώς το κάθε Fog Node, θα ενημερώνεται άμεσα, μόνο για τις πληροφορίες που έχει ανάγκη. Όσον αφορά τη δεύτερη τεχνολογία που θα χρησιμοποιήσω, είναι μία προϋπάρχουσα τεχνολογία που χρησιμοποιείται από τους δημιουργούς, για την επικοινωνία μεταξύ των Fog Nodes, τη τεχνολογία REST. Πιο συγκεκριμένα, το REST επιλέχθηκε για το τρόπο δόμησης των Requests/Responses μεταξύ των Nodes, διότι είναι Stateless, μία πολύ σημαντική ιδιότητα που ταιριάζει απόλυτα σε συστήματα IoT, καθώς είναι σημαντικός ο φόρτος που υπάρχει στο δίκτυο. Χρησιμοποιώντας το μοντέλο REST μαζί με το πρότυπο DDS, επιτυγχάνεται ένα πρωτόκολλο επικοινωνίας που είναι αρκετά αξιόπιστο, αλλά και ένα πρωτόκολλο που είναι από τα πιο κατάλληλα σε embedded Systems, καθώς τα Requests/Responses γίνονται με API Calls. Το κάθε Response στα REST API Calls απαντά απλά μικρά JSONs τα οποία δεν επιβαρύνουν το δίκτυο, και είναι ευανάγνωστα από το κάθε Fog Node, όπως επίσης απαντά και αντίστοιχο Response Status Code Ανάλυση υψηλού επιπέδου του ECTORAS protocol Όπως έχει αναφερθεί και στα Κεφάλαια 2, 3 και 5 τα Fog Nodes στα συστήματα ΙοΤ πρέπει να έχουν τέτοιο τρόπο επικοινωνίας, ώστε να μην τους καθιστά την απαίτηση να βρίσκονται σε κεντρικοποιημένο σύστημα. Χρησιμοποιώντας το πρότυπο DDS, επιτυγχάνεται η επικοινωνία μίας Publish/Subscribe επικοινωνίας, χωρίς Broker. Τα Topics παρόλ αυτά, πρέπει να υφίστανται κάπου στο σύστημα, ώστε να μπορέσει να επιτευχθεί μία Publish/Subscribe επικοινωνία. Για αυτό το λόγο, [47]

51 χρησιμοποιούμε το Registry Unit του συστήματος, ώστε να μπορούν να γίνονται οι εγγραφές των Topics. Στην Εικόνα 21, παρατηρούμε την απλουστευμένη μορφή επικοινωνίας που έχει το κάθε Fog Node με τη Registry. Το Fog Node έρχεται σε επικοινωνία με τη Registry ώστε να ενημερωθεί για το τι είδους Topics υπάρχουν. Η Registry με τη σειρά της, απαντά στο Fog Node, τα διαθέσιμα Topics. Η διαδικασία αυτή μπορεί να επαναληφθεί όσες φορές θεωρεί το Fog Node ότι είναι αναγκαίες, καθώς τα Topics αλλάζουν δυναμικά στο χρόνο, όπως και τα Fog Nodes. Εικόνα 21: Απλουστευμένο παράδειγμα επικοινωνίας Fog Node με Registry Unit Τα Topics μπορούν να είναι θεωρητικά άπειρα σε μία Registry, καθώς κάθε Topic μπορεί να αναφέρεται σε θέματα που αφορούν κάποια από τα Fog Nodes στο σύστημα μας. Στην Εικόνα 21 φαίνονται τα Subscribes των Fog Nodes στα Topics. Όπως παρατηρούμε, σε ένα Topic μπορούν να είναι εγγεγραμμένα αρκετά Fog Nodes, αλλά ταυτόχρονα κάθε Fog Node έχει τη δυνατότητα να είναι εγγεγραμμένο σε παραπάνω από ένα Topic. Ο λόγος που θέλουμε να υπάρχει η δυνατότητα αυτή, είναι διότι σε ένα σύστημα, μπορούν να υπάρχουν διαφορετικού είδους Topics, με διαφορετικές κατηγορίες. Κάποιες προτεινόμενες κατηγορίες είναι οι εξής: Χωροταξικά Topics: Για παράδειγμα Sensors δωματίου #1 Με βάση τα πρωτόκολλα που εξυπηρετούν: Για παράδειγμα Fog Nodes που επικοινωνούν με micaz αισθητήρες Με βάση τις υπηρεσίες που θέλουν να προσφέρουν: Για παράδειγμα Σύνολο αισθητήρων που ασχολούνται με την θερμοκρασία ενός χώρου Με βάση τα Policies που εφαρμόζουν τα Fog Nodes: Για παράδειγμα συζήτηση του Policy Resource management που αναφέρθηκε στο Κεφάλαιο 4.2, ώστε στη περίπτωση φόρτου ενός Fog Node, να γνωρίζει σε ποιο Fog Node να μεταφέρει τα Services του. [48]

52 Με βάση τις δομικές λειτουργίες της αρχιτεκτονικής: Για παράδειγμα η Registry θα μπορούσε να είναι ένα Topic Με βάση τα Resources: Για παράδειγμα Fog Nodes που είναι με ρεύμα και με μπαταρία Εικόνα 22: Subscription των Fog Nodes στα Topics Όταν πλέον υπάρχουν δημιουργημένα Topics και εγγεγραμμένα Fog Nodes σε αυτά, μπορούμε να δούμε την Peer-to-Peer επικοινωνία των Fog Nodes, ανάλογα με τα Topics που ακολουθούν. Στην Εικόνα 22 παρατηρούμε την επικοινωνία που συμβαίνει μεταξύ των Fog Nodes, ανάλογα με τα Topics που έχουν επιλεγεί. Να σημειωθεί ότι, συγκρίνοντας την Εικόνα 22 και Εικόνα 23, παρατηρούμε ότι κάποια Topics (στο συγκεκριμένο παράδειγμα το Topic n) δεν εμφανίζονται και στις δύο εικόνες. Αυτό συμβαίνει διότι στο Topic n, υπάρχει μόνο ένα εγγεγραμμένο Fog Node, και σαν αποτέλεσμα δεν έχει κάποια Peer-to-Peer επικοινωνία με άλλο Fog Node. Όμως αν το παράδειγμα αυτό θεωρήσουμε πως τρέξει σε πραγματικό χρόνο, τότε ενδεχομένως να υπάρξουν νέα Fog Nodes στο σύστημα, ή τα υπάρχοντα, που θα κάνουν εγγραφή στο Topic n, και τότε στην Εικόνα 23 θα είχε νόημα να αναπαρασταθεί και το Topic n σαν «οντότητα». [49]

53 Εικόνα 23: Peer-to-Peer επικοινωνία μεταξύ των Fog Nodes Το πρωτόκολλο επικοινωνίας ECTORAS, όπως αναφέρεται και από το ακρωνύμιο του, είναι ένα πρωτόκολλο το οποίο βασίζεται σε μία αποτελεσματική επικοινωνία πάνω από συστήματα αρχιτεκτονικής REST. Χρησιμοποιώ το πρότυπο DDS για μία αποτελεσματική, άμεση και πιο αξιόπιστη επικοινωνία μεταξύ των Fog Nodes, και ταυτόχρονα η Peer-to-Peer επικοινωνία, βασίζεται στο μοντέλο REST, που βάσει των αρχών του, είναι επίσης αξιόπιστο. Πιο συγκεκριμένα, η Peer-to-Peer επικοινωνία θα γίνεται με Request/Response μοντέλο και αυτά τα Requests/Responses θα είναι REST API Calls μεταξύ των Fog Nodes όπως και μεταξύ των Fog Nodes με το Registry Unit. Στην Εικόνα 24 αναλύω τα REST Calls που προτείνω στο ECTORAS protocol, για την εγγραφή (Subscribe) ενός Fog Node σε ένα Topic, και την επικοινωνία που θα δημιουργεί μετά με όλα τα άλλα Fog Nodes (Participants) του εκάστου Topic. Το πρώτο Action του Fog Node γίνεται στο Registry Unit ώστε να δηλωθεί ότι είναι παρόν. Η Registry απαντά με ένα HTTP Status Code καθώς και ένα JSON το οποίο του γνωστοποιεί το ID του στη Registry. Η επόμενη διαδικασία του Fog Node είναι να δηλώσει τι Services παρέχει, ώστε η Registry να του απαντήσει ένα JSON με τα IDs των Services. Το επόμενο Action, αποτελείται πρακτικά από 2 κλήσεις, που είναι ανεξάρτητες αλλά χρειάζεται να κληθούν με τη συγκεκριμένη σειρά. Στη πρώτη κλήση αυτού του Action, το Fog Node ζητά από τη Registry τα διαθέσιμα Topics, και η Registry απαντά τα διαθέσιμα Topics σε JSON [50]

54 Εικόνα 24: REST API Calls ενός Fog Node για το Subscribe του σε ένα Topic μορφή. Το Fog Node σε αυτό το σημείο, είναι αυτόνομο να επιλέξει σε ποια Topics πρέπει να κάνει Subscribe ανάλογα με το τι Topic θεωρεί ότι είναι σημαντικό για αυτό. Εφόσον πάρει την απόφαση, κάνει μία κλήση με HTTP verb POST, και στο body της κλήσης αναφέρει τα Topics που θέλει να κάνει Subscribe. Εφόσον το Fog Node είναι πλέον εγγεγραμμένο στα Topics που επιθυμεί, είναι η στιγμή που θα πρέπει να κάνει την Peer-to-Peer επικοινωνία με τα Fog Nodes/Participants. Για να το επιτύχει αυτό, κάνει μία κλήση στη Registry ώστε να ενημερωθεί για τους Participants του Topic. H Registry ενημερώνει με JSON απάντηση το Fog Node, και πλέον το Fog Node, έχει τη λίστα των [51]

55 Participants ώστε να κάνει τη Peer-to-Peer επικοινωνία. Τέλος το Fog Node στέλνει Request(s) με το ID του Topic καθώς και τη πληροφορία που ενδιαφέρει, σε όλους τους Participants, και οι Participants απαντούν με ένα HTTP Status Code. Όπως επισημαίνεται και στην Εικόνα 24, τα Actions εκτός του πρώτου (Register του Fog Node), μπορούν να επαναληφθούν θεωρητικά άπειρες φορές στον κύκλο ζωής ενός Fog Node. Ο λόγος για τον οποίο κάποια Actions μπορεί να επαναλαμβάνονται, είναι ότι σε ένα δυναμικό σύστημα, τα δεδομένα μπορούν να αλλάζουν κάθε διακριτή χρονική στιγμή, και η ενημέρωση των πληροφοριών συμβάλλει στην εγκυρότητα αυτών. [52]

56 Κεφάλαιο 6: Υλοποίηση πρωτοκόλλου ECTORAS Βασιζόμενη στη μοντελοποίηση του πρωτοκόλλου που πρότεινα, θα γίνει και η υλοποίηση (Proof of Concept) του πρωτοκόλλου επικοινωνίας στο σύστημα που έχω επιλέξει. Για να επιτύχουμε την παραπάνω υλοποίηση, αρχικά, πρέπει να γίνει αναφορά στη δομή μηνυμάτων του πρωτοκόλλου. Όπως έχει αναφερθεί στο Κεφάλαιο 5, το πρωτόκολλο ECTORAS θα έχει μία Publish/Subscribe επικοινωνία μεταξύ των Fog Nodes και της Registry. Για να επιτευχθεί αυτό, δημιουργήθηκαν, στη γλώσσα προγραμματισμού που ήδη χρησιμοποιείται (JAVA), παραπάνω λειτουργίες (κλάσεις) στο Registry Unit, οι οποίες δημιουργούν δυναμικά τα Topics μέσω κλήσεων URIs που γίνονται από τα Fog Nodes. Τα URIs που αφορούν τα Topics είναι τα παρακάτω: [reg_ip]:[port]/topics URI Operation Εμφάνιση της λίστας όλων των διαθέσιμων Topics [reg_ip]:[port]/topics/create Δημιουργία ενός νέου Topic [reg_ip]:[port]/topics/subscribe/[topic_id]/ [aggr_id] Εγγραφή σε ένα Topic [reg_ip]:[port]/topics/unsubscribe/[topic_id]/ [aggr_id] Απεγγραφή από ένα Topic [reg_ip]:[port]/topics/participants/ [topic_id] Λίστα με τους συμμετέχοντες ενός Topic Πίνακας 5: URIs για τη δημιουργία, εγγραφή, απεγγραφή και λίστα των Topics [53]

57 6.1 Περιγραφή των URIs και Error Handling o [reg_ip]:[port]/topics Χρησιμοποιώντας το URI /topics εμφανίζονται όλα τα διαθέσιμα topics που είναι εγγεγραμμένα στο Registry Unit. Η λίστα που στέλνει το Registry Unit στο Fog Node, είναι με δομή JSON, και είναι παρόμοιο με το JSON που φαίνεται στην Εικόνα 25. Εικόνα 25: Λίστα με τα διαθέσιμα Topics σε μορφή JSON o [reg_ip]:[port]/topics/create Χρησιμοποιώντας το URI /topics/create, το Fog Node μπορεί να δημιουργήσει ένα νέο Topic. Οι πληροφορίες που θα πρέπει να δοθούν από το Fog Node στο Registry Unit, δίνονται υπό τη μορφή JSON στο body του POST Request, όπως φαίνεται στην Εικόνα 26. Το JSON θα πρέπει να περιέχει το description του Topic, το machinedescription του Topic (γνωστό για τα Fog Nodes ώστε να αποφασίζουν σε ποιο Topic θέλουν να εγγράφονται), και το name του Topic σε User-Friendly μορφή κειμένου. [54]

58 Εικόνα 26: Απεικόνιση του POST Request που δημιουργεί το Fog Node προς τη Registry o [reg_ip]:[port]/topics/subscribe/[topic_id]/[aggr_id] Χρησιμοποιώντας το URI /topics/subscribe/[topic_id]/[aggr_id], το Fog Node μπορεί κάνει εγγραφή (Subscribe) σε ένα Topic. Για να είναι valid η εγγραφή, θα πρέπει να δώσει σωστό id του Topic, και το σωστό id του. Η απεικόνιση ενός Subscribe φαίνεται στην Εικόνα 27. Εικόνα 27: Δομή κλήσης Subscribe σε ένα Topic [55]

59 o [reg_ip]:[port]/topics/unsubscribe/[topic_id]/[aggr_id] Χρησιμοποιώντας το URI /topics/unsubscribe/[topic_id]/[aggr_id], το Fog Node κάνει αίτηση απεγγραφής από ένα Topic. Το URI έχει ίδια δομή με το URI του Subscribe, άλλάζοντας μόνο το path σε Unsubscribe, όπως φαίνεται στην Εικόνα 28. Εικόνα 28: Δομή κλήσης Unsubscribe από ένα Topic o [reg_ip]:[port]/topics/participants/[topic_id] Χρησιμοποιώντας το URI /topics/participants/[topic_id], το Fog Node μπορεί να ενημερωθεί για τους συμμετέχοντες σε ένα Topic, ανεξάρτητα εάν συμμετέχει σε αυτό ή όχι. Η απάντηση που λαμβάνει από τη Registry είναι μορφής JSON όπως φαίνεται στην Εικόνα 29. Το JSON θα περιέχει λίστα με IP του κάθε Participants, το Port του κάθε Participant και το UID του. [56]

60 Εικόνα 29: Δομή κλήσης Participants και η απάντηση JSON από τη Registry Σε όλες τις παραπάνω περιπτώσεις, αναλύω τα ενδεχόμενα, τα URIs που αιτούνται τα Fog Nodes, να είναι σωστά και έγκυρα ως προς τη δομή τους και τη πληροφορία που υπάρχει στα ids και στα body του Request (εάν αναφερόμαστε σε URI όπως του create). Για τη περίπτωση που κάποιο URI δεν πληροί τις παραπάνω προϋποθέσεις, τότε η απάντηση της Registry θα πρέπει να έχει ανάλογο μήνυμα. Δημιούργησα όλα τα πιθανές περιπτώσεις να υπάρχει λάθος στο URI, και οι περιπτώσεις είναι οι εξής: Στο URI που καλείται για το Create ενός Topic, το JSON στο body του request, όταν είναι λάθος δομημένο (λιγότερα ή περισσότερα fields από τα απαιτούμενα), το Response Registry Unit θα είναι το παρακάτω, όπως φαίνεται στην Εικόνα 30. [57]

61 Εικόνα 30: Απεικόνιση μη έγκυρης δημιουργίας ενός Topic Στα URIs Subscribe, Unsubscribe και Participants, θα εμφανίζονται HTTP Status Code Errors (400, 401, 404) ανάλογα με το λάθος που υπάρχει στο URI (λάθος topic_id, λάθος aggr_id [uid], και λάθος path του URI) και φαίνονται στις Εικόνες 31, 32 και 33. Εικόνα 31: HTTP Error μη έγκυρο ID του Fog Node [58]