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

Transcript

1 ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΑΤΡΩΝ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΤΕΧΝΟΛΟΓΙΑΣ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ ΗΛΕΚΤΡΟΝΙΚΗΣ & ΥΠΟΛΟΓΙΣΤΩΝ ΕΡΓΑΣΤΗΡΙΟ ΣΥΣΤΗΜΑΤΩΝ ΥΠΟΛΟΓΙΣΤΩΝ Διπλωματική Εργασία του φοιτητή του Τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών της Πολυτεχνικής Σχολής του Πανεπιστημίου Πατρών Ιωάννη-Φοίβου Χριστουλάκη του Χριστόδουλου με Αριθμό Μητρώου: 6663 Θέμα Το Διαδίκτυο των Αντικειμένων σε Συστήματα Βιομηχανικών Αυτοματισμών Επιβλέπων Κλεάνθης Θραμπουλίδης Αριθμός Διπλωματικής Εργασίας: Πάτρα, 08 Μαρτίου 2017

2

3 ΠΙΣΤΟΠΟΙΗΣΗ Πιστοποιείται ότι η Διπλωματική Εργασία με θέμα Το Διαδίκτυο των Αντικειμένων σε Συστήματα Βιομηχανικών Αυτοματισμών Του φοιτητή του Τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών Ιωάννη-Φοίβου Χριστουλάκη του Χριστόδουλου με Αριθμό Μητρώου: 6663 Παρουσιάστηκε δημόσια και εξετάστηκε στο Τμήμα Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών στις 08/03/2017 Ο Επιβλέπων Ο Διευθυντής του Τομέα Καθηγητής, Κλεάνθης Θραμπουλίδης Καθηγητής, Ευθύμιος Χούσος

4 Αριθμός Διπλωματικής Εργασίας: Θέμα: «Το Διαδίκτυο των Αντικειμένων σε Συστήματα Βιομηχανικών Αυτοματισμών» Φοιτητής: Ιωάννης-Φοίβος Χριστουλάκης Επιβλέπων: Κλεάνθης Θραμπουλίδης Περίληψη Το Διαδίκτυο των Αντικειμένων (IoT) πρόκειται να επηρεάσει θεμελιακά τον τρόπο που ζούμε. Οι εφαρμογές του θα επηρεάσουν σχεδόν κάθε τομέα της ανθρώπινης δραστηριότητας. Ειδικότερα στο χώρο της βιομηχανίας, αντιμετωπίζεται ως η επόμενη βιομηχανική επανάσταση. Προκλήσεις που δημιουργούνται από την αναμενόμενη ένταξη ενός νέου πληθυσμού συσκευών στο διαδίκτυο πρέπει να διευθετηθούν ούτως ώστε τα οφέλη που θα προκύψουν να ανταπεξέλθουν στις προσδοκίες αυτές. Προς την κατεύθυνση αυτή έχουν ήδη κάνει την εμφάνισή τους διάφορες τεχνολογίες που επιχειρούν να ικανοποιήσουν τις νέες ανάγκες επικοινωνίας. Στο πλαίσιο της παρούσας εργασίας μελετήθηκε η χρήση ορισμένων τέτοιων τεχνολογιών μέσω της ανάλυσης, του σχεδιασμού και, τέλος, της υλοποίησης ενός IoT-συμβατού κατανεμημένου βιομηχανικού συστήματος παραγωγής, με την έννοια πως τα επιμέρους υποσυστήματά του δεν είναι χωροταξικά συγκεντρωμένα και επικοινωνούν μεταξύ τους με τη χρήση IoT τεχνολογιών. Ειδικότερα, το κατανεμημένο σύστημα ελέγχου που αναπτύχθηκε αξιοποιεί τα πρωτόκολλα CoAP και LwM2M, τα οποία υιοθετούν τα χαρακτηριστικά εκείνα του HTTP που κατέστησαν το τελευταίο το βασικότερο πρωτόκολλο του παγκόσμιου ιστού. Ταυτόχρονα όμως είναι προσαρμοσμένα στις απαιτήσεις λειτουργίας των IoT ενσωματωμένων υπολογιστικών συστημάτων. Επιπρόσθετα, αναπτύχθηκαν και τρεις διαφορετικοί εξομοιωτές των μηχανικών τμημάτων του συστήματος παραγωγής, με τη βοήθεια των οποίων πραγματοποιήθηκαν και οι δοκιμές της σωστής λειτουργίας του συστήματος ελέγχου. Στο τέλος γίνεται μια συνολική αξιολόγηση του συστήματος και προτείνονται κατευθύνσεις προς τις οποίες μπορεί να προσανατολιστεί η περαιτέρω ανάπτυξη του. 1

5 Abstract Internet of Things in Industrial Automation Systems Internet of Things will greatly influence the way we all live. Its applications will affect almost every aspect of human activity. Particularly within the industry domain, IoT has been labeled as the next Industrial Revolution. Addressing the challenges this new concept raises is essential to unlocking the full potential it carries. Towards this direction, there have already been developed some new technologies aiming to address the emerging communication needs of the next billion connected devices. The overall goal of this work is to study some of these technologies through a process of analysis, design, and, ultimately, implementation of an IoT-compliant distributed industrial production system, in the sense that its constituent parts are (spatially) spread across relatively long distances and communicate with each other through Internet. In particular, the developed distributed control system utilizes CoAP and LwM2M protocols, which borrow the features (and properties) of HTTP that made it the foundation of data communication for the World Wide Web, while being (appropriately) adapted for the operational requirements of IoT embedded computer systems. In addition to that, three distinct emulators of the mechanical parts of the system have been developed which were employed in the testing of the control system s operation. Finally, a review of the system and the development procedure is given, along with suggestions for future development. 2

6 Πρόλογος Η εκπόνηση της παρούσας διπλωματικής εργασίας πραγματοποιήθηκε στο εργαστήριο συστημάτων υπολογιστών το διάστημα Μάρτιος 2014 Μάρτιος Θα ήθελα να ευχαριστήσω τον επιβλέποντα Καθηγητή Κ. Κλεάνθη Θραμπουλίδη για την ενθάρρυνση, καθοδήγηση, και συνεχή βοήθεια την οποία μου προσέφερε καθώς και για την εμπιστοσύνη που έδειξε στο άτομό μου σε όλη τη διάρκεια της ευρύτερης συνεργασίας μας. 3

7

8 Περιεχόμενα Περίληψη... 1 Abstract... 2 Περιεχόμενα... 5 Ευρετήριο Εικόνων... 7 Ευρετήριο Πινάκων Εισαγωγή Από το Διαδίκτυο στο Διαδίκτυο των αντικειμένων (IoT) Το Διαδίκτυο των αντικειμένων στη βιομηχανία (IIoT) Αντικείμενο της εργασίας Οργάνωση του κειμένου Γενικές πληροφορίες και βασικές έννοιες Αρχιτεκτονικό στυλ REST HTTP - CoAP Device Management Πρωτόκολλο LwM2M Γενικά Σύντομη περιγραφή των βασικών μηχανισμών του LwM2M Liqueur plant production system (LPPS) περιγραφή και απαιτήσεις Υψηλού επιπέδου σχεδιασμός του συστήματος Σχεδιασμός του API των υποσυστημάτων του LPPS API των σιλό Αναλυτική περιγραφή των LwM2M objects και των resources τους Παρατηρήσεις API των κοινόχρηστων πόρων Σχεδιασμός των γραμμών παραγωγής Ανάπτυξη του συστήματος ελέγχου Γενικά - Επιλογή hardware και software

9 5.2. LwM2M Clients Περιγραφή του βασικού leshan framework για τους LwM2M clients Δομή των σιλό Δομή των κοινόχρηστων πόρων LwM2M servers Περιγραφή του βασικού leshan framework για τους LwM2M servers Ανάπτυξη των server Εξομοιωτής του μηχανικού σιλό Περιγραφή Προδιαγραφές - Απαιτήσεις Software Silo Emulator Hardware Silo Emulator Hardware Software IEC61131 εξομοιωτής Εισαγωγή κίνητρα Γενική περιγραφή Δομή Silo driver IEC61131 Layer Δοκιμές Συμπεράσματα Μελλοντικές Βελτιώσεις Δοκιμές Συμπεράσματα Βελτιώσεις Παράρτημα Α: Πηγαίος Κώδικας Ακρωνύμια Αναφορές

10 Ευρετήριο Εικόνων Εικόνα 2-1: σχηματική αναπαράσταση της δομής ενός LwM2M client Εικόνα 3-1: Σχηματική αναπαράσταση του συστήματος παραγωγής liqueur Εικόνα 4-1: state chart διάγραμμα της κατάστασης του σιλό (Silo Object/state resource) Εικόνα 4-2: sequence διάγραμμα αλληλεπίδρασης με έναν κοινόχρηστο πόρο Εικόνα 4-3: activity διάγραμμα για τη γρ. παραγωγής # Εικόνα 4-4: activity διάγραμμα για τη γρ. παραγωγής # Εικόνα 4-5: στοιχειώδη activities για τις δύο γραμμές παραγωγής Εικόνα 5-1: Concept map του leshan framework για έναν LwM2M client Εικόνα 5-2: LwM2mInstanceEnabler interface Εικόνα 5-3: Component διάγραμμα του σιλό Εικόνα 5-4: Μέρος του Διαγράμματος κλάσεων του σιλό Εικόνα 5-5: Μέρος του διαγράμματος κλάσεων του κοινόχρηστου πόρου Εικόνα 5-6: μέρος του διαγράμματος κλάσεων του server Εικόνα 5-7: μέρος του διαγράμματος κλάσεων του server Εικόνα 5-8: sequence διάγραμμα αποστολής notify μηνυμάτων. Α)αρχικός σχεδιασμός, Β) αναθεωρημένος σχεδιασμός Εικόνα 5-9: State chart διάγραμμα γρ. παραγωγής # Εικόνα 5-10: State chart διάγραμμα γρ. παραγωγής # Εικόνα 5-11: εναλλακτικός σχεδιασμός της INITIALIZING κατάστασης του statechart διαγράμματος της γρ. παραγωγής # Εικόνα 5-12: μέρος του διαγράμματος κλάσεων του server Εικόνα 6-1: Γραφική διεπαφή του 1 ου εξομοιωτή σιλό Εικόνα 6-2: Διάγραμμα κλάσεων του 1ου εξομοιωτή σιλό Εικόνα 6-3: 3-D απεικόνιση του τελικού κυκλώματος του 2 ου εξομοιωτή σιλό Εικόνα 6-4: Διάγραμμα κλάσεων του 1 ου εξομοιωτή σιλό Εικόνα 6-5: Διάγραμμα κλάσεων του προγράμματος που εκτελείται στον μικροελεγκτή του κυκλώματος Εικόνα 7-1: Τα βασικά components του 3 ου εξομοιωτή σιλό και οι διεπαφές ανάμεσά τους Εικόνα 7-2: Διάγραμμα κλάσεων του silo driver component του 3 ου εξομοιωτή σιλό

11 Ευρετήριο Πινάκων Πίνακας 4-1: LwM2M objects των σιλό. *R=Readable,O=Observable,W=Writable,E=Executable Πίνακας 4-2: common resource LwM2M object Πίνακας 4-3: Αλγόριθμοι για τις δύο γραμμές παραγωγής liqueur Πίνακας 6-1: Μηχανισμός της βιβλιοθήκης Pi4J που αξιοποιείται για κάθε συνδυασμό αποστολέα/είδος μηνύματος Πίνακας 6-2: κωδικοποίηση αναπαράστασης εισόδων του σιλό με ένα byte Πίνακας 6-3: κωδικοποίηση κατάστασης του σιλό με μία 16-bit λέξη Πίνακας 7-1: Κωδικοποίηση χαρακτήρων για αποστολή στο cod2j named pipe Πίνακας 7-2: Κωδικοποίηση χαρακτήρων για αποστολή στο j2cod named pipe

12 1. Εισαγωγή 1.1. Από το Διαδίκτυο στο Διαδίκτυο των αντικειμένων (IoT) Το Διαδίκτυο είναι μια εξελισσόμενη οντότητα μεγαλώνει σε σημασία, ενώ μέσω της εξάπλωσής και των νέων τρόπων αξιοποίησής του δημιουργείται επιπρόσθετη αξία. Το Διαδίκτυο ξεκίνησε ως το Διαδίκτυο των υπολογιστών, ένα παγκόσμιο δίκτυο με υπηρεσίες όπως ο παγκόσμιος ιστός. Την τελευταία δεκαετία πήρε τη μορφή ενός Διαδικτύου των ανθρώπων, δημιουργώντας νέες έννοιες όπως το Web 2.0, στο οποίο το περιεχόμενο δημιουργείται και καταναλώνεται από συνδεδεμένους ανθρώπους [1]. Αυτή η τάση γίνεται ιδιαίτερα εμφανής από τη μαζική ανάπτυξη που είχαν τα μέσα κοινωνικής δικτύωσης (για παράδειγμα το facebook με 1.71 δισεκατομμύρια ενεργούς χρήστες [2] ή το twitter με 310 εκατομμύρια ενεργούς χρήστες [3]). Η τεχνολογική πρόοδος διευρύνει καθημερινά τα όρια του Διαδικτύου. Η πρόσβαση σε αυτό φτάνει συνεχώς σε όλο και περισσότερα σημεία με όλο και μικρότερο κόστος. Η επεξεργαστική ισχύς και η μνήμη των ηλεκτρονικών συσκευών με δυνατότητες διασύνδεσης γίνονται όλο και μεγαλύτερες ενώ το μέγεθος και το κόστος τους όλο και μικρότερο. Επιπλέον οι συσκευές αυτές εμπεριέχουν ή/και μπορούν να συνδεθούν με αισθητήρες και actuators, θολώνοντας τα όρια μεταξύ φυσικού και ψηφιακού κόσμου. Ο συνδυασμός των παραπάνω δημιουργεί ένα περιβάλλον όπου είναι πλέον δυνατή η ενσωμάτωση νοημοσύνης και επικοινωνιακών δυνατοτήτων στα περισσότερα από τα αντικείμενα που μας περιβάλλουν [4]. Συντελείται έτσι μια μετάβαση από το Διαδίκτυο των ανθρώπων στο Διαδίκτυο των αντικειμένων, όπου ως αντικείμενο νοείται κάθε αντικείμενο του φυσικού κόσμου (φυσικά αντικείμενα) ή του πληροφοριακού κόσμου (εικονικά αντικείμενα), το οποίο είναι ικανό να αναγνωριστεί μοναδικά (uniquely identified) και να ενταχθεί σε ένα επικοινωνιακό δίκτυο [5]. To IoT αναγνωρίζεται ως μια από τις πλέον αναδυόμενες τεχνολογίες στον τομέα της πληροφορικής [6]. Η επέκταση του διαδικτύου που θα επιφέρει το IoT σε νέους τομείς, είναι συγκρίσιμη σε κλίμακα με τη διάδοση που είχε το διαδίκτυο τη δεκαετία του 90 [7]. Ενδεικτικά προβλέπεται πως το 2020, θα υπάρχουν παγκοσμίως 50 δισεκατομμύρια συνδεδεμένες συσκευές [8] και πως στα επόμενα 15 χρόνια, κάθε σπίτι και εταιρεία στον πλανήτη θα έχει επηρεαστεί με κάποιο τρόπο από το IoT [9]. Σήμερα η πλειονότητα των συνδέσεων στο διαδίκτυο παγκοσμίως γίνεται από συσκευές τις οποίες χειρίζονται απευθείας άνθρωποι, για παράδειγμα pc s και smartphones. Η μορφή αυτή επικοινωνίας μεταξύ τέτοιων συσκευών ονομάζεται human to human. Στο, όχι πολύ μακρινό, μέλλον το πλήθος των διασυνδεδεμένων αντικειμένων θα υπερβαίνει κατά πολύ το πλήθος των ανθρώπων και οι 9

13 άνθρωποι θα αποτελούν μια μειοψηφία στην παραγωγή και κατανάλωση πληροφορίας. Επομένως η πλειονότητα των συνδέσεων δεν θα είναι άνθρωποι που επικοινωνούν με ανθρώπους, ούτε άνθρωποι που καταναλώνουν πληροφορίες, αλλά αντικείμενα (ή αλλιώς μηχανήματα) που ανταλλάσσουν πληροφορίες απ ευθείας με άλλα μηχανήματα [10] για λογαριασμό ανθρώπων ή με άλλα λόγια επικοινωνία M2M (machine to machine) Το Διαδίκτυο των αντικειμένων στη βιομηχανία (IIoT) Από τη στιγμή που χρησιμοποιήθηκαν τα πρώτα PLC για την αυτοματοποίηση της παραγωγής, οι βιομηχανίες συλλέγουν δεδομένα για τις επιχειρησιακές τους διεργασίες και διαχειρίζονται αυτές μέσω συστημάτων SCADA και δικτύων M2M. Σήμερα όμως λόγω της προόδου που έχει επέλθει στους τομείς της υπολογιστικής ισχύος, της χαμηλού κόστους μνήμης, της ασύρματης συνδεσιμότητας και της κατασκευής φθηνών, αξιόπιστων και υψηλής ανάλυσης (resolution) αισθητήρων, το πλήθος των σημείων της διαδικασίας παραγωγής τα οποία μπορούν να παρακολουθούνται, να ελέγχονται και να συντονίζονται μεταξύ τους αυξάνεται δραματικά. Αυτή η τάση που υπάρχει σήμερα είναι στην ουσία η εφαρμογή της ιδέας του IoT στη βιομηχανία και ονομάζεται IIoT (Industrial IoT). Ένα από τα αποτέλεσμα αυτής της διαδικασίας είναι τα συστήματα ελέγχου της παραγωγής να έχουν μια πολύ πιο ολοκληρωμένη και λεπτομερή εικόνα της διαδικασίας παραγωγής σε κάθε σημείο της και για κάθε χρονική στιγμή. Η ανάλυση των νέων αυτών δεδομένων αυτών οδηγεί σε βελτιστοποίηση της διαδικασίας παραγωγής και σε μείωση του συνολικού κόστους παραγωγής δηλαδή τελικά στην αύξηση της λειτουργικής απόδοσης. Ενδεικτικά, αυξάνοντας το επίπεδο αυτοματισμού των διεργασιών και εισάγοντας πιο ευέλικτες μεθόδους παραγωγής, η παραγωγικότητα μπορεί να αυξηθεί έως και 30%. Η εφαρμογή της προγνωστικής συντήρησης (predictive maintenance), η οποία είναι ένας τομέας υψηλού ενδιαφέροντος, είναι οικονομικότερη κατά 12% από την προγραμματισμένη συντήρηση και δύναται να μειώσει το συνολικό κόστος συντήρησης έως και 30% αλλά και την εμφάνιση βλαβών έως και 70% [11]. Με τη διασύνδεση των βιομηχανικών συστημάτων παραγωγής με διάφορα άλλα συστήματα, συσκευές, βιομηχανίες και καταναλωτές μέσω του Διαδικτύου δημιουργούνται επιπλέον νέες δυνατότητες όπως [12]: Μαζική εξατομίκευση - Δημιουργία εξατομικευμένων προϊόντων με μικρούς χρόνους παράδοσης: Πάντοτε υπήρχε ένας συμβιβασμός που έπρεπε να κάνει ένας κατασκευαστής μεταξύ εξατομίκευσης των προϊόντων και μαζικής παραγωγής τους. Το IIoT μέσα από το δικτυωμένο έξυπνο εργοστάσιο κάνει δυνατή την εξατομίκευση των προϊόντων σε κλίμακα μαζικής παραγωγής. 10

14 Συνεργασία ανθρώπου μηχανής. Αύξηση της ασφάλειας και της παραγωγικότητας: Η συνεργασία ανθρώπου μηχανής μπορεί να διαχωριστεί σε φορητές διεπαφές ανθρώπου μηχανής (mobile Human-Machine Interfaces, HMI) και συνεργατικά συστήματα ανθρώπου μηχανής (Human-Machine Collaborative Systems, HMCS). Οι ΗΜΙ τεχνολογίες (π.χ. κινητά τηλέφωνα, ταμπλέτες, φορούμενα (wearable) ηλεκτρονικά) σε συνδυασμό με πρόσβαση στο διαδίκτυο θα αλλάξουν ριζικά τον τρόπο που οι χειριστές των μηχανών και οι μηχανικοί θα παρακολουθούν και θα χειρίζονται την παραγωγή. Η φυσική παρουσία του προσωπικού στο χώρο διαχείρισης δε θα είναι απαραίτητη (πράγμα που αυξάνει την ασφάλειά του) και οι ικανότητες του χειριστή διευρύνονται με τρόπους όπως άμεση πρόσβαση σε online εγχειρίδια μηχανών και δυνατότητες εικονικής πραγματικότητας για την καλύτερη παρακολούθηση της παραγωγής και τον εντοπισμό προβλημάτων. Οι HMCS τεχνολογίες στοχεύουν στην κατασκευή ευέλικτων ρομποτικών συστημάτων για κατασκευαστές μικρής κλίμακας οι οποίοι τροποποιούν συχνά τις γραμμές παραγωγής τους. Η δυνατότητα ανάλυσης αλυσίδας ενεργειών (Action sequence analysis) θα δίνει τη δυνατότητα στα ρομποτικά συστήματα αυτά να μαθαίνουν δυναμικά νέες εργασίες όπως η συναρμολόγηση κάποιου προϊόντος με επαναληπτικές μεθόδους αντί για προγραμματισμό, πράγμα που μπορεί εύκολα να γίνει από ένα εργαζόμενο χωρίς γνώσεις προγραμματισμού. Ενοποίηση της παγκόσμιας αλυσίδας εφοδιασμού από τον προμηθευτή μέχρι τον καταναλωτή: Η παγκοσμιοποίηση της αγοράς και των αλυσίδων εφοδιασμού, αν και εξαιρετικά κερδοφόρα για τους κατασκευαστές, δημιουργεί ορισμένα προβλήματα. Οι κατασκευαστές απαιτείται να λαμβάνουν υπ όψη τους πολλούς παράγοντες όπως οι τρέχουσες τιμές, διαθεσιμότητες, χρόνοι παράδοσης, ποιοτικές προδιαγραφές και αποθέματα πρώτων υλών, μηχανών και εργαλείων. Στα πλαίσια του IIoT αναπτύσσονται εργαλεία τα οποία παρέχουν ενοποιημένη πρόσβαση σε πραγματικό χρόνο στις πληροφορίες αυτές (για παράδειγμα συστήματα εντοπισμού θέσης αντικειμένων) πράγμα που ενισχύει την παραγωγικότητα, την ποιότητα της παραγωγής και την ασφάλεια στο χώρο εργασίας. Η έλευση του IIoT αναμένεται να έχει τόσο έντονο αντίκτυπο σε όλη τη διαδικασία της παραγωγής ώστε τελικά να οδηγήσει στην επονομαζόμενη τέταρτη βιομηχανική επανάσταση. Οι πιο αισιόδοξες προβλέψεις κάνουν λόγο για παραγωγή επιπρόσθετης αξίας παγκοσμίως από το IIoT της τάξης των 15 τρισεκατομμυρίων δολαρίων μέχρι το 2030 [11]. Φυσικά μια τόσο μεγαλεπήβολη ιδέα συνοδεύεται από πλήθος προκλήσεων που πρέπει να αντιμετωπιστούν ώστε τα οφέλη που θα προκύψουν να είναι τα αναμενόμενα. Οι δύο μεγαλύτερες προκλήσεις για την επιτυχία του IIoT και την εξασφάλιση του μέγιστου δυνατού οφέλους από αυτό, είναι μάλλον η διαλειτουργικότητα μεταξύ μηχανών και γενικότερα συσκευών και η ασφάλεια (security) των δεδομένων [13]. Παρά τη σημαντικότητά της τελευταίας, η παρούσα εργασία δεν ασχολείται με το θέμα της ασφάλειας αλλά εστιάζει στο ζήτημα της διαλειτουργικότητας. 11

15 Σημειώνεται πως σύμφωνα με το [14], η διαλειτουργικότητα μεταξύ των συστημάτων που θα απαρτίζουν το IIoT είναι απαραίτητη για το κατά μέσο όρο 40% της αναμενόμενης αξίας που θα δημιουργηθεί από την πραγματοποίησή του Αντικείμενο της εργασίας Αντικείμενο της παρούσας εργασίας είναι η μελέτη της δυνατότητας ικανοποίησης των επικοινωνιακών αναγκών των σύγχρονων και μελλοντικών IIoT συστημάτων από το συνδυασμό των πρωτοκόλλων επιπέδου εφαρμογής CoAP και LwM2M. Η διαδικασία αυτή γίνεται μέσα από την ανάπτυξη ενός IoT-συμβατού κατανεμημένου βιομηχανικού συστήματος παραγωγής, με την έννοια πως τα επιμέρους υποσυστήματά του δεν είναι χωροταξικά συγκεντρωμένα και επικοινωνούν αξιοποιώντας τα πρωτόκολλα αυτά. Το σύστημα παραγωγής αποτελείται βασικά από τέσσερα σημεία επεξεργασίας πρώτων υλών τα οποία χρησιμοποιούνται ταυτόχρονα από δύο γραμμές παραγωγής διαφορετικών προϊόντων. Αναπτύχθηκε ένα κατανεμημένο σύστημα ελέγχου του συστήματος παραγωγής καθώς και τρεις διαφορετικοί εξομοιωτές των μηχανικών τμημάτων του, με τη βοήθεια των οποίων πραγματοποιήθηκαν και οι δοκιμές της σωστής λειτουργίας του συστήματος ελέγχου Οργάνωση του κειμένου Στο κεφάλαιο 1 γίνεται μια εισαγωγή στην έννοια του Διαδικτύου των αντικειμένων και στο περιεχόμενο της εργασίας. Στο κεφάλαιο 2 γίνεται μια σύντομη περιγραφή του αρχιτεκτονικού στυλ REST και των δύο πρωτοκόλλων επικοινωνίας (CoAP και LwM2M) τα οποία ακολουθούν το στυλ αυτό και αξιοποιούνται για την επικοινωνία των επιμέρους τμημάτων του συστήματος παραγωγής που αναπτύχθηκε. Στο κεφάλαιο 3 γίνεται μια λεπτομερής περιγραφή των μηχανικών τμημάτων του συστήματος και της διάταξής τους και στη συνέχεια παρατίθενται οι απαιτήσεις λειτουργίας του συστήματος παραγωγής. Στο κεφάλαιο 4 παρουσιάζεται η διαδικασία σχεδιασμού των δομών εκείνων του LwM2M πρωτοκόλλου μέσα από τις οποίες τα διάφορα υποσυστήματα του συστήματος παραγωγής θα επικοινωνούν μεταξύ τους. Στο κεφάλαιο 5 παρουσιάζεται η διαδικασία ανάπτυξης του απαραίτητου για τη λειτουργία του συστήματος λογισμικού, τα εργαλεία που χρησιμοποιήθηκαν, τα προβλήματα που αντιμετωπίστηκαν και οι λύσεις που επιλέχθηκαν. 12

16 Στο κεφάλαιο 6 περιγράφονται οι δύο από τους τρεις εξομοιωτές των μηχανικών υποσυστημάτων που αναπτύχθηκαν, ένας υλοποιημένος εξ ολοκλήρου σε λογισμικό και ένας ως συνδυασμός υλικού και λογισμικού. Στο κεφάλαιο 7 περιγράφεται ο τρίτος εξομοιωτής, ο οποίος είναι μια παραλλαγή του ενός από τους προηγούμενους, τροποποιημένος ώστε να λειτουργεί σε συνδυασμό με παραδοσιακά ελεγχόμενα από PLC s συστήματα παραγωγής. Στο κεφάλαιο 8 περιγράφονται οι δοκιμές για τον έλεγχο της σωστής λειτουργίας του συστήματος, ορισμένα συμπεράσματα και προτεινόμενες μελλοντικές βελτιώσεις του. 13

17

18 2. Γενικές πληροφορίες και βασικές έννοιες 2.1. Αρχιτεκτονικό στυλ REST Η μεγάλη ανάπτυξη που είχε την τελευταία δεκαετία ο τομέας των ενσωματωμένων συστημάτων συνετέλεσε στη δημιουργία πολλών μικρών υπολογιστών όπου σχεδόν κάθε τύπος αισθητήρα/actuator μπορεί να συνδεθεί. Διασυνδέοντας ασύρματα αυτούς τους μικρούς υπολογιστές εμφανίζονται νέοι τρόποι αλληλεπίδρασης με το φυσικό κόσμο. Αυτά τα δίκτυα κατανεμημένων υπολογιστών ονομάζονται WSN (wireless sensor networks) και αποτελούν εξαιρετικά χρήσιμα εργαλεία για την παρακολούθηση του φυσικού κόσμου [15]. Λόγω έλλειψης standards μέχρι πριν λίγα χρόνια στον τομέα αυτό, οι περισσότερες εφαρμογές βασίζονταν σε λογισμικό (software) και υλικό (hardware), διαφορετικό για κάθε εφαρμογή και συχνά ασύμβατο μεταξύ των εφαρμογών, δημιουργώντας ένα έντονα ανομοιογενές περιβάλλον όπου η ανάπτυξη ακόμα και σχετικά απλών εφαρμογών απαιτούσε ιδιαίτερες γνώσεις, ικανότητα και χρόνο. Επιπλέον μεγάλο μέρος της βασικής (και κοινής σε πολλές εφαρμογές) λειτουργικότητας έπρεπε να αναπτύσσεται ξανά και ξανά αφού η επαναχρησιμοποίησή της( π.χ. με τη μορφή βιβλιοθηκών) δεν ήταν δυνατή σε έναν ικανοποιητικό βαθμό. Μια τέτοια κατάσταση αποτελεί και τροχοπέδη στη δημιουργία εφαρμογών οι οποίες χρησιμοποιούν περισσότερα WSN s, διαφορετικών τεχνολογιών αλλά και στη γενικότερη συνεργασία διαφορετικών WSN μεταξύ τους. Μιας και όπως προαναφέρθηκε, ένα μεγάλο μέρος του IoT αφορά ενσωματωμένα συστήματα, γίνεται σαφές πως για να διευκολυνθεί η ευρεία αποδοχή του IoT, είναι απαραίτητοι μηχανισμοί απλοποίησης και διευκόλυνσης της ανάπτυξης εφαρμογών ταυτόχρονα με την μεγιστοποίηση της διαλειτουργικότητας μεταξύ των συστημάτων που το αποτελούν. Ένας τρόπος να εκπληρωθούν τα παραπάνω ζητούμενα είναι η ευρεία υιοθέτηση κοινής αρχιτεκτονικής, αρχικά σε επίπεδο δικτύου, το οποίο επιτυγχάνεται με τα 6LoWPAN standards [16] και στη συνέχεια σε επίπεδο εφαρμογών για το οποίο μια πολλά υποσχόμενη ιδέα είναι το web of things [17], κατά την οποία τα έξυπνα αντικείμενα και οι υπηρεσίες που παρέχουν ενσωματώνονται πλήρως στον παγκόσμιο ιστό (world wide web) επαναχρησιμοποιώντας τεχνολογίες και μοτίβα τα οποία έχουν χρησιμοποιηθεί ευρέως για το παραδοσιακό περιεχόμενο του web [17]. Αυτή η προσέγγιση επιτυγχάνει τη χαλαρή ζεύξη (loose coupling) μεταξύ των τμημάτων που αποτελούν μια 15

19 κατανεμημένη εφαρμογή, ιδιότητα κλειδί για την επίτευξη της ζητούμενης διαλειτουργικότητας [15]. Υπάρχουν αρκετά πρωτόκολλα για την παροχή και χρήση υπηρεσιών μέσω web όπως τα SOAP, WSDL, UDDI (γνωστά και ως WS-* τεχνολογίες) αλλά τα τελευταία χρόνια το αρχιτεκτονικό στυλ REST [18] έκανε την εμφάνισή του ως μια εναλλακτική με πολλαπλά προτερήματα απέναντι σε αυτές [19]. Το REST περιστρέφεται γύρω από την έννοια του resource το οποίο στο πλαίσιο αυτό είναι το κάθε δομικό στοιχείο μιας εφαρμογής το οποίο αξίζει να αναγνωρίζεται μοναδικά και να αντιστοιχίζεται σε ένα μοναδικό URI [17] και χαρακτηρίζεται από τέσσερις βασικές ιδιότητες [19]: 1. Τα resources αναπαριστούν αφαιρετικά την κατάσταση της εφαρμογής και τις οντότητες στο server δηλαδή κάθε στοιχείο που μπορεί να είναι ο προορισμός ενός υπερσυνδέσμου αποτελεί ένα resource. 2. Κάθε resource αντιστοιχίζεται με ένα μοναδικό URI. 3. Όλα τα resources μοιράζονται μια κοινή διεπαφή ( πχ τις μεθόδους του πρωτοκόλλου HTTP) για να αλληλεπιδρούν με εφαρμογές κάποιου client. 4. Η αλληλεπίδραση με ένα resource είναι πάντα stateless (statelessness: κάθε αίτημα από τον client στο server πρέπει να περιέχει όλες τις απαραίτητες πληροφορίες για την εξυπηρέτησή του και δε μπορεί να εκμεταλλευτεί κανένα αποθηκευμένο context στο server. Η κατάσταση της συνεδρίας (session) δηλαδή είναι εξ ολοκλήρου αποθηκευμένη στον client) Πέρα από το κύριο ζητούμενο που είναι η χαλαρή ζεύξη μεταξύ των τμημάτων μιας κατανεμημένης εφαρμογής, οι υπηρεσίες του ιστού βασισμένες στο REST παρουσιάζουν μια σειρά από επιπλέον πλεονεκτήματα για την υιοθέτησή του στην ανάπτυξη του IoT: Οι υπηρεσίες του ιστού βασισμένες στο REST θεωρούνται απλές επειδή με τη λογική του είναι σχεδιασμένα ευρέως χρησιμοποιούμενα πρωτόκολλα (HTTP, XML, URI) και η μόνη απαιτούμενη υποδομή είναι ο παγκόσμιος ιστός ο οποίος βρίσκεται ήδη παντού με την έννοια πως οι περισσότερες γλώσσες προγραμματισμού και τα λειτουργικά συστήματα υποστηρίζουν εγγενώς (natively) τα πρωτόκολλα που χρησιμοποιούνται σε αυτόν. Αυτό συνεπάγεται και το δεύτερο πλεονέκτημα των υπηρεσιών αυτών, τις χαμηλές τους απαιτήσεις σε πόρους επεξεργασίας και μνήμης. Το τελευταίο πλεονέκτημα έρχεται να ενισχύσει το γεγονός πως ένας RESTful server δεν αποθηκεύει πληροφορίες συνεδρίας με αποτέλεσμα να αποδεσμεύεται γρηγορότερα μνήμη και να απλοποιείται περεταίρω η υλοποίησή του. Αυτό συμβάλλει επιπλέον και στην αυξημένη επεκτασιμότητα που χαρακτηρίζει τις υπηρεσίες αυτές [18]. Έχει σημασία να επισημανθεί πως το REST δεν περιγράφει κάποιο συγκεκριμένο πρωτόκολλο αλλά είναι μόνο ένα στυλ σχεδιασμού πρωτοκόλλων επικοινωνίας. 16

20 2.2. HTTP - CoAP Αρκετές επιστημονικές δημοσιεύσεις προτείνουν τη χρήση του HTTP για την ομαλή ανάπτυξη του IoT (και κυρίως της M2M επικοινωνίας) επάνω στην ήδη υπάρχουσα υποδομή του διαδικτύου [20]. Αυτή η πρόταση είναι εύλογη αφού το HTTP είναι το πιο ευρέως χρησιμοποιούμενο RESTful πρωτόκολλο με αποτέλεσμα όποια εφαρμογή το υιοθετήσει να έχει μεγάλη συμβατότητα με την ήδη υπάρχουσα δικτυακή υποδομή (software και hardware). Επιπλέον περιλαμβάνει αξιόπιστες και καλά δοκιμασμένες δυνατότητες κρυπτογράφησης(https). Όμως το HTTP δεν είναι σχεδιασμένο για την Μ2Μ επικοινωνία η οποία παρουσιάζει κάποιες σημαντικές διαφορές από την human-based (H2H και H2M) επικοινωνία. Η προερχόμενη από τον άνθρωπο δικτυακή κίνηση είτε παρουσιάζει αιχμές και διαστήματα αδράνειας (περιήγηση στο web), είτε αφορά μετάδοση μεγάλων πακέτων δεδομένων (μεταφορά αρχείων) είτε μετάδοση σταθερού ή μεταβλητού ρυθμού (VoIP, video). Σε αντιδιαστολή, η M2M δικτυακή κίνηση θα αποτελείται κυρίως από μικρές σε μέγεθος και με μεγάλη χρονική απόσταση μεταξύ τους μεταδόσεις δεδομένων [21]. Επιπλέον ένα μέρος της διαδρομής του δικτύου που θα ακολουθούν τα δεδομένα θα είναι μέσα σε δίκτυα χαμηλής ισχύος και με υψηλό ποσοστό απώλειας δεδομένων (Low power and Lossy Networks ή LLN) [20]. Έτσι λοιπόν ένα κατάλληλο για την M2M επικοινωνία πρωτόκολλο πρέπει να μεγιστοποιεί την εξοικονόμηση ενέργειας, να είναι αποδοτικό όταν χρησιμοποιείται σε LLN s και να είναι σχετικά ελαφρύ ώστε να εκτελείται σε μικρών δυνατοτήτων (μνήμης και επεξεργαστικής ισχύος) ενσωματωμένα συστήματα. Τέλος θεωρούνται πολύ σημαντικές δυνατότητες ασύγχρονης επικοινωνίας, multicast [20] και εντοπισμού resources [7]. Από τις παραπάνω απαιτήσεις γίνονται ξεκάθαρες οι αδυναμίες του HTTP για τη χρήση του στην M2M επικοινωνία αφού το TCP, στο οποίο βασίζεται το HTTP, έχει προβλήματα απόδοσης σε LLNs και το overhead που εισάγει είναι πολύ μεγάλο για μικρής διάρκειας δοσοληψίες (short-lived transactions) [20]. Επιπρόσθετα το HTTP δε διαθέτει κάποιο μηχανισμό για αποστολή multicast και εντοπισμού resources. Γι αυτό και o οργανισμός IETF συνέστησε την ομάδα εργασίας CoRE (Constrained RESTful Environments) προκειμένου να εργαστεί στην δημιουργία ενός πλαισίου λειτουργίας resourceoriented εφαρμογών σχεδιασμένων να λειτουργούν επάνω σε περιορισμένων δυνατοτήτων IP δίκτυα [22]. Η ομάδα εργασίας αυτή δημιούργησε το CoAP (Constrained Application Protocol), ένα ειδικού σκοπού RESTful πρωτόκολλο επιπέδου εφαρμογής σχεδιασμένο για χρήση σε περιορισμένων δυνατοτήτων δίκτυα και κόμβους. Το CoAP ακολουθεί όπως και το HTTP τις αρχές του REST. Κάθε ορισμένο resource αντιστοιχίζεται με ένα URI από το οποίο και γίνεται δυνατή η stateless πρόσβαση σε αυτό με μεθόδους που 17

21 περιλαμβάνουν τις GET, PUT, POST, DELETE. Το CoAP όμως δεν αποτελεί μια συμπιεσμένη έκδοση του HTTP. Υποστηρίζει ένα υποσύνολο των δυνατοτήτων του HTTP οι οποίες έχουν επανασχεδιασθεί λαμβάνοντας υπ όψη συντελεστές όπως χαμηλή κατανάλωση ενέργειας και μικρή επεξεργαστική ισχύς των κόμβων στους οποίους θα εκτελείται. Επιπροσθέτως διάφοροι μηχανισμοί έχουν τροποποιηθεί και νέες λειτουργίες έχουν προστεθεί για να γίνει το πρωτόκολλο κατάλληλο για IoT και M2M εφαρμογές. Ως αποτέλεσμα το CoAP έχει σημαντικά μικρότερο header overhead και πολυπλοκότητα της διαδικασίας του parsing από το HTTP. Χρησιμοποιεί δυαδικό header με μέγεθος 4 bytes το οποίο ακολουθείται προαιρετικά από κάποιες επιλογές και το payload. Υποστηρίζεται προαιρετικά η αξιόπιστη μεταφορά δεδομένων αλλά και η ασφαλής σύνδεση με τη χρήση του πρωτοκόλλου DTLS. Το βασικό μοντέλο αλληλεπίδρασης του CoAP είναι παρόμοιο με εκείνο του HTTP. Ένας client αποστέλλει ένα αίτημα με το οποίο αιτείται την εφαρμογή μιας μεθόδου (από τις GET, PUT, POST, DELETE) με τη μορφή ενός κωδικού μεθόδου σε ένα resource (με τη μορφή ενός URI) στο server. O server αφού επεξεργαστεί το αίτημα απαντάει με ένα μήνυμα που περιέχει ένα κωδικό απάντησης και ίσως κάποιο payload. Σε αντίθεση με το HTTP, το CoAP χειρίζεται αυτές τις ανταλλαγές μηνυμάτων ασύγχρονα χρησιμοποιώντας το UDP ως πρωτόκολλο επιπέδου μεταφοράς. Αυτό, σε σχέση με το TCP στο οποίο βασίζεται το HTTP, έχει πολλαπλά προτερήματα: Υποστήριξη multicast αιτημάτων. Δίνεται η δυνατότητα για point-to-multipoint επικοινωνία, χαρακτηριστικό που πολύ συχνά απαιτείται στις εφαρμογές αυτοματισμού [7]. Δραστική μείωση του overhead που εισάγει το επίπεδο μεταφοράς. Ελαφρύτερη υλοποίηση σε σχέση με έναν TCP-based server Μια σημαντική απαίτηση της ομάδας εργασίας CoRE κατά το σχεδιασμό του CoRE ήταν να εξασφαλιστεί η απλή αντιστοίχιση μεταξύ HTTP και CoAP ώστε η εναλλαγή μεταξύ των δύο πρωτοκόλλων (π.χ. σε ένα cross-proxy ή σε ένα gateway) να είναι δυνατή [23]. Αφού λοιπόν το CoAP είναι ένα RESTful πρωτόκολλο και άρα έχει παρόμοια λειτουργικότητα με το HTTP, είναι αρκετά σαφής και απλή η αντιστοίχιση από το CoAP στο HTTP και το αντίστροφο. Αυτή η μετατροπή μπορεί να γίνεται σε έναν cross-protocol proxy ή/και σε ένα gateway, λειτουργίες οι οποίες έχουν κεντρικό ρόλο στην αρχιτεκτονική συστημάτων περιορισμένων δυνατοτήτων [7], [23]. Η δυνατότητα εντοπισμού resources είναι σημαντική για τις αλληλεπιδράσεις M2M [7] και υλοποιείται στο CoAP με τον παρακάτω τρόπο: Ένα URI /.well-known/core ορίζεται στο server ως το resource το οποίο με την εφαρμογή της μεθόδου GET, επιστρέφει ως απάντηση μια λίστα με συνδέσμους (στη μορφή CoRE Link Format) προς τα resources που δημοσιοποιούνται από τον server αυτό. 18

22 Το REST μοντέλο επικοινωνίας περιλαμβάνει έναν client ο οποίος ανταλλάζει αναπαραστάσεις από resources με ένα server, όπου η αναπαράσταση αυτή αποτυπώνει την τρέχουσα ή την επιθυμητή κατάσταση ενός resource. Έτσι ένας client που ενδιαφέρεται για την κατάσταση ενός resource, αποστέλλει ένα αίτημα στο server. Στη συνέχεια ο server επιστρέφει μια απάντηση με την αναπαράσταση του resource η οποία ισχύει για τη στιγμή που έγινε το αίτημα. Αυτό το μοντέλο δε δουλεύει καλά όταν ο client ενδιαφέρεται να έχει μια τρέχουσα αναπαράσταση ενός resource για μεγάλο χρονικό διάστημα. Οι ήδη υπάρχουσες προσεγγίσεις με χρήση του HTTP (όπως polling και HTTP long polling) εισάγουν σημαντική πολυπλοκότητα και/ή overhead και άρα είναι λιγότερο κατάλληλες για χρήση σε περιορισμένων δυνατοτήτων περιβάλλοντα (constrained environments) [24]. Το CoAP περιλαμβάνει τον μηχανισμό observe ο οποίος δίνει τη δυνατότητα σε έναν client να εγγραφεί ως observer (παρατηρητής) σε κάποιο resource ενός server με την αποστολή ενός ειδικού αιτήματος GET. Ο server με τη σειρά του καταχωρεί τον client σε μια εσωτερική του λίστα που περιέχει όλους του observers του συγκεκριμένου resource. Κάθε φορά που το εν λόγω resource υπόκειται σε μια αλλαγή (καθορίζεται από το server και όχι από το CoAP τι θεωρείται αλλαγή ) ο server μπορεί να στείλει μια ειδοποίηση σε κάθε observer με τη νέα αναπαράσταση του resource. Με τον τρόπο αυτό o client μπορεί να έχει μια όσο το δυνατόν περισσότερο χρόνο επίκαιρη αναπαράσταση του observed resource χωρίς polling, μειώνοντας την καταναλισκόμενη ενέργεια αλλά και τη συμφόρηση του δικτύου. Μέχρι στιγμής το CoAP δεν έχει δοκιμαστεί αρκετά, όμως κάποιες προκαταρκτικές δοκιμές που έγιναν με δύο υλοποιήσεις του, μία σε C (libcoap) [20] και μία σε Java (californium) [25] συμπεραίνουν πως η χρήση του σε σχέση με τη χρήση HTTP, έχει σημαντική επίδραση στην κατανάλωση ενέργειας και στο χρόνο απόκρισης του server σε διάφορα σενάρια επικοινωνίας Device Management Πρωτόκολλο LwM2M Γενικά Όσο το IoT μεγεθύνεται, τόσο πιο πολύπλοκη αλλά και αναγκαία καθίσταται η απομακρυσμένη διαχείριση όλων αυτών των νέων συσκευών που εντάσσονται στο Διαδίκτυο. Με τον όρο απομακρυσμένη διαχείριση (remote device management) εννοούμε τη δυνατότητα ελέγχου και διαχείρισης μιας συσκευής απομακρυσμένα. Είναι κοινώς αποδεκτό πως τα εκατομμύρια συνδεδεμένων συσκευών που (θα) συνθέτουν το M2M τμήμα του IoT, πρέπει να ενεργοποιούνται, ρυθμίζονται, συντηρούνται, ενημερώνονται με νέο software, ανακάμπτουν από σφάλματα, παρακολουθούνται, επισκευάζονται και τέλος απενεργοποιούνται και αποσυνδέονται στο τέλος της διάρκειας ζωής τους [26]. Ιδανικά όλα αυτά θα πρέπει να γίνονται απομακρυσμένα, αφού οι 19

23 περισσότερες συσκευές θα βρίσκονται σε σημεία όπου δε θα υπάρχει φυσική πρόσβαση ή αυτή θα είναι πολύ δύσκολη/δαπανηρή και μερικές από αυτές τις λειτουργίες πρέπει να γίνονται μαζικά σε μεγάλα πλήθη συσκευών. Τα περισσότερα πρωτόκολλα device management που είναι διαδεδομένα στην αγορά σήμερα, έχουν υψηλό κόστος και ταυτόχρονα σημαντικούς περιορισμούς ενώ είναι κατάλληλα για περιορισμένα σενάρια χρήσης. Διακρίνοντας την έλλειψη ενός πρότυπου το οποίο να είναι κατάλληλο για τη διαχείριση συσκευών περιορισμένων δυνατοτήτων στα σενάρια χρήσης που προβλέπονται στο IoT, ο οργανισμός προτυποποίησης Open Mobile Alliance (OMA), σχεδίασε το RESTful πρωτόκολλο LwM2M (Lightweight Machine to Machine) το οποίο έχει ως βασικό στόχο την αποδοτική διαχείριση των συσκευών αυτών. Ωστόσο αυτό δεν περιορίζει την καταλληλότητα του LwM2M όσον αφορά τη διαχείριση και συσκευών μεγαλύτερων δυνατοτήτων όπως είναι τα gateways. Επιπλέον ορίζει και μια ενοποιημένη διεπαφή για την παροχή υπηρεσιών μιας συσκευής προς το εξωτερικό της περιβάλλον και είναι επεκτάσιμο ώστε να υποστηρίζει στο μέλλον διεπαφές που δεν έχουν καθοριστεί σήμερα. Με αυτό τον τρόπο αποδεσμεύονται πλήρως τα συστατικά στοιχεία κάποιου συστήματος και το σύστημα αποκτά την ιδιότητα Plug-and-play. Επιπλέον είναι δυνατόν σε αρκετές περιπτώσεις το LwM2M να αποτελεί το μόνο απαιτούμενο πρωτόκολλο του επιπέδου του για τη συνολική λειτουργία μιας συσκευής ή ενός συστήματος Σύντομη περιγραφή των βασικών μηχανισμών του LwM2M Το LwM2M είναι σχεδιασμένο να αξιοποιεί το CoAP και προαιρετικά το πρωτόκολλο DTLS για τις εφαρμογές που απαιτούν ασφαλή επικοινωνία. Καθορίζει την επικοινωνία μεταξύ ενός LwM2M client ο οποίος τυπικά εκτελείται στην προς διαχείριση συσκευή και ενός LwM2M server. Ορίζονται τέσσερις διεπαφές (interfaces) για την επικοινωνία μεταξύ ενός LwM2M server και ενός LwM2M client: 1. Bootstrap: ορίζεται η διαδικασία κατά την οποία ένας LwM2M client αποκτά τις απαραίτητες πληροφορίες (από έναν LwM2M bootstrap server) για τον/τους LwM2M server στον οποίο πρέπει να εγγραφεί (register). 2. Client Registration: καθορίζεται ο τρόπος με τον οποίο ένας LwM2M client εγγράφεται σε και απεγγράφεται από έναν ή περισσότερους LwM2M servers. Κατά τη διαδικασία της εγγραφής, ο LwM2M server αποκτά όλες τις απαραίτητες πληροφορίες για την αξιοποίηση των υπηρεσιών που παρέχει ο LwM2M client. 3. Device Management & Service Enablement (DM&SE): περιγράφει τον τρόπο με τον οποίο ένας LwM2M server προσπελάζει τα LwM2M objects και τα LwM2M resources (περισσότερα παρακάτω) που έχει ένας LwM2M client. 20

24 4. Information Reporting: χρησιμοποιείται από έναν LwM2M server για την παρακολούθηση αλλαγών σε κάποιο resource ενός LwM2M client. Η αλληλεπίδραση μεταξύ client και server (ειδικότερα για τα δύο τελευταία interfaces) ακολουθώντας τις αρχές της REST αρχιτεκτονικής, γίνεται ως εξής: Κάθε πληροφορία ή υπηρεσία που ο LwM2M client διαθέτει στο περιβάλλον του έχει τη μορφή ενός LwM2M resource. Κάθε resource, μεταξύ των υπόλοιπων ιδιοτήτων του, διαθέτει και έναν τύπο (type) ο οποίος μπορεί να είναι ένας από τους {String, Integer, Float, Boolean, Opaque, Time, Objlnk}. Τα resources είναι λογικά ομαδοποιημένα σε LwM2M Objects. Ο LwM2M client δύναται να έχει οποιοδήποτε αριθμό από resources τα οποία όμως ανήκουν σε κάποιο object. Κάθε object μπορεί να έχει ένα μοναδικό ή πολλαπλά στιγμιότυπα (object instances). Ενδεικτικά ο LwM2M client στην Εικόνα 2-1 υποστηρίζει δύο objects εκ τον οποίων το ένα μόνο (object 1) έχει πολλαπλά object instances. Κάθε {object/ object instance /resource ενός συγκεκριμένου object} αναγνωρίζεται μονοσήμαντα από ένα μοναδικό {object id/ object instance id / resource id} αντίστοιχα. Η αναφορά σε κάποιο resource γίνεται μέσα από ένα path με τη μορφή /{Object ID}/{Object Instance ID}/{Resource ID}. Ο LwM2M server εκκινώντας μια αλληλεπίδραση με έναν LwM2M client, του αποστέλλει ένα αίτημα. Τα βασικά συστατικά ενός αιτήματος είναι i) το path του resource στο οποίο αναφέρεται και ii) η μέθοδος η οποία αιτείται να εφαρμοστεί στο resource αυτό. Το DM&SE ορίζει το σύνολο των μεθόδων οι οποίες μπορούν να εφαρμοστούν σε κάποιο resource και το σημαινόμενο της καθεμιάς. Οι βασικότερες από αυτές είναι οι: READ: ζητείται να επιστραφεί η τιμή ενός resource WRITE: ζητείται η αλλαγή της τιμής ενός resource EXECUTE: ζητείται η πραγματοποίηση κάποιας ενέργειας. Με τη σειρά του ο LwM2M client στέλνει στον LwM2M server μια απάντηση η οποία περιέχει έναν κωδικό απάντησης και σε ορισμένες περιπτώσεις κάποιο περιεχόμενο (content). Για παράδειγμα μια απάντηση σε ένα αίτημα READ μπορεί να έχει για κωδικό απάντησης το 2.05 Content και για περιεχόμενο την τιμή του resource το οποίο αφορούσε το αίτημα. Ανάλογα τον τύπο του αρχικού αιτήματος, ο κωδικός απάντησης έχει διαφορετική σημασία. Αξιοποιώντας το μηχανισμό observe του CoAP, το LwM2M με τον τρόπο που περιγράφει το Information reporting interface παρέχει τη δυνατότητα σε έναν LwM2M server (observer) να παρακολουθεί ό,τι αλλαγές γίνονται σε ένα resource ενός LwM2M client λαμβάνοντας από αυτόν ειδοποιήσεις (notifications) όταν η τιμή του προς παρακολούθηση resource αλλάζει. Μία τέτοια observe-notify σχέση μεταξύ ενός server και ενός client ξεκινάει με την αποστολή ενός αιτήματος τύπου observe από τον server στον client για ένα object, object instance ή resource που είναι παρακολουθήσιμο (observable). Μετά από την επιτυχή εγκαθίδρυση μιας τέτοιας σχέσης, ο LwM2M 21

25 client αποστέλλει ένα μήνυμα τύπου notify στον server. Το μήνυμα αυτό περιέχει τη νέα τιμή του resource που παρακολουθείται. Ο οργανισμός OMA μαζί με τις προδιαγραφές του LwM2M δημοσιοποιεί και ένα μητρώο (object registry) με LwM2M objects τα οποία έχουν καταχωρηθεί σε αυτό από τον ίδιο τον οργανισμό και από τρίτους. Η ιδέα πίσω από αυτό είναι πως όταν ένας LwM2M client θέλει να ενημερώσει κάποιον LwM2M server για τα objects τα οποία υποστηρίζει και τις λεπτομέρειες αυτών, αρκεί να αποστείλει μόνο τα αντίστοιχα object ids. Όλα τα χαρακτηριστικά που αφορούν τα objects αυτά και τα resources τους μπορούν να ανασυρθούν από το δημόσιο αυτό μητρώο είτε από το Διαδίκτυο είτε από ένα αποθηκευμένο στη μνήμη του LwM2M server αντίγραφο. Υπάρχει και ένα επιπλέον μητρώο αντίστοιχης λογικής με επαναχρησιμοποιούμενα resources ( resources registry ) τα οποία έχουν κοινά χαρακτηριστικά και σημασία σε κάθε LwM2M object που τα περιέχει. (Για την υλοποίηση του συστήματος που περιγράφεται σε αυτή την εργασία, έγινε χρήση ορισμένων, καταχωρημένων στο μητρώο του OMA, objects και resources αλλά ορίστηκαν και νέα ειδικά σχεδιασμένα για τη συγκεκριμένη εφαρμογή). Εικόνα 2-1: σχηματική αναπαράσταση της δομής ενός LwM2M client 22

26 3. Liqueur plant production system (LPPS) περιγραφή και απαιτήσεις Τα συστήματα βιομηχανικού αυτοματισμού αποτελούνται από μηχανικά υποσυστήματα, τα οποία εκτελούν τις απαραίτητες φυσικές διεργασίες, και από δίκτυα ενσωματωμένων υπολογιστών τα οποία εκτελούν τις απαραίτητες υπολογιστικές διεργασίες για την παρακολούθηση, τον έλεγχο και το συντονισμό των φυσικών διεργασιών [27]. Ένα τέτοιο δίκτυο ενσωματωμένων υπολογιστών (hardware και software του) θα αναφέρεται παρακάτω ως σύστημα ελέγχου του βιομηχανικού συστήματος παραγωγής ή απλά σύστημα ελέγχου. Ένα σύστημα ελέγχου αλληλεπιδρά με μηχανικά συστήματα μέσω αισθητήρων και actuators. Στο [28] περιγράφεται ένα σύστημα παραγωγής liqueur (στο εξής LPPS) και ένα σύστημα ελέγχου του, βασισμένο σε PLC s προγραμματισμένα σε γλώσσες του προτύπου IEC Στα πλαίσια της παρούσας εργασίας αναπτύχθηκε για το ίδιο σύστημα παραγωγής ένα σύστημα ελέγχου βασισμένο σε IoT τεχνολογίες. Ακολουθεί αναλυτική περιγραφή αυτού του συστήματος παραγωγής liqueur και των απαιτήσεων του συστήματος ελέγχου: Το σύστημα αποτελείται από τέσσερα σιλό συνδεδεμένα με ένα σωλήνα όπως φαίνεται στην Εικόνα 3-1. Κάθε σιλό έχει μία βαλβίδα εισαγωγής, μία βαλβίδα εξαγωγής και δύο αισθητήρες παρουσίας υγρού, έναν στο κάτω μέρος του σιλό, ο οποίος ανιχνεύει πότε το σιλό είναι άδειο, κι έναν στο πάνω μέρος, ο οποίος ανιχνεύει πότε είναι γεμάτο. Δύο από τα σιλό (#2 και #4) περιλαμβάνουν από ένα στοιχείο θέρμανσης και έναν αισθητήρα θερμοκρασίας. Δύο από τα σιλό (#3 και #4) περιλαμβάνουν από ένα στοιχείο μείξης. Στην εγκατάσταση αυτή εκτελούνται δύο γραμμές παραγωγής και η επεξεργασία που κάνει η καθεμία έχει ως εξής: Γρ. παραγωγής #1 : Το σιλό #1 γεμίζει με υγρό (από τη βαλβίδα εισαγωγής του). Στη συνέχεια το υγρό μεταφέρεται μέσω του σωλήνα στο σιλό #4, όπου θερμαίνεται (με τη βοήθεια του στοιχείου θέρμανσης) μέχρι μία επιθυμητή θερμοκρασία. Στη συνέχεια το υγρό αναδεύεται (με τη βοήθεια του στοιχείου μείξης) για συγκεκριμένο χρονικό διάστημα. Τέλος, το υγρό μεταφέρεται σε επόμενο στάδιο παραγωγής από τη βαλβίδα εξαγωγής του σιλό #4. 23

27 Γρ. παραγωγής #2 : Το σιλό #2 γεμίζει με υγρό το οποίο και θερμαίνεται μέχρι την επιθυμητή θερμοκρασία. Στη συνέχεια το υγρό μεταφέρεται μέσω του σωλήνα στο σιλό #3, όπου και αναδεύεται για συγκεκριμένο χρονικό διάστημα. Τέλος, το υγρό μεταφέρεται από τη βαλβίδα εξαγωγής του σιλό #3 σε κάποιο επόμενο στάδιο παραγωγής. Οι δύο γραμμές παραγωγής είναι ανεξάρτητες μεταξύ τους και εκτελούνται κυκλικά και ταυτόχρονα με τους εξής περιορισμούς: 1. Ο σωλήνας είναι κοινός για τις δύο γραμμές παραγωγής και μπορεί να χρησιμοποιείται για μία μεταφορά κάθε στιγμή (σιλό #1 προς το σιλό #4 ή σιλό #2 προς το σιλό #3) 2. Ένα μόνο από τα στοιχεία μείξης μπορεί να είναι σε λειτουργία κάθε στιγμή λόγω περιορισμού στην κατανάλωση ισχύος. Εικόνα 3-1: Σχηματική αναπαράσταση του συστήματος παραγωγής liqueur 24

28 Επιπλέον, θεωρούμε πως τα σιλό είναι μεταξύ τους σε απόσταση τέτοια ώστε κρίνεται σκοπιμότερη η χρήση του Διαδικτύου για τη διασύνδεσή τους σε σχέση με ένα τοπικό δίκτυο ενσωματωμένων υπολογιστών ή ένα συγκεντρωμένο σύστημα ελέγχου του συστήματος παραγωγής. 25

29

30 4. Υψηλού επιπέδου σχεδιασμός του συστήματος Στο κεφάλαιο αυτό περιγράφεται ο υψηλού επιπέδου σχεδιασμός (High-level design) του συστήματος ο οποίος αφορά την πιθανή ομαδοποίηση και την αντιστοίχιση των φυσικών υποσυστημάτων σε LwM2M clients και servers καθώς και τον τρόπο αλληλεπίδρασης μεταξύ τους. Βασική προϋπόθεση για την ένταξη του LPPS στο IoT, είναι η ενσωμάτωση τουλάχιστον ενός μικροϋπολογιστή με δυνατότητες δικτύωσης στο LPPS, καθώς και των απαραίτητων ηλεκτρονικών στοιχείων προκειμένου να επιτευχθεί η διεπαφή αυτού με τα μηχανικά υποσυστήματα του LPPS. Αυτός/αυτοί οι μικροϋπολογιστές, οι οποίοι θα αποτελούν μέρος του συστήματος ελέγχου του LPPS, θα παρέχουν στο περιβάλλον κάποιες υπηρεσίες τις οποίες θα χρησιμοποιούν ένας ή περισσότεροι LwM2M servers για να επιτυγχάνεται η παραγωγή liqueur Σχεδιασμός του API των υποσυστημάτων του LPPS Το API κάθε LwM2M client μπορεί να είναι σχεδιασμένο ώστε να παρέχει στο περιβάλλον υπηρεσίες υψηλότερου ή/και χαμηλότερου επιπέδου. Χαμηλότερου επιπέδου είναι οι υπηρεσίες οι οποίες είναι απλές και με σχετικά άμεση αντιστοίχιση σε υπηρεσίες που προσφέρουν τα μηχανικά υποσυστήματα του σιλό στο σύστημα ελέγχου. Έτσι, για ένα από τα σιλό κάποιες από τις δυνατές υπηρεσίες χαμηλού επιπέδου είναι οι: Άνοιγμα βαλβίδας εισαγωγής Ενεργοποίηση στοιχείου θέρμανσης Απενεργοποίηση στοιχείου μείξης Έλεγχος παρουσίας υγρού στον άνω αισθητήρα υγρού Από την άλλη, οι υπηρεσίες υψηλού επιπέδου αντιστοιχούν σε πιο σύνθετες λειτουργίες που συνήθως απαιτούν από το σύστημα ελέγχου το συντονισμό περισσότερων μηχανικών υποσυστημάτων καθώς και την εκτέλεση ενός πιο σύνθετου αλγορίθμου. Κάποιες υψηλού επιπέδου υπηρεσίες για το σύστημα παραγωγής θα μπορούσαν να είναι η παραγωγή liqueur τύπου #1 και η επεξεργασία υγρού στο σιλό #4. Μια τέτοια προσέγγιση θα έκανε την ανάπτυξη του LwM2M server απλούστερη, αλλά ταυτόχρονα θα περιόριζε τη δυνατότητα αξιοποίησης του συστήματος από άλλες εφαρμογές. Ας πάρουμε, για παράδειγμα, το σενάριο όπου το API που παρέχει το σύστημα αποτελείται μόνο από τις υπηρεσίες παραγωγή liqueur τύπου #1 και παραγωγή liqueur τύπου 27

31 #2. Κάτι τέτοιο καθιστά αδύνατη όχι μόνο τη χρήση του συστήματος για την παραγωγή κάποιου τρίτου τύπου liqueur, το οποίο θα απαιτούσε διαφορετική επεξεργασία, αλλά και την παραμικρή αλλαγή στις παραμέτρους των γραμμών παραγωγής #1 και #2. Αυτό αποτελεί πολύ σημαντικό μειονέκτημα, αφού η γραμμή παραγωγής δεν είναι καθόλου ευέλικτη ενώ τα περισσότερα έξυπνα αντικείμενα θα πρέπει να μπορούν να χρησιμοποιούνται από πολλές εφαρμογές, ακόμα και ταυτόχρονα. Αυτό, για το σύστημα παραγωγής liqueur, θα μπορούσε να σημαίνει πως τη στιγμή που κάποια εφαρμογή χρησιμοποιεί το σύστημα για την παραγωγή liqueur, μια άλλη εφαρμογή αξιοποιεί τις υπηρεσίες που προσφέρει προκειμένου να: ενημερώσει κάποιον πελάτη σχετικά με το στάδιο που βρίσκεται η παραγγελία του ειδοποιήσει τον υπεύθυνο συντήρησης για κάποιο γεγονός στην εγκατάσταση καταχωρίσει αυτόματα μια παραγγελία κάποιας πρώτης ύλης όταν το απόθεμα αυτής θα έχει μειωθεί Γίνεται λοιπόν σαφές πως όσο χαμηλότερου επιπέδου υπηρεσίες παρέχονται από το σύστημα, τόσο πιο ευέλικτο και διαλειτουργικό σε επίπεδο εφαρμογής γίνεται. Με βάση αυτό, οι συγγραφείς του [29] προτείνουν τη thin server αρχιτεκτονική κατά την οποία τα έξυπνα αντικείμενα είναι πλήρως αποσυζευγμένα από οποιαδήποτε εφαρμογή και προσφέρουν τις χαμηλότερου δυνατού επιπέδου υπηρεσίες. Σε μια τέτοια αρχιτεκτονική το λογισμικό που εκτελείται στο έξυπνο αντικείμενο λειτουργεί απλά ως ένας wrapper των αισθητήρων και των actuators που ενσωματώνει το αντικείμενο. Αν και αυτή η προσέγγιση έχει το πλεονέκτημα της μέγιστης δυνατής διαλειτουργικότητας, εντούτοις εγείρεται το εξής ζήτημα: Υπάρχουν σε διάφορα σενάρια χρήσης, τμήματα του εκτελούμενου αλγόριθμου (στο εξής κρίσιμα τμήματα) στα οποία κάποιο γεγονός του συστήματος πρέπει να ακολουθηθεί σε πραγματικό χρόνο από μία ενέργεια. Έτσι, στην περίπτωση που η εφαρμογή εκτελείται απομακρυσμένα, εισάγεται μια καθυστέρηση μεταξύ του γεγονότος και της ενέργειας που πρέπει να ακολουθήσει. Τέτοιου είδους καθυστερήσεις μπορεί να μην είναι ανεκτές για συγκεκριμένα σενάρια χρήσης. Επιπλέον, ενώ αυτές οι καθυστερήσεις κυμαίνονται στην τάξη των milliseconds, σε περίπτωση προσωρινών προβλημάτων σύνδεσης του έξυπνου αντικειμένου ή του κόμβου που εκτελεί την εφαρμογή, δύναται να γίνουν σημαντικά μεγαλύτερες (>1 second) καθιστώντας αυτό το πρόβλημα ικανό να επηρεάσει εφαρμογές και σενάρια χρήσης με όχι και τόσο υψηλές απαιτήσεις εκτέλεσης σε πραγματικό χρόνο. Στο σύστημα παραγωγής liqueur, ένα τέτοιο σενάριο χρήσης είναι η σύνθετη λειτουργία πλήρωσης του σιλό #2. Ο αλγόριθμος για να γίνει αυτό αποτελείται από τα παρακάτω βήματα: 28

32 Αν ο άνω αισθητήρας δεν ανιχνεύει υγρό: a. Άνοιξε τη βαλβίδα εισαγωγής b. Όταν ο άνω αισθητήρας ανιχνεύσει υγρό, κλείσε τη βαλβίδα εισαγωγής. Γίνεται φανερό πως αν μια μεγάλη καθυστέρηση εμφανιστεί αφού ο αισθητήρας ανιχνεύσει υγρό και πριν ολοκληρωθεί το κλείσιμο της βαλβίδας εισαγωγής, το σιλό θα συνεχίσει να γεμίζει παραπάνω από το επιθυμητό επίπεδο πλήρωσης. Λαμβάνοντας υπόψιν τα παραπάνω, η επιλογή που έγινε για το API του συστήματος παραγωγής είναι η εξής: θα παρέχονται χαμηλού επιπέδου υπηρεσίες όπως προτείνεται από τη thin server αρχιτεκτονική. Εκτός αυτών, θα παρέχονται ως υψηλότερου επιπέδου υπηρεσίες όλα τα κρίσιμα τμήματα που εμφανίζονται στους αλγόριθμους των 2 γραμμών παραγωγής. Αυτές οι υψηλότερου επιπέδου υπηρεσίες θα πρέπει να είναι οι απλούστερες δυνατές για να παραμένουν όσο το δυνατόν πιο διαλειτουργικές API των σιλό Η διαδικασία του σχεδιασμού του API του LPPS, ξεκίνησε με μια καταγραφή όλων των κρίσιμων τμημάτων που εμφανίζονται στους αλγόριθμους των γραμμών παραγωγής #1 και #2 : Κάποιο σιλό γεμίζει με υγρό: η βαλβίδα εισαγωγής του σιλό πρέπει να κλείσει αμέσως μόλις ο άνω αισθητήρας υγρού του σιλό ανιχνεύσει υγρό. Κάποιο σιλό αδειάζει από υγρό: η βαλβίδα εξαγωγής του σιλό πρέπει να κλείσει αμέσως μόλις ο κάτω αισθητήρας υγρού ανιχνεύσει απουσία υγρού. Θέρμανση περιεχομένου σιλό μέχρι μια θερμοκρασία: το στοιχείο θέρμανσης ενός σιλό πρέπει να απενεργοποιηθεί αμέσως μόλις το θερμόμετρο του σιλό ανιχνεύσει μια επιθυμητή θερμοκρασία. Ανάδευση περιεχομένου ενός σιλό για κάποιο χρόνο: το στοιχείο ανάδευσης πρέπει να απενεργοποιηθεί όταν θα έχει περάσει συγκεκριμένο χρονικό διάστημα από τη στιγμή ενεργοποίησής του. Από τη λίστα αυτή παρατηρείται πως κάθε κρίσιμο τμήμα εμπλέκει λειτουργίες των υποσυστημάτων ενός μόνο σιλό. Έτσι η κάθε υψηλού επιπέδου υπηρεσία μπορεί να παρέχεται από ένα σιλό αυτόνομα, χωρίς δηλαδή την ανάγκη γνώσης οποιαδήποτε πληροφορίας ή αλληλεπίδρασης με περιβάλλον του. Το γεγονός αυτό, σε συνδυασμό με το ότι τα σιλό μεταξύ τους βρίσκονται σε μεγάλη απόσταση, οδηγεί στην απόφαση σε κάθε σιλό να ενσωματωθεί ένας διασυνδεδεμένος μικροϋπολογιστής και κάθε σιλό να αποτελεί έναν αυτόνομο LwM2M client. Κάθε τέτοιος 29

33 μικροϋπολογιστής μαζί με τα απαραίτητα ηλεκτρονικά στοιχεία και το απαραίτητο λογισμικό που εκτελείται σε αυτόν, θα αναφέρεται στο εξής ως σύστημα ελέγχου του σιλό. Ακολουθώντας τις αρχές της REST αρχιτεκτονικής και τη λογική του LwM2M, πρέπει να οριστούν κάποια LwM2M objects και τα αντίστοιχα resources τους, μέσω των οποίων θα γίνεται η πρόσβαση στις υπηρεσίες που παρέχει κάποιο σιλό. Για τις υψηλού επιπέδου υπηρεσίες, ορίζεται το LwM2M object Silo. Για τις χαμηλού επιπέδου υπηρεσίες, ορίζεται ένα σύνολο από LwM2M objects με τα αντίστοιχα resources τα οποία αντιστοιχίζονται εύκολα στις λειτουργίες των διαφόρων υποσυστημάτων του σιλό. Τα παραπάνω φαίνονται στον πίνακα Αναλυτική περιγραφή των LwM2M objects και των resources τους Object Silo: μέσω αυτού παρέχονται υψηλού επιπέδου υπηρεσίες από το σιλό. o Resource state: αναπαριστά κάθε στιγμή την κατάσταση του Silo. Αυτή μπορεί να είναι μία εκ των {EMPTY,FILLING,FULL,EMPTYING} Στο state chart της Εικόνας 4-1 παρουσιάζονται και οι συνθήκες μετάβασης μεταξύ των καταστάσεων αυτών. o Resources fill, empty: μέσω αυτών δίνεται η εντολή για να ξεκινήσει η διαδικασία πλήρωσης και αδειάσματος του σιλό αντίστοιχα o Resource stop: με ένα αίτημα EXECUTE σε αυτό το resource, αν είναι σε εξέλιξη μια διαδικασία πλήρωσης ή αδειάσματος του σιλό. Σταματάει. Αν ήταν σε εξέλιξη η πρώτη, το σιλό μεταβαίνει στην κατάσταση FULL ενώ αν ήταν η δεύτερη στην κατάσταση EMPTY. o Resource initialize: δίνει στο σιλό τη δυνατότητα να εκτελέσει οποιαδήποτε αρχικοποίηση απαιτείται. o Resources heat, mix: μέσω αυτών εκτελούνται οι λειτουργίες θέρμανσης και μείξης αντίστοιχα. o Resources Filling completed mixing completed: μέσω αυτών των resources γίνεται δυνατή η ενημέρωση οποιουδήποτε ενδιαφερόμενου σχετικά με το πέρας μιας λειτουργίας. Ο ενδιαφερόμενος αρκεί να εγκαθιδρύσει μια σχέση observe-notify με το αντίστοιχο resource. Όλοι οι ενδιαφερόμενοι θα λαμβάνουν ένα notification πως η τιμή του resource έγινε TRUE, κάθε φορά που μια αντίστοιχη λειτουργία ολοκληρώνεται. o Resource target temperature: όταν βρίσκεται σε εξέλιξη μια λειτουργία HEAT και το θερμόμετρο ανιχνεύσει αυτή τη θερμοκρασία, η διαδικασία HEAT ολοκληρώνεται. Object Valve: παρέχει πρόσβαση σε χαμηλού επιπέδου υπηρεσίες μιας βαλβίδας ροής υγρού. o Resource On/off: Όταν έχει την τιμή TRUE, η βαλβίδα είναι ανοιχτή και όταν έχει την τιμή FALSE κλειστή. 30

34 Object Level sensor: δίνει τη δυνατότητα αλληλεπίδρασης με έναν ανιχνευτή παρουσίας υγρού. o Resource sensor type: ο τύπος του αισθητήρα. o Resource digital output state: Έχει την τιμή TRUE αν ανιχνεύεται υγρό και την τιμή FALSE σε αντίθετη περίπτωση. Object Mixer: αντιστοιχεί στο στοιχείο μείξης του σιλό. o Resource On/off: Όταν έχει την τιμή TRUE, το στοιχείο μείξης είναι σε λειτουργία και όταν έχει την τιμή FALSE, το αντίθετο. o Time to operate: Καθορίζει σε δευτερόλεπτα τον επιθυμητό χρόνο μείξης για μια λειτουργία MIX. Object Heater: αντιστοιχεί στο στοιχείο θέρμανσης του σιλό. o Resource On/off: Όταν έχει την τιμή TRUE, το στοιχείο θέρμανσης είναι σε λειτουργία και όταν έχει την τιμή FALSE, το αντίθετο. Object Temperature Sensor: αντιστοιχεί στο θερμόμετρο του σιλό. o Resource sensor value: η θερμοκρασία του σιλό. o Resource sensor value units: η μονάδα μέτρησης της θερμοκρασίας. 31

35 Object (ID) Silo (16663) Valve (16664) Level Sensor (16665) Mixer (16667) Heater (16668) Temperature Sensor (3303) Resource Resource ID R(O)WE* Single Mandatory Type Y state 0 R(O) Y Y String fill 1 E Y Y Boolean empty 2 E Y Y Boolean stop 3 E Y Y Boolean initialize 4 E Y Y Boolean heat 5 E Y Boolean mix 6 E Y Boolean filling completed 7 R(O) Y Y Boolean emptying completed 8 R(O) Y Y Boolean heating completed 9 R(O) Y Boolean mixing completed 10 R(O) Y Boolean target Temperature 11 RW Y Float on/off 5850 RW Y Y Boolean sensor type 5751 R Y String digital Output State 5550 R(O) Y Y Boolean on/off 5850 R(O)W Y Y Boolean time to operate 0 RW Y Integer on/off 5850 R(O)W Y Y Boolean Sensor Value 5700 R(O) Y Y Float Sensor Units 5701 R Y String Πίνακας 4-1: LwM2M objects των σιλό. *R=Readable,O=Observable,W=Writable,E=Executable 32

36 Παρατηρήσεις Τα resources target temperature και time to operate, των objects Silo και Mixer αντίστοιχα, έχουν μια προεπιλεγμένη τιμή η οποία δεν επιτρέπεται να αλλάξει όσο κάποιο υποσύστημα του σιλό βρίσκεται εν λειτουργία. Με πράσινο χρώμα σημειώνονται τα objects και resources που υπάρχουν στο object και resource registry του οργανισμού OMA. When ( Παραλαβή αιτήματος FILL ) FILLING When( άνω αισθητήρας παρουσίας υγρού ανιχνεύσει υγρό παραλαβή αιτήματος STOP ) EMPTY FULL When( Παραλαβή αιτήματος FILL ) When( Παραλαβή αιτήματος EMPTY) EMPTYING When( κάτω αισθητήρας παρουσίας υγρού δεν ανιχνεύει πλέον υγρό παραλαβή αιτήματος STOP ) When( Παραλαβή αιτήματος EMPTY ) Εικόνα 4-1: state chart διάγραμμα της κατάστασης του σιλό (Silo Object/state resource) 4.3. API των κοινόχρηστων πόρων Στο σύστημα παραγωγής υπάρχουν δύο κοινόχρηστοι πόροι, ο σωλήνας και η ισχύς. Η βασική λειτουργία της διαχείρισης ενός κοινόχρηστου πόρου είναι η εξασφάλιση πως μόνο ένας ενδιαφερόμενος κάθε στιγμή θα χρησιμοποιεί τον πόρο. Στο LPPS οι ενδιαφερόμενοι εννοούνται οι δύο γραμμές παραγωγής. Η ισχύς δεν έχει υλική υπόσταση και ως εκ τούτου η λογική που είναι υπεύθυνη για τη διαχείρισή της δε χρειάζεται να εκτελείται σε κάποιο συγκεκριμένο κόμβο. Το γεγονός πως ο σωλήνας δεν έχει αισθητήρες και actuators, μας δίνει την ίδια ελευθερία και για το σωλήνα. Μπορούν λοιπόν οι δύο κοινόχρηστοι πόροι, παρά τις διαφορές τους να αντιμετωπιστούν ως ομοειδή αντικείμενα. 33

37 Ο τρόπος που επιτυγχάνεται ο ζητούμενος αμοιβαίος αποκλεισμός είναι ο εξής: Κάθε κοινόχρηστος πόρος αναπαρίσταται ως ένα LwM2M object instance του LwM2M object Common Resource σε κάποιον LwM2M client. Η δομή του LwM2M object αυτού φαίνεται στον πίνακα 4-2. Object (ID) Common Resource (16666) Resource Resource ID R(O)WE Single Mandatory Type owner 0 R(O) Y Y String acquire 1 E Y Y Boolean release 2 E Y Y Boolean Πίνακας 4-2: common resource LwM2M object Κάθε ενδιαφερόμενος για τη χρήση του κοινόχρηστου πόρου, αναγνωρίζεται με ένα μοναδικό string (αναγνωριστικό του). Κάθε φορά που ένας ενδιαφερόμενος θέλει να δεσμεύσει τον κοινόχρηστο πόρο, αποστέλλει ένα αίτημα EXECUTE στο resource acquire με παράμετρο το αναγνωριστικό του. Όταν το resource owner πάρει την τιμή του αναγνωριστικού του ενδιαφερόμενου, ο ενδιαφερόμενος είναι πλέον ο ιδιοκτήτης του πόρου και μπορεί να τον χρησιμοποιήσει. Όταν θέλει να τον αποδεσμεύσει, αποστέλλει ένα αίτημα EXECUTE στο resource release με παράμετρο το αναγνωριστικό του. Από τη στιγμή που ο κοινόχρηστος πόρος αλλάξει την τιμή του resource owner με το αναγνωριστικό κάποιου άλλου ενδιαφερόμενου ή το αναγνωριστικό NONE, ο ενδιαφερόμενος παύει να είναι ο ιδιοκτήτης του πόρου. Η υποστήριξη της δυνατότητας observe - notify από το resource owner δίνει τη δυνατότητα στους ενδιαφερόμενους να ενημερώνονται άμεσα για κάθε αλλαγή του τρέχοντος ιδιοκτήτη. Ο κοινόχρηστος πόρος καθορίζει ποιος θα είναι ο επόμενος ιδιοκτήτης μετά από ένα αίτημα release. Δεδομένου ότι οι δύο γραμμές 34

38 Εικόνα 4-2: sequence διάγραμμα αλληλεπίδρασης με έναν κοινόχρηστο πόρο παραγωγής έχουν ίδια προτεραιότητα, τα αιτήματα χρήσης του πόρου θα εξυπηρετούνται με την πολιτική First-come, first-served. Μια τυπική αλληλεπίδραση με τους κανόνες που περιγράφονται, μεταξύ ενός κοινόχρηστου πόρου και δύο ενδιαφερόμενων, φαίνεται στο sequence διάγραμμα στην Εικόνα Σχεδιασμός των γραμμών παραγωγής Δεδομένου των υπηρεσιών που θα προσφέρουν τα σιλό και οι κοινόχρηστοι πόροι ως LwM2M clients, οι δύο γραμμές παραγωγής θα υλοποιηθούν ως δύο LwM2M servers οι οποίοι θα αξιοποιούν τα API των clients. Οι δύο servers είναι δυνατόν να εκτελούνται σε οποιουσδήποτε δικτυωμένους 35

39 υπολογιστικούς κόμβους, είτε και στον ίδιο είτε ακόμα και σε κάποιο κόμβο όπου εκτελείται κάποιος από τους προαναφερθέντες LwM2M clients. Παρατηρείται πως κάθε γραμμή παραγωγής αξιοποιεί δύο σιλό εκ των οποίων αρχικά χρησιμοποιεί το ένα και στη συνέχεια το άλλο. Έτσι για κάθε γραμμή παραγωγής έχουμε ένα σιλό όπου εισέρχεται αρχικά το υγρό ( σιλό IN ή Sin ) και ένα από το οποίο τελικά εξέρχεται ( σιλό OUT ή Sout ). Ξεκινώντας το σχεδιασμό, μπορούμε να αναπαραστήσουμε αφαιρετικά τους αλγόριθμους των δύο γραμμών παραγωγής ως δύο επαναλαμβανόμενες σειρές από βήματα: Γρ. παραγωγής #1 Γρ. Παραγωγής # Γέμισε το σιλό IN 1.2. Δέσμευσε το σωλήνα 1.3. Μετάφερε το υγρό από το σιλό IN στο σιλό OUT 1.4. Αποδέσμευσε το σωλήνα 1.5. Θέρμανε το υγρό στο σιλό OUT 1.6. Δέσμευσε την ισχύ 1.7. Ανάμειξε το υγρό στο σιλό OUT 1.8. Αποδέσμευσε την ισχύ 1.9. Άδειασε το σιλό OUT 2.1. Γέμισε το σιλό IN 2.2. Θέρμανε το υγρό στο σιλό IN 2.3. Δέσμευσε το σωλήνα 2.4. Μετάφερε το υγρό από σιλό IN στο σιλό OUT 2.5. Αποδέσμευσε το σωλήνα 2.6. Δέσμευσε την ισχύ 2.7. Ανάμειξε το υγρό στο σιλό OUT 2.8. Αποδέσμευσε την ισχύ 2.9. Άδειασε το σιλό OUT Πίνακας 4-3: Αλγόριθμοι για τις δύο γραμμές παραγωγής liqueur. Οι δύο γραμμές παραγωγής απαιτούν τη χρήση των δύο κοινόχρηστων πόρων και εφόσον εκτελούνται ταυτόχρονα, πρέπει να μελετηθεί κατά πόσο είναι πιθανόν να εμφανιστεί κάποια κατάσταση deadlock. Στην παραπάνω καταγραφή τα κρίσιμα τμήματα είναι τα: , , , Φαίνεται εύκολα πως καμία γραμμή παραγωγής δεν απαιτεί ποτέ τη δέσμευση και των δύο κοινόχρηστων πόρων. Επομένως δεν υπάρχει περίπτωση να εμφανιστεί μια κατάσταση deadlock. 36

40 Οι παραπάνω σειριακοί αλγόριθμοι περιέχουν τμήματα τα οποία μπορούν να παραλληλοποιηθούν οδηγώντας σε βελτιστοποίηση της παραγωγής. Παραδείγματος χάριν το βήμα 1.1. για τον επόμενο κύκλο παραγωγής της γραμμής παραγωγής #1 μπορεί να εκτελείται ταυτόχρονα με τα βήματα Μια τέτοια βελτιστοποιημένη εκδοχή των αλγορίθμων των δύο γραμμών παραγωγής φαίνεται με τη μορφή activity διαγραμμάτων στις Εικόνες 4-3 και 4-4. Εικόνα 4-3: activity διάγραμμα για τη γρ. παραγωγής #1 Εικόνα 4-4: activity διάγραμμα για τη γρ. παραγωγής #2 37

41 Κάθε activity των διαγραμμάτων αυτών μπορεί να αναλυθεί περαιτέρω σε μια σειρά από επιμέρους activities τα οποία συσχετίζονται άμεσα με υπηρεσίες που παρέχουν οι LwM2M clients του συστήματος. Κάθε επιμέρους activity είναι είτε αποστολή κάποιου αιτήματος, είτε αναμονή μέχρι να έρθει ένα notification για αλλαγή της τιμής ενός resource στο οποίο ο εκάστοτε LwM2M server έχει εγγραφεί ως observer. Στην πρώτη περίπτωση τα χαρακτηριστικά του activity σημειώνονται ως εξής: Send {τύπος αιτήματος} request on {LwM2M Client}/{LwM2M object}/{ LwM2M resource} Ενώ στη δεύτερη: Wait for {LwM2M Client}/{LwM2M Object}/{LwM2M resource} ={επιθυμητή τιμή} 38

42 Εικόνα 4-5: στοιχειώδη activities για τις δύο γραμμές παραγωγής 39

43

44 5. Ανάπτυξη του συστήματος ελέγχου 5.1. Γενικά - Επιλογή hardware και software Στο κεφάλαιο αυτό περιγράφεται η υλοποίηση τωνlwm2m clients και servers με τις προδιαγραφές που περιγράφονται στο προηγούμενο κεφάλαιο. Επιλέχθηκε η ανάπτυξή τους σε Java κυρίως λόγω της ευελιξίας που προσφέρει όσον αφορά τις συσκευές στις οποίες μπορεί να εκτελεστεί. Επιλέγοντας όμως την java έχουμε τη δυνατότητα να χρησιμοποιήσουμε δύο βιβλιοθήκες που υλοποιούν τα πρωτόκολλα CoAP και LwM2M, τις Californium 1 και Leshan 2 αντίστοιχα. Τα εργαλεία που χρησιμοποιήθηκαν είναι το eclipse IDE 3 για τη συγγραφή του κώδικα σε συνδυασμό με το πρόσθετο ObjectAid 4 για τη δημιουργία των διαγραμμάτων κλάσεων, τα προγράμματα σχεδιασμού EDrawMax 5 και Microsoft Visio για τη δημιουργία των υπόλοιπων διαγραμμάτων και το σύστημα ελέγχου πηγαίου κώδικα Git 6 σε συνδυασμό με την υπηρεσία GitHub LwM2M Clients Περιγραφή του βασικού leshan framework για τους LwM2M clients Ο LeshanClient χρησιμοποιεί ένα σύνολο από στιγμιότυπα κλάσεων που υλοποιούν το LwM2mObjectEnabler interface, ένα για κάθε LwM2M Object που υποστηρίζει ο LwM2M Client. Η κλάση ObjectLoader χρησιμοποιεί ένα αρχείο (File) από το οποίο εισάγει όλα τα χαρακτηριστικά των υποστηριζόμενων LwM2M objects με τη μορφή στιγμιότυπων της ObjectModel. Ένα σύνολο από ObjectModels αποτελούν ένα LwM2mModel. Ο ObjectInitializer αντλώντας πληροφορίες από ένα LwM2mModel, αντιστοιχίζει πολλούς LwM2mInstanceEnablers σε έναν ObjectEnabler.(Βλέπε Εικόνα 5-1 )

45 Εικόνα 5-1: Concept map του leshan framework για έναν LwM2M client Για την αρχικοποίηση των LwM2M clients ακολουθούνται τα παρακάτω βήματα: Δημιουργία του LwM2mModel με τη βοήθεια του ObjectLoader: // Create LwM2mModel List<ObjectModel> defaultobjectmodels = ObjectLoader.loadDefault(); File f = new File("src" + File.separator + "main" + File.separator + "resources"); List<ObjectModel> customobjectmodels = ObjectLoader.load(f); List<ObjectModel> allobjectmodelslist = new ArrayList<ObjectModel>(); allobjectmodelslist.addall(defaultobjectmodels); allobjectmodelslist.addall(customobjectmodels); LwM2mModel lwm2mmodel = new LwM2mModel(allObjectModelsList); Δημιουργία του ObjectInitializer: ObjectsInitializer initializer = new ObjectsInitializer(lwM2mModel); Για κάθε LwM2M object (ενδεικτικός κώδικας): 42

46 o δήλωση στον ObjectInitializer σχετικά με το ποια object instances υποστηρίζονται και ποιοι είναι οι αντίστοιχοι LwM2mInstanceEnablers. Με τη μη ρητή δήλωση των LwM2M object instance id s υπονοείται πως επιλέγονται τόσα id s όσα και οι LwM2mInstanceEnablers που δηλώνονται, από το σύνολο {0,1,2,3,4, }. Στον παρακάτω κώδικα υπονοείται η επιλογή των id=0 και 1 για τα invalve και outvalve αντίστοιχα: ValveInstanceEnabler invalve = new InValveInstanceEnabler(smartSilo); ValveInstanceEnabler outvalve = new OutValveInstanceEnabler(smartSilo); initializer.setinstancesforobject(16664, invalve, outvalve); o Δημιουργία του αντίστοιχου ObjectEnabler και προσθήκη του στη λίστα με τους ObjectEnablers που θα δηλωθούν στον LeshanClient: enablers.add(initializer.create(16664)); Δημιουργία και εκκίνηση του LeshanClient: final LeshanClient client = new LeshanClient(clientAddress, serveraddress, new ArrayList<LwM2mObjectEnabler>(enablers)); // Start the client client.start(); Μετά την αρχικοποίηση, ο LeshanClient προωθεί κάθε εισερχόμενο αίτημα στον αντίστοιχο LwM2mObjectEnabler. Αυτός με τη σειρά του το προωθεί στον κατάλληλο LwM2mInstanceEnabler, καλώντας μία από τις μεθόδους { read( ),write( ),execute( ) }, αναλόγως τον τύπο του αιτήματος. Το interface LwM2mInstanceEnabler περιέχει δύο ακόμα μεθόδους, addresourcechangedlistener( ) και removeresourcechangedlistener( ) οι οποίες καλούνται από το leshan όταν για κάποιο resource του LwM2M object instance που αντιστοιχεί στον εκάστοτε LwM2mInstanceEnabler, έχει παραληφθεί ένα αίτημα observe ή ένα αίτημα cancel observe αντίστοιχα. Το Interface LwM2mInstanceEnabler παρουσιάζεται στην Εικόνα 5-2. Εικόνα 5-2: LwM2mInstanceEnabler interface Το leshan, για διευκόλυνση του χρήστη, παρέχει την κλάση BaseInstanceEnabler, η οποία υλοποιεί το interface LwM2mInstanceEnabler και είναι μια κλάση τύπου adapter. Περιέχει έναν τυπικό μηχανισμό διατήρησης λίστας με τους τρέχοντες observers και μια υλοποίηση των { 43

47 read( ),write( ),execute( ) } μεθόδων που επιστρέφουν μια απάντηση not found. Ο χρήστης μπορεί να κάνει override μόνο τις μεθόδους που θέλει να έχουν διαφορετική συμπεριφορά Δομή των σιλό Μια αφαιρετική περιγραφή της δομής της java εφαρμογής των σιλό, φαίνεται στην Εικόνα 5-3 με τη μορφή ενός component διαγράμματος. Η εφαρμογή μπορεί να χωριστεί σε τρία δομικά μέρη. Το πρώτο (Leshan wrapper) υλοποιεί τη διεπαφή της κυρίως εφαρμογής με το leshan και αποτελείται από τους LwM2mInstanceEnablers. Το δεύτερο είναι η κυρίως εφαρμογή (application core), και έχει το ρόλο να υλοποιεί όποια λογική πρέπει να υλοποιείται τοπικά όπως αναλύθηκε παραπάνω. Αποτελείται από την κλάση SiloController και όλες τις εσωτερικές της κλάσεις (Δεν εμφανίζονται στην Εικόνα 5-4). Το τρίτο μέρος (silo Driver) συνδέεται με το application core με ένα παρεχόμενο και ένα απαιτούμενο interface και αναλαμβάνει τη διεπαφή της εφαρμογής με τους αισθητήρες και τους actuators του σιλό. Η ανάπτυξη του silo Driver εξετάζεται σε επόμενο κεφάλαιο. Leshan Leshan Wrapper Application Core SiloControllerInterface Silo Driver SiloDriverInterface Εικόνα 5-3: Component διάγραμμα του σιλό Αναλυτικότερα: όλα τα αιτήματα που φτάνουν στο leshan wrapper από το leshan, προκαλούν την κλίση κάποιας μεθόδου της κλάσης SiloController η οποία αποτελεί το βασικό δομικό στοιχείο του application core. Η καλούμενη μέθοδος επιστρέφει γενικά ό,τι πρέπει να επιστραφεί και ως απάντηση στον LwM2M server που απέστειλε το αίτημα. Για το μηχανισμό observe notify, το πρωτόκολλο LwM2M δίνει την ελευθερία στο χρήστη να καθορίσει αυτός πότε θεωρείται πως ένα resource έχει αλλάξει και πρέπει να ειδοποιηθούν οι observers του. Γι αυτό ορίστηκε το interface ObserversUpdater το οποίο κάθε LwM2mInstanceEnabler που χρησιμοποιείται στην εφαρμογή υλοποιεί. Η μοναδική μέθοδος που περιέχει το interface αυτό, όταν καλείται με όρισμα το {resourceid}, ειδοποιεί όλους τους observers του LwM2M resource με id = {resourceid} σχετικά την αλλαγή του resource. Η κλάση SiloController αξιοποιεί αυτό το μηχανισμό. Τα παραπάνω φαίνονται στο διάγραμμα κλάσεων στην Εικόνα

48 Εικόνα 5-4: Μέρος του Διαγράμματος κλάσεων του σιλό. 45

49 Δομή των κοινόχρηστων πόρων Μια παρόμοια δομή με τα σιλό έχει και η εφαρμογή που εκτελείται στους LwM2M clients κοινόχρηστους πόρους. Ο leshan wrapper αποτελείται από την κλάση CommonResourceEnabler η οποία μετά από κάποιους στοιχειώδεις ελέγχους προωθεί τα έγκυρα εισερχόμενα αιτήματα στον CommonResourceController. Εικόνα 5-5: Μέρος του διαγράμματος κλάσεων του κοινόχρηστου πόρου 5.3. LwM2M servers Περιγραφή του βασικού leshan framework για τους LwM2M servers Μετά την αρχικοποίηση της εφαρμογής, για να αποσταλεί κάποιο αίτημα σε κάποιον LwM2M client, αρκεί να καλεστεί μία από τις σχετικές μεθόδους ενός στιγμιότυπου της κλάσης LeshanServer (οι 46

50 τρεις μέθοδοι με όνομα send ). Η κλάση LeshanServerBuilder είναι μια βοηθητική κλάση η οποία επιτρέπει την απλή παραμετροποίηση και δημιουργία του στιγμιότυπου της LeshanServer. Μεταξύ των παραμέτρων που πρέπει να της δοθούν για τη δημιουργία του LeshanServer είναι ένα στιγμιότυπο κλάσης που υλοποιεί τον interface LwM2mModelProvider όπως είναι η CustomModelProvider. Αυτή η κλάση έχει το ρόλο να φορτώσει από ένα αρχείο (File) όλα τα χαρακτηριστικά των υποστηριζόμενων LwM2M objects με τη μορφή ενός LwM2mModel το οποίο αποτελεί όπως και στον LwM2M client ένα σύνολο από ObjectModels. Καλώντας η κλάση LiqueurPlantServer τη μέθοδο LeshanServerBuilder.build() επιστρέφεται ένα στιγμιότυπο της LeshanServer το οποίο χρησιμοποιεί από εκεί και πέρα η υπόλοιπη εφαρμογή για να αποστείλει LwM2M αιτήματα όπως αναφέρθηκε. Το αντίστοιχο τμήμα του διαγράμματος κλάσεων φαίνεται στην Εικόνα

51 Εικόνα 5-6: μέρος του διαγράμματος κλάσεων του server Η εγκαθίδρυση μιας σχέσης observe notify με κάποιον LwM2M client πραγματοποιείται με τον εξής τρόπο: Για να αποστείλει ο LeshanServer ένα αίτημα observe σε κάποιον LwM2M client, πρέπει να καλεστεί μία από τις μεθόδους του, send( ) με ένα ObserveRequest ως όρισμα. Αυτό μπορεί να εγκαθιδρύσει μια σχέση observe notify μεταξύ του LwM2M server και client η οποία αναπαρίσταται εσωτερικά στο server ως ένα Observation. Κάθε Observation έχει εσωτερικά ένα μητρώο με 48

52 ObservationListeners οι οποίοι ειδοποιούνται κάθε φορά που ο server παραλαμβάνει ένα notify μήνυμα για το αντίστοιχο observable LwM2M resource. Η κλάση ObservationCreator δημιουργήθηκε για να απλοποιήσει τη διαδικασία αποστολής observe αιτημάτων και προσθήκης ObservationListeners στα Observations. Περιέχει δύο μεθόδους, την establishobservation(string,int,int,int) και την addobservationlistener(string,int,int,int,observationlistener). Η πρώτη συντάσσει και προωθεί στο LeshanServer το κατάλληλο αίτημα με τη μορφή ενός ObserveRequest. Κατά την κλήση της δεύτερης, ζητείται από το LeshanServer το ObservationRegistry, και σε αυτό αναζητείται, και ανασύρεται εφόσον υπάρχει, το ζητούμενο Observation. Στη συνέχεια προστίθεται σε αυτό o ObservationListener (η τελευταία παράμετρος της μεθόδου). Το σώμα της μεθόδου αυτής φαίνεται στον Κώδικα 5-1. Οι παραπάνω κλάσεις, μαζί με τους μεταξύ τους συσχετισμούς, φαίνονται στην Εικόνα 5-7. public boolean addobservationlistener(string clientendpoint,int objectid,int instanceid,int resourceid,observationlistener listener){ //retrieve target client Client client=getclientbyidentifier(clientendpoint); //retrieve observation for target client Set<Observation> clientobservations=server.getobservationregistry().getobservations(client); Iterator<Observation> iter=clientobservations.iterator(); Observation soughtoutobservation=null; while(iter.hasnext() && soughtoutobservation==null){ Observation examiningobservation=iter.next(); if(observationmatches(examiningobservation,objectid,instanceid,resourceid)) soughtoutobservation=examiningobservation; } } //if observation found, add to it the listener if(soughtoutobservation==null)return false; else{ soughtoutobservation.addlistener(listener); return true; } Κώδικας 5-1: μέθοδος ObservationCreator.addObservationListener(String,int,int,int,ObservationListener) 49

53 Εικόνα 5-7: μέρος του διαγράμματος κλάσεων του server Ανάπτυξη των server Αναθεώρηση σχεδιασμού Ο αρχικός σχεδιασμός για το LPPS ήταν η ύπαρξη δύο πλήρως ανεξάρτητων LwM2M servers, ενός για κάθε γραμμή παραγωγής. Κάθε LwM2M server θα εγκαθίδρυε μια σχέση observe notify με τα 50

54 resources των clients που τον αφορούσαν και όλοι οι ενδιαφερόμενοι θα ειδοποιούνταν σε κάθε αλλαγή του αντίστοιχου resource (βλέπε Εικόνα 5-8 Α ). Κατά την ανάπτυξη του συστήματος όμως διαπιστώθηκε πως ένας περιορισμός του leshan θα εμπόδιζε την υλοποίηση του σχεδιασμού αυτού. Συγκεκριμένα, η έκδοση του leshan που χρησιμοποιείτο, δεν υποστήριζε τη λειτουργία notify πολλαπλών observers ενός observable resource ενός LwM2M client. Αν πολλαπλοί LwM2M servers είχαν εγκαθιδρύσει μια σχέση observe-notify με κάποιο resource, ένα notify μήνυμα ελάμβανε μόνο ο server που είχε αποστείλει το τελευταίο αίτημα observe για το συγκεκριμένο resource και όχι όλοι όπως ορίζει το πρωτόκολλο LwM2M. Εφόσον ο αρχικός σχεδιασμός αξιοποιούσε την observe notify λειτουργία του LwM2M πρωτοκόλλου, και απαιτούσε για διάφορα LwM2M observable resources την ύπαρξη περισσότερων του ενός observers, έπρεπε να γίνει μια αλλαγή στο σχεδιασμό του συστήματος ώστε να είναι υλοποιήσιμο με την τρέχουσα έκδοση του leshan. Λαμβάνοντας υπ όψιν πως ο περιορισμός του leshan αυτός είναι αντίθετος με το LwM2M πρωτόκολλο και άρα είναι θέμα χρόνου να αρθεί, η σχεδιαστική αλλαγή θα πρέπει να είναι τέτοια ώστε μόλις κάποια επόμενη έκδοση του leshan υποστηρίζει τη ζητούμενη δυνατότητα, η εφαρμογή να μπορεί με τις λιγότερες δυνατές αλλαγές να λειτουργεί σύμφωνα με τον αρχικό σχεδιασμό. Με βάση τα παραπάνω, η αναθεώρηση που έγινε ήταν η εξής: οι δύο γραμμές παραγωγής θα υλοποιούνται ως ανεξάρτητες μεταξύ τους οντότητες σε έναν κοινό και μοναδικό LwM2M server. Ο server αυτός θα εγκαθιδρύει όλες τις σχέσεις observe-notify που απαιτούν οι δύο γραμμές παραγωγής. Κάθε εισερχόμενο μήνυμα notify θα προωθείται σε όσες από τις γραμμές παραγωγής αφορά αυτό. (βλέπε Εικόνα 5-8 Β). Με τον τρόπο αυτό, απλοποιείται και η μελλοντική αλλαγή από αυτή την υλοποίηση σε μία σύμφωνη με τον αρχικό σχεδιασμό. Επιπλέον μπορεί να αξιοποιηθεί ο υπάρχων μηχανισμός του leshan ο οποίος επιτρέπει την προσθήκη πολλαπλών ObservationListeners σε κάθε Observation στο server, όπως αναλύθηκε στην παράγραφο

55 Εικόνα 5-8: sequence διάγραμμα αποστολής notify μηνυμάτων. Α)αρχικός σχεδιασμός, Β) αναθεωρημένος σχεδιασμός Συμπεριφορά Κάθε γραμμή παραγωγής μπορεί να θεωρηθεί πως κάθε στιγμή βρίσκεται σε μία από ένα πεπερασμένο πλήθος καταστάσεων στην οποία αναμένει κάποιο γεγονός από το περιβάλλον της προκειμένου να μεταβεί σε μια επόμενη κατάσταση. Κατά τη μετάβαση αυτή αποστέλλει αιτήματα στους κατάλληλους LwM2M clients. Ως εκ τούτου, τα διαγράμματα των εικόνων 4-3, 4-4 και 4-5 μπορούν εναλλακτικά να αναπαρασταθούν από δύο state chart διαγράμματα, ένα για κάθε γραμμή παραγωγής (Εικόνες 5-9 και 5-10). 52

56 INITIALIZING / send(sin, FILL) FILLING Sin When(Sin filling completed) / send (pipe, ACQUIRE) ACQUIRING PIPE / send(sout, EMPTY) EMPTYING Sout When(Sout emptying completed) When(pipe aqcuired) / send(sin, EMPTY), send(sout, FILL) When(Sout filling complete Sin emptying complete) / send(sin, STOP) send(sout, STOP), send(pipe, RELEASE) TRANSFERING LIQUEUR / send(sin, FILL) FILLING Sin PROCESSING When(Sin, filling completed) / send(sout, HEAT) HEATING EMPTYING Sout When(Sout, emptying completed) / send(pipe, ACQUIRE) When(Sout heating completed) / send(power, ACQUIRE) When(Sout mixing completed) / send(power, RELEASE), send(sout, EMPTY) ACQUIRING POWER MIXING When(power acquired) / send (Sout, MIX) Εικόνα 5-9: State chart διάγραμμα γρ. παραγωγής #1 53

57 / send(sin, FILL) FILLING Sin INITIALIZING When(Sin filling completed) / send(sin, HEAT) HEATING When(Sin heating completed) / send (pipe, ACQUIRE) ACQUIRING PIPE / send(sout, EMPTY) EMPTYING Sout When(Sout emptying completed) When(pipe aqcuired) / send(sin, EMPTY), send(sout, FILL) When(Sout filling complete Sin emptying complete) / send(sin, STOP) send(sout, STOP), send(pipe, RELEASE) TRANSFERING LIQUEUR PROCESSING / send(sin, FILL) FILLING Sin When(Sin filling completed) / send(sin, HEAT) HEATING When(Sin heating completed) EMPTYING Sout / send(power, ACQUIRE) When(Sout, emptying completed) / send(pipe, ACQUIRE) When(Sout mixing completed) / send(power, RELEASE), send(sout, EMPTY) ACQUIRING POWER MIXING When(power acquired) / send (Sout, MIX) Εικόνα 5-10: State chart διάγραμμα γρ. παραγωγής #2 Στα παραπάνω διαγράμματα απεικονίζονται και ορισμένες σύνθετες (composite) καταστάσεις. Το νόημα αυτών είναι πως η εκάστοτε γραμμή παραγωγής δε μπορεί να μεταβεί στην επόμενη 54

58 κατάσταση μέχρι όλα τα εσωτερικά state chart διαγράμματα να τερματίσουν σε μία τελική κατάσταση. Αυτά τα εσωτερικά διαγράμματα μοντελοποιούν παράλληλα εκτελούμενες διαδικασίες και μπορούν να υλοποιηθούν με παράλληλα εκτελούμενα νήματα. Κάτι που παρατηρείται είναι πως όσες σύνθετες καταστάσεις περιέχουν περιοχές (regions) από τις οποίες μόνο μία έχει πάνω από μία εσωτερική κατάσταση (sub state) (εκτός της τελικής και της αρχικής κατάστασης), τότε αυτή η σύνθετη κατάσταση μπορεί να μετασχηματιστεί σε μία σειρά απλών καταστάσεων με τις κατάλληλες μεταξύ τους μεταβάσεις. Ας πάρουμε για παράδειγμα την κατάσταση INITIALIZING της γραμμής παραγωγής #2 (Εικόνα 5-10). Αποτελείται από δύο εσωτερικά state chart διαγράμματα, έστω το Δ1 (επάνω) και Δ2 (κάτω). Το Δ2 αποτελείται από τον αρχικό κόμβο, μία ενέργεια μετάβασης (transition action) στην κατάσταση EMPTYING Sout, την ομώνυμη κατάσταση, μία συνθήκη μετάβασης στην τελική κατάσταση και την τελική κατάσταση. Αν στο Δ1 συμπεριληφθούν: Η ενέργεια μετάβασης από το Δ2 ως ενέργεια μετάβασης από τον αρχικό κόμβο στην πρώτη κατάσταση, Η κατάσταση EMPTYING Sout ως παρεμβάλλουσα μεταξύ της τελευταίας κατάστασης και της τελικής κατάστασης, Η συνθήκη μετάβασης του Δ2 ως συνθήκη μετάβασης από την κατάσταση EMPTYING Sout στην τελική κατάσταση, Όπως φαίνεται στην Εικόνα 5-11, προκύπτει μια ισοδύναμη με το αρχικό μοντέλο συμπεριφορά αφού: η ενέργεια μετάβασης θα εκτελεστεί κατά την πρώτη μετάβαση (από την αρχική κατάσταση στην πρώτη κατάσταση). Όταν το state machine μεταβεί στην κατάσταση EMPTYING Sout, αν η συνθήκη μετάβασης στην τελική κατάσταση είναι αληθής, θα μεταβεί στην τελική κατάσταση αμέσως, ενώ αν είναι ψευδής θα παραμείνει σε αυτή μέχρι να γίνει αληθής. Αυτή η συμπεριφορά είναι ισοδύναμη με του αρχικού μοντέλου με τη σύνθετη κατάσταση. Το όφελος που υπάρχει με το μετασχηματισμό αυτό, είναι πως δεν απαιτείται ένα επιπλέον νήμα. Αυτός ο μετασχηματισμός μπορεί να εφαρμοστεί στις τρεις από τις τέσσερις σύνθετες καταστάσεις των εικόνων 5-9 και / send(sin, FILL), send(sout, EMPTY) FILLING Sin When(Sin filling completed) / send(sin, HEAT) HEATING When(Sin heating completed) EMPTYING Sout When(Sout emptying completed) Εικόνα 5-11: εναλλακτικός σχεδιασμός της INITIALIZING κατάστασης του statechart διαγράμματος της γρ. παραγωγής #2 55

59 Δομή Σε κάθε γραμμή παραγωγής αντιστοιχεί μια κλάση τύπου ProcessMonitor και ένα βασικό νήμα(liqueurprocessthread). Η πρώτη επιτελεί δύο ρόλους. Ο πρώτος είναι να παρέχει στο νήμα ένα αφαιρετικό interface για όλα τα αιτήματα τα οποία μπορεί το νήμα να αποστείλει. Μέρος των μεθόδων αυτού του interface φαίνεται στον Κώδικα 5-2. Αυτό προσφέρει την απόζευξη της λογικής που υλοποιεί το νήμα από το πρωτόκολλο επικοινωνίας (LwM2M) που χρησιμοποιείται. public void sendsiloinfill() throws InterruptedException{ server.send(siloinclient, new ExecuteRequest(16663,0,1)); } public void sendsilooutfill() throws InterruptedException{ server.send(silooutclient, new ExecuteRequest(16663,0,1)); } public void sendsiloinempty() throws InterruptedException{ server.send(siloinclient, new ExecuteRequest(16663,0,2)); } Κώδικας 5-2: Μέρος των μεθόδων της ProcessMonitorAbstract κλάσης Ο δεύτερος ρόλος της κλάσης αυτής είναι η διατήρηση μιας τρέχουσας αναπαράστασης της κατάστασης όλων των απομακρυσμένων συστημάτων που αφορούν τη γραμμή παραγωγής (στο εξής τοπική κατάσταση) και η υλοποίηση ενός monitor στο οποίο το αντίστοιχο νήμα μπορεί να περιμένει (wait()) μέχρι κάποια παράμετρος της κατάστασης αυτής να πάρει μια συγκεκριμένη τιμή. Αυτή η λειτουργία παρέχεται με τις μεθόδους με όνομα waitfor () όπως για παράδειγμα η μέθοδος waitforsilooutheatingcompleted() που φαίνεται στον Κώδικα 5-3. public synchronized void waitforsilooutheatingcompleted(){ while(! silooutheatingcompleted){ try { wait(); } catch (InterruptedException e) { e.printstacktrace(); } } } silooutheatingcompleted=false; Κώδικας 5-3: Μέθοδος ProcessMonitorAbstract.waitForSiloOutHeatingCompleted() 56

60 Κάθε ProcessMonitor είναι δηλωμένο στο leshan ως ObservationListener για τα Observations που το αφορούν. Η δήλωση αυτή γίνεται κατά την εγκαθίδρυση των σχέσεων observe notify με τους LwM2M clients και μέρος της διαδικασίας αυτής φαίνεται στον Κώδικα 5-4. // silo2 heating completed observationcreator.establishobservation("silo-2", 16663, 0, 9); observationcreator.addobservationlistener("silo-2", 16663, 0, 9, process2monitor); // silo3 mixing completed observationcreator.establishobservation("silo-3", 16663, 0, 10); observationcreator.addobservationlistener("silo-3", 16663, 0, 10, process2monitor); // pipe owner observationcreator.establishobservation("pipe-0", 16666, 0, 0); observationcreator.addobservationlistener("pipe-0", 16666, 0, 0, process1monitor); observationcreator.addobservationlistener("pipe-0", 16666, 0, 0, process2monitor); // power owner observationcreator.establishobservation("power-0", 16666, 0, 0); observationcreator.addobservationlistener("power-0", 16666, 0, 0, process1monitor); observationcreator.addobservationlistener("power-0", 16666, 0, 0, process2monitor); Κώδικας 5-4: μέρος του κώδικα εγκαθίδρυσης των observe notify σχέσεων (κλάση LiqueurPlantServer) Για κάθε εισερχόμενο notify μήνυμα το leshan εκκινεί ένα νήμα το οποίο ειδοποιεί όλους τους ObservationListeners του αντίστοιχου Observation. Αναλυτικά: κατά την παραλαβή ενός notify μηνύματος ξεκινάει το νήμα του leshan το οποίο εκτελεί τη μέθοδο newvalue() καθενός ObservationListener του αντίστοιχου Observation. Αυτή η μέθοδος έχει διαφορετικό σώμα για κάθε ProcessMonitor (στην κληρονομούμενη κλάση ProcessMonitorAbstract είναι δηλωμένη ως abstract μέθοδος) και αφού κάνει τις απαραίτητες ενέργειες ώστε να ενημερωθεί η τοπική κατάσταση, ειδοποιεί όλα τα νήματα που περιμένουν στο monitor πως έγινε κάποια αλλαγή. Όσον αφορά το βασικό νήμα κάθε γραμμής παραγωγής, αυτό είναι ένα νήμα που χρησιμοποιεί αποκλειστικά το αντίστοιχο monitor με τον τρόπο που αναλύθηκε παραπάνω και καθορίζει το πότε και με ποια σειρά πρέπει να γίνουν οι κατάλληλες ενέργειες στο σύστημα παραγωγής ώστε η γραμμή παραγωγής να λειτουργεί βέλτιστα και χωρίς διενέξεις με τους υπόλοιπους χρήστες του συστήματος παραγωγής (τις άλλες γραμμές παραγωγής). Σημειώνεται πως το βασικό νήμα της γραμμής παραγωγής #2 (LiqueurGenerationProcess2) χρησιμοποιεί ένα δεύτερο νήμα (SecondaryThread) για να παρουσιάζει την αναμενόμενη συμπεριφορά όπως αναλύθηκε στην 57

61 παράγραφο Η μέθοδος LiqueurGenerationProcess2.run() παρουσιάζεται ενδεικτικά στον Κώδικα 5-5. Οι παραπάνω κλάσεις παρουσιάζονται στο διάγραμμα κλάσεων της Εικόνας public void run(){ String id=integer.tostring( getprocessid()); try{ monitor.sendsiloinfill(); monitor.sendsilooutempty(); monitor.waitforsiloinfillingcompleted(); monitor.sendsiloinheat(); monitor.initializeheat(); monitor.waitforsiloinheatingcompleted(); monitor.waitforsilooutemptyingcompleted(); while(continueproduction){ monitor.sendacquirepipe(id); monitor.waitforpipe(id); monitor.initializetransfer(); monitor.sendsiloinempty(); monitor.sendsilooutfill(); monitor.waitforliqueurtransfer(); monitor.sendsiloinstop(); monitor.sendsilooutstop(); monitor.sendreleasepipe(id); monitor.sendsiloinfill(); monitor.sendacquirepower(id); secondarythread=new SecondaryThread(); secondarythread.start(); monitor.waitforpower(id); monitor.sendsilooutmix(); monitor.initializemix(); monitor.waitforsilooutmixingcompleted(); monitor.sendreleasepower(id); monitor.sendsilooutempty(); monitor.waitforsilooutemptyingcompleted(); try { secondarythread.join(); } catch (InterruptedException e) {e.printstacktrace();} } } catch(interruptedexception e){e.printstacktrace();} }//end run Κώδικας 5-5: μέθοδος LiqueurGenerationProcess2.run() 58

62 Εικόνα 5-12: μέρος του διαγράμματος κλάσεων του server 59

63

64 6. Εξομοιωτής του μηχανικού σιλό 6.1. Περιγραφή Για την προσομοίωση της διαδικασίας παραγωγής liqueur με σκοπό το γενικότερο έλεγχο της σωστής λειτουργίας του συστήματος ελέγχου που αναπτύχθηκε, δημιουργήθηκαν κάποιοι εξομοιωτές (emulators) των απαραίτητων φυσικών υποσυστημάτων. Αυτά περιλαμβάνουν μόνο τα τέσσερα σιλό παραγωγής αφού για την προσομοίωση των κοινόχρηστων πόρων δεν απαιτείται κάτι άλλο πέρα από τις εφαρμογές που αναλύθηκαν σε προηγούμενο κεφάλαιο. Για την ευκολότερη παρακολούθηση όμως της κατάστασης του συστήματος κάθε στιγμή, προστέθηκε μια γραφική διεπαφή σε κάθε κοινόχρηστο πόρο στην οποία απεικονίζεται ο τρέχων ιδιοκτήτης του πόρου και οι εκκρεμείς αιτήσεις των ενδιαφερόμενων για τη χρήση του. Όσον αφορά τα σιλό, λόγω της ομοιότητας μεταξύ τους, αναπτύχθηκε ο εξομοιωτής ενός μόνο σιλό ο οποίος περιλαμβάνει όλα τα κοινά χαρακτηριστικά των τεσσάρων σιλό των προδιαγραφών και επιπλέον ένα στοιχείο θέρμανσης και ένα μίξης. Τα δύο τελευταία μπορούν, ανεξάρτητα μεταξύ τους, να απενεργοποιηθούν είτε απλά να μην χρησιμοποιηθούν καθιστώντας αυτόν τον εξομοιωτή ικανό να εξομοιώσει τη συμπεριφορά οποιουδήποτε από τα τέσσερα σιλό των προδιαγραφών. Έτσι με τη χρήση τεσσάρων τέτοιων εξομοιωτών είναι δυνατή η προσομοίωση του LPPS Προδιαγραφές - Απαιτήσεις Η βασική απαίτηση από τον εξομοιωτή του σιλό είναι να υλοποιεί το interface SiloDriverInterface και να ανταποκρίνεται με ένα τρόπο παρόμοιο με εκείνο ενός πραγματικού σιλό. Συγκεκριμένα: Το επίπεδο του υγρού να ανεβαίνει με σταθερό ρυθμό όσο η βαλβίδα εισαγωγής είναι ανοιχτή και η βαλβίδα εξαγωγής κλειστή. Το επίπεδο του υγρού να κατεβαίνει με σταθερό ρυθμό όσο η βαλβίδα εισαγωγής είναι κλειστή και η βαλβίδα εξαγωγής ανοιχτή. Οι αισθητήρες παρουσίας υγρού να ανταποκρίνονται χωρίς κάποια καθυστέρηση στην παρουσία υγρού. Η θερμοκρασία του υγρού να αυξάνεται με σταθερό ρυθμό όσο το στοιχείο θέρμανσης είναι ενεργό και να εξισώνεται με τη θερμοκρασία δωματίου όταν στο σιλό εισέρχεται μη θερμασμένο υγρό. 61

65 Για την ορθή επικοινωνία μεταξύ του εξομοιωτή σιλό και του συστήματος ελέγχου του σιλό, ο εξομοιωτής θα πρέπει να αξιοποιεί ένα αντικείμενο τύπου SiloControllerInterface, το οποίο του δίνεται (passed) κατά την αρχικοποίησή του με κλήση της μεθόδου SiloDriverInterface. setcontroller(silocontrollerinterface controller), καλώντας τις κατάλληλες μεθόδους του, κατά την αλλαγή της τιμής της εξόδου των αισθητήρων παρουσίας υγρού. Εφόσον η διεπαφή μεταξύ εξομοιωτή και συστήματος ελέγχου του σιλό γίνεται στη γλώσσα προγραμματισμού java (τα προαναφερθέντα interfaces αποτελούν java interfaces), συνεπάγεται πως ένα απαραίτητο δομικό συστατικό οποιουδήποτε εξομοιωτή σιλό θα είναι ο οδηγός του σιλό (στο εξής: silo driver) ο οποίος αποτελεί ένα πρόγραμμα σε java που υλοποιεί τη διεπαφή μεταξύ του συστήματος ελέγχου του σιλό και της κατασκευής που υλοποιεί τη λογική της εξομοίωσης Software Silo Emulator Ο πρώτος εξομοιωτής που αναπτύχθηκε είναι εξ ολοκλήρου υλοποιημένος σε software και πιο συγκεκριμένα σε java. Η κλάση γύρω από την οποία είναι δομημένη η εφαρμογή είναι η SiloSimulatorDriver. Αυτή υλοποιεί και τη διεπαφή με το σύστημα ελέγχου του σιλό (υλοποιεί το SiloDriverInterface και αξιοποιεί ένα αντικείμενο τύπου SiloControllerInterface ) αλλά και τη λογική της εξομοίωσης της συμπεριφοράς του σιλό. Το τελευταίο επιτυγχάνεται με τη βοήθεια τριών βοηθητικών κλάσεων: της SiloLiquidLevel η οποία είναι μια αναπαράσταση του εξομοιούμενου επιπέδου του υγρου στη δεξαμενή, της HeatingSimulator η οποία διευκολύνει τη διαχείριση της εξομοιούμενης θερμοκρασίας του υγρού εντός του σιλό και της SiloSimulatorTimer η οποία αξιοποιώντας την κλάση Timer της βασικής βιβλιοθήκης της java, υλοποιεί τον απαραίτητο μηχανισμό polling για την ανανέωση της κατάστασης του σιλό. Συγκεκριμένα οι δύο παράμετροι που μπορεί να αλλάξουν την κατάσταση του σιλό μετά από κάποιο χρονικό διάστημα, ακόμα κι αν τίποτα άλλο δεν έχει αλλάξει στο σιλό είναι i) το επίπεδο του υγρού και ii) η θερμοκρασία του περιεχομένου του σιλό. Γι αυτό και δύο SiloSimulatorTimers επαναλαμβάνουν κάθε συγκεκριμένο χρονικό διάστημα τον αντίστοιχο έλεγχο και αν χρειάζεται αλλάζουν και την κατάσταση του σιλό. 62

66 Επιπλέον ο εξομοιωτής περιλαμβάνει και μια γραφική διεπαφή (SiloSimulatorGui) στην οποία απεικονίζεται σε πραγματικό χρόνο η κατάσταση του σιλό (Εικόνα 6-1). Εικόνα 6-1: Γραφική διεπαφή του 1 ου εξομοιωτή σιλό Σημειώνεται ακόμα πως κατά την δημιουργία του εξομοιωτή πρέπει να δοθούν οι παρακάτω κατασκευαστικές παράμετροι: 1. hasmixer, hasheater: Boolean μεταβλητές που καθορίζουν αν το σιλό που εξομοιώνεται διαθέτει στοιχείο μείξης και θέρμανσης αντίστοιχα. 2. highlevelsensorheight και lowlevelsensorheight: ορίζονται δέκα ισαπέχουσες στάθμες στο ύψος του σιλό (0 για το κατώτατο επίπεδο έως και 10 για το ανώτατο) στις οποίες μπορούν να τοποθετηθούν οι ανιχνευτές υγρού. 3. time2fill: ο χρόνος σε ms που χρειάζεται για να ανέβει το υγρό από την n στην n+1 στάθμη όταν το σιλό γεμίζει ή ο χρόνος που χρειάζεται για να κατέβει το υγρό από την n+1 στην n στάθμη όταν το σιλό αδειάζει. Οι παράμετροι 2 και 3 προστέθηκαν ώστε να πραγματοποιηθούν προσομοιώσεις με διαφορετικές παραμέτρους για κάθε σιλό, κάτι που θα οδηγήσει σε πιο αξιόπιστα αποτελέσματα. Οι παράμετροι δίνονται στον constructor της SiloSimulatorDriver με τη μορφή ενός στιγμιότυπου της κλάσης SiloParameters. Τα παραπάνω φαίνονται στο διάγραμμα κλάσεων στην Εικόνα

67 Εικόνα 6-2: Διάγραμμα κλάσεων του 1ου εξομοιωτή σιλό 64

68 6.3. Hardware Silo Emulator Ο δεύτερος εξομοιωτής που αναπτύχθηκε αποτελείται από ένα ψηφιακό ηλεκτρονικό κύκλωμα. Η λογική της εξομοίωσης εκτελείται σε έναν 8-bit μικροελεγκτή Atmel ATmega328 ο οποίος βρίσκεται σε μια πλακέτα Arduino Nano η οποία χρησιμοποιήθηκε για τον ευκολότερο προγραμματισμό του, μέσω καλωδίου USB. Ο εξομοιωτής επικοινωνεί με το μικροϋπολογιστή (Raspberry pi 2 (RPi)) στον οποίο εκτελείται το λογισμικό του συστήματος ελέγχου του σιλό με ψηφιακά ηλεκτρικά σήματα. ( Ο μικροϋπολογιστής RPi επιλέχθηκε λόγω της δυνατότητάς του για εκτέλεση java εφαρμογών και των I/O ακίδων που διαθέτει για τη σύνδεσή του με τον εξομοιωτή.) Επιπλέον η συνολική κατάσταση του σιλό αντικατοπτρίζεται σε πραγματικό χρόνο σε οπτικές και ακουστικές ενδείξεις που περιλαμβάνονται στο κύκλωμα. Το κύκλωμα και η πλακέτα (PCB) του εξομοιωτή σχεδιάστηκε στο πρόγραμμα σχεδιασμού Eagle Hardware Για την πλήρη αναπαράσταση της τρέχουσας κατάστασης του σιλό, το κύκλωμα διαθέτει: μία μπάρα led 10 τμημάτων(10 segment led bar) για την απεικόνιση της στάθμης του υγρού εντός του σιλό, δύο led για την ένδειξη της κατάστασης των βαλβίδων εισόδου και εξόδου, δύο led για την ένδειξη της εξόδου των αισθητήρων παρουσίας υγρού, ένα led για την ένδειξη της κατάστασης του στοιχείου θέρμανσης και ένα led, αλλά και ένα buzzer, για την ένδειξη της κατάστασης του στοιχείου μείξης, δύο 7-segment displays για την ένδειξη της τρέχουσας θερμοκρασίας του σιλό Ο επιλεγμένος μικροελεγκτής δεν είναι ικανός να οδηγήσει απευθείας τόσα πολλά led γι αυτό και στο κύκλωμα προστέθηκαν εξειδικευμένα ολοκληρωμένα κυκλώματα: για την οδήγηση των ενδείξεων της θερμοκρασίας χρησιμοποιήθηκε το MAX7219 από τη Maxim. Το ολοκληρωμένο αυτό είναι ένα led display driver ικανό να οδηγεί (μεταξύ άλλων) μέχρι και οχτώ 7- segment displays (πολυπλέκοντάς τα). Για την επικοινωνία υποστηρίζει το πρωτόκολλο SPI, και είναι σχεδιασμένο για τροφοδοσία στα 5 Volts. Για την οδήγηση των υπόλοιπων leds επιλέχθηκε το TPIC6B596 της Texas Instruments. Το ολοκληρωμένο αυτό περιλαμβάνει έναν 8-bit shift register ο οποίος τροφοδοτεί 8 DMOS σε συνδεσμολογία open drain, ικανά να οδηγήσουν ρεύμα έως και 150mA το καθένα. το TPIC6B596 έχει

69 τη δυνατότητα να συνδεθεί αλυσιδωτά (daisy chained) με άλλα TPIC6B596 εξοικονομώντας τις ακίδες εισόδου/εξόδου (GPIO pins) του μικροελεγκτή. Τα led που έπρεπε να οδηγηθούν από αυτό το ολοκληρωμένο ήταν 16, γι αυτό και χρησιμοποιήθηκαν δύο daisy chained TPIC6B596. Το κύκλωμα, εκτός από τις ενδείξεις αυτές, περιλαμβάνει και έναν ψηφιακό αισθητήρα θερμοκρασίας (maxim DS18B20) σε συσκευασία TO-92. Ο αισθητήρας αυτός προστέθηκε ούτως ώστε να δίνεται η δυνατότητα στο χρήστη να αλλάζει την εξομοιούμενη θερμοκρασία του σιλό θερμαίνοντας τον αισθητήρα. Η επιλογή ανάμεσα σε θερμοκρασία που θα εξομοιώνεται από το λογισμικό του κυκλώματος και σε απευθείας ένδειξη από το θερμόμετρο γίνεται με 2 jumpers τα οποία στην τελική πλακέτα που σχεδιάστηκε τοποθετήθηκαν ως solder jumpers στην πίσω μεριά της πλακέτας. Ο μικροελεγκτής ATmega328 τροφοδοτείται από τάση +5 Volts, όσο είναι για αυτόν και το επίπεδο τάσης του λογικού 1. Επειδή όμως το κύκλωμα αυτό σχεδιάστηκε για να επικοινωνεί με ένα RPi, του οποίου το λογικό 1 είναι στα 3.3 Volts, το κύκλωμα περιλαμβάνει και τα απαραίτητα στοιχεία ώστε οι I/O ακίδες από τις οποίες γίνεται η επικοινωνία να λειτουργούν με το λογικό 1 στα 3.3 Volts. 1. FULL (έξοδος) : ο άνω αισθητήρας υγρού ανιχνεύει υγρό 2. EMPTY (έξοδος) : ο κάτω αισθητήρας υγρού ανιχνεύει υγρό 3. +5V (είσοδος/έξοδος) : αν ο εξομοιωτής τροφοδοτείται από την USB του Arduino nano, τότε μπορεί να χρησιμοποιηθεί για να παρέχει τροφοδοσία 5 Volts σε εξωτερικά κυκλώματα. Σε άλλη περίπτωση, ο εξομοιωτής μπορεί να τροφοδοτείται από αυτή την ακίδα. 4. DS18B20 DQ (είσοδος/έξοδος) : Συνδέεται στην DQ ακίδα του ολοκληρωμένου κυκλώματος DS18B GND V (έξοδος) : παρέχεται τάση 3.3Volts για τροφοδοσία εξωτερικών κυκλωμάτων 7. HEATER (είσοδος) : ενεργοποιεί το στοιχείο θέρμανσης 8. INVALVE (είσοδος) : ενεργοποιεί τη βαλβίδα εισόδου 9. ΤΧ (έξοδος) : σειριακή έξοδος. Κάθε φορά που η μετρούμενη θερμοκρασία μεταβάλλεται, μεταδίδεται το string: T=xx (όπου xx είναι η νέα θερμοκρασία) ακολουθούμενο από τον ASCII χαρακτήρα LF (0xA). 10. OUTVALVE (είσοδος) : ενεργοποιεί τη βαλβίδα εξόδου 11. RX (είσοδος) : σειριακή είσοδος. Δε χρησιμοποιείται. Παρέχεται για πιθανή μελλοντική χρήση. 12. MIXER (είσοδος) : ενεργοποιεί το στοιχείο μείξης Μετά από τις βασικές λειτουργικές δοκιμές σε ένα πρωτότυπο του κυκλώματος, σχεδιάστηκε και κατασκευάστηκε κατάλληλη πλακέτα (PCB). Η τελική της μορφή μετά την τοποθέτηση όλων των εξαρτημάτων φαίνεται στην Εικόνα

70 Εικόνα 6-3: 3-D απεικόνιση του τελικού κυκλώματος του 2 ου εξομοιωτή σιλό Software Silo Driver Ο silo driver που αναπτύχθηκε για το δεύτερο εξομοιωτή είναι σχεδιασμένος για το RPi. Αποκλειστικός του ρόλος του είναι η μεταβίβαση μηνυμάτων μεταξύ της java εφαρμογής του συστήματος ελέγχου του σιλό και του I/O ακίδων του RPi (προς τον εξομοιωτή). Για τη πρόσβαση στις I/O ακίδες του RPi και την αξιοποίηση όλων των δυνατότητων που παρέχονται από το RPi για αυτές, χρησιμοποιήθηκε η java βιβλιοθήκη Pi4J [30]. Στη βιβλιοθήκη αυτή, κάθε I/O ακίδα ψηφιακού σήματος του RPi αναπαρίσταται με ένα αντικείμενο τύπου GpioPinDigitalInput (αν λειτουργεί ως είσοδος) ή GpioPinDigitalOutput (αν λειτουργεί ως έξοδος). Κάθε πιθανό ζεύγος αποστολέα-είδος μηνύματος εξυπηρετείται από έναν διαφορετικό μηχανισμό όπως φαίνεται στον πίνακα 6-1. Τα παραπάνω φαίνονται σχηματικά στο διάγραμμα κλάσεων στην Εικόνα

71 αποστολέας\ είδος μηνύματος σύστημα ελέγχου σιλό αλλαγή λογικού επιπέδου I/O ακίδας Αξιοποίηση της μεθόδου GpioDigitalOutput.setState(boolean state) που παρέχεται από το Pi4J μήνυμα στη σειριακή θύρα επικοινωνίας Δεν αξιοποιείται εξομοιωτής σιλό Η βιβλιοθήκη Pi4J παρέχει μηχανισμό δήλωσης listener για αλλαγές τάσης στις ακίδες εισόδου. Η κλάση GpioListener υλοποιώντας το interface GpioPinListenerDigital, αξιοποιεί το μηχανισμό αυτό και ειδοποιείται σε κάθε αλλαγή, εκτελώντας τις απαραίτητες ενέργειες. Η βιβλιοθήκη Pi4J παρέχει μηχανισμό δήλωσης listener για εισερχόμενα μηνύματα στη σειριακή θύρα επικοινωνίας. Η κλάση SerialListener υλοποιώντας το interface SerialDataEventListener, αξιοποιεί το μηχανισμό αυτό. Πίνακας 6-1: Μηχανισμός της βιβλιοθήκης Pi4J που αξιοποιείται για κάθε συνδυασμό αποστολέα/είδος μηνύματος. 68

72 Εικόνα 6-4: Διάγραμμα κλάσεων του 1 ου εξομοιωτή σιλό Silo Emulator Για την ανάπτυξη της εφαρμογής που εκτελείται στο μικροελεγκτή του κυκλώματος, χρησιμοποιήθηκε το περιβάλλον ανάπτυξης Arduino. Η γλώσσα προγραμματισμού του Arduino είναι 69

73 μία περιορισμένη έκδοση της C++ επαυξημένη με κάποιες ειδικού σκοπού βιβλιοθήκες. Έτσι ακολουθήθηκε μια αντικειμενοστραφής προσέγγιση στο σχεδιασμό της εφαρμογής. Η κλάση InputsHandler έχει το ρόλο να διαβάζει τις εισόδους του κυκλώματος και να τις οργανώνει σε ένα byte(η κωδικοποίησή του φαίνεται στον πίνακα 6-2) το οποίο και προωθεί στη LogicImplementer. Αυτό γίνεται επαναληπτικά (polling) καθ όλη τη διάρκεια εκτέλεσης του προγράμματος με την κλήση της μεθόδου InputsHandler.check(). bit d0 d1 d2 d3 d5-d7 Αντιστοιχία HEATER MIXER OUTVALVE INVALVE Δε χρησιμοποιούνται Πίνακας 6-2: κωδικοποίηση αναπαράστασης εισόδων του σιλό με ένα byte Η LogicImplementer δέχεται ως είσοδο τις τρέχουσες εισόδους του κυκλώματος, υπολογίζει τη συνολική κατάσταση του σιλό και την προωθεί στην OutputsHandler. Αναλυτικά: Η LogicImplementer διατηρεί εσωτερικά μια αναπαράσταση της κατάστασης του σιλό με τη μορφή μιας 16 bit λέξης. (πίνακας 6-3). bit d0-d9 d10 d11 d12 d13 d14 d15 Αντιστοιχία επίπεδο υγρού: 1(κατώτατο) έως 10(ανώτατο) INVALVE OUTVALVE FULL EMPTY HEATER MIXER Πίνακας 6-3: κωδικοποίηση κατάστασης του σιλό με μία 16-bit λέξη 70

74 Κάθε φορά που συμβαίνει ένα γεγονός, υπολογίζεται η νέα κατάσταση του σιλό και προωθείται στην OutputsHandler. Ως γεγονός νοείται ένα από τα παρακάτω: Αλλαγή κάποιας από τις εισόδους του κυκλώματος Γεγονός έλευσης χρόνου: η κατάσταση του σιλό είναι δυνατόν να αλλάξει και με την έλευση ενός συγκεκριμένου χρονικού διαστήματος. Για παράδειγμα: το επίπεδο του υγρού πρέπει να ανέβει κατά την πλήρωση του σιλό ή η θερμοκρασία πρέπει να αυξηθεί κατά τη λειτουργία του στοιχείου θέρμανσης. Η κλάση LogicImplementer αξιοποιεί τη λειτουργικότητα που παρέχουν τρεις βοηθητικές κλάσεις: LiquidLevel: Είναι μια αναπαράσταση του επιπέδου του υγρού στο σιλό συνοδευόμενη από μεθόδους για εύκολη διαχείρισή του. IOWord: Μία 16-bit λέξη με μεθόδους για διαχείρισή της σε επίπεδο bits, bytes ή/και word. MyTimer1: ένας γενικού σκοπού μετρητής χρόνου. Χρησιμοποιούνται δύο στιγμιότυπά της, ένα για το επίπεδο του υγρού και ένα για τη θερμοκρασία, με τρόπο αντίστοιχο της κλάσης SiloSimulatorTimer από τον Software Silo Simulator(6.2). Η τελευταία κλάση που χρησιμοποιείται είναι η OutputsHandler, η οποία δέχεται την ψηφιακή αναπαράσταση του σιλό (με τη μορφή μιας 16-bit λέξης με την ίδια κωδικοποίηση χρησιμοποιείται στην LogicImplementer και ενός ακέραιου αριθμού που αναπαριστά την τρέχουσα θερμοκρασία του σιλό) και ενημερώνει κατάλληλα τις ακίδες εξόδου, τα ενδεικτικά led και το buzzer του κυκλώματος. Το διάγραμμα κλάσεων που απεικονίζει τις σχέσεις μεταξύ των παραπάνω κλάσεων φαίνεται στην Εικόνα

75 Εικόνα 6-5: Διάγραμμα κλάσεων του προγράμματος που εκτελείται στον μικροελεγκτή του κυκλώματος 72

76 7. IEC61131 εξομοιωτής 7.1. Εισαγωγή κίνητρα Σήμερα, η συντριπτική πλειοψηφία των βιομηχανικών αυτοματισμών είναι βασισμένη σε PLC s των οποίων το λογισμικό είναι ανεπτυγμένο στα πλαίσια του προτύπου IEC το οποίο ορίζει ένα σύνολο από γλώσσες προγραμματισμού σχεδιασμένες ειδικά για τα PLC s. Η ομαλή μετάβαση από ένα παραδοσιακό αυτοματοποιημένο βιομηχανικό σύστημα σε ένα σύγχρονο IIOT σύστημα θα είναι αναγκαστικά σταδιακή. Τα συστήματα αυτά συχνά αποτελούνται από εκτεταμένα δίκτυα PLC s των οποίων το λογισμικό είχε το χρόνο να δοκιμαστεί και να αποσφαλματωθεί (debug) σε βάθος ώστε να χαρακτηρίζεται από τον υψηλό βαθμό αξιοπιστίας που απαιτεί ένα βιομηχανικό σύστημα. Μια πλήρης μετατροπή ενός τέτοιου συστήματος σε ένα σύμφωνο με τις αρχές του IOT θα σήμαινε ένα πολύ μεγάλο κόστος σε σχεδιασμό, προγραμματισμό, αποσφαλμάτωση και χρόνο μη λειτουργίας (downtime). Γι αυτό το λόγο και κρίνεται αποδοτικότερη η λύση της σταδιακής αντικατάστασης επιμέρους υποσυστημάτων με IOT-συμβατά. Μια μεγάλη ανησυχία των κατασκευαστών είναι το πρόβλημα της διασύνδεσης των παραδοσιακού τύπου συστημάτων με τα νέα IOT-συμβατά. Ένα από τα εργαλεία που μπορούν να προσφέρουν λύση σε αυτό το πρόβλημα είναι η προσθήκη στα παραδοσιακά συστήματα ενός IOT-wrapper δηλαδή ενός επιπέδου (layer) στη χρησιμοποιούμενη στοίβα πρωτοκόλλων επικοινωνίας το οποίο λειτουργεί επάνω από το IEC61131 επίπεδο και δίνει πρόσβαση στις υπηρεσίες του συστήματος στον εξωτερικό κόσμο με έναν τρόπο σύμφωνο με τις αρχές του IOT. Η ανάπτυξη του 3 ου εξομοιωτή σιλό είχε ως στόχο την εξέταση της παραπάνω ιδέας Γενική περιγραφή Για τον 3 ο εξομοιωτή σιλό, αρχικά αξιοποιήθηκε το κύκλωμα του 2 ου εξομοιωτή και ένα RPi που λειτουργούσε ως PLC για να δημιουργηθεί ο εξομοιωτής ενός παραδοσιακού τύπου σιλό βασισμένο σε PLC. Στη συνέχεια αναπτύχθηκε ένας silo driver σε java ο οποίος καθιστά το παραπάνω σιλό λειτουργικά συμβατό με το LPPS έτσι ώστε να μπορεί να λειτουργήσει ως ένα από τα τέσσερα σιλό του LPPS χωρίς καμία άλλη αλλαγή (Εικόνα 7-1). Αναλυτικά: 73

77 Για την ανάπτυξη του εξομοιωτή PLC, χρησιμοποιήθηκε η πλατφόρμα ανάπτυξης CODESYS σε συνδυασμό με το πρόσθετο CODESYS Control for Raspberry Pi SL το οποίο επιτρέπει στο RPi να προγραμματίζεται μέσα από το CODESYS και να λειτουργεί όπως ένα PLC αξιοποιώντας τις I/O ακίδες του RPi για τη διασύνδεσή του με μηχανικά συστήματα όπως ο εξομοιωτής σιλό. Αυτό το δομικό στοιχείο (component) αναπαρίσταται στην Εικόνα 7-1 ως IEC61131 LAYER. Η επικοινωνία του με τον εξωτερικό κόσμο γίνεται μέσω της κατασκευής των named pipes του Linux, τα οποία είναι εμφανίζονται ως αρχεία στα οποία όταν μία διεργασία αποστέλλει δεδομένα για εγγραφή, τότε αυτά αμέσως προωθούνται σε κάποια άλλη η οποία έχει ανοίξει το ίδιο αρχείο-named pipe για ανάγνωση. Αυτός ο τρόπος επικοινωνίας διεργασιών χρησιμοποιήθηκε διότι ο silo driver εκτελείται στον ίδιο υπολογιστικό κόμβο (RPi) και τα named pipes ήταν ένας γρήγορος, αμφίδρομος και εύκολα υλοποιήσιμος τρόπος επικοινωνίας μεταξύ δύο διεργασιών (μίας IEC61131 και μίας Java). Ακόμα κι αν αυτό προϋποθέτει πως ένας κόμβος εκτελεί ταυτόχρονα διεργασίες σε IEC61131 και Java, κάτι τέτοιο δεν είναι απαραίτητο. Σε ένα διαφορετικό σενάριο όπου ο silo driver εκτελείται στο δικό του υπολογιστικό κόμβο, η επικοινωνία με το PLC θα μπορούσε να γίνει, χωρίς καμία αλλαγή στην ουσία της ιδέας, με χρήση κάποιου ευρέως χρησιμοποιούμενου βιομηχανικού πρωτοκόλλου επικοινωνίας όπως CANopen, EtherCAT, Modbus κτλ. Raspberry Pi Java Linux Pipes IEC61131 Electronic signals Application Core SiloController Interface Silo Driver cod2j IEC61131 LAYER Physical silo/ silo emulator j2cod SiloDriverInterface Εικόνα 7-1: Τα βασικά components του 3 ου εξομοιωτή σιλό και οι διεπαφές ανάμεσά τους. Δύο pipes χρησιμοποιήθηκαν, ένα για κάθε κατεύθυνση ροής δεδομένων: Cod2j: ροή δεδομένων από το IEC61131 LAYER προς τον java silo driver J2cod: ροή δεδομένων από το silo driver προς το IEC61131 LAYER Στο πρώτο, το IEC61131 LAYER αποστέλλει επαναλαμβανόμενα ένα string τεσσάρων χαρακτήρων με την εξής σημασία: 74

78 χαρακτήρας σημασία τιμή 0 Temperature digit (θερμοκρασία σε δεκαδικό 1 Temperature digit1 σύστημα) 2 έξοδος άνω αισθητήρα ανίχνευσης υγρού (FULL) 3 έξοδος κάτω αισθητήρα ανίχνευσης υγρού (EMPTY) '1' όταν ο αισθητήρας ανιχνεύει υγρό. '0' διαφορετικά. Πίνακας 7-1: Κωδικοποίηση χαρακτήρων για αποστολή στο cod2j named pipe Στο j2cod named pipe, o silo driver αποστέλλει το string με την εξής σημασία όταν του μεταβιβάζεται μια εντολή από τον SiloController με τον οποίο έχει συσχετιστεί: χαρακτήρας σημασία τιμή 0 HEATER '1' για ενεργοποίηση στοιχείου. '0' για απενεργοποίηση. 1 MIXER '1' για ενεργοποίηση στοιχείου. '0' για απενεργοποίηση. 2 OUT VALVE '1' για άνοιγμα βαλβίδας. '0' για κλείσιμο. 3 IN VALVE '1' για άνοιγμα βαλβίδας. '0' για κλείσιμο. Πίνακας 7-2: Κωδικοποίηση χαρακτήρων για αποστολή στο j2cod named pipe 7.3. Δομή Silo driver Η κεντρική κλάση είναι η SiloCodesysDriver η οποία υλοποιεί το interface SiloDriverInterface και διαθέτει μια εσωτερική αναπαράσταση των εισόδων από το PLC (στιγμιότυπο της SiloInputs) και μία των εξόδων προς το IEC61131 LAYER (στιγμιότυπο της SiloOutputs). Επιπλέον υλοποιεί το interface PipeFillerSource ώστε να μπορεί να λειτουργεί ως πηγή δεδομένων(που περιέχει η SiloOutputs) για την OutPipeFiller η οποία προωθεί τα δεδομένα αυτά σε ένα PipePrinterInterface για την προώθησή τους προς το named pipe j2cod. 75

79 Ο ρόλος της κλάσης PipeTailer είναι να προωθεί τα εισερχόμενα δεδομένα (από το named pipe cod2j) σε έναν PipeTailerListener. Το interface αυτό υλοποιείται από την κλάση SiloCodesysDriver. Οι προαναφερθείσες κλάσεις και οι βασικές σχέσεις τους φαίνονται στο διάγραμμα κλάσεων στην Εικόνα 7-2. Εικόνα 7-2: Διάγραμμα κλάσεων του silo driver component του 3 ου εξομοιωτή σιλό. 76