Καθηγητής Κλεάνθης Θραμπουλίδης

Transcript

1 ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΑΤΡΩΝ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΤΕΧΝΟΛΟΓΙΑΣ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ: Ηλεκτρονικής και Υπολογιστών Διπλωματική Εργασία του φοιτητή του Τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών της Πολυτεχνικής Σχολής του Πανεπιστημίου Πατρών Νικολούλη Κων/νου-Ανδρέα Αριθμός Μητρώου:6592 Θέμα «Αξιοποιώντας την τεχνολογία του service oriented computing σε συστήματα βιομηχανικού αυτοματισμού» Επιβλέπων Καθηγητής Κλεάνθης Θραμπουλίδης Αριθμός Διπλωματικής Εργασίας:

2

3 ΠΙΣΤΟΠΟΙΗΣΗ Πιστοποιείται ότι η Διπλωματική Εργασία με θέμα «Αξιοποιώντας την τεχνολογία του Service Oriented Computing σε συστήματα βιομηχανικού αυτοματισμού» Του φοιτητή του Τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών Νικολούλη Κων/νου-Ανδρέα Αριθμός Μητρώου:6592 Παρουσιάστηκε δημόσια και εξετάστηκε στο Τμήμα Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών στις 17/7/2012 Ο Επιβλέπων Ο Διευθυντής του Τομέα Κλεάνθης Θραμπουλίδης Καθηγητής Ευθύμιος Χούσος Καθηγητής

4

5 Αριθμός Διπλωματικής Εργασίας: Θέμα: «Αξιοποιώντας την τεχνολογία του service oriented computing σε συστήματα βιομηχανικού αυτοματισμού» Φοιτητής: Νικολούλης Κων/νος Επιβλέπων: Καθηγητής Κλεάνθης Θραμπουλίδης Περίληψη Το παράδειγμα του Service Oriented computing αναφέρεται σε ένα σύνολο από έννοιες, αρχές και μεθόδους οι οποίες αξιοποιούν την Service Oriented αρχιτεκτονική, σύμφωνα με την οποία οι εφαρμογές λογισμικού κατασκευάζονται από ανεξάρτητες συνιστώσες υπηρεσιών με πρότυπες διεπαφές. Η υπηρεσιοστρεφής (Service Oriented) αρχιτεκτονική είναι ένα σύνολο από κανόνες και μεθοδολογίες για το σχεδιασμό και την ανάπτυξη λογισμικού με τη μορφή διαλειτουργικών υπηρεσιών. Μία από τις σημαντικότερες τεχνολογίες για την αξιοποίηση αυτής της αρχιτεκτονικής είναι τα Web Services. Τα Web Services είναι μία τεχνολογία σχεδιασμένη για την υποστήριξη διαλειτουργικών αλληλεπίδρασης σταθμών πάνω από το διαδίκτυο. Τα συστήματα βιομηχανικών αυτοματισμών είναι συστήματα τα οποία χρησιμοποιούνται για την αύξηση της απόδοσης των βιομηχανικών καθώς και των διαδικασιών παραγωγής. Οι παραδοσιακές τεχνικές ανάπτυξης των συστημάτων αυτών δεν ικανοποιούν πλέον τις απαιτήσεις των σύνθετων βιομηχανικών συστημάτων και υπάρχει μια τάση για αξιοποίηση τεχνολογιών αιχμής από την περιοχή του Software Engineering. Στην κατεύθυνση αυτή η παρούσα εργασία μελετά τα πλεονεκτήματα αλλά και τα μειονεκτήματα που προσφέρει η αξιοποίηση του SOC παραδείγματος στην ανάπτυξη βιομηχανικών συστημάτων. Μελετήθηκε η DPWS τεχνολογία η οποία αποτελεί μια επέκταση της τεχνολογίας των Web Services με σκοπό την ικανοποίηση των αναγκών που παρουσιάζουν οι εφαρμογές βιομηχανικού αυτοματισμού. Ως μελέτη περίπτωσης χρησιμοποιήθηκε το εργαστηριακό σύστημα Festo MPS. Σχεδιάστηκε και υλοποιήθηκε ένας εξομοιωτής του συστήματος αυτού, ο οποίος στη συνέχεια επεκτάθηκε για να είναι συμβατός με την DPWS Τεχνολογία. Με βάση αυτόν σχεδιάστηκε και υλοποιήθηκε ένας ελεγκτής του συστήματος ο οποίος αξιοποιώντας τις υπηρεσίες που προσφέρει η DPWS τεχνολογία υλοποίει την διαδικασία ελέγχου του συστήματος Festo MPS. Στη συνέχεια με βάση τα αποτελέσματα των δοκιμών προχωρήσαμε σε μια συνολική αξιολόγηση της τεχνολογίας.

6

7 Πρόλογος Η εκπόνηση της διπλωματικής εργασίας αυτής έγινε στο εργαστήριο συστημάτων υπολογιστών το χρονικό διάστημα Φεβρουάριος 2010-Ιουλιος Σε αυτό το σημείο θα ήθελα να ευχαριστήσω τον επιβλέποντα Καθηγητή Κ. Θραμπουλίδη για τη συνεχή βοήθεια και καθοδήγηση τnν οποία μου προσέφερε σε όλη τη διάρκεια της διαδικασίας έρευνας και ανάπτυξης καθώς και στη συγγραφή αυτής της εργασίας. Στη συνέχεια θέλω να ευχαριστήσω τον υποψήφιο Διδάκτορα Γ. Δούκα για τις πολύτιμες συμβουλές που μου έδωσε όσον αφορά το ζητήματα που αφορούσαν το τεχνικό κομμάτι αυτής της εργασίας. Τέλος θέλω να ευχαριστήσω τον φίλο και συμφοιτητή Στέλιο Συρίγο για τη πολύτιμη βοήθεια του.

8

9 Περιεχόμενα Εισαγωγή... 5 Κεφάλαιο Υπηρεσιοστρεφής αρχιτεκτονική Εισαγωγή Προσέγγιση της αρχιτεκτονικής με βάση τα Web Services Δομικά στοιχεία των Web Services Προδιαγραφές των Web Services Οφέλη της προσέγγισης των Web Services Κεφάλαιο Υπηρεσιοστρεφής αρχιτεκτονική στην περιοχή του Βιομηχανικού αυτοματισμού Εισαγωγή Περιορισμοί των συμβατικών μεθόδων Γιατί κινούμαστε προς την SOA αρχιτεκτονική Το έργο SIRENA SIRENA Devices Profile for Web Services εργαλειοθήκη Πρωτοβουλίες που δημιουργήθηκαν από το έργο SIRENA Web Services For Devices Initiative Το έργο SOCRADES Οι στόχοι του έργου SOCRADES Επίπεδα του SOCRADES Το έργο IMC-AESOP Κεφάλαιο Devices Profile for Web Services Εισαγωγή Devices Profile for Web Services Specifications DPWS Eventing Specification DPWS Discovery DPWS Addressing DPWS Description DPWS Security Μειονεκτήματα του DPWS

10 Εισαγωγή μεγάλου φόρτου στο δίκτυο Μεταφορά μεγάλου όγκου δεδομένων Κεφάλαιο Το σύστημα Festo MPS Εισαγωγή Το φυσικό σύστημα Festo MPS Μονάδα διανομής Μονάδα Ελέγχου Σύστημα μεταφοράς το τεμαχίου Μονάδα Επεξεργασίας Μονάδα Αποθήκευσης Festo MPS Εξομοιωτής Παρουσίαση δομής του εξομοιωτή Αποκλίσεις πραγματικού συστήματος και Festo Simulator Κεφάλαιο Εναλλακτικές προτάσεις σχεδίασης του συστήματος Εισαγωγή Προσέγγιση ως ολοκληρωμένο σύστημα Βιομηχανικού ελέγχου Απαιτήσεις σχεδίασης Συνιστώσες του Συστήματος Προτεινόμενες σχεδιάσεις Κατανεμημένος απομακρυσμένος έλεγχος Κεντρικός απομακρυσμένος ενορχηστρωτής Ειδικά προβλήματα του κεντρικού απομακρυσμένου ενορχηστρωτή και προτάσεις αντιμετώπισης Κεντρικός απομακρυσμένος ενορχηστρωτής με τοπικό έλεγχο Σύγκριση Κεφάλαιο Κλάσεις του συστήματος και εργαλεία υλοποίησης Εισαγωγή Διαθέσιμες DPWS εργαλειοθήκες από την WS4D πρωτοβουλία WS4D-gSOAP WS4D-uDPWS WS4D-Axis

11 WS4D-JCoap WS4D-JMEDS Παρουσίαση της WS4D-JMEDS εργαλειοθήκης DefaultDevice και Device DefaultService Operations και DefaultEventSource DefaultClient Ανάλυση των προσαρμοσμένων κλάσεων FestoMPS Festo Control Application Κεφάλαιο Υλοποίηση συστήματος Εισαγωγή Υλοποίηση με ολικό απομακρυσμένο έλεγχο Festo MPS Festo Control Μελέτη περίπτωσης του Feeder Υλοποίηση με Τοπικό και περιορισμένο απομακρυσμένο έλεγχο Festo MPS Festo Control Μελέτη περίπτωσης του Feeder Κεφάλαιο Συμπεράσματα Αξιολόγηση της Υπηρεσιοστρεφούς αρχιτεκτονικής για την σχεδίαση συστημάτων βιομηχανικών αυτοματισμών Αξιολόγηση της DPWS τεχνολογίας Προτάσεις για μελλοντική ερευνά Αναφορές

12 4

13 Εισαγωγή Τα δίκτυα βιομηχανικών αυτοματισμών αποτελούν τα τελευταία χρόνια τη μοναδική ολοκληρωμένη λύση για τη δημιουργία συστημάτων βιομηχανικού ελέγχου. Αν και η τεχνολογία αυτή προσφέρει πληθώρα εργαλείων και καλές αποδόσεις όσον αφορά την αξιοπιστία και την ταχύτητα τον υλοποιήσεων, παρουσιάζει ελλείψεις σε τομείς όπως η ευελιξία και η επεκτασιμότητα. Αυτά τα μειονεκτήματα πηγάζουν από την αρχιτεκτονική των δικτύων βιομηχανικών αυτοματισμών τα οποία προωθούν την βελτιστοποίηση σε βάρος της ευελιξίας. Ως αποτέλεσμα αυτού, έγιναν έρευνες προς την κατεύθυνση της επέκτασης ήδη υπαρχόντων αρχιτεκτονικών στον τομέα της επιστήμης των υπολογιστών ώστε να μπορούν να χρησιμοποιηθούν σε εφαρμογές βιομηχανικού τύπου. Μια τέτοιου είδους τεχνολογία είναι η Devices Profile for Web Services ( DPWS). Στα πλαίσια αυτής της εργασίας μελετάται η χρήση της υπηρεσιοστρεφούς αρχιτεκτονικής μέσω της DPWS τεχνολογίας ως πιθανή λύση για το πρόβλημα της μειωμένη ευελιξίας και επεκτασιμότητας. Το DPWS, βασίζεται στη τεχνολογία των Web Services ενώ παράλληλα εμπεριέχει πρόσθετα χαρακτηριστικά με σκοπό να ανταποκρίνεται στις απαιτήσεις των βιομηχανικών συστημάτων. Για να αξιολογηθεί η αποδοτικότητα του DPWS δημιουργήσαμε μία σειρά από υλοποιήσεις με βάση διαφορετικά σχεδιαστικά μοντέλα με σκοπό να δούμε την απόδοση της τεχνολογίας. Ως μελέτη περίπτωσης της λειτουργίας και της απόδοσης αυτών των υλοποιήσεων χρησιμοποιήθηκε το σύστημα Festo Mps. Τέλος, Βασιζόμενοι στην συμπεριφορά των υλοποιήσεων με βάση το σύστημα αυτό προχωρήσαμε σε διατύπωση συμπερασμάτων. Στο κεφάλαιο 1 παρουσιάζεται η υπηρεσιοστρεφής αρχιτεκτονική και η τεχνολογία των Web Services. Ειδικότερα, πρωτίστως παρουσιάζεται το αντικειμενοστρεφές αρχιτεκτονικό μοντέλο μέσω της λογικής σχεδίασης την οποία εισάγει και στη συνέχεια γίνεται ανάλυση του σημαντικότερου εκπροσώπου αυτής της αρχιτεκτονικής, της τεχνολογίας των Web Services. Στο κεφάλαιο 2 παραθέτουμε τους λόγους και τις σημαντικότερες κινήσεις που έγιναν ώστε να ενσωματωθεί η τεχνολογία των Web Services στη υλοποίηση συστημάτων βιομηχανικού ελέγχου. Οι κινήσεις αυτές είχαν ως αφετηρία το πρόγραμμα SIRENA το οποίο παρήγαγε την πρώτη υλοποίηση εργαλείου ανάπτυξης με βάση την DPWS τεχνολογία. Η εξέλιξη της τεχνολογίας συνεχίστηκε από διεθνή προγράμματα και πρωτοβουλίες (initiatives) με σκοπό η DPWS τεχνολογία να αποτελέσει μελλοντικά μία πλήρη και αξιόπιστη λύση για την ανάπτυξη εφαρμογών βιομηχανικού ελέγχου. Στο κεφαλαίο 3 παραθέτουμε μία ανάλυση της DPWS τεχνολογίας. Ειδικότερα σε αυτό το κεφαλαίο αναλύονται οι αρχές λειτουργίας της DPWS τεχνολογίας και 5

14 παραθέτονται τα ιδιαίτερα χαρακτηριστικά της. Στη συνέχεια αναφέρουμε τα μειονεκτήματα της τεχνολογίας τα οποία εντοπιστήκαν μέσω της βιβλιογραφικής έρευνας. Στο κεφάλαιο 4 παρουσιάζεται η δομή και οι λειτουργίες του συστήματος Festo MPS, το οποίο είναι το βιομηχανικό σύστημα πάνω στο οποίο δοκιμάστηκαν οι εφαρμογές βιομηχανικού ελέγχου που κατασκευάσαμε. Στη συνέχεια την παρουσίαση του πραγματικού συστήματος, ακολουθεί η παρουσίαση της εφαρμογής εξομοίωσης καθώς και μία σύντομη αναφορά στις αποκλίσεις που παρουσιάζει η συγκεκριμένη εφαρμογή από το πραγματικό σύστημα. Στο κεφάλαιο 5 παραθέτουμε μια σειρά από εναλλακτικές σχεδιάσεις οι οποίες θα μπορούσαν να αποτελέσουν βάση για την υλοποίηση του συστήματος επίδειξης. Επίσης σε αυτό το κεφάλαιο προσεγγίζουμε την εφαρμογή υλοποίησης ως ένα τμήμα ενός ευρύτερου συστήματος το οποίο βασίζεται στο μοντέλο SOCRADES και εξηγούμε την θέση της υλοποίησης μας στο ευρύτερο σύστημα. Στο κεφάλαιο 6 παρουσιάζουμε μία σειρά από διαθέσιμα εργαλεία τα οποία μπορούμε να επιλέξουμε για την ανάπτυξη DPWS συστημάτων, ενώ στη συνέχεια παρουσιάζονται οι δομές και οι κλάσεις οι οποίες θα χρησιμοποιηθούν κατά την διαδικασία της υλοποίησης. Η παρουσίαση αυτή αναφέρεται τόσο στις κλάσεις οι οποίες παρέχονται από την εργαλειοθήκη WS4D-JMEDS όσο και οι προσαρμοσμένες (custom) κλάσεις που δημιουργήθηκαν για να καλύψουν τις ανάγκες υλοποίησης. Στο κεφάλαιο 7 παραθέτουμε την ανάλυσης των υλοποιήσεων του συστήματος επίδειξης. Οι υλοποιήσεις αυτές βασίστηκαν στις επιλεγμένες σχεδιάσεις που παρουσιαστήκαν στο κεφάλαιο 5. Κάθε υλοποίηση αναλύεται χρησιμοποιώντας αναφορές στις κλάσεις που παρουσιάστηκαν στο κεφάλαιο 6. Στη συνέχεια για την καλύτερη κατανόηση του τρόπου λειτουργίας της κάθε υλοποίησης παραθέτεται μελέτη περίπτωσης (case study) μετά από κάθε ανάλυσης λειτουργίας. Στο κεφάλαιο 8 παραθέτουμε μία αξιολόγηση της DPWS τεχνολογίας με βάση τα συμπεράσματα που προέκυψαν από την διαδικασία της υλοποίησης. Στη συνέχεια παραθέτουμε μία σειρά από προτάσεις οι οποίες θα μπορούσαν να αποτελέσουν αντικείμενο μελλοντικών ερευνών και εργασιών. Οι προτάσεις αυτές αφορούν τόσο την επέκταση όσο και την περεταίρω ανάλυση τμημάτων του συστήματος που υλοποιήσαμε. 6

15 Κεφάλαιο 1 Υπηρεσιοστρεφής αρχιτεκτονική 1.1. Εισαγωγή Η υπηρεσιοστρεφής αρχιτεκτονική (Service Oriented Architecture) είναι ένα αρχιτεκτονικό στιλ για τη δημιουργία μιας αρχιτεκτονικής σε επίπεδο επιχειρησιακών εφαρμογών η οποία εκμεταλλεύεται τις αρχές της υπηρεσιοστρεφής προσέγγισης για να επιτύχει στενότερη σχέση μεταξύ της επιχείρησης και των πληροφοριακών συστημάτων που την αποτελούν [1].Την υπηρεσιοστρεφή αρχιτεκτονική τη συναντάμε σε μια από τις σημαντικότερες και πιο εμπορικά επιτυχημένες τεχνολογίες των δικτυοκεντρικών συστημάτων, τα Web Services. Τα Web Services είναι αυτόνομες αρθρωτές εφαρμογές οι οποίες μπορούν να περιγραφούν εντοπιστούν και να καλεστούν μέσα στα πλαίσια ενός δικτύου και γενικά του Διαδικτύου[1]. Κάθε Web Service υλοποιεί μια ενέργεια, όπως πχ. η δημιουργία μιας online κράτησης. Τα Web Serviceς όπως αναφέραμε παραπάνω δεν περιλαμβάνουν κλήσεις προς αλλά Web Services. Αντί αυτού για να επικοινωνήσουν χρησιμοποιούν συγκεκριμένα πρωτόκολλα που περιγράφουν τον τρόπο με τον όποιο δέχονται τα μηνύματα, καθώς και τον τρόπο με τον οποίο διαβάζουν τα μηνύματα (parsing) που πρόκειται να δεχτούν ως εισόδους.αυτή η πληροφορία περιγράφει τη συμπεριφορά εισόδου και εξόδου των Web Services και αποθηκεύεται ως Μέτα-δεδομένα με τη χρήση της Web Service Description Language (WSDL). Στόχος της SOA είναι να μεγιστοποιήσει την επαναχρησιμοποίηση (reusability) ώστε οποιαδήποτε εφαρμογή (application) να μπορεί να κατασκευαστεί με την ενορχήστρωση ήδη υπαρχόντων συνιστωσών ( components ), μειώνοντας έτσι κατά πολύ το χρόνο ανάπτυξης μίας εφαρμογής. Η βασική αρχή της υπηρεσιοστρεφής αρχιτεκτονικής είναι ότι οι συνιστώσες της είναι ανεξάρτητες και κάθε μία υλοποιεί μία διαδικασία η οποία πρέπει να είναι σχετικά απλή. Η κάθε συνιστώσα της υπηρεσιοστρεφής αρχιτεκτονικής μπορεί βέβαια να υλοποίει και μια σύνθετη διαδικασία, αυτό όμως μειώνει την επαναχρησιμοποίηση και την ανεξαρτησία του αντικειμένου, γι αυτό πρέπει να αποφεύγεται η δημιουργία τέτοιου είδους συνιστωσών. Μία τέτοια SOA συνιστώσα πρέπει να αντικατασταθεί με περισσότερές οι οποίες υλοποιούν απλούστερες λειτουργίες, έτσι ώστε αν ο προγραμματιστής ορίσει την μεταξύ τους διασύνδεση με τον κατάλληλο τρόπο, δηλαδή κάνοντας ενορχήστρωση, να μπορεί να πετύχει το ίδιο αποτέλεσμα. 7

16 Η διαδικασία της διασύνδεσης των επιμέρους SOA συνιστωσών ώστε να λειτουργούν συντονισμένα για επίτευξη ενός στόχου ονομάζεται ενορχήστρωση (orchestration). Κατά τη διαδικασία της ενορχήστρωσης ο προγραμματιστής συσχετίζει τις SOA συνιστώσες με τις λειτουργίες τις οποίες εκτελούν χρησιμοποιώντας ένα εργαλείο λογισμικού τύπου Client, το οποίο του παρέχει πρόσβαση σε όλες τις διαθέσιμες υπηρεσίες και τα χαρακτηριστικά τους Προσέγγιση της αρχιτεκτονικής με βάση τα Web Services Ένας σχεδιαστής μπορεί υλοποιήσει τη SOA αρχιτεκτονική χρησιμοποιώντας μια από τις διαθέσιμες τεχνολογίες SOAP, RPC, REST, DCOM, CORBA, Web Services, DDS και WCF. Εμείς θα αναλύσουμε περεταίρω την τεχνολογία των Web Services Δομικά στοιχεία των Web Services Τα δομικά στοιχεία της τεχνολογίας των Web Services είναι: A. Service Provider- Service Client/Consumer B. Service Broker C. Μέτα-δεδομένα D. Γλώσσα περιγραφής υπηρεσιών παγκόσμιου ιστού (WSDL) E. Πρωτόκολλο πρόσβασης απλών αντικειμένων ( SOAP) A. Service Provider- Service Client/Consumer Όπως είπαμε παραπάνω τα Web Services αποτελούν μία τεχνολογία υλοποίησης της υπηρεσιοστρεφής αρχιτεκτονικής. Ένα Web Service είναι ένα σύστημα λογισμικού σχεδιασμένο να υποστηρίζει τη διαλειτουργικη (interoperable), από μηχανή σε μηχανή, αλληλεπίδραση πάνω σε ένα δίκτυο. Κάθε Web Service έχει μία διεπαφή η οποία περιγράφεται σε μία μορφή την οποία μπορεί να επεξεργαστεί η μηχανή. Η μορφή αυτή για την αναπαράσταση της χρησιμοποιεί τη γλώσσα WSDL [2]. Τα άλλα συστήματα αλληλεπιδρούν με το Web Service με ένα τρόπο ο οποίος υπαγορεύεται από την περιγραφή του με τη χρήση SOAP μηνυμάτων. Αυτά τα μηνύματα συνήθως μεταφέρονται με τη χρήση του HTTP, με μία XML σειριακοποίηση (serialization) σε συνδυασμό με άλλα συσχετιζόμενα με το διαδίκτυο πρότυπα [3]. Τα υπηρεσιοστρεφή συστήματα δομούνται από αντικείμενα τα οποία παίζουν έναν από τους δύο παρακάτω ρόλους, είναι είτε Service Providers είτε Service Consumers/Clients. Ο Service Provider είναι υπεύθυνος για την δημιουργία του Web Service και την δημοσίευση του σε έναν κατάλογο (registry). Ο κατάλογος αυτός 8

17 βρίσκεται σε έναν service broker μέσω του οποίου οι Clients μπορούν να αναζητήσουν το Service. Ο Service Client/Consumer αναζητά το Service στο κατάλογο του Service Broker χρησιμοποιώντας μία διαδικασία αναζήτησης. Σε αυτό το σημείο πρέπει να σημειώσουμε ότι υπάρχουν πολλοί τρόποι για να αναζητήσει ο Service Client ένα Web Service. Αφού ολοκληρωθεί η διαδικασία της αναζήτησης ο Client χρησιμοποιεί την πληροφορία που πήρε από τον κατάλογο για να συνδεθεί (binding ) με το Web Service. B. Service Broker Αναφέρθηκε παραπάνω ότι κάθε Service Provider δημοσιεύει τις υπηρεσίες που προσφέρει σε μία registry ώστε να είναι ορατό κατά την αναζήτηση από τους πελάτες. Η Registry αυτή μπορεί να βρίσκεται σε έναν Service Broker που λειτουργεί στα πλαίσια του τοπικού δικτύου η του Διαδικτύου. Αξίζει να σημειωθεί η UDDI (Universal Description Discovery and Integration) η οποία είναι μια Platform independent, XML-based registry η οποία επιτρέπει σε επιχειρήσεις από όλο τον κόσμο να διαφημίσουν τα Service τα οποία προσφέρουν, ενώ τους δίνει και την δυνατότητα να αναζητήσουν Web Services άλλων εταιριών με βάση μια σειρά από κριτήρια που μπορούν να θέσουν κατά τη διαδικασία της αναζήτησης.tέλος η UDDI προσφέρει υπηρεσίες για το Licensing και τον καθορισμό κόστους για την χρήση ενός Service. Σχήμα 1.1 Web Service Component Roles 9

18 C. Μετα-δεδομένα Αν και δεν υπάρχει αυστηρός ορισμός για το τι είναι Μετα-δεδομένα (metadata) ο ορισμός ο οποίος χρησιμοποιούμε συνήθως είναι ότι τα Μέτα-Δεδομένα είναι δεδομένα τα οποία περιέχουν πληροφορία για δεδομένα [5]. Ένα από τα βασικότερα πλεονεκτήματα όπως αναφέραμε παραπάνω είναι ότι τα Web Services δεν περιορίζονται από τα όρια μία συγκεκριμένης πλατφόρμας ή γλώσσας προγραμματισμού [3]. Ο τρόπος που πετυχαίνουν αυτή την ανεξαρτησία είναι ο εξής: Αρχικά, η διεπαφή η οποία προφέρει το Web Service καταγράφεται με μία περιγραφική γλώσσα (πχ XML,WSDL) και στη συνέχεια δίνεται στο αρχείο το οποίο περιέχει αυτή τη περιγραφή, μία διεύθυνση. Η διεύθυνση αυτή αποτελεί το endpoint του Web Service. Οποιοσδήποτε Client θέλει να συνδεθεί με το WS αρκεί να διαβάσει το WSDL που βρίσκεται στο επιλεγμένο endpoint. Διαβάζοντας ο Client παίρνει την πληροφορία για το πια Operations είναι διαθέσιμα και τι είδους δομές δεδομένων δέχονται ως εισόδους. Αρά από τα παραπάνω βλέπουμε ότι ένα WS δεν οφείλει να έχει κάποια συγκεκριμένη δομή ή συμπεριφορά για να επικοινωνήσει με κάποιον Client, αφού ο Client μπορεί να ανακαλύψει το πρωτόκολλο εισόδουεξόδου διαβάζοντας το WSDL κατά τη διαδικασία της αναζήτησης. Η συμπεριφορά των Services στηρίζεται τόσο στα Μετα-δεδομένα τα οποία περιγράφουν την συμπεριφορά εισόδου και εξόδου του όπως αναφέραμε παραπάνω, όσο και στο πρωτόκολλο το οποίο ορίζει τους κανόνες επικοινωνίας. Το πρωτόκολλο αυτό ονομάζετε SOAP ( Simple Object Access Protocol) και βασίζεται στην ανταλλαγή μηνυμάτων Μετα-δεδομένων. Αν και τα WSDL και SOAP αυτή τη στιγμή χρησιμοποιούνται ως πρότυπα δεν είναι σίγουρο ότι αυτό δεν θα αλλάξει στο μέλλον. Ανεξάρτητα με το αν αντικατασταθούν, τα Μετα-δεδομένα στην SOA πρέπει να πληρούν τις εξής προϋποθέσεις: Τα Μετα-δεδομένα πρέπει να είναι σε μία μορφή η οποία επιτρέπει στα συστήματα λογισμικού να τα «ανακαλύπτουν» δυναμικά και να μπορούν να τα ενσωματώσουν καθώς και να τα αξιοποιήσουν για να αποκτήσουν πρόσβαση καθώς και να χρησιμοποιήσουν ένα Web Service. Τα Μετα-δεδομένα πρέπει να είναι σε μορφή την οποία μπορεί να κατανοήσει ο σχεδιαστής του συστήματος (δηλαδή πρέπει να είναι αναγνώσιμα και κατανοητά από τον άνθρωπο). D. Γλώσσα περιγραφής υπηρεσιών παγκόσμιου ιστού (WSDL) Η WSDL είναι μια μορφή XML που χρησιμοποιείται για την περιγραφή Web Services σαν ένα σύνολο από endpoints, τα οποία διαχειρίζονται μηνύματα που περιέχουν είτε document oriented είτε procedure oriented πληροφορίες. Τα Operations, τα οπoία αποτελούν τις μεθόδους του Service, και τα μηνύματα περιγράφονται αφηρημένα (abstract) και στη συνέχεια δεσμεύονται (binding) σε ένα συγκεκριμένο 10

19 πρωτόκολλο δικτύου και σε μία συγκεκριμένη δομή μηνύματος για να καθορίσουν ένα endpoint. Tα endpoints τα οποία είναι συσχετιζόμενα μεταξύ τους συνδυάζονται σε ένα πιο γενικό endpoint το όποιο αποτελεί και το endpoint του Service στο οποίο ανήκουν. Σχήμα 1.2 Δομή του WSDL E. Πρωτόκολλο πρόσβασης απλών αντικειμένων ( SOAP) Το SOAP είναι ένα βασισμένο σε XML πρωτόκολλο, το οποίο επιτρέπει σε εφαρμογές να ανταλλάσουν δομημένα μηνύματα πάνω από το HTTP πρωτόκολλο. Ο λόγος για τον οποίο το χρησιμοποιούμε πάνω από το HTTP είναι επειδή η αρχιτεκτονική βασίζεται σε RPC (Remote Procedure Calls-απομακρυσμένες κλήσεις) και αυτό αποτελεί πρόβλημα από πλευράς τόσο συμβατότητας, όσο και από πλευράς ασφάλειας. Τα Firewall και οι proxy Servers υπό κανονικές συνθήκες (αν δεν έχουν γίνει ειδικές ρυθμίσεις ) εμποδίζουν τέτοιου είδους κλήσεις. Η βασική δομή που χρησιμοποιούμε στην επικοινωνία με το SOAP πρωτόκολλο είναι ο SOAP φάκελος. Αυτός ο φάκελος περιέχει όλες τις πληροφορίες οι οποίες χρειάζονται για 11

20 την επικοινωνία μεταξύ Web Services και μεταφέρεται μέσω HTTP requests και HTTP responses. Σχήμα 1.3 Δομή του SOAP Envelope [4] Αξίζει να σημειωθεί ότι η WSDL είναι επεκτάσιμη ώστε να επιτρέπει τη περιγραφή των παραμέτρων και των μηνυμάτων τους, ανεξάρτητα από τις μορφές των μηνυμάτων ή των πρωτόκολλων δικτύου που χρησιμοποιούνται για την επικοινωνία. Παρόλα αυτά, εμείς στην υλοποίηση μας θα χρησιμοποιήσουμε το WSDL μόνο σε συνδυασμό με το πρωτόκολλο SOAP οπότε όταν θα αναφερόμαστε σε WSDL θα έχουν πάντα την δομή η οποία είναι συσχετιζόμενη με το SOAP.O ρόλος των SOAP και WSDL στην διαδικασία λειτουργίας των Web Services φαίνεται το σχήμα Προδιαγραφές των Web Services Η συμπεριφορά καθώς και τρόπος υλοποίησης των Web Services καθορίζονται από ένα σύνολο προδιαγραφών (Specifications). Αυτές οι προδιαγραφές έχουν προταθεί από διάφορους οργανισμούς όπως η IBM,OASIS,W3C και αλληλοσυμπληρώνουν, επαναλαμβάνουν η μπορεί ακόμα και να ανταγωνίζονται ο ένας τον άλλο [3]. Παρακάτω παραθέτουμε μία λίστα με τις προδιαγραφές τις οποίες συμμορφώνεται υλοποίηση των Web Services που θα χρησιμοποιήσουμε στο δικό μας σύστημα. 12

21 Σχήμα 1.3 Web Services Architecture WS-Addressing: Περιγράφει ανεξάρτητους από τη μέθοδο μεταφοράς μηχανισμούς μέσω των οποίων να μπορούμε να αναφερόμαστε σε Web Services ή μηνύματα. WS-Discovery : Περιγράφει το πρωτόκολλο το οποίο χρησιμοποιείται για να εντοπιστεί ένα Web Service. WS-Eventing : Περιγράφει το πρωτόκολλο που επιτρέπει στα Web Services να δέχονται εγγραφές (subscriptions) για γεγονότα (events) και να στέλνουν ειδοποιήσεις WS-Transfer: Περιγράφει ένα γενικό SOAP-based πρωτόκολλο το οποίο παρέχει πρόσβαση στην XML αναπαράσταση των Web Service-based πόρων. WS-Security: Περιγράφει πως μπορεί να επιτευχθεί η ακεραιότητα και η ασφάλεια κατά την ανταλλαγή μηνυμάτων. WS-MetadaExchange: Χρησιμοποιείται σε συνεργασία με τις WS- Addressing και WS-Policy προδιαγραφές καθώς και με την WSDL για τη ανάκτηση μέτα-δεδομένων για ένα Web Service endpoint. WS-Policy: Επιτρέπει στα Web Service να χρησιμοποιούν XML για να διαφημίσουν τις πολιτικές τους και επίσης επιτρέπει σε καταναλωτές των Web Services να προσδιορίζουν τις απαιτήσεις τους όσον αφορά την πολιτική των Web Services που ζητούν. 13

22 Οφέλη της προσέγγισης των Web Services Οι κανόνες που αναφέρθηκαν στο κεφάλαιο εξασφαλίζουν ότι τα Web Services θα έχουν μία ενιαία συμπεριφορά ανεξάρτητα με τις ιδιαιτερότητες της κάθε εφαρμογής. Αυτή η ενιαία συμπεριφορά εξασφαλίζει ότι τα οφέλη της τεχνολογίας εξακολουθούν να ισχύουν ανεξάρτητα της πλατφόρμας υλοποίησης. Τα οφέλη αυτά είναι: Service loose coupling-τα Services διατηρούν μία σχέση η οποία ελαχιστοποιεί τις μεταξύ τους εξαρτήσεις και διατηρούν μόνο ελάχιστα στοιχεία ώστε να μπορούν να προσδιορίζουν την ύπαρξη των άλλων Web Services. Service abstraction Τα Services προσφέρουν λειτουργίες αποκρύπτοντας τις εσωτερικές διεργασίες από το περιβάλλον, οδηγώντας σε υψηλότερου επιπέδου λύσεις. Service reusability- Η δομή των Services είναι τέτοια ώστε με την κατάλληλη ενορχήστρωση να μπορούν να χρησιμοποιηθούν για να καλύψουν διαφορετικές ανάγκες. Service autonomy Τα Services είναι εντελώς αυτόνομες οντότητες (δεν κάνουν κλήσεις σε άλλα Web Services) Service statelessness - Τα Services δεν δαπανούν πόρους για την αποθήκευση καταστάσεων αφού η κάθε κλήση είναι εντελώς ανεξάρτητη. Δηλαδή σε κάθε νέα κλήση το Service ανταποκρίνεται σαν να δημιουργήθηκε εκείνη την στιγμή δεν αποθηκεύει κάπου την προηγουμένη κατάσταση του. Service discoverability- Τα Services παρέχουν μετα-δεδομένα, ώστε να είναι δυνατόν να ανακαλυφθούν και να αποκτήσουν πρόσβαση οι Clients. Service Composability Τα Services είναι κατασκευασμένα με τέτοιο τρόπο ώστε να αποτελούν εύχρηστές συνιστώσες, και να μπορούν να χρησιμοποιηθούν αυτούσια και χωρίς αλλαγές για να εξυπηρετήσουν διαφορετικές εφαρμογές. Standarized service Contract Οι συμβολισμοί και το συντακτικό που ορίζουν την δομή των μηνυμάτων και την δομή της συμπεριφοράς εισόδου και εξόδου του Service, δηλαδή το WSDL, είναι αυστηρά καθορισμένοι ώστε να μην υπάρχει ασυμβατότητα μεταξύ Client και Service. Αν δεν ήταν αυστηρά καθορισμένα ο Client θα μπορούσε να λάβει από το Service μήνυμα με διαφορετικό συντακτικό από αντί αυτού που περιμένει, με αποτέλεσμα να εμφανιστούν σφάλματα κατά τη διαδικασία ανάλυσης( parsing). 14

23 Κεφάλαιο 2 Υπηρεσιοστρεφής αρχιτεκτονική στην περιοχή του Βιομηχανικού αυτοματισμού 2.1. Εισαγωγή Μία βιομηχανική μονάδα η οποία εγκαθιστά ένα σύστημα αυτόματου ελέγχου για την γραμμής παραγωγής έχει πολύ περιορισμένες επιλογές όσον αφορά την τεχνολογία που θα επιλέξει. Τα δίκτυα βιομηχανικού αυτοματισμού αποτελούν την μοναδική πλήρη λύση για τέτοιου είδους διαδικασίες και ο επιχειρηματίας είναι υποχρεωμένος να επιλέξει ανάμεσα από προϊόντα διαφορετικών κατασκευαστών που ακολουθούν όμως, την ίδια αρχιτεκτονική λειτουργίας. Τα βιομηχανικά δίκτυα αυτοματισμών αν και ανταποκρίνονται ικανοποιητικά στις περισσότερες περιπτώσεις, έχουν κάποιους περιορισμούς που οφείλονται στον τρόπο κατασκευής και λειτουργίας τους. Αυτοί οι περιορισμοί σε συνδυασμό με την πρόοδο της τεχνολογίας και την αύξηση του ανταγωνισμού είχαν ως αποτέλεσμα να αναζητηθούν νέες λύσεις. Οι νέες αυτές λύσεις θα είχαν ως στόχο το συντονισμό των διαδικασιών παραγωγής και την επέκταση των δυνατοτήτων που έχουν τα κλασικά βιομηχανικά δίκτυα μεγιστοποιώντας το όφελος της επιχείρησης. Προς την κατεύθυνση της δημιουργίας μιας νέας τεχνολογίας η οποία θα ανταποκρινόταν στις νέες ανάγκες των βιομηχανικών μονάδων κινήθηκε το έργο SIRENA. Το έργο SIRENA πρότεινε ως απάντηση στις νέες ανάγκες την DPWS τεχνολογία και παρουσίασε τις πρώτες υλοποιήσεις με βάση αυτή. Στη συνέχεια η DPWS τεχνολογία αποτέλεσε αντικείμενο έρευνας των προγραμμάτων SODA,SOCRADES και AESOP καθώς και των WS4D και SOA4D πρωτοβουλιών, οι οποίες επέκτειναν τις δυνατότητες αυτής της τεχνολογίας είτε μέσω της δημιουργίας εργαλείων υλοποίησης, είτε διευρύνοντας τις δυνατότητες της τεχνολογίας με σκοπό να αποτελέσει μια πλήρης λύση για την δημιουργία συστημάτων βιομηχανικού ελέγχου Περιορισμοί των συμβατικών μεθόδων Οι σύγχρονες βιομηχανίες έχοντας ως κίνητρο τον ανταγωνισμό αναζητούν τεχνολογίες στα συστήματα παραγωγής οι οποίες θα τους επιτρέψουν να έχουν τον πλεονέκτημα έναντι των ανταγωνιστών τους. Για να δημιουργήσει μια εταιρία στο βιομηχανικό χώρο ένα στρατηγικό σχέδιο το οποίο θα οδηγήσει στη ανάπτυξη, καταγράφει του παράγοντες που επιφέρουν κέρδος καθώς και αυτούς που προκαλούν ζημίες και στη συνέχεια δημιουργεί 15

24 στρατηγικές για την μέγιστη αξιοποίηση των πρώτων και ελαχιστοποίηση των δεύτερων. Ένας από τους παράγοντες ο οποίος δρα ζημιογόνα για τις επιχειρήσεις είναι το κόστος αναβάθμισης και επέκτασης. Το κόστος αυτό είναι το άθροισμα τριών παραγόντων : 1) Το κόστος αγοράς του υλικού, π.χ. αγορά των νέων μηχανημάτων. 2) Το χρονικό κόστος, π.χ. για ποσό καιρό θα πρέπει να μείνουν εκτός λειτουργίας τμήματα της γραμμής παραγωγής μέχρι να ολοκληρωθεί η αναβάθμιση. 3) Το κόστος αντικατάστασης ή επέκτασης από τυχόν ασυμβατότητες, π.χ. στις παραδοσιακές μεθόδους έλεγχου-δίκτυα Βιομηχανικών αυτοματισμών- που είναι στενά συνδεδεμένες με μία πλατφόρμα, παρουσιάζονται περιπτώσεις κατά τις οποίες κάποια δίκτυα ή συσκευές δεν μπορούν να συνδεθούν μεταξύ τους ή χρειάζονται ειδικά gateways τα οποία αυξάνουν το κόστος και εισάγουν καθυστερήσεις στην μεταφορά δεδομένων. Ως παράδειγμα αναφέρουμε ότι μία συσκευή του CAN Δικτύου, η οποία για να συνδεθεί με το Profibus χρησιμοποιώντας πύλη (gateway) τελευταίας τεχνολογίας, εισάγει καθυστέρηση έως 5ms ). Ένα επιπλέον πρόβλημα που προκύπτει από την ασυμβατότητα είναι ότι περιορίζονται οι επιλογές μιας βιομηχανίας αφού αυτή είναι υποχρεωμένη να επιλέγει μεταξύ συγκεκριμένων κατασκευαστών. Σήμερα περίπου το 1/3 του συνολικού κόστους ενός σταθμού παραγωγής σε όλη τη διάρκεια ζωής του, δαπανάται σε νέες εγκαταστάσεις μηχανημάτων και στη συντήρηση τους. Ένα σημαντικό μέρος αυτού του κόστους οφείλεται στην έλλειψη ευελιξίας των συμβατικών δικτύων βιομηχανικού ελέγχου. Αυτό έχει ως αποτέλεσμα, περίπου το 80% του χρόνου των μηχανικών που συντηρούν μία εγκατάσταση να σπαταλιέται για να δημιουργούνται ξανά μηχανισμοί έλεγχου οι όποιοι ήδη υπήρχαν σε προηγούμενες εγκαταστάσεις αλλά δεν είναι συμβατοί με τις νέες [18]. Αυτό το κόστος θα μπορούσε να αποφευχθεί αν εφαρμοζόταν μία προσέγγιση βασισμένη σε συνιστώσες, η οποία δεν θα ήταν άμεσα εξαρτημένη από συγκεκριμένη πλατφόρμα. Συμφώνα με μελέτη η οποία έγινε σε συνεργασία με τη Ford Motors το 80% των μηχανημάτων και των μηχανισμών έλεγχου που συμμετέχουν στην κατασκευή των powetrain κομματιών ενός οχήματος λειτουργούν με βάση τα ίδια μηχανικά μέρη [17]. Από τα παραπάνω προκύπτει ότι στόχος είναι μια σχεδίαση η οποία θα λύσει τα προβλήματα συμβατότητας μεταξύ συσκευών, θα προσφέρει εύκολη επέκταση της υπάρχουσας γραμμής παραγωγής καθώς και δυνατότητα ενοποίησης των επιμέρους συστημάτων παραγωγής. 16

25 2.3. Γιατί κινούμαστε προς την SOA αρχιτεκτονική Η υιοθέτηση της SOA αρχιτεκτονικής στων τομέα των βιομηχανικών συστημάτων ευνοήθηκε από μία σειρά από γεγονότα: A. Η ανάπτυξη της τεχνολογίας και πιο συγκεκριμένα η ανάπτυξη της τεχνολογίας στην ολοκλήρωση κυκλωμάτων έχει ως αποτέλεσμα σήμερα να διαθέτονται σε χαμηλό κόστος συσκευές οι οποίες προσφέρουν υψηλές επιδώσεις και έχουν σχετικά χαμηλή κατανάλωση ενέργειας. Η εξέλιξη αυτή έφερε πολλές αλλαγές στα συστήματα βιομηχανικού έλεγχου. Έδωσε την δυνατότητα στους μηχανικούς να αναζητήσουν λύσεις πέρα από τις παραδοσιακές μεθόδους. Οι απαιτήσεις σχεδίασης συστήματος βιομηχανικών αυτοματισμών παλαιότερα, λόγω των περιορισμένων ταχυτήτων μετάδοσης δεδομένων και της περιορισμένης υπολογιστικής ισχύς, ήταν ταχύτητα και η αξιοπιστία. Η πρόοδος της τεχνολογίας όμως, καθώς και αυξανόμενες απαιτήσεις της αγοράς είχαν ως αποτέλεσμα να δημιουργηθούν νέες απαιτήσεις στον τομέα του βιομηχανικού ελέγχου όπως η δυνατότητα εύκολης προσαρμογής (scalability), η δυνατότητα επαναχρησιμοποίησης (reusability), η ευελιξία καθώς και η ευκολία στη χρήση. B. Λόγω της ραγδαίας ανάπτυξης του διαδικτύου και του χαμηλού κόστους της Ethernet τεχνολογίας υπάρχουν ήδη πολλές εγκαταστάσεις, μεγάλη υποδομή και πληθώρα εργαλείων που μπορούν να χρησιμοποιηθούν από εφαρμογές και συστήματα τα οποία χρησιμοποιούν πρωτόκολλα και αρχιτεκτονικές που βασίζονται στο διαδίκτυο. Αυτό έχει ως αποτέλεσμα, οι τεχνολογίες οι οποίες χρησιμοποιούν αυτή την υποδομή να εξοικονομούν πόρους τόσο στον τομέα της έρευνας όσο και στον τομέα της δημιουργίας νέων υποδομών. Αυτό επιτυγχάνεται χρησιμοποιώντας ήδη έτοιμες επικοινωνιακές λύσεις και ενσωματώνοντας τις σε νέες υλοποιήσεις. C. Μεγάλο μέρος των εφαρμογών οι οποίες απευθύνονται σε διαχείριση επιχειρησιακών πόρων χρησιμοποιούν ήδη υπηρεσιοστρεφείς αρχιτεκτονικές. Όμως λόγω των διαφορών που παρουσιάζονται στην δομή των παραδοσιακών δικτύων βιομηχανικού αυτοματισμού υπάρχει αδυναμία μιας πραγματικά διαστρωματικής (cross-layer) δομής μέχρι τα κατώτερα επίπεδα. Παρατηρώντας τις απαιτήσεις στον τομέα των βιομηχανικών αυτοματισμών και λαμβάνοντας υπόψη τις υπάρχουσες υποδομές μπορούμε να συμπεράνουμε ότι η υιοθέτηση της υπηρεσιοστρεφούς αρχιτεκτονικής αποτελεί λογικό επακόλουθο. Η αρχιτεκτονική αυτή άρχισε να υιοθετείται και να εφαρμόζεται σταδιακά σε ερευνητικά έργα με χαρακτηριστικά τα SIRENA,SOCRADES,SODA και σχετικά πρόσφατα ξεκίνησε το έργο AESOP. Προβλέπεται δε να αποτελέσει σημείο 17

26 αναφοράς στο μέλλον αφού σύμφωνα με στοιχεία του AESOP ο αριθμός των ενσωματωμένων συσκευών αναμένεται να φτάσει τα 500 δισεκατομμύρια μέχρι το Το έργο SIRENA Οι πρώτες κινήσεις για την εύρεση μιας από κοινού αποδεκτής και λειτουργικής λύσης για τη εισαγωγή της υπηρεσιοστρεφούς αρχιτεκτονικής στις διαδικασίες βιομηχανικού έλεγχου έγιναν το 2003 στο έργο SIRENA(Service Infrastructure for Real-time Embedded Networked Devices) [9]. Στο έργο αυτό σε πρώτο στάδιο οριστήκαν οι βασικές προδιαγραφές με βάση τις οποίες θα επιλεγόταν η τεχνολογία η οποία θα αποτελούσε τη βάση του έργου. Η επιλογή έγινε μέσα από έναν αριθμό από υποψήφιες τεχνολογίες οι οποίες είχαν δοκιμαστεί στο παρελθόν σε διαφορετικού τύπου υλοποιήσεις. Οι τεχνολογίες αυτές αναφέρονται και στο σχήμα 2.1 οπού μπορούμε να δούμε τις προδιαγραφές που πληροί η κάθε μία από αυτές. Οι τεχνολογίες υποψήφιες να αποτελέσουν βάση για το πρόγραμμα SIRENA είναι: Audio/Video Interoperability (HAVi) Open Services Gateway initiative framework (OSGi) Java Intelligent Network Infrastructure (JINI) Universal Plug and Play (UPnP) Web Services Devices Profile for Web Services(DPWS). Σχήμα 2.1 Χαρακτηριστικά που διαθέτουν οι τεχνολογίες οι οποίες ήταν υποψήφιες να αποτελέσουν βάση του SIRENA PROJECT [9] Μετά από μία σύγκριση των τεχνολογιών αποφασίστηκε ότι η καταλληλότερη τεχνολογία για να αποτελέσει την βάση του έργου SIRENA είναι η DPWS. Αυτή η απόφαση είχε ως αποτέλεσμα τη δημιουργία του SIRENA FRAMEWORK του οποίου 18

27 η δομή παραθέτεται στο σχήμα 2.2. Το SIRENA BASIC FRAMEWORK καθορίζει τη βασική υπηρεσιοστρεφή τεχνολογία η οποία χρησιμοποιείται για επικοινωνία και λειτουργία των συσκευών που είναι συμβατές με το framework. Σχήμα 2.2 SIRENA Framework [9] Η DPWS τεχνολογία επιλέχτηκε επειδή πληρούσε τις προδιαγραφές του έργου SIRENA και επειδή βασιζόταν στην ήδη επιτυχημένη και ευρέως διαδεδομένη τεχνολογία των Web Services οπότε αναμενόταν να αντιμετωπιστεί θετικά από την αγορά. Τα Web Services όπως έχουμε αναφέρει είναι ανεξάρτητα πλατφόρμας. Ουσιαστικά αποτελούν ένα σύνολο από κανόνες αναπαράστασης δεδομένων και πρωτόκολλα επικοινωνίας τα οποία μπορούν να συνδυάζονται μεταξύ τους ώστε να δημιουργήσουν νέους κανόνες και πρωτόκολλα τα οποία καθορίζουν την συμπεριφορά των αντικειμένων που συμμετέχουν στη επικοινωνία. Το DPWS αποτελεί και αυτό ένα σύνολο από πρωτόκολλα τα οποία φαίνονται στο σχήμα 2.3. Σχήμα 2.3 DPWS Framework 19

28 Σε αυτό το σημείο πρέπει να σημειώσουμε ότι οι προδιαγραφές λειτουργίας του DPWS βασίζονται και εμπλουτίζουν κάποιες από τις προδιαγραφές λειτουργίας των Web Services που έχουμε αναφέρει στο κεφάλαιο 1. Ονομαστικά αυτές οι προδιαγραφές είναι οι εξής:ws-addressing, WS-Discovery, WS-Metadata Exchange και WS-Eventing SIRENA Devices Profile for Web Services εργαλειοθήκη Η SIRENA-DPWS εργαλειοθήκη (toolkit) είναι η πρώτη DPWS εργαλειοθήκη και αναπτύχθηκε από την εταιρία Schneider Electric στα πλαίσια του έργου SIRENA έχοντας ως βάση την γλώσσα προγραμματισμού C. Για την δημιουργία της εργαλειοθήκης χρησιμοποιήθηκε το πακέτο (package ) ανοιχτού κώδικα gsoap και η υλοποίηση της επικοινωνίας έγινε μέσω του SOAP πρωτοκόλλου. Αξίζει επίσης να αναφερθεί ότι η συγκεκριμένη εργαλειοθήκη προσφέρει εργαλεία για την αυτόματη δημιουργία κώδικα και την σύνδεση(binding) των δομών της C/C++ με XML- SOAP μηνύματα και το αντίστροφο. Αυτό σημαίνει ότι η διεπαφή του DPWS πελάτη καθώς και του εξυπηρετητή δημιουργούνται αυτόματα, άρα χρειάζεται να κατασκευαστεί μόνο η υλοποίηση πελάτη και του εξυπηρετητή που αντιστοιχεί στην κάθε εφαρμογή. Σχήμα 2.4. Οι συνιστώσες της διαδικασίας ανάπτυξης μίας εφαρμογής με βάση την DPWS τεχνολογία [9]. Αξίζει επίσης να σημειωθεί η πρόταση του SIRENA extensions network το οποίο παρέχει λύσεις για την διασύνδεση μέσω πυλών (gateways) του SIRENA Network με άλλα δίκτυα «έξυπνων» συσκευών που ακολουθούν SOA αρχιτεκτονικές. 20

29 2.5. Πρωτοβουλίες που δημιουργήθηκαν από το έργο SIRENA Το πρόγραμμα SIRENA, έθεσε τις προδιαγραφές της DPWS τεχνολογίας και παρήγαγε τις πρώτες υλοποιήσεις και τα πρώτα εργαλεία για την ανάπτυξη βασισμένων στο DPWS εφαρμογών. Μετά την ολοκλήρωση του, δημιουργήθηκαν κάποιες πρωτοβουλίες (initiatives) οι οποίες είχαν ως στόχο την προώθηση και ανάπτυξη των αποτελεσμάτων του προγράμματος SIRENA. Οι δυο σημαντικότερες πρωτοβουλίες, οι οποίες αποτελούνται τόσο από εταιρίες όσο και από πανεπιστήμια τα οποία συμμετείχαν στο πρόγραμμα SIRENA, είναι η Service Oriented Architecture For Devices (SOA4D) και η Web Services For Devices (WS4D). Κάθε μία από τις δύο πρωτοβουλίες πρότεινε και κατασκεύασε τις δικές της υλοποιήσεις του DPWS οι οποίες όμως βασίζονται στα αποτελέσματα του έργου SIRENA και είναι απόλυτα συμβατές μεταξύ τους. Tέλος, πρέπει να σημειώσουμε ότι οι υλοποιήσεις που προσφέρει η SOA4D βασίζονται στις γλώσσες προγραμματισμού C (DPWS Core) και Java (DPWS4J core) και δεν θα αναλυθούν στα πλαίσια αυτής της εργασίας Web Services For Devices Initiative Η WS4D πρωτοβουλία δημιουργήθηκε το 2006 από ετέρους, τόσο από τον ακαδημαϊκό όσο και από τον βιομηχανικό χώρο, οι οποίοι συμμετείχαν στο πρόγραμμα SIRENA. Η WS4D πρωτοβουλία μπορεί να θεωρηθεί ως ένα επακόλουθο πρόγραμμα το οποίο έχει ως σκοπό να επεκτείνει τα αποτελέσματα του SIRENA και να διατηρήσει τη συνεργασία μεταξύ των εταίρων. Η πρωτοβουλία αυτή είναι υπεύθυνη για τον σχεδιασμό και την υλοποίηση εργαλείων και βιβλιοθηκών οι οποίες χρησιμοποιούνται για την ανάπτυξη DPWS εφαρμογών και της οποίες θα χρησιμοποιήσουμε και στην υλοποίηση του δικού μας συστήματος. Μία σύντομη ανάλυση των εργαλείων ανάπτυξης και των βιβλιοθηκών που προσφέρει η συγκεκριμένη πρωτοβουλία δίνεται στο κεφάλαιο Το έργο SOCRADES Το έργο SOCRADES- Service-Oriented Cross-layer infrastructure for Distributed smart Embedded devices ξεκίνησε 2006 με 16 συνεργάτες από 6 χώρες της ευρωπαϊκής ένωσης τόσο από τον χώρο της βιομηχανίας όσο και από τον ακαδημαϊκό χώρο [7]. Το SOCRADES υιοθέτει το παράδειγμα το συνεργαζόμενου αυτοματισμού (collaborative automation paradigm [19]) όπου ο σκοπός είναι να αναπτυχτούν εργαλεία και μέθοδοι που μπορούν να επιτύχουν ευέλικτο, 21

30 επαναπρογραμματιζόμενο (reconfigurable), scalable, διαλειτουργικό (interoperable), συμβατό με το δίκτυο (network-enabled) συντονισμό μεταξύ αποκεντρωμένων (decentralized) και κατανεμημένων συστημάτων [7] Οι στόχοι του έργου SOCRADES Το SOCRADES επιδιώκει να δημιουργήσει ένα υπηρεσιοστρεφές οικοσύστημα, που αποτελείται από «έξυπνες συσκευές», οι οποίες αλληλεπιδρούν τόσο σε φυσικό επίπεδο όσο και σε επίπεδο οργάνωσης. Ο διαχωρισμός της λογικής έλεγχου σε επίπεδο συσκευών όπου κάθε συσκευή έχει τις κατάλληλες δομές για τον έλεγχο της και την επικοινωνία της με άλλες, ευνοεί τη προσαρμοστικότητα και μειώνει την ανάγκη ύπαρξης διαδικασίας επαναπρογραμματισμού των ρυθμίσεων αρχικοποίησης (reconfigurability ). Αυτό συμβαίνει επειδή ο χρονοβόρος ολικός επαναπρογραμματισμός των μεγάλων, μη component-based συστημάτων, αντικαθίσταται με την ρύθμιση των νέων συνιστωσών, ώστε να ανταποκρίνονται στις απαιτήσεις λειτουργίας του συστήματος. Επιγραμματικά οι στόχοι του project είναι: 1. Η ανάπτυξη μιας υπηρεσιοστρεφούς δομής η οποία θα βασίζεται στο DPWS και η οποία θα προσφέρει πρόσβαση και έλεγχο των δυνατοτήτων μίας συσκευής(work functions) προσφέροντας τις λειτουργίες της ως Web Services. 2. Ο καθορισμός των προδιαγραφών των frameworks που χρησιμοποιούνται τόσο στην διαχείριση όσο και στην ενορχήστρωση των Services που προσφέρονται. 3. Ο καθορισμός μίας μεθοδολογίας για την περιγραφή των Services με σημασιολογικές σημάνσεις (semantic mark-up) οι οποίες μπορούν να ερμηνευτούν και να επεξεργαστούν από πράκτορες (agents) ώστε να μπορούν να ανακαλυφθούν, να επιλέγουν και να αποτελέσουν πόρους (resources) ενός ευρύτερου συστήματος. Η μεθοδολογία με την οποία το SOCRADES προσεγγίζει αυτούς τους στόχους φαίνεται στο σχήμα 2.5. Παρατηρώντας το σχήμα 2.5 συμπεραίνουμε ότι το SOCRADES ακολουθεί δυο συμπληρωματικές τεχνολογικές προσεγγίσεις. Η πρώτη επικεντρώνει στη λειτουργία των συσκευών στο χαμηλότερο επίπεδο των ενσωματωμένων συσκευών (sensors,actuators). Σε αυτό το επίπεδο ο στόχος του σχεδιασμού είναι οι συσκευές να συμπεριφέρονται με έναν ευέλικτο τρόπο. Οι παράγοντες οι οποίοι καθορίζουν την ευελιξία του δικτύου είναι: ανοχή στα λάθη, δυνατότητα επαναπρογραμματισμού των ρυθμίσεων λειτουργίας, ασφαλής λειτουργία(safety), ασφάλεια (security) και απόδοση σε συνθήκες πραγματικού χρόνου. 22

31 Σχήμα 2.5. Δομή της αρχιτεκτονικής του μοντέλου SOCRADES [7]. Η δεύτερη υιοθέτει την υπηρεσιοστρεφή προσέγγιση όχι μόνο για τη σχεδίαση της ιεραρχίας στο επίπεδο των ενσωματωμένων συσκευών αλλά και για τα υψηλοτέρα επίπεδα των βιομηχανικών διαδικασιών. Σε αυτή την προσέγγιση βασικός στόχος είναι να μπορούν οι συσκευές να επικοινωνούν τόσο μεταξύ τους όσο και με τις επιχειρησιακές εφαρμογές (business applications ) των ανωτέρω επιπέδων. Σε αυτό το σημείο να σημειώσουμε ότι η επικοινωνία με τα ανώτερα επίπεδα μπορεί να είναι είτε τύπου εφαρμογής-συσκευής είτε τύπου εφαρμογής-συστήματος από συσκευές (System of Devices) Επίπεδα του SOCRADES Με βάση το σχήμα 2.5 παραθέτουμε μία ανάλυση των επιπέδων του SOCRADES. Τα επίπεδα σύμφωνα με την υπηρεσιοστρεφή προσέγγιση είναι τα εξής: 1. Sensor/actuator network Σε αυτό το επίπεδο βρίσκονται οι συσκευές σαν φυσικές οντότητες που μπορεί να λειτουργούν και να επικοινωνούν με οποιαδήποτε τεχνολογία. 2. Device level middleware Ευθύνη αυτού του επιπέδου είναι να αποκρύπτει τις ιδιαιτερότητες των τεχνολογιών των δικτύων αισθητήρων-ενεργοποιητών. 3. Device level application platform-το επίπεδο είναι υπεύθυνο να εκθέτει τα γεγονότα (events) των αισθητήρων και τις λειτουργίες των ενεργοποιητών (actuators) στα παραπάνω επίπεδα. Η υλοποίηση αυτού του επιπέδου γίνεται με βάση την υπηρεσιοστρεφή αρχιτεκτονική ενώ η τεχνολογία η οποία προτιμάται συνήθως είναι τα Web Services. 23

32 4. Enterprise level middleware-το επίπεδο αυτό προσφέρει λειτουργίες όπως ενορχήστρωση (orchestration) και χορογραφία (choreography).σε αυτό το επίπεδο επίσης προσφέρεται διαχείριση της αποθήκης (repository) των Services και εκτελείται η διαδικασία αναζήτησης ενός service με βάση κάποιο από τα χαρακτηριστικά του. Μία τέτοια διαδικασία π.χ. είναι η αναζήτηση ενός service το οποίο κάνει grapple. 5. Enterprise level application platform-το επίπεδο αυτό είναι μέρος ενός προγράμματος διαχείρισης επιχειρήσεων (business process management system). Όλη η πλατφόρμα στοχεύει στη υλοποίηση ενός ολοκληρωμένου προγράμματος διαχείρισης επιχειρήσεων το οποίο προσφέρει άμεσο έλεγχο και εποπτεία στο επίπεδο των συσκευών. Παράλληλα ο έλεγχος και η γενική εποπτεία όλης της παραγωγικής διαδικασίας θα γίνεται μέσω ενός BMS (Business Management System) όπως π.χ. ένα Enterprise Resource Planning Suite. Η απεικόνιση ενός συστήματος το οποίο υλοποιεί την σχεδίαση που βασίζεται στα επίπεδα που αναλύσαμε παραθέτεται στο σχήμα 2.6. Σχήμα 2.6 Συνιστώσες ενός συστήματος βασισμένο στη δομή SOCRADES 2.7. Το έργο IMC-AESOP Το έργο IMC-AESOP [20] άρχισε τις διεργασίες του το Σεπτέμβριο του 2010 και αναμένεται να διαρκέσει 30 μήνες. Σκοπός αυτού του Project είναι η διερεύνηση της υπηρεσιοστρεφούς αρχιτεκτονικής και η δημιουργία λύσεων για την εποπτεία και τον έλεγχο διεργασιών παραγωγής πολύ μεγάλης κλίμακας. Το IMC-AESOP Project κινείται προς τη κατεύθυνση της δημιουργίας ολοκληρωμένων συστημάτων παραγωγής τα οποία θα επιτρέψουν την εποπτεία και τον έλεγχο της παραγωγής να 24

33 πραγματοποιείται ομοιόμορφα με έναν διαστρωματικό (cross-layer ) τρόπο. Η δομή την οποία προτείνει το έργο AESOP για τη δημιουργία των παραπάνω συστημάτων είναι μία βασισμένη σε υπηρεσιοστραφή λογική SCADA/DCS δομή (SOA-based SCADA/DCS infrastructure ). Μέχρι αυτή τη στιγμή το έργο δεν έχει δημοσιεύσει αποτελέσματα που να προέκυψαν από τις διεργασίες του, καθώς δεν βρίσκεται ακόμα στο στάδιο των υλοποιήσεων. Είναι όμως σημαντικό να αναφέρουμε ότι το έργο έχει δημοσιεύσει μία σειρά από προδιαγραφές οι οποίες θα καθορίσουν το Framework που θα προκύψει ως αποτέλεσμα του. Αν και οι επιδιώξεις οι οποίες έχει θέσει το έργο είναι γενικής φύσεως παρακάτω παραθέτεται μία σειρά από τεχνολογικούς στόχους οι οποίοι υλοποιούν τις επιδιώξεις του προγράμματος. Στόχοι τoυ προγράμματος είναι: Nα προτείνει μια προσέγγιση τύπου σύστημα συστημάτων (System-of- Systems) για κατανεμημένο και συνεργαζόμενο έλεγχο βασισμένο στην υπηρεσιοστραφή αρχιτεκτονική καθώς και η εφαρμογή του σε διεργασίες βιομηχανικού έλεγχου πολύ μεγάλης κλίμακας. Να διερευνήσει «πόσο βαθιά» στην αρχιτεκτονική των επιχειρήσεων μπορούμε να φτάσουμε με την υπηρεσιοστραφή λογική. Να διερευνήσει αν είναι εφικτό να εισαχτεί η υπηρεσιοστραφή αρχιτεκτονική μέσα στον βρόχο ελέγχου (control loop) του επιπέδου συσκευών. Να προσδιορίσει πιο είναι το εύρος του αριθμού των συσκευών που μπορεί να λειτουργήσει αποτελεσματικά στα πλαίσια συστημάτων βασισμένων στην υπηρεσιοστραφή αρχιτεκτονική. Να δημιουργήσει τις βάσεις για την πρόβλεψη της απόδοσης τέτοιων αρχιτεκτονικών. Να προτείνει ένα πρωτόκολλο μετάβασης για την ενσωμάτωση των κληροδοτημένων συσκευών (legacy devices) σε συστήματα βασισμένα στις αρχιτεκτονικές που περιγράφηκαν παραπάνω. Να προτείνει λύσεις ώστε οι συσκευές που ακολουθούν την βασισμένη σε υπηρεσιοστραφή λογική SCADA/DCS δομή να αποτελέσουν επαρκείς κληροδοτημένες συσκευές στο μέλλον. Το έργο AESOP αναμένεται να επεκτείνει τις υπάρχουσες δυνατότητες της DPWS τεχνολογίας προσθέτοντας νέα εργαλεία υλοποίησης και επεκτείνοντας τις δυνατότητες της τεχνολογίας σε όλα τα επίπεδα σχεδίασης, με σκοπό τη δημιουργία αποδοτικότερων συστημάτων βιομηχανικού αυτοματισμού. 25

34 26

35 Κεφάλαιο 3 Devices Profile for Web Services 3.1. Εισαγωγή Συμφώνα με την ανάλυση και τις αναφορές που παρατέθηκαν στο κεφάλαιο 2 καταλήγουμε στο συμπέρασμα ότι αν θέλουμε να ακολουθήσουμε την υπηρεσιοστρεφή αρχιτεκτονική και να εφαρμόσουμε τις αρχές της σε συστήματα ενσωματωμένων συσκευών, η Devices Profile for Web Services(DPWS) [26] αποτελεί τη λογική επιλογή. Αυτή η τεχνολογία έχει αποτελέσει αντικείμενο πολλών ερευνών και προγραμμάτων και αποτελεί την πιο πλήρη λύση για την υλοποίηση συστημάτων ελέγχου και εποπτείας με βάση την υπηρεσιοστρεφή αρχιτεκτονική. Η DPWS τεχνολογία προσφέρει πλούσιο ερευνητικό υλικό και παρέχει εργαλεία για τη διευκόλυνση της υλοποίησης εφαρμογών, ενώ παράλληλα προσφέρει ικανοποιητικές επιδόσεις και αξιοπιστία. Σε αυτό το κεφαλαίο παραθέτουμε και αναλύουμε τις βασικές προδιαγραφές λειτουργίας της DPWS τεχνολογίας καθώς και τα μειονεκτήματα τα οποία εντοπίζονται από την ανάλυση των συγκεκριμένων προδιαγραφών. Τα συγκεκριμένα προβλήματα παρουσιάζονται και στις διάφορες υλοποιήσεις της DPWS τεχνολογίας Devices Profile for Web Services Specifications Η DPWS προδιαγραφή (Specification) καθορίζει μία αρχιτεκτονική στα πλαίσια της οποίας οι συσκευές Devices προσφέρουν δύο τύπους από υπηρεσίες : a) Υπηρεσίες φιλοξενίας(hosting Services) b) Φιλοξενούμενες υπηρεσίες (hosted Services) Οι υπηρεσίες φιλοξενίας είναι άμεσα συσχετιζόμενες με μία συσκευή και παίζουν πολύ σημαντικό ρόλο στη διαδικασία ανακάλυψης της συσκευής την οποία θα αναλύσουμε περεταίρω. Οι φιλοξενούμενες υπηρεσίες προσφέρουν κυρίως λειτουργίες και βασίζονται στις υπηρεσίες που τις φιλοξενούν για να είναι ορατές κατά τη διαδικασία της ανακάλυψης. Πρόσθετα με αυτές τις υπηρεσίες που αναφέραμε το DPWS καθορίζει και ένα σύνολο από ενσωματωμένες στη συσκευή υπηρεσίες: a) Υπηρεσίες ανακάλυψης: Χρησιμοποιούνται από την συσκευή για να διαφημιστεί και για να ανακαλύψει άλλες συσκευές. 27

36 b) Υπηρεσίες ανταλλαγής Μετα-δεδομένων: Προσφέρουν δυναμική πρόσβαση στα Μετα-δεδομένα των φιλοξενούμενων υπηρεσιών της συσκευής. c) Υπηρεσίες συμβάντων (Eventing Services): Επιτρέπουν σε άλλες συσκευές να εγγραφούν(subscribe) ώστε να λαμβάνουν ασύγχρονα μηνύματα γεγονότων(event messages) τα οποία παράγονται από τη συγκεκριμένη συσκευή. Οι βασικές προδιαγραφές των Web Services που αναφέρθηκαν στο κεφάλαιο 1 αποτελούν τον πύρινα των προδιαγραφών του DPWS [27], ενώ για να εξυπηρετηθούν οι ανάγκες οι οποίες προκύπτουν από το ειδικό περιβάλλον στο οποίο απευθύνεται το DPWS προσθέτονται δυο ακόμα προδιαγραφές. Οι προδιαγραφές αυτές αφορούν τη δημιουργία πρωτοκόλλων για την εγγραφή στα συμβάντα των συσκευών (WS-Eventing) και τη διαδικασία ανακάλυψης συσκευών (WS-Discovery). Μία συνολική εικόνα των πρωτοκόλλων και των προδιαγραφών στα οποία βασίζεται η DPWS τεχνολογία φαίνεται παρακάτω στο σχήμα 2.7. Αναλυτικότερα στο θέμα των πρωτοκόλλων, η DPWS τεχνολογία για την διαδικασία της διευθυνσιοδότησης βασίζεται στο IP πρωτόκολλο. Όσον αφορά τη διαδικασία μεταφοράς μηνυμάτων χρησιμοποιεί τα πρωτόκολλα UDP και TCP στο επίπεδο μεταφοράς και το πρωτόκολλο HTTP στο επίπεδο εφαρμογής. Σε αυτό το σημείο πρέπει να σημειώσουμε ότι το DPWS βασίζεται στη τεχνολογία των Web Services. Υπενθυμίζουμε ότι οι προδιαγραφές των Web Services είναι οι WS- Security, WS-Adressing, WS-Discovery, WS-Eventing, WS-Policy και WS- MetadataExchange. Αυτές οι προδιαγραφές μαζί με τις ανάλογες επεκτάσεις που χρειάζονται για να ανταποκριθούν στις νέες ανάγκες καθώς και την WSDL και το πρωτόκολλο SOAP, αποτελούν τον πύρινα των λειτουργιών του DPWS. Σχήμα 2.7 DPWS protocol Stack 28

37 DPWS Eventing Specification Η συγκεκριμένη προδιαγραφή προσδιορίζει την συμπεριφορά την οποία αναμένουμε να έχει κάθε υλοποίηση της DPWS τεχνολογίας στον τομέα της επικοινωνίας. Η προδιαγραφή ορίζει την συμπεριφορά τόσο στην περίπτωση που η επικοινωνία γίνεται με σύγχρονο τρόπο όσο και με ασύγχρονο. Η σύγχρονη επικοινωνία γίνεται μέσω απομακρυσμένων κλήσεων και καλύπτεται από τις προδιαγραφές WS-Addressing και WS-MetadataExchange. Αυτός ο τρόπος επικοινωνίας είναι όμοιος με τον τρόπο επικοινωνίας που χρησιμοποιούν τα Web Services όπως αναφέρεται στο Κεφάλαιο 1. Αντίθετα η ασύγχρονη επικοινωνία αν και βασίζεται στην WS-Eventing προδιαγραφή των Web Serviceς [28], επεκτείνει τους υπάρχοντες μηχανισμούς και εισάγει νέους. Στην DPWS τεχνολογία, η ασύγχρονη επικοινωνία χρησιμοποιείται για να ειδοποιηθεί κάποιος πελάτης ότι συνέβη ένα γεγονός. Σε αυτό το σημείο πρέπει να αναφέρουμε ότι ο πελάτης πρέπει να έχει δηλώσει ότι θέλει να «μαθαίνει» πότε συνέβη ένα γεγονός ώστε να λαμβάνει ειδοποίηση, δηλαδή πρέπει να έχει προηγηθεί μια διαδικασία εγγραφής. Οι διαδικασίες τις οποίες ορίζουν οι DPWS προδιαγραφές για τη διαχείριση τέτοιων απαιτήσεων είναι: A. Οι διαδικασίες της εγγραφής, της ανανέωσης και της απεγραφής B. Η διαδικασία του φιλτραρίσματος. A. Εγγραφή, Ανανέωση και Απεγγραφή Οι ειδοποιήσεις γεγονότων είναι μηνύματα τα οποία βασίζονται στο SOAP και στην WS-Adressing προδιαγραφή και η δομή τους βασίζεται στους ορισμούς του WSDL με το οποίο συσχετίζονται. Η WS-Eventing προδιαγραφή του DPWS καθορίζει ένα πρωτόκολλο διαχείρισης του μηχανισμού δημοσίευσης-εγγραφής (publishsubscribe). Το πρωτόκολλο αυτό επιτρέπει σε ένα Web Service, το οποίο έχει το ρόλο του event sink, να εγγραφεί σε ένα άλλο Web Service. Το Web Service αυτό έχει το ρόλο της πηγής γεγονότων (event source) και ο σκοπός του είναι να λαμβάνει ειδοποιήσεις (notifications) για γεγονότα. Οι ειδοποιήσεις είναι συνήθως μηνύματα μιας διαδρομής (one way), αλλά μπορεί να είναι μηνύματα αλληλεπιδράσεων τα οποία ζητούν απάντηση (solicit response interactions ).Τα μηνύματα αυτά μεταφέρονται με τον ίδιο τρόπο όπως τα υπόλοιπα SOAP μηνύματα και μπορεί να περιλαμβάνουν δεδομένα οποιουδήποτε τύπου. Πρέπει να σημειωθεί ότι εγγραφή ενός event sink σε μία πηγή γεγονότων λήγει μετά από κάποιο χρονικό διάστημα και για αυτόν τον λόγο το DPWS προβλέπει λειτουργία ανανέωσης(renew) της εγγραφής, ενώ στην περίπτωση που υπάρχει ανάγκη να σταματήσει η αποστολή των ειδοποιήσεων παρέχεται η δυνατότητα απεγγραφής. Συνολικά λοιπόν μπορούμε να πούμε ότι το DPWS προσφέρει τρείς λειτουργίες που 29

38 αφορούν την διαχείριση των μηνυμάτων ειδοποιήσεων γεγονότων (event notification messages) ενσωματωμένες στην συσκευή. Αυτές είναι η εγγραφή, ανανέωση και απεγραφή. B. Φιλτράρισμα (Filtering) Μια ακόμα λειτουργία η οποία μπορεί προαιρετικά να προσφέρεται σύμφωνα με την WS-Eventing προδιαγραφή του DPWS είναι η δυνατότητα φιλτραρίσματος των ειδοποιήσεων που θα λάβει. Η συνθήκη φιλτραρίσματος αν υπάρχει περιλαμβάνεται στην αίτηση εγγραφής και έχει ως αποτέλεσμα η πηγή γεγονότων να στέλνει μόνο τις ειδοποιήσεις οι οποίες πληρούν τις προϋποθέσεις του φίλτρου. Αξίζει να σημειωθεί ότι το φιλτράρισμα που επιτρέπει το DPWS περιορίζεται στη σύγκριση μεταξύ unified resource identifiers [21] DPWS Discovery Η DPWS τεχνολογία χρησιμοποιεί το πρωτόκολλο που προτείνει η WS-Discovery προδιαγραφής για την ανακάλυψη συσκευών τις οποίες αναζητά μία συνιστώσα τύπου πελάτη (Client Component). Οι τρόποι λειτουργίας(modes) που προβλέπει WS-Discovery προδιαγραφή για την διαδικασία της ανακάλυψης είναι οι εξής: a. Ad Hoc Τρόπος b. Managed τρόπος a. Ad Hoc Τρόπος Σχήμα 2.8 Ad Hoc Mode Discovery sequence diagram [8] 30

39 Ένα Web Service μόλις εισέλθει σε ένα δίκτυο στέλνει ένα multicast Hello μήνυμα το για να δηλώσει ότι είναι διαθέσιμο. O Client παράλληλα, στο διάστημα που είναι ενεργός, «ακούει» για multicast μηνύματα. Όταν θελήσει να αναζητήσει ένα service στέλνει ένα multicast Probe μήνυμα το οποίο περιέχει τις παραμέτρους αναζήτησης. Η ανακάλυψη μπορεί να γίνει είτε με βάση τον τύπο (Type) είτε με βάση το πεδίο δράσης (Scope). H παράμετρος αναζήτησης Type αναφέρεται στο στοιχείο PortType του WSDL του Service, ενώ η παράμετρος Scope χρησιμοποιείται για την ομαδοποίηση των Web Services σε λογικές ομάδες. Στο σχήμα 2.9 φαίνεται η δομή ενός Probe μηνύματος όπου ο Client αναζητά ένα Service το οποίο υλοποιεί ένα Basic Print Type και βρίσκεται στο Scope του engineering Department. Αν μερικά από τα διαθέσιμα Web Services έχουν τις κατάλληλες παραμέτρους, σύμφωνα με το Probe μήνυμα που έστειλε o Client, στέλνουν ένα Unicast Probe Match μήνυμα στον Client. Στη συνέχεια ο Client στέλνει ένα multicast μήνυμα επίλυσης (Resolve) για να εντοπίσει ένα συγκεκριμένο Service. Στη συνέχεια όποιο από τα υποψήφια Services πληροί τις προϋποθέσεις του Resolve μνήματος στέλνει ένα unicast Resolve match μήνυμα στον Client,έτσι o Client εντοπίζει το κατάλληλο Target Service. Τέλος αν ένα Service εξέλθει από το δίκτυο στέλνει ένα multicast Bye μήνυμα για να δηλώσει ότι δεν είναι πια διαθέσιμο. Η διαδικασία ανακάλυψης που περιγράψαμε φαίνεται σχηματικά στο διάγραμμα ακολουθίας του σχήματος 2.8. Σχήμα 2.9 Probe message envelope 31

40 b. Managed τρόπος Σε αυτό το σημείο πριν αναλύσουμε την λειτουργία του managed τρόπου λειτουργίας πρέπει να αναφέρουμε την λειτουργία της Discovery Proxy οντότητα. Όπως αναφέραμε η ανακάλυψη (Discovery), η οποία βασίζεται στα multicast μηνύματα περιορίζεται στα τοπικά δίκτυα. Για να μπορεί η διαδικασία της ανακάλυψης να ενσωματωθεί σε επιχειρησιακού εύρους εφαρμογές η WS- Discovery προδιαγραφή προτείνει την έννοια της Discovery Proxy. Η Discovery proxy έχει δυο λειτουργίες : Πρώτον να περιορίσει την κίνηση η οποία δημιουργείται από τα multicast μηνύματα και δεύτερον να επεκτείνει το πρωτόκολλο ανακάλυψης πέρα από τα όρια του δικτύου. Σχήμα 2.10 Managed Mode Discovery sequence diagram [8] Το πρωτόκολλο επικοινωνίας μεταξύ ενός Service και Client έχει ως αποτέλεσμα λόγω των multicast μηνυμάτων να δημιουργείται φορτίο στο δίκτυο. Για να αποφευχθεί η δημιουργία υπερβολικού φορτίου η WS-Discovery προδιαγραφή προβλέπει έναν δεύτερο τρόπο λειτουργίας της διαδικασίας ανακάλυψης. Αυτός είναι ο managed τρόπος (managed mode). Ο managed τρόπος κατά τη διαδικασία ανακάλυψης ακολουθεί το πρωτόκολλο που φαίνεται στο σχήμα 2.8. To Service στέλνει ένα Unicast hello μήνυμα σε ένα Discovery Proxy όταν εισέλθει σε ένα δίκτυο. Από τη πλευρά του o Client όταν θέλει να ανακαλύψει ένα Service στέλνει ένα unicast Probe αίτημα στο Discovery Proxy και το Proxy ανταποκρίνεται στέλνοντας μία Probe match απάντηση η οποία περιέχει τα Services, τα οποία πληρούν τις προϋποθέσεις του Probe μηνύματος. Στη συνέχεια όπως και στον Ad hoc τρόπο λειτουργίας ακολουθείτε η διαδικασία Resolve αίτησης-απάντησης (request- response) ώστε να ανακαλύψει ο Client το κατάλληλο Service. Τέλος όταν ένα Service εξέρχεται από το δίκτυο στέλνει ένα Bye μήνυμα στo Discovery proxy για να δηλώσει ότι δεν είναι πλέον διαθέσιμο. Η διαδικασία αναζήτησης του 32

41 managed τρόπου λειτουργίας δίνεται σχηματικά μέσω του διαγράμματος ακολουθίας του σχήματος DPWS Addressing Η βάση της DPWS διευθυνσιοδότησης (addressing) βρίσκεται στην διευθυνσιοδότηση του Internet Protocol έκδοση 4 (IPv4)/Internet Protocol έκδοση 6. To DPWS «υποθέτει» ότι μία συσκευή έχει λάβει μία αποδεκτή IP διεύθυνση. Για να γίνει σωστά η διευθυνσιοδότηση το DPWS απευθύνεται στο Dynamic Host Configuration Protocol (DHCP) και στον auto configuration μηχανισμό του IPv6 πρωτοκόλλου DPWS Description Ο μηχανισμός περιγραφής του DPWS επιτρέπει την δυναμική περιγραφή των Μεταδεδομένων της συσκευής όπως φιλοξενούμενα Services ή πληροφορίες για την ιδία τη συσκευή όπως κατασκευαστή και μοντέλο. Ένα σημαντικό χαρακτηριστικό που προβλέπει αυτή η προδιαγραφή είναι ότι τα συγκεκριμένα μετα-δεδομένα πρέπει να είναι συσχετιζόμενα με έναν αριθμό έκδοσης (version number) μετα-δεδομένων ο οποίος περιλαμβάνεται και στα μηνύματα ανακάλυψης. Έτσι οι Clients μπορούν να αντιλαμβάνονται τις αλλαγές στα μετα-δεδομένα περιγραφής της συσκευής. Η διεπαφή η οποία χρησιμοποιείται για να ανακτήσουμε την περιγραφή της συσκευής βασίζεται στη WS-Metadata Exchange προδιαγραφή. Όπως καθορίζεται λοιπόν από την προαναφερθείσα προδιαγραφή, τα μετα-δεδομένα είναι διαχωρισμένα σε τμήματα. Το DPWS καθορίζει πιο endpoint μιας συσκευής αναφέρεται σε κάθε ένα από τα τμήματα που αναφέρθηκαν παραπάνω. Επίσης παρέχει την δυνατότητα δημιουργίας προσαρμοσμένων τμημάτων (custom section) ώστε η επεκτασιμότητα της περιγραφής του Device να αυξηθεί και να μπορεί να χρησιμοποιηθεί και για προσαρμοσμένες εφαρμογές (custom applications). Στο παρακάτω σχήμα 2.11 φαίνεται τμήμα του SOAP envelope που αποτελεί απάντηση σε ένα αίτημα Get προς την συσκευή. Όπως βλέπουμε στο σχήμα 2.11 το τμήμα «thisdevice» παρέχει πληροφορίες για την συσκευή ενώ το τμήμα «thismodel» προσφέρει πληροφορία για το συγκεκριμένο μοντέλο DPWS Security Η DPWS προδιαγραφή ορίζει την έννοια των προφίλ ασφαλείας. Τα προφίλ ασφαλείας αποτελούν ένα σύνολο από περιορισμούς που καθιστούν τις επιμέρους διαδικασίες μιας υλοποίηση της DPWS τεχνολογίας, ασφαλείς. Η προδιαγραφή αν και ορίζει ένα συγκεκριμένο προφίλ ασφαλείας, αυτό δεν είναι δεσμευτικό. Μια συσκευή μπορεί να χρησιμοποιεί ένα δικό της προσαρμοσμένο (custom) προφίλ. Οι απαιτήσεις όσον αφορά την ασφάλεια βασίζονται κυρίως στην ίδια την εφαρμογή, παρόλα αυτά το προφίλ ασφαλείας θα πρέπει να στοχεύει σε εύκολη και «ελαφριά» υλοποίηση. Το προφίλ ασφαλείας το οποίο ορίζεται από το DPWS περιλαμβάνει δυο βασικά χαρακτηριστικά: 33

42 Πρώτον ασφαλή διαδικασία ανακάλυψης αφού τα multicast μηνύματα χρησιμοποιούν WS-Discovery υπόγραφες. Αυτές οι υπογραφές είναι παρόμοιες με τις XML υπογραφές που ορίζει η WS-Security προδιαγραφή άλλα με λιγότερη επιβάρυνση (overhead). Δεύτερον ασφαλές κανάλι το οποίο προσφέρει κρυπτογράφηση στο επίπεδο επικοινωνίας βασισμένη στην TLS/SSL ( Transport Layer Security, Secure Sockets Layer ) τεχνολογία. Σχήμα 2.11 Απάντηση Συσκευής σε Get μήνυμα του Client ( SOAP Envelope) 3.4. Μειονεκτήματα του DPWS Εξετάζοντας συνολικά το αποτέλεσμα το οποίο προκύπτει από τις υιοθέτηση των προδιαγραφών που αναφέραμε στο κεφάλαιο 3.2, εντοπίσαμε μία σειρά από μειονεκτήματα τα οποία είναι αποτέλεσμα του σχεδιασμού. Αυτά τα μειονεκτήματα θα αναλυθούν στη συνέχεια αυτής της παραγράφου, ενώ παράλληλα θα προταθούν λύσεις και βελτιώσεις. Πρέπει να αναφέρουμε ότι τα μειονεκτήματα που θα παρουσιάσουμε στη συνέχεια αποτελούν παρατηρήσεις οι οποίες συγκεντρώθηκαν τόσο από την μελέτη των προδιαγραφών της DPWS τεχνολογίας, όσο και από την 34

43 μελέτη δημοσιεύσεων πάνω στην αρχιτεκτονική της τεχνολογίας. Σε αυτό το σημείο να σημειώσουμε ότι τα μειονεκτήματα και οι ελλείψεις οι οποίες διαπιστώθηκαν κατά τη υλοποίηση της εφαρμογής επίδειξης θα αναλυθούν στο κεφάλαιο Εισαγωγή μεγάλου φόρτου στο δίκτυο Η διαδικασία της δυναμικής ανακάλυψης του DPWS βασίζεται στην WS-Discovery και SOAP-over-UDP προδιαγραφές. Αυτή η διαδικασία της ανακάλυψης την οποία περιγράψαμε σε προηγουμένη παράγραφο αποτελεί και ένα από τα σημαντικότερα μειονεκτήματα της DPWS αρχιτεκτονικής [14]. Η παραπάνω διαδικασία αν και προσφέρει μεγάλη ευελιξία στους Client αφού μπορούν να ανακαλύψουν και να συνδεθούν με μία συσκευή γνωρίζοντας ελάχιστα στοιχεία γι αυτή, έχει υψηλό κόστος από πλευράς πόρων. Κατά την ad hoc λειτουργία σε κάθε αναζήτηση ενός Service εκτελούνται δύο διαδικασίες αίτησης απάντησης (Probe-Probe Match και Resolve-Resolve Match) στην χειρότερη περίπτωση και μάλιστα τα Probe και Resolve μηνύματα είναι Multicast μηνύματα. Η παραπάνω διαδικασία μπορεί ανάλογα με του πόρους του δικτύου να διαρκέσει αρκετά δευτερόλεπτα λόγω του μεγέθους των SOAP μηνυμάτων, ενώ τα multicast μηνύματα αυξάνουν σημαντικά την κίνηση στο δίκτυο. Όμως αυτή η διαδικασία δεν είναι απαραίτητο ότι θα εκτελείται σε όλες τις περιπτώσεις που ένας Client χρειάζεται να συνδεθεί με μία συσκευή. Προτάσεις Μία διαδικασία προσωρινής αποθήκευσης θα μπορούσε να μειώσει τους αναγκαίους πόρους καθώς και τον φόρτο του δικτύου στην περίπτωση που ένας Client χρειάζεται να ανακαλύπτει μια συσκευή πολλές φορές. Δηλαδή να ανακαλύπτει τη συσκευή, να συνδέεται με την συσκευή, στη συνέχεια να αποσυνδέεται και μετά από κάποιο σύντομο χρονικό όταν ξανασυνδεθεί με την ίδια συσκευή μη χρειάζεται να ζητήσει ξανά τις πληροφορίες τις συσκευής αφού θα βρίσκονται αποθηκευμένες σε κάποια προσωρινή μνήμη. Μία ακόμα πρόταση είναι να χρησιμοποιήσουμε την πληροφορία για μια συσκευή που γνωρίζουμε εκ των προτέρων (κατά τον χρόνο ανάπτυξης). Για παράδειγμα αν γνωρίζουμε το endpoint της συσκευής εκ των προτέρων μπορούμε να συμπεριλάβουμε αυτό το endpoint στο κώδικα ώστε να έχουμε απευθείας πρόσβαση στη συσκευή Μεταφορά μεγάλου όγκου δεδομένων Το πιο εμφανές μειονέκτημα του DPWS, το οποίο συμβάλει ουσιαστικά ώστε η ήδη αργή διαδικασία της αναζήτησης να γίνει ακόμα πιο αργή είναι η επιβάρυνση η οποία προσθέτει η αναπαράσταση των δεδομένων σε μορφή XML και ιδιαίτερα η χρήση των XML namespaces. Αυτός ο συμβιβασμός βασίζεται στην αρχή, ότι η 35

44 ευελιξία είναι σημαντικότερη από την βελτιστοποίηση. Αυτή η αρχή παρουσιάζεται πολύ συχνά στα υπηρεσιοστραφή συστήματα, όμως όταν αναφερόμαστε σε ενσωματωμένα συστήματα οπού οι πόροι είναι περιορισμένοι, η βελτιστοποίηση αποτελεί τη σημαντικότερη επιδίωξη, επομένως η προηγούμενη αρχή τίθεται υπό αμφισβήτηση. Προτάσεις Ιδανικά θα πρέπει να δημιουργηθεί μια μορφή αναπαράστασης η οποία θα αποτελεί έναν συμβιβασμό ανάμεσα στη βελτιστοποίηση και την ευελιξία, ενώ μια άλλη λύση θα μπορούσε να είναι η αντικατάσταση της XML αναπαράστασης ως κύρια μέθοδος αναπαράστασης δεδομένων με μια δυαδικού τύπου αναπαράσταση για τη μεταφορά μηνυμάτων στα ιδιαίτερα κρίσιμα τμήματα του συστήματος. 36

45 Κεφάλαιο 4 Το σύστημα Festo MPS 4.1. Εισαγωγή Σε αυτό το κεφάλαιο θα παρουσιαστεί το σύστημα γραμμής παραγωγής Festo Modular Production System (Festo MPS). Το Festo MPS αποτελεί το σύστημα επίδειξης πάνω στο οποίο υλοποιήσαμε μία διαδικασία βιομηχανικού ελέγχου κάνοντας χρήση της DPWS τεχνολογίας. Στις επόμενες παραγράφους παρουσιάζονται συνοπτικά τα δομικά στοιχεία του Festo MPS και δίνονται πίνακες με το σύνολο των ενεργοποιητών και αισθητήρων που έχει η κάθε μονάδα του συστήματος. Όπως αναλύθηκε στο κεφάλαιο 3, η DPWS τεχνολογία χρησιμοποιείται για να φτιάξουμε μία διαδραστική αναπαράσταση της πραγματικής συσκευής η οποία μπορεί να είναι ορατή μέσω του δικτύου και να μεταφέρει τα μηνύματα ελέγχου από και προς την πραγματική συσκευή. Για να κατασκευαστεί σωστά αυτή η DPWS αναπαράσταση, δηλαδή η DPWS συσκευή, πρέπει οι ειδοποιήσεις των αισθητήρων και οι λειτουργίες των ενεργοποιητών της πραγματικής συσκευής να αναπαρασταθούν μία προς μία και να προσαρτηθούν στην DPWS συσκευή. Λαμβάνοντας υπόψη την ένα προς ένα αντιστοίχηση, η οποία είναι απαραίτητο στάδιο της διαδικασίας υλοποίησης δίνονται στο κεφάλαιο αυτό, οι πίνακες αντιστοίχησης των ενεργοποιητών και αισθητήρων του πραγματικού συστήματος με τα γεγονότα (events) και τις λειτουργίες (Operations) της DPWS διεπαφής για την κάθε συσκευή. Τέλος στη τελευταία παράγραφο αυτού του κεφαλαίου δίνεται μία σύντομη περιγραφή του εξομοιωτή του συστήματος Festo, ο οποίος θα χρησιμοποιηθεί για να δοκιμάσουμε τις υλοποιήσεις του συστήματος ελέγχου που σχεδιάσαμε και επίσης αναφέρονται οι αποκλίσεις οι οποίες παρατηρήθηκαν μεταξύ του εξομοιωτή και του πραγματικού συστήματος Το φυσικό σύστημα Festo MPS Το σύστημα Festo MPS είναι ένα σύστημα γραμμής παραγωγής διδακτικού σκοπού το οποίο αναπτύχθηκε από την εταιρία Festo. To σύστημα αυτό είναι αρθρωτά κατασκευασμένο σε μονάδες λειτουργιών οι οποίες μπορούν να λειτουργούν τόσο 37

46 ανεξάρτητα όσο και σε συνεργασία μεταξύ τους. Οι μονάδες από τις οποίες αποτελείται το σύστημα είναι οι εξής: A. Μονάδα διανομής (Distribution Station) B. Μονάδα έλεγχου (Testing Station) C. Μονάδα επεξεργασίας (Processing Station) D. Μονάδα αποθήκευσης (Warehouse Station) Κάθε μία από τις μονάδες αποτελείται από επιμέρους εξαρτήματα τα οποία εκτελούν συγκεκριμένες ενέργειες μέσω των ενεργοποιητών τους. Επίσης να συμπληρώσουμε ότι παράλληλα με τα εξαρτήματα λειτουργούν και οι αισθητήρες οι οποίοι είναι τοποθετημένοι σε διάφορα σημεία της κάθε μονάδας ώστε να προσφέρουν ανάδραση από τις ενέργειες των ενεργοποιητών για να μπορεί να υπάρξει ολοκληρωμένη διαδικασία ελέγχου. Μια συσκευή η οποία είναι συμβατή με την DPWS τεχνολογία αντιστοιχεί αυτόματα την ενεργοποίηση ενός αισθητήρα με τη δημιουργία ενός γεγονότος (event occurred). Αυτό το γεγονός στη συνέχεια θα γίνει αντιληπτό από τους Clients που έχουν δηλώσει ότι θέλουν να ειδοποιούνται όταν συμβαίνει αυτό το γεγονός (Subscriptions) μέσω του μηχανισμού ειδοποιήσεων που προσφέρει η EventSource διεπαφής του DPWS. Μία διαδικασία αντιστοίχησης όπως αυτή που περιγράψαμε συμβαίνει μεταξύ των ενεργοποιητών (actuators) και των λειτουργιών (Operations) που προσφέρει μία συσκευή. Με αυτό τον τρόπο κάθε λειτουργία του ενεργοποιητή είναι ορατή ως μέθοδος ενός Web Service. Στις επόμενες παραγράφους γίνεται αναλυτικότερη παρουσίαση κάθε σταθμού του συστήματος, ενώ παράλληλα παρατίθενται πίνακες αντιστοίχησης μεταξύ των ειδοποιήσεων των αισθητήρων και των γεγονότων στα οποία μεταφράζονται, καθώς και μεταξύ των ενεργοποιητών και των Operations στα οποία αντιστοιχούν Μονάδα διανομής Η μονάδα διανομής αποτελείται από τα εξής επιμέρους εξαρτήματα: a) Feeder b) Converter Περιγραφή Η μονάδα διανομής δέχεται τεμάχια (Workpieces) από μία στοίβα στην οποία βρίσκονται αποθηκευμένα και τα μεταφέρει στην μονάδα ελέγχου. Η μεταφορά αυτή πραγματοποιείται μέσω ενός πνευματικού κυλίνδρου. Στον συγκεκριμένο κύλινδρο αναφερόμαστε ως Feeder και η απεικόνιση του φαίνεται στο σχήμα 4.8. Ο Feeder μεταφέρει το τεμάχιο στην κατάλληλη θέση ώστε να παραληφθεί από τον μεταφορέα (Converter).Τέλος ο μεταφορέας, του οποίου η απεικόνιση φαίνεται στο 38

47 σχήμα 4.9, δεσμεύει και μεταφέρει το τεμάχιο μέσω της θηλής την οποία διαθέτει στη μονάδα ελέγχου. Στον τομέα του συντονισμού, ο έλεγχος των επιμέρους εξαρτημάτων, δηλαδή του Feeder και του μεταφορέα, γίνεται με τη βοήθεια αισθητήρων και ενεργοποιητών. Οι ενεργοποιητές και οι αισθητήρες που υπάρχουν στην μονάδα φαίνονται στον πίνακα 4.1 και η αντιστοιχία τους με τα Events και τα Operations φαίνονται στους πίνακες 4.2,4.3,4.4 και 4.5. Πινάκας 4.1 Παρουσίαση των ενεργοποιητών και των αισθητήρων του της μονάδας διανομής [31] a) Feeder Σχήμα 4.8 Απεικόνιση του Feeder[31] 39

48 Events FeederBackPositionNotification FeederFrontPositionNotification Sensors Sensor for Back Stop Sensor for Front Stop PieceinPositionANotification* Workpiece sensor(position A) Πινάκας 4.2 Αντιστοίχηση μεταξύ αισθητήρων και γεγονότων του Feeder *ο αισθητήρας WorkPiece sensor δεν υπάρχει στο πραγματικό σύστημα Festo MPS στοv Feeder, αλλά υπάρχει στην υλοποίηση του εξομοιωτή που θα χρησιμοποιήσουμε στο σύστημα ελέγχου της υλοποίησης μας. Operations Actuators MoveForward Push-out Cylinder move Forward MoveBack Push-out Cylinder move Backwards Stop Stop Πινάκας Αντιστοίχηση μεταξύ αισθητήρων και γεγονότων του Feeder b) Converter Σχήμα 4.9 Απεικόνιση του Converter[31] Events Sensors ConverterRightStopNotification Sensor for Right Stop(position A) ConverterLeftStopNotification Sensor for Left Stop(position B) PieceSuckedInNotification Piece sucked in PieceInPositionANotification Workpiece sensor(position A) Πινάκας 4.4 Αντιστοίχηση μεταξύ αισθητήρων και γεγονότων του Converter 40

49 Operations Actuators MoveRight Pneumatic sucker move right MoveLeft Pneumatic sucker move left Stop Stop VacuumOn Vacuum On VacuumOff Vacuum Off Πινάκας 4.5 Αντιστοίχηση μεταξύ αισθητήρων και γεγονότων του Converter Μονάδα Ελέγχου Η μονάδα έλεγχου αποτελείται από τα εξής επιμέρους εξαρτήματα: a) Detection Module b) Shift out Cylinder c) Elevator Περιγραφή Η μονάδα ελέγχου, η οποία παρουσιάζεται στο σχήμα 4.10, λαμβάνει τα τεμάχια από την μονάδα διανομής και χρησιμοποιώντας αισθητήρες ελέγχει το κατά πόσο είναι κατάλληλα η όχι. Στη συνέχεια αν τα τεμάχια κριθούν ακατάλληλα ενεργοποιείται ένας πνευματικός κύλινδρος ο όποιος τα απομακρύνει. Στην αντίθετη περίπτωση τα τεμάχια μεταφέρονται μέσω του ανελκυστήρα στο σύστημα μεταφοράς που θα τα μεταφέρει στη μονάδα επεξεργασίας. Οι ενεργοποιητές και οι αισθητήρες που υπάρχουν στην μονάδα φαίνονται στον πίνακα 4.6 και η αντιστοιχία τους με τα Events και τα Operations φαίνονται στους πίνακες 4.7 έως Σχήμα 4.10 Απεικόνιση της Μονάδας ελέγχου [31] 41

50 Πινάκας 4.6 Παρουσίαση των ενεργοποιητών και των αισθητήρων του της μονάδας ελέγχου[31] 1. Detection Module Events ConverterRightStopNotification PieceHeightNotification PieceColorNotification PieceMaterialNotification Sensors Workpiece Sensor Sensor for Height Sensor for Color Sensor for Material* *o αισθητήρας υλικού (sensor material ) δεν έχει υλοποιηθεί στον εξομοιωτή Πινάκας 4.7 Αντιστοίχηση μεταξύ αισθητήρων και γεγονότων του Detection Module 2. Shift out Cylinder Events Sensors SOC_BackPositionNotification Sensor for Back Stop SOC_FrontPositionNotification Sensor for Front Stop Πινάκας 4.8 Αντιστοίχηση μεταξύ αισθητήρων και γεγονότων του Shift Out Cylinder Operations Actuators MoveForward Shift out Cylinder move backward MoveBackwards Shift out cylinder move forward Stop Stop Πινάκας 4.9 Αντιστοίχηση μεταξύ λειτουργιών και ενεργοποιητών του Shift Out Cylinder 42

51 3. Elevator Events Sensors ElevatorUpPositionNotification Sensor for Lower Stop ElevatorDownPositionNotification Sensor for Upper Stop Πινάκας 4.10 αντιστοίχηση μεταξύ αισθητήρων και γεγονότων του Elevator Operations Actuators MoveUp Elevator Move Up MoveDown Elevator Move Down Stop Stop Πινάκας 4.11 αντιστοίχηση μεταξύ λειτουργιών και ενεργοποιητών του Elevator Σύστημα μεταφοράς το τεμαχίου Περιγραφή Το σύστημα μεταφοράς τεμαχίου δεν διαθέτει ενσωματωμένους αισθητήρες ούτε ενεργοποιητές, επομένως δεν θα κάνουμε ανάλυση πέραν της λειτουργίας του. Η λειτουργία του συστήματος μεταφοράς τεμαχίου είναι να μεταφέρει τα τεμάχια από την μονάδα ελέγχου στον περιστρεφόμενο δίσκο της μονάδας επεξεργασίας μέσω ενός ιμάντα μεταφοράς όπως φαίνεται στο σχήμα Σχήμα 4.11 Απεικόνιση του συστήματος μεταφοράς[31] 43

52 Μονάδα Επεξεργασίας Η μονάδα επεξεργασίας αποτελείται από τα εξής επιμέρους εξαρτήματα: a) Rotating Disk b) Drilling Machine c) Checking Machine Περιγραφή Η μονάδα επεξεργασίας λαμβάνει το τεμάχιο μέσω του ιμάντα του συστήματος μεταφοράς και το επεξεργάζεται. Το τεμάχιο μέσω του ιμάντα μεταφέρεται σε έναν περιστρεφόμενο δίσκο ο οποίος μετακινεί το τεμάχιο αρχικά στη μηχανή τρυπήματος και τη συνέχεια στη μηχανή ελέγχου. Τέλος ο δίσκος μεταφέρει τεμάχια κάτω από την θηλή (teat) του κυλίνδρου της μονάδας αποθήκευσης. Τα εξαρτήματα της μονάδας επεξεργασίας φαίνονται στο σχήμα Επίσης παραθέτονται οι ενεργοποιητές και οι αισθητήρες που υπάρχουν στην μονάδα στον πίνακα 4.18 και η αντιστοιχία τους με τα Events και τα Operations στους πίνακες 4.12 έως Σχήμα 4.12 Απεικόνιση της Μονάδας επεξεργασίας [31] 1. Rotating Disk Events RotatingDiskPieceinPositionNotificati on* ElevatorDownPositionNotification Sensors Workpiece present in position 1 Workpiece present in position 2 Workpiece present in position 3 Workpiece present in position 4 Sensor for Upper Stop Πινάκας 4.12 Αντιστοίχηση μεταξύ γεγονότων και αισθητήρων του Rotating Disk *Όλοι οι αισθητήρες οι οποίοι εντοπίζουν την ύπαρξη ενός τεμαχίου σε μία θέση το δίσκου περιστροφής αναφέρονται στην ίδια πηγή γεγονότων(event Source) και ανάλογα με τη θέση που εντοπίστηκε το κομμάτι αλλάζει το περιεχόμενο του μηνύματος ειδοποίησης που θα μεταφερθεί στον Client. 44

53 Operations Actuators Rotate Rotate 90 degrees clockwise Stop Stop Πινάκας 4.13 Αντιστοίχηση μεταξύ λειτουργιών και ενεργοποιητών του Rotating Disk 2. Drilling Machine n Events DrillingMachineBrackedInNotification DrillingMachineBrackedOutNotification DrillingMachineLiftingCylinderUpNotificatio DrillingMachineLiftingCylinderDownNotifica tion Sensors Workpiece Bracked In Workpiece Bracked Out Lifting Cylinder Up Lifting Cylinder Down Πινάκας 4.14 Αντιστοίχηση μεταξύ γεγονότων και αισθητήρων του Drilling Machine Operations Actuators MoveUp Lifting Cylinder Move Up MoveDown Lifting Cylinder Move Down Clamp Cylinder Brack in Clamp Cylinder Brack in Clamp Cylinder Brack out Clamp Cylinder Brack out Stop Lifting Cylinder Stop Lifting Cylinder Stop Drilling Stop Drilling Stop Bracking Stop Bracking Stop Stop Action Πινάκας 4.15 Αντιστοίχηση μεταξύ λειτουργιών και ενεργοποιητών του Drilling Machine 3. Checking Machine Events Sensors CheckingCylinderUpNotification Checking Cylinder Up CheckingCylinderDownNotification Checking Cylinder Down Πινάκας 4.16 Αντιστοίχηση μεταξύ γεγονότων και αισθητήρων του Checking Machine Operations MoveUp MoveDown Stop Actuators Checking Cylinder Move Up Checking Cylinder Move Down Checking Cylinder Stop Πινάκας 4.17 Αντιστοίχηση μεταξύ λειτουργιών και ενεργοποιητών του Checking Machine 45

54 Μονάδα Αποθήκευσης Η μονάδα επεξεργασίας αποτελείται από τα εξής επιμέρους εξαρτήματα: 1. Warehouse Cylinder Περιγραφή Η μονάδα αποθήκευσης που φαίνεται στο σχήμα 4.13 αποτελείται από έναν πνευματικό κύλινδρο ο οποίος μπορεί να κινείται τόσο κάθετα όσο και οριζόντια μέσω μεταλλικών αξόνων. Η λειτουργία αυτού του κυλίνδρου είναι να μεταφέρει τα τεμάχια που παραλαμβάνει από το περιστρεφόμενο δίσκο στη μονάδα αποθήκευσης. Οι ενεργοποιητές και οι αισθητήρες που υπάρχουν στην μονάδα αποθήκευσης φαίνονται στον πίνακα 4.18 και η αντιστοιχία τους με τα Events και τα Operations φαίνεται στους πίνακες 4.19 και Πινάκας 4.18 Παρουσίαση των ενεργοποιητών και των αισθητήρων του της μονάδας επεξεργασίας και της μονάδας ελέγχου[31]. 46

55 1. Warehouse Cylinder Σχήμα 4.13 Απεικόνιση της Μονάδας Αποθήκευσης[31] Events Sensors WarehouseCylinderVacuumStartedNotification Vacuum has started WarehouseCylinderPieceRemovedNotification Pieced removed from table WarehouseCylinderReturnedToDisk Cylinder Returned to Disk Πινάκας 4.10 Αντιστοίχηση μεταξύ γεγονότων και αισθητήρων του Warehouse Cylinder Operations Stop StopVacuum StartVacuum RemovePiece ReturnToDisk Actuators Stop Cylinder Stop Vacuum Start Vacuum Warehouse Cylinder removes piece from table Warehouse Cylinder return to Disk Πινάκας 4.20 Αντιστοίχηση μεταξύ λειτουργιών και ενεργοποιητών του Warehouse Cylinder 47

56 4.3. Festo MPS Εξομοιωτής Παρουσίαση δομής του εξομοιωτή O Festo MPS εξομοιωτής αποτελεί μία εφαρμογή εξομοίωσης του συστήματος Festo MPS που περιγράψαμε σε αυτό το κεφάλαιο. Σε αυτό το σημείο πρέπει να σημειώσουμε ότι ο εξομοιωτής Festo MPS δημιουργήθηκε στα πλαίσια διπλωματικής εργασίας [29]. Η έκδοση του εξομοιωτή που θα χρησιμοποιήσουμε αποτελεί βελτιωμένη έκδοση της πρώτης υλοποίησης [30] με κάποιες μετατροπές που έγιναν ώστε είναι συμβατός με την DPWS τεχνολογία. Ο συγκεκριμένος εξομοιωτής αποτελείται από κλάσεις τύπου Unit οι οποίες εξομοιώνουν την συμπεριφορά των πραγματικών εξαρτημάτων από τα οποία αποτελείται. Κάθε κλάση, απόγονος της κλάσης Unit, είναι ουσιαστικά ένα thread το οποίο υλοποιεί την διεπαφή Unit. Το Unit επικοινωνεί με τα εξωτερικά συστήματα με δύο τρόπους, μέσω των γεγονότων που στέλνει και μέσω των εντολών που λαμβάνει. Σε αυτό το σημείο πρέπει να σημειώσουμε ότι στην υλοποίηση του εξομοιωτή, η επικοινωνία μεταξύ της DPWS διεπαφής του Unit και του νήματος που αναπαριστά το κάθε ενεργό εξάρτημα του Festo MPS, πραγματοποιείται χρησιμοποιώντας το μοντέλο του παραγωγού-καταναλωτή. Το ρόλο του παραγωγού αναλαμβάνει το αντικείμενο το οποίο στέλνει την εντολή σε έναν επόπτη (Monitor), ο οποίος είναι αποκλειστικός για κάθε συσκευή. Το ρολό του καταναλωτή αναλαμβάνει το ίδιο Unit, το οποίο μόλις ολοκληρώσει την σειρά ενεργειών που υπαγορεύτηκε από την προηγούμενη εντολή καλεί την μέθοδο get του αποκλειστικού επόπτη, για να λάβει την επόμενη Αποκλίσεις πραγματικού συστήματος και Festo Simulator Κάνοντας μία προσεκτική παρατήρηση τόσο στη συμπεριφορά όσο και στην ίδια τη δομή της εφαρμογής εξομοίωσης διαπιστώνουμε ότι υπάρχουν κάποιες αποκλίσεις σε σχέση με το πραγματικό σύστημα. Μια σημαντική διάφορα που εμφανίζεται σε αυτή την εξομοίωση είναι η απόκλιση στους χρόνους απόκρισης. Στον εξομοιωτή, η καθυστέρηση μεταφοράς μίας εντολής ελέγχου από την στιγμή που θα φτάσει στη διεπαφή της DPWS συσκευής μέχρι να ληφθεί από το Unit αναμένουμε να είναι πολύ μικρότερη από την καθυστέρηση του πραγματικού συστήματος. Παρόμοια συμπεριφορά αναμένουμε να έχει και η μεταφορά ενός μηνύματος ειδοποίησης ενός γεγονότος από το πραγματικό Unit μέχρι να φτάσει στην DPWS διεπαφή η οποία θα το στείλει στον πελάτη. Σε αυτό το σημείο πρέπει να αναφέρουμε ότι εκτός από τις αποκλίσεις που αναφέραμε παραπάνω οι οποίες οφείλονται στο γεγονός ότι το πραγματικό σύστημα είναι ένα πολύπλοκο σύστημα με πολλές διαφορετικές συνιστώσες, ενώ ο 48

57 εξομοιωτής αναπαριστά με τη χρήση κώδικα την γενική συμπεριφορά αυτών των συνιστωσών, παρουσιάζονται και άλλου τύπου αποκλίσεις. Οι συγκεκριμένες αποκλίσεις αφορούν την κατασκευή του ίδιου του εξομοιωτή. Αυτές οι κατασκευαστικές αποκλίσεις οι έχουν ως αποτέλεσμα ο εξομοιωτής να μιμείται την συμπεριφορά ενός συστήματος παρόμοιο με το Festo MPS αλλά με κάποιες διαφορές. Οι διαφορές παρουσιάζονται στα εξής σημεία: 1. Το Detection Module δεν έχει υλοποιηθεί σαν ανεξάρτητη συσκευή, αντί αυτού όλες τις λειτουργίες του έχουν προστεθεί σε άλλα εξαρτήματα. Η προσέγγιση αυτή δεν δημιουργεί μεγάλες αποκλίσεις από τη λειτουργία του πραγματικού συστήματος γιατί οι ειδοποιήσεις που προσφέρουν οι αισθητήρες που αποτελούν το Detection Module έχουν προστεθεί στις γειτονικές συσκευές, οπότε το λειτουργικό αποτέλεσμα είναι το ίδιο. 2. Μια ακόμα διαφορά είναι ότι ο Shift Out πνευματικός κύλινδρος, ο οποίος μπορεί και κινείται προς τα πάνω η προς τα κάτω με μαζί με τον ανελκυστήρα, έχει αντικατασταθεί στον εξομοιωτή με δύο κυλίνδρους οι οποίοι βρίσκονται ο ένας στη πάνω θέση και ο άλλος στην κάτω θέση και έχουν το ίδιο λειτουργικό αποτέλεσμα με τον πνευματικό κύλινδρο του πραγματικού συστήματος. 49

58 50

59 Κεφάλαιο 5 Εναλλακτικές προτάσεις σχεδίασης του συστήματος 5.1. Εισαγωγή Με βάση την παρουσίαση που έγινε στο κεφάλαιο 2 καλούμαστε να επιλέξουμε την τεχνολογία και τα εργαλεία που θα χρησιμοποιήσουμε για να υλοποιήσουμε ένα σύστημα ελέγχου το οποίο βασίζεται στην SOA αρχιτεκτονική. Πρέπει να σημειώσουμε ότι το σύστημα αυτό θα αποτελέσει ένα τμήμα ενός ευρύτερου συστήματος το οποίο θα βασίζεται στο μοντέλο SOCRADES το οποίο παρουσιάσαμε στο κεφάλαιο 3. Με βάση αυτήν τη προσέγγιση πρέπει να προσδιορίσουμε σε ποια επίπεδα του μοντέλου του συνολικού συστήματος θα επικεντρωθεί η υλοποίηση μας. Στη συνέχεια βασιζόμενοι στην σύγκριση που έγινε μεταξύ των διάφορων υποψήφιων τεχνολογιών στα πλαίσια του έργου SIRENA επιλέξαμε για την δική μας υλοποίηση την DPWS τεχνολογία. Στο κεφάλαιο αυτό περιγράφουμε τρείς εναλλακτικές σχεδιάσεις του συστήματος, έχοντας ως δεδομένο ότι το σύστημα που θέλουμε να υλοποιήσουμε βασίζεται στην DPWS τεχνολογία. Στη συνεχεία για κάθε περιγραφή ακολουθεί αξιολόγηση καθώς και καταγραφή των προβλημάτων που διαπιστώθηκαν. Mετά την παρουσίαση των εναλλακτικών σχεδιάσεων, έχοντας ως κριτήριο τις απαιτήσεις σχεδίασης, παραθέτουμε μία σύγκριση. Τέλος έχοντας ως βάση αυτή τη σύγκριση για να επιλέξουμε ποίες από αυτές είναι κατάλληλες για να αποτελέσουν αντικείμενο υλοποίησης Προσέγγιση ως ολοκληρωμένο σύστημα Βιομηχανικού ελέγχου Όπως έχει αναφερθεί στο κεφάλαιο 3 η DPWS τεχνολογία αποτελεί έναν από του δομικούς λίθους για την κατασκευή βασισμένων στην υπηρεσιοστρεφή αρχιτεκτονική συστημάτων. Η υλοποίηση η οποία θα παρουσιαστεί σε επόμενες παραγράφους αποτελεί ένα τμήμα του ολοκληρωμένου συστήματος το οποίο θα δημιουργηθεί μελλοντικά. Τα μοντέλο κατασκευής στο οποίο θα βασίζεται το ολοκληρωμένο σύστημα είναι αυτό που προτείνεται από το πρόγραμμα SOCRADES και έχει παρουσιαστεί στο κεφάλαιο 2. Γνωρίζοντας ότι η συγκεκριμένη υλοποίηση θα αποτελέσει τμήμα ενός μεγαλύτερου συστήματος είναι χρήσιμο να αναφέρουμε σε πια τμήματα του συνολικού συστήματος αναφέρεται. Στο σχήμα 5.1Α παρουσιάζονται τα επίπεδα ενός συστήματος βιομηχανικού ελέγχου με βάση την σχεδίαση που προτείνει το έργο SOCRADES. Το σχήμα 5.1Β απεικονίζει την αντιστοίχιση τον συνιστωσών του 51

60 συστήματος υλοποίησης με τα επίπεδα του μοντέλου SOCRADES που αναπαριστώνται στο σχήμα 5.1Α. Το σχήμα 5.2 απεικονίζει το ίδιο σύστημα με το σχήμα 5.1Β με τη διαφορά ότι το σύστημα δεν περιλαμβάνει πραγματικές συσκευές στα κατώτερα επίπεδα αλλά χρησιμοποιεί εξομοιωτή για να προσομοιώσει την λειτουργία τους. Τα επίπεδα Device Networks και Device Level Middleware αντιστοιχούν στην υλοποίηση του εξομοιωτή Festo, την οποία παρουσιάζουμε στο κεφάλαιο 7. Το επίπεδο Device Layer Application Platform αναφέρεται στην διεπαφή η οποία μέσω της DPWS τεχνολογίας κάνει ορατές στο δίκτυο τις πραγματικές συσκευές ως DPWS συσκευές. Το επόμενο επίπεδο το οποίο ονομάζεται Enterprise Middleware αντιστοιχεί στην FestoControl εφαρμογή και περιλαμβάνει τις διαδικασίες έλεγχου. Τέλος σε αυτό το σημείο πρέπει να αναφέρουμε δεν θα παρουσιαστεί υλοποίηση που να αντιστοιχεί στο επίπεδο Enterprise application platform σε αυτή την εργασία αλλά προτείνεται ως αντικείμενο υλοποίησης σε μελλοντική εργασία. Σχήμα 5.1 Α. Επίπεδα συστήματος ελέγχου σύμφωνα με το πρότυπο του SOCRADES (πάνω αριστερά), B. Επίπεδα συστήματος ελέγχου της υλοποίησης μας πάνω στο πραγματικό σύστημα Festo MPS σύμφωνα με το πρότυπο του SOCRADES(πάνω δεξιά) 52

61 Σχήμα 5.2 Τα Επίπεδα συστήματος ελέγχου της υλοποίησης μας με τη χρήση εξομοιωτή αντί πραγματικού συστήματος σύμφωνα με το πρότυπο του SOCRADES 5.3. Απαιτήσεις σχεδίασης Κατά τη διαδικασία της σχεδίασης καλούμαστε να σχεδιάσουμε ένα σύστημα το οποίο βασίζεται στις συνιστώσες που παρουσιάζουμε στην παράγραφο 5.5 και το οποίο πρέπει να συμμορφώνεται με τον καλύτερο δυνατό τρόπο στις παρακάτω απαιτήσεις. Απαιτήσεις σχεδίασης του συστήματος 1. Βασισμένο την υπηρεσιοστρεφή αρχιτεκτονική(soa Based): Το σύστημα πρέπει να είναι σχεδιασμένο με βάση το υπηρεσιοστρεφές μοντέλο. Αυτό σημαίνει ότι η συνολική λειτουργία του συστήματος θα πρέπει να προκύπτει από τον συντονισμό ανεξάρτητων των λειτουργιών που προσφέρουν οι επιμέρους συνιστώσες του. 2. Δυνατότητα εύκολης προσαρμογής (Scalalability) και Επεκτασιμότητα : To σύστημα θα πρέπει να είναι σχεδιασμένο με τέτοιο τρόπο ώστε να μπορούμε εύκολα να προσθέσουμε ή να αφαιρέσουμε μονάδες λειτουργίας, χωρίς να χρειαστεί να αλλάξει ριζικά η κατασκευή του συνολικού συστήματος. 3. Αξιοπιστία: Οι ενέργειες οι οποίες εκτελούνται στα πλαίσια της λειτουργίας του πρέπει συστήματος να επιτελούνται χωρίς σφάλματα, ενώ το συνολικό σύστημα 53

62 πρέπει να εκτελεί του στόχους για τους οποίους σχεδιάστηκε για τη χρονική περίοδο την όποια είναι προγραμματισμένο να λειτουργεί. 4. Ταχύτητα: Ο σχεδιασμός του συστήματος θα πρέπει να γίνει με στόχο, οι λειτουργίες οι οποίες επιτελεί, να παρουσιάζουν την ελάχιστη δυνατή καθυστέρηση. Στα συστήματα βιομηχανικών αυτοματισμών η παράμετρος της ταχύτητας παίζει ιδιαίτερα σημαντικό ρόλο αφού πολλές από τις διαδικασίες οι οποίες εκτελούνται έχουν απαιτήσεις πραγματικού χρόνου Συνιστώσες του Συστήματος Στόχος μας είναι να σχεδιάσουμε το σύστημα με βάση την υπηρεσιοστρεφή αρχιτεκτονική η οποία είναι βασισμένη σε συνιστώσες (component based). Οι συνιστώσες από τις οποίες θα αποτελείται το σύστημα είναι οι DPWS συσκευές, οι υπηρεσίες (Services), τα Client Proxies, οι ελεγκτές (controllers ) και ο ενορχηστρωτής (orchestrator). 1. DPWS συσκευή Η DPWS συσκευή μπορεί να είναι είτε μια συσκευή με ενσωματωμένη DPWS δυνατότητα (DPWS enabled ) είτε μία DPWS διεπαφή η όποια επικοινωνεί μέσω προγραμμάτων οδηγών (drivers) με μία συσκευή η οποία δεν έχει DPWS δυνατότητες. Τέλος πρέπει να αναφέρουμε ότι η DPWS διεπαφή της συσκευής έχει το ρόλο του host για τις υπηρεσίες που προσφέρει η συσκευή. 2. Service Το Service φιλοξενείται σε μία DPWS συσκευή (hosted Service) και διαφημίζει στο δίκτυο τα Operations και τα Event Sinks τα οποία παρέχει η συσκευή. 3. Client Proxies Οι Client proxies βρίσκονται στην πλευρά της Client εφαρμογής και προσφέρουν πρόσβαση στα Operations που διαφημίζει μία συσκευή μέσω το μηχανισμού των απομακρυσμένων κλήσεων (remote procedure calls) και του μηχανισμού των εγγραφών (subscriptions). 4. Ελεγκτές Ως ελεγκτή ορίζουμε την οντότητα εκείνη η οποία παίρνει ως δεδομένα εισόδου, ειδοποιήσεις γεγονότων (event notifications) και ανάλογα με το προγραμματισμό της δίνει ως εξόδους, μηνύματα ελέγχου. Οι υλοποιήσεις του ελεγκτή μπορεί να διαφέρουν ανάλογα με τη σχεδίαση, η λειτουργία του όμως παραμένει η ίδια. Στις σχεδιάσεις και στις υλοποιήσεις που 54

63 παραθέτουμε όταν αναφερόμαστε σε ελεγκτές, εννοούμαι νήματα τα οποία λαμβάνουν ειδοποιήσεις και ανάλογα με τον προγραμματισμό τους «στέλνουν» τις κατάλληλες εντολές ελέγχου. Κάθε νήμα ελεγκτή είναι υπεύθυνο για την διαδικασία ελέγχου μόνο μίας DPWS συσκευής. Τέλος πρέπει να σημειωθεί ότι οι συγκεκριμένοι ελεγκτές δεν υλοποιούν κάποια διαδικασία μεταφοράς. Αντίθετα επικοινωνούν με τις συσκευές μέσω των μηχανισμών που προσφέρουν τα Client Proxies Προτεινόμενες σχεδιάσεις Έχοντας ως δεδομένες τις βασικές συνιστώσες του συστήματος και προσπαθώντας την όσο το δυνατόν βέλτιστη επίτευξη των στόχων σχεδίασης, παρουσιάζουμε τρείς εναλλακτικές σχεδιάσεις,οι οποίες θα μπορούσαν να αποτελέσουν βάση για την υλοποίηση του συστήματος Κατανεμημένος απομακρυσμένος έλεγχος Στη πρώτη σχεδίαση θέλοντας να μεγιστοποιήσουμε το βαθμό χρήσης της υπηρεσιοστρεφής αρχιτεκτονικής καταλήξαμε στην σχεδίαση που φαίνεται στο σχήμα 5.3. Σε αυτή την σχεδίαση θεωρούμε ότι οι ελεγκτές μιας DPWS συσκευής αποτελούν ανεξάρτητες οντότητες οι οποίες παίρνουν ειδοποιήσεις γεγονότων ως εισόδους και δίνουν εντολές ελέγχου ως εξόδους. Το ανάλογο αυτής της σχεδίασης από πλευράς hardware θα ήταν να είχαμε διάφορα Units τα οποία συνδέονταν με ένα προσωπικό ελεγκτή (πχ PLC) και όλοι οι προσωπικοί ελεγκτές θα συνδέονταν σε ένα κεντρικό ελεγκτή o οποίος θα ήταν υπεύθυνος για την ενορχήστρωση. Μειονεκτήματα To μειονέκτημα αυτής της προσέγγισης παρουσιάζεται στην ταχύτητα. Η ανταλλαγή μηνυμάτων μεταξύ των συνιστωσών Controller και Controller Orchestrator προσθέτει καθυστέρηση στο σύστημα. Αυτό συμβαίνει επειδή κάθε μήνυμα πρέπει να μεταφερθεί μέσω του δικτύου τουλάχιστον δύο φορές μέχρι να φτάσει στον τελικό προορισμό του. Επειδή όμως το πεδίο εφαρμογής της σχεδίασης είναι οι ενσωματωμένες συσκευές που συμμετέχουν σε βιομηχανικές διαδικασίες, η μεγάλη καθυστέρηση που εισάγει αυτή η σχεδίαση την καθίστα απαγορευτική Κεντρικός απομακρυσμένος ενορχηστρωτής Ένα πολύ σημαντικό μειονέκτημα της DPWS τεχνολογίας όπως αναφέραμε στο κεφάλαιο 3 είναι ο μεγάλος χρόνος αποστολής μηνύματος από την DPWS συσκευή στον πελάτη. Η σχεδίαση με κεντρικό απομακρυσμένο ενορχηστρωτή, αν και μειώνει τον κατανεμημένο χαρακτήρα της εφαρμογής, βοηθά στην εξοικονόμηση 55

64 πόρων δικτύου και επιτυγχάνει σημαντικές αυξήσεις στην ταχύτητα απόκρισης του συστήματος. Σχήμα 5.3 Διάγραμμα συνιστωσών με κατανεμημένο απομακρυσμένο έλεγχο. Όσον αφορά το χρόνο απόκρισης η μεγαλύτερη καθυστέρηση στη συγκεκριμένη σχεδίαση συναντάται στην επικοινωνία μεταξύ Client και DPWS συσκευής, η οποία γίνεται μέσω του δικτυού με τη χρήση του SOAP πρωτοκόλλου. Αυτό συμβαίνει επειδή η διαδικασία ελέγχου γίνεται από την πλευρά του ενορχηστρωτή σε αντίθεση με τη διαδικασία ελέγχου που παρουσιάστηκε στο κεφάλαιο 5.5.1, η οποία γίνεται κατανεμημένα. Ο ρόλος του ενορχηστρωτή σε αυτή την περίπτωση είναι ενισχυμένος καθώς είναι υπεύθυνος για τον συντονισμό των επιμέρους 56

65 διαδικασιών ελέγχου της κάθε συσκευής καθώς επίσης και για το συντονισμό της συνολικής διαδικασίας. Η απεικόνιση της συγκεκριμένης σχεδίασης για την περίπτωση που το σύστημα περιλαμβάνει μόνο δύο συσκευές (units) παραθέτεται στο σχήμα 5.4. Σχήμα 5.4 Διάγραμμα UML συνιστωσών σχεδίασης με κεντρικό απομακρυσμένο ενορχηστρωτή 57

66 Μειονεκτήματα Το μειονέκτημα αυτής της σχεδίασης είναι ότι ο έλεγχος γίνεται αποκλειστικά απομακρυσμένα ενώ σε πολλές περιπτώσεις μπορεί να αποφευχθεί. Η συγκεκριμένη διαδικασία ελέγχου αν και είναι βελτιωμένη σε σχέση με την σχεδίαση που παρουσιάστηκε στο κεφάλαιο εξακολουθεί να έχει υψηλό κόστος τόσο από πλευράς πόρων του δικτύου όσο και από πλευράς χρόνου απόκρισης. Το μεγάλο κόστος σε πόρους προκύπτει από τον μεγάλο μέγεθος των SOAP μηνυμάτων και από τον μεγάλο αριθμό των διαδικασιών αναζήτησης, οι οποίες όπως έχουμε αναφέρει στο κεφάλαιο 3 έχουν πολύ υψηλό κόστος από πλευράς φόρτου δικτυού. Επίσης πρέπει να αναφερθεί ότι κάθε εγγραφή ( subscription ) απασχολεί ένα αποκλειστικό TCP κανάλι, κάτι το οποίο συμβάλει στο φόρτο του δικτύου. Προχωρώντας σε περεταίρω ανάλυση του προβλήματος συμπεραίνουμε η μεγάλη χρονική καθυστέρηση βασίζεται σε δύο παράγοντες: πρώτον το χρόνο μετάδοσης των μεγάλων SOAP μηνυμάτων και δεύτερον στην επανάληψη της αποστολής ενός μηνύματος στην περίπτωση αποτυχίας αποστολής του. Ο δεύτερος παράγοντας ο οποίος αναφέραμε έχει και μία δεύτερη επίπτωση η οποία προκαλεί ένα πιο σημαντικό πρόβλημα από την καθυστέρηση. Το πρόβλημα αυτό είναι η αναδιάταξη της ακολουθίας των εντολών ελέγχου και των ειδοποιήσεων γεγονότων Ειδικά προβλήματα του κεντρικού απομακρυσμένου ενορχηστρωτή και προτάσεις αντιμετώπισης Ο συγκεκριμένος τρόπος σχεδίασης εκτός από τα ζητήματα που αφορούν την μειωμένη απόδοση, εισάγει και μία σειρά από προβλήματα τα οποία επηρεάζουν την αξιοπιστία του συστήματος. Τα προβλήματα αυτά είναι: A. H αναδιάταξη της ακολουθίας των εντολών και των ειδοποιήσεων γεγονότων. B. Η ασύγχρονη λήψη ειδοποιήσεων από πελάτες που εγγράφονται στο ίδιο γεγονός. Στη συνέχεια θα περιγράψουμε περεταίρω τις αιτίες και τα σφάλματα που μπορεί να προκαλέσουν αυτά τα προβλήματα και θα προτείνουμε λύσεις για την αντιμετώπιση τους. 58

67 A. Αναδιάταξη της ακολουθίας των εντολών και των ειδοποιήσεων γεγονότων Λόγω της σοβαρότητας του, αυτό το πρόβλημα αξίζει να αναλυθεί εκτενώς. Σύμφωνα με τις προδιαγραφές του DPWS, στο επίπεδο μεταφοράς των μηνυμάτων μέσω του δικτύου χρησιμοποιούμε το TCP πρωτόκολλο. Το TCP πρωτόκολλο στην περίπτωση που ένα πακέτο χαθεί, επαναλαμβάνει την αποστολή μέχρι να φτάσει επιτυχώς στον προορισμό του. Αυτό σημαίνει πως αν σταλούν δύο μηνύματα το ένα αμέσως μετά το άλλο, αν υπάρξει αποτυχία αποστολής του πρώτου και επανάληψη, τότε θα μεταβληθεί η σειρά αποστολής αφού το δεύτερο μήνυμα θα φτάσει στον προορισμό του νωρίτερα από το πρώτο. Αυτή η συμπεριφορά δημιουργεί προβλήματα στο βασισμένο στο DPWS σύστημα που ακολουθεί την συγκεκριμένη σχεδίαση, καθώς ένα σύστημα ελέγχου μίας γραμμής παραγωγής βασίζεται στην αυστηρή ακολουθία εντολών και μία οποιαδήποτε αλλαγή στην σειρά θα μπορούσε να προκαλέσει σημαντικές ζημιές. Προτάσεις Η στοίβα αναμενόμενου γεγονότος είναι μία δομή την οποία σχεδιάσαμε με σκοπό την αντιμετώπιση του προβλήματος της αναδιάταξης της ακολουθίας των εντολών και των ειδοποιήσεων γεγονότων. Η στοίβα αναμενόμενου γεγονότος παρεμβάλλεται μεταξύ της DPWS διεπαφής και της διαδικασίας αποστολής των εντολών στην πραγματική συσκευή καθώς και μεταξύ του DPWS πελάτη και του νήματος ελέγχου. Ο ρόλος αυτής της δομής είναι να εμποδίζει την λήψη μηνυμάτων, αν αυτά δεν φτάνουν στο προορισμό τους με τη σωστή χρονική σειρά. Η λογική της στοίβας αναμενόμενου γεγονότος η οποία φαίνεται και σχηματικά στο διάγραμμα ροής του σχήματος 5.5 είναι η εξής: Σε κάθε ειδοποίηση γεγονότος την οποία στέλνει μία DPWS συσκευή δίνεται ένας αριθμός,τον οποίο ονομάζουμε αριθμό ειδοποίησης γεγονότος της συσκευής, και αυτός ο αριθμός στέλνεται μαζί με την ειδοποίηση στον πελάτη o οποίος έχει εγγραφεί. Ο αριθμός αυτός είναι ένας ακέραιος ο οποίος δείχνει της σειρά με την οποία συνέβη το κάθε γεγονός. Στην πλευρά του Client οι ειδοποιήσεις των γεγονότων οι οποίες παραλαμβάνονται μέσω του κάθε Client Proxy κάθε DPWS συσκευής τοποθετούνται στην στοίβα αναμενόμενου γεγονότος. Η στοίβα αναμενόμενου γεγονότος είναι μία κλάση επόπτης (monitor), η οποία διαθέτει μία εσωτερική στοίβα και έναν μετρητή. Ο μετρητής περιέχει τον αριθμό ειδοποίησης γεγονότος που αναμένουμε να στείλει η συσκευή. Όσο η ειδοποίηση που έχει τον αναμενόμενο αριθμό γεγονότος δεν εντοπίζεται στην στοίβα, δεν επιτρέπει να σταλεί η επόμενη ιδιοποίηση στον ελεγκτή της συσκευής,δηλαδή ο ελεγκτής βρίσκεται σε κατάσταση Wait. Όταν σταλεί νέα ειδοποίηση στην στοίβα γίνεται έλεγχος αν υπάρχει ειδοποίηση με τον αναμενόμενο αριθμό στην στοίβα, και αν υπάρχει στέλνεται στον κατάλληλο ελεγκτή. Με αυτόν τον τρόπο η 59

68 ακολουθία των μηνυμάτων ελέγχεται και αναδομείται στη περίπτωση που έχουν υπάρξει αναδιατάξεις. Τέλος πρέπει να σημειώσουμε ότι αυτή η δομή μπορεί να εφαρμοστεί με ανάλογο τρόπο για να ελέγξουμε και την ακολουθία των μηνυμάτων ελέγχου που στέλνει ο ελεγκτής στη DPWS συσκευή. Σχήμα 5.5 διάγραμμα ροής της διεργασίας που εκτελείτε όταν ένας ελεγκτής ζητά το επόμενο μήνυμα. Το διάγραμμα αναπαριστά την λειτουργία της εξωτερικής στοίβας αναμενόμενου γεγονότος B. Ασύγχρονη λήψη ειδοποιήσεων από πελάτες που εγγράφονται στο ίδιο γεγονός Το πρόβλημα αυτό αναφέρεται στα σφάλματα τα οποία μπορεί να συμβούν στην περίπτωση που δύο ή παραπάνω διαφορετικοί πελάτες εγγραφούν στην ίδια πηγή γεγονότων (event Source). Στην περίπτωση αυτή επειδή η μετάδοση γίνεται με τη χρήση του TCP πρωτοκόλλου οι ειδοποιήσεις θα φτάσουν με μία χρονική διαφορά. Η διαφορά αυτή, επειδή αναφερόμαστε σε συστήματα στα οποία λειτουργούν παράλληλα πολλές διαφορετικές συσκευές, μπορεί να προκαλέσει σφάλματα στην 60

69 λειτουργία του συστήματος. Αυτά τα σφάλματα εστιάζονται στο γεγονός ότι όταν κατασκευάζουμε συστήματα που υλοποιούν κάποια μορφή ελέγχου αναμένουμε ότι όταν συμβεί ένα γεγονός θα το αναληφθούν ταυτόχρονα όλες οι συσκευές οι οποίες έχουν κάποια εξάρτηση από αυτό. Στη συγκεκριμένη όμως περίπτωση αυτό δεν συμβαίνει με αποτέλεσμα π.χ. μία συσκευή, της οποίας ο ελεγκτής αντιλαμβάνεται ένα γεγονός, μπορεί να ξεκινήσει μία σειρά από ενέργειες, ενώ μια άλλη η οποία θα έπρεπε να δράσει παράλληλα να μην το έχει αντιληφθεί λόγω της καθυστέρησης. Αποτέλεσμα αυτού είναι να παρουσιαστεί έλλειψη συντονισμού μεταξύ των δύο συσκευών. Προτάσεις Για να αντιμετωπιστεί αυτό το πρόβλημα θα πρέπει κάθε γεγονός που συμβαίνει σε μία συσκευή να στέλνει μία ειδοποίηση στη πλευρά του Service Client. Στη συνέχεια η ειδοποίηση των επιμέρους ελεγκτών για το γεγονός θα πρέπει να γίνεται προγραμματιστικά από τον ίδιο το Client ή από κάποια συνιστώσα του συστήματος η οποία θα βρίσκεται στην πλευρά του Client και η οποία θα αναλαμβάνει να μεταφέρει τα μηνύματα από τον Service Client στους ελεγκτές. Με αυτό τον τρόπο οι ελεγκτές ειδοποιούνται ταυτόχρονα αφού η διαδικασία ειδοποίησης πραγματοποιείται χωρίς να παρεμβάλλεται το δίκτυο το οποίο εισάγει απρόβλεπτες καθυστερήσεις Κεντρικός απομακρυσμένος ενορχηστρωτής με τοπικό έλεγχο Λόγω του μεγάλου μεγέθους από πλευράς όγκου δεδομένων των SOAP φακέλων, καταλαβαίνουμε ότι η ανταλλαγή μηνυμάτων μεταξύ SOAP συνιστωσών είναι μία διαδικασία η οποία έχει πολύ υψηλό κόστος τόσο χρονικό όσο και σε πόρους του δικτύου. Αυτό σημαίνει ότι αν θέλουμε να πετύχουμε μέγιστη απόδοση πρέπει να μειώσουμε στο ελάχιστο την ανταλλαγή μηνυμάτων μέσω δικτύου εισάγοντας τοπικό έλεγχο όπου είναι εφικτό. Πρέπει όμως παράλληλα και να διατηρήσουμε την επικοινωνία μέσω SOAP μηνυμάτων μόνο σε επίπεδο ενορχήστρωσης των διαφορετικών συσκευών. Αυτό σημαίνει ότι μία συσκευή θα έχει έναν τοπικό ελεγκτή ο οποίος θα είναι υπεύθυνος για τις εσωτερικές διαδικασίες ελέγχου. Παράλληλα ένα τμήμα του ελέγχου, το οποίο αφορά το συντονισμό και την ενορχήστρωση μεταξύ των διεργασιών που πραγματοποιεί η κάθε ανεξάρτητη συσκευή, θα πραγματοποιείται απομακρυσμένα μέσω των Web Services με τη χρήση απομακρυσμένου ενορχηστρωτή. Αυτή η αρχιτεκτονική ορίζει δύο βρόχους ελέγχου(control loops): A. Ο τοπικός βρόχος ελέγχου φαίνεται στο σχήμα 5.6 και δημιουργείται μεταξύ συσκευής και τοπικού ελεγκτή (Local Control). 61

70 B. Ο βρόχος απομακρυσμένου ελέγχου φαίνεται στο σχήμα 5.6 και δημιουργείται μεταξύ συσκευής και απομακρυσμένου ενορχηστρωτή (remote orchestrator). Σχήμα 5.6 Αναπαράσταση των βρόχων ελέγχου της σχεδίασης A. Τοπικός βρόχος ελέγχου O τοπικός βρόχος ελέγχου αναπαριστά τις εσωτερικές διαδικασίες ελέγχου της συσκευής. Ο έλεγχος αυτός αφορά τα εξαρτήματα της συσκευής των οποίων η συμπεριφορά εξαρτάται μόνο από παραμέτρους της ίδιας της συσκευής και όχι από τη συμπεριφορά των εξωτερικών συσκευών. Χαρακτηριστικό αυτού του βρόχου είναι ότι οι διαδικασίες ελέγχου πραγματοποιούνται με πολύ μικρή χρονική καθυστέρηση. Ο βρόχος εσωτερικού ελέγχου δημιουργείται ανάμεσα στην συσκευή και σε έναν τοπικό ελεγκτή ο οποίος είναι ενσωματωμένος στην συσκευή, ο ελεγκτής αυτός μπορεί να είναι για παράδειγμα κάποιος προγραμματιζόμενος λογικός ελεγκτής (PLC) οποίος βρίσκεται ενσωματωμένος στη συσκευή. Ο τοπικός ελεγκτής λαμβάνει σαν εισόδους τα γεγονότα της συσκευής και επιστρέφει στην συσκευή μηνύματα ελέγχου. Με τη χρήση του τοπικού ελεγκτή στοχεύουμε σε μείωση της καθυστέρησης του βρόγχου έλεγχου, συνεπώς το βασικό ζητούμενο για τον τοπικό ελεγκτή είναι η ταχύτητα με τη μορφή της ελαχιστοποίησης του χρόνου απόκρισης. 62

71 B. Βρόχος απομακρυσμένου ελέγχου O συγκεκριμένος βρόχος αφορά την επικοινωνία και την ενορχήστρωση μεταξύ διαφορετικών συσκευών. Ειδικότερα αφορά τα μηνύματα συντονισμού των επιμέρους συσκευών ενός συστήματος και χαρακτηριστικό αυτού του βρόχου είναι ότι παρουσιάζει μεγάλη καθυστέρηση, επομένως δεν πρέπει να εκτελείται με μεγάλη συχνότητα. Ο βρόχος απομακρυσμένου ελέγχου δημιουργείται ανάμεσα στην συσκευή και την εφαρμογή ενορχήστρωσης όπως φαίνεται στο σχήμα 5.7. Σε αυτό το σημείο πρέπει να αναφέρουμε ότι οι τοπικοί ελεγκτές του συστήματος όπως παρουσιάζεται στο σχήμα 5.7 περιλαμβάνονται στη συνιστώσα Service Orchestration. Κάθε συσκευή είναι ορατή στο δίκτυο μέσω της DPWS διεπαφής ως DPWS συσκευή. Η πραγματική συσκευή στέλνει ειδοποιήσεις στον τοπικό ελεγκτή σε πρώτο στάδιο και αν ο ελεγκτής αφού εκτελέσει εσωτερικούς ελέγχους κρίνει ότι είναι απαραίτητο, μεταφέρει μέσω του μηχανισμού διαχείρισης ειδοποιήσεων που προσφέρει το DPWS, την ειδοποίηση για το γεγονός στον ενορχηστρωτή. Σε επόμενο στάδιο όταν η εφαρμογή ενορχήστρωσης και απομακρυσμένου ελέγχου λάβει μία ειδοποίηση ανταποκρίνεται καλώντας τα κατάλληλα operations της συσκευής ανάλογα με τον προγραμματισμό της. Μειονεκτήματα Η συγκεκριμένη σχεδίαση λόγω ακριβώς του τοπικού έλεγχου που χρησιμοποιεί περιορίζει το «εύρος» του ελέγχου που μπορούμε να ασκήσουμε απομακρυσμένα μέσω των Web Services. Λόγω της μορφής του ελέγχου μερικές από τις μεθόδους τις οποίες χρησιμοποιούνται από τον τοπικό ελεγκτή δεν είναι διαθέσιμες για απομακρυσμένη κλήση. Αυτό έχει ως αποτέλεσμα να μην έχουμε ολοκληρωμένη πρόσβαση στις λειτουργίες και στις πηγές γεγονότων της συσκευής. Μια πρώτη λύση για αυτό το πρόβλημα θα ήταν να ορίσουμε αυτές τις μεθόδους τις οποίες χρησιμοποιεί ο τοπικός ελεγκτής ως Operations τα οποία είναι ορατά και σαν μέθοδοι των ήδη υπαρχόντων Web Services ώστε να έχουμε πρόσβαση σε αυτά και απομακρυσμένα. Ο σχεδιασμός αυτός όμως κάνει το σύστημα ευάλωτο σε σφάλματα αφού οι εξωτερικές κλίσεις έχουν άμεσο αντίκτυπο στις διαδικασίες τοπικού ελέγχου οι οποίες εκτελούνται με μια αυστηρή ακολουθία. Αποτέλεσμα αυτής της παρεμβολής είναι να σημειωθούν σφάλματα στο τοπικό βρόχο ελέγχου. Αυτή η πρόταση με βάση την ανάλυση που έγινε εισάγει προβλήματα και επομένως δεν θα υιοθετηθεί. 63

72 Σχήμα 5.7 Αριστερά βρόχος τοπικού ελέγχου, Δεξιά βρόχος απομακρυσμένου ελέγχου. 64

73 5.6. Σύγκριση Η σχεδίαση με κατανεμημένο απομακρυσμένο έλεγχο μεγιστοποιεί την επαναχρησιμοποίηση (reusability) και δυνατότητα εύκολης προσαρμογής (Scalability) του συστήματος, αφού η είσοδος ή η έξοδος οποιασδήποτε συσκευής από το σύστημα έχει ως αποτέλεσμα να αφαιρεθεί ή να προστεθεί στο σύστημα ο αντίστοιχος ελεγκτής. Αποτέλεσμα αυτού είναι η συγκεκριμένη σχεδίαση να υπερτερεί σαν μοντέλο σχεδιασμού από τις υπόλοιπες όσον αφορά το κόστος επέκτασης. Όμως ο κατανεμημένος χαρακτήρας της, έχει ως αποτέλεσμα η διαδικασία ανταλλαγής μηνυμάτων να είναι ιδιαίτερα υψηλή σε κόστος αφού κάθε μήνυμα πρέπει να μεταδοθεί μέσω του δικτύου τουλάχιστον δύο φόρες. Ως αποτέλεσμα αυτού προκύπτει ότι οι χρόνοι εκτέλεσης των επιμέρους λειτουργιών αναμένεται να είναι πολύ μεγάλοι. Λαμβάνοντας υπόψη ότι το σύστημα το οποίο καλούμαστε να υλοποιήσουμε απευθύνεται σε βιομηχανικές εφαρμογές οι οποίες συνήθως έχουν απαιτήσεις πραγματικού χρόνου, ενώ παράλληλα η υπολογιστική τους ισχύ είναι περιορισμένη, συμπεραίνουμε ότι αυτή η σχεδίαση δεν είναι κατάλληλη για τέτοιου είδους εφαρμογές. Η σχεδίαση με απομακρυσμένο ενορχηστρωτή εφαρμόζει και αυτή το υπηρεσιοστρεφές μοντέλο, είναι όμως λιγότερο κατανεμημένη από την πρώτη σχεδίαση. Όσον αφορά τις απαιτήσεις εύκολης προσαρμογής (Scalability) και επεκτασιμότητας, αυτές πληρούνται σε ικανοποιητικό βαθμό, όμως σε αυτή τη σχεδίαση η είσοδος μίας νέα συσκευής στο σύστημα θα επιφέρει αλλαγές και στην υλοποίηση του κεντρικού ενορχηστρωτή, κάτι το οποίο δεν αποτελούσε ζήτημα στη σχεδίαση με κατανεμημένο απομακρυσμένο έλεγχο. Όσον αφορά την αξιοπιστία όπως αναφέρθηκε στην παράγραφο 5.5.3, η συγκεκριμένη σχεδίαση εισάγει προβλήματα. Όμως αν στο σύστημα εισάγουμε τις κατάλληλες υλοποιήσεις των προτάσεων που προτείνουμε τότε η αξιοπιστία δεν επηρεάζεται. Όσον αφορά τις απαιτήσεις ταχύτητας, εξακολουθούμε να έχουμε χαμηλές επιδόσεις χωρίς όμως οι χρόνοι να είναι απαγορευτικοί όπως γινόταν στη σχεδίαση με κατανεμημένο απομακρυσμένο έλεγχο. Αυτό συμβαίνει διότι κάθε μήνυμα θα μεταδοθεί τουλάχιστον μία φορά σε αντίθεση με την πρώτη σχεδίαση έτσι ο χρόνο εκτέλεσης κάθε λειτουργίας είναι μειωμένος. Η σχεδίαση με απομακρυσμένο ενορχηστρωτή ικανοποιεί επαρκώς τις απαιτήσεις σχεδίασης χωρίς να αποτελεί τη βέλτιστη λύση. Προσφέρει όμως μέγιστη πρόσβαση στις λειτουργίες τις συσκευής και επομένως προσφέρεται για περιπτώσεις δοκιμών και ανάπτυξης συστημάτων επίδειξης και γενικότερα σε περιπτώσεις όπου δεν υπάρχουν απαιτήσεις πραγματικού χρόνου. Η σχεδίαση με κεντρικό απομακρυσμένο ενορχηστρωτή με τοπικό έλεγχο αποτελεί βελτίωση της σχεδίασης με κεντρικό απομακρυσμένο ενορχηστρωτή διότι διατηρεί όλα τα πλεονεκτήματα της, ενώ παράλληλα προσφέρει βελτιώσεις στο τομέα της ταχύτητας. Οι βελτιώσεις αυτές προκύπτουν από το γεγονός ότι η 65

74 μεταφορά μηνυμάτων από την DPWS συσκευή στον ενορχηστρωτή γίνεται μόνο για τα μηνύματα που αφορούν την διαδικασία συντονισμού του συνολικού συστήματος. Αυτό σημαίνει ότι μεγάλο μέρος των μηνυμάτων ελέγχου καθώς και των ειδοποιήσεων δεν θα μεταδοθεί ποτέ μέσω του δικτυού αλλά θα υποστεί διαχείριση από τον τοπικό ελεγκτή. Έτσι η ιδιαίτερα υψηλού κόστους μεταφορά μηνυμάτων μέσω του δικτύου μειώνεται στο ελάχιστο και η συνολική διαδικασία ελέγχου είναι ταχύτερη αφού μέρος των λειτουργιών της γίνεται τοπικά. Από τα παραπάνω συμπεραίνουμε συγκεκριμένη σχεδίαση προσφέρει ικανοποιητικές αποδόσεις και θετικά χαρακτηριστικά και μπορεί να χρησιμοποιηθεί για την υλοποίηση εφαρμογών βιομηχανικού ελέγχου σε συστήματα τα οποία παρουσιάζουν απαιτήσεις πραγματικού χρόνου. 66

75 Κεφάλαιο 6 Κλάσεις του συστήματος και εργαλεία υλοποίησης 6.1. Εισαγωγή Η DPWS τεχνολογία έχει αποτελέσει αντικείμενο έρευνας πολλών οργανισμών τόσο του επιχειρησιακού όσο και του ακαδημαϊκού κλάδου καθώς και αντικείμενο μελέτης αρκετών ευρωπαϊκών έργων. Αποτέλεσμα αυτού είναι να διατίθεται μία ευρεία γκάμα εργαλείων ανάπτυξης και βιβλιοθηκών για την υλοποίηση εφαρμογών. Στα πλαίσια αυτού του κεφαλαίου παραθέτουμε μια σύντομη ανάλυση των διαθέσιμων εργαλείων που προσφέρει η WS4D πρωτοβουλία. Με βάση αυτή την ανάλυση επιλέξαμε τα εργαλεία τα οποία ικανοποιούν καλύτερα την ανάγκες του συστήματος μας. Για την κατασκευή αυτών των υλοποιήσεων του συστήματος επιλέχτηκε ως γλώσσα προγραμματισμού η Java και χρησιμοποιήθηκε η εργαλειοθήκη WS4D- JMEDS. Σε αυτό το σημείο πρέπει να αναφέρουμε ότι αν και οι βασικές απαιτήσεις της υλοποίησης καλύπτονται από την WS4D-JMEDS εργαλειοθήκη, παράλληλα με τις κλάσεις και τις διεπαφές που παρέχει, κατασκευάστηκαν και προσαρμοσμένες κλάσεις ( custom classes) για την υλοποίηση λειτουργιών τις οποίες δεν καλύπτει το WS4D- JMEDS. Με σκοπό την καλύτερη κατανόηση της λειτουργίας του συνολικού συστήματος που υλοποιήθηκε και την εξήγηση των επιμέρους λειτουργιών του, στις επόμενες παραγράφους παραθέτουμε μία σύντομη ανάλυση των σημαντικότερων κλάσεων και διεπαφών που χρησιμοποιήθηκαν κατά την υλοποίηση Διαθέσιμες DPWS εργαλειοθήκες από την WS4D πρωτοβουλία Η WS4D πρωτοβουλία έχει αναπτύξει μια σειρά από εργαλειοθήκες οι οποίες χρησιμοποιούνται για την ανάπτυξη εφαρμογών με βάση στην DPWS τεχνολογία, ενώ παρουσιάζουν πολύ διαφορετικά χαρακτηριστικά [6]. Κάθε μια από αυτές τις εργαλειοθήκες αν και έχει ως βάση την DPWS τεχνολογία είναι προσανατολισμένη ώστε να ικανοποιεί διαφορετικού τύπου ανάγκες. 67

76 WS4D-gSOAP To WS4D-gSOAP αποτελεί μια επέκταση γνωστού εργαλείου ανάπτυξης Web Services το οποίο βασίζεται στις γλώσσες προγραμματισμού c και c++. Το εργαλείο αυτό ονομάζεται gsoap και αυτό αποτελείται από ένα περιβάλλον ανάπτυξης και ένα περιβάλλον runtime. To gsoap εργαλείο έχει ορίσει τη δική του γλώσσα περιγραφής των Web Services η οποία βασίζεται στην σύνταξη της γλώσσας C. Οι περιγραφές που κατασκευάζουμε με το εργαλείο αποθηκεύονται σε ειδικά gsoap αρχεία παρόμοια με τα header files της που χρησιμοποιούνται από την γλώσσα C. Για να προσφέρει ολοκληρωμένη διαδικασία σχεδίασης βασισμένων σε Web Service εφαρμογών, η εργαλειοθήκη προσφέρει και ένα εργαλείο παραγωγής κώδικα ο οποίος μετατρέπει τα WSDL αρχεία σε gsoap αρχεία. Αυτό το εργαλείο δημιουργεί συνδέσεις δεδομένων (data bindings) μεταξύ της βασισμένης σε XML-Schema αναπαράστασης των δεδομένων του WSDL και των δομών δεδομένων της C δημιουργώντας έτσι τις κατάλληλες συναρτήσεις για τη μετατροπή των δεδομένων από τη μία μορφή στην άλλη. Επίσης αυτό το εργαλείο είναι υπεύθυνο για τη δημιουργία του «σκελετού» του κώδικα (skeleton code ) στην πλευρά του εξυπηρετητή και την δημιουργία των εκπροσώπων (Stubs) από την πλευρά του Client ώστε να αντιστοιχηθούν τα Operations που περιγράφει το WSDL σε συναρτήσεις της C. Η διαδικασία παραγωγής κώδικα αναπαριστάται σχηματικά παρακάτω στο διάγραμμα του σχήματος 6.1. Σχήμα 6.1 WS4D-g SOAP ροη της διαδικασίας παραγωγής κώδικα [10] Η WS4D-gSOAP εργαλειοθήκη χρησιμοποιεί τον μηχανισμό των προσθέτων (plug-ins) που προσφέρει η gsoap εργαλειοθήκη για να επεκτείνει την λειτουργία της ώστε να ανταποκρίνεται και στις νέες προδιαγραφές που προκύπτουν από τη DPWS προδιαγραφή (WS-Addressing,WS-Discovery, WS-MetadataExchange / WS- 68

77 Transfer,WS-Eventing). Μια γραφική απεικόνιση όλης της εργαλειοθήκης με τα προσθετά που περιγράψαμε παραπάνω δίνεται στο παρακάτω σχήμα 62. Σχήμα 6.2 WS4D-g SOAP toolkit Όπως φαίνεται και στο σχήμα 6.2 η εργαλειοθήκη gsoap δέχεται ως «εισόδους» WSDL αρχεία που περιέχουν τις δηλώσεις των Web Services και τα μετατρέπει σε gsoap αρχεία με βάση το μηχανισμό που περιγράψαμε. H WS4D-gSOAP ακολουθεί την ιδία αρχή λειτουργιάς. Για να δημιουργήσει ο προγραμματιστής μία DPWS συσκευή πρέπει πρώτα να ορίσει μία WSDL περιγραφή των Web Services που προσφέρει η συσκευή καθώς και τα Μετα-δεδομένα της συσκευής. Τα Μεταδεδομένα της συσκευής χρησιμοποιούνται για να δημιουργήσουν κώδικα ο οποίος θα χρησιμοποιηθεί για την αρχικοποίηση και ανάθεση των Μετα-Δεδομένων του μοντέλου και των χαρακτηριστικών της συσκευής WS4D-uDPWS Η WS4D-uDPWS υλοποίηση του DPWS, έχει ως στόχο την υλοποίηση συστημάτων ενσωματωμένων συσκευών τα οποία βασίζονται σε ασύρματους κόμβους αισθητήρων [15]. Αυτά τα συστήματα χαρακτηρίζονται από πολύ μεγάλους περιορισμούς όσον αφορά τους πόρους μνήμης, υπολογιστικής ισχύς και εύρους ζώνης. Το udpws στοχεύει σε δίκτυα τα οποία χρησιμοποιούν το 6LoWPAN [16] πρωτόκολλο. Αυτή τη στιγμή η ομάδα ανάπτυξης του udpws στοχεύει στη δημιουργία ενός πρωτοτύπου το οποίο θα επιτρέπει στα 6LoWPAN ασύρματα δίκτυα να χρησιμοποιούν και να παρέχουν DPWS λειτουργίες. Συμφώνα με τη ιστοσελίδα της WS4D πρωτοβουλίας, η υλοποίηση της εργαλειοθήκης θα είναι διαθέσιμη σύντομα WS4D-Axis2 Η WS4D-Axis2 DPWS εργαλειοθήκη είναι βασισμένη στο Axis 2.Το Axis 2 είναι ένα έργο (Project) από την Apache Software Foundation το οποίο προσφέρει έναν SOAP 69

78 Server καθώς και άλλα εργαλεία για την ανάπτυξη Web Services. Σε αυτό το σημείο πρέπει να αναφέρουμε ότι αυτά τα εργαλεία χρησιμοποιούνται ευρέως στο χώρο των επιχειρησιακών εφαρμογών. To Axis 2 υποστηρίζει τις εκδόσεις SOAP 1.1 και SOAP 1.2 καθώς και υποστηρίζει τη μεταφορά πάνω από διάφορα πρωτόκολλα όπως τα HTTP,TCP, JMS και SMTP. Το έργο αυτό έχει ενσωματωμένη μόνο την υλοποίηση της WS-Addressing προδιαγραφής των Web Services, η αρθρωτή του όμως κατασκευή επιτρέπει την επέκταση του με υλοποιήσεις των προδιαγραφών που θέλουμε να προσθέσουμε. Με αυτό τον τρόπο μπορούμε να προσθέσουμε και μία υλοποίηση της DPWS προδιαγραφής καθώς και των υπόλοιπων WS-* προδιαγραφών [13]. Χρησιμοποιώντας τη WS4D Axis 2 εργαλειοθήκη μπορούμε να υλοποιήσουμε την DPWS αρχιτεκτονική χωρίς να εγκαταλείψουμε εργαλεία και λύσεις οι οποίες ήδη υπάρχουν και είναι ευρέως διαδεδομένες σε επίπεδο επιχειρήσεων (enterprise level ), αυξάνοντας έτσι τη συμβατότητα των DPWS εφαρμογών. Το WS4D-Axis 2 λειτουργεί πάνω στη Java Standard Edition και αυτό το κάνει ακατάλληλο για χρήση πάνω σε ενσωματωμένες συσκευές, όμως η μεγάλη συμβατότητα με τις υπάρχουσες βασισμένες σε Web Sevices (Web Service based) υποδομές το κάνουν ιδανικό για την ανάπτυξη εφαρμογών ελέγχου και ενορχήστρωσης από την πλευρά του Client WS4D-JCoap Το JCoap είναι μία εφαρμογή του Πρωτοκόλλου περιορισμένων εφαρμογών Constrained Application Protocol (CAP)[11] για την Java. Το Πρωτόκολλο περιορισμένων εφαρμογών είναι ένα πρωτόκολλο το οποίο ορίστηκε από την IETF CoRE WorkGro και αυτή τη στιγμή βρίσκεται σε στάδιο σχεδίου (Internet Draft). To συγκεκριμένο πρωτόκολλο με μια σύντομη περιγραφή αποτελεί ένα εναλλακτικό πρωτόκολλο του HTTP στο επίπεδου εφαρμογών (application Layer) για εφαρμογές οι οποίες χρησιμοποιούν την REST αρχιτεκτονική [12] σε συσκευές με πολύ περιορισμένους πόρους (highly resource-constrained). Ως παράδειγμα των πλεονεκτημάτων που προσφέρει το CAP αναφέρουμε μία σημαντική διαφορά μεταξύ των δύο πρωτοκόλλων. Η διαφορά εστιάζεται στο γεγονός ότι ενώ το πρωτόκολλο HTTP βασίζεται στο TCP, το πρωτόκολλο περιορισμένων εφαρμογών παρέχει χαρακτηριστικά στοιχειώδους αξιοπιστίας. Έτσι αυτό το πρωτόκολλο μπορεί να χρησιμοποιηθεί πάνω από το UDP πρωτόκολλο εξοικονομώντας πόρους λόγω του ότι το TCD προσθέτει πολύ μεγαλύτερη επιβάρυνση (overhead ) από το UDP τόσο σαν μέγεθος πακέτου όσο σαν πρωτόκολλο επικοινωνίας. Η WS4D-JCoap εργαλειοθήκη βρίσκεται ακόμα σε στάδιο ανάπτυξης. Παρόλα αυτά τα χαρακτηριστικά τα οποία προσφέρει εγγυώνται υψηλές αποδόσεις με χαμηλή επιβάρυνση, ενώ ένα από τα σημαντικότερα πλεονεκτήματα του είναι ότι 70

79 δεν ακλουθεί την αρχιτεκτονική των βασισμένων στο SOAP Web Services ( SOAP based Web Services). Η συγκριμένη αρχιτεκτονική αν και προσφέρει πλεονεκτήματα στα ανώτερα επίπεδα της εφαρμογής προσθέτει μεγάλη επιβάρυνση (overhead ) στο επίπεδο επικοινωνίας των συσκευών. Αποτέλεσμα αυτού είναι να μην αποτελεί η DPWS τεχνολογία αποδοτική λύση για εφαρμογές οι οποίες έχουν αυστηρούς χρονικούς περιορισμούς και πολύ χαμηλούς πόρους WS4D-JMEDS H Java multi edition DPWS έκδοση του εργαλείου στοχεύει τόσο σε ενσωματωμένες συσκευές με περιορισμένη μνήμη και υπολογιστική ισχύ, όσο και σε υπολογιστικά συστήματα τα οποία δεν παρουσιάζουν τέτοιους περιορισμούς. Η αρθρωτή κατασκευή (modularity) της JMEDS εργαλειοθήκης επιτρέπει τη χρήση διαφορετικών προσθετών (Modules) και εγγυάται υψηλή προσαρμοστικότητα. Η JMEDS εργαλειοθήκη υποστηρίζει διαφορετικές εκδόσεις της Java συμπεριλαμβανομένης και της Java ME CLDC. Η WS4D-JMEDS εργαλειοθήκη βασίζεται στη Connected Limited Device Configuration που αποτελεί το μικρότερο υποσύνολο λειτουργιών που παρέχει η Java Micro Edition (ME) έκδοση, οπότε μπορεί να χρησιμοποιηθεί από όλες τις πλατφόρμες οι οποίες είναι συμβατές με Java ME ενώ έχουν δημιουργηθεί και μηχανισμοί ώστε να υπάρχει συμβατότητα με την Java Standard Edition. Τέλος ένα ακόμα σημαντικό χαρακτηριστικό της JMEDS εργαλειοθήκης είναι ότι είναι συμβατή με όλα τα PDA και Smartphones που χρησιμοποιούν την Java ME έκδοση ενώ οι νεότερες εκδόσεις είναι συμβατές με το λειτουργικό σύστημα Android Παρουσίαση της WS4D-JMEDS εργαλειοθήκης Με βάση την ανάλυση που έγινε στην παράγραφο 6.2 για τις υλοποιήσεις της DPWS τεχνολογίας καταλήξαμε στο συμπέρασμα ότι η WS4D-JMEDS εργαλειοθήκη αποτελεί την καταλληλότερη επιλογή για την υλοποίηση του συστήματος που θα κατασκευάσουμε. Στη συνέχεια παραθέτουμε μία σειρά από διεπαφές και κλάσεις τις οποίες θα χρησιμοποιήσουμε στην υλοποίηση μας DefaultDevice και Device Η διεπαφή Device αναπαριστά ένα Web Service με συγκεκριμένες λειτουργίες, όπως την φιλοξενία άλλων Services. Στη διεπαφή αυτή μπορούμε να αναφερθούμε μέσω της μοναδικής endpoint αναφοράς (endpoint reference) ή μπορούμε να την 71

80 εντοπίσουμε μέσω της διαδικασίας ανακάλυψης (discovery) χρησιμοποιώντας την παράμετρο Xaddress ή κάποιο μοναδικό PortType. Όσον αφορά τον τομέα της ασφάλειας οι ρυθμίσεις, που βασίζονται στην WS- Security προδιαγραφή, υλοποιούνται από την διεπαφή DeviceCommons, ενώ πρόσθετες λειτουργίες για την επικοινωνία των συσκευών σε τοπικό επίπεδο περιλαμβάνονται στην διεπαφή Local Device. H κλάση DefaultDevice, η οποία υλοποιεί τις παραπάνω διεπαφές όπως φαίνεται στο σχήμα 6.3, έχει όλα τα χαρακτηριστικά μίας DPWS συσκευής τα οποία περιγράφονται από την DPWS προδιαγραφή και μπορούν να χρησιμοποιηθούν από τον προγραμματιστή για προσαρμοσμένες υλοποιήσεις (custom implementations). Στην περίπτωση που θέλουμε η συσκευή να είναι ορατή εκτός τοπικού δικτύου το JMEDS προσφέρει την κλάση ProxyDevice η όποια υλοποιεί την διεπαφή Device reference. Η διεπαφή αυτή όπως φαίνεται στο σχήμα 6.3 αποτελεί πρόγονο της ProxyDevice η οποία περιλαμβάνει τις λειτουργίες για τον εντοπισμό της συσκευής απομακρυσμένους Clients που βρίσκονται εκτός τοπικού δικτύου. Σχήμα 6.3 Διάγραμμα κληρονομικότητας των κλάσεων DefaultDevice και ProxyDevice οι οποίες έχουν υλοποιηθεί από την JMEDS εργαλειοθήκη [22] DefaultService H κλάση UnitService που αναπαριστά τα Services της υλοποίησης αποτελεί απόγονο της κλάσης DefaultService και το διάγραμμα κληρονομικότητας της 72

81 φαίνεται στο σχήμα 6.4. H κλάση DefaultService προσφέρει μεθόδους με τις οποίες μπορούμε να προσθέσουμε Operations και EventSinks. Επίσης αξίζει να σημειωθεί ότι η κλάση χρησιμοποιείται για την παράγωγη του κατάλληλου WSDL κατά το runtime της εφαρμογής. Σε αυτό το σημείο πρέπει να αναφέρουμε ότι για να μεταφραστεί χωρίς προβλήματα η κλάση DefaultService, πρέπει να αρχικοποιηθούν σωστά οι ιδιότητες (properties) του Service. Οι παράμετροι αρχικοποίησης του κάθε service μπορούν να δοθούν είτε μέσω των συναρτήσεων αρχικοποίησης που προσφέρει η ίδια η κλάση DefaultService είτε μέσω σύνδεσης(binding) ενός αρχείου properties στο οποίο υπάρχουν οι αρχικοποιήσεις. Σχήμα 6.4 Διάγραμμα κληρονομικότητας των κλάσεων DefaultService και ProxyService οι οποίες έχουν υλοποιηθεί από την JMEDS εργαλειοθήκη [22] Operations και DefaultEventSource Η διεπαφή OperationDescription και η υλοποίηση της Operation Commons αποτελούν την κοινή βάση τόσο για την κλάση Operation όσο και για την κλάση DefaultEventSource στο DPWS-JMEDS πλαίσιο (framework). Η παραπάνω διεπαφή 73

82 και η υλοποίηση της περιέχουν όλες τις ιδιότητες που πρέπει να έχουν οι συμβατές με DPWS διαδικασίες(operations). Επίσης οι συγκεκριμένες κλάσεις προσφέρουν μεθόδους δημιουργίας και επιστροφής(return methods) παραμέτρων εισόδου, εξόδου καθώς και σφαλμάτων. Οι σχέσεις μεταξύ των κλάσεων και οι μέθοδοι που προσφέρουν παραθέτονται στο σχήμα H διεπαφή EventSource ορίζει τα ειδικά χαρακτηριστικά των γεγονότων (events). To DPWS πλαίσιο υποστηρίζει δύο τύπους επικοινωνίας γεγονότων οι οποίοι είναι συμβατοί με τις WSDL 1.1 και WS-Eventing προδιαγραφές, τις ειδοποιήσεις και τις «λειτουργίες που ζητούν απάντηση» (Solicit Response Operations). Οι ειδοποιήσεις είναι μηνύματα μίας διαδρομής (one-way) ενώ οι «λειτουργίες που ζητούν απάντηση» προβλέπουν και μία απάντηση από τον Client συνδρομητή στον αποστολέα. Η διεπαφή EventSource επίσης ορίζει και τη λειτουργία της συνδρομής την οποία χρησιμοποιεί ένας Client για να δηλώσει ότι θέλει να λαμβάνει ειδοποιήσεις για ένα συγκεκριμένο γεγονός. Η κλάση DefaultEventSource υλοποιεί την EventSource διεπαφή και κληρονομεί την κλάση OperationCommons που παρέχει μεθόδους που δίνουν πληροφορία για την ίδια την πηγή γεγονότων και για το Service που την περιέχει. Η κλάση Operation υλοποιεί την μέθοδο invoke η οποία χρησιμοποιείται από τον πελάτη για την εκτέλεση της διαδικασίας που αντιπροσωπεύει το Operation. Επίσης πρέπει να σημειωθεί ότι ένα Operation μπορεί να είναι μίας διαδρομής ή αίτησης-απόκρισης (request-response).τέλος πρέπει να αναφέρουμε ότι οι κλάσεις DefaultEventSource και Operation χρησιμοποιούνται ως κλάσεις πρόγονοι, τις ιδιότητες των οποίων κληρονομούν οι προσαρμοσμένες κλάσεις (custom classes) των προγραμματιστών που αναπτύσσουν μια εφαρμογή βασισμένη σε αυτό το toolkit DefaultClient Η κλάση DefaultClient περιέχει τις υλοποιήσεις των διεπαφών Service Listener, SearchCallBack, EventListener, DeviceListener και HelloListener. Οι σχέση μεταξύ των διεπαφών φαίνεται στο σχήμα 6.4. Η HelloListener διεπαφή «ακούει» το δίκτυο για Hello μηνύματα τα οποία περιέχουν το endpoint reference της συσκευής καθώς και άλλες πληροφορίες για την συσκευή όπως metadata version, port types, scopes και transport addresses. Η SearchCallback διεπαφή προσφέρει μεθόδους ανάκλησης (callback) οι οποίες καλούνται όταν βρεθεί ως αποτέλεσμα διαδικασίας αναζήτησης ένα Service ή μία συσκευή. Η συγκεκριμένη κλάση προσφέρει συναρτήσεις για την αναζήτηση συσκευών, τον εντοπισμό των αλλαγών κατάστασης μιας DPWS συσκευής και τη λήψη ειδοποιήσεων γεγονότων από Services που έχει εγγραφεί. Οι διεπαφές ServiceListener και DeviceListener είναι υπεύθυνες να ειδοποιούν τον πελάτη για τυχόν αλλαγές στην κατάσταση των Services και των συσκευών. Τέλος η 74

83 διεπαφή EventListener παρέχει τις λειτουργίες για την λήψη ειδοποιήσεων από τα EventSources καθώς και συναρτήσεις που επιστρέφουν την κατάσταση των συνδρομών. Σχήμα 6.5 Διάγραμμα κληρονομικότητας των κλάσεων DefaultEventSource και Operation οι οποίες έχουν υλοποιηθεί από την JMEDS εργαλειοθήκη [22] Ανάλυση των προσαρμοσμένων κλάσεων Με βάση την ανάλυση που παρουσιάστηκε στο κεφαλαίο 5 στα πλαίσια της υλοποίησης του συστήματος επίδειξης δημιουργήθηκαν προσαρμοσμένες (custom) προγραμματιστικές δομές και κλάσεις οι οποίες αποτελούν τους δομικούς λίθους με τους οποίους υλοποιήθηκε η εφαρμογή επίδειξης. Οι κλάσεις αυτές χωρίζονται σε δύο κατηγορίες. Στη πρώτη κατηγορία ανήκουν οι κλάσεις οι οποίες συμμετέχουν στην υλοποίηση της εφαρμογής από την πλευρά του εξυπηρετητή, δηλαδή το Festo MPS project και στη δεύτερη κατηγορία ανήκουν οι κλάσεις που έχουν να κάνουν με την υλοποίηση της εφαρμογής από την πλευρά του πελάτη, δηλαδή το FestoControl project. Οι κλάσεις που θα αναλυθούν παρακάτω δεν σχετίζονται με την υλοποίηση της λειτουργικής συμπεριφοράς του κάθε unit, δηλαδή με την 75

84 υλοποίηση του εξομοιωτή, ούτε με την υλοποίηση της συμπεριφοράς του ενορχηστρωτή καθώς το αντικείμενο αυτής της μελέτης εστιάζεται αλλού. Η παρουσίαση που παραθέτουμε αναλύει τις κλάσεις οι οποίες υλοποιούν την επικοινωνία μεταξύ συσκευής και απομακρυσμένου ελεγκτή μέσω Web Services ή έχουν σχέση με την αντιμετώπιση προβλημάτων που προκύπτουν κατά την επικοινωνία όπως αυτά που παρουσιαστήκαν στη παράγραφο Σχήμα 6.4 Διάγραμμα κληρονομικότητας της κλάσης DefaultClient η οποία έχει υλοποιηθεί από την JMEDS εργαλειοθήκη [22] FestoMPS Οι βασικές κλάσεις που περιλαμβάνει το Festo Mps project είναι οι εξής: A. UnitEventSource B. UnitOperation C. UnitMonitor D. UnitMonitorWithExpectedInput E. UnitService 76

85 A. UnitEventSource Η κλάση UnitEventSource αποτελεί κλάση απόγονο της κλάσης DefaultEventSource που παρουσιάστηκε στην παράγραφο και αναπαριστάται στο σχήμα 6.5. Η κλάση αυτή κληρονομεί όλα τα χαρακτηριστικά και τις λειτουργίες μίας πηγής δημιουργίας γεγονότων που παρέχονται από την κλάση DefaultEventSource και περιλαμβάνει μερικά πρόσθετα χαρακτηριστικά που διευκολύνουν την υλοποίηση της εφαρμογής μας. Το πρώτο αξιοσημείωτο χαρακτηριστικό που θα αναφερθούμε είναι οι παράμετροι εισόδου, ονομάστηκα οι μεταβλητές WEB_SERVICE_NAME και EVENT. Οι μεταβλητές αυτές, που ορίζονται ως μεταβλητές εισόδου, δημιουργούν το endpoint του EventSource και των στοιχείων (elements) που αποτελούν το μήνυμα ειδοποίησης του γεγονότος που θα σταλεί στον πελάτη. Αυτή η συμπεριφορά έχει ως αποτέλεσμα κατά τη δημιουργία ενός νέου UnitEventSource να δημιουργηθούν αυτόματα όλα τα endpoints που χρειάζονται για τη λειτουργία του. Επίσης η κλάση ορίζει και την δομή του μηνύματος ειδοποίησης το οποίο θα σταλεί στον πελάτη που θα εγγραφεί. Η δομή του μηνύματος ειδοποίησης είναι προκαθορισμένη από τη DPWS προδιαγραφή. Η προδιαγραφή προσδιορίζει όλα τα στοιχεία τα οποία είναι απαραίτητο να υπάρχουν προκειμένου η διαδικασία αποστολής ειδοποιήσεων να είναι επιτυχημένη. Έχοντας το βασικό πλαίσιο ως δεδομένο ο προγραμματιστής προσθέτει σε αυτή την προκαθορισμένη δομή τα στοιχεία μηνύματος της ειδοποίησης που περιέχουν τα δεδομένα που πρέπει να στείλει. Η δομή των μηνυμάτων ειδοποίησης που θα χρησιμοποιήσουμε στην υλοποίηση μας, η οποία φαίνεται στο σχήμα 6.6 αποτελείται από ένα στοιχείο SimpleNotifType σύνθετου τύπου (complex type) το οποίο περιέχει δύο απλά στοιχεία. Το στοιχείο NOTIFICATION είναι το αλφαριθμητικό μήνυμα της ειδοποίησης και το στοιχείο EVENT_NUMBER περιέχει το αύξοντα αριθμό του γεγονότος. Ο αριθμός αυτός χρησιμοποιείται σε επόμενο στάδιο για την ταξινόμηση των ειδοποιήσεων από τον Client. Σχήμα 6.5 UML διάγραμμα της κλάσης του UnitEventSource. 77

86 Σχήμα 6.6. δομή του μηνύματος ειδοποιήσεων που στέλνουν οι πηγές γεγονότων στιγμιότυπα της κλάσης UnitEventSource. B. UnitOperation H κλάση UnitOperation κληρονομεί την κλάση Operation που προσφέρει το JMEDS, ενώ η UML αναπαράσταση της κλάσης δίνεται στο σχήμα 6.7. Όπως αναφέραμε παραπάνω, η κλάση Operation αποτελεί την υλοποίηση μία μεθόδου που προσφέρει μία DPWS συσκευή. Η κλάση αυτή προσφέρει στις κλάσεις που την κληρονομούν, την μέθοδο Invoke. Η μέθοδος αυτή γίνεται override από την κλάση κληρονόμο και προσφέρεται σε αυτήν η λογική της λειτουργίας που θέλουμε να υλοποιήσουμε καθώς και οι κατάλληλες μεταβλητές εισόδου και εξόδου. Στην δική μας υλοποίηση, δηλαδή την κλάση UnitOperation, η μέθοδος invoke λαμβάνει ως είσοδο ένα αλφαριθμητικό, το οποίο είναι ο αύξον αριθμός τη λειτουργίας ελέγχου. Ο αριθμός αυτός θα χρησιμοποιηθεί σε επόμενο στάδιο για την εξασφάλιση της σωστής σειράς λήψης των μηνυμάτων ελέγχου από την κλάση UnitMonitorWithExpectedInput. Το στιγμιότυπο της κλάσης UnitOperation δημιουργεί τα αναγκαία endpoints κατά τη δημιουργία του με το ίδιο τρόπο που περιγράφηκε παραπάνω στην κλάση UnitEventSource. Τα σημεία που διαφοροποιείται το κάθε στιγμιότυπο είναι οι μεταβλητές εισόδου WEB_SERVICE_NAME και OPERATION από τις οποίες δημιουργούνται τα endpoints καθώς επίσης και η μεταβλητή DeviceCommand. Η μεταβλητή αυτή είναι ένα αλφαριθμητικό το οποίο αποτελεί την εντολή που αποστέλλεται στο προσωπικό επόπτη (Monitor) της κάθε συσκευής ώστε να παραληφθεί στη συνέχεια από την ίδια τη συσκευή για να εκτελεστεί. Το αλφαριθμητικό το οποίο θα αποσταλεί στην συσκευή για να εκτελεστεί μία ενέργεια εξαρτάται από τις ρύθμιση της ίδια της συσκευή, όμως είναι μοναδικό για κάθε ενέργεια. Με αυτό τον τρόπο θέτοντας το κατάλληλο αλφαριθμητικό στην μεταβλητή DeviceCommand κατά τη δημιουργία του στιγμιότυπου, αντιστοιχούμε την κλήση του κάθε Operation στη αποστολή μίας εντολής στην πραγματική συσκευή. Τέλος πρέπει να αναφέρουμε πως ανάλογα με τη σχεδίαση, δηλαδή αν έχουμε τοπικό έλεγχο η όχι, η κλάση επόπτης η οποία δέχεται τα μηνύματα που λαμβάνει η κλάση UnitOperation, έχει διαφορετική υλοποίηση. 78

87 Σχήμα 6.7 UML διάγραμμα της κλάσης του UnitEventSource. C. UnitMonitor H επικοινωνία μεταξύ της DPWS διεπαφής της συσκευής και της ίδιας της συσκευής ή του εξομοιωτή στην συγκεκριμένη εφαρμογή επιτυγχάνεται χρησιμοποιώντας το μοντέλο του παραγωγού-καταναλωτή με τη βοήθεια κλάσης επόπτη (Monitor). Η κλάση UnitMonitor είναι μία κλάση επόπτης η οποία περιέχει μια εσωτερική λίστα στη οποία στέλνονται αλφαριθμητικά εντολών όταν καλείται ένα από τα Operations που προσφέρει το Service μίας συσκευής και από την όποια λαμβάνει μηνύματα ελέγχου η συσκευή. D. UnitMonitorWithExpectedInput Η κλάση UnitMonitorWithExpectedInput είναι μία κλάση επόπτης (Monitor) με εσωτερική λίστα για εντολές, όπως η κλάση UnitMonitor που περιγράψαμε παραπάνω με μία πρόσθετη δυνατότητα. Η κλάση είναι υπεύθυνη για την αποστολή των εντολών στον Client με βάση την ταξινόμηση που προκύπτει από τον αριθμό του Operation. Δηλαδή αυτή η κλάση αποτελεί μία υλοποίηση της δομής της στοίβας αναμενόμενου γεγονότος που προτάθηκε ως λύση για το πρόβλημα της αναδιάταξη της ακολουθίας των εντολών και των ειδοποιήσεων γεγονότων στην παράγραφο E. UnitService Η κλάση UnitService κληρονομεί την κλάση DefaultService η οποία αναπαριστά το Service που προσφέρει μία συσκευή. Η κλάση επίσης προσφέρει τη μέθοδο firenotification η οποία υλοποιεί την λειτουργία της αποστολής ειδοποιήσεων μέσω των EventSource που έχει το Service.Τέλος η αρχικοποίηση του Service γίνεται μέσω ενός αρχείου ιδιοτήτων(properties) με τη μέθοδο της σύνδεσης (binding).το UML διάγραμμα αυτής της κλάσης φαίνεται στο σχήμα

88 Σχήμα 6.8 UML διάγραμμα της κλάσης του UnitService Festo Control Application Οι βασικές κλάσεις που περιλαμβάνει το Festo Control Application project είναι οι εξής: A. ServiceInitMonitor B. ComponentStarter C. UnitServiceMonitorEXN D. UnitServiceCollector E. UnitServiceClient A. ServiceInitMonitor Η κλάση ServiceInitMonitor είναι μία κλάση επόπτης η οποία χρησιμοποιείται κατά την αρχικοποίηση ενός στιγμιότυπου της κλάσης UnitServiceClient. Όπως έχει αναφερθεί και σε προηγούμενο κεφάλαιο για να συνδεθεί ένας πελάτης με το Service μιας DPWS συσκευής χρησιμοποιεί την διαδικασία ανακάλυψης (Discovery). Αυτή η διαδικασία ανάλογα με την ταχύτητα, το φόρτο και τον αριθμό των DPWS συσκευών του δικτύου μπορεί να διαρκέσει έως και μερικά δευτερόλεπτα. Σε αυτό το χρονικό διάστημα ο πελάτης αναμένει να βρεθούν τα Services, δηλαδή βρίσκεται σε κατάσταση wait, και όταν τα Services βρεθούν ειδοποιούν το πελάτη να προχωρήσει σε εγγραφές. Δηλαδή εκτελείται μία notify διαδικασία με την όποια το νήμα (Thread) του πελάτη προχωρά σε διαδικασίες εγγραφών. Το UML διάγραμμα αυτής της κλάσης φαίνεται στο σχήμα 6.9. Σχήμα 6.9 UML διάγραμμα της κλάσης ServiceInitMonitor. 80

89 B. ComponentStarter Η κλάση ComponentStarter περιλαμβάνει όλους τους επιμέρους ελεγκτές και προσφέρει μεθόδους για την έναρξη και την λήξη της διαδικασίας ελέγχου. C. UnitServiceMonitorEXN Η κλάση UnitServiceMonitorEXN είναι μία κλάση επόπτης(monitor), στην οποία στέλνονται τα μηνύματα ειδοποιήσεων που δέχεται από τα EventSources, η κλάση UnitServiceClient. Η κλάση αυτή περιέχει σαν datamember μία λίστα στην οποία αποθηκεύονται τα μηνύματα που στέλνει η DPWS συσκευή και από την οποία λαμβάνει μηνύματα η κλάση UnitServiceCollector. Πρέπει να σημειωθεί ότι η κλάση αυτή έχει μια προσθετή λειτουργιά μέσω της μεθόδου findinlistentrywithexpectedcommandno. Όταν μία κλάση ελεγκτής ζητήσει την επόμενη εντολή που περιέχεται στην στοίβα της κλάσης, τότε μέσω της μεθόδου findinlistentrywithexpectedcommandno, ελέγχεται η ιδιότητα ExpectedCommandNo που έχει κάθε έγγραφη της λίστας για να διαπιστωθεί αν υπάρχει η αναμενόμενη εγγραφή. Έτσι εξασφαλίζεται ότι οι κλάσεις ελεγκτές δέχονται πάντα ειδοποιήσεις οι οποίες είναι χρονικά ταξινομημένες. Τέλος πρέπει να σημειώσουμε ότι αυτή η κλάση όπως και η UnitMonitorWithExpectedInput αποτελούν υλοποιήσεις της στοίβας αναμενόμενου γεγονότος που παρουσιάστηκε στη παράγραφο D. UnitServiceCollector Η κλάση UnitServiceCollector λειτούργει ως ένας συλλέκτης ο οποίος μεταφέρει τις ειδοποιήσεις που λαμβάνει από την στοίβα της κλάσης UnitServiceMonitorEXN και ανάλογα με την αρχικοποίηση του, στέλνει τα μηνύματα στην κατάλληλη κλάση επόπτη μέσω της οποίας το λαμβάνει ο ελεγκτής της συσκευής. Η κλάση αυτή διαθέτει έναν εσωτερικό κατάλογο, ο οποίος ονομάζεται bindinglist και περιέχει την αντιστοίχηση μεταξύ της πηγής του μηνύματος ειδοποίησης και του Monitor προορισμού. Σε αυτό το σημείο πρέπει να αναφέρουμε ότι η μέθοδος η οποία χρησιμοποιείται για την αρχικοποίηση του εσωτερικού καταλόγου, είναι η bindnotificationwithmonitor. Τέλος πρέπει να σημειώσουμε ότι κλάση UnitServiceCollector χρησιμοποιείται και για να μεταφέρει ειδοποιήσεις οι οποίες έχουν ως προορισμό δύο διαφορετικούς ελεγκτές. Δηλαδή η συγκεκριμένη κλάση αποτελεί υλοποίηση της πρότασης που έγινε στην παράγραφο για να αντιμετωπιστεί το πρόβλημα της ασύγχρονης λήψης ειδοποιήσεων από πελάτες 81

90 που εγγράφονται στην ίδια πηγή γεγονότων. Το UML διάγραμμα αυτής της κλάσης φαίνεται στο σχήμα Σχήμα 6.10 UML διάγραμμα της κλάσης UnitServiceCollector. E. UnitServiceClient Η κλάση UnitServiceClient είναι απόγονος της κλάσης DefaultClient. Οι μέθοδοι ανάκλησης (callback) servicefound και eventreceived κληρονομούνται από την κλάση γονέα και χρησιμοποιούνται ως μία μορφή ειδοποιήσεων. Η μέθοδος servicefound χρησιμοποιείται για να ειδοποιηθεί η κλάση όταν βρεθεί κάποιο Service για το οποίο είχε αρχίσει διαδικασία ανακάλυψης. Με παρόμοιο τρόπο λειτουργεί και η μέθοδος eventreceived η οποία καλείται κάθε φορά που μία ειδοποίηση κάποιου γεγονότος φτάνει στο EvenSink της κλάσης. Το EventSink της κλάσης UnitServiceClient αποτελεί ένα στιγμιότυπο της κλάσης EventSink που παρέχεται από τη JMEDS εργαλειοθήκη και αποτελεί το αντικείμενο το οποίο δέχεται τις ειδοποιήσεις από τα EventSources στα οποία έχει εγγραφεί ο πελάτης. Η εγγραφή σε ένα EventSource πραγματοποιείται μέσω τη μεθόδου subscribefornotification, η οποία παίρνει ως όρισμα το όνομα της ειδοποίησης. Το όνομα αυτό θα χρησιμοποιηθεί για να παραχθεί το URI στο οποίο θα σταλεί η αίτηση εγγραφής. Τέλος η κλάση προσφέρει τη μέθοδο InvokeOperation η οποία χρησιμοποιείται για να πραγματοποιηθεί η απομακρυσμένη κλήση μίας από τις μεθόδους που προσφέρει το Service με το οποίο είναι «συνδεδεμένη». Η επιλογή της κατάλληλης μεθόδου του Service γίνεται μέσω του αλφαριθμητικού που δίνεται ως όρισμα εισόδου στην μέθοδο InvokeOperation. Το UML διάγραμμα αυτής της κλάσης φαίνεται στο σχήμα

91 Σχήμα 6.11 UML διάγραμμα της κλάσης UnitServiceClient. 83

92 84

93 Κεφάλαιο 7 Υλοποίηση συστήματος 7.1. Εισαγωγή Βασιζόμενοι στην αξιολόγηση των εναλλακτικών σχεδιάσεων που προτάθηκαν στην παράγραφο 5.3 συμπεραίνουμε ότι δύο από αυτές μπορούν να οδηγήσουν σε υλοποιήσεις, οι οποίες προσομοιώνουν επαρκώς τη συμπεριφορά ενός συστήματος βιομηχανικού ελέγχου βασισμένο στην τεχνολογία του Service Oriented Computing. Η σχεδίαση με κεντρικό απομακρυσμένο ενορχηστρωτή και η σχεδίαση με κεντρικό απομακρυσμένο και τοπικό έλεγχο. Η πρώτη σχεδίαση προσφέρεται για υλοποιήσεις οι οποίες δεν έχουν απαιτήσεις πραγματικού χρόνου όπως π.χ. την επίδειξη της λειτουργίας(demonstration) ή τον έλεγχο(testing) ενός συστήματος. Αυτό συμβαίνει επειδή η συγκεκριμένη σχεδίαση προσφέρει πλήρη πρόσβαση στις λειτουργίες της συσκευής μέσω της DPWS διεπαφής, όμως η γενική του απόδοση κρίνεται επαρκής για να αποτελέσει βάση για υλοποιήσεις πραγματικών βιομηχανικών συστημάτων. Αντίθετα η σχεδίαση με τοπικό και απομακρυσμένο έλεγχο αν και «αποκόπτει» τις εσωτερικές λειτουργίες μίας συσκευή μέσω του τοπικού ελέγχου ικανοποιεί επαρκώς τις απαιτήσεις σχεδίασης και μπορεί να χρησιμοποιηθεί για υλοποιήσεις σε πραγματικά συστήματα βιομηχανικού ελέγχου. Έχοντας επιλέξει τις σχεδιάσεις θα προχωρήσουμε σε παρουσίαση των υλοποιήσεων τους. Η παρουσίαση θα ακολουθήσει την σειρά με την οποία έγινε η κατασκευή. Δηλαδή θα αναλύσουμε πρωτίστως, την διαδικασία κατασκευής της DPWS διεπαφής και των υπόλοιπων κλάσεων οι οποίες εγγυώνται τη σωστή λειτουργία της DPWS συσκευής. Σε αυτό το σημείο να αναφέρουμε ότι σύνολο των DPWS συσκευών περιλαμβάνεται στο project Festo MPS. Στη συνέχεια θα προχωρήσουμε στην ανάλυση της διαδικασίας κατασκευής της εφαρμογή η οποία εκτελεί τις διαδικασίες ελέγχου μέσω της ενορχήστρωσης των Web Services που προσφέρει η κάθε συσκευή. Η εφαρμογή αυτή περιλαμβάνεται στο project Festo Control. Τέλος για την καλύτερη κατανόηση του τρόπου λειτουργίας της κάθε υλοποίησης παραθέτουμε μία μελέτη περιπτώσεων (case study) της λειτουργίας της συσκευής Feeder, η οποία αποτελεί αντιπροσωπευτικό δείγμα της συμπεριφοράς και των υπόλοιπων συσκευών του συστήματος. Σε αυτό το σημείο πρέπει να σημειωθεί ότι οι υλοποιήσεις που παρουσιάζονται παρακάτω χρησιμοποιούν τις κλάσεις και τα εργαλεία που παρουσιαστήκαν στο κεφάλαιο 6 για την υλοποίηση του συστήματος. 85

94 7.2. Υλοποίηση με ολικό απομακρυσμένο έλεγχο Η συγκεκριμένη υλοποίηση βασίζεται στην σχεδίαση με κεντρικό απομακρυσμένο ενορχηστρωτή η οποία παρουσιάστηκε στην παράγραφο Η σχεδίαση αυτή βασίζεται εξολοκλήρου στον έλεγχο του απομακρυσμένου ενορχηστρωτή. Δηλαδή όλες οι λειτουργίες των DPWS συσκευών παρέχονται ως μέθοδοι των Web Services που φιλοξένει η DPWS διεπαφή της κάθε συσκευής και η διαδικασία ελέγχου γίνεται αποκλειστικά από τον απομακρυσμένο ενορχηστρωτή. Ακολουθώντας αυτές τις αρχές σχεδίασης στις επόμενες παραγράφους θα αναλύσουμε την διαδικασία υλοποίησης με τη χρήση της WS4D-JMEDS εργαλειοθήκης. Σε αυτό το σημείο πρέπει να αναφέρουμε ότι το σύστημα θα εξεταστεί τόσο από την πλευρά του εξυπηρετητή η οποία αποτελεί το project Festo MPS, όσο και από την πλευρά του πελάτη η οποία αποτελεί το project Festo Control. Τέλος να σημειώσουμε κατά την ανάλυση του συνολικού συστήματος θα χρησιμοποιηθούν οι κλάσεις που παρουσιάστηκαν στο κεφάλαιο 6. Επίσης για την καλύτερη κατανόηση του τρόπου λειτουργίας του συστήματος μετά τη περιγραφή κάθε υλοποίησης παραθέτεται μελέτη περιπτώσεων ενός τμήματος του συνολικού συστήματος, πιο συγκεκριμένα της συσκευής Feeder Festo MPS To Project Festo MPS περιλαμβάνει το σύνολο των υλοποιήσεων των DPWS συσκευών του συστήματος. Η κάθε μία από αυτές φιλοξενεί ένα Service στο οποίο προσθέτουμε Operations και EventSources εκθέτοντας τις λειτουργίες της συσκευής στο δίκτυο. Το διάγραμμα κλάσεων της κάθε DPWS συσκευής φαίνεται στο σχήμα 7.1. Η βασικές κλάσεις οι οποίες αποτελούν την καρδία της υλοποίησης είναι τα Devices. Τα Devices είναι στιγμιότυπα της κλάσης DefaultDevice την οποία προσφέρει η WS4D-JMEDS εργαλειοθήκη. Η κλάση Device προσφέρει δυο μεθόδους οι οποίες δίνουν πρόσβαση στα properties συσκευής. Πρώτον μέσο set συναρτήσεων και δεύτερον μέσω ενός properties αρχείου στο οποίο αρχικοποιούμε τις ιδιότητες των συσκευών μέσω του μηχανισμού συνδέσεων (bindings) που προσφέρει η εργαλειοθήκη. Οι ιδιότητες (properties) των Devices αποτελούν ουσιαστικά μετά-δεδομένα τα οποία δίνουν πρόσθετες πληροφορίες για τη συσκευή. Οι ιδιότητες που αρχικοποιούμε στη περίπτωση του feederdevice φαίνονται αναλυτικά στο παράδειγμα του σχήματος 7.5. Κατά την αρχικοποίηση, μέσω του μηχανισμού συνδέσεων, εκτός από τις ιδιότητες οι οποίες παρέχουν πληροφορίες για την συσκευή θα πρέπει να ορίσουμε τις ιδιότητες που αφορούν την συμπεριφορά του Device ως Web Service όπως π.χ. το port στο οποίο ακούει. Μέρος αυτής της 86

95 αρχικοποίηση γίνεται μέσω του ορισμού των HTTPBindings, ενώ οι υπόλοιπες αρχικοποιήσεις γίνονται με βάση τα bindings που υπάρχουν στις περιοχές Devices και Services το αρχείου αρχικοποιήσεων. Αυτές οι παραμετροποιήσεις της DPWS συσκευής πρέπει να γίνουν με τέτοιο τρόπο ώστε να μεγιστοποιείται η αναγνωσιμότητα και η επαναχρησιμοποίηση του κώδικα. Εξωτερικά το Device θα πρέπει να έχει τρείς παρεχόμενες διεπαφές και μία προαπαιτούμενη όπως φαίνεται στο σχήμα 7.2. Οι δύο από τις παρεχόμενες διεπαφές θα διαφημίζονται και θα αποτελούνται από το σύνολο των Οperations και Event Sinks που προσφέρει η DPWS συσκευή στο δίκτυo, ενώ οι υπόλοιπες δύο χρησιμοποιούνται για την υλοποίηση της επικοινωνίας του DPWS Device με τα κατώτερα επίπεδα. Σε αυτό το σημείο πρέπει να σημειώσουμε ότι στην υλοποίηση μας τα κατώτερα επίπεδα, δηλαδή οι πραγματικές συσκευές, αντικαθιστώμαι από τον εξομοιωτή. Τέλος πρέπει να υπενθυμίσουμε ότι η κάθε συσκευή του εξομοιωτή ανταλλάσει μηνύματα με την αντίστοιχη DPWS διεπαφή χρησιμοποιώντας το μοντέλο του παράγωγου καταναλωτή με τη βοήθεια επόπτη (Monitor). H κλάση που χρησιμοποιούμαι ως επόπτη στη υλοποίηση μας είναι η κλάση UnitMonitorWithExpectedInput. Η συγκεκριμένη κλάση εκτός από την κλασική λειτουργία του επόπτη, προσφέρει κάποιες πρόσθετες λειτουργίες που αφορούν την ακολουθία των μηνυμάτων οι οποίες έχουν αναφερθεί στην παράγραφο Σχήμα 7.1. UML σχεσιακό διάγραμμα των βασικότερων κλάσεων του project Festο MPS 87

96 Σχήμα 7.2. UML διάγραμμα συνιστωσών της DPWS συσκευής Festo Control Το project Festo Control περιλαμβάνει την εφαρμογή η οποία υλοποιεί την διαδικασία έλεγχου χρησιμοποιώντας τις λειτουργίες που διαφημίζουν οι DPWS συσκευές. Η πρόσβαση στις λειτουργίες των DPWS συσκευών γίνεται μέσω της κλάσης UnitServiceClient, η οποία εκτελεί την διαδικασία ανακάλυψης και πραγματοποιεί την σύνδεση με την συσκευή. Η διαδικασία ελέγχου πραγματοποιείται μέσω της ενορχήστρωσης των Operations και των γεγονότων που προσφέρει η συσκευή. Η ενορχήστρωση γίνεται σε επίπεδο συσκευής, δηλαδή κάθε συσκευή είναι «συνδεδεμένη» με έναν απομακρυσμένο ελεγκτή ο οποίος επικοινωνεί με τους υπόλοιπους ελεγκτές που του συστήματος όταν είναι απαραίτητο, με σκοπό να συντονίσει τις ενέργειες της συσκευής για την οποία είναι «υπεύθυνος». Ως ελεγκτής θεωρούμε ένα νήμα (Thread) το οποίο αναλαμβάνει την διαδικασία ελέγχου και δέχεται ως εισόδους τις ειδοποιήσεις από τα γεγονότα που λαμβάνει από τον πελάτη και ως εξόδους στέλνει μήνυμα ελέγχου μέσω των Operations που προσφέρει η DPWS συσκευή. Σε αυτό το σημείο να υπενθυμίσουμε ότι η μεταφορά των ειδοποιήσεων από τον πελάτη μιας συσκευής στον ελεγκτή της, γίνεται χρησιμοποιώντας το μοντέλο του παραγωγού- καταναλωτή με τη χρήση κλάσεων εποπτών (Monitor). Οι κλάσεις οι οποίες λαμβάνουν μέρος στον έλεγχο του Feeder και του Converter καθώς και οι μεταξύ τους σχέσεις αναπαριστώνται στο σχήμα 7.3. Στην υλοποίηση μας, λόγω του προβλήματος της αλλοίωσης της ακολουθίας των μηνυμάτων το οποίο έχει περιγραφεί στην παράγραφό 5.5.3, παρεμβάλουμε μεταξύ της επικοινωνίας UnitServiceClient και ελεγκτή (Controller) ένα ακόμη στάδιο από το οποίο πρέπει να περάσουν τα μηνύματα ειδοποιήσεων. Αυτό το στάδιο χρησιμοποιείται για να διασφαλίσουμε ότι τα μηνύματα φτάνουν με τη σωστή χρονική σειρά και ακόμα για να εξασφαλίσουμε ότι μηνύματα ειδοποιήσεων που πρέπει να παραληφθούν από πολλούς ελεγκτές φτάνουν ταυτόχρονα σε όλους. 88

97 Η πρώτη λειτουργία αυτού του σταδίου ενσωματώνεται στην κλάση UnitServiceMonitorEXN. Η κλάση αυτή είναι υπεύθυνη να λαμβάνει τις ειδοποιήσεις γεγονότων που στέλνει ο πελάτης και να εξασφαλίζει ότι θα στέλνονται με τη σωστή χρονική σειρά ανεξάρτητα από τη σειρά που λήφθηκαν από τον πελάτη. Σε επόμενο στάδιο ο UnitServiceCollector λαμβάνει ένα μήνυμα και αφού ελέγξει την εσωτερική λίστα με τις συνδέσεις (bindings) που του έχουμε ορίσει, το στέλνει στο προσωπικό επόπτη κάθε ελεγκτή. Στη συνέχεια το νήμα του ελεγκτή ειδοποιείται για την ύπαρξη νέου μηνύματος μέσω μίας notify συνάντησης και σε επόμενο βήμα λαμβάνει την νέα ειδοποίηση και προχωρά στην εκτέλεση των κατάλληλών διαδικασιών ελέγχου. Σχήμα 7.3. Διάγραμμα σχέσεων κλάσεων της εφαρμογής ελέγχου των Feeder και Converter συσκευών Μελέτη περίπτωσης του Feeder Για την καλύτερη κατανόηση της λειτουργίας και του τρόπου κατασκευής του συστήματος, παραθέτουμε: 89

98 A. Αναλυτική περιγραφή της διαδικασία αρχικοποίησης της DPWS διεπαφής του Feeder από την πλευρά του εξυπηρετητή. B. Αναλυτική περιγραφή της διαδικασίας αρχικοποίησης του UnitServiceClient καθώς και του απομακρυσμένου ελεγκτή του Feeder από την πλευρά του πελάτη. C. Βήμα προς βήμα ανάλυση των διεργασιών που τελούνται σε όλο το σύστημα στη περίπτωση που ο Feeder φτάσει στην μπροστά θέση. Για να γίνει σωστά η διαδικασία της αρχικοποίησης της συσκευής πρέπει να καταγράψουμε μία λίστα από ενέργειες τις οποίες θέλουμε να εκτελεί η συσκευή. Αυτές η ενέργειες αθροιστικά αποτελούν την συνολική συμπεριφορά της συσκευής. Στη περίπτωση του Feeder οι ενέργειες οι οποίες θέλουμε να εκτελούνται είναι οι εξής : Αν υπάρξει ειδοποίηση από αισθητήρα ότι o feeder βρίσκεται στην πίσω θέση, τότε δώσε εντολή να κινηθεί προς τα μπροστά. Αν υπάρξει ειδοποίηση από αισθητήρα ότι o feeder βρίσκεται στην μπροστά θέση, τότε δώσε εντολή να σταματήσει και στη συνέχεια να κινηθεί προς τα πίσω. Αν υπάρξει ειδοποίηση από το αισθητήρα ότι υπάρχει τεμάχιο στην θέση Α, τότε ειδοποίησε τον Converter. A. Αρχικοποίηση της DPWS διεπαφής της συσκευής feeder Η αρχικοποίηση της DPWS συσκευής του Feeder περιλαμβάνει την αρχικοποίηση της DPWS διεπαφής του, μέσω της κλάσης DefaultDevice. H κλάση DefaultDevice παίρνει ως όρισμα ένα ConfigurationId. Αυτό το Id χρησιμοποιείται για να συνδέσουμε τη συσκευή με ένα σύνολο από αρχικοποιήσεις οι οποίες βρίσκονται στο Properties αρχείο του project όπως φαίνεται στα σχήματα 7.6 και 7.7. Αυτές οι αρχικοποιήσεις περιγράφουν τα χαρακτηριστικά της FeederDevice τα οποία είναι διαθέσιμα σε πελάτες που βρίσκονται στο τοπικό δίκτυο μέσω get μεθόδων, ενώ παράλληλα χρησιμοποιούνται και στην διαδικασία ανακάλυψης της συσκευής. Η ίδια μέθοδος αρχικοποίησης μέσω configuration Id χρησιμοποιείται και στα Services όπως φαίνεται στο σχήμα 7.6. Εδώ πρέπει να σημειωθεί ότι παράλληλα με τις υπόλοιπες ιδιότητες πρέπει να γίνει αρχικοποίηση και των HTTPBindings μέσω της ιδιότητας BindingId. Αυτό το Id αναφέρεται σε ένα σύνολο αρχικοποιήσεων που περιλαμβάνουν στοιχεία όπως την πόρτα (port) και το πρόθεμα(suffix) όπως φαίνεται στο σχήμα 7.4. Για να ολοκληρωθεί η αρχικοποίηση μιας συσκευής πρέπει να προστεθούν σε αυτήν τα κατάλληλα Operations και τα κατάλληλα EventSources τα οποία στην υλοποίηση μας αναπαριστώνται από τις κλάσεις UnitOperation και UnitEventSource. Τα στιγμιότυπα της κλάσης UnitOperation αντιστοιχούν στους 90

99 ενεργοποιητές (actuators) που προσφέρει η συσκευή και η αντιστοίχηση τους για την συσκευή Feeder φαίνεται στο πίνακα ενώ η αντιστοίχηση μεταξύ UnitEventSource και των Sensors της συσκευής φαίνεται στον πίνακα 4.2.Τα UnitOperations και EventSources μπορούν να προστεθούν στο Service της συσκευής μέσω των μεθόδων addoperation και addeventsource, οι οποίες παρέχονται από την ίδια την κλάση όπως φαίνεται στο σχήμα 7.7. Ακολουθώντας την αντιστοίχηση που αναφέραμε δημιουργούμε τρία νέα UnitOperations τα οποία ονομάζονται MoveForward, MoveBack και Stop και στέλνουν μηνύματα ώστε ο Feeder να κινηθεί προς τα εμπρός, προς τα πίσω ή να σταματήσει να κινείται. Η ίδια λογική ισχύει και για τα EventSources, έτσι δημιουργούμε τα FeederFrontPositionNotification, FeederBackPositionNotification και PieceInPositionANotification τα οποία αντιστοιχούν στα γεγονότα που είναι καταγεγραμμένα στον πίνακα 4.2. Μετά την ολοκλήρωση της αρχικοποίησης, κατά το Runtime, το πλαίσιο (framework) του JMEDS-DPWS δημιουργεί αυτόματα, με βάση τα χαρακτηριστικά που έχουμε ορίσει, είτε μέσω του Java κώδικα, είτε μέσω του αρχείου Properties, τα κατάλληλα WSDL αρχεία. Αυτά τα αρχεία δημοσιεύονται στον Server και χρησιμοποιούνται ώστε η συσκευή να γίνει ορατή στο δίκτυο ως Web Service ενώ οι λειτουργίες της συσκευής παρέχονται ως μέθοδοι του Service το όποιο φιλοξενείται στην DPWS αναπαράσταση της συσκευής. Σχήμα 7.4 Αρχικοποίηση HTTPBinding στο Properties αρχείο B. Αρχικοποίηση Client και ελεγκτή Ο Client ο οποίος θα συνδεθεί με την DPWS συσκευή του Feeder την οποία ορίσαμε παραπάνω αποτελεί στιγμιότυπο της κλάσης UnitServiceClient. Το στιγμιότυπο της κλάσης όπως φαίνεται στο σχήμα 7.8 ονομάζεται feederclient και ο δημιουργός του έχει τέσσερεις μεταβλητές εισόδου. Είναι σημαντικό να αναφέρουμε ότι η τρίτη μεταβλητή εισόδου η οποία είναι ακέραιος αποτελεί το ConfigurationId, το οποίο χρησιμοποιείται στην λειτουργία αρχικοποίησης του event sink του Client μέσω του αρχείου Control.Properties. Η διαδικασίας αρχικοποίησης του EventSink καθώς και του HTTPBinding που χρησιμοποιεί το EventSink φαίνεται στα σχήματα 7.9 και Σαν event sink ορίζουμε την κλάση η οποία δέχεται τις ειδοποιήσεις στις οποίες εγγράφεται ο Client. Αυτή η κλάση παρέχει τη μέθοδο η οποία υλοποιεί τη διαδικασία της εγγραφής, subscribefornotification, της οποίας το συντακτικό 91

100 φαίνεται στο σχήμα 7.8. Το πρώτο όρισμα της μεθόδου αυτής χρησιμοποιείται για να συνδεθεί ο πελάτης με το event Source που παρέχει η συσκευή μέσω του Uniform Resource Identifier(URI), ενώ το δεύτερο όρισμα αναφέρεται στο χρόνο τον οποίο θέλουμε ο UnitServiceClient να παραμείνει εγγεγραμμένος στο ΕventSource. O feederclient, που αποτελεί στιγμιότυπο της κλάσης UnitServiceClient με EventSources τα FeederFrontPositionNotification, FeederBackPositionNotification και PieceInPositionANotification. Πρέπει να σημειωθεί ότι η εγγραφές γίνονται εφόσον έχει βρεθεί το σωστό Service. Για να εξασφαλιστεί αυτή η προϋπόθεση χρησιμοποιείται η μέθοδος waituntilserviceifound. Σχήμα 7.5 Αρχικοποίηση των ιδιοτήτων της DPWS συσκευής FeederDevice μέσω σύνδεσης(binding) στο Properties αρχείο Σχήμα 7.6 Αρχικοποίηση των ιδιοτήτων του Web Service που θα φιλοξενήσει η DPWS συσκευή FeederDevice μέσω σύνδεσης(binding) στο Properties αρχείο. 92

101 Σχήμα 7.7 Αρχικοποίηση της DPWS συσκευής FeederDevice. Στη συνέχεια γίνεται η αρχικοποίηση του feeder collector. Η κλάση UnitServiceCollector, όπως έχει αναφερθεί στο κεφάλαιο 6, ανάλογα με την αρχικοποίηση που έχει γίνει, στέλνει το μήνυμα της κάθε ειδοποίησης που λαμβάνει, στο κατάλληλο ελεγκτή. Υπενθυμίζεται ότι η μέθοδος bindnotificationwithmonitor χρησιμοποιείται για την αντιστοίχηση Event Source με ελεγκτή. Στην περίπτωση μας η αρχικοποίηση που γίνεται στον Collector του feeder φαίνεται στο σχήμα 7.8 και είναι η εξής: Τα μηνύματα ειδοποιήσεων του EventSource FeederFrontPositionNotification στέλνονται στην Monitor κλάση του Controller του Feeder. Τα μηνύματα ειδοποιήσεων του EventSource FeederBackPositionNotification στέλνονται στην Monitor κλάση του Controller του Feeder. Τα μηνύματα ειδοποιήσεων του EventSource PieceInPositionANotifications στέλνονται στην Monitor κλάση του Controller του Converter. Ο ελεγκτής FeederSR λαμβάνει μηνύματα ειδοποιήσεων από την Monitor κλάση FeederM και ανάλογα με το μήνυμα ειδοποίησης το οποίο λαμβάνει και το προγραμματισμό του, καλεί τις κατάλληλες μεθόδους της συσκευής. Τέλος να υπενθυμίσουμε ότι η πρόσβαση στις μεθόδους που προσφέρει ένα DPWS Device γίνεται μέσω της μεθόδου invoke που προσφέρει η κλάση UnitServiceClient. C. Βήμα προς βήμα ανάλυση των διεργασιών στη περίπτωση που ο Feeder φτάσει στη μπροστά θέση Σε αυτή την παράγραφο θα αναλύσουμε ακολουθιακά μία προς μία τις διεργασίες που λαμβάνουν χώρα όταν η συσκευή Feeder φτάσει στην μπροστά θέση. Η ανάλυση θα γίνει με βάση το σχήμα στο οποίο φαίνεται σχηματικά η ανταλλαγή μηνυμάτων μεταξύ των αντικειμένων του συστήματος σε συνδυασμό με τον πίνακα 7.1. Ο συγκεκριμένος πίνακας προσφέρει μία επεξήγηση των 93

102 λειτουργιών που λαμβάνουν χώρα με βάση την σειρά την οποία απεικονίζονται στο σχήμα Σχήμα 7.8 Αρχικοποίηση των κλάσεων feederclient, feedercollector και feedersr. Σχήμα 7.9 Αρχικοποίηση του EventSink της κλάσης feederclient μέσω σύνδεσης με configuration id. Σχήμα 7.10 Αρχικοποίηση του HTTPBinding που χρησιμοποιεί το EventSink της κλάσης feederclient. Σε αυτό το σημείο πρέπει να αναφέρουμε ότι επειδή το σύστημα αποτελείται από νήματα η ακολουθία των λειτουργιών που παρουσιάζουμε στον πίνακα 7.1 δεν είναι απόλυτη. Σε οποιοδήποτε άλλο σενάριο λειτουργίας θα ακολουθούνταν οι αντίστοιχες διαδικασίες αλλά με διαφορετική σειρά. 94

103 Σχήμα Διάγραμμα ακολουθίας του συνολικού συστήματος στην περίπτωση ο η συσκευή Feeder φτάσει στην μπροστά θέση. Βήματα λειτουργιών 1. Ο Feeder στέλνει την ειδοποίηση ότι βρίσκεται στην μπροστά θέση στην κλάση UnitService. 2. Η κλάση ανάλογα με την ειδοποίηση που πήρε επιλέγει το κατάλληλο Event Sink και στέλνει την ειδοποίηση στους πελάτες μέσω της μεθόδου fire που προσφέρει το Event Sink. 3. Ο Feeder στέλνει την ειδοποίηση ότι το τεμάχιο βρίσκεται στη θέση A. 4. Η κλάση ανάλογα με την ειδοποίηση που πηρέ «επιλέγει» το κατάλληλο Event Sink και στέλνει την ειδοποίηση στους πελάτες μέσω της μεθόδου fire που αυτό προσφέρει. 5. O Feeder ζητά νέα εντολή από την κλάση επόπτη. 95

104 6. Ο Feeder μπαίνει σε κατάσταση αναμονής. 7. Ο Client του Feeder ειδοποιείται για το γεγονός ότι ο Feeder έχει φτάσει στην μπροστά θέση μέσω της μεθόδου ανάκλησης eventreceived. 8. Ο Client του Feeder στέλνει στην κλάση feederservicemonitor το αλφαριθμητικό της ειδοποίησης. 9. Ο ελεγκτής του Feeder, FeederSR τελειώνει τις προηγούμενες εργασίες του και ζητά νέο μήνυμα ειδοποίησης. 10. Ο επόπτης δεν έχει νέο μήνυμα οπότε ο ελεγκτής μπαίνει σε κατάσταση αναμονής. 11. Ο ελεγκτής του Converter, Converter SR τελειώνει τις προηγούμενες εργασίες του και ζητά νέο μήνυμα ειδοποίησης. 12. Ο επόπτης δεν έχει νέο μήνυμα οπότε ο ελεγκτής μπαίνει σε κατάσταση αναμονής. 13. Το νήμα της κλάσης FeederCollector ολοκληρώνει τις προηγούμενες εργασίες του και ζητά νέο μήνυμα ειδοποίησης. 14. Η κλάση feederservicemonitor πριν δώσει το νέο μήνυμα καλεί την μέθοδο findentryinlistwithexpectedcommandno για να εντοπίσει αν υπάρχει το αναμενόμενο μήνυμα στην εσωτερική λίστα της κλάσης. 15. Το αναμενόμενο μήνυμα έχει έρθει και στέλνεται στον feedercollector. 16. Ο feedercollector στέλνει το μήνυμα ειδοποίησης στη κλάση feederμ. 17. Καλείται η μέθοδος notify για να αφυπνιστούν τα νήματα που είναι σε κατάσταση αναμονής. 18. Ο ελεγκτής του Feeder feedersr λαμβάνει το μήνυμα ειδοποίησης και ακολουθεί τον αλγόριθμο ελέγχου. 19. Η διαδικασία ελέγχου υπαγορεύει να μετακινηθεί ο Feeder προς τα πίσω, αρά καλείται η μέθοδος invokeoperation της κλάσης feederclient με το κατάλληλο όρισμα. 20. Ανάλογα με το όρισμα της μεθόδου invokeoperation η κλάση επιλέγει πoία από της μεθόδους του Service θα καλέσει. Η κλήση θα γίνει μέσω της μεθόδου invoke του κατάλληλου Operation. 21. O FeederCollector ζητά νέα ειδοποίηση από τον επόπτη. 22. Η κλάση feederservicemonitor δεν περιέχει νέα ειδοποίηση όποτε ο feedercollector μπαίνει σε κατάσταση αναμονής. 23. Ο Client του Feeder ειδοποιείται για το γεγονός ότι το τεμάχιο βρίσκεται στην θέση Α. 24,25,26,27. Τα βήματα αυτά είναι αντίστοιχα με τα βήματα 13 έως 16 οπότε δεν θα αναλυθούν περαιτέρω. 28. Ο FeederCollector στέλνει το μήνυμα ειδοποίησης στη κλάση converterμ 29. Καλείται η μέθοδος notify για να αφυπνιστούν τα νήματα που είναι σε κατάσταση αναμονής. 30. Ο ελεγκτής του Converter ConverterSR λαμβάνει το μήνυμα ειδοποίησης και ακολουθεί τον αλγόριθμο ελέγχου. 31. Καλείται μέσω της μεθόδου invoke η μέθοδος MoveBack και στέλνεται το κατάλληλο μήνυμα στη κλάση feeder. 96

105 32. Καλείται η μέθοδος notify για να αφυπνιστούν τα νήματα που είναι σε κατάσταση αναμονής. 33. Η κλάση feederm πριν δώσει το νέο μήνυμα καλεί την μέθοδο FindEntryinListWithExpectedCommandNo δει αν το επόμενο μήνυμα που περιμένουμε έχει έρθει υπάρχει στη εσωτερική του λίστα. 34. Ο feeder λαμβάνει την εντολή «moveb» και εκτελεί τις κατάλληλες λειτουργίες. Πινάκας 7.1 Ανάλυση ακολουθίας λειτουργιών στην υλοποίηση ολικού απομακρυσμένου ελέγχου Υλοποίηση με Τοπικό και περιορισμένο απομακρυσμένο έλεγχο Η δεύτερη υλοποίηση εισάγει το στοιχείο του τοπικού ελέγχου και ακολουθεί την σχεδίαση με κεντρικό απομακρυσμένο ενορχηστρωτή και τοπικό έλεγχο που έχει παρουσιαστεί στην παράγραφο Festo MPS Σε αυτή την υλοποίηση, η DPWS διεπαφή της συσκευής που φαίνεται στο σχήμα 7.11, είναι όμοια με την πρώτη υλοποίηση που αναφέραμε στην παράγραφο 7.2. Η βασική διαφορά εστιάζεται στο ότι μεταξύ της DPWS διεπαφής και της διεπαφής επικοινωνίας της πραγματικής συσκευής παρεμβάλλεται ένα επίπεδο τοπικού ελέγχου. Ο τοπικός έλεγχος πραγματοποιείται από μία κλάση ελεγκτή η οποία δέχεται τις ειδοποιήσεις από το αισθητήρες της πραγματικής συσκευής και ανάλογα με τον προγραμματισμό του, στέλνει μηνύματα ελέγχου. Στη συνέχεια ανάλογα με την ειδοποίηση που θα λάβει από τους αισθητήρες της συσκευής, ο τοπικός ελεγκτής «αποφασίζει» αν θα διαχειριστεί ο ίδιος την ειδοποίηση ή θα την στείλει μέσω της DPWS διεπαφής στον απομακρυσμένο ενορχηστρωτή για να γίνει η διαχείριση σε έναν από τους ελεγκτές που περιλαμβάνει. Όσον αφορά τα μηνύματα ελέγχου η διεπαφή που παρέχει η συσκευή, την οποία μπορούμε να δούμε στο σχήμα 7.11 με την ονομασία execute command, χρησιμοποιείται τόσο από τον τοπικό ελεγκτή όσο και από την DPWS διεπαφή που μεταφέρει μηνύματα ελέγχου από τους απομακρυσμένους ελεγκτές. Ο συγκεκριμένος τρόπος λειτουργίας έχει ως αποτέλεσμα η πραγματική συσκευή να λαμβάνει μηνύματα ελέγχου που προέρχονται και από τον απομακρυσμένο και από τον τοπικό ελεγκτή. Η υλοποίηση αυτή, όπως αναφέρθηκε και στην σχεδίαση της, εξοικονομεί πόρους του συστήματος σε σημαντικό βαθμό περιορίζοντας τα μηνύματα ελέγχου και τις ειδοποιήσεις γεγονότων που μεταφέρονται μέσω του 97

106 δικτύου, αλλά περιορίζει το εύρος του απομακρυσμένου ελέγχου. Αυτό συμβαίνει διότι είναι λιγότερες οι λειτουργίες που προσφέρει η συσκευή ως διαθέσιμες στο δίκτυο μέσο του μηχανισμού των Web Services. Σχήμα 7.11 Διάγραμμα συνιστωσών της DPWS συσκευής με τοπικό έλεγχο Festo Control Η υλοποίηση του συστήματος στην πλευρά του πελάτη (Client side ) με βάση τον ολικό απομακρυσμένο έλεγχο είναι όμοια με την υλοποίηση με βάση τον τοπικό και περιορισμένο απομακρυσμένο έλεγχο. Η πρόσβαση στις μεθόδους και στις πηγές γεγονότων που προσφέρουν οι DPWS συσκευές γίνεται μέσω της κλάσης UnitServiceClient ενώ η διαδικασία ελέγχου πραγματοποιείται μέσω των προσωπικών νημάτων ελέγχου της κάθε συσκευής. Η επικοινωνία μεταξύ UnitServiceClient και της κλάσης ελεγκτή γίνεται χρησιμοποιώντας το μοντέλο του παραγωγού-καταναλωτή το οποίο έχει υλοποιηθεί με την χρήση κλάσεων εποπτών(monitor). Μια σημαντική παρατήρηση σε αυτό το σημείο είναι ότι το ενδιάμεσο στάδιο, το οποίο παρεμβάλλεται μεταξύ του νήματος ελέγχου και της κλάσης UnitServiceClient και χρησιμοποιείται για να αντιμετωπιστούν τα προβλήματα που προκύπτουν από 98

107 την μετάδοση μηνυμάτων μέσω του δικτυού, δεν είναι απαραίτητο σε αυτήν την υλοποίηση. Αυτό συμβαίνει επειδή, λόγω του τοπικού ελέγχου δεν υπάρχουν περιπτώσεις που δυο μηνύματα ειδοποιήσεων στέλνονται το ένα μετά το άλλο. Υπενθυμίζουμε ότι σε αυτή τη περίπτωση συναντάμε το πρόβλημα της αναδιάταξης. Παρόλα αυτά, για λόγους πληρότητας θα παραμένει στη υλοποίηση ώστε το σύστημα να μπορεί να ανταποκριθεί σε οποιοδήποτε σενάριο λειτουργίας στο οποίο μπορεί να παρουσιάζονται τέτοιου είδους προβλήματα. Αναλυτικότερα το πρόβλημα της ανακατάταξης της σειράς των λήψεων δεν παρουσιάζεται γιατί η διαχείριση των λειτουργιών ελέγχου οι οποίες μπορούν να προκαλέσουν αλλαγές στην ακολουθία των μηνυμάτων κατά τη μεταφορά τους μέσα από το δίκτυο γίνεται τοπικά. Σε αυτό το σημείο πρέπει να αναφέρουμε ότι αν και το πρόβλημα της αναδιάταξης δεν υπάρχει, το πρόβλημα της ετεροχρονισμένης λήψης ειδοποιήσεων, που παρουσιάστηκε στην παράγραφο 5.5.3, εξακολουθεί να υπάρχει. Αυτό σημαίνει ότι λειτουργία των Collector κλάσεων πρέπει να υπάρχει και σε αυτή την υλοποίηση. Η σημαντική διάφορα αυτής της υλοποίησης στην πλευρά του πελάτη σε σχέση με την υλοποίηση που παρουσιάσαμε στη παράγραφο 7.2 εστιάζεται στην λειτουργία των ελεγκτών (Controllers). O έλεγχος που γίνεται από τους απομακρυσμένους ελεγκτές μέσω των UnitServiceClient κλάσεων είναι πολύ πιο περιορισμένος αφού μεγάλο μέρος του ελέγχου γίνεται τοπικά με αποτέλεσμα να χρειάζονται λιγότερες έγραφες στα EventSources των συσκευών και τα νήματα ελέγχου να καταναλώνουν λιγότερους πόρους αφού εκτελούν λιγότερες λειτουργίες Μελέτη περίπτωσης του Feeder Για την καλύτερη κατανόηση της λειτουργίας του συστήματος, παραθέτουμε: A. Αναλυτική περιγραφή της διαδικασία αρχικοποίησης της DPWS διεπαφής του Feeder από την πλευρά του εξυπηρετητή B. Αναλυτική περιγραφή της διαδικασίας αρχικοποίησης του UnitServiceClient καθώς και του απομακρυσμένου ελεγκτή του Feeder από την πλευρά του πελάτη. C. Βήμα προς βήμα ανάλυση των διεργασιών που τελούνται σε όλο το σύστημα στη περίπτωση που ο Feeder φτάσει στην μπροστά θέση. Για να γίνει σωστά η διαδικασία της αρχικοποίησης της συσκευής πρέπει να καταγράψουμε μία λίστα από ενέργειες τις οποίες θέλουμε να εκτελεί η συσκευή. Αυτές η ενέργειες αθροιστικά αποτελούν την συνολική συμπεριφορά της συσκευής. Στη περίπτωση του Feeder οι ενέργειες οι οποίες θέλουμε να εκτελούνται είναι οι εξής: 99

108 Αν υπάρξει ειδοποίηση από αισθητήρα ότι o feeder βρίσκεται στην πίσω θέση, τότε δώσε εντολή να κινηθεί προς τα μπροστά. Αν υπάρξει ειδοποίηση από αισθητήρα ότι o feeder βρίσκεται στην μπροστά θέση, τότε δώσε εντολή να σταματήσει και στη συνέχεια να κινηθεί προς τα πίσω. Αν υπάρξει ειδοποίηση από τον αισθητήρα ότι υπάρχει τεμάχιο στην θέση Α, τότε ειδοποίησε τον Converter. Μόνο οι λειτουργίες ελέγχου οι οποίες αφορούν την επικοινωνία και το συντονισμό διαφορετικών συσκευών γίνονται με απομακρυσμένο έλεγχο. Οι «εσωτερικές» διεργασίες ελέγχου πραγματοποιούνται από τον τοπικό ελεγκτή. A. Αρχικοποίηση της DPWS συσκευής του Feeder και του τοπικού ελεγκτή Η διαδικασία αρχικοποίησης παρουσιάζει αρκετές αλλαγές σε σχέση με διαδικασία που ακολουθήθηκε στη σχεδίαση με πλήρη απομακρυσμένο έλεγχο. Μία σημαντική αλλαγή είναι ότι μόνο οι λειτουργίες ελέγχου οι οποίες αφορούν την επικοινωνία μεταξύ διαφορετικών συσκευών γίνονται με απομακρυσμένο έλεγχο, ενώ μόνο οι ειδοποιήσεις η οποίες χρειάζονται για τις διαδικασίες συντονισμού μεταξύ διαφορετικών συσκευών είναι απαραίτητο να υλοποιούνται ως EventSources. Με βάση αυτές τις συνθήκες η μοναδική λειτουργία την οποία πρέπει να προσφέρει η συσκευή ως υπηρεσία είναι κίνηση του Feeder προς τα εμπρός, ενώ τα γεγονότα τα οποία έχουν χρηστική σημασία για απομακρυσμένους ελεγκτές και είναι απαραίτητο να υλοποιούνται ως ΕventSources είναι τα FeederBackPositionNotification και PieceinPositionANotification. Η ειδοποίηση FeederBackPositionNotification στέλνεται κάθε φορά που ο Feeder φτάνει στην πίσω θέση και PieceinPositionANotification στέλνεται κάθε φορά που ένα τεμάχιο έχει φτάσει στη θέση από την οποία θα το παραλάβει ο Converter. Με βάση την εισαγωγική ανάλυση που έγινε στη αρχή της παραγράφου και λαμβάνοντας υπόψη το πίνακα 4.2 ο οποίος περιέχει την αντιστοίχηση μεταξύ γεγονότων και αισθητήρων συμπεραίνουμε ότι η διαχείριση της ειδοποίησης FeederFrontPositionNotification θα γίνεται από το τοπικό ελεγκτή ενώ η διαχείριση των ειδοποιήσεων FeederBackPositionNotification και PieceinPositionANotification γίνεται από τον απομακρυσμένο ελεγκτή. Όσον αφορά τις λειτουργίες που προσφέρουν οι ενεργοποιητές μέσω της διεπαφής ελέγχου της συσκευής, οι λειτουργίες MoveBack και Stop είναι ορατές μόνο από τον τοπικό ελεγκτή ενώ οι λειτουργία MoveForward είναι ορατή στο δίκτυο μέσω της DPWS διεπαφής. Την υλοποίηση της παραπάνω ανάλυσης βέπουμε στο σχήμα

109 Σχήμα 7.12 Διαδικασία αρχικοποίησης της DPWS συσκευής FeederDevice Σχήμα 7.13 Αρχικοποίηση της κλάσης feederclient, feedercollector και feedersr B. Αρχικοποίηση πελάτη και απομακρυσμένου ελεγκτή Η διαδικασία αρχικοποίησης του πελάτη είναι όμοια με την διαδικασία αρχικοποίησης της κλάσης feederclient που περιγράψαμε στην υλοποίηση με ολικό απομακρυσμένο έλεγχο και επομένως δεν θα επεκταθούμε περεταίρω. Πρέπει όμως να σημειώσουμε ότι μόνο οι λειτουργίες ελέγχου, οι οποίες αφορούν την επικοινωνία και το συντονισμό διαφορετικών συσκευών γίνονται με απομακρυσμένο έλεγχο. Επομένως οι μόνες ειδοποιήσεις οι όποιες είναι απαραίτητες για τον συντονισμό του feeder με τις υπόλοιπες συσκευές είναι οι FeederBackPositionNotification, η οποία στέλνεται κάθε φορά που ο Feeder φτάνει στην πίσω θέση, και η PieceinPositionANotification, η οποία στέλνεται κάθε φορά που ένα τεμάχιο έχει φτάσει στη θέση από την οποία θα το παραλάβει ο Converter. Συνεπώς έχουμε λιγότερες έγγραφες (subscriptions) σε σχέση με αυτές που είχαμε στην προηγούμενη υλοποίηση. Όσον αφορά τον απομακρυσμένο ελεγκτή, έχει πολύ περιορισμένες αρμοδιότητες σε σχέση με την υλοποίηση της παραγράφου 7.2. Η διαδικασία ελέγχου την οποία υλοποιεί 101