ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ. του φοιτητή του Τμήματος Ηλεκτρολόγων Μηχανικών και. Τεχνολογίας Υπολογιστών της Πολυτεχνικής σχολής του Πανεπιστημίου Πατρών:

ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΑΤΡΩΝ ΠΟΛΥΤΕΧΝΙΚΗ ΣΧΟΛΗ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ & ΤΕΧΝΟΛΟΓΙΑΣ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ: ΗΛΕΚΤΡΟΝΙΚΗΣ ΚΑΙ ΥΠΟΛΟΓΙΣΤΩΝ ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ του φοιτητή του Τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών της Πολυτεχνικής σχολής του Πανεπιστημίου Πατρών: Μάρκος Χανδράς Αριθμός Μητρώου:5802 Θέμα: «Χρήση Real Time Linux για την ανάπτυξη embedded συστημάτων» Επιβλέπων: Κλεάνθης Θραμπουλίδης ΠΑΤΡΑ, ΙΟΥΛΙΟΣ 2009

ΠΙΣΤΟΠΟΙΗΣΗ Πιστοποιείται ότι η διπλωματική εργασία με θέμα: «Χρήση Real Time Linux για την ανάπτυξη embedded συστημάτων» του φοιτητή του τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών Χανδρά Μάρκου του Ιωάννη (Α.Μ. 5802) παρουσιάστηκε δημόσια και εξετάστηκε στο τμήμα Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών στις 10/07/2009 Κ. Θραμπουλίδης Καθηγητής Ο Διευθυντής του Τομέα K. Γκούτης Kαθηγητής Ο Επιβλέπων

Αριθμός Διπλωματικής Εργασίας: Τίτλος: Χρήση Real Time Linux για την ανάπτυξη embedded συστημάτων Φοιτητής: Μάρκος Χανδράς Επιβλέπων: Κλεάνθης Θραμπουλίδης Περίληψη Το πρότυπο IEC61499 ορίζει το Function Block ως νέο τρόπο ανάπτυξης συστημάτων ελέγχου και αυτοματισμού. Τα συστήματα αυτά αποτελούνται από κατανεμημένες, ενσωματωμένες συσκευές οι οποίες διασυνδέονται μέσω βιομηχανικών δικτύων πραγματικού χρόνου. Λόγω του κατανεμημένου χαρακτήρα των συστημάτων αυτών, η εύρεση και επιδιόρθωση σφαλμάτων και ο έλεγχος της ορθής λειτουργίας τους θα πρέπει να γίνεται στο περιβάλλον των ενσωματωμένων αυτών συστημάτων. Στα πλαίσια αυτής της διπλωματικής δίνεται μία υλοποίηση για την κάλυψη της παραπάνω ανάγκης. Ο χρήστης μέσω μίας γραφικής διεπαφής, έχει την δυνατότητα να εκτελεί βασικές λειτουργίες απασφαλμάτωσης στο περιβάλλον των ενσωματωμένων συστημάτων, σε πραγματικό χρόνο, με την χρήση του RTAI και του RTnet.

Πίνακας περιεχομένων Πρόλογος... 7 Κεφάλαιο 1: Εισαγωγή... 9 Κεφάλαιο 2: Σύγχρονες τεχνικές έλεγχου στη Βιομηχανία...13 Η χρήση των PLC στον αυτόματο έλεγχο...13 To IEC61499 Execution environment...17 Embedded Linux στον έλεγχο...21 Κεφάλαιο 3: To Real Time Linux...22 Το Real Time Application Interface...22 RTAI AXE... 23 To Real Time Networking...24 Kεφάλαιο 4: Ολοκληρωμένες λύσεις σε λειτουργία...26 Κεφάλαιο 5: Σχεδιασμός συστήματος...33 Περιγραφή των συσκευών της MASMEC...33 Χαρακτηριστικά συσκευών...33 Η κατανεμημένη εφαρμογή...35 Σχεδιασμός εφαρμογής...35 Το layer του δαίμονα...36 Daemon Service... 37 IPCPNode Service... 37 Γραφικό Εργαλείο ελέγχου...40 Κεφάλαιο 6: Χρήση της εφαρμογής...41 Δαίμονας... 41 Γραφική εφαρμογή...42 Kεφάλαιο 7: Πηγαίος κώδικας...45 Δαίμονας... 45 Γραφικός debugger...51

Κεφάλαιο 8: Συμπεράσματα και μελλοντική εργασία...74 Βιβλιογραφία... 75 Πρόλογος Η διπλωματική αυτή έγινε το διάστημα 2008-2009 στο εργαστήριο Συστημάτων Υπολογιστών του τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών υπό την επίβλεψη του καθηγητή Κ. Θραμπουλίδη. Θα ήθελα να ευχαριστήσω θερμά τον κ. Κλεάνθη Θραμπουλίδη για την εμπιστοσύνη που μου έδειξε στην ανάθεση αυτής της διπλωματικής. Οι συμβουλές του κατά την πορεία της διπλωματικής ήταν πολύτιμες για μένα και κέρδισα αρκετές εμπειρίες για την μελλοντική μου καριέρα. Θα ήθελα επίσης να ευχαριστήσω τον Γιώργο Δούκα για την υπομονή του και την πολύτιμη βοήθεια που μου πρόσφερε καθ όλη την πορεία εκπόνησης της διπλωματικής μου εργασίας. Θα ήθελα επίσης να τον ευχαριστήσω για την εξαιρετική δουλειά που είχε κάνει στο παρελθόν, την οποία χρησιμοποίησα ως βάση για την δική μου διπλωματική.

Κεφάλαιο 1: Εισαγωγή Η διαδύνδεση των ενσωμετωμένων συσκευών που χρησιμοποιούνται στην περιοχή του αυτοματισμού και ελέγχου γίνεται μέσω των βιομηχανικών δικτύων. Τα βιομηχανικά δίκτυα αποτελούν μία υποκατηγορία των τοπικών δικτύων υπολογιστών με συγκεκριμένες απαιτήσεις και προδιαγραφές. Ο σκοπός των δικτύων αυτών να αποτελέσουν την βάση για σύγχρονα, ευέλικτα και αποδοτικά συστήματα αυτοματοποίησης. Στα συστήματα αυτά απαιτείται η αξιόπιστη διασύνδεση ετερογενών μονάδων, όπως υπολογιστικά συστήματα γενικού ή/και ειδικού σκοπού όπως προγραμματιζόμενοι λογικοί ελεγκτές, αισθητήρες, ενεργοποιητές και άλλα. Η κύρια λειτουργική απαίτηση που πρέπει να ικανοποιούν τα προηγμένα συστήματα αυτοματοποίησης είναι η εξασφάλιση της δυνατότητες απόκρισης τους σε πραγματικό χρόνο. Ως εκ τούτου, τα βιομηχανικά δίκτυα υπολογιστών, που παρέχουν την υποδομή κατανεμημένων συστημάτων αυτοματοποίησης, θα πρέπει να 1 εξασφαλίζουν την δικτυακή απόκριση σε πραγματικό χρόνο. Είναι σύνηθες στα βιομηχανικά δίκτυα να χρησιμοποιούνται embedded συστήματα. Τα embedded συστήματα είναι υπολογιστές ειδικού σκοπού σχεδιασμένοι για πραγματοποιούν μία ή περισσότερες συγκεκριμένες λειτουργίες, συνήθως με απαιτήσεις πραγματικού χρόνου. Κάθε embedded σύστημα αποτελείται από το υλικό ( hardware ) και τα μηχανικά μέρη ( mechanical parts ) τα οποία αποτελούν τις εισόδους/εξόδους του συστήματος. Η επιλογή των embedded συστημάτων στα βιομηχανικά συστήματα γίνεται λόγο της αξιοπιστίας που αυτά προσφέρουν στο σύστημα. Τα embedded συστήματα μπορούν και λειτουργούν συνέχεια, για χρόνια. Σε περίπτωση σφάλματος πολλά από αυτά μπορούν και ανακάμπτουν μόνα τους και συνεχίζουν να λειτουργούν. Η κατανάλωση ρεύματος είναι μικρή, καθιστώντας έτσι την λειτουργία τους οικονομική. Παράλληλα, τα embedded συστήματα χρησιμοποιούν flash μνήμες ως αποθηκευτικά μέσα. Η μη χρήση μηχανικών αποθηκευτικών μέσων έχει ως αποτέλεσμα την μεγάλη ταχύτητα εκτέλεσης των προγραμμάτων με μικρότερη πιθανότητα λάθους. Έτσι, τα προγράμματα τρέχουν με πολύ μεγάλες ταχύτητες και με μικρότερη πιθανότητα εμφάνισης σφαλμάτων. Το λειτουργικό σύστημα Linux2 και συγκεκριμένα το Embedded Linux3 είναι αυτό που κυριαρχεί στα ενσωματωμένα συστήματα. Το embedded Linux σε αντίθεση με το Linux, που έχει σχεδιαστεί να τρέχει σε servers και προσωπικούς υπολογιστές, έχει σχεδιαστεί για να χρησιμοποιείται σε συσκευές με σχετικά λίγους πόρους. Λόγο της

ανάγκης για ελαχιστοποίηση του μεγέθους και του κόστους, οι ενσωματωμένες συσκευές έχουν πολύ λίγη RAM και ελάχιστο χώρο για αποθήκευση δεδομένων. Η ευκολία που δίνει το Linux στην παραμετροποίηση του, επιτρέπει στους κατασκευαστές embedded συστημάτων να το προσαρμόσουν στις ανάγκες τις κάθε συσκευής και εφαρμογής. Ακριβώς επειδή κάθε embedded σύστημα, επιτελεί συνήθως μόνο μια λειτουργία, οι κατασκευαστές τροποποιούν τον πυρήνα του Linux έτσι ώστε να περιλαμβάνει μόνο τα απαραίτητα κομμάτια που είναι απαραίτητα για την συγκεκριμένη λειτουργία. Παράλληλα, οι νέοι πυρήνες επιτρέπουν την εισαγωγή κάποιων real-time στοιχείων. Τα real-time multithreading, λειτουργικά ( RTOS ) που κάνουν χρήση του χρησιμοποιούνται στην ανάπτυξη real-time εφαρμογών. Μόνο και μόνο η χρήση RTOS δεν εγγυάται ότι το αποτέλεσμα θα είναι realtime. Η ανάπτυξη σωστού λογισμικού που θα εκμεταλλεύεται πλήρως τις δυνατότητες του RTOS είναι ευθύνη του προγραμματιστή. Τα RTOS δεν αυξάνουν την ταχύτητα εκτέλεσης των προγραμμάτων αλλά εισάγουν την έννοια του deadline, δηλαδή εισάγουν χρονικά όρια στην εκτέλεση των διαφόρων εντολών. Επίσης, τα RTOS υποστηρίζουν πολλαπλές εφαρμογές με πολλαπλές εισόδους και εξόδους καθώς επίσης χρησιμοποιούν πλήρως τις δυνατότητες των νέων υπολογιστών και τις νέες αρχιτεκτονικές δικτύων. Ακριβώς τα παραπάνω πλεονεκτήματα των RTOS είναι αυτά που εκμεταλλεύτηκαν οι κατασκευαστές με την εισαγωγή των RTOS στα embedded συστήματα. Στα σύγχρονα βιομηχανικά δίκτυα, η χρήση και μόνο RTOS δεν εξασφαλίζει τον real-time χαρακτήρα της εφαρμογής. Τα δίκτυα αυτά είναι συνήθως TCP/IP. Έτσι, ακόμα και αν η εφαρμογή που τρέχει στην κάθε ενσωματωμένη συσκευή είναι real-time, το δίκτυο που χρησιμοποιούν για την επικοινωνία τους δεν είναι. Ο περιορισμός αυτός κάμπτεται με την χρήστη του RtNet4. To RTnet εξασφαλίζει ευέλικτη επικοινωνία πραγματικού χρόνου, η οποία είναι ανεξάρτητη υλικού. Παράλληλα επιτρέπει πλήρη και διαφανή συμβατότητα με τα υπάρχοντα TCP/IP δίκτυα. Αυτό σημαίνει ότι η κάθε συσκευή μπορεί και είναι συνδεδεμένη και στα δύο δίκτυα παράλληλα χρησιμοποιώντας μία μόνο συσκευή δικτύου. Η δυνατότητα αυτή προσέφερε πολλά πλεονεκτήματα τα οποία θα αναλυθούν εκτενώς στην συνέχεια. Στην διπλωματική αυτή παρουσιάζεται μία υλοποίηση για το debugging κατανεμημένων βιομηχανικών εφαρμογών που τρέχουν σε ενσωματωμένα συστήματα. Η εφαρμογές αυτές χρησιμοποιούν την τεχνολογία των Function blocks όπως αυτά ορίζονται στο πρότυπο IEC 61499. Η υλοποίηση αυτή μπορεί και αλλάζει τις τιμών των μεταβλητών της εφαρμογής κατά το runtime, καθώς επίσης μπορεί

και παρακολουθεί τις τιμές των μεταβλητών και σημάτων που θέλει ο χρήστης. Η εξασφάλιση του real time γίνεται με την χρήστη του RTAI το οποίο δίνει την δυνατότητα στον προγραμματιστή να αναπτύξει real time εφαρμογές. Ειδικά για κατανεμημένες εφαρμογές οι οποίες τρέχουν σε ενσωματωμένα συστήματα, το debugging πρέπει να γίνεται σε πραγματικό χρόνο και αξιοπιστία σε κάθε συσκευή. Για την αντιμετώπιση αυτής της real time απαίτησης σε επίπεδο δικτύου χρησιμοποιήθηκε το RTnet. Με την χρήση του RTnet διασφαλίζεται η προϋπόθεση του αυστηρού πραγματικού χρόνου σε επίπεδο δικτύου, που όπως αναφέρθηκε προηγουμένως είναι κρίσιμης σημασίας. Παράλληλα, χρησιμοποιήθηκε η πλατφόρμα GNU/Linux όπου σε συνδυασμό με το RTAI, εξασφάλισε πραγματικό χρόνο σε επίπεδο εφαρμογής. Η ανταλλαγή πακέτων μεταξύ των συσκευών πάνω από το RTnet δίκτυο έγινε χρησιμοποιώντας Unix TCP/IP Sockets 5 τα οποία εξασφαλίζουν πλήρη posix συμβατότητα. Τέλος, ένα γραφικό εργαλείο βασισμένο στην Qt46 πλατφόρμα, επιτρέπει στον χρήστη τον έλεγχο του κεντρικού υπολογιστή και κατ επέκταση ολόκληρου του δικτύου. Στο δεύτερο κεφάλαιο παρουσιάζονται μερικές από τις σύγχρονες τεχνικές ελέγχου στην βιομηχανία δίνοντας έμφαση στα συστήματα που κάνουν χρήση των PLC καθώς επίσης και στο IEC 1131. Παράλληλα, παρουσιάζεται το πρότυπο 61499, πάνω στο οποίο βασίζεται η πλατφόρμα ανάπτυξης που χρησιμοποιήθηκε στην παρούσα διπλωματική. Στο τρίτο κεφάλαιο παρουσιάζεται αναλυτικά το περιβάλλον ανάπτυξης εφαρμογών πραγματικού χρόνου σε λειτουργικά συστήματα GNU/Linux. Το περιβάλλον αυτό προσθέτει real time εργαλεία σε επίπεδο πυρήνα, χρησιμοποιώντας έναν micro kernel, που τρέχει παράλληλα με τον Linux kernel, ο οποίος είναι υπεύθυνος στον χειρισμό των real time processes. Παράλληλα, μια τροποποιημένη έκδοση του HAL7 φροντίζει για την λήψη και αποστολή δεδομένων και σημάτων μεταξύ των real time εφαρμογών. Τέλος παρουσιάζεται το RTnet που χρησιμοποιήθηκε στην υλοποίηση ενός real time δικτύου μέσω του οποίου συνδέονται οι συσκευές μεταξύ τους. Στο τέταρτο κεφάλαιο, παρουσιάζονται κάποιες εναλλακτικές υλοποιήσεις που χρησιμοποιούν διάφορες εταιρίες για να κάνουν debug τις εφαρμογές στα ενσωματωμένα συστήματα. Οι υλοποιήσεις αυτές μπορεί να είναι γραφικά εργαλεία ή προγράμματα κονσόλας, και η επιλογής τους βασίζεται στις εκάστοτε ανάγκες που έχει ο χρήστης. Στο πέμπτο κεφάλαιο, παρουσιάζονται αναλυτικότερα τα εργαλεία που χρησιμοποιήθηκαν στην υλοποίηση όπως τα χαρακτηριστικά των ενσωματωμένων συσκευών και η κατανεμημένη

εφαρμογή που τρέχει σε αυτά. Δίνεται η σχεδίαση του συστήματος που αναπτύχθηκε προκειμένου να λύσει το πρόβλημα του debugging στην κατανεμημένη αυτήν εφαρμογή. Στο κεφάλαιο έξι, παρουσιάζεται τόσο η χρήση του δαίμονα όσο και του γραφικού εργαλείου ώστε ο χρήστης να κατανοήσει τον τρόπο λειτουργίας του εύκολα και γρήγορα. Στο κεφάλαιο εφτά, αναλύεται διεξοδικά ο κώδικας τόσο του κεντρικού κόμβου όσο και της γραφικής διεπαφής που τον ελέγχει, δίνοντας έμφαση στον τρόπο που αυτά τα δύο αλληλεπιδρούν μεταξύ τους. Στο κεφάλαιο οχτώ δίνονται τα συμπεράσματα που προέκυψαν μετά την υλοποίηση και χρήση του συστήματος που αναπτύχθηκε καθώς και μερικές βελτιώσεις που θα μπορούσαν να γίνουν στο μέλλον.

Κεφάλαιο 2: Σύγχρονες τεχνικές έλεγχου στη Βιομηχανία Το θέμα του ελέγχου των βιομηχανικών συστημάτων (Industrial Control System ) έκανε έντονη την εμφάνιση του πριν από τρεις με τέσσερις δεκαετίες. Τα κατανεμημένα συστήματα ελέγχου (Distributed Control Systems) αναφέρονται σε ένα μεμονωμένο λειτουργικό στοιχείο ελέγχου το οποίο βρίσκεται σε βιομηχανικά συστήματα παραγωγής ( Πετρελαιοβιομηχανίες, Χημικές διεργασίες, Μονάδες επεξεργασίας νερού κ.α. ). H ιδέα για την χρησιμοποίηση DCS προήλθε από την ανάγκη παρακολούθησης δεδομένων καθώς και τον έλεγχο συστημάτων, τα οποία βρίσκονται διάσπαρτα σε μια παραγωγική διαδικασία, η οποία έπρεπε να γίνεται σε πραγματικό χρόνο, με το μεγαλύτερο δυνατό εύρος μεταφοράς, και με την λιγότερη δυνατή καθυστέρηση. Η χρήση των PLC στον αυτόματο έλεγχο Οι προγραμματιζόμενοι λογικοί ελεγκτές ( Programmable Logic Controller ) (Εικόνα 1) οι οποίοι χρησιμοποιήθηκαν στην αρχή, ήταν εξοπλισμένοι κατάλληλα για την αντιμετώπιση περιβαλλοντικών συνθηκών όπως σκόνη, βροχή, ζέστη κτλ. Αυτός ο εξοπλισμός, τους καθιστούσε κατάλληλους για τον έλεγχο real time εφαρμογών αφού οι συνθήκες περιβάλλοντος δεν επηρέαζαν καθόλου την λειτουργία τους. Οι πολλαπλές είσοδο/έξοδοι σε συνδυασμό με τους αισθητήρες και τους μηχανικούς διακόπτες προσέφεραν στον μηχανικό την ευελιξία για τον έλεγχο μεγάλου εύρους εφαρμογών. Εικόνα 1:Διάταξη PLC πολλαπλών εισόδων/εξόδων

Οι προγραμματιζόμενοι λογικοί ελεγκτές χρησιμοποιήθηκαν για τον έλεγχο ηλεκτροκινητήρων, πνευματικών και υδραυλικών κυλίνδρων, μαγνητικά ρελέ και αναλογικών εξόδων. Η κάθε συσκευή PLC μπορεί να φέρει πάνω της μια συστοιχία εισόδων/εξόδων. Τέλος, υπάρχουν ειδικές κάρτες που προσφέρουν επιπρόσθετες εισόδους/εξόδους ( Εικόνα 2 ). Εικόνα 2:Κάρτες επέκτασης PLC

Τα συστήματα PLC έχουν πολλαπλές εισόδους και εξόδους επικοινωνίας όπως, RS2328, RS48, Ethernet, Modbus10 και BACnet11 και άλλα. Σε μεγάλα συστήματα, τα PLC μπορεί να έχουν άμεση επικοινωνία με τους επεξεργαστές. Αυτό επιτρέπει τον καταμερισμό του ελέγχου των πολύπλοκων διεργασιών επιτρέποντας παράλληλα στα υποσυστήματα να συντονίζονται μεταξύ τους πάνω από το link επικοινωνίας. Οι διασυνδέσεις αυτές χρησιμοποιούνται συχνά από τις γραφικές διεπαφές μέσω των οποίων ο χρήστης μπορεί και ελέγχει το σύστημα. Τα PLC συνδέονται συνήθως σε συστήματα SCADA12. Τα προγράμματα που εκτελούν οι PLC, γράφονται σε προσωπικούς υπολογιστές χρησιμοποιώντας ειδικές εφαρμογές και στην συνέχεια αποστέλλονται μέσω σειριακής σύνδεσης στο PLC. Το πρόγραμμα αποθηκεύεται συνήθως σε μνήμη RAM ή σε κάποια flash μνήμη. Σύμφωνα με το IEC 113113, ο προγραμματισμός των PLC μπορεί να γίνει με την χρήση οποιασδήποτε γλώσσας προγραμματισμού για PLC. Το πρότυπο αυτό ορίζει την σύνταξη, αναπαράσταση και εμφάνιση των παρακάτω γλωσσών προγραμματισμού Ladder diagram (LD) Sequential Function Charts (SFC) Function Block Diagram (FBD) Structured Text (ST) Instruction List (IL) Ένα από τα κύρια πλεονεκτήματα που προσέφερε αυτό το πρότυπο είναι ότι επιτρέπει την χρήση πολλαπλών γλωσσών προγραμματισμού σε ένα PLC. Αυτό επιτρέπει στον προγραμματιστή να διαλέξει γλώσσα προγραμματισμού ανάλογα με την λειτουργία που θέλει να εκτελεί ο PLC. Η ladder diagram γλώσσα προγραμματισμού, αναπαριστά το πρόγραμμα γραφικά βασισμένο σεκυκλωματικά διαγράμματα ( Εικόνα 3 )

Εικόνα 3:PLC ladder diagram Tα Function Blocks χρησιμποιούνται συχνά για την δημιουργία προγραμμάτων τα οποία θα εκτελούνται στα τερματικά ή στα PLC. Σε αντίθεση με τις κλασσικές γλώσσες προγραμματισμού όπως η C και η Fortran, ο προγραμματισμός χρησιμοποιώντας Function Block απαιτεί ελάχιστη εμπειρία από την πλευρά του προγραμματιστή. Tα Function Block διαγράμματα, είναι γραφικές αναπαραστάσεις μεταξύ της αλληλεπίδρασης των εισόδων και των εξόδων ενός συστήματος. Σαν function ορίζεται ένα σύνολο από βασικά blocks. Οι είσοδοι ενώνονται με τις εξόδους μέσω συνδετικών γραμμών. Οι γραμμές αυτές είναι προσανατολισμένες και δείχνουν την ροή των δεδομένων. (Εικόνα 4 ). Εικόνα 4:Function Block diagram Το ΙEC 6149914 είναι ένα ανοιχτό πρότυπο για κατανεμημένο έλεγχο και αυτοματισμό που κάνει ευρεία χρήση των function blocks. To πρότυπο αυτό ορίζει τα function blocks σαν τις βασικές οντότητες που χρησιμοποιούνται για την ανάπτυξη μίας ολόκληρης εφαρμογής. Δύο είδη function block ορίζονται. Τα βασικά και τα σύνθετα. Τα σύνθετα FB περιέχουν και σύνθετα και βασικά function

blocks. Το βασικό function block περιέχει αλγορίθμους και ένα γράφημα ελέγχου ( ECC ). Τα function blocks έχουν εισόδους και εξόδους δεδομένων και σημάτων. Στα βασικά FB η εκτέλεση ενός αλγορίθμου ξεκινάει όταν ανιχνευθεί κάποιο σήμα ή στοιχείο δεδομένων στην είσοδο. Όταν τελειώσει η εκτέλεση του αλγορίθμου αυτού, τότε προκύπτει κάποιο στοιχείο για αποστολή στην έξοδο. To IEC61499 Execution environment Η προτεινόμενη αρχιτεκτονική πλατφόρμα πάνω στην οποία βασίζεται η διπλωματική, επεκτείνει και τροποποιεί κατάλληλα το IEC μοντέλο από την πλατφόρμα CORFU15. Οι επεκτάσεις αυτές καλύπτουν θέματα τα οποία δεν υποστηρίζονται από το πρότυπο. Παράλληλα οι τροποποιήσεις που έγιναν βελτιώνουν την διαδικασία ανάπτυξης όσον αφορά τους παράγοντες της αξιοπιστίας, του χρόνου που απαιτεί η ανάπτυξη, και του βαθμού του αυτοματισμού16. Μία αφαιρετική σχεδίαση αυτής της πλατφόρμας παρουσιάζεται στην Εικόνα 5. Όπως φαίνεται, βασικά επίπεδα: η δομή του περιβάλλοντος αποτελείται Επίπεδο εφαρμογής ( Application Execution ) Πρωτόκολλο Protocol ) Μηχανική διεπαφή ( Mechanical Process Interface ) ελέγχου διεργασίας ( Industrial από Process τρία Control Εικόνα 5:Το execution environment σε συνδυασμό με τις διάφορες συσκευές Το πρώτο επίπεδο είναι υπεύθυνο για την παροχή εργαλείων που απαιτούνται για την αρχικοποίηση και εκτέλεση της εκάστοτε

εφαρμογής. Το δεύτερο επίπεδο παρέχει το βασικό επικοινωνίας μεταξύ των κόμβων με σκοπό να πετύχει επίπεδο Την συνεργασία μεταξύ των κόμβων έτσι ώστε να ικανοποιούνται οι απαιτήσεις επικοινωνίας σύμφωνα με κανόνες QoS ( Quality of Service ). Δυνατότητα κατεβάσματος νέων function δυνατότητα επαναρύθμισης των υπαρχόντων. Δυνατότητα επικοινωνίας με τους χειριστές τις εφαρμογής. blocks και Για την υλοποίηση του IPCP επιπέδου, χρησιμοποιήθηκε μια realtime έκδοση του Linux, το RTAI. Η επιλογή του RTAI θεωρήθηκε κατάλληλη αφού παρέχει ευκολίες σε θέματα QoS το οποίο είναι απαραίτητο σε real-time εφαρμογές. Παράλληλα υιοθετήθηκε το publish-subscribe μοντέλο το οποίο εξασφαλίζει την συμβατότητα με το IEC μοντέλο, παρέχει δυνατότητες QoS οι οποίες είναι απαραίτητες για τα κατανεμημένα συστήματα ελέγχου, επιτρέπει ευέλικτη αρχικοποίηση, λειτουργία και επαναρύθμιση των FB στους κόμβους ακόμα και κατά την διάρκεια της εκτέλεσης του προγράμματος. To ΙPCP προσφέρει τις παρακάτω λειτουργίες στο επίπεδο εκτέλεσης της εφαρμογής. Το περιβάλλον λειτουργίας ( Αpplication Execution Layer ) ΙEC61499 ικανοποιεί τις εξής απαιτήσεις: Δημιουργία νέων Function εκτέλεσης της εφαρμογής Δημιουργία νέων στιγμιότυπων των Function Blocks Δημιουργία νέων Event και Data διασυνδέσεων ή αλλαγή των υπαρχόντων Blocks κατά την διάρκεια της Έτσι σύμφωνα με τα παραπάνω, το περιβάλλον αποτελείται από τα εξής στοιχεία Deployment Management Entity ( DME ) Event Connection Manager ( ECM ) Data Connection Manager ( DCM ) FBType Repository Συλλογή με FB Containers ( FBC ). Η τοπολογία των παραπάνω φαίνεται παρακάτω ( Εικόνα 6 )

Εικόνα 6:Αρχιτεκτονική σχεδίαση του Application Execution layer ( AE ) Το δεύτερο επίπεδο επικοινωνίας είναι το IPCP το οποίο χρησιμοποιεί μηχανισμούς από το RTAI. Ο μηχανισμός επικοινωνίας του βασίζεται στο μοντέλο subscriber-publisher, το οποίο εξασφαλίζει συμβατότητα με το IEC μοντέλο, προσφέρει δυνατότητες QOS καθώς επίσης επιτρέπει ευέλικτη τροποποίηση του περιβάλλοντος ακόμα και κατά την διάρκεια της εκτέλεσης του. Το IPCP προσφέρει τις παρακάτω δυνατότητες στο AE επίπεδο: 1. RegisterExportedEvent or Data: Το Service αυτό χρησιμοποιείται από τον Deployment manager με σκοπό την κοινοποίηση ενός εσωτερικού στοιχείου δεδομένων ή συμβάν σε έναν απομακρυσμένο κόμβο. 2. RegisterImportedData or Event & Register Event or Data Subscriber: H λειτουργία αυτή χρησιμοποιείται από τον deployment manager με σκοπό την δημιουργία σύνδεσης με ένα απομακρυσμένο συμβάν ή στοιχείο δεδομένων. Όπως φαίνεται και στην εικόνα 15, το IPCP επίπεδο αποτελείται από τις παρακάτω οντότητες.

IPCP-Configuration Management Entity ( IPCP-CME ) Publisher Subscriber Event Channel Management Entity Το IPCP-CME, εκμεταλλευόμενο τις «εικονικές» συνδέσεις μεταξύ των publisher και των subscriber, παρέχει τις παρακάτω λειτουργίες: registerexportedevent(eventglobalid), εσωτερικό συμβάν. registerexporteddata(dataglobalid), στοιχείο δεδομένων. registerimportedevent( globaleventid, sublocaleventid, withdatalist), που εγγράφεται σε ένα κοινοποιημένο συμβάν registerimporteddata(globaldataid), κοινοποιημένο στοιχείο δεδομένων registereventsubscriber(globaleventid, withdatalist), εγγράφει έναν κόμβο συνδρομιτή σε ένα συμβάν registerdatasubscriber(globaldataid), που εγγράφει έναν κόμβο συνδρομιτή σε ένα στοιχείο δεδομένων που που που κοινοποιεί κοινοποιεί εγγράφεται σε ένα ένα ένα που Εικόνα 5:H δομή του IPCP επιπέδου

Embedded Linux στον έλεγχο Παρόλο που τα PLC προσφέρουν ολοκληρωμένες λύσεις ελέγχου και εποπτείας συστημάτων, εντούτοις υστερούν σημαντικά σε σχέση με τα ενσωματωμένα συστήματα. Η ανάπτυξη ενσωματωμένων συστημάτων είναι μια ακριβή διαδικασία κατά την φάση της σχεδίασης και της υλοποίησης. Όμως αφού το πρόγραμμα ολοκληρωθεί, η συντήρηση του απαιτεί μηδενικό κόστος και το κόστος της ανάπτυξης εύκολα αποσβένεται με την απόδοση των συστημάτων αυτών στην παραγωγή. Παράλληλα, η ευκολία παραμετροποίησης των embedded συστημάτων λόγο της χρήσης του Linux σαν λειτουργικό, κάνει τα ενσωματωμένα συστήματα ποιο ευέλικτα και ικανά να ικανοποιήσουν τις ανάγκες τις κάθε βιομηχανικής διεργασίας. H χρήση ενός λειτουργικού συστήματος ως βάση για την ανάπτυξη εφαρμογών, δίνει στον προγραμματιστή περισσότερη ευχέρεια και ευελιξία. Όπως ειπώθεαληκε και παραπάνω, τα PLC έχουν συγκεκριμένες γλώσσες προγραμματισμού βάζοντας έτσι όρια στους προγραμματιστές. Αντίθετα, με την χρήστη Linux ο προγραμματιστής μπορεί να προγραμματίσει την εφαρμογή του σε όποια γλώσσα προγραμματισμού θέλει αυτός. Το κόστος ενός ενσωματωμένου συστήματος λόγω των περιορισμένων πόρων που χρησιμοποιεί είναι σημαντικά μικρότερο από αυτό ενός PLC. Τέλος, η επέκταση ενός embedded συστήματος γίνεται, πολύ πιο εύκολα και με μικρότερο κόστος από ότι στα PLC.

Κεφάλαιο 3: To Real Time Linux Το Linux, είναι ένα ανοιχτού κώδικα λειτουργικό σύστημα βασισμένο στο Unix. Σχεδιάστηκε από τον Linux Torvals to 1991 με σκοπό την γενικότερη χρήση του σε υπολογιστικά συστήματα. Ακριβώς γι' αυτόν τον λόγο δόθηκε μεγάλη έμφαση στην υψηλή απόδοση και αξιοπιστία του. Όμως δεν μπορούσε να καλύψει real time απαιτήσεις. Η ανάγκη αυτή οδήγησε στην υλοποίηση ενός επιπλέον API που προσφέρει αυτήν την δυνατότητα στο Linux. Το Real Time Application Interface Το Real Time Application Interface (RTAI), το οποίο εκδόθηκε κάτω από την άδεια GPL, αποτελείται από ένα μικρό πυρήνα ο οποίος μπορεί και τρέχει παράλληλα με τον πυρήνα του Linux. Η υλοποίηση αυτή καθιστά το RTAI ευέλικτο, εύκολο στην αναβάθμιση και εξαιρετικά χρήσιμο για την χρήση του σε εφαρμογές ελέγχου και αυτοματισμού. Το RTAI βασίζεται σε έναν micro kernel ο οποίος τρέχει τον πυρήνα του Linux σαν μια διεργασία με την μικρότερη δυνατή προτεραιότητα. Χρησιμοποιεί έναν εικονικό μηχανισμό ελέγχου των διακοπών ( interrupts ), τα οποία κανονικά θα γίνονταν αντιληπτά από τον πυρήνα του Linux. Έτσι αυτός ο micro kernel παρεμβαίνει ενδιάμεσα και παίρνει των έλεγχο των hardware interrupts. Αυτό παρέχει σιγουριά ως προς το ό,τι ποτέ δεν θα παρέμβει ο Linux kernel στον χειρισμό τέτοιων events. Ο ίδιος μηχανισμός φροντίζει για την προώθηση μη-χρήσιμων interrupts στον Linux kernel. Έτσι ο micro kernel μπορεί και τρέχει παράλληλα και με διαφανή τρόπο, με τον κλασσικό Linux kernel. Μία τυπική RTAI εφαρμογή αποτελείται από ένα σύνολο thread αυστηρού πραγματικού χρόνου ( hard real-time threads ) τα οποία ελέγχονται από τον RT micro kernel scheduler. Τα threads αυτά τρέχουν στον χώρο μνήμης του πυρήνα ( kernel address space ). Παράλληλα, ένα σύνολο threads ελαστικού πραγματικού χρόνου ( soft real-time threads ) μπορεί και συνυπάρχει παράλληλα. Το RTAI προσφέρει συγκεκριμένους τρόπους επικοινωνίας μεταξύ των threads ( intercommunication mechanisms ). Οι μηχανισμοί αυτοί επιτρέχουν την επικοινωνία των rtai threads ( hard και soft real time ) με τα threads που τρέχει ο Linux kernel. Στα αρχικά στάδια του RTAI, η hard real time εφαρμογές έπρεπε πάντα να τρέχουν στο kernel space σαν modules, το οποίο ωφελούσε πολύ την απόδοση αυτών των εφαρμογών. Όμως, υπήρχε ένα σημαντικό μειονέκτημα. Ακριβώς επειδή τα real time threads έτρεχαν στο

kernel space, το οποίο σήμαινε ότι μοιράζονταν την ίδια μνήμη, ήταν επικίνδυνα για την εύρυθμη λειτουργία του συστήματος. Αυτό γιατί, αν σε κάποιο από τα thread υπήρχε ένα σφάλμα, τότε όλο το σύστημα κατέρρεε. Γι αυτό τον λόγο, στις μετέπειτα εκδόσεις, υιοθετήθηκε το LXRT17. Το LXRT είναι ένα kernel module του RTAI, που επιτρέπει την χρήση του RTAI API σε επίπεδο user space. Αυτό ήταν μία πολύ ουσιαστική εξέλιξη καθότι επέτρεψε τους προγραμματιστές να γράφουν τις εφαρμογές τους προστατεύοντας παράλληλα την λειτουργία του συστήματος. Για να το επιτύχει αυτό, το LXRT απενεργοποιεί τα soft interrupts για τις hard real time εφαρμογές που τρέχουν σε user space. Με αυτόν τον τρόπο, τα hard real time threads και interrupts του πυρήνα, μπορούν να παρέμβουν στα user space modules. Όμως ο Linux πυρήνας, που όπως αναφέρθηκε παραπάνω, έχει χάσει τον έλεγχο των interrupts από τον rtai micro kernel, δεν μπορεί να παρέμβει στην λειτουργία των user space modules. 1819 RTAI AXE Το RTAI-AXE20, είναι μία επέκταση της πλατφόρμας Archimedes21 που υποστηρίζει την πλατφόρμα ανάπτυξης IEC61499. Αποτελεί την πρώτη real time υλοποίηση του IEC61499 Function Block μοντέλου, που υποστηρίζει πλήρη πλήρη δυνατότητα επαναρύθμισης των Function block κατά την διάρκεια της εκτέλεσης του προγράμματος. To RΤΑΙ-ΑΧΕ επεκτείνει τις δυνατότητες της πλατφόρμας Archimedes με τέτοιο τρόπο ώστε να εκμεταλλεύεται πλήρως τις δυνατότητες του Real Time Linux κατά την φάση της model driven22 ανάπτυξης κατανεμημένων συστημάτων ελέγχου. Το RTAI-AXE αποτελείται από τα εξής τέσσερα στοιχεία: 1. Το RTAI-AXE IMF, το οποίο είναι ένα μοντέλο υλοποίησης των Function Block. Είναι ένα σύνολο από κλάσεις που επιτρέπουν την επαναχρησιμοποίηση ς όλων αυτών των ρυθμιστικών διατάξεων που έγιναν με σκοπό την επιτυχή χρήστη των RTAI εργαλείων στην αντιστοιχία των Function Block σε real time υλοποιήσεις. 2. Το RTAI-AXE EXE, που είναι μια πλατφόρμα την οποία χρησιμοποιούν τα μοντέλα, βασισμένα στα Functions block, προκειμένου να λειτουργήσουν. 3. Ένα σύνολο από ερμηνευτές (FBType2RTAI, FBNet2RTAI ), οι οποίοι δημιουργούν αυτόματα το μοντέλο υλοποίησης από το FB σχεδιαστικό μοντέλο.

4. Τέλος, ένα ειδικό εργαλείο ( RTAI υπεύθυνο για την εκκίνηση των real launcher ), είναι time εφαρμογών. To Real Time Networking Όπως ειπώθηκε και παραπάνω, στα βιομηχανικά δίκτυα υπάρχει για πραγματικό χρόνο στις διεργασίες. Πακέτα τα οποία αποστέλλονται από τον ένα κόμβο στον άλλο πρέπει να φτάνουν στον προορισμό τους μέσα σε συγκεκριμένο χρονικό διάστημα και χωρίς λάθη Την αναγκαία αυτή συνθήκη μας εξασφαλίζουν τα δίκτυα αυστηρού και ελαστικού πραγματικού χρόνου. Τα δίκτυα αυστηρού πραγματικού χρόνου, εκτός από την εξασφάλιση της ακεραιότητας των δεδομένων, φροντίζουν και για την αυστηρή τήρηση των χρονικών ορίων για την μετάδοση ενός πακέτου. Τέτοια δίκτυα είναι κρίσιμης σημασίας όταν η υπό μελέτη εφαρμογή μεταδίδει σήματα συναγερμού τα οποία πρέπει να φτάσουν μέσα σε συγκεκριμένο χρόνο στον παραλήπτη. Ο βασικός μηχανισμός για την ανάπτυξη και λειτουργία τέτοιων δικτύων είναι τα χρησιμοποιούμενα πρωτόκολλα τα οποία συνήθως είναι στο επίπεδο του MAC το οποίο είναι το κατώτατο επικοινωνιακό πρωτόκολλο στην ιεραρχία του OSI πρωτοτύπου 23. Τέτοια δίκτυα είναι τα TDMA24, Token Bus και Token Ring25. Στην περίπτωση που το δίκτυο δεν έχει κρίσιμα σήματα τα οποία απαιτούν αυστηρά χρονικά όρια μετάδοσης, ένα δίκτυο ελαστικού πραγματικού χρόνου είναι μια αποδεκτή λύση. Το δίκτυο αυτό εξασφαλίζει ακεραιότητα δεδομένων αλλά είναι ανεκτό σε καθυστερήσεις μετάδοσης πακέτων. Τέτοια δίκτυα είναι τα δίκτυα φωνής όπου υπάρχει ανοχή 5% στην καθυστέρηση μετάδοσης 26. Ένα ανοιχτό πρωτόκολλο υλοποίησης αυστηρού πραγματικού χρόνου είναι το Rtnet 27. To Rtnet εξασφαλίζει ευέλικτη, πραγματικού χρόνου επικοινωνία, ανεξάρτητη του υλικού. Έκανε την εμφάνιση του το 2001 από τον Ulrich Marx στα πλαίσια της διπλωματικής του εργασίας για το Institute for Systems Engineering, Real-Time Systems Group 28, στο πανεπιστήμιο του Ανόβερο. Η σχεδίαση της στοίβας πρωτοκόλλου του Rtnet φαίνεται παρακάτω ( Εικόνα 9 ), βασίζεται πολύ στην τμηματική σχεδίαση τη δικτυακής στοίβας του Linux.

Εικόνα 6:Στοίβα RTnet Έτσι, προσφέρει ευκολία και υψηλή απόδοση και το καθιστά κατάλληλο για διάφορες πραγματικές εφαρμογές. Παράλληλα, ακριβώς επειδή το Rtnet είναι αμοιγώς λογισμικό, δεν εξαρτάται καθόλου από το διαδικτυακό υλικό που χρησιμοποιείται. Τέλος, εκτός από ethernet δίκτυα, μπορεί να χρησιμοποιηθεί και αλλού. Όπως φαίνεται και παρακάτω ( Εικόνα 10 ), το Rtnet μπορεί και συνυπάρχει παράλληλα με το TCP/IP δίκτυο κάτι που επιτρέπει την δημιουργία υβριδικών δικτύων χωρίς πρόβλημα.29 Εικόνα 7:Τυπικό δίκτυο Rtnet

K ε φ ά λ α ι ο 4 : Ο λ ο κ λ η ρ ω μ έ ν ε ς λ ύ σ ε ι ς σ ε λ ε ι τ ου ρ γ ί α Στα προηγούμενα κεφάλαια έγινε ανάλυση στην χρήση των ενσωματωμένων συστημάτων στον αυτόματο έλεγχο. Όπως ειπώθηκε κάθε μια βιομηχανική διεργασία αποτελείται από κατανεμημένα ενσωματωμένα συστήματα που το κάθε ένα είναι υπεύθυνο για ένα και μόνο τμήμα τις εφαρμογής. Αυτό είναι προφανές ότι οδηγεί σε προβλήματα κατά την διάρκεια του debugging λόγο του κατανεμημένου χαρακτήρα. Τα προβλήματα αυτά γίνονται ακόμα πιο έντονα αν υπάρξει η ανάγκη για debugging κατά την φάση του runtime και κατά πόσο αυτό θα επηρεάσει την λειτουργία του συστήματος. Αρκετές υλοποιήσεις έχουν προταθεί για να αντιμετωπίσουν τα παραπάνω προβλήματα. Η εταιρία Lynuxworks30 προτείνει το εργαλείο Spyker31. Είναι ένα διαγνωστικό εργαλείο για debugging και βελτιστοποίηση των εφαρμογών που τρέχουν σε ενσωματωμένα συστήματα. Μπορεί και παρακολουθεί όλα τα σήματα και δεδομένα που παράγει και δέχεται η εφαρμογή. Το εργαλείο αυτό ανήκει στα trace εργαλεία τα οποία μπορούν και συλλέγουν δεδομένα και σήματα που παράγονται από το λειτουργικό σύστημα και την κάθε εφαρμογή ξεχωριστά. Για να λειτουργήσει το εργαλείο αυτό δεν χρειάζεται να αλλαχτεί ο κώδικας του Linux πυρήνα για την εισαγωγή πρόσθετων συναρτήσεων. Το γεγονός αυτό εξασφαλίζει μηδενική παρεμβολή στην σταθερότητα του συστήματος. Οι υπηρεσίες που προσφέρει το εργαλείο στον προγραμματιστεί που θέλει να κάνει debug είναι οι εξής Απομακρυσμένη δυνατότητα για debugging Σαφής ορισμός των δεδομένων προς παρακολούθησης. Δίνεται επίσης η δυνατότητα για την εμφάνιση timestamps κατά την παραγωγή ή λήψη δεδομένων Δυνατότητα για δυναμική εκκίνηση και διακοπή ανάλογα με τα λαμβανόμενα σήματα Οι δυνατότητες αυτές προσφέρονται στον χρήστη μέσω ενός γραφικού εργαλείου ( Εικόνα 8 ).

Αφού ο χρήστης συμπληρώσει τα πεδία τότε ξεκινάει μια γραφική αναπαράσταση του runtime της εφαρμογής ( Εικόνα 9 ). Παράλληλα ο χρήστης μπορεί να παρακολουθεί ανά πάσα στιγμή τις τιμές που έχει μια μεταβλητή ή το πότε εμφανίζεται ένα σήμα ( Εικόνα 10 ). Εικόνα 8: Γραφική διεπαφή του Spyker debugger Εικόνα 9: Το spyker κατά το runtime

Εικόνα 10: Debugging της εφαρμογής κατά το runtime Παρόλο που το Spyker αποτελεί μια πολύ καλή υλοποίηση για το debugging εφαρμογών σε ενσωματωμένα συστήματα, εντούτοις δεν καλύπτει την δεύτερη απαίτηση, δηλαδή το debugging κατανεμημένων εφαρμογών, δηλαδή την παρακολούθηση μεταβλητών και σημάτων παράλληλα από διαφορετικές συσκευές. Η εταιρία Freescale32 αναπτύσσει το real time debugging εργαλείο FreeMaster33. To freemaster επιτρέπει τον απομακρυσμένο έλεγχο μιας εφαρμογής μέσω ενός γραφικού εργαλείου. Παρέχει την δυνατότητα για παρακολούθηση των μεταβλητών της εφαρμογής σε πραγματικό χρόνο. Η αναπαράσταση των τιμών γίνεται Χρήστη logger Αναπαράσταση σε κονσόλα Γραφική αναπαράσταση με διαγράμματα

Μέσω του γραφικού ελέγχου, ο χρήστης μπορεί να Αλλάξει άμεσα την τιμή μιας μεταβλητής Αλλάξει την τιμή της μεταβλητής ανάλογα με την κατάσταση της εφαρμογής Εισάγει ειδικές εντολές ελέγχου στην κονσόλα Ο τρόπος που γίνεται το debugging χωρίζεται σε δύο μέρη. Στην γραφική εφαρμογή η οποία τρέχει στον προσωπικό υπολογιστή του χρήστη, και την εφαρμογή που τρέχει στο embedded σύστημα. Η γραφική εφαρμογή χρησιμοποιεί μία δυναμική βιβλιοθήκη η οποία χειρίζεται την επικοινωνία. Στο embedded σύστημα η επικοινωνία και το πρωτόκολλο είναι object files με τα οποία συνδέεται η εφαρμογή προς παρακολούθηση κατά την φάση του compile και του runtime. Η υλοποίηση αυτή απαιτεί αλλαγές στον πηγαίο κώδικα της εφαρμογης που τρέχει πάνω στο ενσωματωμένο σύστημα ώστε να επιτευχθεί η συμβατότητα με την εξωτερική βιβλιοθήκη. Μερικά στιγμιότυπα της εφαρμογής σε λειτουργίας φαίνονται στις παρακάτω εικόνες (Εικόνες 11,12,13) Εικόνα 11: Πίνακας ελέγχου

Εικόνα 12: Γραφική αναπαράσταση των τιμών των μεταβλητών

Εικόνα 13: Εισαγωγή τιμών στις μεταβλητές Η εταιρία ARC International34 κατασκεύασε τον SeeCode 35 Debugger. Ο debugger αυτός απευθύνεται σε έμπειρους προγραμματιστές. Το κύριο πλεονέκτημα του είναι ότι μπορεί να προσαρμοστεί ακριβώς στις ανάγκες του κάθε προγραμματιστή. Προσφέρει δυνατότητες debugging σε επίπεδο assembly, παρακολούθηση των τιμών των μεταβλητών καθώς και αλλαγή της τιμής τους. Στην Εικόνα 14 φαίνεται χαρακτηριστικά λεπτομέρειας στην αναπαράσταση των τιμών. το μέγεθος της Σε αυτήν του είδους την κατηγορία των debuggers μπορούν να περιεληφθούν και οι opensource debuggers για λειτουργικά 36 συστήματα Linux όπως ο GNU/GDB.. Ο gdb debugger 37 περιελαμβάνεται στην GNU GCC toolchain το οποίο βρίσκεται σε όλα τα embedded systems που χρησιμοποιουν embedded Linux σαν λειτουργικό. O gdb μπορεί να χρησιμοποιηθεί για remote debugging εφαρμογών που βρίσκονται σε ενσωματωμένα συστήματα, μέσω σειριακής πόρτας ή δικτύου TCP/IP.

Εικόνα 14: SeeCode runtime debugging38 H επικοινωνία σε αυτήν την περίπτωση γίνεται με μια μικροεφαρμογή η οποία τρέχει στην ενσωματωμένη συσκευή και ονομάζεται stub 39. Το προτόκολλο είναι αρκετά απλό και υποστυρίζει μόνο εγγραφή και ανάγνωση προς και από τους registers της cpu και της μνήμης, καθώς επίσης single stepping στην λειτουργία της εφαρμογής. Η εφαρμογή στο ενσωματωμένο σύστημα θα πρέπει να γίνει link και compile με το stub το οποίο προσφέρει δύο βασικές συναρτήσεις που μπορούν να χρησιμοποιηθούν στον κώδικα της εφαρμογής. Αυτές είναι οι getdebugchar() putdebugchar() Ο GDB είναι ένα εργαλείο debugging που τρέχει σε κονσόλα. Για διευκόλυνση έχουν αναπτυχθεί διάφορα GUI όπως το Insight40 Από όλα τα παραπάνω γίνεται εύκολα αντιληπτό ότι η κατάλληλη επιλογή του debugging tool είναι αποκλειστικά θέμα του χρήστη αλλά και της φύσης της εφαρμογής που θέλει να κάνει debug. Σε συνήθεις βιομηχανικές διεργασίες, το debug της εφαρμογής γίνεται από χρήστες οι οποίοι δεν είναι απαραίτητο ότι θα είναι ταυτόχρονα και προγραμματιστές της εφαρμογής. Αυτό συνεπάγεται ότι το εργαλείο που θα πρέπει να χρησιμοποιήσουν, θα πρέπει να

αποκρύβει στοιχεία της αρχιτεκτονικής και να δίνει στον χρήστη την ευχέρεια να παρακολουθήσει όποια μεταβλητή ή σήμα θέλει αποκρύπτοντας του της τεχνικές λεπτομέρειες. Τέτοια εργαλεία είναι το Spyker και το Freemaster. Αντίθετα, όταν ο χρήστης θέλει να κάνει ποιο εκτενές debugging της εφαρμογής τότε ποιο πολύπλοκα εργαλεία πρέπει να χρησιμοποιηθούν. Τέτοιου βάθους debugging γίνεται συνήθως κατά τα στάδια της υλοποίησης της εφαρμογής ενώ δεν είναι απαραίτητο κατά την διάρκεια του runtime. Κ ε φ ά λ α ι ο 5 : Σ χ ε δι α σ μ ό ς σ υ σ τ ή μ α τ ο ς Περιγραφή των συσκευών της MASMEC Χαρακτηριστικά συσκευών Στα πλαίσια της διπλωματικής αυτής χρησιμοποιήθηκαν δύο embedded boards από την εταιρία MASMEC41. Τα συστήματα αυτά συνδέονται μέσω RtNet δικτύου μεταξύ τους. Χρησιμοποιούν Debian 4 σαν λειτουργικό παράλληλα με RTAI. Και οι δύο συσκευές είναι ίδιες μεταξύ τους Αναλυτικά, ο πυρήνας που χρησιμοποιούν είναι ο target1:~# uname -a Linux target1 2.6.22.1rtai36-etch EET 2008 i586 GNU/Linux #1 PREEMPT Thu Dec 11 06:11:42 Στον πυρήνα αυτό έχουν γίνει κάποιες αλλαγές ( patches ) από το RTAI προκειμένου να μπορεί να υποστηρίξει real time εφαρμογές. Η έκδοση του RTAI που χρησιμοποιείται είναι η 3.6 και του RtNet είναι η 0.9.7. Και οι δυο συσκευές χρησιμοποιούν επεξεργαστή Geode από την εταιρία Advanced Micro Devices42, με τα παρακάτω χαρακτηριστικά: target1:~# cat /proc/cpuinfo : 0 vendor_id : AuthenticAMD processor

cpu family : 5 model : 10 model name : Geode(TM) Integrated Processor by AMD PCS stepping : 2 cpu MHz : 499.949 cache size : 128 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow bogomips : 1000.92 clflush size : 32 Η μεταφορά του RTAI-AXE σε αυτά ήταν αρκετά απλή διαδικασία αφού το μόνο που χρειάστηκε ήταν μια συμβατή GNU toolchain για να μπορέσει να γίνει compile και install το RTAI-AXE. H toolchain που χρησιμοποιήθηκε είναι αυτή του gcc-4.1.243 όπως φαίνεται και παρακάτω target1:~# cat /proc/version Linux version 2.6.22.1rtai36-etch (root@target2) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 PREEMPT Thu Dec 11 06:11:42 EET 2008

Η κατανεμημένη εφαρμογή Για τις ανάγκες τις διπλωματικής, αναπτύχθηκε μια κατανεμημένη εφαρμογή με την χρήση των function blocks. Τα function blocks αυτά, κατέβηκαν στις δύο συσκευές όπου έγιναν deploy, compile και configure. Το function block διάγραμμα φαίνεται στο σχήμα 14. Εικόνα 15: FB Diagram της κατανεμημένης εφαρμογής Η εφαρμογή αυτή υλοποιεί έναν κατανεμημένο αριθμητή. Τα function blocks μοιράστηκαν στις δυο συσκευές όπου στην συνέχεια δημιουργήθηκαν οι συνδέσεις μεταξύ τους πριν εκκινήσει η εφαρμογή. Παρόλο που αυτή η κατανεμημένη εφαρμογή είναι μία πολύ απλουστευμένη υλοποίηση ενός κατανεμημένου προβλήματος, μερικά θέματα που προκύπτουν βρίσκουν βάση και πραγματικές βιομηχανικές εφαρμογές. Σχεδιασμός εφαρμογής

Για την αντιμετώπιση του προβλήματος ελέγχου των μεταβλητών και των σημάτων της παραπάνω εφαρμογής, προτείνεται μία υλοποίηση η οποία χωρίζεται σε δύο βασικά μέρη. Στην εισαγωγή ενός νέου νέου layer ( δαίμονα ) σε έναν από τους κόμβους του δικτύου ο οποίος θα επικοινωνεί κάνοντας χρήση του IPCP layer με τους αλλους κόμβους. Ο δαίμονας αυτός λαμβάνει εντολές από μια γραφική εφαρμογή την οποία χρησιμοποιεί ο χρήστης με σκοπό να κάνει debug στο target environment. Το layer του δαίμονα Όπως ειπώθηκε πριν, η επιλογή του RTAI έγινε διότι εξασφαλίζει αυστηρό real-time έλεγχο και λειτουργία. Λόγω αυτού όμως, η παρακολούθηση και ο έλεγχος σε επίπεδο κόμβου καθίσταται αρκετά επισφαλές αφού οποιαδήποτε καθυστέρηση στην υπορουτίνα μπορεί να οδηγήσει σε απώλεια του real-time χαρακτήρα της εφαρμογής. Γι αυτό τον λόγο επιλέχθηκε να χρησιμοποιηθεί ένας δαίμονας σε έναν από τους κόμβους του δικτύου. O δαίμονας είναι ένα layer πάνω από το IPCP επίπεδο χωρίς όμως να παρεμβάλεται στην λειτουργία του. Ο δαίμονας τρέχει σε μία από ολες τις συσκεές του δικτύου. Η συσκεή αυτή μπορεί να χαρακτηρηστεί και ως gateway. Ο ειδικά σχεδιασμένος κόμβος θα χρησιμοποιεί το ίδιο Execution Enviroment όπως παρουσιάστηκε παραπάνω με κάποιες μικρές διαφοροποιήσεις. Η εισαγωγή του δαίμονα σε έναν από τους υπάρχοντες κόμβους του real time δικτύου, εξασφαλίζει τα παρακάτω: Εξασφάλιση real-time συμπεριφοράς Μηδαμινή αλλαγή στο Execution Enviroment Πλήρης συμβατότητα με τους υπόλοιπους κόμβους Έτσι κόμβος αυτός θα αποτελείται ουσιαστικά από δυο layers: Ένα daemon Service που περιμένει συνδέσεις από το εργαλείο ελέγχου Τον IPCPNode ο οποίος θα επικοινωνεί με τους υπόλοιπους χρησιμοποιώντας τις τεχνικές του publisher subscriber μοντέλου.

Daemon Service Στο παρακάτω σχήμα παρουσιάζεται ο τρόπος λειτουργίας του daemon Service. Αρχικά, ο δαίμονας περιμένει μια σύνδεση από το εργαλείο ελέγχου χρησιμοποιώντας Unix TCP/IP Sockets. Αφού δημιουργηθεί μια σύνδεση, ο δαίμονας είναι υπεύθυνος για την δημιουργία δύο νέων thread τα οποία θα είναι υπεύθυνα για τις εξής τρεις λειτουργίες Ρύθμιση των κόμβων του δικτύου (conf_thread) Παρακολούθηση (reader_thread) Αποστολή τιμών στο εργαλείο ελέγχου(reader_thread) τιμών H αρχικοποίηση του Daemon παρακάτω σχήμα (Εικόνα 16 ) σε δεδομένα service και φαίνεται συμβάντα καλύτερα στο Εικόνα 16: Αρχικοποίηση daemon service IPCPNode Service Πρόκειται ουσιαστικά για έναν IPCPNode όμοιο με αυτόν που βρίσκεται σε όλους τους υπόλοιπους κόμβους. Η μόνη διαφορά είναι ότι όταν λάβει ένα πακέτο από κάποιον άλλο κόμβο, δεν εκτελεί κάποια εσωτερική λειτουργία, απλά τοποθετεί το πακέτο σε μια FIFO[1]. Η Fifo αυτή στην συνέχεια διαβάζεται από το Daemon

Service το οποίο αναλύει το πακέτο και το προωθεί στο εργαλείο ελέγχου. Σχηματικά, η λειτουργία του παρουσιάζεται από ένα OID διάγραμμα ( Eικόνα 17 ) Εικόνα 17: DFD διαγραμμα για το IPCPNode service Use Cases Στις παρακάτω εικόναι παρουσιάζονται τα εξής δύο OID: Παρακολούθηση του data στοιχείου ( Εικόνα 18 ) Εισαγωγή τιμής δεδομένων ( Εικόνα 19 )

Εικόνα 18: OID για την επίβλεψη στοιχείου δεδομένων Εικόνα 19: OID για την αλλαγή τιμής σε στοιχείο δεδομένων

Γραφικό Εργαλείο ελέγχου Η γραφική διεπαφή ( παρακάτω απαιτήσεις Εικόνα 20 ) θα πρέπει να ικανοποιεί Remote debugging Δυνατότητα παρακολούθησης των τιμών των μεταβλητών Ενημέρωση για τα ληφθέντα events Δυνατότητα αλλαγής κόμβο του δικτύου. Δυνατότητα αποστολής events σε απομακρυσμένο κόμβο τιμής μιας μεταβλητής σε τις οποιοδήποτε Εικόνα 20: Γραφική εφαρμογή Παρακάτω παρουσιάζεται ( Εικόνα 21 ) ένα state machine διάγραμμα με όλες τις δυνατές καταστάσεις που μπορεί να πάρει το γραφικό εργαλείο.

Εικόνα 21: State machine diagram για την γραφική εφαρμογή Κεφάλαιο 6: Χρήση της εφαρμογής Δαίμονας Η εκκίνηση του δαίμονα στον κόμβο γίνεται με την χρήση 3 παραμέτρων. Την πόρτα που θα περιμένει τις συνδέσεις Την IP διεύθυνση του naming server Την IP που θα έχει ο IPCPNode κατά το configuration time Την ΙP που θα έχει ο IPCPNode κατά το runtime

Συνήθως οι δύο τελευταίες ΙΡ διευθύνσεις είναι ίδιες. Έτσι, για να ξεκινήσει ο δαίμονας στον κόμβο αρκεί ο χρήστης να πληκτρολογήσει./ipcpdaemon 65432 192.168.1.1 192.168.1.2 192.168.1.2 Και ο δαίμονας ξεκινάει κανονικά στην συσκευή Registering GWNODE... Registering... OK IPCPNode deamon is running... Waiting for connections on 0.0.0.0:65432... Γραφική εφαρμογή Η γραφική εφαρμογή έδωσε έμφαση στο usability ώστε να κάνει το έργο του χρήστη ευκολότερο. Η λειτουργία του γραφικού περιβάλλοντος μπορεί να χωριστεί σε δύο διαφορετικά επίπεδα 1. Σύνδεση με τον απομακρυσμένο κόμβο και αποστολή πακέτων ρυθμίσεων 2. Λήψη, επεξεργασία και εμφάνιση αποτελεσμάτων Για την υλοποίηση τους χρησιμοποιήθηκαν threads έτσι ώστε οι δύο παραπάνω λειτουργίες να γίνονται παράλληλα και ανεξάρτητα η μία από την άλλη. Για την υλοποίηση του γραφικού περιβάλλοντος χρησιμοποιήθηκε το Qt4 Toolkit μαζί με το εργαλείο Qt-Creator44. Και τα δύο εργαλεία είναι cross-platform, δηλαδή υπάρχει πλήρης συμβατότητα με Linux, Windows(tm),και MacOSX. έγινε σε λειτουργικό σύστημα Linux ( Παρόλα αυτά η ανάπτυξη Gentoo Linux45 AMD64).

Στην Εικόνα 22 διακρίνουμε τα εξής πεδία προς συμπλήρωση Daemon Server IP Port Τα δυο αυτά πεδία πρέπει να συμπληρωθούν πριν από οποιοδήποτε άλλο. Στο πρώτο πεδίο συμπληρώνεται η ΙΡ διεύθυνση του δαίμονα και στο δεύτερο η πόρτα στην οποία περιμένει τις συνδέσεις. Στην συνέχεια ο χρήστης πατάει το κουμπί Σύνδεση και συνδέεται με τον απομακρυσμένο κόμβο Εικόνα 22: Γραφική εφαρμογή Έπειτα ο χρήστης συμπληρώνει τα παρακάτω πεδία ( Εικόνα 23 )

Εικόνα 23:Πεδία που αφορούν τα προς παρακολούθηση στοιχεία Αρχικά διαλέγει την ενέργεια που θέλει να κάνει, δηλαδή αν θέλει να παρακολουθήσει μια μεταβλητή ή ένα event ή αν θέλει να αλλάξει την τιμή μίας μεταβλητής ή να στείλε ένα event. Επιλέγει αν είναι στοιχείο δεδομένων ή event και αν είναι στοιχείο δεδομένων και τότε συμπληρώνει την τιμή που θέλει να του εισάγει σε περίπτωση που θέλει να το αλλάξει. Κατόπιν, συμπληρώνει το όνομα τις συσκευής στην οποία βρίσκεται το στοιχείο που θέλει να παρακολουθήσει, το όνομα του function block και το όνομα του στοιχείου. Tέλος, μέσω του ειδικού ροοστάτη, η γραφική εφαρμογή ενημερώνει τον χρήστη όταν περάσει το deadline για κάποιο από τα events. Όταν ο χρήστης πατήσει Send τότε ξεκινάει η διαδικασία της παρακολούθησης όπως φαίνεται και στην Εικόνα 24.

Εικόνα 24: Το πρόγραμμα στην φάση του monitoring Kεφάλαιο 7: Πηγαίος κώδικας Δαίμονας Αρχικοποίηση Αρχικά θα πρέπει να οριστεί το όνομα με το οποίο ο δαίμονας θα δηλωθεί στους naming servers καθώς επίσης και η πόρτα στην οποία θα περιμένει συνδέσεις από το γραφικό εργαλείο ελέγχου. #define GUI_PORT 65433 #define GWIPCP_NODE_NAME "GWNODE" Ακολουθεί η αρχικοποίηση του IPCPNode στην συσκευή node=new IPCPNode(10,10,30,argv[2],argv[3],argv[4]); if(node->registerdevicetonameserver(gwipcp_node_name)<0){ printf("registration failed.. Is dns server up and running????\n"); exit(1); Το γεγονός ότι η κάθε συσκευή έχει ένα μοναδικό όνομα, οδηγεί στην χρήση ενός naming server service. Στις περιπτώσεις που χρειάζεται να επιτευχθεί μία σύνδεση μεταξύ δύο συσκευών, είναι αναγκαία η

γνώση της IP διεύθυνσης της κάθε συσκευής. Αυτό το αναλαμβάνει το naming service το οποίο κάνει mapping το όνομα της συσκευής με την IP διεύθυνσή της. Η κάθε συσκευή αμέσως μετά το στάδιο του IPCPNode Initialisation, εγγράφεται σε αυτό το naming service παρέχοντας του το όνομα της και την IP της. devicens=new NamingServiceClient(argv[2],5555); sock->getinetaddr(&ina); Bind και Listen για το Daemon Service if(sock->bind(port)<0) { printf("error: service socket\n"); exit(1); if(sock->listen(32)<0) { printf("error: socket\n"); exit(1); bind listen while(true){ Socket *_sock_=new Socket(); if(sock->accept(_sock_)<0) printf("error: client\n"); else{ Τhread το οποίο είναι απομακρυσμένων κόμβων υπεύθυνο IPCPNode για IPCPNode accept την daemon service configuration ρύθμιση των if(pthread_create(&conf_dmn,null,conf_client_func,(void*)_sock_)! =0) printf("error creating configuration thread!\n"); Thread το οποίο είναι υπεύθυνο για την λήψη πακέτων από τους απομακρυσμένους κόμβους if(pthread_create(&read_dmn,null,read_client_func, (void*)_sock_)!=0) printf("error creating reading thread!\n"); Configuration Thread Το thread αυτό είναι υπεύθυνο για την λήψη των πακέτων από το γραφικό εργαλείο ελέγχου και την ρύθμιση των απομακρυσμένων κόμβων

while(true){ // Waiting for gui packets _sock_->recv((void*)&packet,sizeof(struct conf_packet)); Τα πακέτα που περιμένει παρακάτω μορφή #define #define #define #define #define #define #define #define #define #define #define #define #define #define #define #define να λάβει το service αυτό έχουν την PUB_DATA 1 PUB_EVENT 2 SUB_DATA 3 SUB_EVENT 4 MAX_FBI_NAME 32 MAX_DATA_NAME 32 MAX_DEV_NAME 32 MAX_R_VALUE 4 TYPE 2 MAX_NAME 65 MAX_LENGTH 128 FBI_NAME 1 DATA_NAME 1 FBI_NAME 1 R_VALUE 1 DEV_NAME 1 struct conf_header { char _type_[type]; ; struct conf_info { char _dev_[max_dev_name]; char _value_[max_r_value]; char _data_[max_data_name]; char _fbi_[max_fbi_name]; ; struct conf_packet { struct conf_header header; struct conf_info info; ; Εχει οριστεί ότι η μεταβλητή _ type _ θα έχει την τιμή: 1 για πακέτα δεδομένων προς κοινοποίηση,

2 για πακέτα συμβάντων προς κοινοποίηση, 3 για πακέτα δεδομένων προς εγγραφή, 4 για πακέτα συμβάντων προς εγγραφή. Συμφωνα με τον παραπάνω κώδικα, το πακέτο που αποστέλνεται απο το γραφικό εργαλείο και είναι υπεύθυνο για την ρυθμιση των κόμβων περιέχει Tον τύπο της ενέργειας που θα εκτελεστεί Το όνομα της συσκευής π Το όνομα του function block Το όνομα της μεταβλητής ή του event. Στην περίπτωση που χρειάζεται να αλλαχθεί η τιμή σε κάποιο στοιχείο δεδομένων, το πακέτο περιέχει ακόμα μια μεταβλητή, την _ value _ η οποία περιέχει την προς ανάθεση τιμή. Ρύθμιση απομακρυσμένου κόμβου /* retrieve remote IPCPNode IP address */ if(devicens->getitemaddress(packet.info._dev_, address)<0){ printf("couldnt find %s\ndid you registerd first??\n",packet.info._dev_); /* connect to remote IPCPNode */ if(ddebug) printf("connecting with %s\n",address); if(_backend_->connect(address,ipcpnode_port)<0){ printf("fatal: Cannot connect to %s\n",packet.info._dev_); _backend_->close(); exit(1); /* Send the actual packet which will configure remote IPCPNode */ _backend_->send((void*)&packet,sizeof(struct conf_packet)); it Αφού το thread λάβει το πακέτο από το γραφικό εργαλέιο, και το επεξεργαστεί στην συνέχεια, μέσω ενός naming service client αποκτάει πρόσβαση στους naming servers που αναλύθηκαν παραπάνω. Αφού ο naming server επιστρέψει την IP της απομακρυσμένης συσκευής, δημιουργείται η σύνδεση και αποστέλεται το πακέτο ρυθμίσεων.

Ρύθμιση τοπικού IPCPNode service O τοπικός αλλά και ο απομακρυσμένος IPCPNode ρυθμίζονται ακριβώς με τον ίδιο τρόπο. Και οι δύο χρησιμοποιούν το ίδιο πακέτο το οποίο στάλθηκε από το γραφικό εργαλείο. Αρχικά το πακέτο αυτό αναλύεται, και ανάλογα με τον τύπο της εντολής που περιέχει στην επικεφαλίδα, ορίζεται και η ανάλογη ενέργεια που θα πρέπει να γίνει. /* Configuring Gateway IPCPNode */ switch(atoi(packet.header._type_)){ Αρχικά η εφαρμογή αναγνωρίζει τον τύπο του πακέτου. case PUB_DATA: Στην περίπτωση που έχει τιμή κατάλληλα ώστε να εγγραφεί σε μια δημοσίευση δεδομένων 1 τότε ο IPCPNode θα ρυθμιστεί printf("calling registersubscriptiondata\n"); node>registersubscriptiondata(packet.info._fbi_,packet.info._data_); printf("done\n"); break; case PUB_EVENT: Στην περίπτωση που έχει τιμή 2 τότε ο IPCPNode θα ρυθμιστεί κατάλληλα ώστε να εγγραφεί σε μια δημοσίευση συμβάντων printf("calling registersubscriptionevent\n"); node>registersubscriptionevent(packet.info._fbi_,packet.info._data_); printf("done\n"); break; case SUB_DATA: Στην περίπτωση που έχει τιμή 3 τότε ο IPCPNode θα κατάλληλα ώστε να κοινοποιήσει ένα στοιχείο δεδομένων ρυθμιστεί printf("calling registerpublicationsdata\n");

pubid=node>registerpublicationdata(packet.info._fbi_,packet.info._data_,packet. info._dev_); [...publication_code...] break; case SUB_EVENT: Στην περίπτωση που έχει τιμή 4 τότε ο IPCPNode κατάλληλα ώστε να κοινοποιήσει ένα συμβάν θα ρυθμιστεί printf("calling registerpublicationevent\n"); pubid=node>registerpublicationevent(packet.info._fbi_,packet.info._data_,packet.info._dev_); [...publication_code...] break; default: printf("error: Received unknown command\n"); break; Reader Thread Η κύρια και βασική λειτουργία του συγκεκριμένου thread είναι η ανάγνωση της FIFO και η αποστολή των απαιτούμενων πακέτων προς την γραφική εφαρμογή ελέγχου while(fd<0){ fd=open(fifo_path,o_rdonly); if (fd < 0){ printf("error %d opening FIFO \n", errno); rdata=read(fd,&packet,sizeof(return_packet)); printf("type: %d\n",packet.type); //check the contents if(rdata==sizeof(return_packet)){ tosend=true; //prevent daemon from sending the same data /* check the timestamp and dont send it if it is the same */ if(!strncmp(_temp_timestamp_,packet._timestamp_,26)){ #ifdef _DEBUG printf("warning: duplicate entry detected...abort sending...\n");

#endif tosend=false; else{ strncpy(_temp_timestamp_,packet._timestamp_,26); tosend=true; if (rdata < 0) { if (errno!= EAGAIN) { printf("error %d reading FIFO \n", errno); rdata = 0; /* empty fifo */ Αφού το thread διαβάσει το πακέτο απο την fifo τότε πρέπει να το στείλει στο γραφικό interface _sock_->send((void*)&packet,sizeof(struct return_packet)) Προκειμένου να μην αποστέλεται πολλαπλές φορές η ίδια πληροφορία, προτού κατασκευαστεί το πακέτο, ελέγχεται το timestamp με αυτό της προηγούμενης αποστολής. Αν είναι το ίδιο, τότε το αγνοείται το εισερχόμενο πακέτο και το thread περιμένει την λήψη νέου. Γραφικός debugger Η αρχικοποίηση του περιβάλλοντος γίνεται με τον εξής τρόπο int main(int argc, char *argv[]) { QApplication a(argc, argv); MainWindow w; w.show(); return a.exec(); Η main συνάρτηση ξεκινάει το event loop πάνω στο στιγμιότυπο της MainWindow κλάσης που θα παρουσιαστεί παρακάτω αναλυτικά.

H Γραφική φόρμα της MainWindow κλάσης (mainwindow.ui) Η φόρμα του γραφικού περιβάλλοντος κατασκευάστηκε μέσω του Designer εργαλείου του Qt-Creator. Η φόρμα είναι αρχεία UI ( user interface ). Στην πραγματικότητα πρόκειται για xml αρχεία, που o parser του Designer αναλαμβάνει να τα μετασχηματίσει σε γραφικές οντότητες ώστε η διαδικασία της σχεδίασης να γίνεται ευκολότερη. Ενδεικτικά, ένα κομμάτι παρουσιάζεται παρακάτω του κώδικα του mainwindow.ui αρχείου <?xml version="1.0" encoding="utf-8"?> <ui version="4.0"> <class>mainwindowclass</class> <widget class="qmainwindow" name="mainwindowclass"> <property name="geometry"> <rect> <x>0</x> <y>0</y> <width>695</width> <height>705</height> </rect> </property> <property name="windowtitle"> <string>rtai/rtnet Configuration Client 32bit v0.0.7</string> </property> <property name="windowicon"> <iconset resource="icons.qrc"> <normaloff>:/icons/icons/rtai-rtnetmain.png</normaloff>:/icons/icons/rtai-rtnet-main.png</iconset> </property> <widget class="qwidget" name="centralwidget"> <layout class="qgridlayout" name="gridlayout_2"> <item row="0" column="0" colspan="2"> <widget class="qlabel" name="label_11"> <property name="font"> <font> <weight>75</weight> <bold>true</bold> <underline>true</underline> </font> </property>

<property name="text"> monitoring</string> Ο parser χρησιμοποιώντας την παραπάνω xml, δημιουργεί το γραφικό στιγμιότυπο ( Εικόνα 25 ). Εικόνα 25: Η γραφική εφαρμογή κατά την φάση της σχεδιάσης Το αρχείο ui μέσω του εργαλείου uic[1] μετασχηματίζεται σε header file το οποίο στην συνέχεια γίνεται include από οποιοδήποτε C++ source αρχείο που χρειάζεται να έρθει σε αλληλεπίδραση με το UI. Το αρχείο mainwindow.h

Παράλληλα με το αρχείο mainwindow.ui, το οποίο όπως ειπώθηκε πριν, μετασχηματίζεται μέσω του uic σε headerfile ( ui_mainwindow.h ), υπάρχει και ένα επιπλέον headerfile το οποίο περικλείει όλα τα απαραίτητα header files αλλά και τις συναρτήσεις που θα χρησιμοποιηθούν από το γραφικό εργαλείο. Σε αυτό το αρχείο περιέχονται τα παρακάτω. Επιπλέον header files #include <QtGui/QMainWindow> Η βασική κλάση για την γραφική εφαρμογή #include #include #include #include #include #include #include #include <QtGui/QMessageBox> <QtGui/QTableWidget> <QtGui/QTableWidgetItem> <QtCore/QThread> <QtCore/QMutex> <QtCore/QVector> <QtCore/QList> <QtCore/QTimer> Βασικές κλάσεις που παρέχει το Qt4 εργαλείο όπως MessageBoxes, Πίνακες, Διανύσματα, Τhreads, Λίστες κ.α. #include "kled.h" Η κλάσει αυτή περιέχει τους ορισμούς για χρησιμοποιήθηκαν στην λήψη των συμβάντων. τα ειδικά leds που //network includes #include "../headers/cppsocket.h" #include "../headers/confpackets.h" Πρόκειται για τα ίδια header files που χρησιμοποιήθηκαν και στους κόμβους του δικτιου, τα οποία είναι απαραίτητα για την επικοινωνία μέσω TCP/IP Unix Sockets public: MainWindow(QWidget *parent = 0); ~MainWindow(); int thread_id; std::queue<std::string> _fifo_; void _send_back_(char *value); Ui::MainWindowClass *ui; QString cmd;

QString QString QString QString QString QString rvalue; device; fbi; data; delay; value; QList<QLabel*> eventlist; Στην Qlist θα σώζονται τα ονόματα των εισερχόμενων events που θα λαμβάνονται απο το πρόγραμμα. Η λίστα αυτή θα εκτυπώνεται στην περιοχή των συμβάντων. QList<KLed*> leds; Όμοια με πριν., η λίστα αυτή θα περιέχει παρουσιάζουν γραφικά την δραστηριότητα συμβάντων. τα leds τα οποία των εισερχόμενων QVector<QString> output; Διάνυσμα διαστάσεων [X,2] όπου στην πρώτη στήλη θα αποθηκεύονται τα ονόματα των εισερχόμενων στοιχείων δεδομένων, και στην δεύτερη στήλη θα αποθηκεύεται η τιμή τους. Τα διανύσματα[1] στην Qt χρησιμοποιούν συναρτήσεις από τα pipes ή fifos. Όπως: void void void void void κ.α. clear () push_back ( const T & value ) push_front ( const T & value ) pop_front () pop_back () private slots: H Qt παρέχει την δυνατότητα, τα slots να ακολουθούν το εξής μοτίβο void on_<component_name>_<slot_name> Οπότε σύμφωνα με το παραπάνω, τα slots ορίζονται ως εξής void on_stopbutton_clicked(); void on_closebutton_clicked(); void on_clearbutton_4_clicked(); void on_clearevents_clicked();

void void void void void void void void void void void void void void void void void on_lineedit_3_textchanged(qstring ); on_actionsystem_information_activated(); on_sendbutton_clicked(); on_connectbutton_clicked(); on_lineedit_6_textchanged(qstring ); on_lineedit_5_textchanged(qstring ); on_lineedit_4_textchanged(qstring ); on_lineedit_2_textchanged(qstring ); on_actionabout_activated(); on_actionabout_qt_activated(); on_checkbox_statechanged(int ); on_checkbox_2_statechanged(int); on_checkbox_3_statechanged(int); on_combobox_currentindexchanged(qstring ); enable_send_button(); enable_connect_button(); turn_off_leds(); Στην συνέχεια ορίζονται τα παρακάτω δύο threads Thread λήψης και αποθήκευσης (Bthread) Το thread αυτό ξεκινάει αμέσως μόλις επιτευχθεί η σύνδεση του γραφικού εργαλείου με τον απομακρυσμένο κόμβο. Η αναλυτική του λειτουργία θα παρουσιαστεί παρακάτω. class BThread : public QThread { public: void run(); void inconnections(); Η συνάρτηση inconnections() είναι υπεύθυνη για μήνυμα που θα ενημερώνει τον χρήστη για τον threads. να τυπώσει ένα τερματισμό των MainWindow *gui; ; Thread εμφάνισης στοιχείων δεδομένων (Dthread) To thread αυτό αναλαμβάνει να εμφανίσει τα αποτελέσματα του διανύσματος που περιέχει τα στοιχεία δεδομένων και τις τιμές τους,

σε ένα ειδικό πίνακα πάνω στο γραφικό εργαλείο. Προτού τα εμφανίσει, το thread πέφτει σε αδράνεια για χρόνο ίσο με τον χρόνο που όρισε ο χρήστης στο ειδικό QspinBox. Όμοια με πριν, το thread αυτό ορίζεται ως εξής class BThread : public QThread { public: void run(); void inconnections(); MainWindow *gui; ; Το αρχείο mainwindow.cpp Αρχικοποίηση τιμών και γραφικού περιβάλλοντος Κατά την εκκίνηση του γραφικού περιβάλλοντος θα πρέπει να αρχικοποιηθούν κάποιες μεταβλητές απαραίτητες για την μετέπειτα εκτέλεση του προγράμματος MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindowClass) { //init QTimer *timer=new QTimer(); timer->setinterval(250);//0.25 secs timer->start(); Ο μετρητής αυτός,κάθε 250ms, μηδενίζεται και ξανά ξεκινά. Όταν ο μετρητής μηδενιστεί, τότε μέσω ενός σήματος ( signal ) σβήνει τα leds τα οποία δείχνουν την δραστηριότητα των εισερχόμενων συμβάντων. ui->setupui(this); Τα κουμπιά για την διακοπή, την εποπτεία, και την διαγραφή απενεργοποιούνται αφού δεν χρειάζονται αρχικά. Θα ενεργοποιηθούν πάλι αφού επιτευχθεί η σύνδεση με τον απομακρυσμένο κόμβο. ui->stopbutton->setenabled(false); ui->sendbutton->setenabled(false); ui->clearbutton_2->setenabled(false);

ui->sendbutton->setenabled(false); this->daemon_connected=false; Αρχικοποιείται ο χρόνος που θα γίνεται η ανανέωση στον πίνακα των αποτελεσμάτων. Η τιμή αυτή μπορεί να αλλάξει κατά την διάρκεια της εκτέλεσης του προγράμματος. ui->spinbox->setvalue(5); ui->connectbutton->setenabled(true); Αρχικοποιούνται οι διαστάσεις του πίνακα ui->tablewidget->setcolumnwidth(0,140); ui->tablewidget->setcolumnwidth(1,70); Όπως ειπώθηκε και πριν, το δυνατότητα καταγραφής της ενεργοποιημένη αρχικά. γραφικό εργαλείο παρέχει την διαδικασίας. Η επιλογή είναι ui->checkbox->setchecked(true); ui->checkbox_2->setchecked(true); ui->lineedit->settext("none"); ui->lineedit->setenabled(false); ui->textedit->setreadonly(true); Ομοίως, απενεργοποιούνται όλα τα πεδία που αφορούν το στοιχείο προς παρακολούθηση, πρωτού επιτευχθεί πρώτα η σύνδεση με τον κόμβο. this->packet_input_fields(false); /* Event list + Leds DO NOT CHANGE THE ORDER */ this->eventlist.push_back(ui->label_19); this->eventlist.push_back(ui->label_20); this->eventlist.push_back(ui->label_23); this->eventlist.push_back(ui->label_24); this->eventlist.push_back(ui->label_21); this->eventlist.push_back(ui->label_22); this->eventlist.push_back(ui->label_25); this->eventlist.push_back(ui->label_26); this->eventlist.push_back(ui->label_27); this->eventlist.push_back(ui->label_28); this->eventlist.push_back(ui->label_29); this->eventlist.push_back(ui->label_30);

this->eventlist.push_back(ui->label_31); this->eventlist.push_back(ui->label_32); this->eventlist.push_back(ui->label_33); this->eventlist.push_back(ui->label_34); this->eventlist.push_back(ui->label_35); this->eventlist.push_back(ui->label_36); this->eventlist.push_back(ui->label_37); this->eventlist.push_back(ui->label_38); this->eventlist.push_back(ui->label_41); this->eventlist.push_back(ui->label_42); this->eventlist.push_back(ui->label_43); this->eventlist.push_back(ui->label_44); this->leds.push_back(ui->kled); this->leds.push_back(ui->kled_2); this->leds.push_back(ui->kled_3); this->leds.push_back(ui->kled_4); this->leds.push_back(ui->kled_5); this->leds.push_back(ui->kled_6); this->leds.push_back(ui->kled_7); this->leds.push_back(ui->kled_8); this->leds.push_back(ui->kled_9); this->leds.push_back(ui->kled_10); this->leds.push_back(ui->kled_12); this->leds.push_back(ui->kled_13); //connect the timer with the leds connect(timer,signal(timeout()),this,slot(turn_off_leds())); /* turn of leds */ this->turn_off_leds(); Αρχικοποιείται η λίστα με τα leds και τα ονόματα των συμβάντων, και τέλος σβήνουν όλα τα leds.

Μενού Βοήθειας Help About Qt // Qt information void MainWindow::on_actionAbout_Qt_activated(){ QmessageBox::aboutQt(this); Πρόκειται για τις Tookit(Εικόνα 26). πληροφορίες που εμφανίζονται σχετικά με το Εικόνα 26: Πληροφορίες σχετικά με το Qt4 toolkit