ΜΕΤΡΟ 4.1 ΠΡΟΓΡΑΜΜΑ ΕΝΙΣΧΥΣΗΣ ΕΡΕΥΝΗΤΙΚΟΥ ΥΝΑΜΙΚΟΥ (ΠΕΝΕ 99) ΤΕΛΙΚΗ ΕΚΘΕΣΗ. Ινστιτούτο Βιοµηχανικών Συστηµάτων (ΙΝ.ΒΙ.Σ.)

Transcript

1 ΕΠΙΧΕΙΡΗΣΙΑΚΟ ΠΡΟΓΡΑΜΜΑ ΕΡΕΥΝΑΣ & ΤΕΧΝΟΛΟΓΙΑΣ (ΕΠΕΤ ΙΙ) Υποπρόγραµµα 4 ΜΕΤΡΟ 4.1 ΠΡΟΓΡΑΜΜΑ ΕΝΙΣΧΥΣΗΣ ΕΡΕΥΝΗΤΙΚΟΥ ΥΝΑΜΙΚΟΥ (ΠΕΝΕ 99) ΕΡΓΟ ΑΡΤΙΟ JAVA/JINI στη βιοµηχανία ΤΕΛΙΚΗ ΕΚΘΕΣΗ Ινστιτούτο Βιοµηχανικών Συστηµάτων (ΙΝ.ΒΙ.Σ.) Τοµέας Ηλεκτρονικής και Υπολογιστών Τµήµα Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών Πανεπιστήµιο Πατρών ΙΤΥ ΠΑΤΡΑ ΟΚΤΩΒΡΙΟΣ 001

2 ΑΡΤΙΟ Τελική έκθεση Συγγραφείς : Καθ. Γεώργιος Παπαδόπουλος, Επ. Καθ. Κλεάνθης Θραµπουλίδης, Λεκτ. Χάρις Βέργος Συνεισφορά: Καθεστώς: Φύση: Επαφή: Στέφανος Ασλάνης, Αγγελική Πραγιάτη, Χρήστος Τρανώρης, Χρήστος Κουλαµάς, Εµµανουήλ Καλλίγερος, Λουκάς Μάνδαλος, Μάτσιεϊ Μπέλλος, Κώστας Χαρατσής. Τελικό Τελική έκθεση Καθ. Γ. Παπαδόπουλος (ΙΝΒΙΣ) Περίληψη Το κείµενο αποτελεί τελική έκθεση προόδου για το έργο. Είναι στα πλαίσια της απαίτησης της ΓΓΕΤ και ακολουθεί την προτεινόµενη από αυτή δοµή. Λέξεις κλειδιά: ίκτυο πεδίου, ιαλειτουργικότητα (interoperability), Function Βlock, ιασύνδεση Πραγµατικού Χρόνου (real-time interconnection), Eργαλείο ιαχείρισης ιατάξεων Πεδίου, Profibus, Lonworks, RTLinux, OPC, Java, Jini, Υλοποίηση Κόµβων ικτύου Πεδίου.

3 ΑΡΤΙΟ Τελική έκθεση 3 ΠΕΡΙΕΧΟΜΕΝΑ 1 Περίληψη 6 Εισαγωγή - Αντικείµενο του Έργου 6 3 Αναλυτική έκθεση της πορείας του ερευνητικού έργου και των ερευνητικών αποτελεσµάτων 8 4 Ανάλυση απαιτήσεων και καταγραφή προδιαγραφών Ανάλυση Απαιτήσεων Το Αίτηµα του Πραγµατικού Χρόνου Το Αίτηµα της ιαλειτουργικότητας Το Επίπεδο Χρήστη (User Layer) Λειτουργικές προδιαγραφές Αρχιτεκτονική του Συστήµατος Η Μονάδα ιασύνδεσης (ΑΡΤΙΟ Gateway) Το Γενερικό Εργαλείο Μηχανικού (ESS) Τεχνικές Προδιαγραφές ιεπαφές ικτύων 4.3. ιεπαφή ικτύου PROFIBUS ιεπαφή ικτύου Lonworks Ανάλυση των επικρατέστερων Αντικειµενοστρεφών Τεχνολογιών Λογισµικού Real-Time Java Το σύστηµα Jini Επισκόπηση της τεχνολογίας COM Τεχνολογία DCOM OLE for Process Control (OPC) Αρχιτεκτονική DNA-Μ 45 5 Σχεδιασµός και Ανάπτυξη πρωτοτύπου Γενικά Η προτεινόµενη αρχιτεκτονική 4 επιπέδων Εργαλείο Μηχανικού (Enginnering Support Systems, ESS) Μελέτη προβλήµατος και λύσεων για περιγραφή συσκευής Σύνθεση υπαρχόντων προδιαγραφών Η ανοιχτή αρχιτεκτονική της µονάδας διασύνδεσης Τα ενεργά στοιχεία της µονάδας διασύνδεσης 54

4 ΑΡΤΙΟ Τελική έκθεση Ο µηχανισµός αλληλεπίδρασης Κανόνες αλληλεπίδρασης Υλοποίηση της Μονάδας ιασύνδεσης Υλοποίηση του µηχανισµού αλληλεπίδρασης Υλοποίηση του Remote Fieldbus Proxy Υλοποίηση του Local Fieldbus Proxy Υλοποίηση του Remote Fieldbus Proxy Η λειτουργία του ESS Χρήση της προδιαγραφής συσκευής στη διαδικασία ανάπτυξης ενός IPMCS Το προτεινόµενο µοντέλο συσκευής 73 6 ιασύνδεση του Profibus και Lonworks στην προτεινόµενη αρχιτεκτονική Τοπολογία ιασύνδεσης των Βιοµηχανικών ικτύων Τεχνολογία Fast Switched Ethernet Η Τεχνολογία ΑΤΜ 8 6. Profibus Αναπαράσταση µεταβλητών Ανάγνωση της πληροφορίας από τον master Αναγνώριση και µετατροπή µεταβλητών Ψηφιακές τιµές ιαφανής Αναλογικές τιµές Τύποι εδοµένων Αναπαράσταση των τύπων δεδοµένων στο PROFIBUS PROFIBUS Wrapper οµές δεδοµένων για την λειτουργία του PROFIBUS Wrapper οµή και λειτουργία του PROFIBUS wrapper InterThread Communication Lonworks Αρχικοποίηση και λειτουργία ενός προγράµµατος Αναπαράσταση µεταβλητών Ανάγνωση της πληροφορίας από την κάρτα Αναγνώριση και µετατροπή µεταβλητών Τύποι εδοµένων Αναπαράσταση των τύπων δεδοµένων στο Lonworks Lonworks Wrapper οµές δεδοµένων για την λειτουργία του LONWORKS Wrapper οµή και λειτουργία του LONWORKS wrapper InterThread Communication 1 7 Υλοποίηση OPC server Γενικά Περιγραφή της προδιαγραφής OPC 130

5 ΑΡΤΙΟ Τελική έκθεση Βασικά στοιχεία της προδιαγραφής OPC Περιγραφή του OPC DataAccess Περιγραφή του OPC Alarm and Event Handling Περιγραφή του OPC Historical Data Access Αρχιτεκτονική και δοµοστοιχεία του OPC Χρήση του OPC server για την καταγραφή της λειτουργίας της εφαρµογής Υλοποίηση Σταθµών ικτύων Profibus, LonWorks Υλοποίηση Εξαρτηµένων (Slave) Σταθµών ικτύου Profibus Γενικά Επιλογή Πλατφόρµας Υλοποίησης Υλοποίηση πρότυπου συστήµατος Περιγραφή λογισµικού του επαναπρογραµµατιζόµενου συστήµατος (πλακέτας) Υλοποίηση Σταθµών ικτύου Lonworks Γενικά Αρχές Υλοποίησης LonWorks Σταθµού Συµπεράσµατα ηµοσιεύσεις Προερχόµενες από το Πρόγραµµα Βιβλιογραφία ΠΑΡΑΡΤΗΜΑ - Νέοι ερευνητές Σύνθεση οµάδας νέων ερευνητών Σύντοµη περιγραφή του ρόλου κάθε νέου ερευνητή, των καθηκόντων και των υποχρεώσεων του ώς προς το τµήµα της εργασίας που έχει αναλάβει στα πλαίσια του έργου Λεπτοµερείς αναφορές κάθε µέλους της οµάδας των νέων ερευνητών Συµβολή του προγράµµατος στην ανάπτυξη της συνεργασίας και της κινητικότητας µεταξύ των συµµετεχόντων φορέων. 163

6 ΑΡΤΙΟ Τελική έκθεση 6 1 Περίληψη Στα πλαίσια του παρόντος έργου προτείνεται µια νέα προσέγγιση για την αντιµετώπιση του σηµαντικού προβλήµατος της εξασφάλισης επικοινωνιακής διαλειτουργικότητας (interoperability) µεταξύ ετερογενών βιοµηχανικών δικτύων ελέγχου (fieldbuses) που βρίσκονται διάσπαρτα στις βιοµηχανικές µονάδες, κυρίως από την οπτική γωνία του Μηχανικού Συστηµάτων Ελέγχου. Ο κύριοι στόχοι του έργου είναι: Η πλήρης ολοκλήρωση πολλαπλών ετερογενών βιοµηχανικών δοµών ελέγχου (πραγµατικού χρόνου) στο συνολικό βιοµηχανικό πληροφοριακό περιβάλλον. Η δυνατότητα ευέλικτης διαχείρισης (προγραµµατισµός - διαµόρφωση) των δικτύων αυτών µε ενιαίο τρόπο και µέσω ΙP δικτύων, δηλαδή και µέσω του INTERNET, ανεξάρτητα, δηλαδή, από την γεωγραφική θέση του διαχειριστή µηχανικού. Πιο συγκεκριµένα το προτεινόµενο αυτό έργο στοχεύει: στη σχεδίαση και ανάπτυξη ενός γενερικού εργαλείου µηχανικού (engineering tool) µε βάση τις τεχνολογίες Java (Real-Time Java) και Jini, το οποίο προορίζεται για το Μηχανικό συστηµάτων βιοµηχανικού ελέγχου, για τον σχεδιασµό και τη διαµόρφωση συστηµάτων ελέγχου που στηρίζονται σε διαφορετικά δίκτυα πεδίου στη σχεδίαση και ανάπτυξη µιας δικτυακού τύπου διάταξης πολλαπλών λειτουργιών MFND (Multi-Functional Networking Device), η οποία θα παίζει το ρόλο, τόσο της ευφυούς γέφυρας στο επίπεδο εφαρµογής (application gateway), όσο και του δροµολογητή ανάµεσα στο δίκτυο ελέγχου και τη δικτυακή υποδοµή IP στην ανάπτυξη ενός ενοποιηµένου περιβάλλοντος για την επίλυση του προβλήµατος της επικοινωνιακής διαλειτουργικότητας µεταξύ ετερογενών δικτύων πεδίου. Εισαγωγή - Αντικείµενο του Έργου Το ζήτηµα της διασύνδεσης και διαλειτουργικότητας µεταξύ ετερογενών διατάξεων πεδίου και συστηµάτων δικτύωσης αποτελεί µια από τις βασικότερες απαιτήσεις στη περιοχή της βιοµηχανικής δικτύωσης. Εκτεταµένες ερευνητικές δραστηριότητες έχουν λάβει χώρα σε πολλές περιοχές, όπως τυποποίηση των πρωτοκόλλων επικοινωνίας πεδίου και µοντελοποίηση των οντοτήτων. Από τις δραστηριότητες αυτές, έχουν παραχθεί σηµαντικά αποτελέσµατα, όπως η τυποποίηση ISO 9506 MMS και η ανάπτυξη πολλών ολοκληρωµένων συστηµάτων πεδίου, είτε επισήµως τυποποιηµένων (όπως η ΕΝ50170) είτε προσανατολισµένων στην αγορά ως "de facto" τυποποιήσεις. Στις περισσότερες περιπτώσεις βασικός στόχος είναι η επίλυση των προβληµάτων διαλειτουργικότητας αναφορικά µε τη σύνδεση διατάξεων πεδίου διαφορετικών κατασκευαστών. Όµως, η απαίτηση για καθολική διαλειτουργικότητα σε ένα ολοκληρωµένο βιοµηχανικό περιβάλλον, το οποίο πιθανά αποτελείται από ετερογενή δίκτυα πεδίου και τοπικά δίκτυα, αποτελεί ένα ακανθώδες ζήτηµα και πηγή δηµιουργίας προβληµάτων σε καθηµερινή βάση.

7 ΑΡΤΙΟ Τελική έκθεση 7 Όπως αναφέρθηκε παραπάνω, πρέπει να γίνουν πολλά βήµατα προς την κατεύθυνση του προβλήµατος της διαλειτουργικότητας, παρ' ότι έχουν ήδη υπάρξει κάποιες προσπάθειες. Αρχικά, καθορίστηκαν τα χαµηλού επιπέδου πρωτόκολλα προσπέλασης µέσου (MAC) για τη διασύνδεση των διατάξεων πεδίου. Κατόπιν προδιαγράφηκαν αφηρηµένες περιγραφές αντικειµένων για τα υψηλότερα επίπεδα (εφαρµογής) του µοντέλου OSIRM, όπως η ιδεατή κατασκευαστική διάταξη (virtual manufacturing device) του MMS. Επιπρόσθετα, ένα επίπεδο χρήστη καθορίστηκε ιδιαιτέρως για τα δίκτυα πεδίου, βασισµένη στη µεθοδολογία Function Block modeling και Device Description. Όµως, δεν υπάρχει ακόµη ένα ευρύτατα αποδεκτό µοντέλο περιγραφής διατάξεων µε αποτέλεσµα κάθε δίκτυο πεδίου να έχει τη δική του συγκεκριµένη υλοποίηση. Σε κάθε περίπτωση, όλες αυτές οι προσεγγίσεις εστιάζουν στην παροχή της ιδιότητας διαλειτουργικότητας, στο επίπεδο ενός δικτύου πεδίου. Όµως, η ολοκλήρωση των διατάξεων - συσκευών στα δίκτυα ελέγχου και των δικτύων ελέγχου σε µια ολοκληρωµένη πολυ-δικτυακή, και όχι απαραίτητα οργανωµένη µε βάση ένα απλό τοπικό δίκτυο, βιοµηχανική επικοινωνιακή δοµή, θα πρέπει να θεωρηθεί από δύο οπτικές γωνίες. Η πρώτη από αυτές είναι η διαδικασία του σχεδιασµού και της διαµόρφωσης ενός ολοκληρωµένου συστήµατος παρακολούθησης και ελέγχου βιοµηχανικής διεργασίας, και η δεύτερη είναι η φάση λειτουργίας του συστήµατος που περιλαµβάνει την διακίνηση δεδοµένων που υποστηρίζουν την διαδικασία παρακολούθησης και ελέγχου αλλά και την διακίνηση δεδοµένων που υπόκεινται σε αυστηρούς χρονικούς περιορισµούς. Ο στόχος της καθολικής διαλειτουργικότητας µπορεί να πραγµατοποιηθεί µε τη δηµιουργία ενός µοντέλου που διασφαλίζει τη διαλειτουργικότητα µεταξύ συσκευών ετερογενών δικτύων πεδίου. Προς αυτήν την κατεύθυνση, η υπό ανάπτυξη τεχνολογία OPC (OLE for Process Control) της Microsoft µπορεί να χρησιµοποιηθεί ως µια ευρέως αποδεκτή πλατφόρµα λογισµικού, η οποία επιλύει το πρόβληµα της διαχρηστικότητας των ετερογενών δικτύων πεδίου µιας βιοµηχανικής µονάδας. Ακόµη όµως και αυτή η τεχνολογία παρουσιάζει κάποια µειονεκτήµατα, µε δεδοµένο ότι είναι διαθέσιµη µόνο για το λειτουργικό σύστηµα Windows και το επικοινωνιακό µοντέλο Common Object Model (COM). Καθώς υπάρχουν προσπάθειες για µεταφορά του επικοινωνιακού µοντέλου COM και στο UNIX το κύριο µειονέκτηµα της τεχνολογίας OPC είναι ότι αυτή καλύπτει προς το παρόν µόνο τις διαδικασίες µεταφοράς δεδοµένων (data access), και διαχείρισης γεγονότων και κρίσιµων καταστάσεων παρέχοντας τα αντίστοιχα APIs. εν υπάρχει API πάνω στο οποίο να µπορεί να βασιστεί η ανάπτυξη του εργαλείου µηχανικού (Engineering Support System -ESS). Επιπλέον δεν αντιµετωπίζεται καθόλου το θέµα της διασύνδεσης διαφορετικών δικτύων πεδίου. Στα πλαίσια του παρόντος έργου προτείνεται µια νέα προσέγγιση για την αντιµετώπιση του σηµαντικού προβλήµατος της εξασφάλισης διαλειτουργικότητας (interoperability) µεταξύ ετερογενών βιοµηχανικών δικτύων ελέγχου (fieldbuses) που βρίσκονται διάσπαρτα στις βιοµηχανικές µονάδες, κυρίως από την οπτική γωνία του Μηχανικού Συστηµάτων Ελέγχου. Ο κύριοι στόχοι του έργου είναι: Η πλήρης ολοκλήρωση πολλαπλών ετερογενών βιοµηχανικών δοµών ελέγχου στο συνολικό βιοµηχανικό πληροφοριακό περιβάλλον Η δυνατότητα ευέλικτης διαχείρισης (προγραµµατισµός - διαµόρφωση) των δικτύων αυτών µε ενιαίο τρόπο και µέσω ΙP δικτύων, δηλαδή και µέσω του

8 ΑΡΤΙΟ Τελική έκθεση 8 INTERNET, ανεξάρτητα, δηλαδή, από την γεωγραφική θέση του διαχειριστή µηχανικού Επιπλέον, η πρακτική αυτή οδηγεί στην απεικόνιση και "µεταφορά" των φυσικών χαρακτηριστικών των δικτύων ελέγχου (δηλαδή ντετερµινιστικές µεταδόσεις) σε µια τεχνολογία βασισµένη στο πρωτόκολλο IP, οδηγώντας στη διαφανή γεφύρωση και οµογενοποίηση ετερογενών δικτύων ελέγχου µέσω µιας διασύνδεσης IP, η οποία είναι κλιµακούµενη (scalable) και προσφέρει προσαρµοζόµενη (adaptable) ποιότητα υπηρεσίας (Quality of Service QoS). Tο έργο αυτό στοχεύει: στη σχεδίαση και ανάπτυξη ενός γενερικού εργαλείου µηχανικού (engineering tool) µε βάση τις τεχνολογίες Java (Real-Time Java) και Jini, το οποίο προορίζεται για το Μηχανικό Συστηµάτων Βιοµηχανικού Ελέγχου, για τον προγραµµατισµό και τη διαµόρφωση συστηµάτων ελέγχου που στηρίζονται σε δίκτυα πεδίου στη σχεδίαση και ανάπτυξη µιας δικτυακού τύπου διάταξης πολλαπλών λειτουργιών MFND (Multi-Functional Networking Device), η οποία παίζει το ρόλο, τόσο της ευφυούς γέφυρας στο επίπεδο εφαρµογής (application gateway), όσο και του δροµολογητή ανάµεσα στο δίκτυο ελέγχου και τη δικτυακή υποδοµή IP στην ανάπτυξη ενός ενοποιηµένου περιβάλλοντος για την επίλυση του προβλήµατος της επικοινωνιακής διαλειτουργικότητας µεταξύ ετερογενών δικτύων πεδίου. 3 Αναλυτική έκθεση της πορείας του ερευνητικού έργου και των ερευνητικών αποτελεσµάτων Στο τµήµα αυτό δίνεται η αναλυτική έκθεση της πορείας του ερευνητικού έργου καθώς και των ερευνητικών αποτελεσµάτων ανά φάση όπως αυτές ορίζονται στο χρονοδιάγραµµα υλοποίησης του έργου. Στην πρώτη φάση (Φ1): 1. Ολοκληρώθηκε η ανάλυση απαιτήσεων για επικοινωνιακή διαλειτουργικότητα στο Βιοµηχανικό ικτυακό περιβάλλον. Καταγράφηκαν οι απαιτήσεις και µελετήθηκε το πρόβληµα του πραγµατικού χρόνου. Μελετήθηκαν οι τρέχουσες τεχνικές περιγραφής συσκευών δικτύου και εντοπίσθηκαν τα θετικά και αρνητικά τους χαρακτηριστικά.. Μελετήθηκαν οι εναλλακτικές επιλογές που αφορούν τις πιθανές τοπολογίες διασύνδεσης ετερογενών βιοµηχανικών δικτύων και η βασική αρχιτεκτονική του προτεινόµενου συστήµατος. 3. Έγινε διεξοδική µελέτη των επικρατέστερων προηγµένων τεχνολογιών λογισµικού για να διαπιστωθεί κατά πόσο µπορούν να χρησιµοποιηθούν στα πλαίσια του έργου. 4. Μελετήθηκαν οι προδιαγραφές των δύο δικτύων πεδίου Profibus και Lonworks και αναλύθηκαν οι ιδιαιτερότητες του κάθε δικτύου. Επίσης καταγράφηκαν τα χαρακτηριστικά τους για την περαιτέρω κρίση των δικτύων αυτών ως κατάλληλα για τη συγκεκριµένη εφαρµογή. Στην δεύτερη φάση (Φ):

9 ΑΡΤΙΟ Τελική έκθεση 9 1. ηµιουργήθηκε η κατάλληλη υποδοµή που κρίθηκε απαραίτητη για την ανάπτυξη του γενερικού εργαλείου µηχανικού.. Σχεδιάστηκε το γενερικό εργαλείο µηχανικού για τον προγραµµατισµό και διαµόρφωση δικτυακών βιοµηχανικών συστηµάτων ελέγχου. 3. Αναπτύχθηκε το κοινό µοντέλο περιγραφής συσκευής για χρήση τόσο κατά το σχεδιασµό όσο και κατά την φάση λειτουργίας του συστήµατος. 4. όθηκε η αρχιτεκτονική της ικτυακής Μονάδας MFND. 5. Αναπτύχθηκε µια πρωτότυπη υλοποίηση της ικτυακής Μονάδας MFND. Στην τρίτη φάση (Φ3): 1. Έγινε η ολοκλήρωση των επιµέρους συνιστωσών του συστήµατος.. Αναπτύχθηκαν τα Profibus και Lonworks µοντέλα λειτουργίας. 3. Έγιναν δοκιµές, µετρήσεις και τροποποιήσεις. Στα πλαίσια της τέταρτης φάσης (Φ4): 1. Υλοποίηση του OPC server για τον έλεγχο της εφαρµογής. Έγινε διάδοση των ερευνητικών αποτελεσµάτων µεταξύ των συµµετεχόντων φορέων. 3. ιαδόθηκαν και αξιολογήθηκαν τα ερευνητικά αποτελέσµατα µέσα από την συγγραφή και παρουσίαση ενός συνόλου ερευνητικών εργασιών σε διεθνή συνέδρια. Στη συνέχεια γίνεται αναλυτική αναφορά στις παραπάνω δραστηριότητες. 4 Ανάλυση απαιτήσεων και καταγραφή προδιαγραφών Στα πλαίσια της 1ης φάσης (Φ1) µελετήθηκαν διεξοδικά οι απαιτήσεις που τίθενται από το υπό ανάπτυξη σύστηµα καθώς και ορισµένες προηγµένες τεχνολογίες λογισµικού για να διαπιστωθεί κατά πόσο µπορούν να χρησιµοποιηθούν στα πλαίσια του έργου. Όσον αφορά την πρώτη διάσταση, καταγράφηκαν οι απαιτήσεις για µια αξιόπιστη διασύνδεση ετερογενών µονάδων δικτύου πεδίου και ιδιαίτερα οι απαιτήσεις που τίθενται από την διάσταση πραγµατικού χρόνου των συστηµάτων αυτών. Σχετικά µε την δεύτερη διάσταση, εξ αρχής υιοθετήθηκε η αντικειµενοστραφής προσέγγιση καθώς έχει γίνει αποδεκτό ότι προσφέρει λύση σε πολλά από τα προβλήµατα της διαδικασίας ανάπτυξης (ανάλυσης, σχεδιασµού και υλοποίησης) συστηµάτων. Έτσι το σύνολο των τεχνολογιών που µελετήθηκαν ανήκουν στην κατηγορία των αντικειµενοστρεφών τεχνολογιών. Ξεκινώντας από την γλώσσα προγραµµατισµού διαπιστώθηκε µια συνεχώς αυξανόµενη τάση για εισαγωγή της γλώσσας προγραµµατισµού Java στη βιοµηχανία. Η Java αν και ξεκίνησε σαν γλώσσα για ενσωµατωµένες συσκευές, εξελίχθηκε στην πορεία σε γενικού σκοπού αντικειµενοστρεφή γλώσσα µε κύρια έµφαση στον προγραµµατισµό για το Internet. Σαν αντικειµενοστραφής γλώσσα παρουσιάζει πολλά πλεονεκτήµατα σε σχέση µε την C++ αλλά υστερεί σηµαντικά στις επιδόσεις καθώς και στα constructs για χαµηλού επιπέδου προγραµµατισµό. Τα δύο αυτά σηµεία προσωρινά αντιµετωπίστηκαν µε τον µηχανισµό για κλήση native κώδικα που κρίθηκε απαραίτητος για εφαρµογές αυτού του είδους. Παρόλα αυτά η απαίτηση για βελτίωση των χαρακτηριστικών του περιβάλλοντος είχε σαν αποτέλεσµα επεκτάσεις

10 ΑΡΤΙΟ Τελική έκθεση 10 που είναι γνωστές σαν Real-Time Java. Οι προσπάθειες αυτές έχουν ήδη ξεπεράσει το ερευνητικό στάδιο και κρίνεται πως είναι ώριµες για χρήση στα πλαίσια του παρόντος έργου. Η συνεχής τάση για ανάπτυξη κατανεµηµένων αντικειµενοστραφών συστηµάτων ήταν επόµενο να προκαλέσει την εµφάνιση περιβαλλόντων που θα µπορούν να δώσουν την κατάλληλη υποδοµή για την ταχύτερη και πλέον αξιόπιστη ανάπτυξη των συστηµάτων αυτών. Η Αρχιτεκτονική Common Object Request Broker (CORBA) είναι η πρώτη αξιόλογη προσπάθεια προς την κατεύθυνση της διασφάλισης µιας επικοινωνιακής υποδοµής για την συνεργασία ετερογενών συνιστωσών λογισµικού. Η τεχνολογία DCOM που αποτελεί επέκταση της COM τεχνολογίας της Microsoft θεωρείται ανταγωνιστική της CORBA υστερεί όµως ως προς τον βαθµό που προσδιορίζει το ανοικτό του συστήµατος αλλά και τον γενικό σχεδιασµό καθώς δεν υιοθετεί πλήρως την αντικειµενοστρεφή προσέγγιση. Παρόλα αυτά η DCOM τεχνολογία αν και σχετικά νεότερη της CORBA κατάφερε προσφέροντας την τεχνολογία OPC να πετύχει µια ευρύτερη αποδοχή στον χώρο της βιοµηχανίας. Προς ανάλογη κατεύθυνση αλλά µε κύριο στόχο την αυτοµατοποίηση των διαδικασιών διαµόρφωσης ενός κατανεµηµένου συστήµατος κινείται η τεχνολογία Jini, η οποία βασίζεται στο περιβάλλον της Java. Οι παραπάνω αναφερόµενες τεχνολογίες µελετήθηκαν σε βαθµό που να είναι δυνατή η υιοθέτηση και χρήση τους στα πλαίσια του παρόντος έργου. Μια αναλυτική αναφορά στις τεχνολογίες αυτές δίνεται σε επόµενο κεφάλαιο. Όσον αφορά στην µεθοδολογία προσέγγισης διακρίθηκαν σύµφωνα µε την αρχιτεκτονική που προτάθηκε (περιγράφεται παρακάτω), τα µονοπάτια πραγµατικού (real-time path) και µη πραγµατικού χρόνου (non real-time path). Όσον αφορά στην επιλογή του ολοκληρωµένου βιοµηχανικού περιβάλλοντος, τα δύο ετερογενή, δηµοφιλή δίκτυα πεδίου Profibus και Lonworks, αποτέλεσαν τον οδηγό για την υλοποίηση της εφαρµογής. Κρίθηκαν κατάλληλα για να παρουσιάσουν ένα πλήρες πλαίσιο ιδιαίτερων χαρακτηριστικών των βιοµηχανικών δικτύων, τα οποία αποτέλεσαν τα κριτήρια απόδοσης της προτεινόµενης προσέγγισης ως προς την καθολική και αξιόπιστη επικοινωνιακή διαλειτουργικότητα στο βιοµηχανικό περιβάλλον. Προς την κατεύθυνση του αναλυτικού ορισµού των δοµών υποστήριξης των δύο παραπάνω µονοπατιών ορίσθηκαν οι παρακάτω επιµέρους περιοχές µε τις αντίστοιχες δραστηριότητες οι οποίες εξελίχθηκαν παράλληλα: 1. Βιοµηχανικό δίκτυο Profibus. Βιοµηχανικό δίκτυο Lonworks 3. Επιλογή ολοκληρωµένης δικτυακής δοµής 4. Εικονικό δίκτυο πεδίου (Virtual fieldbus) 5. Εργαλείο Μηχανικού 6. Ανοιχτό πραγµατικό σύστηµα πραγµατικού χρόνου 7. OPC 4.1 Ανάλυση Απαιτήσεων Τα Βιοµηχανικά ίκτυα Υπολογιστών αποτελούν µία υποκατηγορία των Τοπικών ικτύων Υπολογιστών µε συγκεκριµένες απαιτήσεις και προδιαγραφές. Ο σκοπός των δικτύων αυτών είναι να αποτελέσουν την βάση για σύγχρονα, ευέλικτα και αποδοτικά συστήµατα αυτοµατοποίησης. Στα συστήµατα αυτά απαιτείται η αξιόπιστη

11 ΑΡΤΙΟ Τελική έκθεση 11 διασύνδεση ετερογενών µονάδων, όπως υπολογιστικά συστήµατα γενικού ή / και ειδικού σκοπού, προγραµµατιζόµενοι λογικοί ελεγκτές, αισθητές, ενεργοποιητές κλπ Το Αίτηµα του Πραγµατικού Χρόνου Η κύρια λειτουργική απαίτηση που πρέπει να ικανοποιούν τα προηγµένα συστήµατα αυτοµατοποίησης είναι η εξασφάλιση της δυνατότητας απόκρισης τους σε πραγµατικό χρόνο. Ως εκ τούτου, τα βιοµηχανικά δίκτυα υπολογιστών, που παρέχουν την υποδοµή για ανάπτυξη κατανεµηµένων συστηµάτων αυτοµατοποίησης, θα πρέπει να εξασφαλίζουν δικτυακή απόκριση σε πραγµατικό χρόνο. Υπάρχουν δύο µεγάλες κατηγορίες στις οποίες κατατάσσονται τα δίκτυα πραγµατικού χρόνου: ίκτυα Αυστηρού Πραγµατικού Χρόνου ίκτυα Eλαστικού Πραγµατικού Χρόνου ίκτυα Αυστηρού Πραγµατικού Χρόνου Ο όρος αυτός αναφέρεται σε δίκτυα στα οποία η ορθή λειτουργία του όλου συστήµατος εξαρτάται όχι µόνο από το λογικό αποτέλεσµα των διαφόρων διαδικασιών, αλλά επίσης και από το χρόνο στον οποίο τα αποτελέσµατα αυτά παράγονται. Ως εκ τούτου, το δίκτυο αυστηρού πραγµατικού χρόνου (hard real-time network) είναι αυτό στο οποίο ο χρόνος κάθε επικοινωνιακού του έργου έχει ένα αυστηρά καθορισµένο χρονικό σηµείο λήξης (deadline). Χρησιµοποιείται επίσης και ο όρος κρίσιµου χρόνου (time-critical) για να δηλώσει την απαίτηση µετάδοσης των πακέτων µέσα σε κρίσιµο χρόνο, όπως πχ. στην περίπτωση εφαρµογών συναγερµού. Συνεπώς, κατ αρχήν το MAC πρωτόκολλο, ως το κατώτατο επικοινωνιακό πρωτόκολλο, πρέπει να παρέχει τη δυνατότητα µετάδοσης πακέτων µέσα σε αυστηρά καθορισµένο χρόνο ή όριο καθυστέρησης, D max (delay bound) ίκτυα Eλαστικού Πραγµατικού Χρόνου Η κατηγορία αυτή αναφέρεται σε δίκτυα, που στοχεύουν στη µεγιστοποίηση του ποσοστού των πακέτων που µεταδίδονται ικανοποιώντας κάποιο προκαθορισµένο χρονικό όριο µετάδοσης. Ως εκ τούτου, στην περίπτωση των δικτύων ελαστικού χρόνου (soft real-time networks), επιτρέπεται η παραβίαση του χρονικού ορίου µετάδοσης για ένα περιορισµένο ποσοστό πακέτων ανάλογα µε την εφαρµογή. Ένα τέτοιο πακέτο, που δεν έχει µεταδοθεί επιτυχώς µέσα σε κάποιο χρονικό όριο µετά τη στιγµή της δηµιουργίας του, θεωρείται χαµένο (lost, discard), άσχετα αν τελικά λαµβάνεται από το σταθµό προορισµού. Είναι λοιπόν φανερό ότι ένα µικρό ποσοστό απώλειας µηνυµάτων είναι συνήθως δεκτό. Ως εκ τούτου, ο βασικός στόχος δεν εντοπίζεται στην ελαχιστοποίηση της µέσης καθυστέρησης του µηνύµατος, αλλά στη µεγιστοποίηση του ποσοστού των επιτυχών µεταδόσεων µέσα στο προκαθορισµένο από την εκάστοτε εφαρµογή χρονικό διάστηµα Τύποι Κίνησης Βιοµηχανικών ικτύων Υπάρχουν δύο µεγάλες κατηγορίες στις οποίες ανήκει ο τύπος της κίνησης ενός βιοµηχανικού δικτύου, η οποία θέτει και τις απαιτήσεις για απόκριση σε πραγµατικό χρόνο που αναφέρθηκαν προηγουµένως: Σύγχρονη Κίνηση (Synchronous Traffic): Είναι η κίνηση που δηµιουργείται από: i. την περιοδική δειγµατοληψία και µετάδοση των τιµών διαφόρων µεταβλητών που παράγουν οι αισθητές και

12 ΑΡΤΙΟ Τελική έκθεση 1 ii. από τη µετάδοση δεδοµένων και εντολών προς τους ενεργοποιητές Τα σύγχρονου ή περιοδικού τύπου µηνύµατα συνήθως υπόκεινται σε αυστηρούς περιορισµούς ως προς το επιτρεπόµενο µέγιστο χρόνο απόκρισης ο οποίος για κλασσικές βιοµηχανικές εφαρµογές είναι της τάξης λίγων ms. Οι ακολουθίες των µηνυµάτων της σύγχρονης κίνησης εµφανίζονται κυκλικά µε προκαθορισµένη περιοδικότητα, και η τήρηση των χρονικών απαιτήσεων εξασφαλίζεται δεσµεύοντας το απαιτούµενο εύρος ζώνης (bandwidth) του δικτύου κατά τη σύνθεση (configuration) του συστήµατος. Ασύγχρονη Kίνηση (Αsynchronous Traffic): Είναι η κίνηση που προέρχεται από τυχαία παραγόµενα πληροφοριακά πακέτα ή µηνύµατα. Το µεγάλο ποσοστό αυτής της κίνησης δεν απαιτεί εξυπηρέτηση σε πραγµατικό χρόνο (απλή ασύγχρονη κίνηση) και µπορεί να προέρχεται από: i. φόρτωµα προγραµµάτων και παραµέτρων ii. συλλογή στοιχείων για επεξεργασία και διάγνωση της κατάστασης των συσκευών πεδίου iii. συλλογή πληροφορίας για τη διαµόρφωση του τρόπου της λειτουργίας των συσκευών / µονάδων του συστήµατος (τύπος συσκευών και αλγορίθµων που χρησιµοποιούνται, οι παράµετροι λειτουργίας κλπ.). Αντίθετα, η ασύγχρονη κίνηση που προέρχεται από σήµατα υψηλής προτεραιότητας όσον αφορά στη διαχείριση τους, όπως πχ. σήµατα συναγερµού, απαιτεί εξυπηρέτηση σε αυστηρό (κρίσιµο) πραγµατικό χρόνο και άρα χαρακτηρίζεται ως ασύγχρονη κίνηση κρίσιµου χρόνου. Το ποσοστό αυτής της κίνησης είναι συνήθως µικρό και δεν ξεπερνά συνήθως το 10% της συνολικής ασύγχρονης κίνησης Απαιτήσεις Πραγµατικού χρόνου στη ιασύνδεση Βιοµηχανικών ικτύων Στην περίπτωση της διασύνδεσης δύο δικτύων, ίδιας ή διαφορετικής τεχνολογίας, απ ευθείας ή µέσω τρίτης δικτυακής δοµής, η διατήρηση των χρονικών χαρακτηριστικών της από άκρο σε άκρο κίνησης των µηνυµάτων δεν µπορεί να θεωρείται δεδοµένη. Ενώ δηλαδή η ύπαρξη ενός ντετερµινιστικού µηχανισµού λειτουργίας ενός τµήµατος δικτύου αποτελεί ικανή συνθήκη για την χρονική συµπεριφορά του, η παράλληλη ύπαρξη ενός δεύτερου µηχανισµού ίδιου ή διαφορετικού εισάγει κατ ελάχιστο την απαίτηση συγχρονισµού των δύο ανεξάρτητων µηχανισµών. Και όταν η διασύνδεση των βιοµηχανικών δικτύων γίνεται µέσω άλλης δικτυακής δοµής, ο συγχρονισµός αυτός απαιτεί ντετερµινιστική συµπεριφορά στις επικοινωνιακές διαδικασίες της δοµής αυτής Το Αίτηµα της ιαλειτουργικότητας Σήµερα, βασική και ουσιαστική απαίτηση των δικτύων πεδίου είναι η διασφάλιση του χαρακτηριστικού της σφαιρικής διασύνδεσης και επικοινωνιακής διαλειτουργικότητας µεταξύ ετερογενών διατάξεων πεδίου και συστηµάτων δικτύωσης, λόγω, κυρίως, του µεγάλου βαθµού ετερογένειας που χαρακτηρίζει τις συσκευές πεδίου διαφορετικών κατασκευαστών και τα υποσυστήµατα λογισµικού διαχείρισης δικτύου και εφαρµογής.

13 ΑΡΤΙΟ Τελική έκθεση 13 Εκτεταµένες δραστηριότητες Ε&Α έχουν λάβει χώρα σε πολλές περιοχές, όπως τυποποίηση των πρωτοκόλλων επικοινωνίας πεδίου και µοντελοποίηση των οντοτήτων. Αρχικά, καθορίστηκαν τα χαµηλού επιπέδου πρωτόκολλα προσπέλασης µέσου (MAC) για τη διασύνδεση των διατάξεων πεδίου. Κατόπιν προδιαγράφηκαν αφηρηµένες περιγραφές αντικειµένων για τα υψηλότερα επίπεδα (εφαρµογής) του µοντέλου OSIRM, όπως η ιδεατή κατασκευαστική διάταξη (virtual manufacturing device - VMD) του MMS (ISO 9506) προτύπου. Επιπρόσθετα, ένα επίπεδο χρήστη καθορίστηκε ιδιαιτέρως για τα δίκτυα πεδίου, βασισµένο στη µεθοδολογία Function Block modeling και Device Description. Όµως, δεν υπάρχει ακόµη ένα ευρύτατα αποδεκτό µοντέλο περιγραφής διατάξεων µε αποτέλεσµα κάθε δίκτυο πεδίου να έχει τη δική του συγκεκριµένη υλοποίηση. Κατά συνέπεια, η απαίτηση για σφαιρική διαλειτουργικότητα σε ένα ολοκληρωµένο βιοµηχανικό περιβάλλον, το οποίο πιθανά αποτελείται από ετερογενή δίκτυα πεδίου και τοπικά δίκτυα, είναι ακόµη µακριά από το να ικανοποιηθεί ένεκα σοβαρών τεχνολογικών προβληµάτων, όπως η ασυµβατότητα των προγραµµατιστικών διεπαφών (interfaces) και η εξάρτηση από τη πλατφόρµα υλικού. Ο στόχος της σφαιρικής ολοκλήρωσης µπορεί πραγµατοποιηθεί µόνο µε την κατάλληλη δοµή ενός προγραµµατιστικού µοντέλου, το οποίο θα παρέχει µια τυποποιηµένη µεθοδολογία η οποία θα εξασφαλίσει τη διαλειτουργικότητα διεπαφών Το Επίπεδο Χρήστη (User Layer) Όπως έχει ήδη αναφερθεί, το κύριο αίτηµα της διαλειτουργικότητας έχει οδηγήσει σε εισαγωγή ενός επιπλέον επιπέδου πάνω από τον κατά OSI-RM περιορισµένο επικοινωνιακό σωρό των τριών επιπέδων των βιοµηχανικών δικτύων. Το επίπεδο αυτό ονοµάζεται Επίπεδο Χρήστη (User Layer) και ορίζει µία αντικειµενοστρεφή δοµή (object-oriented structure) βάσει της οποίας είναι δυνατή η περιγραφή του βιοµηχανικού περιβάλλοντος µε ενιαίο τρόπο. Η επιτροπή προτυποποίησης ISA / IEC SP50 έχει καταλήξει σε µια εκτενέστατη περιγραφή του προτύπου που πρέπει να ακολουθείται από το βιοµηχανικό περιβάλλον ώστε να είναι δυνατή η επίτευξη της διαλειτουργικότητας των βιοµηχανικών εξαρτηµάτων. Για τον ορισµό και προτυποποίηση τµηµάτων του επιπέδου αυτού έχουν αναληφθεί διάφορες δραστηριότητες, όπως αυτή του ορισµού της Γλώσσας Περιγραφής Συσκευών (Device Description Language, DDL). Η πλέον σηµαντική δραστηριότητα αφορά στη δηµιουργία µιας διεθνούς επιτροπής µε σκοπό την πρόταση ενός διεθνώς αποδεκτού προτύπου σχετικά µε επίπεδο χρήστη. Αυτή η επιτροπή, η ISA/IEC SP5O έχει ήδη επεξεργασθεί και επιδώσει ένα σχέδιο (draft) πρότασης για ένα πρότυπο στο επίπεδο χρήστη. Η ακολουθούµενη διαδικασία προβλέπει την ενσωµάτωση στο πρότυπο των ιδιοτήτων και δοµών των πλέον σηµαντικών ήδη υπαρχόντων συσκευών ελέγχου (DCSs, PLCs). Σύµφωνα µε αυτό το πρότυπο η αρχιτεκτονική του επιπέδου χρήσης ακολουθεί µια αντικειµενοστραφή προσέγγιση. Συγκεκριµένα, υπάρχουν τρεις τύποι αντικειµένων, δηλαδή ο Φυσικός Κόµβος (Physical Node, PN), o Λογικός Κόµβος (Logical Node, LN) και η Οµάδα Συναρτήσεων (Function Block, FB). Ένα κοινό χαρακτηριστικό όλων των αντικειµένων που ορίζονται στο πρότυπο είναι ότι αυτά µπορούν να αναγνωρισθούν µε την χρήση ενός πεδίου διεύθυνσης (TAG) εύρους 16 bits, ενώ ταυτόχρονα τα αντικείµενα αυτά διαθέτουν και ένα πεδίο δεδοµένων για την καταγραφή των πληροφοριών που σχετίζονται µε αυτά.

14 ΑΡΤΙΟ Τελική έκθεση 14 Ως PN ορίζεται κάθε συσκευή που µπορεί να διασυνδεθεί σε ένα δίκτυο πεδίου. Ο LN είναι ένα έργο (task) που µπορεί να εκτελεσθεί σε ένα PN, άρα ένας ΡΝ µπορεί να περιέχει ένα ή περισσότερους LNs. Τέλος, ένας LN είναι το αποτέλεσµα µιας σειράς κλήσεων στοιχειωδών συναρτήσεων που εκτελούν κάποιο είδος συλλογής, εξόδου διαχείρισης δεδοµένων και ορίζουν το FB. Κάθε LN µπορεί να περιέχει ένα ή περισσότερα FBs οµές λειτουργίας (Function Blocks) Από τα προηγούµενα συνάγεται ότι η βάση του επιπέδου χρήστη είναι η ιδέα του FB. Το FB είναι ένα αντικείµενο που περιέχει έναν αλγόριθµο και µία βάση δεδοµένων. Ο αλγόριθµος παριστά την συναρτησιακή-λειτουργική συµπεριφορά του FB. H βάση δεδοµένων περιέχει τα δεδοµένα που είναι απαραίτητα για τον ορισµό του FB και την εκτέλεση του αλγορίθµου. Επίσης, η βάση περιέχει τις εισόδους και εξόδους του FB καθώς και τις παραµέτρους του. Όλα τα δεδοµένα που µπορούν να προσπελαθούν µέσω του δικτύου πεδίου είναι τα attributes του FB. Συναγερµοί Είσοδοι Αλγόριθµοι Προµηθευτή Εξοδοι Υποσύστηµα Γεγονότων οµή Τρόπου Λειτουργίας (πχ. Auto, Manual) Σχήµα 1. Η δοµή του FB. Η ιδέα της διαλειτουργικότητας είναι ως, εκ τούτου, αφ ενός σχετική µε τον ορισµό του FB µε τέτοιο τρόπο ώστε η συµπεριφορά και απόδοση του να ακολουθεί συγκεκριµένους κανόνες και αφ ετέρου η δηµιουργία του LN, που συνίσταται από ακολουθίες κλήσεων FBs, να βασίζεται σε ακριβώς καθορισµένη χρονική σειρά και εκτέλεση FBs Η Τεχνολογία Περιγραφής Συσκευών Πεδίου Η τεχνολογία περιγραφής συσκευών (DD) πεδίου είναι µία µέθοδος που έχει προταθεί για την επίτευξη διαλειτουργικότητας µεταξύ των συσκευών πεδίου διαφορετικών κατασκευαστών ή δικτύων και χρησιµοποιείται επιπροσθέτως του ορισµού των πρότυπων παραµέτρων και λειτουργικότητας των FBs. Η περιγραφή συσκευής είναι ουσιαστικά ένας οδηγός (driver) για τη συσκευή, υλοποιώντας ουσιαστικά την περιγραφή, µε ένα πρότυπο τρόπο, των αντικειµένων που περιλαµβάνονται σε ένα VMD. Για την εγκατάσταση της συσκευής δεν απαιτείται τίποτα περισσότερο από την σύνδεση της στο δίκτυο πεδίου και στην τροφοδότηση του κεντρικού συστήµατος ελέγχου µε την DD της συσκευής. Η DD περιλαµβάνει τις λειτουργικές διαδικασίες, τις περιγραφές των µεταβλητών και άλλες πληροφορίες που απαιτούνται από τον κεντρικό σταθµό.

15 ΑΡΤΙΟ Τελική έκθεση 15 Η περιγραφή συσκευής γράφεται σε µια ειδική τυποποιηµένη γλώσσα προγραµµατισµού, γνωστή ως Device Description Language (DDL). Τυπικά, οι προµηθευτές συσκευών προετοιµάζουν ένα συµπληρωµατικό DD που αναφέρεται στο Πρότυπο των DDs. Επίσης, οι προµηθευτές µπορούν να προσθέτουν ειδικά χαρακτηριστικά στις συσκευές τους, όπως π.χ. πληροφορίες ρύθµισης και διαγνωστικών. Ως εκ τούτου, µπορούν να προστίθενται νέες συσκευές στο δίκτυο πεδίου απλά συνδέοντας τις στο κανάλι επικοινωνίας και παρέχοντας στον κεντρικό σταθµό ελέγχου το αντίστοιχο συµπληρωµατικό DD της κάθε νέας συσκευής. Για την ανάγνωση αυτών των DDs των συσκευών, στον κεντρικό σταθµό χρησιµοποιούνται ορισµένες συναρτήσεις βιβλιοθήκης που καλούνται Υπηρεσίες DD (Device Description Services, DDS), όπως φαίνεται στο επόµενο σχήµα. Σχήµα. Οι DDSs χρησιµοποιούνται για την ανάγνωση των περιγραφών συσκευών Πρέπει εδώ να σηµειωθεί ότι οι DDSs διαβάζουν περιγραφές και όχι λειτουργικές τιµές. Οι λειτουργικές τιµές διαβάζονται από την συσκευή πεδίου µέσω των δικτυακών υπηρεσιών του επιπέδου εφαρµογής του δικτύου πεδίου. Είναι σαφές ότι η DDS τεχνολογία επιτρέπει την λειτουργία συσκευών διαφόρων κατασκευαστών πάνω στο ίδιο δίκτυο πεδίου, κάτω από τον έλεγχο ενός µοναδικού HMI, γεγονός που εξασφαλίζει την επιθυµητή διαλειτουργικότητα. Σύµφωνα, λοιπόν, µε όλα τα προηγούµενα, η τελική διαµόρφωση του δικτυακού συστήµατος γίνεται µετά τη σχεδίαση του συστήµατος και την επιλογή των συσκευών και οργάνων πεδίου, µε την διασύνδεση των εισόδων και εξόδων των FBs για κάθε συσκευή, όπως απαιτείται από το σενάριο της εφαρµογής και την στρατηγική ελέγχου (Σχ. 3).

16 ΑΡΤΙΟ Τελική έκθεση 16 Σχήµα 3. Η διασύνδεση των συσκευών περιγράφεται µε την διασύνδεση των εισόδων και εξόδων των αντίστοιχων FBs. Αυτές οι συνδέσεις γίνονται µε χρήση γραφικών αντικειµένων που περιέχονται στο λογισµικό διαµόρφωσης, παριστώντας τις λογικές συνδέσεις µεταξύ των συσκευών πεδίου, που όλες διασυνδέονται φυσικά µέσω του απλού καναλιού επικοινωνίας του δικτύου πεδίου. Μετά από αυτή την πλήρως γραφική αναπαράσταση της αρχιτεκτονικής του συστήµατος, το λογισµικό διαµόρφωσης παράγει τα δεδοµένα διαµόρφωσης για κάθε συσκευή πεδίου, όπως φαίνεται στο Σχ. 4. Ως εκ τούτου, το σύστηµα καθίσταται λειτουργικό, εφ όσον όλες οι διασυνδεδεµένες συσκευές πεδίου έχουν λάβει τα δεδοµένα διαµόρφωσης τους. Σχήµα 4. Η διαδικασία διαµόρφωσης του συστήµατος

17 ΑΡΤΙΟ Τελική έκθεση Απαιτήσεις ιαλειτουργικότητας στη ιασύνδεση Βιοµηχανικών ικτύων Είναι προφανές πως, ενώ η διαλειτουργικότητα ανοµοιογενών συσκευών διασυνδεδεµένων σε ένα δικτύου πεδίου µπορεί να θεωρείται σε αρκετά µεγάλο βαθµό σήµερα δεδοµένη, δεν ισχύει το ίδιο µεταξύ συσκευών συνδεδεµένων σε ετερογενή δίκτυα πεδίου. Συνεπώς, υπάρχει ανάγκη για τον καθορισµό ενός «εικονικού» δικτύου πεδίου (virtual fieldbus), το οποίο θα παρέχει τη λειτουργικότητα των διαφόρων συσκευών στα εργαλεία µηχανικού µε καθορισµένη και κοινή προγραµµατιστική διεπαφή. 4. Λειτουργικές προδιαγραφές 4..1 Αρχιτεκτονική του Συστήµατος Ο µηχανισµός επικοινωνίας αφορά µια δοµή διασύνδεσης, η οποία συνδυάζει κατάλληλα την πραγµατικού χρόνου φύση (hard real-time) των δικτύων πεδίου, µε µια διασύνδεση IP, η οποία είναι κλιµακούµενη (scalable) και προσφέρει προσαρµοζόµενη (adaptable) ποιότητα υπηρεσίας (Quality of Service QoS). Είναι προφανές ότι η επικοινωνία σε πραγµατικό χρόνο που αναφέρθηκε, δεν είναι εφικτή µε την υφιστάµενη δικτυακή υποδοµή επιχείρησης, διότι αυτή είναι βασισµένη σε παραδοσιακές δικτυακές τεχνολογίες (κυρίως TCP/IP πάνω από Ethernet) οι οποίες δεν παρέχουν εγγυηµένη ποιότητα υπηρεσίας. Για την αντιµετώπιση του προβλήµατος αυτού εξετάστηκαν διάφορες τοπολογίες και τελικά επιλέχθηκαν 4 σαν πλέον επικρατέστερες για να µελετηθούν διεξοδικά. Οι 4 τοπολογίες µπορούν να καταταγούν σε δύο κατηγορίες. Η πρώτη από αυτές χρησιµοποιεί το δίκτυο της επιχείρησης για τη διακίνηση πληροφορίας µη πραγµατικού χρόνου και ταυτόχρονα χρησιµοποιεί ένα αφιερωµένο δίκτυο για µεταφορά πληροφορίας πραγµατικού χρόνου (Σχ. 5). Η τοπολογία αυτή είναι στα πλαίσια της αρχικής εκτίµησης (Σχ. 6). Ένα εναλλακτικό σενάριο που διερευνήθηκε είναι η δυνατότητα χρήσης για την διασύνδεση των επί µέρους δικτύων πεδίου ενός δικτύου πεδίου αντί για Ethernet. Configuration Monitoring Ethernet AΡΤΙΟ Gateway AΡΤΙΟ Gateway RT path Ethernet Σχήµα 5. Τοπολογία αφιερωµένου δικτύου για κίνηση πραγµατικού χρόνου.

18 ΑΡΤΙΟ Τελική έκθεση 18 ARTIO Server ARTIO Client Internet ARTIO Client IP Router Fieldbus A Factory plant X ARTIO Gateway 10BaseT Fast Ethernet Factory's Primary Intranet (Backbone LAN - TCP/IP) Traffic type: conventional 10BaseT ARTIO Gateway Fast Ethernet Fieldbus B Factory plant Y 10BaseT ARTIO Gateway Fieldbus C Factory plant Z Fast Ethernet Factory's Secondary Intranet (IP based) Traffic type: real-time Σχήµα 6. Αρχιτεκτονική του ολοκληρωµένου βιοµηχανικού δικτυακού περιβάλλοντος Η δεύτερη κατηγορία χρησιµοποιεί ένα δίκτυο για µεταφορά κάθε είδους πληροφορίας, πραγµατικού χρόνου ή µη (Σχήµα 7). Configuration Monitoring Ethernet AΡΤΙΟ Gateway Non RT RT path Non RT AΡΤΙΟ Gateway Fast/ Switched Ethernet

19 ΑΡΤΙΟ Τελική έκθεση 19 Σχήµα 7.(α) Στην κατηγορία αυτή οι επιλογές που εξετάζονται είναι αφενός µεν η χρήση ΑΤΜ ή GigaBit Ethernet που ικανοποιεί αναµφίβολα τις απαιτήσεις πραγµατικού χρόνου αλλά παρουσιάζει πολύ µεγάλο κόστος εγκατάστασης και αφετέρου η χρήση Fast ή Switched Ethernet. Configuration Monitoring Ethernet AΡΤΙΟ Gateway Non RT RT path Non RT AΡΤΙΟ Gateway ATM or GigaBit Ethernet Σχήµα 7(β). Τοπολογίες ενιαίου δικτύου για κίνηση πληροφορίας πραγµατικού χρόνου και µη. 4.. Η Μονάδα ιασύνδεσης (ΑΡΤΙΟ Gateway) Ο πυρήνας της προτεινόµενης αρχιτεκτονικής είναι η δικτυακού τύπου µονάδα διασύνδεσης (AΡΤΙΟ Gateway). ιακρίνουµε δύο δρόµους επικοινωνίας (Σχήµα 8): Μη Πραγµατικού χρόνου (non real-time path) Πραγµατικού χρόνου (real-time path) Όσον αφορά το non real-time path η µονάδα AΡΤΙΟ Gateway µετασχηµατίζει το δίκτυο πεδίου σε ένα virtual fieldbus (VF), το οποίο ορίστηκε στα πλαίσια του έργου. Το VF παρέχει το απαραίτητο API για την ανάπτυξη αφενός µεν των client που προορίζονται για επίβλεψη και έλεγχο της βιοµηχανικής διεργασίας αφετέρου δε του γενερικού εργαλείου µηχανικού που αναπτύχθηκε στα πλαίσια του έργου και υποστηρίζει τον προγραµµατισµό και τη διαµόρφωση των δικτύων πεδίου. Το ειδικό αυτό εργαλείο µπορεί να «τρέχει» σε σταθµό εργασίας που βρίσκεται είτε στο δίκτυο της επιχείρησης είτε στο Internet διασφαλίζοντας βέβαια την ικανοποίηση των κανονισµών ασφάλειας. Στη περίπτωση µιας συνόδου διαχείρισης, η διάταξη του Σχήµα 8 λειτουργεί ως γέφυρα επιπέδου εφαρµογής και η ροή της πληροφορίας γίνεται διαµέσου της διαστρωµάτωσης TCP/IP, του επιπέδου του εικονικού δικτύου πεδίου και του επιπέδου διαµεσολάβησης του πραγµατικού δικτύου πεδίου (wrapper field device proxies). Για κάθε συσκευή πεδίου υπάρχει ένας wrapper, ο οποίος µετατρέπει την αναπαράσταση της συσκευής στην κατάλληλη µορφή για χρήση από

20 ΑΡΤΙΟ Τελική έκθεση 0 το Gateway. Στην περίπτωση που η συσκευή συνοδεύεται από την απαιτούµενη κοινή αναπαράσταση, ένα proxy της συσκευής πεδίου χρησιµοποιείται από το Gateway για την αποκατάσταση της επικοινωνίας της συσκευής µε το επίπεδο χρήστη. Όσον αφορά το real-time path, η µονάδα AΡΤΙΟ Gateway επιτρέπει τη συνεχή διασύνδεση µεταξύ διαφορετικών δικτύων πεδίου, τα οποία είναι διεσπαρµένα σε τµήµατα της βιοµηχανίας (νησίδες ελέγχου), µε διάφανο τρόπο µέσα από µια διασύνδεση IP. Στη περίπτωση συνόδου συνεχούς επικοινωνίας σε πραγµατικό χρόνο ανάµεσα στα δίκτυα πεδίου, η διάταξη λειτουργεί ως ένας δροµολογητής δικτύου πεδίου-σε-ip, και ενθυλακώνει τα πακέτα του δικτύου πεδίου σε IP datagrams µέσω του επιπέδου δροµολόγησης (real-time dispatchers). Σχήµα 8. Αρχιτεκτονική της µονάδας διασύνδεσης (ΑΡΤΙΟ gateway) Το Σχήµα 9 δίνει µια draft µορφή της αρχιτεκτονικής του ΑΡΤΙΟ Gateway. Σαν λειτουργικό σύστηµα της µονάδας ΑΡΤΙΟ Gateway επιλέχτηκε το Linux και πιο συγκεκριµένα το Real-Time Linux για την ικανοποίηση των απαιτήσεων που τίθενται εξ' αιτίας της ύπαρξης του real-time path. Παρουσιάζονται τα βασικά tasks που τρέχουν στο περιβάλλον του RT Linux καθώς και η µεταξύ τους επικοινωνία. ιακρίνονται η εφαρµογή ελέγχου (control application), ο δαίµονας (process P1) που είναι υπεύθυνος για την ενηµέρωση του items buffer από και προς το δίκτυο πεδίου. To task AΡTIOGT (ΑΡΤΙΟ Gateway) είναι υπεύθυνο για την µετατροπή της διακινούµενης πληροφορίας πραγµατικού χρόνου από και προς το κοινό format και την δροµολόγηση της.

21 ΑΡΤΙΟ Τελική έκθεση Το Γενερικό Εργαλείο Μηχανικού (ESS) Το Γενερικό Εργαλείο Μηχανικού έχει ως στόχο την παροχή στο χρήστη-µηχανικό της δυνατότητας άµεσης αλληλεπίδρασης µε τις υπηρεσίες των διατάξεων πεδίου, οπουδήποτε και αν βρίσκεται στο δίκτυο της επιχείρησης ή στο Internet και ανεξάρτητα από τη δικτυακή τους τεχνολογία. Η ανάπτυξη του βασίζεται στο API του virtual fieldbus και αποτελείται οπωσδήποτε από ένα client διαµέσου του οποίου ο χρήστης έχει αφενός µεν τη δυνατότητα διαµόρφωσης των παραµέτρων του δικτύου αλλά και του σχεδιασµού της βιοµηχανικής εφαρµογής. Control applicati on Process P1 Items ARTIO Gateway Routing Informa tion Table Profibus API IP rpotocol stack Σχήµα 9. Αρχιτεκτονική (draft) του real-time path της µονάδας διασύνδεσης. Ανεξαρτησία από την τεχνολογία πεδίου σηµαίνει πως θα ακολουθηθεί µια προσέγγιση σύγκλισης των διαφορετικών µεθοδολογιών περιγραφής διατάξεων εξαλείφοντας την ανάγκη ύπαρξης δοµοστοιχείων µετάφρασης των γλωσσών περιγραφής διατάξεων (Device Description Language - DDL), τα οποία υπάρχουν σήµερα σε παρόµοια εργαλεία. Η εφαρµογή µπορεί να χρησιµοποιηθεί για την υλοποίηση ενός µηχανισµού διασύνδεσης υπηρεσιών διατάξεων που βρίσκονται σε ετερογενή δίκτυα πεδίου, σύµφωνα µε το σενάριο εφαρµογής ελέγχου (φάση σχεδίασης), έτσι ώστε να δηµιουργηθεί µια δοµή βρόχου ελέγχου σε πραγµατικό χρόνο από άκρο-σε-άκρο, πέρα από τα στενά όρια ενός µοναδικού δικτύου πεδίου. Επιπλέον, χρησιµοποιώντας τις προγραµµατιστικές διεπαφές των διασυνδεδεµένων υπηρεσιών, καθοδηγεί αυτές, να µεταφράσουν οτιδήποτε χρειάζονται στις κατάλληλες ενέργειες που οι διατάξεις τους θα διεκπεραιώσουν, και να διαµορφώσουν την απαιτούµενη πληροφορία στη συγκεκριµένη διάταξη. Πρέπει να σηµειωθεί ότι όλες οι διεξαγωγές του τύπου αυτού δεν έχουν απαιτήσεις πραγµατικού χρόνου. Σ' αυτή τη κατεύθυνση, οι τεχνολογίες Java ή Java/Jini χρησιµοποιήθηκαν ως πλατφόρµα υποστήριξης ενός τέτοιου εργαλείου, επιτρέποντας τη λογική περιγραφή

22 ΑΡΤΙΟ Τελική έκθεση των δοµών και των διατάξεων πεδίου στο επίπεδο του εικονικού δικτύου (virtual fieldbus). υο είναι εκ πρώτης όψεως τα επίπεδα στα οποία η τεχνολογία Jini µπορεί να αξιοποιηθεί: σε επίπεδο συσκευής (device) σε επίπεδο δικτύου πεδίου. Στην πρώτη περίπτωση κάθε συσκευή θεωρείται αρκετά έξυπνη καθώς έχει δοµηθεί µε τρόπο που να µπορεί να συµµετέχει σε µια κοινότητα Jini υποστηρίζοντας τις απαραίτητες υπηρεσίες. Σύµφωνα µε το σενάριο αυτό κάθε συσκευή µπορεί να υποστηρίξει αυτόµατα την διαδικασία ένταξης της στο δίκτυο πεδίου το οποίο θα έχει δοµηθεί σαν µια κοινότητα Jini. Το µειονέκτηµα της επιλογής αυτής είναι το αυξηµένο κόστος που προκύπτει για κάθε κόµβο του δικτύου. Στην δεύτερη περίπτωση θεωρούµε τη λειτουργικότητα Jini σε επίπεδο virtual fieldbus. Κάθε VF έχει την ικανότητα να ενταχθεί σε µια κοινότητα Jini όπως θα θεωρείται το σύνολο των VFs. Σαν πλεονέκτηµα της επιλογής αυτή µπορεί να θεωρηθεί το µικρό κόστος εγκατάστασης καθώς η υποδοµή του ΑΡΤΙΟgateway είναι αρκετή για να καλύψει τις απαιτήσεις της λειτουργικότητας Jini. Ένας συνδυασµός των δύο παραπάνω προσεγγίσεων µπορεί να οδηγήσει σε µια ευέλικτη και οικονοµική λύση. Είναι προφανές ότι η αξιοποίηση της Jini τεχνολογίας βελτιώνει σε µεγάλο βαθµό την ευελιξία και τις δυνατότητες του εργαλείου µηχανικού. Σύµφωνα µε µια τέτοια προσέγγιση, κάθε διάταξη (κόµβος) κάνει γνωστές τις υπηρεσίες της στο σύστηµα µέσω ενός αντιπροσώπου (proxy) ο οποίος βρίσκεται στη µονάδα διασύνδεσης του δικτύου πεδίου µε το δίκτυο της επιχείρησης ενώ το εργαλείο µηχανικού παρουσιάζει µε ενοποιηµένο και µε γραφικό τρόπο, στο µηχανικό ελέγχου, όλες τις διαθέσιµες υπηρεσίες, οι οποίες αναπαριστούν τις διατάξεις και λειτουργίες πεδίου. Με το τρόπο αυτό, η γνώση που αφορά στη συγκεκριµένη διάταξη ενσωµατώνεται µέσα στην ίδια τη διάταξη, παρέχοντας έτσι τη δυνατότητα σ' ένα υφιστάµενο σύστηµα ελέγχου ιδιοκτησιακού τύπου να διασυνδεθεί σε µια ολοκληρωµένη βιοµηχανική δικτυακή δοµή µε τη µικρότερη δυνατή προσπάθεια. 4.3 Τεχνικές Προδιαγραφές Στα πλαίσια του έργου υλοποιήθηκαν διατάξεις διασύνδεσης µε Profibus και Lonworks δίκτυα, τα οποία είναι δυνατό να ελεγχθούν πλήρως από το γενερικό εργαλείο µηχανικού, µέσω του επιπέδου του «εικονικού δικτύου πεδίου» (virtual fieldbus). Συγκεκριµένα, ο χρήστης-µηχανικός του εν λόγω εργαλείου είναι σε θέση να περιγράψει και να θέσει σε λειτουργία ένα βρόχο ελέγχου που θα περιλαµβάνει σηµεία εισόδου και εξόδου σε συσκευές συνδεδεµένες στα δύο προαναφερθέντα δίκτυα πεδίου, τα οποία συνδέονται µεταξύ τους µέσω δικτύου FastEthernet που παρέχει εγγύηση απόκρισης πραγµατικού χρόνου ιεπαφές ικτύων Η κάθε µονάδα διασύνδεσης παρέχει, από την πλευρά των τοπικών δικτύων, δύο διεπαφές. Η πρώτη είναι µια 10BaseT (Ethernet) διεπαφή µέσω της οποίας συνδέεται στο συµβατικό τοπικό δίκτυο της επιχείρησης και η δεύτερη µια αφιερωµένη Fast Ethernet διεπαφή, µέσω της οποίας επιτυγχάνεται η διασύνδεση σε πραγµατικό χρόνο των δικτύων πεδίου µεταξύ τους. Σε ότι αφορά τη Fast Ethernet διεπαφή, οι απαιτήσεις πραγµατικού χρόνου µπορούν να ικανοποιηθούν µιας και το συγκεκριµένο δίκτυο είναι αφιερωµένο και µε γνωστά χαρακτηριστικά κίνησης για

23 ΑΡΤΙΟ Τελική έκθεση 3 κάθε εφαρµογή (αυτά των δικτύων πεδίου) καθώς και µε εύρος πεδίου έως και 100 φορές µεγαλύτερο από το σύνηθες των δικτύων πεδίου (1 1.5 Mbps). Η επιλογή του θεωρείται βέλτιστη σε ότι αφορά το λόγο κόστους / απόδοσης, η ανάπτυξη όµως του συστήµατος στο σύνολό του δεν βασίστηκε στη συγκεκριµένη τεχνολογία, αλλά έγινε κατά τρόπον ώστε πιο εξελιγµένες και ακριβότερες τεχνολογίες (π.χ. ATM ή xdsl) να µπορούν να το υποστηρίξουν ιεπαφή ικτύου PROFIBUS Κατά τη φάση αυτή έγινε: Μελέτη του protocol stack και του Profibus API, υπηρεσίες, πηγαίος κώδικας, porting σε RT Linux Μελέτη της κάρτας, υνατότητα πρόσβασης στην dual port RAM ΑΡΤΙΟ Gateway Mode λειτουργίας Master Slave, αξιολόγηση, επιλογή. Αναπαράσταση της διακινούµενης RT πληροφορίας, τύποι, κ.λ.π. Εφαρµογή των παραπάνω στη διασύνδεση δύο δικτύων profibus διαµέσου RT Linux. Ethernet - RT Linux. Σαν τοπολογία χρησιµοποιούνται δύο κάρτες profibus µε Master functionality σε δύο PC µε RT Linux. Τα PC επικοινωνούν µέσω TCP/IP. Ανάπτυξη εφαρµογής σε C που αποκαθιστά την επικοινωνία µεταξύ δύο συσκευών δικτύου profibus που βρίσκονται σε διαφορετικά δίκτυα πεδίου. Εξετάστηκαν όλες οι δυνατές επιλογές (DP, DPV1, FMS, ) όπως polling και interrupt τεχνική. Ταυτόχρονα έγινε porting σε RT Linux ATM - RT Linux ή RT Linux - RT Linux. Η διαδικασία αυτή κρίθηκε απαραίτητη γιατί η πλατφόρµα του RT-Linux το απαιτούσε. Πρέπει να σηµειωθεί ότι αυτό δεν περιορίζει τη γενικότητα καθότι είναι εύκολη η µετάβαση σε Java και στη συνέχεια σε RT Java. To πρότυπο του βιοµηχανικού δικτύου PROFIBUS ορίζει τρεις διαφορετικές εκδοχές του πρωτοκόλλου: PROFIBUS DP: Χρησιµοποιείται για εφαρµογές πραγµατικού χρόνου, παρέχοντας υψηλές ταχύτητες ανταλλαγής µηνυµάτων, είτε µέσω σύγχρονης (DP) είτε µέσω ασύγχρονης (DPV1) κίνησης. Αποτελεί την ευρύτερα διαδεδοµένη σε αριθµό εγκαταστάσεων εκδοχή του δικτύου. PROFIBUS FMS: Βασίζεται στο MMS πρότυπο και χρησιµοποιείται για γενικού σκοπού επικοινωνίες, κυρίως ανάµεσα σε πιο σύνθετες συσκευές (high-end PLCs), λόγω της πολυπλοκότητάς του. PROFIBUS PA: Στηρίζεται στις επικοινωνιακές υπηρεσίες του DP/DPV1, ορίζοντας εναλλακτικό φυσικό επίπεδο για εφαρµογές που απαιτούν αντιεκρηκτική προστασία. Ορίζει επίσης ένα σύνολο από ιδιότητες (profile) βασικών συσκευών στις εφαρµογές ελέγχου διεργασιών (Process Control) κατ αντιστοιχία µε το πρότυπο του επιπέδου χρήστη (user layer) που περιγράφηκε στην παράγραφο..1.(function Blocks Device Descriptions). Από τα παραπάνω προκύπτει ότι για την ανάδειξη των δύο ερευνητικών διαστάσεων του έργου πραγµατικός χρόνος / διαλειτουργικότητα - η µονάδα διασύνδεσης πρέπει να υποστηρίζει το PROFIBUS DP, ενώ, σε ότι αφορά την ανάπτυξη του επιπέδου «εικονικού δικτύου πεδίου» (virtual fieldbus), πρέπει να ληφθεί υπ όψη η αρχιτεκτονική και τα οριζόµενα στο PA Profile όπου αυτό είναι δυνατόν.

24 ΑΡΤΙΟ Τελική έκθεση 4 Συγκεκριµένα, το DP αποτελεί µια επικοινωνιακή υποδοµή, η οποία παρέχει στην οντότητα εφαρµογής ένα αριθµό από υπηρεσίες (services) µέσω µιας προγραµµατιστικής διεπαφής (Application Programming Interface). Οι υπηρεσίες αυτές είναι είτε υπηρεσίες µεταφοράς δεδοµένων είτε υπηρεσίες σύνθεσης του δικτύου (configuration). Οι επικοινωνιακές υπηρεσίες είναι αυτές στις οποίες στηρίζονται τα ανώτερα επίπεδα της µονάδας διασύνδεσης (ΑΡΤΙΟ Profibus gateway) τα οποία υλοποιούν τη λειτουργικότητα της IP δροµολόγησης σε πραγµατικό χρόνο (real-time dispatchers). Αντίθετα, οι υπηρεσίες σύνθεσης παράλληλα ίσως και µε τις επικοινωνιακές χρησιµοποιούνται από τα επίπεδα που διαπραγµατεύονται τη διαλειτουργικότητα, δηλαδή τους αντιπροσώπους των συσκευών ή των λειτουργικών οντοτήτων (field device proxies) και του εικονικού δικτύου πεδίου. Σε ότι αφορά το εικονικό δίκτυο πεδίου (virtual fieldbus), όπως έχει ήδη αναφερθεί, η λειτουργικότητα των διαφόρων µονάδων ανάγεται στο σχεδιασµό κατάλληλων Java αντικειµένων ή Jini υπηρεσιών που κρύβουν από την εφαρµογή τις λεπτοµέρειες και τις ιδιαιτερότητες του Profibus προτύπου. Ο σχεδιασµός των κλάσεων των αντικειµένων αυτών εκµεταλλεύεται την αντικειµενοστραφή περιγραφή της λειτουργικότητάς τους, όπως αυτή καθορίζεται στα Physical, Transducer & Function Blocks του PA Profile, σε συνάρτηση µε τις αντίστοιχες περιγραφές αντικειµένων του LNS του δικτύου Lonworks ιεπαφή ικτύου Lonworks Το ίκτυο Ελέγχου ( Ε) Lonworks είναι ένα δίκτυο για την σύγχρονη και ενοποιηµένη δικτύωση όλων των υποσυστηµάτων αυτοµατισµού τόσο στην βιοµηχανία όσο και στον έλεγχο αυτοµατισµών σε κτιριακό επίπεδο. Με αυτά τα δίκτυα κάθε προϊόν όπως π.χ. διακόπτης, φωτιστικό, µηχανή - µοτέρ, ηλεκτροβαλβίδα, θερµοστάτης, ροόµετρο, ελεγκτής διεργασιών, αισθητήρας, ηλεκτρική κλειδαριά, ηλεκτρικός µετρητής ενέργειας, κλπ. γίνεται ένας κόµβος δικτύου και η αυτοµατοποίηση υλοποιείται ολοκληρωµένα και ενοποιηµένα. Κόµβοι σ ένα δίκτυο ελέγχου είναι τα αισθητήρια (sensors), οι ενεργοποιητές (actuators), οι ελεγκτές (controllers), τα χειριστήρια ελέγχου / απεικόνισης (interface panels), τα πληκτρολόγια (keypads), οι οθόνες (displays) και οι Η/Υ µε το συνοδευτικό λογισµικό, όπως ακριβώς οι Η/Υ οι δροµολογητές / διακόπτες και οι συγκεντρωτές αποτελούν τους κόµβους ενός δικτύου δεδοµένων. Τα δίκτυα ελέγχου κάνουν την ολοκλήρωση ετερογενών συστηµάτων αυτοµατισµού πραγµατικότητα µέσω της διαλειτουργικότητας που προσφέρουν η οποία στηρίζεται σε ειδικά πρωτόκολλα επικοινωνίας. Επίσης ανεβάζουν σε υψηλό επίπεδο την αξιοπιστία του συνολικού συστήµατος ελέγχου µέσω µίας πραγµατικά ανοιχτής κατανεµηµένης αρχιτεκτονικής σε αντίθεση µε τα κεντρικοποιηµένα συστήµατα ελέγχου τα οποία υποφέρουν από το πρόβληµα της κατάρρευσης λόγω βλάβης στο κεντρικό σύστηµα (single point of failure) Κατανεµηµένη αρχιτεκτονική Κάθε κόµβος (σηµείο ελέγχου) του Lonworks πρέπει να διαθέτει την απαραίτητη επεξεργαστική ισχύ για να εκτελεί τους δικούς του αλγορίθµους ελέγχου αυτόνοµα και να επικοινωνεί (peer-to-peer) µε τους υπόλοιπους κόµβους του δικτύου χωρίς την ανάγκη ενός κεντρικού κόµβου (master) ή Η/Υ.

25 ΑΡΤΙΟ Τελική έκθεση Τοπολογία Το Lonworks µπορεί να υποστηρίζει ευέλικτες τοπολογίες ώστε να παρέχεται η δυνατότητα της βέλτιστης συνδεσµολογίας που απαιτεί κάθε επιµέρους εφαρµογή. Θα πρέπει να επιτρέπεται η καλωδίωση των κόµβων του Ε χωρίς ουσιαστικά κανέναν τοπολογικό περιορισµό. Αυτό σηµαίνει ότι το Ε θα πρέπει να χρησιµοποιεί µία τεχνική ελεύθερης τοπολογίας (free topology) που θα υποστηρίζει συνδεσµολογία όλων των παρακάτω τύπων: αστέρα (star) κυκλική (loop) διαύλου (bus) ώστε να επιλέγεται η βέλτιστη µέθοδος καλωδίωσης που ταιριάζει στην κάθε εγκατάσταση, µειώνοντας την ανάγκη για εκ των προτέρων σχεδιασµό όλων των πιθανών µελλοντικών εφαρµογών και επιτρέποντας αλλαγές που µπορεί να προκύψουν την τελευταία στιγµή στο χώρο εγκατάστασης. Επίσης, µια ελεύθερης συνδεσµολογίας τοπολογία επιτρέπει τη µελλοντική επέκταση του Ε µε µια απλή σύνδεση του νέου ή νέων κόµβων στην υπάρχουσα καλωδίωση στο σηµείο που είναι βολικότερο, ασχέτως µε το υποσύστηµα στο οποίο ανήκουν Μέσα µετάδοσης (φυσικό επίπεδο) Στο Lonworks επιτρέπεται η σύνδεση των κόµβων µέσω πολλαπλών µέσων µετάδοσης (συνεστραµµένο ζεύγος - ΤΡ, οµοαξονικό - coaxial, γραµµές ισχύος - power line, ασύρµατη ζεύξη - RF/IR, οπτική ίνα - fibber optic) στο ίδιο δίκτυο παρέχοντας ευελιξία στην επιλογή του βέλτιστου τρόπου διασύνδεσης των επιµέρους συστηµάτων ελέγχου σε ένα κοινό δίκτυο Ενεργός εξοπλισµός Το Lonworks υποστηρίζει ενεργές δικτυακές συσκευές που επιτρέπουν την πρακτικά απεριόριστη επέκταση του αριθµού των κόµβων ελέγχου, εξασφαλίζοντας την µεταξύ τους διαφανή επικοινωνία. Συνεπώς υποστηρίζονται οι εξής συσκευές: επαναλήπτες (repeaters) για την αύξηση του µήκους του Ε και του αριθµού των υποστηριζόµενων κόµβων δροµολογητές (routers) για την διασύνδεση διαφορετικών µέσων µετάδοσης και / η διαφορετικών πρωτοκόλλων (π.χ TCP/IP) πύλες (gateways) για τη διασύνδεση µε ετερογενή δίκτυα (π.χ. PSTN) PC Interfaces για διασύνδεση µε Η/Υ ιαλειτουργικότητα συστηµάτων ελέγχου Το δίκτυο Lonworks παρέχει τη δυνατότητα ολοκλήρωσης και διαλειτουργικότητας όλων των συστηµάτων ελέγχου σε ένα δίκτυο. Με την τεχνολογία ενός OPC Server η πληροφορία που υπάρχει σε ένα δίκτυο Lonworks µπορεί να διοχετευτεί σε ένα υπολογιστή σε µία στάνταρ µορφή όπου από εκεί σύµφωνα µε το τι επιθυµεί ο χρήστης µπορεί να την εκµεταλλευτή ανάλογα. Πρωτόκολλο επικοινωνίας πραγµατικού χρόνου. Το δίκτυο υποστηρίζει ένα πρωτόκολλο επικοινωνίας πραγµατικού χρόνου (real-time) που εξασφαλίζει την απόκριση κρίσιµων εφαρµογών σε πραγµατικό χρόνο. Αποδεδειγµένη αξία της προτεινόµενης τεχνολογίας σε υπάρχουσες εγκαταστάσεις ανά τον κόσµο. Τα προτεινόµενα συστήµατα θα πρέπει να έχουν εγκατασταθεί και να λειτουργούν επιτυχώς σε παρόµοια έργα ανά τον κόσµο.

26 ΑΡΤΙΟ Τελική έκθεση 6 υνατότητα αλλαγής του κώδικα εφαρµογής στον κάθε κόµβο-σταθµό µέσω δικτύου (node application download through network). Οι κόµβοι του κάθε υποσυστήµατος θα πρέπει να δέχονται αλλαγή του προγράµµατος εφαρµογής τους µέσω του δικτύου ώστε να παρέχεται η εύκολη αναβάθµιση των λειτουργιών τους ιευθυνσιοδότηση ικτύου Κάθε κόµβος εµπεριέχει ένα Neuron Chip το οποίο έχει ένα µοναδικό Neuron ID. O αριθµός αυτός αποτελείται από 48-bit και είναι χαρακτηριστικό του κόµβου στον οποίο βρίσκεται για όλη την διάρκεια ζωής του. Η διεύθυνση είναι και αυτό ένα µοναδικό χαρακτηριστικό του κάθε κόµβου και αποτελείται από ορισµένα πεδία σύµφωνα µε τον τρόπο διευθυνσιοδότησης που ακολουθούν τα πακέτα. Ορισµένες φορές το Neuron ΙD µπορεί να χρησιµοποιηθεί και σαν χαρακτηριστικό κόµβου για την αποστολή ενός πακέτου. Από ποια πεδία αποτελείται η διεύθυνση ενός κόµβου φαίνεται παρακάτω: Χρήση του Domain ID. Το Domain αποτελεί µια λογική συνάθροιση κόµβων σε ένα ή περισσότερα κανάλια. Πολλά Domain µπορούν επίσης να βρίσκονται σε ένα Domain. Χρήση του Subnet ID. To Subnet είναι µία συλλογή από κόµβους µέσα σε ένα Domain, οι οποίοι όµως δεν πρέπει να ξεπερνούν τους 17. Μέσα σε ένα Domain µπορούν να δηµιουργηθούν το πολύ 55 subnets. Η χρήση του Node Number ID. Κάθε κόµβος µέσα στο Subnet στο οποίο βρίσκεται έχει και ένα node number. Ένα subnet δεν έχει παραπάνω από 17 κόµβους. Η έννοια του Group. Ένας κόµβος µπορεί να ανήκει σε µία οµάδα κόµβων. Η συγκεκριµένη οµαδοποίηση χρησιµοποιείται όταν θέλουµε την επικοινωνία ενός κόµβου προς πολλούς. Έτσι λοιπόν ο βασικός τρόπος απόδοσης διεύθυνσης σε ένα Lonworks δίκτυο είναι: Domain, Subnet και node ID. Σε κάθε κόµβο λοιπόν αποδίδεται ένας µοναδικός αριθµός µέσα στο Subnet, ο οποίος είναι ένας αριθµός των 7 bit. Ο µέγιστος αριθµός των κόµβων σε ένα Domain είναι (55 Subnets * 17 κόµβοι ανά Subnet) ιαχείριση ικτύου Σε ένα δίκτυο Lonworks, πάντα υπάρχει ένας κόµβος, ο οποίος µπορεί δεν είναι απαραίτητα µόνιµος (µπορεί να είναι ένα PC που συνδέεται περιστασιακά στο δίκτυο) που φροντίζει για το managing του δικτύου. Αυτό σηµαίνει ότι πρέπει να γνωστοποιήσει στους κόµβους το ποιος κόµβος µιλάει µε ποιόν και από ποίους κάποιοι δέχονται ή στέλνουν µηνύµατα. Αυτό µπορεί γίνεται κατά την αρχικοποίηση του δικτύου, και αποκεί και πέρα το δίκτυο µπορεί να λειτουργήσει χωρίς τον Network Manager. Οι υπηρεσίες που προσφέρονται στο δίκτυο Lonworks και οι οποίες µπορούν να ζητηθούν από ένα Network Manager είναι οι ακόλουθες: Address Assignment: απόδοση ιευθύνσεων στους κόµβους του δικτύου. Node Query: Η ανάκτηση της κατάστασης των κόµβων και άλλων ζωτικών παραµέτρων. Router Maintenance: Ρύθµιση και αποκατάσταση των Routers του δικτύου.

27 ΑΡΤΙΟ Τελική έκθεση 7 Node States Applicationless: Κατάσταση κατά την οποία δεν έχει φορτωθεί κάποιος κώδικας εφαρµογής στον κόµβο. Unconfigured: Κατάσταση κατά την οποία ο κώδικας έχει φορτωθεί στον κόµβο αλλά λόγω κάποιας ρυθµίσεις ο κόµβος έχει βγει εκτός κανονικής λειτουργίας. Hard-Offline: κατάσταση κατά την οποία ενώ ο κόµβος έχει φορτωµένο κάποιο πρόγραµµα βρίσκεται εκτός λειτουργίας. Configured: Η κανονική κατάσταση λειτουργίας του κόµβου. Σε αυτή την κατάσταση ο κόµβος µπορεί να είναι εκτός και εντός λειτουργίας (offline / online) σύµφωνα µε µηνύµατα που θα λάβει από το network manager Περιγραφή Υπηρεσιών Query ID () Η εντολή αυτή ζητάει από κάποιον ους κόµβο ους, την αποστολή του Neuron_ID Respond to Query () Η συγκεκριµένη εντολή θέτει ή µηδενίζει το respond to Query bit του κόµβου στον οποίο απευθύνεται. Update Domain () Η συγκεκριµένη υπηρεσία είναι για την αλλαγή των εισαγωγών σε επίπεδο Domain σε ένα κόµβο. Leave Domain () Λαµβάνοντας αυτή την εντολή ένας κόµβος οφείλεί να εγκαταλείψει το Domain στο οποίο ανήκει, ακόµα και στην περίπτωση που έχει διευθύνσεις που τον τοποθετούν µέσα σ αυτό. Update Key () χρησιµοποιείται για την αλλαγή των κωδικών κρυπτογράφησης µηνυµάτων. Update Address () Αλλαγές διευθύνσεων στον πίνακα εισαγωγών διευθύνσεων του κάθε κόµβου. Query Address () Η εντολή αυτή επιστρέφει την διεύθυνση της θέσης του πίνακα στην οποία δείχνει η εντολή. Query Network Variable Configuration () Με την εντολή αυτή γίνεται η αναζήτηση των ρυθµίσεων που έχουν γίνει για

28 ΑΡΤΙΟ Τελική έκθεση 8 κάποια µεταβλητή( π.χ. είναι µεταβλητή εξόδου, εισόδου τύπος κτλ.) Update group address () Αυτή η εντολή χρησιµοποιείται για την ανανέωση µιας εισαγωγής τύπου Group. Συνήθως αποστέλλεται σε όλο το Group των κόµβων. Query Domain () Η εντολή αυτή χρησιµοποιείται για την ανάκτηση µίας εκ των δύο καταχωρήσεων σχετικά µε τα Domain που ανήκει ο κόµβος (ο κάθε κόµβος µπορεί να ανήκει το πολύ σε δύο Domain). Update Network Variable Configuration () Με την εντολή αυτή ο κόµβος που την λαµβάνει κάνει αλλαγές στον πίνακα όπου κρατούνται οι ρυθµίσεις οι σχετικές µε τις µεταβλητές δικτύου (SNVTs σύµφωνα και µε τα προηγούµενα παραδοτέα). Read Memory () Χρησιµοποιείται για την ανάγνωση της µνήµης. Σε περίπτωση που υπάρχει προστασία ανάγνωσης στον κόµβο τότε συγκεκριµένες περιοχές µνήµης εκ των οποίων µία είναι και η περιοχή των µεταβλητών. Write Memory () Η εντολή αυτή χρησιµοποιείται για εγγραφή στην µνήµη ενός κόµβου και υπάρχει σε δύο εκδόσεις. Στην µία έκδοση ένα reset του κόµβου προκαλείται µετά την εγγραφή ενώ στην άλλη δίνεται απλά µία βεβαίωση σωστής εγγραφής. Checksum Recalculation () Install () Αυτή η εντολή εξαναγκάζει το Neuron_Chip να υπολογίζει και να διατηρεί µια καταµέτρηση κάθε ρύθµισης και κάθε εφαρµογής. Πρέπει να χρησιµοποιείται µετά το τέλος εντολών τύπου Network Management. Εντολή που χρησιµοποιείται κατά την διαρκεί της εισαγωγής του κόµβου στο δίκτυο για διάφορους σκοπούς. Memory Refresh () Αυτή η εντολή δίνεται σε ένα κόµβο και σκοπό έχει την αντιγραφή της µνήµης σε ένα άλλο σηµείο και µετά επανεγγραφεί στο ίδιο µε σκοπό την ανανέωση των εγγραφών. Σκοπός της όλης διαδικασίας να συγκρατηθεί η εγγραφή για µεγαλύτερο χρονικό διάστηµα. Query standard Network Variable Type () Με την εντολή αυτή γίνεται η ανάκτηση της τιµής µιας µεταβλητής δικτύου από

29 ΑΡΤΙΟ Τελική έκθεση 9 τον κόµβο στον οποίο παράγεται η τιµή της. Network Variable Value fetch () εντολή που χρησιµοποιείται από κάποιο κόµβο για να ζητήσει την τιµή µίας µεταβλητής από τον κόµβο που την παράγει. Service Pin Message: Αποτελεί ένα µήνυµα που στέλνεται από κάποιον κόµβο όταν πιεστεί το Service pin. Το µήνυµα απευθύνεται σε όλους τους κόµβους και δηλώνει το Neuron Id και την διεύθυνση του κόµβου που το στέλνει µέσα στο δίκτυο. Service Pin Message Αποτελεί ένα µήνυµα που στέλνεται από κάποιον κόµβο όταν πιεστεί το Service pin. Το µήνυµα απευθύνεται σε όλους τους κόµβους και δηλώνει το Neuron Id και την διεύθυνση του κόµβου που το στέλνει µέσα στο δίκτυο Easylon Card, PCI Bus Interface - Τοπολογίες του συστήµατος που χρησιµοποιήθηκαν Η κάρτα η οποία επιλέχτηκε για την υλοποίηση η PC 104 (PCI bus interface) της GESYTEC, συνοδεύεται από οδηγούς για το LINUX Red Hat 6.1 (Kernel version..1). Η χρήση της κάρτας της Easylon αποτέλεσε µία αναγκαστική επιλογή καθώς ήταν η µόνη κάρτα την στιγµή της αναζήτησης που πρόσφερε οδηγούς για Linux. Στην υλοποίηση των απαιτήσεων του ΑΡΤΙΟ υλοποιήθηκαν δύο αρχιτεκτονικές. Στην µία η οποία αποτέλεσε και την πιο απλή ένας κόµβος τύπου Ι/Ο συνδέθηκε µε την κάρτα της Easylon µε σκοπό την ανταλλαγή µηνυµάτων µεταβλητών που αντιστοιχούσαν στις εισόδους /εξόδους της κάρτας και εµφάνιση των αποτελεσµάτων στον υπολογιστή που φιλοξενεί την κάρτα. Στην δεύτερη αρχιτεκτονική δύο τερµατικά συνδέθηκαν µέσω διαδικτύου. Το κάθε τερµατικό φιλοξενεί από µια κάρτα της Easylon οι οποίες συνδέονται µε έναν κόµβο I/O. Στόχος της διασύνδεση ήταν η σωστή εκποµπή και λήψη µηνυµάτων από το ένα δίκτυο στο άλλο σε πλαίσια πραγµατικού χρόνου. Στην υλοποίηση των παραπάνω δικτύων παρουσιάστηκαν αρκετά σχεδιαστικά προβλήµατα καθώς οι οδηγοί που συνόδευαν τις κάρτες ήταν πολύ γενικοί Easylon driver Η Easylon προσφέρει έναν οδηγό γενικής χρήσης µε την βοήθεια του οποίου γίνεται η αρχικοποίηση της κάρτας και προσφέρονται οι ρουτίνες εγγραφής και ανάγνωσης από αυτή. Τέλος δίνεται η ρουτίνα κλεισίµατος της κάρτας όταν τελειώνει κάποιο application. Συµπληρωµατικά στον Driver έρχονται κάποιες ρουτίνες, εκ των οποίων οι περισσότερες ηµιτελείς, οι οποίες µπορούν να χρησιµοποιηθούν σαν οδηγός για την κατασκευή ενός ολοκληρωµένου application που θα υλοποιεί όλη την απαιτούµενη από το ΑΡΤΙΟ λειτουργία. Σε αυτές τις ρουτίνες προστέθηκαν καινούριες για να υποστηρίξουν τις µεταβλητές που ανταλλάσσονται µεταξύ των κόµβων, παρέχοντας

30 ΑΡΤΙΟ Τελική έκθεση 30 υπηρεσίες τύπου αναζήτησης-ανάκτησης τιµής, εγγραφής µεταβλητής στην εφαρµογή και γενικότερα ρουτίνες που υλοποιούν διαδικασίες διαχείρισης του δικτύου. Οι ρουτίνες που προαναφέρθηκαν παρουσιάζονται αναλυτικά παρακάτω Προσφερόµενες Υπηρεσίες από την κάρτα Init_local_node () Με την χρήση των υπηρεσιών αυτής της ρουτίνας αρχικοποιείται η κάρτα. Κατά την αρχικοποίηση η κάρτα καλείται να αποστείλει ένα µήνυµα στο δίκτυο όπου δηλώνει την αρχικοποίηση της και ότι είναι σε κατάσταση normal και online. Receive_packets () Με την ρουτίνα αυτή το πρόγραµµα που τρέχει στον υπολογιστή που φιλοξενεί την κάρτα, κάνει polling την κάρτα και όταν η κάρτα δώσει µήνυµα ότι είναι έτοιµη να διαβαστεί τότε διαβάζεται ο buffer της κάρτας που φιλοξενεί το τυχόν παραληφθέν µήνυµα. Στη περίπτωση που δεν έχει ληφθεί κάποιο µήνυµα τότε ο έλεγχος γυρνάει πάλι στο αρχικό πρόγραµµα µετά το κάλεσµα της ρουτίνας. Handle_incoming () Στην ρουτίνα αυτή µπαίνει το πρόγραµµα όταν ένα µήνυµα παραλειφθεί από την κάρτα. Η ρουτίνα αυτή συµπληρώθηκε µε σκοπό να εξυπηρέτηση την λειτουργικότητα που απαιτείται καθώς από τον κατασκευαστή είναι εντελώς κενή. Κατά την διάρκεια της ρουτίνας διαβάζεται το «code» του µηνύµατος και ανάλογα µε το περιεχόµενο του το πρόγραµµα αντιλαµβάνεται το είδος της υπηρεσίας που απαιτείται και καλεί την ανάλογη ρουτίνα εξυπηρέτησης. Dumpmsg () Ρουτίνα η οποία διαβάζει και φανερώνει το µήνυµα που έχει διαβαστεί, από τον buffer της κάρτας, στην οθόνη του συστήµατος. Χρησιµοποιείται τόσο όταν το µήνυµα είναι ένα εισερχόµενο ή ένα εξερχόµενο µήνυµα. Do_response () Γράφει µήνυµα απάντησης σε εισερχόµενη εντολή ανάκτησης. Για την δηµιουργία ενός τέτοιου µηνύµατος το µόνο που χρειάζεται είναι η αλλαγή του τµήµατος της πληροφορίας του µηνύµατος καθώς όλα τα υπόλοιπα πεδία παραµένουν όµοια. Send_msg () Στέλνει οποιοδήποτε µήνυµα υπάρχει προς αποστολή. Send_local () Ίδια λειτουργία µε την προηγούµενη, µε την διαφορά ότι χρησιµοποιείται για αποστολή µηνύµατος στον ίδιο τον κόµβο. Οι παραπάνω ρουτίνες όπως είναι φανερό δεν είναι αρκετές για να διασφαλίσουν την απαραίτητη λειτουργικότητα για την εφαρµογή του ΑΡΤΙΟ. Προστέθηκαν λοιπόν, οι παρακάτω ρουτίνες. Ρουτίνες που υποστηρίζουν τις διαδικασίες που αφορούν τις µεταβλητές δικτύου. Load_NV_config ()

31 ΑΡΤΙΟ Τελική έκθεση 31 Ρουτίνα η οποία εξυπηρετεί την εισαγωγή των µεταβλητών κατά την αρχικοποίηση της κάρτας. Κατά την εισαγωγή δίνονται πληροφορίες σχετικά µε τις µεταβλητές (εισόδου, εξόδου κτλ.) σε µορφή πίνακα (ΝV table). Handle_update_nv_config () Καλείται όταν ο διαχειριστής του δικτύου καλείται να ενώσει µία µεταβλητή ενός κόµβου µε µία µεταβλητή ενός άλλου. ιαβάζει την πληροφορία από το µήνυµα που καταφτάνει και εν συνεχεία ενηµερώνει των πίνακα µεταβλητών (ΝV table). Handle_query_nv_config () Ρουτίνα η οποία εξυπηρετεί ένα διαχειριστή δικτύου όταν αυτός ζητάει πληροφορίες σχετικά µε την σύνδεση µίας µεταβλητής. ιαβάζει ποια µεταβλητή του ζητείται από το µήνυµα, παίρνει τις πληροφορίες από τον πίνακα των µεταβλητών και ενηµερώνει το µήνυµα της απόκρισης. Handle_query_SNVT () Ρουτίνα που στέλνει σχετικές πληροφορίες µε την µεταβλητή για την οποία δέχεται ερώτηση από τον διαχειριστή συστήµατος. Handle_nv_fetch () Καλείται όταν ο διαχειριστής συστήµατος επιθυµεί να ανανεώσει την τιµή µίας µεταβλητής. Ο κόµβος ο οποίος δέχεται το µήνυµα είναι αναγκασµένος να διαβάσει την µεταβλητή που του ζητείται από το µήνυµα, να ανανεώσει την τιµή της και να την µετάδοση στο δίκτυο. Handle_netvar_message () Η ρουτίνα καλείται όταν ένας κόµβος λάβει µήνυµα το οποίο περιέχει την ανανεωµένη τιµή µιας µεταβλητής. NV_update () Η συγκεκριµένη ρουτίνα χρησιµοποιείτε για την ανανέωση κάποιας µεταβλητής από τον χρήστη ή από τιµή η οποία λαµβάνεται µέσω του διαδικτύου και η τιµή της αποστέλλεται στο δίκτυο Lonworks. NV_poll() Ρουτίνα που δίνει στον χρήστη την δυνατότητα να ζητήσει από κάποιο κόµβο την τιµή µίας µεταβλητής. Οι τελευταίες δύο ρουτίνες όπως γίνεται κατανοητό είναι και οι πιο χρήσιµες για την εφαρµογή καθώς δίνουν την δυνατότητα στις κάρτες που επικοινωνούν µέσω του διαδικτύου να περνάν τις εντολές της µίας από την άλλη στα δίκτυα που υποστηρίζουν. 4.4 Ανάλυση των επικρατέστερων Αντικειµενοστρεφών Τεχνολογιών Λογισµικού Στα πλαίσια της 1ης φάσης µελετήθηκαν ορισµένες προηγµένες τεχνολογίες λογισµικού για να διαπιστωθεί κατά πόσο µπορούν να χρησιµοποιηθούν στα πλαίσια του έργου. Καθώς η αντικειµενοστραφής προσέγγιση έχει γίνει αποδεκτό ότι προσφέρει λύση σε πολλά από τα προβλήµατα της διαδικασίας ανάπτυξης (ανάλυσης, σχεδιασµού και υλοποίησης) συστηµάτων το σύνολο των τεχνολογιών που µελετήθηκαν ανήκουν στην κατηγορία των αντικειµενοστραφών τεχνολογιών.

32 ΑΡΤΙΟ Τελική έκθεση 3 Ξεκινώντας από την γλώσσα προγραµµατισµού διαπιστώθηκε µια συνεχώς αυξανόµενη τάση για εισαγωγή της γλώσσας προγραµµατισµού Java στη βιοµηχανία. Η Java αν και ξεκίνησε σαν γλώσσα για ενσωµατωµένες συσκευές, εξελίχθηκε στην πορεία σε γενικού σκοπού αντικειµενοστραφή γλώσσα µε κύρια έµφαση στον προγραµµατισµό για το Internet. Σαν αντικειµενοστραφής γλώσσα παρουσιάζει πολλά πλεονεκτήµατα σε σχέση µε την C++ αλλά υστερεί σηµαντικά στις επιδόσεις καθώς και στα constructs για χαµηλού επιπέδου προγραµµατισµό. Τα δύο αυτά σηµεία προσωρινά αντιµετωπίστηκαν µε τον µηχανισµό για κλήση native κώδικα που κρίθηκε απαραίτητος για εφαρµογές αυτού του είδους. Παρόλα αυτά η απαίτηση για βελτίωση των χαρακτηριστικών του περιβάλλοντος είχε σαν αποτέλεσµα επεκτάσεις που είναι γνωστές σαν Real-Time Java. Οι προσπάθειες αυτές έχουν ήδη ξεπεράσει το ερευνητικό στάδιο και κρίνεται πως είναι ώριµες για χρήση στα πλαίσια του παρόντος έργου. Η συνεχής τάση για ανάπτυξη κατανεµηµένων αντικειµενοστραφών συστηµάτων ήταν επόµενο να προκαλέσει την εµφάνιση περιβαλλόντων που θα µπορούν να δώσουν την κατάλληλη υποδοµή για την ταχύτερη και πλέον αξιόπιστη ανάπτυξη των συστηµάτων αυτών. Η Αρχιτεκτονική Common Object Request Broker (CORBA) είναι η πρώτη αξιόλογη προσπάθεια προς την κατεύθυνση της διασφάλισης µιας επικοινωνιακής υποδοµής για την συνεργασία ετερογενών συνιστωσών λογισµικού. Η τεχνολογία DCOM που αποτελεί επέκταση της COM τεχνολογίας της Microsoft θεωρείται ανταγωνιστική της CORBA υστερεί όµως ως προς τον βαθµό που προσδιορίζει το ανοικτό του συστήµατος αλλά και τον γενικό σχεδιασµό καθώς δεν υιοθετεί πλήρως την αντικειµενοστραφή προσέγγιση. Παρόλα αυτά η DCOM τεχνολογία αν και σχετικά νεότερη της CORBA κατάφερε προσφέροντας την τεχνολογία OPC να πετύχει µια ευρύτερη αποδοχή στον χώρο της βιοµηχανίας. Προς ανάλογη κατεύθυνση αλλά µε κύριο στόχο την αυτοµατοποίηση των διαδικασιών διαµόρφωσης ενός κατανεµηµένου συστήµατος κινείται η τεχνολογία Jini, η οποία είναι επέκταση του περιβάλλοντος Java. Οι παραπάνω αναφερόµενες τεχνολογίες µελετήθηκαν σε βαθµό που να είναι δυνατή η υιοθέτηση και χρήση τους στα πλαίσια του παρόντος έργου. Στις τεχνολογίες αυτές γίνεται στη συνέχεια µια αναλυτική αναφορά Real-Time Java Οι γλώσσες που προορίζονται για την δηµιουργία λογισµικού για συστήµατα πραγµατικού χρόνου (ΣΠΧ) είναι πολλές. Παρόλα αυτά καµία δεν έχει γνωρίσει την αποδοχή της Java τόσο στον ακαδηµαϊκό όσο και τον εµπορικό τοµέα. Η Ada95 για παράδειγµα, που έχει γνωρίσει µεγάλη αποδοχή στον χώρο των ΣΠΧ λόγω του ότι περιείχε πολλά τεχνολογικά επιτεύγµατα, απέτυχε να επικρατήσει για διάφορους µη τεχνολογικούς λόγους. Κατά την γέννηση της Java δεν φαινόταν κάποια σχέση ή σύνδεσή της µε των χώρο των ΣΠΧ αν και η γλώσσα γεννήθηκε από ένα project που στόχο είχε την ανάπτυξη ενός περιβάλλοντος για ενσωµατωµένες συσκευές. Στοιχεία που πρέπει να υπάρχουν στα ΣΠΧ, όπως thread behavior, synchronization, interrupts, διαχείριση µνήµης και Ι/Ο, δεν είχε προβλεφθεί να υποστηρίζονται καθόλου από την γλώσσα.

33 ΑΡΤΙΟ Τελική έκθεση 33 Επιπλέον η δυνατότητα παραγωγής portable κώδικα αν και προσδίδει σηµαντική επιβάρυνση στις επιδόσεις, φαίνεται ότι µπορεί να µειώσει αρκετά το κόστος ανάπτυξης λογισµικού σε ΣΠΧ, γιατί παρότι στους υπολογιστές γραφείου δεν υπάρχει µεγάλη ποικιλία επεξεργαστών και λειτουργικών συστηµάτων, στον χώρο των ΣΠΧ υπάρχουν δεκάδες διαφορετικοί επεξεργαστές και δεκάδες διαφορετικά λειτουργικά συστήµατα. Έτσι, κατά την δηµιουργία της RT-Java, η µεγαλύτερη πρόκληση ήταν ο συγκερασµός των από την φύση τους αποκλινόντων χαρακτηριστικών της γλώσσας µε αυτά του real-time προγρµµατισµού. Η συµβατότητα µεταξύ του Real-Time Specification for Java (RTSJ), µε το Java Language Specification έπρεπε να διατηρηθεί ενώ ταυτόχρονα έπρεπε το πρώτο να διαµορφωθεί έτσι ώστε να επιτρέπει χαµηλά επίπεδα κόστους για συσκευές πραγµατικού χρόνου. Η διαδικασία που ακολουθήθηκε διασφαλίζει σε µεγάλο βαθµό την ποιότητα του αποτελέσµατος. Σε µια πρώτη φάση καθορίστηκαν οι απαιτήσεις από ένα περιβάλλον για ανάπτυξη συστηµάτων πραγµατικού χρόνου αλλά και καταβλήθηκε προσπάθεια να αποκτηθεί η συναίνεση της πλειοψηφίας των συµµετεχόντων στην ανάπτυξη ΣΠΧ. Σε µια δεύτερη φάση δόθηκε έµφαση στο να συµφωνηθεί ένα κοινό λεξικό όρων πραγµατικού χρόνου για το RTSJ, και αυτό γιατί µέχρι τώρα στον χώρο των ΣΠΧ δεν υπάρχει ένας καθορισµένος τρόπος επικοινωνίας. Οι βασικές αρχές που οριοθέτησαν τους στόχους της οµάδας Real-Time for Java Expert Group (RTJEG) και έθεσαν τα πλαίσια ανάπτυξης του RTJS είναι: Εφαρµογή σε διάφορα περιβάλλοντα Java To RTJS δεν θα πρέπει να περιέχει προδιαγραφές που θα περιορίζουν τη χρήση του σε ορισµένα περιβάλλοντα όπως πχ. κάποιο συγκεκριµένο JDK κλπ. Συµβατότητα προς τα πίσω Το RTJS θα πρέπει να επιτρέπει την εκτέλεση σε υπάρχουσες Java εφαρµογές µη πραγµατικού χρόνου. Write once Run Anywhere Το RTJS θα πρέπει να αποδεχθεί την σηµασία του WORA αλλά και να εκτιµήσει κατάλληλα την δυσκολία της εφαρµογής της αρχής αυτής σε συστήµατα πραγµατικού χρόνου. Τρέχουσες χρήσεις σε σχέση µε µελλοντικές επεκτάσεις Τo RTJS θα πρέπει να διασφαλίζει τις τρέχουσες χρήσεις αλλά και να επιτρέπει µελλοντικές επεκτάσεις µε στόχο ενσωµάτωση νέων χαρακτηριστικών. Προβλέψιµη συµπεριφορά Πρώτης προτεραιότητας στόχο θα πρέπει να αποτελεί για το RTJS η προβλέψιµη συµπεριφορά κάτω από κάθε συνθήκη. Μη επέκταση της σύνταξης Η γλώσσα δεν θα πρέπει να επεκτείνει την υπάρχουσα σύνταξη της Java ούτε να εισάγει καινούρια keywords. Να επιτρέπει διαφοροποιήσεις σε θέµατα υλοποίησης Η οµάδα RTJEG αναγνώρισε σύντοµα ότι οι ανάγκες επιβάλουν ώστε οι διάφορες υλοποιήσεις του RTJS να διαφέρουν όσον αφορά αποφάσεις υλοποίησης όπως η χρήση περισσότερο ή λιγότερο αποδοτικών αλγορίθµων, trade offs µεταξύ χρόνου και χώρου, και άλλα θέµατα. Για το λόγο αυτό το RTJS πρέπει να προσφέρει την ευελιξία της δηµιουργίας υλοποιήσεων που να καλύπτουν τις εκάστοτε απαιτήσεις.

34 ΑΡΤΙΟ Τελική έκθεση 34 Μέσα στα παραπάνω πλαίσια ορίσθηκαν επτά περιοχές του περιβάλλοντος Java στις οποίες θα πρέπει να δοθεί ειδική µέριµνα για την υποστήριξη εφαρµογών πραγµατικού χρόνου. Στη συνέχεια γίνεται µια σύντοµη αναφορά στις βασικές κατευθύνσεις που τέθηκαν σε κάθε µια από τις επτά αυτές περιοχές. Thread scheduling / dispatching Η ποικιλία των µοντέλων scheduling και dispatching και η αναγνώριση ότι το κάθε επι µέρους µοντέλο έχει ευρεία αποδοχή σε επί µέρους κλάδους των βιοµηχανικών συστηµάτων πραγµατικού χρόνου οδήγησε στην υιοθέτηση της άποψης που δεν προσδιορίζει την φύση ενός συγκεκριµένου µηχανισµού αλλά ούτε και οριοθετεί τον αριθµό των µηχανισµών που µπορούν να χρησιµοποιηθούν. Επιπλέον το RTJS απαιτεί έναν βασικό scheduler για όλες τις υλοποιήσεις, ο οποίος είναι γνώριµος σε προγραµµατιστές ΣΠΧ. Πρέπει να είναι βασισµένος σε προτεραιότητες, να είναι preemptive και να έχει 8 τουλάχιστο επίπεδα προτεραιοτήτων. ιαχείριση µνήµης Αναγνωρίσθηκε πως η αυτόµατη διαχείριση µνήµης αποτελεί ένα σηµαντικότατο χαρακτηριστικό στοιχείο της Java, και έγινε προσπάθεια το έργο αυτό να εκτελείται αυτόµατα στο µέτρο του δυνατού και να µην φορτίζει το έργο του προγραµµατιστή. Επιπλέον αναγνωρίστηκε η ύπαρξη πολλών µηχανισµών garbage collection (GC) και πως αρκετοί από αυτούς ικανοποιούν τις απαιτήσεις των εφαρµογών πραγµατικού χρόνου. Έτσι η γενική στρατηγική για την αυτόµατη διαχείριση µνήµης θα πρέπει: Να είναι ανεξάρτητη από οποιαδήποτε αλγόριθµο GC Να επιτρέπει στο πρόγραµµα να εκτιµά στο χρόνο εκτέλεσης τις επιδράσεις ενός αλγορίθµου στην εξέλιξη του Να επιτρέπει την διαχείριση αντικειµένων έξω από την επιρροή οποιουδήποτε GC. Συγχρονισµός και διαχείριση πόρων Στις προδιαγρφές αποφασίσθηκε ότι για να επιτραπεί ασφαλής συγχρονισµός σε πραγµατικό χρόνο, πρέπει οι υλοποιήσεις του keyword synchronized που παρέχει η Java να συµπεριλαµβάνουν αλγορίθµους που αποτρέπουν το priority inversion σε threads που έχουν δηµιουργηθεί. Επίσης εντοπίστηκε ότι σε µερικές περιπτώσεις priority inversion πολλοί αλγόριθµοι δεν είναι αποδοτικοί τόσο στο να αποφύγουν το priority inversion όσο και στο να επιτρέπουν στο thread να έχει εκτελεσιµότητα υψηλότερη από τον GC. Έτσι δηµιουργήθηκε ένα σύνολο από wait-free queue κλάσεις όπου µπορούν να χρησιµοποιηθούν σε τέτοιες περιπτώσεις. Ασύγχρονος χειρισµός γεγονότων Στις προδιαγρφές έχουν συµπεριληφθεί αποδοτικοί µηχανισµοί οι οποίοι γενικεύουν τον µηχανισµό της Java για ασύγχρονο χειρισµό γεγονότων. Απαραίτητες κλάσεις αναπαριστούν γεγονότα που πιθανόν να συµβούν και λογική που εκτελείται όταν αυτά τα γεγονότα συµβούν. Η εκτέλεση αυτής της λογικής δροµολογείται µέσο ενός ήδη υλοποιηµένου scheduler. Ασύγχρονη µεταφορά ελέγχου Μερικές φορές γεγονότα στον πραγµατικό χρόνο αλλάζουν τόσο δραστικά και ασύγχρονα όπου το παρόν σηµείο εκτέλεσης του προγράµµατος πρέπει να µεταφερθεί

35 ΑΡΤΙΟ Τελική έκθεση 35 σε κάποιο άλλο σηµείο. Το RTSJ συµπεριλαµβάνει έναν µηχανισµό ο οποίος επεκτείνει το exception handling ώστε να αλλάζει ο έλεγχος εύκολα σε κάποιο άλλο thread. Ασύγχρονος τερµατισµός thread Πολλές φορές η λογική του προγράµµατος µπορεί να χρειάζεται να µεταφέρει τον έλεγχο ενός thread και να το τερµατίσει µε ασφάλεια. Παρόλο που ο µηχανισµός της Java δεν είναι ασφαλής, στο RTJS είναι. Πρόσβαση στην φυσική µνήµη Στο RTJS ορίζεται µία κλάση που επιτρέπει στους προγραµµατιστές να έχουν πρόσβαση στην µνήµη σε επίπεδο byte, όπως επίσης και µια κλάση που επιτρέπει και την δηµιουργία αντικειµένων στην φυσική µνήµη Το σύστηµα Jini Το σύστηµα Jini είναι ένα κατανεµηµένο σύστηµα που υποστηρίζει αφενός µεν την δηµιουργία κοινοτήτων (federations) που περιλαµβάνουν χρήστες και τους πόρους που οι χρήστες αυτοί χρειάζονται, αφετέρου δε την υποστήριξη της µεταξύ τους συνεργασίας. Στόχος είναι να µετατραπεί το δίκτυο σε ένα ευέλικτο, εύκολο στη διαχείριση πληθυσµό όπου οι πόροι µπορούν εύκολα να εντοπιστούν και χρησιµοποιηθούν από ανθρώπινους αλλά και υπολογιστικούς πελάτες. Το δίκτυο µεταλλάσσεται κατ αυτόν τον τρόπο σε µια ευέλικτη οντότητα που ανταποκρίνεται καλύτερα στις δυναµικές απαιτήσεις µιας εξελισσόµενης οµάδας χρηστών και των αντίστοιχων πόρων-υπηρεσιών. Οι πόροι ή υπηρεσίες που µπορεί να υλοποιούνται είτε σαν συσκευές υλικού είτε σαν λογισµικό είτε σαν συνδυασµός των δύο, µπορούν να εισέρχονται αλλά και να εξέρχονται από την κοινότητα µε ένα πιο ευέλικτο και δυναµικό σχήµα. Η υπηρεσία (service) αποτελεί το βασικό στοιχείο του συστήµατος Jini. Μια υπηρεσία είναι µια οντότητα που µπορεί να χρησιµοποιηθεί από ένα πρόσωπο, ένα πρόγραµµα ή ακόµη από µια άλλη υπηρεσία. Σαν υπηρεσίες ενδεικτικά αναφέρονται: συσκευές όπως εκτυπωτές, οδηγοί δίσκων, CDs, κ.λ.π. λογισµικό όπως εφαρµογές ή εργαλεία (utilities) και πληροφορία όπως βάσεις δεδοµένων και αρχεία. Οι υπηρεσίες εµφανίζονται σαν αντικείµενα της γλώσσας προγραµµατισµού Java τα οποία µπορεί να αποτελούνται µε τη σειρά τους από άλλα αντικείµενα. Κάθε υπηρεσία έχει µια διεπαφή η οποία ορίζει τις λειτουργίες που µπορεί να ζητηθούν από την υπηρεσία. Ο τύπος της υπηρεσίας είναι αυτός που ορίζει τις διεπαφές που απαρτίζουν την υπηρεσία. Τα βασικά τµήµατα του Jini συστήµατος είναι: Ένα σύνολο από συνιστώσες (components) που παρέχουν την απαραίτητη υποδοµή για την δηµιουργία των κοινοτήτων των υπηρεσιών Ένα µοντέλο προγραµµατισµού που υποστηρίζει και ενθαρρύνει την παραγωγή αξιόπιστων κατανεµηµένων υπηρεσιών Υπηρεσίες που αποτελούν µέρος των Jini κοινοτήτων αλλά και παρέχουν λειτουργικότητα σε κάθε άλλο µέλος της κοινότητας Τα παραπάνω τµήµατα αν και φαίνονται ευδιάκριτα εκ πρώτης όψης έχουν άµεση συσχέτιση µεταξύ τους. Οι συνιστώσες που παρέχουν την απαραίτητη υποδοµή για την δηµιουργία των κοινοτήτων των υπηρεσιών χρησιµοποιούν το µοντέλο

36 ΑΡΤΙΟ Τελική έκθεση 36 προγραµµατισµού Jini. Το ίδιο συµβαίνει και µε τις υπηρεσίες που χρησιµοποιούν την παραπάνω υποδοµή. Επίσης το µοντέλο προγραµµατισµού υποστηρίζεται απαραίτητα από τις συνιστώσες της υποδοµής. Είναι εµφανές ότι το σύστηµα Jini επεκτείνει το περιβάλλον προγραµµατισµού Java από τα όρια µιας εικονικής µηχανής Java (virtual Java machine) σε ένα δίκτυο µηχανών. Η δυνατότητα που παρέχει το Java περιβάλλον προγραµµατισµού για µετακίνηση από µηχανή σε µηχανή όχι µόνο του κώδικα αλλά και των απαραίτητων δεδοµένων αποτελεί την βάση για την δόµηση ενός σθεναρού περιβάλλοντος για κατανεµηµένες εφαρµογές. Το περιβάλλον έχει ενσωµατωµένους µηχανισµούς ασφάλειας, οι οποίοι επιτρέπουν το ασφαλές κατέβασµα κώδικα από άλλη µηχανή και την εν συνεχεία εκτέλεση του. Άλλα στοιχεία του Java περιβάλλοντος που εκµεταλλεύεται το σύστηµα Jini για να απλοποιήσει την ανάπτυξη κατανεµηµένων εφαρµογών είναι το strong typing και η δυνατότητα κλήσης οποιουδήποτε τµήµατος του δικτύου για την εκτέλεση λειτουργιών. Το βασικό χαρακτηριστικό του συστήµατος Jini είναι η παροχή µηχανισµών προς συσκευές, υπηρεσίες και χρήστες να προσχωρούν (join) σε κοινότητες Jini αλλά και να αποχωρούν (detach) από αυτές όταν το κρίνουν απαραίτητο. H διαδικασία της προσχώρησης αλλά και αυτή της αποχώρησης εκτελούνται αυτόµατα χωρίς την παρέµβαση του διαχειριστή συστήµατος και έτσι µπορούν να εκτελούνται όποτε απαιτηθούν οδηγώντας σε πλήρως δυναµικά εξελισσόµενα συστήµατα. Το σύστηµα προϋποθέτει την ύπαρξη ενός δικτύου που διασυνδέει τα µέλη της κοινωνίας. Επίσης κάθε συσκευή που θέλει να έχει Jini λειτουργικότητα πρέπει να διαθέτει κάποια υπολογιστική ισχύ, αλλά και µνήµη. Η τελευταία αυτή προϋπόθεση δεν είναι αυστηρή καθώς η αρχιτεκτονική Jini παρέχει τη δυνατότητα ενσωµάτωσης συσκευών που δεν διαθέτουν υπολογιστική ισχύ και µνήµη. Στην περίπτωση αυτή µια άλλη οντότητα που διαθέτει υπολογιστική ισχύ και µνήµη και είναι γνωστή µε το όνοµα proxy, αναλαµβάνει να διαδραµατίσει το ρόλο του αντιπροσώπου της συσκευής στην κοινότητα Jini. Σαν βασική γλώσσα για την ανάπτυξη των υπηρεσιών Jini θεωρείται η Java, αλλά µπορεί να χρησιµοποιηθεί και κάθε άλλη γλώσσα που διαθέτει µεταγλωττιστή που παράγει κώδικα συµβατό µε αυτόν της Java Η υπηρεσία σαν βασικό στοιχείο του συστήµατος Jini Η υπηρεσία αποτελεί όπως ορίστηκε παραπάνω το βασικό δοµικό στοιχείο κάθε συστήµατος Jini. Πρέπει να τονισθεί ότι το σύστηµα Jini δεν είναι απλά ένα σύνολο πελατών και εξυπηρετών, χρηστών και προγραµµάτων ή ακόµη προγραµµάτων και αρχείων, αλλά ένα σύστηµα που δηµιουργεί µια δυναµικά εξελισσόµενη κοινωνία υπηρεσιών που συνεργάζονται για την εκτέλεση ενός συγκεκριµένου έργου. Το σύστηµα παρέχει µηχανισµούς για την ανάπτυξη υπηρεσιών, για την ενσωµάτωση τους σε κοινωνίες Jini, την επικοινωνία µε τα άλλα µέλη της κοινότητας και γενικότερα την χρήση τους σε κατανεµηµένα συστήµατα. Η επικοινωνία µεταξύ των µελών της κοινότητας Jini βασίζεται στο πρωτόκολλο-υπηρεσίας (service protocol), το οποίο είναι ένα σύνολο από Java διεπαφές. Το πρωτόκολλο-υπηρεσίας είναι ένα ανοικτό πρωτόκολλο για το οποίο έχουν προς το παρόν ορισθεί µόνο τα πολύ βασικά πρωτόκολλα που είναι απαραίτητα για την υποστήριξη βασικών αλληλεπιδράσεων µεταξύ υπηρεσιών.

37 ΑΡΤΙΟ Τελική έκθεση Η υπηρεσία Lookup Η υπηρεσία lookup δίνει τη δυνατότητα στους χρήστες µιας κοινότητας Jini να αναζητήσουν την κατάλληλη υπηρεσία. Αφενός µεν αντιστοιχεί διεπαφές που περιγράφουν την παρεχόµενη λειτουργικότητα µιας υπηρεσίας σε ένα σύνολο από αντικείµενα που υλοποιούν την υπηρεσία αφετέρου δε διατηρώντας ένα σύνολο από περιγραφικά χαρακτηριστικά για κάθε υπηρεσία υποστηρίζει µια αυστηρή διαδικασία επιλογής µεταξύ παρόµοιων υπηρεσιών. H υπηρεσία-lookup έχει ιεραρχική οργάνωση επιτρέποντας σε µια υπηρεσία να περιέχει άλλες υπηρεσίες-lookup. To χαρακτηριστικό αυτό µπορεί να επεκταθεί µε τρόπο που µια περιεχόµενη υπηρεσία να περιλαµβάνει αντικείµενα που ενσωµατώνουν άλλες υπηρεσίες naming και discovery παρέχοντας τη δυνατότητα ανάπτυξης γεφυρών (bridges) µεταξύ του συστήµατος Jini και άλλων παρόµοιων συστηµάτων. Μια υπηρεσία προστίθεται σε µια υπηρεσία-lookup αυτόµατα από το ίδιο το αντικείµενο που παρέχει την υπηρεσία µε κατάλληλη χρήση των πρωτοκόλλων discovery και join. Το πρωτόκολλο discovery επιτρέπει τον εντοπισµό της κατάλληλης υπηρεσίας-lookup και στη συνέχεια η εισαγωγή της υπηρεσίας στην κοινότητα γίνεται µε χρήση του πρωτοκόλλου join Java Remote Method Invocation Η επικοινωνία µεταξύ υπηρεσιών γίνεται µε τη χρήση του Java Remote Method Invocation (JRMI) το οποίο αντίθετα µε την υπηρεσία-lookup δεν αποτελεί υπηρεσία που πρέπει να εντοπιστεί και στη συνέχεια να χρησιµοποιηθεί αλλά αποτελεί βασικό τµήµα της Jini υποδοµής. Είναι ο µηχανισµός που υποστηρίζει τον εντοπισµό και ενεργοποίηση των κατάλληλων αντικειµένων και στη συνέχεια την συλλογή τους µε τη διαδικασία GC. Ο JRMI µηχανισµός επεκτείνει την παραδοσιακή Remote Procedure Call - RPC τεχνική στο επίπεδο αντικειµένων και κλήσης µεθόδων για την γλώσσα προγραµµατισµού Java. H ισχύς του µηχανισµού έγκειται στην δυνατότητα που παρέχει για µεταφορά, όχι µόνο δεδοµένων, αλλά αντικειµένων που περιλαµβάνουν και τον κώδικα τους. Η µεταφορά κώδικα που συντελείται µε αυτό τον τρόπο δίνει µια ιδιαίτερη ευελιξία και απλότητα στο σύστηµα Jini. Πελάτες µπορούν να χρησιµοποιούν υπηρεσίες σε ένα δίκτυο χωρίς να απαιτείται η γνωστή από τον διαχειριστή συστήµατος διαδικασία εγκατάστασης ή φορτώµατος των κατάλληλων οδηγών ή άλλου λογισµικού. H πλήρης στοίβα πρωτοκόλλων που χρησιµοποιεί το σύστηµα Jini δίνεται στο σχήµα 10. Application Jini Java OS Network Service protocol Java RMI Network protocol Service Jini Java OS Network

38 ΑΡΤΙΟ Τελική έκθεση 38 Σχήµα 10. Στοίβα πρωτοκόλων που χρησιµοποιεί το σύστηµα Jini Εκµίσθωση Η έννοια της εκµίσθωσης (leasing) είναι βασική για τη λειτουργία του συστήµατος Jini παρέχοντας ευελιξία και ευκαµψία σε αυτό. Μια συσκευή υπηρεσία ενσωµατώνεται στην κοινότητα για συγκεκριµένο εκµισθωµένο χρόνο (leased time). Όταν ο χρόνος παρέλθει η συσκευή επαναδιαπραγµατεύεται νέο εκµισθωµένο χρόνο. Αν για οποιοδήποτε αιτία η συσκευή αποµακρυνθεί από το δίκτυο πριν ο εκµισθωµένος χρόνος της παρέλθει, η καταχώρηση της συσκευής από τον lookup πίνακα αφαιρείται. Η διαδικασία της εκµίσθωσης υποστηρίζεται από το πρωτόκολλο υπηρεσίας το οποίο υποστηρίζει τη διαπραγµάτευση της εκµίσθωσης µεταξύ του χρήση µιας υπηρεσίας και της οντότητας που παρέχει την υπηρεσία. Η εκµίσθωση µπορεί να είναι αποκλειστική ή µη-αποκλειστική. Αποκλειστική εκµίσθωση ισοδυναµεί µε αποκλειστική χρήση της υπηρεσίας ενώ η µη-αποκλειστική επιτρέπει σε πολλούς χρήστες να διαµοιράζονται την υπηρεσία πόρο Συναλλαγή Μια ακολουθία λειτουργιών της ίδιας υπηρεσίας ή περισσοτέρων υπηρεσιών µπορούν να οµαδοποιηθούν και να αντιµετωπιστούν σαν συναλλαγή (transaction) µε τον µηχανισµό του transaction που το σύστηµα Jini υποστηρίζει. Το Transaction interface του Jini συστήµατος παρέχει τις απαραίτητες υπηρεσίες πρωτοκόλλου που απαιτούνται για την εφαρµογή συναλλαγών δύο φάσεων (two phase commit) Γεγονότα Η αρχιτεκτονική Jini υποστηρίζει τη διαχείριση των γεγονότων (events) σε κατανεµηµένο περιβάλλον. Κάθε αντικείµενο της Jini κοινότητας επιτρέπει σε άλλα αντικείµενα της κοινότητας να δηλώσουν ενδιαφέρον για συγκεκριµένα γεγονότα και να ενηµερώνονται σχετικά κάθε φορά που αυτά λαµβάνουν χώρα. Παρέχει έτσι την κατάλληλη υποδοµή για την ανάπτυξη κατανεµηµένων event-based προγραµµάτων αυξηµένης αξιοπιστίας και επεκτασιµότητας Συνιστώσες ενός Jini συστήµατος Οι συνιστώσες που απαρτίζουν ένα Jini σύστηµα διακρίνονται σε τρεις κατηγορίες (σχήµα 11): Συνιστώσες υποδοµής (infrastructure) Συνιστώσες µοντέλου προγραµµατισµού και Υπηρεσίες Η υποδοµή είναι το σύνολο των συνιστωσών που επιτρέπει την δηµιουργία κοινοτήτων Jini, ενώ οι υπηρεσίες είναι οι οντότητες που συµµετέχουν στην κοινότητα. Το µοντέλο προγραµµατισµού είναι το σύνολο των διεπαφώνs που υποστηρίζει την ανάπτυξη αξιόπιστων υπηρεσιών είτε αυτές είναι µέρος της υποδοµής είτε µέλη της κοινότητας. Αν και είναι δυνατός ο ορισµός ενός συστήµατος µε την ίδια ή παραπλήσια λειτουργικότητα µε αυτήν του συστήµατος Jini χωρίς την χρήση των συγκεκριµένων τεχνολογιών, η επιλογή των συγκεκριµένων τεχνολογιών παρέχει στο Jini την

39 ΑΡΤΙΟ Τελική έκθεση 39 απαιτούµενη ισχύ για την ανάπτυξη σύγχρονων κατανεµηµένων εφαρµογών. Στην ουσία µε τον συνδυασµό αυτό η αρχιτεκτονική Jini επεκτείνει στο δίκτυο το µοντέλο προγραµµατισµού, την υποδοµή και τις υπηρεσίες που έκαναν την Java επιτυχηµένο περιβάλλον στα επίπεδα µιας µηχανής. Υποδοµή Java Java Virtual Machine Remote Method Invocation Java Security Java Discovery/Join + Distributed Security Jini Lookup Μοντέλο προγραµµατισµού Java APIs Java Beans. Leasing Transactions Events Υπηρεσίες JNDI Enterprise Beans JTS. Printing Transaction Manager JavaSpaces Service Σχήµα 11. Βασικές Συνιστώσες της αρχιτεκτονικής Jini. Στη συνέχεια γίνεται µια σύντοµη αναφορά σε κάθε µια από τις παραπάνω κατηγορίες Υποδοµή H υποδοµή ορίζει και τον ελάχιστο δυνατό πυρήνα του συστήµατος Jini. O πυρήνας αυτός περιλαµβάνει: Ένα κατανεµηµένο σύστηµα ασφάλειας ενσωµατωµένο στον µηχανισµό JRMI, που επεκτείνει το µοντέλο ασφάλειας της Java στον περιοχή των κατανεµηµένων συστηµάτων. Τα πρωτόκολλα discover και join που επιτρέπουν σε υπηρεσίες (υλικού και λογισµικού) να ανακαλύπτουν κοινότητες, να ενσωµατώνονται σε αυτές και να διαφηµίζουν τις παρεχόµενες υπηρεσίες τους στα άλλα µέλη της κοινότητας. Την υπηρεσία καταλόγου (lookup service), που βασίζεται σε ένα κατάλογο που οι καταχωρήσεις του είναι Java αντικείµενα και όχι αναφορές σε αυτά. Τα αντικείµενα αυτά µπορούν να µεταφερθούν µε χρήση της κατάλληλης υπηρεσίας καταλόγου και να χρησιµοποιηθούν σαν τοπικοί αντιπρόσωποι (proxies) της υπηρεσίας που καταχώρησε το αντικείµενο στην υπηρεσία καταλόγου. Πιο αναλυτικά τα πρωτόκολλα discovery και join ορίζουν τον τρόπο µε τον οποίο µια υπηρεσία οποιουδήποτε τύπου ενσωµατώνεται στην κοινότητα Jini. Ο µηχανισµός JRMI αποτελεί την βάση για την επικοινωνία των υπηρεσιών. Το µοντέλο ασφάλειας ορίζει τον τρόπο µε τον οποίο οι οντότητες αναγνωρίζονται αλλά και αποκτούν δικαιώµατα για την εκτέλεση ενεργειών για λογαριασµό τους ή για λογαριασµό άλλων οντοτήτων. Τέλος, η υπηρεσία καταλόγου περιέχει τα τρέχοντα µέλη της κοινότητας και δρα σαν το κεντρικό σηµείο για την προσφορά και την ανεύρεση υπηρεσιών από τα µέλη της κοινότητας.

40 ΑΡΤΙΟ Τελική έκθεση 40 Η υποδοµή υποστηρίζει το µοντέλο προγραµµατισµού αλλά και το χρησιµοποιεί. Η βασική υποστήριξη έγκειται στην δυνατότητα µεταφοράς κώδικα που η υποδοµή παρέχει και αποτελεί απαραίτητη προϋπόθεση για το µοντέλο προγραµµατισµού. Οι καταχωρήσεις της υπηρεσίας καταλόγου εκµισθώνονται για συγκεκριµένο χρόνο επιτρέποντας την υπηρεσία να γνωρίζει επακριβώς κάθε χρονική στιγµή το σύνολο των διαθέσιµων υπηρεσιών. Η ενσωµάτωση ή αποµάκρυνση µιας υπηρεσίας από την υπηρεσία καταλόγου αποτελούν γεγονότα τα οποία γνωστοποιούνται στις οντότητες που ζήτησαν κάτι τέτοιο. Έτσι οι οντότητες ενηµερώνονται για την προσφορά νέων υπηρεσιών ή την διακοπή παροχής άλλων. Σε περίπτωση που µια οντότητα δεν µπορεί να εντοπίσει µια υπηρεσία καταλόγου, µπορεί να χρησιµοποιήσει µια τεχνική γνωστή µε το όνοµα peer lookup. Σύµφωνα µε αυτή, η οντότητα αποστέλλει απευθείας σε αντικείµενα-παροχείς υπηρεσιών το ίδιο πακέτο πληροφορίας που αποστέλλει στην υπηρεσία καταλόγου ζητώντας από αυτούς να παραχωρήσουν την υπηρεσία. Τα αντικείµενα-παροχείς υπηρεσιών µε τη σειρά τους εκτελούν µια διαδικασία καταχώρησης σαν αυτή του καταλόγου υπηρεσίας αλλά τώρα προς τον πελάτη σαν αυτός να είναι υπηρεσία καταλόγου. Ο πελάτης στη συνέχεια µπορεί να επιλέξει την υπηρεσία που χρειάζεται από τις αιτήσεις καταχώρησης που δέχτηκε σαν απόκριση στην αίτηση του και να απορρίψει τις υπόλοιπες Μοντέλο προγραµµατισµού Οι υποδοµή όπως και οι υπηρεσίες είναι υπολογιστικές οντότητες που αναπτύσσονται µε το Java µοντέλο προγραµµατισµού. Οι υπηρεσίες συνιστούν διεπαφές οι οποίες µε τη σειρά τους ορίζουν επικοινωνιακά πρωτόκολλα που µπορούν να χρησιµοποιηθούν από τις υπηρεσίες και την υποδοµή για την µεταξύ τους επικοινωνία. Οι υπηρεσίες αυτές συνιστούν µια επέκταση της του βασικού περιβάλλοντος της Java και ορίζουν την Jini αρχιτεκτονική. Μεταξύ των διεπαφών που απαρτίζουν το Jini περιβάλλον προγραµµατισµού είναι: Το leasing interface, που ορίζει τον τρόπο εκµίσθωσης και απελευθέρωσης πόρων µε µια τεχνική ανανέωσης διάκριτων χρονικών διαστηµάτων (durationbased renewable model). Επεκτείνει το µοντέλο προγραµµατισµού Java προσθέτοντας την παράµετρο χρόνο στην διαδικασία απόκτησης της αναφοράς ενός πόρου, για να αντιµετωπίσει τα προβλήµατα που δηµιουργούνται από πτώσεις του δικτύου. Τα event και notification interfaces, που αποτελούν επέκταση του event µοντέλου που υιοθετούν οι JavaBeans συνιστώσες για το κατανεµηµένο περιβάλλον και επιτρέπουν µια βασισµένη σε γεγονότα επικοινωνία µεταξύ των υπηρεσιών του Jini συστήµατος. Το transaction interface που υποστηρίζει επικοινωνία βασισµένη στην έννοια της συναλλαγής. Εισάγει ένα ελαφρύ αντικειµενοστραφές πρωτόκολλο που επιτρέπει τις Jini εφαρµογές να συντονίζουν αλλαγές καταστάσεων. Στην πρώτη φάση της συναλλαγής κάθε αντικείµενο γνωρίζει ότι έχει ολοκληρώσει τη δική του συνεισφορά στο έργο και δεσµεύεται να αποδεχθεί τις αλλαγές που επιτελέστηκαν. Σε µια δεύτερη φάση µια οντότητα συντονιστής αποστέλλει µια αποδοχή της συναλλαγής (commit) σε κάθε αντικείµενο που συµµετέχει σε αυτή.

41 ΑΡΤΙΟ Τελική έκθεση 41 Οι διεπαφές του µοντέλου προγραµµατισµού Jini χρησιµοποιούνται από τις συνιστώσες υποδοµής όπου απαιτείται και από τις βασικές υπηρεσίες του συστήµατος Jini. Έτσι για παράδειγµα η υπηρεσία καταλόγου χρησιµοποιεί το interface leasing για να διασφαλίσει ότι οι καταχωρηµένες υπηρεσίες εξακολουθούν να είναι διαθέσιµες και το interface event για να υποστηρίξει τους διαχειριστές να εντοπίσουν προβλήµατα και συσκευές που θέλουν διαµόρφωση (configuration) Υπηρεσίες Οι υπηρεσίες που απαρτίζουν κοινότητες Jini κάνουν χρήση της υποδοµής Jini για να ανακαλύψουν και κάνουν κλίσεις η µία στην άλλη, για να ανακοινώσουν την παρουσία τους σε άλλες υπηρεσίες και χρήστες της κοινότητας. Από την σκοπιά της υλοποίησης οι υπηρεσίες έχουν την µορφή αντικειµένων υλοποιηµένων µε την γλώσσα προγραµµατισµού Java. Κάθε υπηρεσία έχει µια διεπαφή που ορίζει τις λειτουργίες που µπορούν να κληθούν από αυτήν. Κάποιες από αυτές τις διεπαφές προτείνονται για χρήση από προγράµµατα, ενώ άλλα προτείνονται για χρήση από τον αποδέκτη της υπηρεσίας ώστε η υπηρεσία να µπορεί να επικοινωνήσει µε το χρήστη. Μια υπηρεσία µπορεί να υλοποιηθεί µε χρήση άλλων υπηρεσιών. Σαν παράδειγµα υπηρεσιών αναφέρονται: H υπηρεσία εκτύπωσης, που υποστηρίζει την εκτύπωση από Java αλλά και από κληροδοτηµένες (legacy) εφαρµογές. Η υπηρεσία JavaSpaces, που µπορεί να χρησιµοποιηθεί για απλή επικοινωνία και για αποθήκευση σχετιζόµενων οµάδων Java αντικειµένων. Η υπηρεσία διαχείρισης συναλλαγών (transaction manager), που επιτρέπει οµάδες από αντικείµενα να συµµετέχουν στο Jini πρωτόκολλο συναλλαγών που ορίζεται από το Jini µοντέλο προγραµµατισµού Χρήση υπηρεσίας από πελάτη Ένας πελάτης της κοινότητας Jini πρέπει πρώτα να εντοπίσει µια υπηρεσία καταλόγου ή να αναθέσει το έργο αυτό σε µια άλλη οντότητα. Στη συνέχεια επικοινωνεί µε την υπηρεσία καταλόγου για να εντοπίσει µια υπηρεσία του τύπου που θέλει να χρησιµοποιήσει. Η διαδικασία εντοπισµού χρησιµοποιεί τη διεπαφή της υπηρεσίας, τον τύπο της και ένα σύνολο από περιγραφικά χαρακτηριστικά της υπηρεσίας. Το αντικείµενο-υπηρεσίας που εντοπίστηκε µεταφέρεται στον πελάτη και είναι διαθέσιµο για κλήση των κατάλληλων µεθόδων. Οι µέθοδοι του αντικειµένουυπηρεσίας (proxy) µπορούν να επικοινωνούν µε το αντικείµενο-παροχέα (service provider) µε ένα οποιοδήποτε πρωτόκολλο. ιαφορετικές υλοποιήσεις του ίδιου αντικειµένου-υπηρεσίας µπορεί να χρησιµοποιούν διαφορετικά πρωτόκολλα για την αλληλεπίδραση τους µε το αντικείµενο-παροχέα. Η υλοποίηση των µεθόδων του αντικειµένου-υπηρεσίας µπορεί να γίνει είτε µε JRMI αναφορές στο αποµακρυσµένο αντικείµενο που υλοποιεί την υπηρεσία, είτε σαν τοπικός υπολογισµός που υλοποιεί όλη την υπηρεσία τοπικά στον πελάτη, είτε σαν συνδυασµός αυτών. Στην περίπτωση αυτή το αντικείµενο-υπηρεσίας που υλοποιεί µέρος της υπηρεσίας τοπικά στον πελάτη και το υπόλοιπο µε αποµακρυσµένη κλίση διαµέσου JRMI αναφοράς στο αντικείµενο-παροχέα καλείται smart proxy. Μια διεπαφή χρήστη µπορεί να αποθηκευθεί σε µια υπηρεσία καταλόγου σαν κατηγόρηµα (attribute) µιας καταχωρηµένης υπηρεσίας. Η διεπαφή αυτή µεταφέρεται στο χώρο του πελάτη εκτελείται και δίνει τη δυνατότητα στο χρήστη να διαχειριστεί άµεσα την υπηρεσία. Σαν παράδειγµα θεωρήστε την περίπτωση µιας Java εφαρµογής

42 ΑΡΤΙΟ Τελική έκθεση 4 που θέλει να χρησιµοποιήσει την υπηρεσία εκτύπωσης σε ένα σύγχρονο εκτυπωτή στον οποίο ο χρήστης της Java εφαρµογής θα πρέπει να ορίσει ένα σύνολο από παραµέτρους εκτύπωσης που υποστηρίζει ο συγκεκριµένος εκτυπωτής, όπως εκτύπωση µπρος-πίσω, αριθµό σελίδων ανά φύλλο, κ.λ.π. Η υπηρεσία εκτύπωσης που εκπροσωπεί τον συγκεκριµένο εκτυπωτή στην Jini κοινότητα θα πρέπει να έχει αποθηκεύσει στην υπηρεσία καταλόγου την κατάλληλη διεπαφή χρήστη σαν κατηγόρηµα µαζί µε το αντικείµενο-υπηρεσίας. Η διεπαφή θα µεταφερθεί στον χώρο του πελάτη, θα εκτελεστεί και ο χρήστης θα ορίσει τις ιδιαίτερες παραµέτρους του συγκεκριµένου εκτυπωτή Αρχιτεκτονικές συσκευών Jini Η αρχιτεκτονική Jini είναι αρκετά ευέλικτη, όσον αφορά τις απαιτήσεις της από τις συσκευές Jini. Η ευελιξία έγκειται στο γεγονός ότι επιτρέπει διάφορες αρχιτεκτονικές που επιβάλλονται από τις εκάστοτε απαιτήσεις κόστους, επιδόσεων, λειτουργικότητας και ευκαµψίας. Έτσι ο σχεδιαστής που αναπτύσσει µια υπηρεσία για να εισάγει µια συσκευή στην κοινότητα Jini έχει στην διάθεση του τις παρακάτω επιλογές χωρίς αυτές να είναι οι µόνες δυνατές. 1. Συσκευές µε ενσωµατωµένη εικονική µηχανή Java. Πρόκειται για συσκευές που διαθέτουν την υπολογιστική ισχύ, την µνήµη και τον σταθερό αποθηκευτικό χώρο που απαιτεί µια πλήρης JVM και τα τµήµατα εκείνα του περιβάλλοντος προγραµµατισµού Java που είναι απαραίτητα για την υποστήριξη της υποδοµής Jini (loading, RMI, security, ). Στην περίπτωση αυτή η µηχανή έχει την µορφή εξειδικευµένης network appliance που προσφέρει µια συγκεκριµένη υπηρεσία ή σύνολο υπηρεσιών διαµέσου µιας ενσωµατωµένης πλατφόρµας Java.. Συσκευές που χρησιµοποιούν εξειδικευµένη εικονική µηχανή. Πρόκειται για συσκευές που διαθέτουν µια εξειδικευµένη εικονική µηχανή που υποστηρίζει µόνο τις λειτουργίες που είναι απαραίτητες από το πρωτόκολλο discovery και την υπηρεσία καταλόγου, µε αποτέλεσµα λιγότερες απαιτήσεις σε υπολογιστική ισχύ, µνήµη, κ.λ.π. Προφανώς πρόκειται για συσκευές περιορισµένης ευελιξίας όσον αφορά την επεκτασιµότητα. 3. Συσκευές οµαδοποιηµένες µε κοινή χρήση µιας εικονικής µηχανής που βρίσκεται στον ίδιο φυσικό χώρο. Αποτελεί εναλλακτικό τρόπο για την µείωση του κόστους χωρίς να θυσιαστεί η ευελιξία. Ένα σύνολο από συσκευές χρησιµοποιούν από κοινού την ίδια JVM σαν ενδιάµεσο επίπεδο για την επικοινωνία τους µε τα υπόλοιπα µέλη της κοινότητας Jini. Στην περίπτωση αυτή µια συσκευή container που διαθέτει την απαραίτητη υποδοµή για την JVM µπορεί να δεχτεί ένα σύνολο από φυσικές συσκευές που θα µοιράζονται την JVM για να συµµετάσχουν στην κοινότητα Jini. H συσκευή αυτή container που ονοµάζεται Jini device bay παρέχει ισχύ, σύνδεση σε δίκτυο και την απαραίτητη υποδοµή για την λειτουργία της JVM, λειτουργεί δε σαν ένας dispatcher προς τις επί µέρους συσκευές που είναι εµφωλιασµένες µέσα της. 4. Συσκευές οµαδοποιηµένες µε κοινή χρήση µιας εικονικής µηχανής που βρίσκεται στον δίκτυο. Περίπτωση ανάλογη της προηγούµενης αλλά οι συσκευές δεν είναι στον ίδιο χώρο µεταξύ τους αλλά και µε την JVM. H επικοινωνία τους µε την JVM γίνεται µε χρήση ιδιωτικού πρωτοκόλλου. Η προσέγγιση αυτή βοηθά στη δηµιουργία γεφυρών (gateways) µεταξύ συσκευών Jini και άλλων αντίστοιχων συστηµάτων. Η προσέγγιση αυτή είναι η πιο ελκυστική για την ενσωµάτωση

43 ΑΡΤΙΟ Τελική έκθεση 43 καταναλωτικών ηλεκτρονικών συσκευών και ηλεκτρονικών συσκευών που χρησιµοποιούνται στην βιοµηχανία αλλά και το οικιακό περιβάλλον. 5. Υπηρεσίες Jini πάνω από το πρωτόκολλο IIOP. Στην περίπτωση αυτή η επικοινωνία βασίζεται πάνω στο πρωτόκολλο Internet Inter-Operability (IIOP) της αρχιτεκτονικής CORBA. Συσκευές που διαθέτουν CORBA ORB µπορούν να επικοινωνούν µε την υπηρεσία καταλόγου Jini χρησιµοποιώντας το πρωτόκολλο IIOP. Είναι προφανές ότι στην περίπτωση αυτή η υπηρεσία κατάλογου θα πρέπει να διαθέτει δύο υλοποιήσεις για τη διεπαφή της, µία για το RMI και µία για το IIOP Επισκόπηση της τεχνολογίας COM Η Component Object Model (COM) αρχιτεκτονική, είναι µια αντικειµενοστραφής περιγραφή, σχεδιασµένη να παρέχει διαλειτουργικότητα (interoperability) µεταξύ συνόλων προκαθορισµένων ρουτινών που καλούνται διεπαφές. Είναι βασισµένο σε δυαδικό(binary) στάνταρ παρά σε επίπεδο πηγαίου κώδικα, µε αποτέλεσµα αντικείµενα που είναι γραµµένα σε διάφορες γλώσσες προγραµµατισµού(όπως, Visual C++, Visual Basic, Delphi, Borland C++ Builder, κ.ά.) να επικοινωνούν, παρόλο που µπορούν να βρίσκονται σε διαφορετικό process space και ακόµη σε διαφορετικές πλατφόρµες. ιαθέτει επίσης µια βιβλιοθήκη η οποία περιέχει ένα σύνολο από στάνταρ διεπαφές που ορίζουν την κύρια λειτουργία ενός COM αντικειµένου, καθώς και ένα σύνολο από API λειτουργίες σχεδιασµένες για την διαχείριση τέτοιων αντικειµένων. Σχεδιασµένη ως αρχιτεκτονική επέκτασης συστηµάτων λογισµικού, η COM αποτελεί την βάση για άλλες τεχνολογίες όπως το OLE και το ActiveX. Αυτές οι τεχνολογίες αποτελούν επεκτάσεις του λειτουργικού συστήµατος όπου διέπονται από του δικούς τους κανόνες και παρέχουν δικές τους βιβλιοθήκες για την διαχείρισή τους. Χρησιµοποιώντας την COM σαν θεµέλιο, οι σχεδιαστές µπορούν να δηµιουργήσουν τις δικές τους επεκτάσεις ώστε νέα αντικείµενα να επικοινωνούν µε υπάρχοντα. Στον Πίνακα 1 δίνονται κάποιες περιγραφές που ορίζει το COM ενώ το Σχήµα 1 δείχνει την αλληλοσυσχέτιση αυτών των στοιχείων σε µια απλή COM/ActiveX εφαρµογή. Πίνακας. Περιγραφή που ορίζει το COM Interface Σύνολο µεθόδων, µε ξεκάθαρο προσδιορισµένο προορισµό COM Object Ένα στιγµιότυπο µιας κλάσης, που καλείτε CoClass, που υλοποιεί τις µεθόδους των διεπαφών COM/ActiveX server Ένα module (ΕΧΕ, DLL, ή OCX) που περιέχει κώδικα για COM ή ActiveX αντικείµενα Class Factory Ένα αντικείµενο ικανό να δηµιουργήσει ένα COM αντικείµενο από κάποια προσδιορισµένη CoClass Type library Ένα δυαδικό αρχείο συµβόλων(binary symbol file) όπου περιέχει πληροφορίες για ένα COM ή ActiveX server Τεχνολογία DCOM Γενικά το Distributed COM ορίζεται ως η δυνατότητα ενός αντικειµένου να τρέξει σε µια µηχανή υπό τον έλεγχο µιας άλλης. Το DCOM πραγµατοποιεί ουσιαστικά τoν µηχανισµό του COM όπου η διεπαφή ενός αντικειµένου µπορεί να είναι απόµακρο (remote).

44 ΑΡΤΙΟ Τελική έκθεση 44 Η κλήση µιας µεθόδου διεπαφής είναι µια απλή κλήση συνάρτησης. Μετατρέποντας κάθε κλήση µιας µεθόδου σε RPC client proxy (κάτι σαν «πλαστή» υλοποίηση), οι παράµετροι µπορούν να περαστούν σ ένα δίκτυο χρησιµοποιώντας DCERPC format (Ditributed Computing Environment) και να µεταδοθούν στον server. O server διαθέτει ένα RPC stub όπου και καλεί την πραγµατική διεπαφή από το πραγµατικό αντικείµενο. Οι επιστρεφόµενες τιµές γυρίζουν στο stub από όπου και γυρίζουν στον client µέσο του proxy. Από την πλευρά του client το proxy είναι η συνάρτηση που καλείται, από την πλευρά του server το stub είναι ο client που την καλεί. Αυτή η διαδικασία σηµαίνει ότι ο χρήστης µιας διεπαφής δεν ξέρει ότι η υλοποίηση του είναι αποµακρυσµένη, εκτός από το ότι παίρνει περισσότερο χρόνο να εκτελεστεί. Αντίστοιχα και η διεπαφή δεν ξέρει ότι ο καλών βρίσκεται σε αποµακρυσµένο µηχάνηµα. Σχήµα 1. Στοιχεία ενός COM/ActiveX server Type library IUnknown COM/ActiveX server IUnknown IDispatch IMyInterface COM object A IClassFactory Class factory for COM object A IUnknown IUnknown IProvideTypeIn ISupportErrorI IData COM object B IClassFactory Class factory for COM object B OLE for Process Control (OPC) Η προδιαγραφή OPC υπαγορεύει κατά κύριο λόγο το πλαίσιο προσπέλασης εφαρµογών σε δεδοµένα (data access) που αφορούν σε µια βιοµηχανική διεργασία κατά τη φάση εκτέλεσής της. Τα δεδοµένα δηµιουργούνται σε πραγµατικό χρόνο από τη βιοµηχανική διεργασία (π.χ. ένας βρόχος ελέγχου PID). Η εποπτεία κρίσιµων παραµέτρων είναι επιτακτική ανάγκη σ ένα σύστηµα βιοµηχανικής αυτοµατοποίησης και ως εκ τούτου, η προδιαγραφή OPC δηµιουργεί ένα παράθυρο

45 ΑΡΤΙΟ Τελική έκθεση 45 στην εξέλιξη της διεργασίας, για τη παρακολούθησή της, χωρίς βέβαια να παραβιάζει η λειτουργία της. Με το τρόπο αυτό οι τιµές των παραµέτρων της διεργασίας εξάγονται από τη κλειστή νησίδα αυτοµατοποίησης και προσφέρονται σε εφαρµογές παρακολούθησης, ελέγχου, οπτικοποίησης και αποθήκευσης. Η προδιαγραφή OPC προσφέρει ένα µοναδικό και τυποποιηµένο τρόπο για την εξαγωγή των παραµέτρων παρακάµπτοντας κλειστούς και ιδιοκτησιακούς τρόπους επικοινωνίας µεταξύ εφαρµογών και διεργασίας. Η προδιαγραφή OPC στηρίζεται στις τεχνολογίες COM και DCOM της Microsoft. Συγκεκριµένα, υπεύθυνος για την εξαγωγή των παραµέτρων µε τη µορφή αντικειµένων είναι ο OPC server. Τυπικό είναι το σενάριο διαφορετικών OPC clients (όπως εφαρµογές Scada, Excel) να συνδέονται µέσω του δικτύου µε τον OPC server. Λόγω του ότι τα προϊόντα της Microsoft είναι αρκετά δηµοφιλή, ανάλογη είναι και η υιοθέτηση του OPC. Σήµερα οι περισσότεροι από τους κατασκευαστές βιοµηχανικού λογισµικού υποστηρίζουν τη τεχνολογία OPC στα προϊόντα τους Αρχιτεκτονική DNA-Μ Η Microsoft πρόσφατα ανακοίνωσε την αρχιτεκτονική Windows Distributed internet Applications (Windows DNA) for Manufacturing. Συµφωνα µε αυτή την αρχιτεκτονική, θα επιτραπεί η εύκολη ολοκλήρωση κατανεµηµένων βιοµηχανικών εφαρµογών, ενεργοποιώντας την εύκολη ανταλλαγή πληροφοριών από το χαµηλότερο επίπεδο της βιοµηχανίας µέχρι και την διαδικασία του ERP. Αυτή η ολοκλήρωση θα ενισχύσει τις δυνατότητες της συλλογής, καταµερισµού και ανάλυσης δεδοµένων µιας επιχείρησης σε πραγµατικό χρόνο, καταλήγοντας σε καλύτερες αποφάσεις, µεγαλύτερη αποδοτικότητα και χαµηλότερο κόστος. Μεγάλοι κατασκευαστές όπως η Siemens AG, ICONICS, Hewlett Packard, National Instruments κλπ. ήδη έχουν αρχίσει να υποστηρίζουν αρκετά την αρχιτεκτονική. Η αρχιτεκτονική, χτισµένη στην πλατφόρµα των Windows, περιλαµβάνει όλες τις γνωστές τεχνολογίες Microsoft, όπως COM/DCOM, OPC καθώς και εργαλεία ανάπτυξης όπως Visual Basic, Microsoft Office κλπ. 5 Σχεδιασµός και Ανάπτυξη πρωτοτύπου 5.1 Γενικά Για να ικανοποιήσουµε την απαίτηση της βιοµηχανίας της κατανοµής βιοµηχανικών συσκευών οι οποίες βρίσκονται σε διαφορετικά, ετερογενή και αποµακρυσµένα βιοµηχανικά δίκτυα υιοθετήσαµε την ιδέα των µονάδων διασύνδεσης, για να διασυνδέσουµε κάθε ένα βιοµηχανικό τοµέα µε το εσωτερικό δίκτυο της βιοµηχανίας. Η προσέγγιση µας για χρήση µονάδων διασύνδεσης µεταξύ των βιοµηχανικών δικτύων και του εσωτερικού δικτύου της εταιρίας, δεν επιφέρει αλλαγές στην ήδη προκαθορισµένη διεργασία καθενός δικτύου και απαιτεί µόνο την ανάθεση των Function Blocks σε κάθε βιοµηχανικό δίκτυο. Αν και αυτή η λύση ικανοποιεί τις απαιτήσεις για παρακολούθηση σε υψηλό επίπεδο δεν ικανοποιεί τις προδιαγραφές διασύνδεσης σε πραγµατικό χρόνο µεταξύ βιοµηχανικών τοµέων. Το υποσύστηµα επικοινωνίας θα πρέπει να παρέχει την απαραίτητη ποιότητα των υπηρεσιών για να ικανοποιεί τις χρονικές απαιτήσεις.

46 ΑΡΤΙΟ Τελική έκθεση Η προτεινόµενη αρχιτεκτονική 4 επιπέδων Για να προχωρήσουµε µε τον σχεδιασµό και την ανάπτυξη ενός εργαλείου υποστήριξης µηχανικού, που απαιτείται για την υποστήριξη του σχεδιασµού, υλοποίησης και λειτουργίας ενός κατανεµηµένου βιοµηχανικού συστήµατος, προχωρήσαµε στον ορισµό µιας αρχιτεκτονικής η οποία φαίνεται στο Σχήµα 13. Σχήµα 13. H προτεινόµενη αρχιτεκτονική 4-επιπέδων. Το κάτω επίπεδο, το επίπεδο πραγµατικού κόσµου, είναι το προκείµενο κατανεµηµένο βιοµηχανικό σύστηµα. Αποτελείτε από την υπό έλεγχο βιοµηχανική διεργασία, τα διάφορα τµήµατα των βιοµηχανικών δικτύων µε τις συνδεδεµένες συσκευές, τις µονάδες διασύνδεσης, το δίκτυο, το intranet της βιοµηχανίας, το δωµάτιο ελέγχου και τον χώρο των µηχανικών. Η ανάπτυξη ενός τέτοιου αξιόπιστου συστήµατος είναι ο στόχος του εργαλείου υποστήριξης του µηχανικού. Προς αυτή την κατεύθυνση, τα υψηλότερα επίπεδα πρέπει να τα αναθέτουµε απευθείας και αυτή η ανάθεση να µην είναι ορατή στον µηχανικό. Πρέπει να προστεθούν κατάλληλοι µηχανισµοί στο εργαλείο, ώστε η ενσωµάτωση αυτών των λειτουργιών να έχουν πρωταρχική σηµασία. Το επόµενο επίπεδο, το επίπεδο συστήµατος, περιλαµβάνει τις απαραίτητες έννοιες, οι οποίες χρησιµοποιούνται από το εργαλείο για να υποστηρίξουν την διαδικασία κατανοµής και ανάθεσης των Function Block σε συσκευές. Αποτελείται από κατάλληλες αναπαραστάσεις των συσκευών, των δικτύων, των µονάδων διασύνδεσης και των σχετικών διασυνδέσεων. Αυτές οι αναπαραστάσεις έχουν την µορφή αντιπροσώπων αντικειµένων του πραγµατικού κόσµου. Το εργαλείο επιτρέπει στον µηχανικό να σχεδιάσει το σύστηµα και να το αντιστοιχήσει στα χαµηλότερα επίπεδα.

47 ΑΡΤΙΟ Τελική έκθεση 47 Για να γίνει αυτή η αντιστοίχηση, χρειάζεται η προδιαγραφή των συσκευών. Αυτή η προδιαγραφή πρέπει να είναι συµβατή µε ένα κοινό µοντέλο, συνοδεύει την συσκευή µε κάποια αναπαράσταση, όπως είναι η XML. Ο µηχανικός που δουλεύει στο επίπεδο πραγµατικό κόσµου, θα συνδέσει τις συσκευές στο βιοµηχανικό δίκτυο. Μετά θα εισάγει την αναπαράσταση της συσκευής στο επίπεδο συστήµατος και χρησιµοποιώντας την προδιαγραφή σε XML και το εργαλείο, θα δηµιουργήσει ένα µοντέλο κατάλληλο να διαβαστεί από την µηχανή. Αυτό είναι και το τελευταίο βήµα για την διαδικασία ανάθεσης των αντιπροσώπων των συσκευών. Ανάλογη διαδικασία πρέπει να ακολουθηθεί για τα υπόλοιπα στοιχεία του επιπέδου του συστήµατος. Το τρίτο επίπεδο, το επίπεδο εφαρµογής, χρησιµοποιείται για να απεικονίσουµε τα ανάλογα δοµικά στοιχεία που χρησιµοποιούνται στο σχεδιασµό και στην υλοποίηση µιας κατανεµηµένης βιοµηχανικής εφαρµογής. Τα Function Blocks, συνδέσεις δεδοµένων και γεγονότων, IPTs (Industrial Process Parameters) και διάφοροι παράµετροι της βιοµηχανικής διεργασίας, είναι οι κύριες έννοιες και τα κύρια δοµικά στοιχεία του επιπέδου εφαρµογής, το οποίο πρέπει να δηµιουργείται από το ανάλογο εργαλείο. Τα στιγµιότυπα των IPTs πρέπει να αντιστοιχηθούν στις πραγµατικές συσκευές. Το εργαλείο πρέπει να παρέχει την λειτουργικότητα που χρειάζεται για την διαδικασία της ανάθεσης των Function Blocks προς το επίπεδο συστήµατος. ιεργασίες του εργαλείου που δεν έχουν να κάνουν άµεσα µε την φάση σχεδίασης της εφαρµογής, αλλά σχετίζονται µε την διαδικασία παραµετροποίησης του συστήµατος, πρέπει να αποκρύπτονται µε κατάλληλους encapsulation µηχανισµούς. Τέλος, το επίπεδο διεπαφής ανθρώπου-µηχανής, περιλαµβάνει όλες τις απαραίτητες έννοιες που έχουν να κάνουν µε την ανάπτυξη και λειτουργία SCADA συστηµάτων. Αυτό το επίπεδο φαίνεται να απασχολεί εν µέρει το εργαλείο του µηχανικού. 5.3 Εργαλείο Μηχανικού (Enginnering Support Systems, ESS) Προς την κατεύθυνση αυτή ορίσθηκαν οι παρακάτω ενέργειες Ορισµός του εργαλείου µηχανικού µε µια σύντοµη αναφορά στο functionality του. Μελέτη τυποποίησης στο χώρο Μελέτη εργαλείων της αγοράς Μελέτη των εργαλείων διαχείρισης των profibus και Lonworks. Εξέταση της διαθέσιµης υποδοµής για ανάπτυξη των επιµέρους εργαλείων (APIs των δικτύων profibus και Lonworks). Καταγραφή του functionality του προτεινόµενου εργαλείου (χρήση της user driven προσέγγισης π.χ. use cases). ηµιουργία µοντέλου ανάλυσης (σε άµεση σχέση µε το µοντέλο του Virtual Fieldbus) Στα πλαίσια ανάπτυξης του Εργαλείου Μηχανικού µελετήθηκε και ορίστηκε η περιγραφή συσκευής βιοµηχανικού δικτύου. Στη συνέχεια περιγράφονται αναλυτικά οι ενέργειες και τα αποτελέσµατα στα πλαίσια αυτής της δράσης. 5.4 Μελέτη προβλήµατος και λύσεων για περιγραφή συσκευής Κατά την αρχική φάση ένταξης στο πρόγραµµα, µελετήθηκε αναλυτικά η γλώσσα προγραµµατισµού Java, η ανάλυση και o σχεδιασµός συστήµατος πραγµατικού χρόνου µε αντικειµενοστραφή προσέγγιση. Τέλος, έγινε µια σε βάθος προσέγγιση της

48 ΑΡΤΙΟ Τελική έκθεση 48 δοµής του δικτύου πεδίου (Fieldbus) Profibus, επικεντρώνοντας στην υψηλού επιπέδου περιγραφή του πρωτοκόλλου. Για να αποκτηθεί µια πλήρης εικόνα των απαιτήσεων και αναγκών του σχεδίου µελετήθηκε το standard του Profibus, οι διαφορετικές παραλλαγές του (DP- Decentralized Periphery, PA, FMS-Fieldbus Machine Specification), τα επίπεδα του OSI µοντέλου που αντιστοιχούν στο Profibus standard, οι προδιαγραφές αυτών και παραδείγµατα εφαρµογών. Λαµβάνοντας υπ όψη τις απαιτήσεις πραγµατικού χρόνου, εντοπίστηκαν κατά τη µελέτη τα σηµεία διαχωρισµού των χαρακτηριστικών πραγµατικού και µη πραγµατικού χρόνου. Κατόπιν, µελετήθηκε ο τρόπος ανάπτυξης και σχεδιασµού µιας εφαρµογής µε αντικειµενοστραφή προσέγγιση, µε εστίαση στην αναπαράσταση και ικανοποίηση απαιτήσεων πραγµατικού χρόνου (real-time constraints). Σ αυτά τα πλαίσια, µελετήθηκε η αντικειµενοστραφής ανάπτυξη συστήµατος µε τη χρήση use cases, η οποία και επιλέχθηκε για την περιγραφή σε υψηλό επίπεδο της λειτουργίας του γενερικού εργαλείου. Στη συνέχεια, µελετήθηκε η γλώσσα αντικειµενοστρεφούς προγραµµατισµού Java. Αναλυτικότερα, επιλέχθηκε αυτή ως κατάλληλη για την υλοποίηση του γενερικού εργαλείου, αφού κρίθηκε πλήρης για την καταγραφή και κάλυψη των αναγκών για λογική περιγραφή των δοµών και των διατάξεων πεδίου στο επίπεδο του εικονικού δικτύου. Η ανάπτυξη του Εργαλείου Μηχανικού περιλαµβάνει την καταγραφή και ανάλυση των απαραίτητων και βασικών (σε πρώτη φάση) δυνατοτήτων που ένα τέτοιο εργαλείο οφείλει να προσφέρει. Για το σκοπό αυτό αναπτύσσεται ένα µοντέλο κλάσεων µε όλες τις έννοιες ενός δικτύου πεδίου, τις αλληλεπιδράσεις µε το χρήστη και τα χαρακτηριστικά των παραµέτρων από τις οποίες αυτό αποτελείται. Σηµαντικό ρόλο στο µοντέλο παίζει η καταγραφή των χαρακτηριστικών των κλάσεων και των παραµέτρων τους. Τα πρότυπα IEC1499 και IEC1804 παρέχουν τις προδιαγραφές µιας συσκευής ώστε να ικανοποιεί τις απαιτήσεις των σύγχρονων συστηµάτων ελέγχου, όπως αυξηµένη ασφάλεια, δυνατότητα υποστήριξης από τα διαθέσιµα εργαλεία, µειωµένο κόστος ανάπτυξης και υποστήριξης, δυνατότητα διατήρησης, µετατροπής, αναβάθµισης, ελέγχου εγκυρότητας, προσαρµοστικότητας, συµβατότητας µε εργαλεία, επαναχρησιµοποίησης στοιχείων λογισµικού και σχεδιασµού. Σκοπός των προτύπων είναι να ορίσουν ένα κοινό πρότυπο που να παρέχει στους χρήστες συµβατότητα, αλληλεπίδραση, διασύνδεση, διαλειτουργικότητα και ανταλλαξιµότητα όσον αφορά τις συσκευές που θα επιλέξουν. Για την αναπαράσταση και σχεδίαση της συµπεριφοράς των συσκευών χρησιµοποιούνται Function Blocks (FB). Οι απαιτήσεις για τα διάφορα µέρη της συσκευής αποτελούν τις προδιαγραφές που η συσκευή πρέπει να ικανοποιεί ώστε να µπορεί να υλοποιήσει τους αλγόριθµους και τη συµπεριφορά που περιγράφει ο σχεδιασµός των FB (επιµέρους κοµµατιών της συσκευής). Κατά την πρώτη φάση συγκεντρώθηκαν τα χαρακτηριστικά µιας συσκευής όπως αναλύονται από τις υπάρχουσες προδιαγραφές και παρουσιάζονται παρακάτω.

49 ΑΡΤΙΟ Τελική έκθεση 49 Επεξεργασία µετρήσεων Σύνδεση δείκτη εγκυρότητας µε την προς επεξεργασία µέτρηση. Ένδειξη δυνατοτήτων της συσκευής µε «κατάσταση συσκευής». Ανάλυση υποβάθµισης συσκευής Άµεση πρόσβαση σε πληροφορία σχετικά µε διαγνωστικά της συσκευής, αποτελέσµατα ελέγχου και παρεµβάσεις διατήρησης. Χρόνος λειτουργιών υπό µη ονοµαστικές συνθήκες Αριθµός µη οµαλών events Αναγνώριση συσκευής Αριθµός µερών εξαρτηµάτων της συσκευής Εκδόσεις υλικού και λογισµικού Κλίµακες εργασίες Υλικά Αναγνωριστική ετικέτα συσκευής (device tag) Ηµεροµηνία εγκατάστασης ιαχείριση χρόνου του συστήµατος Εντολή συγχρονισµού που επιτρέπει χρονική ακρίβεια Σχετικός χρόνος δικτύου Απόλυτος χρόνος δικτύου ιαχείριση αναθεώρησης Profile της συσκευής Αναθεώρηση του profile της συσκευής Αναθεώρηση κλειδωµένου γραψίµατος στατικών δεδοµένων Παράµετροι που επιτρέπουν προσπέλαση Επικοινωνία ντετερµινιστικές µεταφορές χωρική συνέπεια των µεταφορών χρονική συνέπεια των µεταφορών υποστήριξη µηχανισµών αποφυγής υπερφόρτωση κατά περιόδους υψηλής δραστηριότητας ιαχείριση συστήµατος Όνοµα κατασκευαστή Αριθµός τύπου ή ονόµατος Αριθµός αναθεώρησης Σειριακός αριθµός Κατά την κανονική λειτουργία η συσκευή πρέπει να ονοµαστεί από µια µοναδική παράµετρο συσκευής (φυσική ετικέτα) ιευθυνσιοδότηση δικτύου Οι διευθύνσεις που έχουν ανατεθεί στους κόµβους είναι καθορισµένες σε κάθε συσκευή µέσω διακοπτών ή γέφυρας βραχυκύκλωσης (jumper) Η ανάθεση διευθύνσεων πρέπει να µπορεί να γίνει δυναµικά ή στατικά Standard δοµές δεδοµένων

50 ΑΡΤΙΟ Τελική έκθεση 50 Standard σηµασιολογία Κοινή λειτουργία σχετική µε τα δεδοµένα Standard ορισµός εισόδων, εξόδων, συναρτήσεων ελέγχου Κατάσταση εισόδων, εξόδων Εντολή ενεργοποίησης fail-safe τύπου λειτουργίας Λεξικό µε objects που περιλαµβάνονται στη συσκευή Βάσει αυτών των προδιαγραφών και των προτύπων IEC61499 και IEC1804 αναπτύχθηκαν τα αντίστοιχα µοντέλα συσκευών σε UML πάνω στα οποία προστέθηκαν στη συνέχεια οι απαιτήσεις που προέκυψαν κατά την ανάπτυξη του ESS. Τα µοντέλα αυτά φαίνονται στα Σχήµατα 14 και 15. SystemConfig SystemName : undefined ApplicationSpec : undefined ApplicationConfig Parameters DeviceConfig DevName : undeifned DevTypeName : undefined ResourceConfig ResName : undefined ResTypeName : undefined AccessPath : undefined ItemType Resource TypeInDevType : undefined TypeInDevInstance : undefined EventCon InDevType : undefined InDevInstance : undefined InResInstance : undefined Present FB TypeName : undefined Name : undefined Init : undefined FBType InDevType : undefined InDevInstance : undefined DataCon InDevType : un defin ed InDevInstan ce : und efine d InResIn stn ce : undefined Σχήµα 14. UML αναπαράσταση για τη διαµόρφωση του µοντέλου συσκευής του IEC61804

51 ΑΡΤΙΟ Τελική έκθεση 51 Device Name : undfined Application 1..* 1 System 1 0..* CreateRes() InitRes() StartRes() StopRes() DeleteRes() QueryRes() FunctionBlock Name : undefined TypeName : undefined Init : undefined Param eters Name : undefined DataType : undefined Init : undefined 1..* DeviceType 1 TypeName : undefined * 1..* EventConnection Source : undefined Destination : undefined EventType : undefined 1 1..* DataConnection Source : undefined Destination : undefined 1 1..* 1..* ResInstDataCon Source : undefined Destination : undefined 1 Resource Name TypeName PAccessPath : undefined CreateItem () CreateFB() CreateCon() InitItem () InitFB() InitCon() StartItem() StartFB() StartCon() StopItem() StopFB() StopCon() DeleteItem () DeleteFB() DeleteCon() QueryItem() QueryFB() QueryCon() 1 1..* 1 1..* FB Name : undefined TypeName : undefined Init : undefined FBType ResInstEventCon Source : undefined Destination : undefined FBType 1..* ResFunctionBlock Name : undefined Type : undefined Init : undefined 1..* ResourceType MaxDataCon : undefined MaxEventCon : undefined 1 PAccessPath : undefined RequiredExecTime : undefined * ItemType ResParameters Name : undefined TypeName : undefined DataType : undefined Init : undefined 1..* 1..* ResEventConnection Source : undefined Destination : undefined ResEventType : undefined 1..* R esdataconnection Source : undefined Destination : undefined Σχήµα 15. UML αναπαράσταση µοντέλου συσκευής του IEC Σύνθεση υπαρχόντων προδιαγραφών Η βιοµηχανία λογισµικού βιοµηχανικής διαδικασίας, συστηµάτων µέτρησης και ελέγχου (IPMCS) αντιµετωπίζει όλο και περισσότερο σήµερα την πρόκληση της δηµιουργίας των σύνθετων επί παραγγελία διανεµηµένων συστηµάτων ελέγχου στα πλαίσια του χρόνου και του προϋπολογισµού, ενώ ο υψηλός ανταγωνισµός µειώνει τις τιµές. Προκειµένου να αντιµετωπιστούν αυτά τα ζητήµατα, τα εξελισσόµενα πρότυπα, όπως το IEC και το πιο πρόσφατο IEC61804, καθορίζουν τις βασικές έννοιες και µια µεθοδολογία για το σχεδιασµό µορφοποιηµένων, επαναχρησιµοποιήσιµων, κατανεµηµένων IPMCSs. Σύµφωνα µε αυτά, το FB αποτελεί την βασική δοµική µονάδα των εφαρµογών IPMCS. Το FB που καθορίζεται µε µια µορφή ανεξάρτητη της εφαρµογής, υπόσχεται να βελτιώσει την παραγωγικότητα από την άποψη της ικανότητας επαναχρησιµοποίησης, της αξιοπιστίας, της ευελιξίας και της διαλειτουργικότητας. Τα FBs µπορούν να χρησιµοποιηθούν για να καθορίσουν τα γερά, επαναχρησιµοποιήσιµα τµήµατα λογισµικού που αποτελούν το κατανεµηµένο IPMCS. Ακόµη περισσότερο, για να αντιµετωπίσει την αυξηµένη πολυπλοκότητα των σύγχρονων IPMCSs, εισάγει δοµές όπως «σύνθετο FB» και «υπο-εφαρµογή». Επίσης µια ορίζεται µεθοδολογία σχεδιασµού συστηµάτων για την κατασκευή κατανεµηµένων συστηµάτων ελέγχου.

52 ΑΡΤΙΟ Τελική έκθεση 5 Αυτή η µεθοδολογία επιτρέπει τον καθορισµό συστηµάτων µέσω λογικά συνδεδεµένων FBs που τρέχουν στα διαφορετικά στοιχεία επεξεργασίας. Ολόκληρες εφαρµογές µπορούν να υλοποιηθούν µέσω ενός δικτύου διασυνδεµένων απλών FBs, σύνθετων FBs και των υποεφαρµογών. Στο Σχήµα 16 παρουσιάζεται το µοντέλο συσκευής όπως µελετήθηκε από το πρότυπο IEC Τα FB-ESS νέας γενιάς είναι απαραίτητα για την υποστήριξη ολόκληρου του κύκλου ζωής αυτών των εφαρµογών IPMCS. Ένα ESS πρέπει να υποστηρίξει τον µηχανικό, τόσο κατά τη φάση ανάλυσης όσο και κατά τη φάση σχεδιασµού καθώς επίσης και στη φάση εφαρµογής. Χρησιµοποιώντας ένα τέτοιο σύστηµα, ο µηχανικός πρέπει να είναι σε θέση να αρχίσει µε την ανάλυση του διαγράµµατος εγκαταστάσεως ώστε να εξάγει τις απαιτήσεις ελέγχου. Κατόπιν, πρέπει να είναι σε θέση να καθορίσει τους σηµαντικότερους τοµείς της λειτουργίας και της αλληλεπίδρασής τους µε την εγκατάσταση. Κατά τη διάρκεια αυτής της στοιχειώδους εργασίας, πρέπει να είναι σε θέση, να εκµεταλλευτεί τα FBs που παρέχονται από τις ευφυείς συσκευές πεδίων όπως οι έξυπνες βαλβίδες, αλλά και να αναθέσει τη λειτουργία στα φυσικά στοιχεία συµπεριφοράς όπως τα PLCs, τα όργανα και οι ελεγκτές. Όλα τα ανωτέρω πρέπει να ολοκληρωθούν ανεξάρτητα από το ελλοχεύον υποσύστηµα επικοινωνίας ακόµη και στη ακραία περίπτωση, όπως µια συνάθροιση διασυνδεµένων τµηµάτων του fieldbus, τα οποία προέρχονται από τους διαφορετικούς προµηθευτές. = D ata & event flow Communication link(s) Device boundary Communication interface(s) Resource x Resource y Resource z Application A Application C Application B Process interface(s) Controlled process Σχήµα 16. Μοντέλο συσκευής του IEC61499 Στα πλαίσια του προγράµµατος ΑΡΤΙΟ, θεωρήσαµε τη διαδικασία διασύνδεσης ετερογενών δικτύων πεδίου, και το σχεδιασµό και εφαρµογή ενσωµατωµένων, κατανεµηµένων FB εγαρµογών πάνω σε αυτά τα δίκτυα. Αναπτύξαµε µια αρχιτεκτονική 4 επιπέδων, η οποία αποδείχθηκε πολύ χρήσιµη κατά τη διαδικασία ανάλυσης των βασικών εννοιών που θα αποτελέσουν τη βάση για την ανάπτυξη FBπροσανατολισµένου ESS. Η αρχιτεκτονική καθορίζει τις βασικές κατευθύνσεις που ένα ESS πρέπει να εξετάσει και διαδραµατίζει έναν σηµαντικό ρόλο κατά τη διάρκεια της φάσης ανάπτυξης ενός ESS εργαλείου. Επίσης, καθώς οι ανάγκες των βιοµηχανικών συστηµάτων αυξάνονται και γίνονται πιο απαιτητικές, τα IPMCSs τείνουν να περιλαµβάνουν συσκευές πεδίων από περισσότερους του ενός κατασκευαστές. εδοµένου ότι αυτές οι διαφορετικές συσκευές πεδίων πρέπει να

53 ΑΡΤΙΟ Τελική έκθεση 53 επικοινωνήσουν, η ανάγκη για µια κοινή περιγραφή συσκευών πεδίων για την απλή και φιλική προς το χρήστη ολοκλήρωση των συσκευών είναι περισσότερο από υποχρεωτική στα σύγχρονα σύνθετα συστήµατα αυτοµατοποίησης. Κατά συνέπεια, το ESS πρέπει να επιτρέψει στον σχεδιαστή εφαρµογής έχει µια σφαιρική επισκόπηση του συστήµατος και να είναι σε θέση να χειριστεί τις συσκευές διαφορετικών κατασκευαστών και δικτύων. Εξακριβώσαµε ότι η προδιαγραφή συσκευών είναι ένα από τα σηµαντικότερα ζητήµατα σε µια τέτοια προσέγγιση. ιάφορες προσεγγίσεις, γνωστές ως γλώσσες περιγραφής συσκευών (Device Description Language DDLs), υποστηρίζουν ήδη την προδιαγραφή των συσκευών πεδίων. ιακρίνουµε το HART DDL, την περιγραφή συσκευών Profibus, τη Foundation fieldbus DDL και τη Lonworks DDL. Η γλώσσα περιγραφής συσκευών HART, που είναι η παλαιότερη ιστορικά, χρησιµοποιείται για την προδιαγραφή των συσκευών αποστολής σηµάτων και των ενεργοποιητών στη περιοχή ελέγχου διεργασίας. Το HART δεν περιλαµβάνει τις παραµέτρους επικοινωνίας δεδοµένου ότι προορίζεται για 4-0ma από σηµείο σε σηµείο επικοινωνίες καλωδίων. Η Fieldbus Foundation DDL προέρχεται άµεσα από τη HART DDL. Αν και καλύπτει το block στοιχείο, οι λεπτοµέρειες διευθυνσιοδότησης και υπηρεσιών της συσκευής δεν εξετάζονται. Το Profibus GSD, που είναι κυρίως για τη διαµόρφωση επικοινωνίας, καλύπτει όλες τις δυνατότητες επικοινωνίας µιας συσκευής Profibus-DP. Το Lonworks παρέχει µια LONMARK εξωτερική διεπαφή, το επονοµαζόµενο XIF, το οποίο είναι ένα αρχείο καθορισµού της εξωτερική διεπαφής για ιµα συσκευή LONWORK. Η εξωτερική διεπαφή περιλαµβάνει τις πληροφορίες αυτο-τεκµηρίωσης της συσκευής, τον αριθµό καταχωρήσεων διευθύνσεων, τον αριθµό ετικεττών µηνυµάτων και τον αριθµό, τους τύπους και τις κατευθύνσεις των µεταβλητών δικτύων. εν εκθέτει τους εσωτερικούς αλγορίθµους µιας συσκευής. Αντ' αυτού, εκθέτει µόνο τις εισόδους και τα αποτελέσµατα από τους αλγορίθµους Οι ανωτέρω προσεγγίσεις χρησιµοποιούνται για να αντιπροσωπεύσουν τις ιδιότητες µιας συσκευής πεδίων σε µια µορφή αναγνώσιµη από τη µηχανή που χρησιµοποιείται από το ESS εργαλείο κατά τη διάρκεια της φάσης ανάπτυξης κατανεµηµένων IPMCS. Η προδιαγραφή χρησιµοποιείται επίσης κατά τη διάρκεια της φάσης λειτουργίας IPMCS s. Εντούτοις δεν υπάρχει κανένα κοινό µοντέλο για την προδιαγραφή συσκευών και οι ανωτέρω προσεγγίσεις οδηγούν σε µη συµβατές προδιαγραφές συσκευών. Οι δυναµικές πτυχές της διαχείρισης συσκευών καθώς επίσης και συστηµάτων πεδίων δεν καλύπτονται από καµιά από τις ανωτέρω γλώσσες. Η ανάγκη για ένα µοντέλο συσκευών πεδίων φαίνεται να είναι περισσότερο από επιτακτική. Το µοντέλο συσκευών πεδίων, που αναπτύχθηκε για τις ανάγκες της συγκεκριµένης εφαρµογής, είναι βασισµένο στα πρότυπα IEC61499 και IEC61804 και προσθέτει τις απαραίτητες ελλείπουσες πτυχές που δεν καλύπτονται από τα υπάρχοντα µοντέλα Στη συνέχεια, θεωρώντας δεδοµένη την αρχιτεκτονική 4 επιπέδων, αναλύουµε αυτό το µέρος της λειτουργίας ενός FB ESS που συσχετίζεται µε την συσκευή πεδίων. Αυτή η ανάλυση οδηγεί σε ένα σύνολο απαιτήσεων που το µοντέλο συσκευών πρέπει να εξετάσει. Το προτεινόµενο µοντέλο συσκευών, που ικανοποιεί και αυτές τις απαιτήσεις και αυτών που τίθενται από την διαλειτουργικότητα συσκευών στη φάση λειτουργίας, παρουσιάζεται παρακάτω.

54 ΑΡΤΙΟ Τελική έκθεση Η ανοιχτή αρχιτεκτονική της µονάδας διασύνδεσης Λόγω των αυστηρών χρονικών περιορισµών των βιοµηχανικών εφαρµογών η µονάδα διασύνδεσης χαρακτηρίζεται ως αυστηρά πραγµατικού χρόνου. Η επεξεργασία των δεδοµένων και η αντίδραση σε γεγονότα πρέπει να γίνεται στιγµιαία. Η προσοχή εστιάζεται στο πόσο αποτελεσµατικά οι µονάδες διασύνδεσης µπορούν να χειριστούν τέτοιες κλήσεις και πώς το υποσύστηµα επικοινωνίας µπορεί να παρέχει την απαιτούµενη ποιότητα υπηρεσιών. Για τους παραπάνω λόγους υιοθετήθηκε ένα λειτουργικό σύστηµα πραγµατικού χρόνου (RT Linux) και ορίστηκε µια αξιόπιστη, αποδοτική και επαναχρησιµοποιήσιµη αρχιτεκτονική. Για το σχεδιασµό αυτής της ανοιχτής µονάδας διασύνδεσης έπρεπε να καθοριστούν κάποιοι καλά καθορισµένοι κανόνες που προσδιορίζουν την αλληλεπίδραση µεταξύ των διαφόρων εσωτερικών υποσυστηµάτων. Χρησιµοποιούµε τον όρο αρχιτεκτονική για να αναφερθούµε στην δοµή του συστήµατος που αποτελείται από ενεργά δοµικά στοιχεία (modules), ένα µηχανισµό που επιτρέπει τη αλληλεπίδραση µεταξύ αυτών των δοµικών στοιχείων (interaction mechanism) και ένα σύνολο από κανόνες που διέπουν αυτή την αλληλεπίδραση Τα ενεργά στοιχεία της µονάδας διασύνδεσης Το Σχήµα 17 δείχνει ένα τµήµα της προτεινόµενης αρχιτεκτονικής της µονάδας διασύνδεσης, που καλύπτει την φάση κατά την οποία το σύστηµα βρίσκεται υπό λειτουργία. Αποτελείται από τα ακόλουθα ενεργά δοµικά στοιχεία. 1. Local Fieldbus Proxy (LFP). Control Application (CA) 3. Remote Fieldbus Proxy (RFP) 4. OPC server Το δοµικό στοιχείο LFP χρησιµοποιείται για να έχουµε µια αφηρηµένη εικόνα του τοπικού δικτύου ως προς το στάνταρ IEC61499 έτσι ώστε να εξασφαλίσουµε την διαλειτουργικότητα σε επίπεδο βιοµηχανικού δικτύου. Κυρίως αποτελείται από Function Block proxies που έχουν εξαχθεί από συσκευές του τοπικού βιοµηχανικού δικτύου. Ένα Function Block θεωρείται ως εξαγόµενο, εάν παρέχει ή δέχεται ένα γεγονός ή δεδοµένο από άλλα Function Blocks που βρίσκονται είτε στο δοµικό στοιχείο CA είτε σε ένα αποµακρυσµένο βιοµηχανικό δίκτυο. Μια ακόµα σηµαντική λειτουργία του δοµικού στοιχείου LFP, είναι η κωδικοποίηση και αποκωδικοποίηση των εκάστοτε αναπαραστάσεων των δεδοµένων σε αναπαραστάσεις του στάνταρ IEC Για την υλοποίηση του δοµικού στοιχείου LFP, ορίστηκε ένα επίπεδο µετατροπής (wrapper) για να υιοθετηθεί το (Application Programming Interface)API του εκάστοτε βιοµηχανικού δικτύου. Εάν πάρουµε για παράδειγµα το Profibus, ο wrapper αποτελείται από µια διαδικασία-δαίµονα που έχει πρόσβαση στη µνήµη διπλής κατεύθυνσης της κύριας κάρτας (master) Profibus, έτσι ώστε να παρέχει τον απαραίτητο µηχανισµό για τη υλοποίηση των Function Block proxies. Ο wrapper είναι επίσης υπεύθυνος στο να υλοποιεί τις διασυνδέσεις των Function Block που βρίσκονται σε διαφορετικές slave συσκευές.

55 ΑΡΤΙΟ Τελική έκθεση 55 Το δοµικό στοιχείο CA, που είναι προαιρετικό, είναι απαραίτητο µόνο όταν υπάρχει ή ανάγκη, από τον µηχανικό, της ανάθεσης Function Block στην µονάδα διασύνδεσης. Συνήθως δεν ενθαρρύνεται τέτοια σχεδιαστική επιλογή, αλλά υπάρχουν περιπτώσεις όπου του σύστηµα µας επιβάλλει τέτοιο σχεδιασµό. Σε αυτές τις περιπτώσεις, µειώνεται η απόδοση του συστήµατος, ενώ πρέπει παράλληλα να καθοριστεί ένα ανώτατο όριο των λειτουργικών απαιτήσεων αυτού του δοµικού στοιχείου. Το δοµικό στοιχείο RFP δουλεύει σαν ένας υποδοχέας (container) όλων των αντιπροσώπων των αποµακρυσµένων δικτύων που πρέπει να βρίσκονται στην µονάδα. Για την διασύνδεση δύο δικτύων διακρίνουµε τις ακόλουθες περιπτώσεις: 1 Ένας αντιπρόσωπος βιοµηχανικού δικτύου ορίζεται σε µια από τις µονάδες διασύνδεσης, έτσι ώστε να περιέχει το παραγωγό και καταναλωτή Function Block του αποµακρυσµένου βιοµηχανικού δικτύου. Σε αυτή την περίπτωση, υπάρχει µόνο ένας αντιπρόσωπος του αποµακρυσµένου βιοµηχανικού δικτύου µέσο του οποίου επιτυγχάνεται η επικοινωνία. Ορίζονται δύο αντιπρόσωποι των δικτύων ένας σε κάθε µονάδα. Σε αυτή την περίπτωση, ο αποµακρυσµένος αντιπρόσωπος του δικτύου περιέχει µόνο το Function Block καταναλωτή. Το δοµικό στοιχείο OPC server είναι επίσης ένα προαιρετικό δοµικό στοιχείο όταν υπάρχει η ανάγκη της αποµακρυσµένης σύνδεσης ενός εµπορικού SCADA client για τον έλεγχο της βιοµηχανικής διεργασίας. Αυτό το δοµικό στοιχείο δρα ως ένας µετατροπέας στην αρχιτεκτονική µας, για να µας δώσει µια διεπαφή η οποία είναι συµβατή µε το (OLE for Process Control) OPC. Επιλέξαµε το OPC γιατί φαίνεται να υιοθετείται ως "κοινά αποδεκτό" στάνταρ από την βιοµηχανία. Για την ικανοποιητική ανάπτυξη ενός δοµικού στοιχείου OPC server, πρέπει να ληφθούν υπόψη κάποιες απαιτήσεις. Το δοµικό στοιχείο: Πρέπει να υποστηρίζει σύγχρονες και ασύγχρονες λειτουργίες εγγραφής και ανάγνωσης δεδοµένων Πρέπει να διανέµει τις αιτήσεις για δεδοµένα, είτε µέσω cache είτε µε απευθείας προσπέλαση στη συσκευή. Πρέπει να είναι ικανό να ρυθµίζει την σειρά των απαιτήσεων, κρατώντας την σειρά που έγιναν και στέλνοντας πίσω τα δεδοµένα µε την ίδια σειρά. Πρέπει να εγγυάται ότι όλα τα σχετικά στοιχεία µιας οµάδας OPC αντικειµένου πρέπει να είναι ενηµερωµένα. Πρέπει να είναι ικανό σε διάφορες περιπτώσεις να στέλνει δεδοµένα (push) χωρίς προηγούµενη αίτηση στον client. Πρέπει να προσφέρει µια ασφαλή µέθοδο διακοπής λειτουργίας της βιοµηχανικής διεργασίας.

56 ΑΡΤΙΟ Τελική έκθεση Ο µηχανισµός αλληλεπίδρασης Όπως φαίνεται στο επόµενο σχήµα, για να είναι δυνατή η επικοινωνία µεταξύ των δοµικών στοιχείων, χρησιµοποιούµε µια διεργασία-δαίµονα και ένα σύνολο από δοµές δεδοµένων. Υπάρχει ένας Πίνακας Συνδέσεων Γεγονότων (Event Connection Table, ECT) για κάθε ένα δοµικό στοιχείο, εκτός από το δοµικό στοιχείο RFP. Σε αυτή τη περίπτωση υπάρχει ένα ECT για κάθε αντιπρόσωπο βιοµηχανικού δικτύου που βρίσκεται στο RFP. Ένα ECT περιέχει, για κάθε εξερχόµενο γεγονός που παράγεται από το δοµικό στοιχείο την πληροφορία που απαιτείται από τον δαίµονα ώστε να ανταποκριθεί σε αυτό το γεγονός. Όταν ένα ενεργό δοµικό στοιχείο παράγει ένα γεγονός, πρέπει να στείλει µια αίτηση στο δαίµονα για να χειριστεί αυτό το γεγονός. Ο δαίµονας χρησιµοποιεί την πληροφορία της σχετικής εγγραφής του ECT, και προωθεί το γεγονός µε τα απαραίτητα δεδοµένα στο δοµικό στοιχείου προορισµού. Είναι ξεκάθαρο ότι υπάρχει µια πολύ κοντινή σχέση µε την λέξη WITH της σηµασιολογίας του Function Block. Η πληροφορία που υπάρχει µαζί µε το WITH χρησιµοποιείται από το Εργαλείο Μηχανικού, ώστε να αρχικοποιήσει σωστά τους ECT. Σχήµα 17. Αρχιτεκτονική της µονάδας διασύνδεσης. Οι υπόλοιπες δοµές δεδοµένων που χρησιµοποιούνται βρίσκονται στον Πίνακα Σύνδεσης εδοµένων (Data Connection Table, DCT). Οι DCTs περιέχουν την απαραίτητη πληροφορία που πρέπει να συνοδεύει κάθε διασύνδεση δεδοµένων από Function Block εξόδου σε άλλα Function Block εισόδου και έχουν ως προορισµό

57 ΑΡΤΙΟ Τελική έκθεση 57 Function Block σε άλλα δοµικά στοιχεία ή σε άλλα βιοµηχανικά δίκτυα. Τέτοια πληροφορία συµπεριλαµβάνει την τιµή, χρόνο, κατάσταση κλπ.. Αυτή η πληροφορία έχει την µορφή του στάνταρ IEC Κανόνες αλληλεπίδρασης Ορίσαµε τους παρακάτω κανόνες, στην προσπάθεια µας να ικανοποιήσουµε της λειτουργικές και µη-λειτουργικές (απόδοση, επεκτασιµότητα, αντοχή) απαιτήσεις: Όταν ένα δοµικό στοιχείο παράγει δεδοµένα που χρειάζονται άλλα στοιχεία, τότε ανανεώνονται αντίστοιχα οι εγγραφές στους DCTs. Όταν ένα γεγονός που αφορά ένα δοµικό στοιχείο, δηµιουργείται από ένα άλλο ενεργό δοµικό στοιχείο, το δοµικό στοιχείο-παραγωγός ειδοποιεί τον δαίµονα για την ύπαρξη του γεγονότος δηµιουργώντας µία αίτηση εξυπηρέτησης. Όταν ο δαίµονας ειδοποιείται για την ύπαρξη του γεγονότος, προσπελαύνει τις πληροφορίες που βρίσκονται στο ECT του δοµικού στοιχείου-παραγωγού. Χρησιµοποιώντας αυτή την πληροφορία, ο δαίµονας συλλέγει τα απαραίτητα δεδοµένα από τους DCT και δηµιουργεί ένα πακέτο, που το στέλνει στο δοµικό στοιχείο προορισµού. Σε κάθε αίτηση ανατίθεται ένας αριθµός προτεραιότητας. Ένα ενεργό δοµικό στοιχείο µπορεί να δηµιουργήσει αίτηση προς ένα άλλο δοµικό στοιχείο. Ένα ενεργό δοµικό στοιχείο µπορεί να δηµιουργήσει αίτηση προς τον εαυτό του, για να ζητήσει από τον δαίµονα προκαθορισµένα δεδοµένα. Οι ECTs µπορούν να ενηµερωθούν κατά την φάση λειτουργίας του συστήµατος, επιτρέποντας την δυναµική διαµόρφωση της εφαρµογής Υλοποίηση της Μονάδας ιασύνδεσης Για την υλοποίηση της µονάδας διασύνδεσης, επιλέξαµε για λειτουργικό σύστηµα το Linux, στο οποίο προσθέσαµε στον kernel τις αναβαθµίσεις του Real-Time Linux. To Linux είναι ένα δωρεάν λειτουργικό σύστηµα, 3-bit, pre-emptive multi-tasking και multi-user. Αν και αναπτύχθηκε για εκπαιδευτικούς λόγους, έχει γίνει αρκετά ελκυστικό σε σχέση µε τους εµπορικούς του αντιπάλους. Σήµερα το Linux, έχει αναπτυχθεί από έναν από Linux kernel, σε µια πληθώρα εφαρµογών και εργαλείων ανοιχτού κώδικα, όπως C/C++, JDK και X-Windows. To RT-Linux από την άλλη, είναι ένα λειτουργικό σύστηµα αυστηρού πραγµατικού χρόνου, που ακολουθεί την προδιαγραφή POSIX για τα λειτουργικά συστήµατα πραγµατικού χρόνου. Μπορεί να χειριστεί κρίσιµες λειτουργίες, ενώ τρέχει το απλό Linux, σαν µια διεργασία που έχει την χαµηλότερη προτεραιότητα. Στο RT-Linux, ένας µικρός kernel πραγµατικού χρόνου, µοιράζεται έναν ή περισσότερους επεξεργαστές µε το απλό Linux. Αυτό επιτρέπει στο σύστηµα να τρέχει µε ακρίβεια εφαρµογές που εκτελούν συλλογή δεδοµένων από εξωτερικές συσκευές και παράλληλα να είναι και ένας κλασικός Linux σταθµός εργασίας. Ο χρόνος εξυπηρέτησης µιας διακοπής από εξωτερική συσκευή και της διαδικασίας εξυπηρέτησης της διακοπής είναι τα 15µsec, για έναν επεξεργαστή αρχιτεκτονικής x86. Η επικοινωνία µεταξύ των διεργασιών είναι εφικτή

58 ΑΡΤΙΟ Τελική έκθεση 58 µέσω FIFO πραγµατικού χρόνου ή µε κοινή µνήµη. Επιλέξαµε το RT-Linux, λόγω µεγάλης αποδοχής, σταθερότητας, δικτύωσης µέσω Linux, και λόγω του ότι διανέµεται δωρεάν. Είναι µια λύση που προσφέρει τα πλεονεκτήµατα ενός λειτουργικού πραγµατικού χρόνου σε έναν απλό επεξεργαστή, µε µικρό κόστος συντήρησης και χωρίς άλλες απαιτήσεις ειδικού software ή hardware. Το Σχήµα 18, δείχνει το Block διάγραµµα της µονάδας διασύνδεσης και καλύπτει την φάση που το σύστηµα βρίσκεται σε λειτουργία. Στο σχήµα φαίνονται όλες οι διεργασίες που αποτελούν την µονάδα διασύνδεσης. Οι RT-FIFOs χρησιµοποιούνται για την επικοινωνία µεταξύ των διεργασιών αν και σαν µηχανισµός υλοποιείται από το RT-Linux ως non-blocking. Για να προσπεράσουµε αυτό το πρόβληµα, χρησιµοποιήσαµε ειδικούς χειριστές που εξυπηρετούν την ανταλλαγή δεδοµένων µεταξύ µιας RT-Linux και µιας απλής Linux διεργασίας, καθώς και ειδικούς χειριστές πραγµατικού χρόνου για την επικοινωνία µεταξύ διεργασιών πραγµατικού χρόνου. Σχήµα 18. Αρχιτεκτονική της µονάδας διασύνδεσης όπως υλοποιήθηκε στο RT-Linux. Όπως φαίνεται στο σχήµα, ο Profibus Driver βρίσκεται στο Linux user space. Αυτός ο driver έχει αγοραστεί µαζί µε την κάρτα master από την εταιρία Softing. υστυχώς δεν υπήρχε πρόσβαση στον πηγαίο του κώδικα, και έτσι δεν έχει καταστεί ακόµη δυνατό το να µεταφέρουµε τον driver στο RT-Linux. Έτσι αναγκαστήκαµε και υλοποιήσαµε τον wrapper σε απλό Linux. Η κύρια διεργασία που εκτελεί ο wrapper είναι η µετατροπή των τιµών του Profibus σε τύπους του στάνταρτ IEC61499 και το αντίστροφο. Η διεργασία του µηχανισµού αλληλεπίδρασης έχει µειωθεί, για την πρώτη υλοποίηση, στην µεταφορά πακέτων µεταξύ των LFP και RFP. Η διεργασία του RFP είναι η µετατροπή του πακέτου, η προσθήκη των κατάλληλων headers και η αποστολή του πακέτου στο δοµικό στοιχείο προορισµού.

59 ΑΡΤΙΟ Τελική έκθεση 59 Πρέπει να τονίσουµε σ αυτό το σηµείο ότι η διεργασία µετατροπής της περιγραφής συσκευής πεδίου σε µορφή συµβατή µε το IEC61499 θα µπορούσε να συµπεριληφθεί στην κάθε συσκευή και να υλοποιηθεί τοπικά σε κάθε κόµβο του δικτύου. Αυτό θα ήταν περισσότερο συµβατό µε την κατανεµηµένη προσέγγιση, αντί της συγκέντρωσης των διαδικασιών στη µονάδα διασύνδεσης. Παρ όλ αυτά, δύο παράγοντες οδήγησαν στην επιλογή του κεντρικοποιηµένου ελέγχου. Πρώτον λήφθηκε υπ όψην το γεγονός ότι οι υπάρχουσες συσκευές πεδίου δεν είναι συµβατές µε το στάνταρτ IEC61499 και άρα είναι απαραίτητη η κάλυψη του αλγορίθµου λειτουργίας τους από τον wrapper υπό µορφή FBs. Επειδή οι συσκευές είναι διαφορετικού τύπου, προέρχονται από διαφορετικό κατασκευαστή και ανήκουν σε διαφορετικά δίκτυα πεδίου, η κεντρικοποίηση της διαδικασίας προσαρµογής τους, απλοποιεί την εισαγωγή µιας νέας συσκευής στο δίκτυο, αφού δε χρειάζεται να αλλάξει τίποτα στη µέχρι τώρα διαδικασία ενσωµάτωσης της συσκευής στο δίκτυο και το µόνο που πρέπει να αλλάξει είναι κάποια διαµόρφωση στον κώδικα του δαίµωνα µέσα στη µονάδα διαµόρφωσης. εύτερον, η master-slave επικοινωνία του δικτύου Profibus του αποδίδει µια δοµή που δεν είναι καθαρά κατανεµηµένη. Έτσι, ο έλεγχος θα µπορούσε να γίνει µόνο σε έναν master όπου και υλοποιείται η µονάδα διασύνδεσης. Ορίσαµε το δοµικό στοιχείο Net wrapper για να ενσωµατώσουµε τις διεργασίες της τοπικής και αποµακρυσµένης σύνδεσης., λόγω της µη ύπαρξης του ATM driver και του ATM protocol stack, για RT-Linux. Αυτό το ενδιάµεσο δοµικό στοιχείο, θα µας επιτρέψει την οµαλή αλλαγή µε drivers του ΑΤΜ που τυχόν θα υπάρξουν στο µέλλον. Επίσης όπως και ο Profibus wrapper, το Net wrapper βρίσκεται στο Linux user space. H διεργασία που εκτελεί η τοπική σύνδεση είναι το να "ακούει" για πακέτα σε µια συγκεκριµένη διεύθυνση που έχουν προορισµό την µονάδα µας, ενώ η διεργασία της αποµακρυσµένης σύνδεσης είναι υπεύθυνη για την σύνδεση µε µια αποµακρυσµένη µονάδα µέσω socket Υλοποίηση του µηχανισµού αλληλεπίδρασης Ο µηχανισµός υλοποίησης, αναπτύχθηκε σαν µια διεργασία του RT-Linux. Η επιλογή του λειτουργικού έγινε χωρίς βλάβη της γενικότητας, αφού µπορεί να υποστηρίξει προγράµµατα σε RT Java. Η εισαγωγή του και η φόρτωση του από τον πυρήνα του RT-Linux γίνεται µέσο της εντολής διαχείρισης module του Linux, την insmod. Στο ακόλουθο κοµµάτι κώδικα, δείχνεται µε ποιον τρόπο γίνεται η ενεργοποίηση και η εισαγωγή του µηχανισµού στον πυρήνα (µέσο της pthread_create). Επίσης, εδώ γίνεται και η αρχικοποίηση όλων των FIFO, µέσο της συνάρτησης rtf_create, που θα χρησιµοποιηθούν, τόσο στην επικοινωνία των real-time διεργασιών, όσο µεταξύ και τον µη-real-time. Εδώ φαίνεται επίσης και πώς αναθέτουµε χειριστές στις FIFO µέσο της συνάρτησης rtf_create_rt_handler. int init_module(void) { int c[10]; pthread_attr_t attr; struct sched_param sched_param; int ret, i; c[1] = rtf_create(lfp_fifo, 000);

60 ΑΡΤΙΟ Τελική έκθεση 60 c[] = rtf_create(rt_rfp_fifo, 000); c[3] = rtf_create(rt_cm_fifo, 000); c[5] = rtf_create(net_fifo, 4000); c[6] = rtf_create(nr_ip_fifo, 10000); c[8] = rtf_create(nr_profi_fifo, 10000); } pthread_attr_init (&attr); sched_param.sched_priority = ; pthread_attr_setschedparam (&attr, &sched_param); ret = pthread_create (&CM_task, &attr, thread_code, 0 ); rtf_create_rt_handler(rt_cm_fifo, &CMFIFO_handler); return 0; Το ακόλουθο τµήµα δείχνει τον handler που έχουµε χρησιµοποιήσει στην FIFO του µηχανισµού αλληλεπίδρασης. Αυτή η FIFO κατά κύριο λόγο δέχεται µηνύµατα από τα υπόλοιπα modules, και ευθύνη αυτού του χειριστή είναι ουσιαστικά να "ξυπνήσει" τον µηχανισµό όταν υπάρχουν διαθέσιµα δεδοµένα στην FIFO, ώστε να έρθει ο µηχανισµός και να τα διαβάσει. int CMFIFO_handler(unsigned int fifo) { if (lock_cm_fifo==1) return 0; #ifdef DEBUG rtl_printf(" CM_task..FIFOHANDLER...\n"); #endif pthread_wakeup_np (CM_task); return 0; } Τα modules εσωτερικά ανταλλάσσουν τις δοµές που έχουν τα ακόλουθα χαρακτηριστικά: struct artiogw_msg_struct { int command; int event_connection; int source; int dest; struct artio_item a_item; }; µε το command να σηµατοδοτεί τον τύπο του µηνύµατος, το event_connection να δείχνει το χαρακτηριστικό identifier της σύνδεσης, το source δείχνει το module που στέλνει το µήνυµα, το dest δείχνει το module προορισµού και το artio_item έχει την µορφή: struct artio_item { USIGN16 itemid; TYPE_ID typeid;

61 ΑΡΤΙΟ Τελική έκθεση 61 }; OCTET value[30]; όπου itemid είναι το χαρακτηριστικό identifier, το TypeID είναι ο τύπος της τιµής και το value είναι η ίδια η τιµή. Παραθέτουµε τώρα το ένα τµήµα από την διεργασία, η οποία δεν είναι περιοδική, αλλά "ξυπνάει" όταν της σταλθεί κάποιο µήνυµα. Όταν διαπιστωθεί µήνυµα στην FIFO, ο handler θα αναλάβει να ξυπνήσει την διεργασία, η οποία µέσο της rtf_get, λαµβάνει το µήνυµα και το δροµολογεί προς το αντίστοιχο module, µαζεύοντας την πληροφορία από τους πίνακες των ECTs και DCTs. void *thread_code(void *t) { struct artiogw_msg_struct msg; struct art_msg lmsg; int retval; while (1) { pthread_suspend_np(cm_task); lock_cm_fifo=1; while ( rtf_get(rt_cm_fifo, &msg, sizeof(msg))==sizeof(msg)){ #ifdef DEBUG rtl_printf("a command came to CM\n"); #endif lmsg.lmh.msgtype=msg_commech; if (msg.dest==srcrfp ){ lmsg.lmb.amsg=msg; retval = rtf_put ( RT_RFP_FIFO, &lmsg, sizeof(lmsg)); STRrtf_put(RT_RFP_FIFO, retval); }else if (msg.dest==srclfp ){ lmsg.lmb.amsg.a_item=msg.a_item; retval = rtf_put ( LFP_FIFO, &lmsg, sizeof(lmsg)); STRrtf_put(LFP_FIFO, retval); msg.dest); }else{ } rtl_printf("destination ID: %d, UNKNOWN\n",

62 ΑΡΤΙΟ Τελική έκθεση 6 }//while Υλοποίηση του Remote Fieldbus Proxy Παρακάτω δίνεται τµήµα της εφαρµογής που ασχολείται µε την λήψη και την αποστολή των αποµακρυσµένων µηνυµάτων. Η διεργασία εξετάζει τον header του µηνύµατος και προωθεί κατάλληλα το µήνυµα, είτε στον µηχανισµό αλληλεπίδρασης, είτε προς το module που θα αναλάβει την αποστολή του στο δίκτυο. while (1) { pthread_suspend_np(rfp_task); lock_rfp_fifo=1; while( rtf_get(rt_rfp_fifo,&artmsg,sizeof(artmsg))==sizeof(artmsg)){ if (artmsg.lmh.msgtype==msg_remote ){ the value msg.command = FB_EVENT_PRESENT; msg.event_connection=101010; msg.source=srcrfp; msg.dest=srclfp; msg.a_item = artmsg.lmb.armsg.a_item; //here is retval = rtf_put ( RT_CM_FIFO, &msg, sizeof(msg)); STRrtf_put(RT_CM_FIFO, retval); }else if (artmsg.lmh.msgtype==msg_commech ){ CM\n"); #ifdef DEBUG rtl_printf("a command came to RFP from #endif }//else }//while get from RFP_FIFO artmsg.lmh.msgtype= MSG_RFP; retval = rtf_put ( NET_FIFO, &artmsg, sizeof(artmsg)); STRrtf_put(NET_FIFO, retval); Υλοποίηση του Local Fieldbus Proxy Παρακάτω δίνεται τµήµα της εφαρµογής που ασχολείται µε την λήψη και την αποστολή των τοπικών µηνυµάτων. Η διεργασία εξετάζει τον header του µηνύµατος και το προωθεί είτε προς το µηχανισµό αλληλεπίδρασης αν προέρχεται από τον wrapper, είτε προς τον wrapper, αν έχει προέλθει από τα modules Control Application

63 ΑΡΤΙΟ Τελική έκθεση 63 ή Remote Fieldbus Proxy. Το πακέτο δροµολογείται προς το αντίστοιχο Function Block, το οποίο προσδιορίζεται από τον σχετικό identifier του event_connection. while (rtf_get(lfp_fifo,&lmsg,sizeof(lmsg)) == sizeof(lmsg)){ if (lmsg.lmh.msgtype==msg_commech ){ #ifdef DEBUG (MSG_COMMECH).\n"); rtl_printf("a command came to LFP #endif tempval = lmsg.lmb.amsg.a_item; sizeof(tempval)); retval = rtf_put ( NR_PROFI_FIFO, &tempval, STRrtf_put(NR_PROFI_FIFO, retval); (MSG_PROFI).\n"); } else if (lmsg.lmh.msgtype==msg_profi ) { #ifdef DEBUG rtl_printf("a command came to LFP #endif msg.command = FB_EVENT_PRESENT; msg.event_connection=101010; msg.source=srclfp; msg.dest=srcrfp; msg.a_item = lmsg.lmb.aitem; retval = rtf_put ( RT_CM_FIFO, &msg, sizeof(msg)); STRrtf_put(RT_CM_FIFO, retval); /***closes loop for LinuxApp only**/ //tempval = msg.a_item; sizeof(tempval)); //retval = rtf_put ( NR_PROFI_FIFO, &tempval, //STRrtf_put(NR_PROFI_FIFO, retval); /********************************/ } }//while rtf_get

64 ΑΡΤΙΟ Τελική έκθεση Υλοποίηση του Remote Fieldbus Proxy Εδώ δίνουµε ένα µικρό κοµµάτι που δείχνει πώς γίνεται το binding του thread που είναι υπεύθυνο στο να ακούει για πακέτα από αποµακρυσµένα δίκτυα. Ουσιαστικά, µετά την δηµιουργία του thread δηµιουργείται ένα binding σε Socket του συστήµατος και στην συνέχει "ακούει" για τυχόν πακέτα που θα έρθουν από το δίκτυο. Όταν ένα πακέτο είναι διαθέσιµο, τότε προωθείται προς το Net module. if(bind(server_sd, (struct sockaddr *) &servaddr, servaddrlen)<0) { fprintf(stderr, "Error Binding Socket... (ThreadServer)\n"); threaderror = ER_BIND_PORT; moveon = 0 ; close(server_sd); pthread_exit(&threaderror); perror("cannot bind port "); } if(listen(server_sd, 5)== 0 ){ printf("waiting for a connection on port: %u (ThreadServer)\n ",SERVER_PORT); timeout = ; while( timeout > 0){ timeout--; if (( timeout % ) == 0 ){ fprintf(stdout, "TimeOut in :%d\n", timeout); } cliaddrlen = sizeof(cliaddr); /**make accept non blocking*/ flags = fcntl(server_sd, F_GETFL,0); flags = fcntl(server_sd, F_SETFL, O_NONBLOCK flags); //fprintf(stdout, "Flags return: %d\n", flags); newsd = accept(server_sd, (struct sockaddr *) &cliaddr, &cliaddrlen); // printf ("newsd %d,",newsd); if( newsd > 0 ){ printf("connection Established... (ThreadServer)\n"); break; } if (timeout == 0 ){ threaderror = ER_TIMEOUT_CONNECTION; moveon = 0; printf("connection TimeOut... (ThreadServer)\n"); pthread_exit(&threaderror); }. Το ακόλουθο τµήµα δείχνει πώς στέλνουµε ένα πακέτο σε ένα αποµακρυσµένο δίκτυο. Ουσιαστικά, πρώτα γίνεται η σύνδεση µε το αποµακρυσµένο σύστηµα και κατόπιν χρησιµοποιούµε την κατασκευάσαµε την συνάρτηση SendPacket, για να στείλουµε το πακέτο.

65 ΑΡΤΙΟ Τελική έκθεση 65. rc = bind(client_sd, (struct sockaddr *) &localaddr, sizeof(localaddr)); if(rc < 0) { fprintf(stderr, "Error Binding Socket... (ThreadClient)\n"); threaderror = ER_BIND_PORT; moveon = 0 ; close(server_sd); perror("cannot bind port "); pthread_exit(&threaderror); } /* connect to server */ h = gethostbyname(host); if(h==null) { printf("unknown host %s exiting...(threadclient)\n",host); threaderror = ER_UNKNOWN_HOST; moveon = 0 ; pthread_exit(&threaderror); } servaddr.sin_family = h->h_addrtype; memcpy((char *) &servaddr.sin_addr.s_addr, h- >h_addr_list[0], h->h_length); servaddr.sin_port = htons(server_port); sizeof(servaddr)); rc = connect(client_sd, (struct sockaddr *) &servaddr,.. int SendPacket( struct artiogw_remote_msg_struct msg ) { int rec; int selectret; fd_set rfds; int size; struct timeval tv; tv.tv_sec = 0; tv.tv_usec = 10 ; FD_ZERO(&rfds); FD_SET(sd, &rfds); selectret = select(fd_setsize, NULL, &rfds, NULL, &tv); 5.7 Η λειτουργία του ESS Ο σχεδιασµός του ESS εργαλείου που υποστηρίζει την ανάπτυξη FB κατανεµηµένων εφαρµογών στηρίζεται στην αρχιτεκτονική 4 επιπέδων. Η συγκεκριµένη προσέγγιση

66 ΑΡΤΙΟ Τελική έκθεση 66 έχει χρησιµοποιηθεί για την προδιαγραφή απαιτήσεων ESS που πρέπει να επιτρέπει στον µηχανικό να: Εισαγάγει τις παραµέτρους βιοµηχανικής διαδικασίας στον χώρο εργασίας στο επίπεδο εφαρµογής, ώστε να καθοριστεί κατάλληλα η αλληλεπίδραση του συστήµατος Εισαγάγει τις συσκευές πεδίων στο επίπεδο συστήµατος. Ο µηχανικός συνδέει τις συσκευές πεδίων µε το κατάλληλο fieldbus στο πραγµατικό επίπεδο και χρησιµοποιεί τις προδιαγραφές των συσκευών για να δηµιουργήσει τις αναπαραστάσεις συσκευών (proxy συσκευών) στο επίπεδο συστήµατος Σχεδιάσει την εφαρµογή. Ο µηχανικός αναλύει τις φυσικές εγκαταστάσεις και χρησιµοποιεί FBs, τις συνδέσεις δεδοµένων και γεγονότων, καθώς επίσης και άλλες δοµές λογισµικού για να αναπαραστήσει τις βασικές έννοιες και λειτοθργίες του τοµέα εφαρµογής. Σχεδιάσει το σύστηµα. Ο µηχανικός κατανέµει φυσικά τις δοµικές µονάδες λογισµικού στις διαθέσιµες συσκευές πεδίων και fieldbuses. Ο διαχωρισµός, η ανάθεση και ο σχεδιασµός είναι µεταξύ των σηµαντικότερων στοιχειωδών εργασιών ελέγχει τη σωστή λειτουργία της εφαρµογής Κατεβάσει στη συσκευή τον πηγαίο κώδικα που υλοποιεί την εφαρµογή Τα υψηλότερα δύο επίπεδα της IPMCS αρχιτεκτονικής 4-επίπεδων πρέπει να ανατεθούν άµεσα στο επίπεδο συστήµατος και αυτή η ανάθεση πρέπει να είναι αόρατη στον µηχανικό. Οι αφηρηµένες αναπαραστάσεις του επιπέδου συστήµατος είναι υπό µορφή proxies των πραγµατικών αντικειµένων στον χώρο εργασίας. Ο αρµόδιος επεξεργαστής επιπέδου συστήµατος επιτρέπει στον µηχανικό να κατασκευάσει το σχέδιο του συστήµατος και να το αντιστοιχήσει άµεσα στο πραγµατικό επίπεδο. Ένα από τα µέσα που χρησιµοποιούνται για να υποστηρίξει µια τέτοια άµεση αντιστοίχηση είναι η προδιαγραφή συσκευών. Αυτή η προδιαγραφή πρέπει να είναι συµβατή µε ένα κοινό µοντέλο συσκευών και πρέπει να συνοδεύει την συσκευή σε µια µορφή αναγνωρίσιµη από χρήστη όπως αυτή που υλοποιείται χρησιµοποιώντας XML. Επιπλέον το ESS πρέπει να παράσχει όλη την λειτουργία που απαιτείται µε την διαδικασία κατανοµής FB s και ανάθεσης στις δοµικές µονάδες επιπέδου συστήµατος και κυρίως στις συσκευές πεδίων. Οι ενέργειες του ESS που δεν έχουν καµία έννοια στη φάση σχεδίου εφαρµογής, αλλά αναφέρονται στη διαµόρφωση του υποκείµενου υποσυστήµατος επικοινωνίας, πρέπει να κρυφτούν κατάλληλα µε µηχανισµούς κρυπτογράφησης και ενθυλάκωσης Εξετάζουµε στη συνέχεια το µέρος της λειτουργίας του ESS εργαλείου που καθορίζει τις προδιαγραφές συσκευών πεδίων. Οι ακόλουθες υπηρεσίες ESS εξετάζονται και αναλύονται: Πρόσθεσε συσκευή (Add Device) Σύνδεσε συσκευή (Connect Device) Πρόσθεσε FB (Add FB) Σύνδεσε FB (Connect FB) Θέσε Χρονικούς Περιορισµούς (Set Time Constraints) Aνάθεσε FB στη συσκευή (Assign FB to Device) Θέσε Παραµέτρους ιαµόρφωσης (Set Configuration Parameters) Κατέβασε FB στη συσκευή (Download FB)

67 ΑΡΤΙΟ Τελική έκθεση 67 A. Πρόσθεσε συσκευή (Add Device) Για να εισαχθεί µια συσκευή πεδίου στο σύστηµα IPMCS, ακολουθείται η παρακάτω διαδικασία. Ο µηχανικός, που εργάζεται στο πραγµατικό επίπεδο, συνδέει την συσκευή στο κατάλληλο fieldbus. Εισάγει έπειτα την προδιαγραφή συσκευών στη αποθήκη τύπων συσκευών, όπως φαίνεται στο επόµενο σχήµα. Αυτή η προδιαγραφή συσκευών, που συνοδεύει την συσκευή, είναι µια αναπαράσταση του µοντέλου συσκευών αναγνωρίσιµη από το χρήστη και δηµιουργείται από τον κατασκευαστή της συσκευής που χρησιµοποιεί ετικέτες XML συγκεκριµένες για κάθε εφαρµογή. Ο µηχανικός έχει τώρα άµεση πρόσβαση στη προδιαγραφή της συσκευής. Κατόπιν, οι τύποι FB που περιλαµβάνονται στη συσκευή, εισάγονται στη αποθήκη FB-τύπων του επιπέδου εφαρµογής. Αυτό απαιτείται για την προσπέλαση των FBs της συσκευής που χρησιµοποιούνται κατά τη διάρκεια κατασκευής του διαγράµµατος της FB εφαρµογής. Στο επίπεδο συστήµατος, ο σχεδιαστής χρησιµοποιεί το εικονίδιο συσκευής για να παρεµβάλει έναν κόµβο συσκευών στο διάγραµµα του συστήµατος. Αυτό είναι η οπτική αναπαράσταση της συσκευής και πρέπει να αντιστοιχεί στην πραγµατική συσκευή. Εάν η συσκευή είναι συµβατή µε το IEC61499, η XML αναπαράσταση της συσκευής χρησιµοποιείται από το ESS για να δηµιουργήσει αυτόµατα ένα proxy της συσκευής στην κατάλληλη µονάδα διαµεσολάβησης (Interworking Unit IU) και να υλοποιήσει αυτήν την ανάθεση. ιαφορετικά, εάν η συσκευή δεν είναι συµβατή µε το IEC61499 αλλά ο τύπος συσκευής υποστηρίζεται από το ESS, ο συσχετισµός εφαρµόζεται µε τη βοήθεια ενός περιτυλίγµατος (wrapper), το οποίο δηµιουργείται αυτόµατα από ESS. Ο wrapper διαµορφώνει τα χαρακτηριστικά της πραγµατικής συσκευής και παρέχει µια συσκευή συµβατή µε το IEC61499 που χρησιµοποιείται κατά τη διάρκεια της ανάπτυξης και της φάσης λειτουργίας. Το proxy ή o wrapper µπορεί να θεωρηθεί ως µια αναγνώσιµη από µηχανή αναπαράσταση της συσκευής µέσω της οποίας ο µηχανικός, προκειµένου να διαµορφωθεί η συσκευή, έχει άµεση πρόσβαση στις παραµέτρους και τις διαδικασίες της. Όπως εµφανίζεται στο Σχήµα 19, τα proxies των συσκευών δηµιουργούνται για τους κόµβους D1, D και D3 στα αντίστοιχα IUs. Αυτό είναι το τελευταίο βήµα για την εφαρµογή της οπτικής αναπαράστασης των συσκευών που αντιστοιχούν στις πραγµατικές συσκευές πεδίου.

68 ΑΡΤΙΟ Τελική έκθεση 68 ESS XML file FB1 FB3 Import FB Type FB4 {Time constraints} FB Add FB Application Layer Assign FB Type Repository IPT System Layer D1 IU FieldbusA DCT ECT FB4 FB Table D1 Device Proxy or Wrapper Backbone DCT ECT IU FB FB Table D3 D Fieldbus B node Add Device D3 D Device Proxy or Wrapper Device Type Repository Import Device Type Σχήµα 19. Χρήση του ESS στη διαδικασία ανάπτυξης εφαρµογής IPMCS Εξετάζουµε την διαδικασία προσπέλασης της πραγµατικής συσκευή µέσω του ESS, ως στοιχειώδη εργασία που εκτελείται σε δύο βήµατα. Σε πρώτη φάση, το ESS καλεί την απαραίτητη υπηρεσία του proxy ή wrapper της συσκευής, χρησιµοποιώντας το διαθέσιµο API. Στο δεύτερο βήµα, το proxy ή wrapper της συσκευής χρησιµοποιεί τον συγκεκριµένο µηχανισµό επικοινωνίας fieldbus, προκειµένου να µεταδοθεί το αίτηµα υπηρεσιών στη πραγµατική συσκευή. B. Σύνδεσε συσκευή (Connect Device) Εξετάζουµε δύο προσεγγίσεις για την σύνδεση µιας συσκευής µε την ελεγχόµενη βιοµηχανική διαδικασία. Αρχικά, σύµφωνα µε την από κάτω προς τα επάνω (bottomup) προσέγγιση, ο µηχανικός που εργάζεται στο πραγµατικό επίπεδο συνδέει τα σηµεία σύνδεσης συσκευών µε τις µετρηµένες ή ελεγχόµενες παραµέτρους της ελεγχόµενης βιοµηχανικής διαδικασίας. Στο επίπεδο συστήµατος, χρησιµοποιεί τον τερµατιστή βιοµηχανικής διαδικασίας (Industrial Process Terminator - IPT) για να αναπαραστήσει την πηγή ή τον προορισµό των µετρηµένων ή ελεγχόµενων παραµέτρων. Ένα τόξο, µεταξύ του σηµείου σύνδεσης των κόµβων και του IPT, αντιπροσωπεύει την πραγµατική φυσική σύνδεση σε αυτό το επίπεδο. Αφετέρου, σύµφωνα µε την από επάνω προς τα κάτω (top-down) προσέγγιση, ο µηχανικός που εργάζεται στο επίπεδο εφαρµογής χρησιµοποιεί τη δοµή IPT για να αναπαραστήσει στο FB διάγραµµα, την πηγή ή τον προορισµό της µετρηµένης ή ελεγχόµενης παραµέτρου. Ένα τόξο, που χρησιµοποιείται για να συνδέσει το IPT µε το κατάλληλο FB, φέρει τις πληροφορίες σχετικά µε την αντίστοιχη βιοµηχανική παράµετρο. Κάθε τόξο πρέπει να εφαρµοστεί στο πραγµατικό επίπεδο µετά από την ανάθεση του αντίστοιχου FB στη συσκευή στο επίπεδο συστήµατος. Το ESS πρέπει να εκτελέσει τους ελέγχους συµβατότητας σχετικά µε τον τύπο της εισόδου/εξόδου

69 ΑΡΤΙΟ Τελική έκθεση 69 του FB και των προδιαγραφών του σηµείου σύνδεσης της συσκευής. Η γνώση που απαιτείται από το ESS για να υποστηρίξει αυτήν την λειτουργία πρέπει να παρέχεται από την προδιαγραφή της συσκευής. Αυτή η γνώση περιλαµβάνει τον αριθµό σηµείων σύνδεσης ανά συσκευή, τον τύπο τους δηλ. αναλογικούς ή ψηφιακούς, τη σειρά, τις µονάδες, το ρυθµό µετάδοσής τους κ.λ.π. Γ. Πρόσθεσε FB (Add FB) Η λειτουργία που περιγράφεται από τις προδιαγραφές του συστήµατος αναλύεται σύµφωνα µε τη διαδικασία που αναφέρεται στο IEC Έτσι προκύπτει το σύνολο των τύπων FBs που απαιτούνται για να περιγράψουν τη λειτουργία του συστήµατος στο επίπεδο εφαρµογής. Σ αυτή τη φάση καθορίζονται επίσης οι τύπο δεδοµένων και το σύνολο γεγονότων που θα χρησιµοποιηθούν για τη σύνδεση των FBs. Στο επίπεδο της FB εφαρµογής εξάγεται η πληροφορία για τον καθορισµό των χρονικών περιορισµών (time constraints). Τα FBs εισάγονται στο FB διάγραµµα του επιπέδου εφαρµογής από τη βιβλιοθήκη FB. Οι τύποι των FBs µπορεί να είναι είτε προκαθορισµένοι είτε αν απαιτείται ένας νέος τύπος, ο σχεδιαστής έχει τη δυνατότητα να δηµιουργήσει ένα δικό του FB τύπο τον οποίο αργότερα κατά τη διάρκεια της διαδικασίας φορτώµατος αυτόµατα το εργαλείο θα µετατρέψει στην κατάλληλη περιγραφή και θα κατεβάσει στην πραγµατική συσκευή. Στην περίπτωση που έχουµε δεδοµένες πραγµατικές συσκευές και έχει εισαχθεί ο τύπος τους στη βιβλιοθήκη συσκευών όπως περιγράφηκε παραπάνω, εξετάζεται αν αυτές οι συσκευές υποστηρίζουν συγκεκριµένους τύπους FBs και ανάλογα ενηµερώνεται η βιβλιοθήκη FBs. Επίσης τα στιγµιότυπα αυτών των FBs, αν υπάρχουν, εισάγονται στο FB διάγραµµα του επιπέδου εφαρµογής.. Σύνδεσε FB (Connect FB) Τα FBs στο επίπεδο εφαρµογής συνδέονται µέσω των συνδέσεων γεγονότος ή δεδοµένων. Για κάθε δεδοµένο και γεγονός που έχει εξαχθεί κατά την ανάλυση της λειτουργίας του συστήµατος γίνεται ανάθεση στις εισόδους και εξόδους των FBs και υλοποιείται η αντίστοιχη σύνδεση. Τρεις περιπτώσεις συνδέσεων µπορούν να υλοποιηθούν: Σύνδεση δύο γεγονότων Σύνδεση δύο δεδοµένων Σύνδεση ενός γεγονότος µε µία παράµετρο της βιοµηχανικής διαδικασίας Σύνδεση ενός δεδοµένου µε µία παράµετρο της βιοµηχανικής διαδικασίας Οι χρονικοί περιορισµοί πρέπει να καθοριστούν και να περιληφθούν στο διάγραµµα FB. Ο µηχανικός πρέπει να λάβει υπόψη αυτούς τους περιορισµούς κατά τη διάρκεια του βήµατος της κατανοµής των FBs στο διάγραµµα συστήµατος. E. Θέσε Χρονικούς Περιορισµούς (Set Time Constraints) Με την υπηρεσία παρέχεται η δυνατότητα στο σχεδιαστή να θέσει χρονικούς περιορισµούς στις συνδέσεις δεδοµένων και γεγονότων των FBs. ιακρίνουµε δύο περιπτώσεις για τα χρονικά όρια: Χρονικός περιορισµός τίθεται µεταξύ ενός γεγονότος εισόδου και του αντίστοιχου γεγονότος εξόδου σε ένα FB. Σ αυτή την περίπτωση, το χρονικό όριο τίθεται στην ολοκλήρωση του αλγορίθµου που εκτελείται στο FB όταν εµφανιστεί το γεγονός εισόδου.

70 ΑΡΤΙΟ Τελική έκθεση 70 Χρονικός περιορισµός µεταξύ του γεγονότος εξόδου ενός FB και του γεγονότος ενός άλλου FB. Αυτή η περίπτωση αναφέρεται στην ανάθεση χρονικού ορίου σε επίπεδο σύνδεσης. Το εργαλείο πρέπει αυτόµατα να µετατρέπει αυτό το χρονικό περιορισµό σε όριο χρόνου για τις συνδέσεις δεδοµένων που ενεργοποιούνται κατά την παραγωγή του γεγονότος εξόδου. Αυτοί οι περιορισµοί χρησιµοποιούνται επίσης από το ESS που τους µεταφράζει σε προτεραιότητες, για τον καθορισµό των παραµέτρων χρονοπρογραµµατισµού (scheduling) αργότερα στη διαδικασία ανάπτυξης. ΣΤ. Aνάθεσε FB στη συσκευή (Assign FB to Device) Αυτή η υπηρεσία επιτρέπει την κατανοµή των FBs από το επίπεδο εφαρµογής στους πόρους (resources) του συστήµατος. Τα FBs ανατίθενται στις συσκευές του διαγράµµατος συστήµατος. Στο Σχήµα 19, απεικονίζουµε την ανάθεση FBs στις συσκευές στο επίπεδο συστήµατος. ιακρίνουµε τις ακόλουθες περιπτώσεις στη διαδικασία ανάθεσης: 1. Το κατεβασµένο FB συνδέεται µε ένα ή περισσότερα FBs στην ίδια συσκευή. Πρόκειται για την περίπτωση των FB1 και FB που ανατίθενται στη συσκευή D3. Εάν η συσκευή είναι συµβατή µε το IEC61499 η ανάθεση είναι απλή. Εντούτοις, εάν η συσκευή δεν είναι συµβατή, ο wrapper είναι αρµόδιος για να παράσχει την παραίσθηση µιας συσκευής IEC Το FB ανατίθεται στην πραγµατική συσκευή αλλά στην πραγµατικότητα φορτώνεται στον wrapper της, υπερφορτώνοντας το IU. Αυτή η περίπτωση είναι παρόµοια µε αυτήν κατωτέρω, όπου η εφαρµογή ελέγχου (Control Application CA) ελέγχου ανατίθεται στο IU.. Το κατεβασµένο FB συνδέεται µε ένα ή περισσότερα FBs που ανήκουν σε άλλες συσκευές στο ίδιο fieldbus. Πρόκειται για την περίπτωση των FB και FB3 που ανατίθενται στις συσκευές D3 και D αντίστοιχα. Το ESS πρέπει αυτόµατα να εφαρµόσει τις διασυνδέσεις µεταξύ αυτών των FBs πάνω από τους µηχανισµούς επικοινωνίας του fieldbus Β. 3. Το κατεβασµένο FB συνδέεται µε ένα ή περισσότερα FBs του CA που βρίσκεται στο IU ενός άλλου. Σε αυτήν την περίπτωση, που δεν εµφανίζεται στο Σχήµα 19, µέρος της λειτουργίας του συστήµατος ελέγχου ανατίθεται στο IU. Ο µηχανισµός διασύνδεσης IU s πρέπει να ενηµερωθεί από το ESS και οι µηχανισµοί επικοινωνίας µεταξύ των διαδικασιών του πρέπει να χρησιµοποιηθούν κατάλληλα για να εφαρµόσουν τις συνδέσεις 4. Το κατεβασµένο FB συνδέεται µε ένα ή περισσότερα FBs που βρίσκονται στις συσκευές άλλων fieldbuses. Πρόκειται για την περίπτωση των FB και FB4 που ανατίθενται στις συσκευές D3 και D1 αντίστοιχα. Ο µηχανισµός διασύνδεσης IU s πρέπει να ενηµερωθεί κατάλληλα από το ESS και ο µηχανισµός επικοινωνίας του Backbone πρέπει να χρησιµοποιηθεί διαφανώς για να εφαρµόσει τις συνδέσεις. Σύµφωνα µε την αρχιτεκτονική της IU που έχει ήδη δηµοδιευθεί, ο µηχανισµός διασύνδεσης του IU είναι βασισµένος σε ένα σύνολο πινάκων σύνδεσης (ECTs, DCTs), οι οποίοι κρατούν τις πληροφορίες για τις συνδέσεις δεδοµένων και γεγονότος που ξεπερνούν το όριο του fieldbus. Στις περιπτώσεις 3 και 4, αυτοί οι πίνακες σύνδεσης πρέπει να ενηµερωθούν αυτόµατα από το ESS, για να απαλλάξουν τον µηχανικό ελέγχου από τις λεπτοµέρειες µηχανισµών επικοινωνίας. Είναι εµφανές

71 ΑΡΤΙΟ Τελική έκθεση 71 ότι η ανάθεση ενός FB µπορεί να υπονοήσει περισσότερους του ενός των ανωτέρω περιπτώσεων των συνδέσεων. Κατά τη διάρκεια της ανάθεσης κάθε FB του διαγράµµατος εφαρµογής στις συσκευές του διαγράµµατος συστήµατος, οι έλεγχοι συµβατότητας πρέπει να εκτελεσθούν αυτόµατα και διαφανώς στον χρήστη. Ο κατάλληλος σχεδιασµός εκτέλεσης των FBs είναι απαραίτητος για να καλύψει τις απαιτήσεις κρίσιµου χρόνου που επιβάλλονται. Εποµένως, οι χρονικοί περιορισµοί και οι προτεραιότητες που ανατίθενται σε κάθε FB, θα χρησιµοποιηθούν από το ESS για τον καθορισµό του αλγόριθµου χρονοπρογραµµατισµού των FBs. Z. Θέσε Παραµέτρους ιαµόρφωσης (Set Configuration Parameters) Με την υπηρεσία αυτή ο σχεδιαστής έχει τη δυνατότητα να εφαρµόζει την πληροφορία των προδιαγραφών του συστήµατος που αναφέρονται στα στατικά χαρακτηριστικά της συσκευής όπως η διεύθυνση του σταθµού στο δίκτυο, το ρυθµό µετάδοσης κλπ. Το ESS εργαλείο καλεί την αντίστοιχη υπηρεσία του µοντέλου της συσκευής, το οποίο µε τη σειρά του εκκινεί τους κατάλληλους µηχανισµούς για το δεδοµένο δίκυο πεδίου. H. Κατέβασε FB στη συσκευή (Download FB) Αυτή η υπηρεσία χρησιµοποιείται για να κατεβάσει το FB διάγραµµα στο σύστηµα. Η υπηρεσία πρέπει να εκτελεσθεί αυτόµατα από το ESS, αφότου έχει ολοκληρωθεί επιτυχώς η ανάθεση των δοµών του FB διαγράµµατος στο επίπεδο συστήµατος. Για κάθε FB ή οµάδα FBs που ανατίθεται στην ίδια συσκευή, το ESS παράγει τον κατάλληλο κώδικα και τον φορτώνει στην αντίστοιχη πραγµατική συσκευή, µέσω του proxy ή του wrapper της. Ο απαραίτητος κώδικας και οι παράµετροι για κάθε σύνδεση επίσης αυτόµατα εφαρµόζονται και φορτώνονται στις αντίστοιχες πραγµατικές συσκευές. Πρέπει να διαπιστωθεί ότι ο wrapper µετατρέπει τους συγκεκριµένους µηχανισµούς επικοινωνίας που υποστηρίζονται από το fieldbus. 5.8 Χρήση της προδιαγραφής συσκευής στη διαδικασία ανάπτυξης ενός IPMCS Ένα IPMCS µπορεί να περιέχει ένα ή περισσότερα δικτύων πεδίου µε το διαφορετικό σχήµα στοιχείων, τις υπηρεσίες και άλλα χαρακτηριστικά γνωρίσµατα δικτύων. Στην τελευταία περίπτωση, η IU απαιτείται για να επιτρέψει την ενδοεπικοινωνία των δικτύων πεδίου. Το Fieldbus χρησιµοποιεί τις διασυνδεδεµένες συσκευές πεδίου για να έχει πρόσβαση στην βιοµηχανική διαδικασία. Η διαλειτουργικότητα είναι µια σηµαντική απαίτηση σε αυτά τα συστήµατα, όπου συσκευές διαφορετικών fieldbuses πρέπει να συνεργαστούν και χρειάζεται άρα να περιγράφουν τα παρόµοια χαρακτηριστικά τους σε ένα κοινό µοντέλο. Επιπλέον το ESS πρέπει να έχε πρόσβαση στις πληροφορίες για τη συσκευή όπως τις δυνατότητες, τις παραµέτρους και τη λειτουργία της. Τα proxies των συσκευών χρησιµοποιούνται στη IU για αυτόν τον λόγο. Το σχήµα των πληροφοριών που χρησιµοποιούνται στα proxies πρέπει να είναι τέτοια για να επιτρέψει την πρόσβαση σε κάθε συσκευή πεδίoυ ανεξάρτητα από το filedbus που ανήκει. Η χρήση του προτεινόµενου µοντέλου στην ανάπτυξη και τη φάση λειτουργίας του IPMCS, που παρουσιάζονται στο Σχήµα 0, δίνει µια λύση σε αυτήν την ανάγκη και την απαίτηση διαλειτουργικότητας. Κατά τη διάρκεια του κύκλου ζωής του IPMCS, οι διαφορετικές πτυχές της περιγραφής συσκευών θα χρησιµοποιηθούν. Ένας τρόπος είναι να καλυφθούν όλες αυτές οι πτυχές άµεσα από ένα µοντέλο. Μια άλλη προσέγγιση είναι να καθοριστεί ένα κοινό µοντέλο, από το

72 <!ATTLIST DataType > Organization CDATA #REQUIRED > <!ELEMENT ASN1Tag EMPTY> <!ELEMENT CompilerInfo (Compiler*)*> <!ATTLIST CompilerInfo > N etw or k Inter face - Devstatus : undefined - NodeAddress : undefined - Proto col : un d efine d - OperationM ode : undefined Process U nit 1..* + Co nfigure () + Init() + DN LFB() 1..* Industrial Process Interface 1..* Con nection Point - T ype : In p ut,o utp u t - Ana log : boole an - RangeSam plfreq : undefined - TimeForBroadcast : undefined Device - Se rialno : in te ge r + Se lft est(d evstatu s) + Chec kdeviceid( ) + Uniqu et a g() + SetDeviceTag() + GetDeviceTag() + S e t A d d r e ss( ) + G e t A d d r e ss( ) + Ge tstatu s() + Cle ara d dre ss() + Read Da ta() + WriteData() + Ge tfb T y p e() + SetConnection() + GetConnection() + Se tfb int ask() + Ne wda tat ype () + Ne wta sk() + Retrie vede fa ult Co nfig () + Re ad Ava ilab lef B() + re ad A ctivef B ( ) + SetUserConfig() + SetVendorConfig() + In itp a ra m () Device Type - Na m e : un de fine d 1..* User Defined Parameters - Nam e : unde fin ed - Value : und efin ed Re sources - ResourceID : undefined 1..* + S etid () + ConnectFB() + C re ate FB () + D elete FB () + StartFB() + StopFB() + C re ate Re sourc e() + D elete Re sourc e() + S ta rtre source() + S to pre source() Network Interface - Devstatus : undefined - NodeAddress : undefined - Protocol : undefined - OperationMode : undefined Device - SerialNo : integer + S elftest(dev status) + CheckDeviceID() + Uni quetag() + S etdevic etag() + GetDevi cetag() + S etaddress () + GetAddress() + GetStatus() + Cl eara ddress() + ReadData() + WriteData() + GetFBType() + SetConnection() Device Type - Name : undefi ned 1..* User Defined Parameters - Name : undefined - Val ue : undefi ned ΑΡΤΙΟ Τελική έκθεση 7 οποίο θα εξαχθουν υποσύνολα. Το προτεινόµενο µοντέλο χρησιµοποιεί τη δεύτερη προσέγγιση. Κατά τη διάρκεια του πρώτου βήµατος της φάσης ανάπτυξης της εφαρµογής, ο µηχανικός σχεδιάζει µε τη βοήθεια του ESS, τηn εφαρµογή από την άποψη των FB διαγραµµάτων και της αρχιτεκτονικής συστηµάτων. Η εφαρµογή πρέπει να αντιστοιχηθεί στη αρχιτεκτονική συστήµατος. Για να εκτελέσει αυτήν την αντιστοίχηση, ο σχεδιαστής πρέπει να µεταφέρει το FB διάγραµµα στο µοντέλο συστήµατος και να αναθέσει τα FBs στις συσκευές. Εποµένως, πρέπει να παραγάγει τις πληροφορίες σχετικά µε την συσκευή. Αυτές οι πληροφορίες είναι δοµηµένες βάσει του προτεινόµενου µοντέλου συσκευής και συµπεριλαµβάνονται σε ένα αρχείο, το οποίο παρέχεται από τον κατασκευαστή και συνοδεύει την συσκευή. Η περιγραφή συσκευής στο αρχείο αντιπροσωπεύεται µε µια µορφή αναγνώσιµο από το χρήστη (XML) και είναι βασισµένη στο προτεινόµενο µοντέλο συσκευής πεδίου. Κατά το δεύτερο βήµα της φάσης σχεδίασης, αφού έχει γίνει η ανάθεση των FBs στις συσκευές του συστήµατος, η λειτουργία που αναπαριστούν τα FBs πρέπει να φορτωθεί στη συσκευή. Η αναπαράσταση της πληροφορίας πρέπει να µετατραπεί σε µορφή αναγνωρίσιµη από τη µηχανή. Application Development Phase User Level <?xml version="1.0" encoding="utf-8"?> <!ELEMENT DataType (Identification?,VersionInfo+,CompilerInfo?,ASN1Tag?,(DirectlyDerivedType EnumeratedType SubrangeType ArrayType StructuredType))> Name CDATA #REQUIRED Comment CDATA #IMPLIED <!ELEMENT VersionInfo EMPTY> <!ATTLIST VersionInfo Version CDATA #REQUIRED Author CDATA #REQUIRED Date CDATA #REQUIRED Remarks CDATA #IMPLIED <!ATTLIST ASN1Tag Class (UNIVERSAL APPLICATION CONTEXT PRIVATE) #IMPLIED Number CDATA #REQUIRED > header CDATA #IMPLIED classdef CDATA #IMPLIED Engineering Tool Electronic Device Description in XML Engineering Tool (Compiling) Machine Level Refined Device model Machine-readable representation Device Proxy Engineering Tool (Optimisation) Run-time Phase System Level Subgroup of Refined Field device model Σχήµα 0. Χρήση του µοντέλου συσκευής κατά τη φάση ανάπτυξης και λειτουργίας της εφαρµογής

73 ΑΡΤΙΟ Τελική έκθεση Το προτεινόµενο µοντέλο συσκευής Α. Μοντέλο συσκευής για το ESS εργαλείο Η ανωτέρω ανάλυση λειτουργίας του ESS εργαλείου προσθέτει γνώση στο µοντέλο συσκευών που έχουµε δηµιουργήσει για να υποστηρίξουµε τη διαλειτουργικότητα συσκευών στη φάση λειτουργίας. Το µοντέλο µας επεκτάθηκε για να υποστηρίξει και την ανάπτυξη και τη φάση λειτουργίας µιας εφαρµογής IPMCS. Στο Σχήµα 1, παρουσιάζουµε µέρος αυτού του µοντέλου που κατασκευάστηκε χρησιµοποιώντας την σηµειωγραφεία UML και το Rational RT-Rose case εργαλείο. Σύµφωνα µε αυτό, µια συσκευή είναι ενός συγκεκριµένου τύπου και θεωρείται ως συνάθροιση µιας µονάδας διεπαφών δικτύων (Network Interface Unit - NIU), ενός ή περισσότερων στοιχείων συµπεριφοράς, µιας µονάδας διεπαφών βιοµηχανικής διαδικασίας (Industrial Process Interface Unit - IPU) και µιας ενότητας διοίκησης εφαρµογής (Application Management Entity - AME). Για τον προσδιορισµό συσκευών παρέχεται ένα συνόλου ιδιοτήτων όπως ο αύξων αριθµός της συσκευής, η ταυτότητα της συσκευής στο σύστηµα, η διεύθυνση της συσκευής στο fieldbus, ο τύπος της συσκευής. Μαζί µε αυτές τις ιδιότητες παρέχεται και ένα σύνολο διαδικασιών όπως Identify, UniqueTag, SetDeviceTag and GetDeviceTag. Αυτές οι τέσσερις µέθοδοι παρέχονται από την κλάση συσκευών και επιτρέπουν στον σχεδιαστή να προσδιορίσει την συσκευή, καθώς επίσης και να έχει µια µοναδική αναφορά σε αυτήν. Η κλάση IPU χρησιµοποιείται για να αντιπροσωπεύσει τον µηχανισµό διεπαφών για την σύνδεση των συσκευών στα IPTs. Αυτή η διεπαφή περιλαµβάνει διάφορα σηµεία σύνδεσης, εκ των οποίων το καθένα καθορίζεται για να έχει τις ιδιότητες που καλύπτουν τις απαιτήσεις της Connect Device λειτουργίας της κλάσης ESS που αντιπροσωπεύει το εργαλείο µηχανικού στο διάγραµµα κλάσης. Τέτοιες ιδιότητες είναι: ο τύπος, ο οποίος θα ήταν αναλογικός ή ψηφιακός και η κατεύθυνση, η οποία θα είναι είσοδος ή έξοδος. Κάθε παράµετρος βιοµηχανικής διαδικασίας µπορεί να συνδεθεί µε ένα ή περισσότερα σηµεία σύνδεσης. Τα σηµεία σύνδεσης µπορούν να συνδεθούν µε ένα ή περισσότερα FBs µέσα στη συσκευή. Γνωρίζοντας τους τύπους σηµείου σύνδεσης της συσκευής, ο µηχανικός µπορεί να αποφασίσει εάν τα FBs προς φόρτωση ταιριάζουν µε τις ικανότητες συσκευών. Η κλάση NIU χρησιµοποιείται για να αντιπροσωπεύσει τους µηχανισµούς διευθυνσιοδότησης και επικοινωνίας που απαιτούνται για τον χειρισµό της συσκευής από το δίκτυο. Οι υπηρεσίες επικοινωνίας, όπως αυτές που καθορίζονται στη κλάση διεπαφών δικτύων, εξετάζονται αναλογικά προς τις υπηρεσίες του εκάστοτε χρησιµοποιούµενου δικτύου. Εκτός από τις σχετικές µε το δίκτυο ιδιότητες που είναι σηµαντικές για την διαχείριση συσκευών, ένας µηχανισµός επέκτασης παρέχεται για την αναπαράσταση των πρόσθετων χαρακτηριστικών, τα οποία διαφοροποιούν ένα fieldbus από άλλο. Το µοντέλο συσκευής µπορεί να θεωρηθεί ως ένα µεταµοντέλο του οποίου, το εκάστοτε µοντέλο συσκευής θα αποτελούσε στιγµιότυπο. Μέσω της κλάσης παραµέτρων καθορισµένων από το χρήστη (User Defined Parameter), ο χρήστης είναι σε θέση να καθορίσει τις συγκεκριµένες ιδιότητες συσκευών που έχουν έννοια µόνο για τον συγκεκριµένο τύπο fieldbus και δεν συλλαµβάνονται από την συσκευή metamodel. Αυτή η κλάση καλύπτει την απαίτηση, που επιβάλλεται από την ανάλυση της Add Device υπηρεσίας του ESS, για τις ιδιαίτερες ιδιότητες που ένας wrapper πρέπει να έχει. Παραδείγµατος χάριν, το Lonworks καθορίζει δικτυακούς τοµείς και

74 ΑΡΤΙΟ Τελική έκθεση 74 υποδίκτυα για την δοµή του fieldbus. Αυτά οι έννοιες δεν υπάρχουν σε Profibus αλλά πρέπει να υποστηριχθούν από το µοντέλο συσκευών για την περιγραφή των συσκευών Lonworks. Για λόγους ευχρηστίας, οι συγκεκριµένες παράµετροι κάθε τύπου fieldbus περιγράφονται από τον τύπο της συσκευής και παρέχονται έτσι αυτόµατα από το µοντέλο. Η κλάση Πόρος (Resource) χρησιµοποιείται για να αντιπροσωπεύσει τις µονάδες επεξεργασίας της συσκευής. Ένας πόρος, όπως καθορίζεται στο IEC61499, είναι µια λειτουργική µονάδα, η οποία έχει ανεξάρτητο έλεγχο λειτουργίας και παρέχει διάφορες υπηρεσίες στις εφαρµογές, συµπεριλαµβανοµένου του σχεδιασµού και της εκτέλεσης των αλγορίθµων. Προκειµένου να αντιµετωπιστεί η συµπεριφορά συσκευών όσον αφορά σε NIU, MPU, IPU, µια οµάδα µεθόδων διαµόρφωσης πρέπει να παρέχεται. Αυτοί αποτελούν το δεύτερο τετράδυµο των διαδικασιών στην κλάση συσκευής. Αυτές οι διαδικασίες µαζί µε την κλάση AME διαµορφώνουν την διοικητική οµάδα που είναι για τον χειρισµό FB και των πόρων. Για τον προσδιορισµό των απαιτήσεων που επιβάλλονται από την Assign FB υπηρεσία του ESS, η κλάση φραγµών λειτουργίας περιέχει ιδιότητες όπως η προτεραιότητα και ο χρονικός περιορισµός. Αυτές οι ιδιότητες τίθενται κατά τη διάρκεια της εκτέλεσης της FB connection υπηρεσίας του ESS, βάσει των χρονικών περιορισµών που καθορίζονται στα διαγράµµατα επιπέδου εφαρµογής. Ένα FB µπορεί να προκαθοριστεί ή να φορτωθεί, ανάλογα µε το εάν περιλαµβάνεται στη συσκευή από τον κατασκευαστή ή αν καθορίζεται από τον σχεδιαστή κατά τη διάρκεια της φάσης ανάπτυξης της εφαρµογής, αντίστοιχα. Το FB είναι ενός συγκεκριµένου τύπου, ο οποίος είτε εισάγεται στη βιβλιοθήκη τύπων FB, όταν προστίθεται µια νέα συσκευή στο διάγραµµα επιπέδου συστήµατος ή καθορίζεται από τον σχεδιαστή. Τα ESS και οι κλάσεις FB παρέχουν τις υπηρεσίες για την δηµιουργία, τη διαγραφή ή τη φόρτωση FBs. Οι έλεγχοι συµβατότητας στο φορτωµένο FBs και την συσκευή πρέπει να υποστηριχθούν από το ESS και διευκολύνονται από τις δύο τελευταίες self-test διαδικασίες της κλάσης συσκευών. Αυτοί οι έλεγχοι εφαρµόζονται για τη συµβατότητα των σηµείων σύνδεσης και των συνδέσεων FB.

75 ΑΡΤΙΟ Τελική έκθεση 75 Resource ResourceID : undefined Configure() Init() SetResourceID() StartResource() StopResource() SetFBinRes() Application Management Entity ScheduleFB() CreateFB() DeleteFB() StartFB(FBHandle) StopFB(FBHandle) Device Type Name : undefined 1..* User Defined Parameter Name : undefined Value : undefined Slave : undefined Domain : undefined Subnet : undefined SetParameterValue() Network Interface NodeAddress : undefined Protocol : undefined OperationMode : undefined GetAd dress () SetAddress() ClearAddress() ESS AddDevice () DeleteDevice() AddFB() DeleteFB() ConnectDevice() ConnectFB() AssignFB() DnlFB() SetCo nfigurationprms() SetTimeConstraints() Device SerialNo : integer 1..* DeviceID : undefined Type : boolean SetDeviceTag() RetrieveDefaultConfig() ReadAvailableFB() SetUs erconfig() SetVendorConfig() New FB(FB type, data, event) Establish Event connection(fbout, FBin, output event, input event) Establish Data Connection(FBout, FBin, output data, input data) Set IPT Connection(FB Handle, input data/event, IPT entry) Set Time Bound(Connection Handle, Time constraint) Download FB(FB Handle) Set User Defined Parameters(Parameter Name, Value) 1..* Industrial Process Interface 1..* ConnectionPoint Type : undefined Input/Output ID(No) : unefined RangeSamplFreq : undefined TimeForBroadcast : undefined Connection source : un defined Destination : und efined TimingConstraints : undefined SetConnection() GetConnection() SetTimeBo und() Event Type Item AvTrRate : undefined MaxTrRate : undefined Polling : boolean PacketLength : Integer FB Type DataType EventConnection Event Item Type : undefined SetActiveLevel() Downloaded FB name CheckCompatibility() Function Block pri ority : unde fined Schedul ingturn : undefined FBID : undefined Assign(Device ID) SetSchedulin g() SetTimeBound(EventIn, Eve ntout) Start() Stop() GetFBType() Predefined FB Data Item range : undefin ed units : undefined DeviceID : undefined DataConnnection NoConPoint : undefined InitData() SetRange() SetOffs et() SetAlarmLevel() SetWarningLevel() Σχήµα 1. Μέρος του µοντέλου συσκευής για χρήση από το ESS εργαλείο κατά τη φάση σχεδιασµού Οι συνδέσεις µεταξύ FBs καθορίζονται µε τη βοήθεια της πηγής και του προορισµού της σύνδεσης. Μια σύνδεση µπορεί να είναι µια σύνδεση δεδοµένων ή µια σύνδεση γεγονότος, αν το σχετικό αντικείµενο είναι δεδοµένο ή γεγονός αντίστοιχα. Όπως επισηµαίνεται νωρίτερα στην ανάλυση της Connect FB υπηρεσίας του ESS, ο µηχανισµός επικοινωνίας και οι χρονικοί περιορισµοί διαδραµατίζουν έναν σηµαντικό ρόλο κατά τη διάρκεια της αυτόµατης εφαρµογής των συνδέσεων για την επίτευξη των απαραίτητων χρόνων. Η επιλογή του µηχανισµού επικοινωνίας της σύνδεσης FB αφήνεται στον µηχανικό. Τέλος, αναφέρουµε τις υπηρεσίες που πρέπει να παρέχει το µοντέλο συσκευής, οι οποίες θα καλούνται από τις αντίστοιχες υπηρεσίες του ESS εργαλείου: Θέσε παραµέτρους της συσκευής (Set device parameters) Η υπηρεσία αυτή καλείται κατά την εκτέλεση των υπηρεσιών Connect device και Set Configuration Parameters του ESS εργαλείου. έχεται ως παραµέτρους το όνοµα και την τιµή που πρέπει να τεθεί στην αντίστοιχη παράµετρο του µοντέλου συσκευής. Φόρτωσε FB (Download FB) Η υπηρεσία αυτή καλείται κατά την εκτέλεση της υπηρεσίας Add FB του ESS εργαλείου. έχεται ως παράµετρο µια αναφορά στον τύπο FB του οποίου στιγµιότυπο πρέπει να µετατρέψει σε κώδικα µηχανής και να φορτώσει στη συσκευή. Επιστρέφει µια αναφορά στο στιγµιότυπο του FB που δηµιουργήθηκε.

76 ΑΡΤΙΟ Τελική έκθεση 76 Σ αυτό το σηµείο πρέπει να αναφέρουµε ότι θεωρούµε ότι η IU διαθέτει την υπηρεσία Update table. Η υπηρεσία αυτή καλείται κατά την εκτέλεση της υπηρεσίας Assign FB του ESS εργαλείου, όταν το FB που ανατίθεται συνδέεται µε FBs της συσκευής ενός άλλου δικτύου πεδίου. έχεται ως παραµέτρους µια αναφορά στο γεγονός και τα δεδοµένα που αντιστοιχούν σε αυτό και ενηµερώνει τους πίνακες ECT και DCT. Εγκατάστησε σύνδεση γεγονότος (Establish event connection) Η υπηρεσία αυτή καλείται κατά την εκτέλεση της υπηρεσίας Assign FB του ESS εργαλείου. έχεται ως παραµέτρους µια αναφορά στο στιγµιότυπο του FB εισόδου, το γεγονός εξόδου αυτού του FB, µια αναφορά στο στιγµιότυπο του FB εξόδου και το γεγονός εισόδου αυτού του FB. Επιστρέφει µια αναφορά στη σύνδεση που δηµιουργήθηκε. Εγκατάστησε σύνδεση δεδοµένων (Establish data connection) Η υπηρεσία αυτή καλείται κατά την εκτέλεση της υπηρεσίας Assign FB του ESS εργαλείου. έχεται ως παραµέτρους µια αναφορά στο στιγµιότυπο του FB εισόδου, το δεδοµένο εξόδου αυτού του FB, µια αναφορά στο στιγµιότυπο του FB εξόδου και το δεδοµένο εισόδου αυτού του FB. Επιστρέφει µια αναφορά στη σύνδεση που δηµιουργήθηκε. Θέσε IPT σύνδεση (Set IPT connection)(fb handle, input data/event, IPT entry) Η υπηρεσία αυτή καλείται κατά την εκτέλεση της υπηρεσίας Assign FB του ESS εργαλείου. έχεται ως παραµέτρους µια αναφορά στο στιγµιότυπο του FB εισόδου, το δεδοµένο ή γεγονός εισόδου αυτού του FB, και την παράµετρο της βιοµηχανικής διαδικασίας που πρέπει να συνδεθεί. Επιστρέφει µια αναφορά στη σύνδεση που δηµιουργήθηκε. Θέσε Χρονικό Περιορισµό (Set Time Bound) Η υπηρεσία αυτή καλείται κατά την εκτέλεση της υπηρεσίας Set Time Constraints του ESS εργαλείου. Ανάλογα µε την περίπτωση σύνδεσης που έχει αναφερθεί πιο πάνω, δέχεται ως παραµέτρους µια αναφορά στη σύνδεση που πρέπει να τεθεί ο χρονικός περιορισµός και την τιµή του τελευταίου ή µια αναφορά στο στιγµιότυπο FB, το γεγονός εισόδου, το γεγονός εξόδου και την τιµή του χρονικού περιορισµού. Β. Μοντέλο συσκευής κατά τη φάση λειτουργίας Στις υπάρχουσες συσκευές, δεν υπάρχει δυνατότητα επέµβασης εσωτερικό στη συσκευή και να γίνει αλλαγή στον αλγόριθµο λειτουργίας. Οι υπηρεσίες που πρέπει να παρέχονται είναι: Η δυνατότητα αναγνώρισης της συσκευής για λόγους συντήρησης του δικτύου (Identify). Η δυνατότητα ελέγχου από την ίδια τη συσκευή (Self-test). Η δυνατότητα ανάγνωσης της διαµόρφωσης της συσκευής (Get Configuration). Επιπλέον απαιτείται η εγγραφή δεδοµένων από ένα IU σε ένα άλλο. Γι αυτόν τον σκοπό παρέχεται η υπηρεσία Write µε παραµέτρους την αναφορά στο στιγµιότυπο του FB, το γεγονός εισόδου και τα δεδοµένα που πρόκειται να γραφούν αν υπάρχουν. Στο επόµενο σχήµα φαίνεται το υποσύνολο του µοντέλου συσκευής που χρησιµοποιείται από το IU κατά τη φάση λειτουργίας. Εδώ έχουν προστεθεί οι παραπάνω υπηρεσίες στο µοντέλο καθώς και οι αντίστοιχες παράµετροι στις απαραίτητες κλάσεις.

77 ΑΡΤΙΟ Τελική έκθεση 77 Connection source : undefined Destination : undefined TimingConstraints : undefined Resource ResourceID : undefined GetConnection() GetTimeBound() EventConnection Event Item Application Management Entity StartResource() StopResource() Event Type Type : undefined GetFBinRes() SetActiveLevel() ScheduleFB() CreateFB() DeleteFB() StartFB(FBHandle) StopFB(FBHandle) 1..* Downloaded FB name Device CheckCom patibility( ) SerialNo : integer Device Type Name : undefined DeviceID : undefined Type : boolean Identify() UniqueTag() Item AvTrRate : undefined MaxTrRate : undefined Polling : boolean Function Block priority : undefined SchedulingTurn : undefined FBID : undefined 1..* User Defined Parameter SelfTest(Devstatus) Read Data(FB Handle, Data index) Write Data(FB Handle, Data index) FB Type Start() Stop() GetFBType() Name : undefined Value : undefined 1..* Predefined FB Slave : undefined Industrial Process Interface Domain : undefined Subnet : undefined Network Interface NodeAddress : undefined GetParameterValue() Protocol : undefined OperationMode : undefined 1..* ConnectionPoint GetAddress() Type : undefined Input/Output ID(No) : unefined Data Item RangeSamplFreq : undefined TimeForBroadcast : undefined DataType range : undefined units : undefined NoConPoint : undefined DataConnnection read() write() Σχήµα. Μέρος του µοντέλου συσκευής για χρήση κατά τη φάση λειτουργίας

78 ΑΡΤΙΟ Τελική έκθεση 78 6 ιασύνδεση του Profibus και Lonworks στην προτεινόµενη αρχιτεκτονική 6.1 Τοπολογία ιασύνδεσης των Βιοµηχανικών ικτύων Η ενότητα αυτή περιλαµβάνει την διερεύνηση των τοπολογιών διασύνδεσης των ετερογενών δικτύων πεδίου, λαµβάνοντας υπ όψιν την απαίτηση της απόκρισης σε πραγµατικό χρόνο (real-time path). Αξιολογήθηκε ένας αριθµός εναλλακτικών τοπολογιών και τελικά κρίθηκαν σαν άµεσα αξιοποιήσιµες δύο από αυτές, οι οποίες βασίζονται στις τεχνολογίες Fast Switched Ethernet και ATM Τεχνολογία Fast Switched Ethernet Μία από τις προτεινόµενες τοπολογίες διασύνδεσης είναι αυτή του Switched Fast Ethernet µε υποστήριξη µηχανισµών προτεραιότητας κίνησης (IEEE 80.1p). Αυτή βασίζεται στο "µαρκάρισµα" των πακέτων/πλαισίων στο ο επίπεδο (MAC Layer). H επιλογή αυτή αποτελεί µια οικονοµική λύση που µπορεί να καλύψει τεχνικά τις προδιαγραφές για µεταφορά δεδοµένων µεταξύ των δυο δικτύων πεδίου σε πραγµατικό χρόνο. Η χρησιµοποίηση ενός 100 Mbps Fast Ethernet Switch (µε υποστήριξη του ΙΕΕΕ 80.1p) επιτρέπει τον χαρακτηρισµό των εισερχοµένων πακέτων µε οκτώ διαφορετικά επίπεδα προτεραιότητας (0-7). Τα πακέτα µε προτεραιότητες 0-3 τοποθετούνται σε µια ουρά χαµηλής προτεραιότητας (low queue-default), ενώ τα πακέτα µε 4-7 σε ουρά υψηλής προτεραιότητας (high queue). Απαιτείται ο χαρακτηρισµός των πακέτων που προορίζονται από το ένα δίκτυο πεδίου στο άλλο και αντίστροφα, ως υψηλής προτεραιότητας. Αυτή η διαδικασία γίνεται στο configuration των Fast Ethernet καρτών (adapters) που βρίσκονται στα Linux µηχανήµατα, τα οποία έχουν τον ρόλο των ΑΡΤΙΟ Gateways. Eαν το πακέτο δεν έχει χαρακτηριστεί (untagged) ο διακόπτης αποφασίζει για την προτεραιότητα του. Eπίσης επιτρέπεται να δοθεί και προτεραιότητα (low-high) σε κάθε switch port. Ετσι, µε τις κατάλληλες ρυθµίσεις επιτυγχάνουµε την µετάδοση δεδοµένων κατά προτεραιότητα µεταξύ των δυο δικτύων πεδίου. Αντίθετα, τα δεδοµένα configuration και monitoring, που κατευθύνονται προς το υπάρχον LAN, είναι χαµηλής προτεραιότητας (default). H επιλογή της τεχνολογίας αυτής και η αναζήτηση των εµπορικών λύσεων, οδήγησε στην αγορά ενός διακόπτη και ανάλογου αριθµού καρτών. Αναλυτικότερα, αγοράστηκε ο ακόλουθος εξοπλισµός :

79 ΑΡΤΙΟ Τελική έκθεση 79 Κωδικός παραγγελίας ES410T16 Πίνακας. ικτυακός εξοπλισµός Eίδος Περιγραφή Tεµάχια Intel Express 410Τ 16-ports Fast Ethernet Switch µε ΙΕΕΕ 80.1p 1 PILA8460C3 Intel PRO/100 S Desktop Adapter 100 Μbps PCI adapter µε ΙΕΕΕ 80.1p 3 Ο Switched Fast Ethernet διακόπτης διαθέτει θύρες που ανιχνεύουν την προτεραιότητα (IEEE 80.1p tagging) στη κίνηση και προωθεί άµεσα τα δεδοµένα από το ένα βιοµηχανικό δίκτυο στο άλλο. Επίσης διαθέτει δυνατότητα σύνδεσης 10/100 Mbps καρτών Shared ή Switched Ethernet και δυνατότητα σύνδεσης µε απλό Hub. Ετσι, δεν απαιτείται ειδικό 10/100 Mbps module, µιας και το υπάρχον δίκτυο (configuration και monitoring) συνδέεται απευθείας στο switch. Configuration Monitoring 10 Mbps Shared Ethernet 100 Mbps Switched Ethernet (RJ-45) Intel Express 410Τ real-time path FieldBus A APTIO GATEWAY A (100 Mbps Switched Ethernet adapter Intel PRO/100 S - Linux) APTIO GATEWAY B (100 Mbps Shared Ethernet adapter Intel PRO/100 S - Linux) FieldBus B Σχήµα 3. Τοπολογία δικτύου Ρύθµιση - Εγκατάσταση - οκιµές διακόπτη και καρτών O διακόπτης προγραµµατίστηκε µέσω σύνδεσης από την σειριακή θύρα στο Local Management που παρέχει. Οι παράµετροι σύνδεσης (VT-100) είναι οι ακόλουθοι:

80 ΑΡΤΙΟ Τελική έκθεση 80 Σχήµα 4. Παράµετροι σύνδεσης στο Local Management του Intel Express 410T Στη συνέχεια, στο µενού ρυθµίστηκαν οι θύρες και 3 ώστε να συνδεθούνε τα ΑΡΤΙΟ gateways και ενεργοποιήθηκε η δυνατότητα ελέγχου της προτεραιότητας της κίνησης. Στη θύρα 4 συνδέθηκε το υπάρχον δίκτυο. Σχήµα 5. Ρυθµίσεις του διακόπτη Eκτός του διακόπτη, εγκαταστάθηκαν σε Linux περιβάλλον οι κάρτες (adapters) µέσω των οποίων τα ΑΡΤΙΟ Gateways στέλνουν τα δεδοµένα (IP κίνηση) στο δίκτυο. Οι κάρτες συνοδεύονται από λογισµικό εγκατάστασης και πλήρη εγχειρίδια χρήσης, πράγµα που έκανε την εγκατάσταση τους πλήρως ικανοποιητική και σύµφωνη µε τις απαιτούµενες προδιαγραφές.

81 ΑΡΤΙΟ Τελική έκθεση 81 Σχήµα 6. Εγκατάσταση των καρτών στα ATPIO Gateways Σχήµα 7. Ρύθµιση της προτεραιότητας κίνησης Από την εγκατάσταση και ρύθµιση του διακόπτη Intel Express 410T µέσω της RS- 3 (π.χ. Hyperterminal) και των Ethernet καρτών Ιntel PRO/100S σε λειτουργικό σύστηµα Linux, η ροή των δεδοµένων πραγµατικού χρόνου από το ένα δίκτυο στο άλλο, καλύπτει πλήρως τις προδιαγραφές πραγµατικού χρόνου που τέθηκαν. Τα δεδοµένα αυτά, έχοντας "µαρκαριστεί" ώς υψηλής προτεραιότητας (4-7) έναντι των άλλων (default) προωθούνται ταχύτατα από τον διακόπτη, ο οποίος ανιχνεύει το IEEE 80.1p tagging, και έτσι δεν παρατηρείται καµία καθυστέρηση. Αντίθετα τα δεδοµένα προς το υπόλοιπο δίκτυο για monitoring και configuration, όταν υπάρχει κίνηση παραµένουν στην ουρά του διακόπτη µέχρι να εξυπηρετηθούν. Ολοκληρώνοντας, καταλήγουµε στο συµπέρασµα ότι οι παραπάνω επιλογές εξοπλισµού, σε συνδυασµό

82 ΑΡΤΙΟ Τελική έκθεση 8 µε τις κατάλληλες ρυθµίσεις, απέδωσαν το επιθυµητό αποτέλεσµα, εξασφαλίζοντας ένα real-time path από το ένα δίκτυο πεδίου στο άλλο και αντίστροφα Η Τεχνολογία ΑΤΜ Η τοπολογία διασύνδεσης µε χρήση ΑΤΜ switch φαίνεται στο επόµενο σχήµα. Στο σχήµα αυτό φαίνεται ότι το δίκτυο ΑΤΜ χρησιµοποιήθηκε σαν µέσο διασύνδεσης των µονάδων. Οι µονάδες είναι εξοπλισµένες µε κάρτες δικτύου Turboways 5 Mbps της IBM και συνδέονται στο IBM 885 ATM switch. Το switch υποστηρίζει στάνταρ όπως LAN Emulation ή IP over ATM, ATM UNI Specification V3.0 και V3.1. Επίσης παρέχει πλήρη υποστήριξη ATM Quality of Service (QoS) και PNNI-1. Παράλληλα, εκτός των δύο µονάδων διασύνδεσης (µέσω των οποίων διασυνδέονται τα δύο δίκτυα πεδίου), υπάρχει και ένας τρίτος υπολογιστής συνδεδεµένος στο switch, ο οποίος παίζει τον ρόλο του gateway και δίνει πρόσβαση στο εσωτερικό δίκτυο και κατά συνέπεια και προς το Internet. 6. Profibus 6..1 Αναπαράσταση µεταβλητών Σύµφωνα µε όσα παρουσιάστηκαν στα προηγούµενα κεφάλαια η πληροφορία που διακινείται στο PROFIBUS δεν παρέχει στον χρήστη πλήρως αναγνωρίσιµες τιµές. (αυτό θα φανεί και παρακάτω µε παραδείγµατα). Κάθε συσκευή µε την προµήθεια της συνοδεύεται από το σχετικό manual όπου δίνονται οδηγίες για την χρήση της συσκευής και τον τρόπο αναπαράστασης της πληροφορίας στις εισόδους και τις εξόδους της. Αυτές τις πληροφορίες ο χρήστης πρέπει να τις λάβει υπ όψιν όταν θα χρησιµοποιήσει τις µεταβλητές αυτές στην εφαρµογή. Στη συνέχεια θα περιγραφεί η προσέγγιση ενοποίησης των κοινών χαρακτηριστικών των µεταβλητών ώστε να καταλήξουµε σε έναν ενιαίο τρόπο χρήσης αυτών.

83 ΑΡΤΙΟ Τελική έκθεση Ανάγνωση της πληροφορίας από τον master Σε κάθε master ανατίθενται κάποιοι slaves. Με αδιαφανή τρόπο ως προς τον χρήστη διαβάζονται οι τιµές εισόδων και εγγράφονται οι τιµές εξόδων αυτών σύµφωνα µε το πρωτόκολλο του PROFIBUS. Η master κάρτα δηµιουργεί µια εικόνα των εσόδων ή εξόδων του κάθε slave σε µια κοινόχρηστη µνήµη. Η προσπέλαση αυτής της µνήµης δίνει την δυνατότητα στον χρήστη για ανάγνωση και εγγραφή δεδοµένων. Τα παραπάνω φαίνονται στο επόµενο σχήµα: Memory Bus Parameters Slave Diagnostics Slave Parameters Data image of Slave 1 Data image of Slave Σχήµα 8. ιαµόρφωση µνήµης στον master Ο χρήστης προσπελαύνει την µνήµη (µέσω των υπηρεσιών που προσφέρονται από το API της Softing) και έτσι χρησιµοποιεί το δίκτυο. Η ανάγνωση των εισόδων ή η εγγραφή των εξόδων ενός slave µπορεί να γίνει µε δύο τρόπους: Με απ ευθείας εγγραφή ή ανάγνωση στην θέση µνήµης που αντιπροσωπεύει τα δεδοµένα που θα αναγνωσθούν ή θα εγγραφούν. Με ανάγνωση ή εγγραφή στο κατάλληλο device που αντιπροσωπεύει τον slave όπως αυτό ορίζεται από τον driver της κάρτας. Για τον πρώτο τρόπο είναι απαραίτητο για τον χρήστη να γνωρίζει την ακριβή θέση των δεδοµένων στην µνήµη. Η Softing προσφέρει µια υπηρεσία µέσω της οποίας ανακτάται αυτή η πληροφορία. Στην συνέχεια γνωρίζοντας την διεύθυνση που ξεκινάνε τα δεδοµένα καθώς και το µήκος αυτών, ο χρήστης µπορεί να διαβάσει είτε όλα τα δεδοµένα µαζί είτε κάποιο συγκεκριµένο που βρίσκεται σε κάποιο offset σε σχέση µε την διεύθυνση αρχής τους. Για να γίνει µε αυτόν τον τρόπο η ανάγνωση είναι απαραίτητη η γνώση της δοµής των δεδοµένων του slave. Με τον δεύτερο τρόπο ο χρήστης διαβάζει ή γράφει όλα τα δεδοµένα. εν χρειάζεται γνώση της διεύθυνσης τους στην µνήµη αφού ο driver αναλαµβάνει να προσπελάσει την σωστή διεύθυνση. Η περαιτέρω επεξεργασία αυτών και ο χωρισµός τους στις διακριτές µεταβλητές αφήνεται στον χρήστη και προϋποθέτει την γνώση της δοµής των µεταβλητών. Προς το παρόν από τον driver για το linux υποστηρίζεται µονάχα ο πρώτος τρόπος λειτουργίας. Στα παρακάτω θα υποθέσουµε ότι µε την ανάγνωση ή την εγγραφή διαβάζονται όλες οι µεταβλητές εισόδου ή εξόδου από τον slave. Η ανάλυση τους στις επιµέρους διακριτές µεταβλητές γίνεται σε ένα δεύτερο στάδιο Αναγνώριση και µετατροπή µεταβλητών Κατά την διάρκεια της διαµόρφωσης του συστήµατος θα πρέπει να γίνει ένας διαχωρισµός των µεταβλητών που κρύβονται µέσα στο octet string που αντιπροσωπεύει τις εισόδους και εξόδους ενός slave, και η µετατροπή τους σε διακριτές µεταβλητές γενικού σκοπού. Για τον λόγο αυτό θα υπάρχει ένας δαίµονας

84 ΑΡΤΙΟ Τελική έκθεση 84 που αναλαµβάνει να διαβάζει τα inputs ενός slave και γνωρίζοντας την δοµή και το είδος των δεδοµένων να τα µετατρέπει σε διακριτές µεταβλητές που θα χρησιµοποιηθούν από το σύστηµα. Ο δαίµονας αυτός παρουσιάζεται και ως ProfibusWrapper στην αρχιτεκτονική του δικτύου. Variable 1 Variable Variable 3 Variable n daemon image data of slave 1 image data of slave Σχήµα 9. Mapping των εισόδων και εξόδων του Slave σε διακριτές µεταβλητές. Σε ένα PROFIBUS-DP σύστηµα οι κύριες µεταβλητές που κυκλοφορούν αφορούν τιµές αναλογικές ή ψηφιακές είτε εισόδων είτε εξόδων. Στο δίκτυο δεν κυκλοφορεί καµία πληροφορία για το είδος και τον τύπο της τιµής. Η πληροφορία είναι διαθέσιµη στον χρήστη ο οποίος αναλαµβάνει να χειριστεί σωστά την τιµή που διαβάζει στο δίκτυο για να την αξιοποιήσει. Με την χρήση του ARTIO σκοπός είναι τελικά η µεταβλητή να αποκτάει υπόσταση ώστε να µπορεί να µεταδοθεί διαφανώς σε άλλα συστήµατα. Για τα συµπεράσµατα που ακολουθούν έγινε κυρίως µελέτη των συσκευών που κατασκευάζει η Siemens και λήφθηκαν υπ όψιν οι υποστηριζόµενοι από το PROFIBUS τύποι δεδοµένων. Η προσέγγιση που ακολουθείται είναι προς την κατεύθυνση το προτεινόµενο σύστηµα να παραµείνει όσο το δυνατόν περισσότερο ανοιχτό σε επεµβάσεις και τροποποιήσεις Ψηφιακές τιµές Οι ψηφιακές τιµές εισόδων ή εξόδων παρουσιάζονται σε οµάδες των 8 Bit. Είναι προφανές ότι στο σύστηµα µας κάθε ένα τέτοιο bit θα πρέπει να θεωρείται µια ξεχωριστή µεταβλητή. Η τιµή αυτής της µεταβλητής είναι είτε αληθής είτε ψευδής και αναπαρίσταται τελικά από ένα byte που όλα του τα Bit είναι 1 (αληθής) ή µηδέν (ψευδής) σε συνδυασµό µε άλλο ένα που µεταφέρει την ποιότητα της τιµής (status) ιαφανής Αναλογικές τιµές. Οι αναλογικές τιµές κωδικοποιούνται σε έναν αριθµό από bit που περιέχονται µέσα σε κάποιο αριθµό από bytes. Τόσο ο αριθµός των Bit που αναπαριστούν το µετρούµενο µέγεθος όσο και ο αριθµός των byte εξαρτάται από τον κατασκευαστή. Επίσης ο τρόπος µε τον οποίο αναπαρίσταται το µέγεθος στα bit µπορεί να είναι διαφορετικός (binary, complement of twos, amount with sign κλπ). Μια αναλογική τιµή έχει ένα εύρος που εξαρτάται κυρίως από το µετρούµενο µέγεθος. Τόσο το µέγεθος όσο και το εύρος της τιµής πρέπει να καθοριστούν. Μια αναλογική τιµή πιθανά συνοδεύεται από κάποια διαγνωστική πληροφορία (overflow κλπ).

85 ΑΡΤΙΟ Τελική έκθεση 85 εδοµένων των παραπάνω είναι λογικό να δεχτούµε ότι τελικά µια αναλογική τιµή µπορεί να παρουσιαστεί πλήρως µέσα από µια δοµή που θα δίνει: τιµή (floating point), status (unsigned8), additional_info (δοµή για τον τύπο του µεγέθους, το εύρος των τιµών κλπ) Τύποι εδοµένων Γενερικοί τύποι δεδοµένων και PROFIBUS Για την διασύνδεση ετερογενών δικτύων είναι επιθυµητή η ύπαρξη γενικών τύπων δεδοµένων που υποστηρίζονται από όλα τα δίκτυα. Η οµογενοποίηση αυτή γίνεται µε την υιοθέτηση των τύπων δεδοµένων του προτύπου 1499 και την µεταφορά σε αυτό των τύπων δεδοµένων που υπάρχουν στο PROFIBUS. Στο επόµενο σχήµα φαίνεται ο συσχετισµός των τύπων στα δύο συστήµατα Bit String (8) Bit String (16) Bit String (3) Bit String (64) Long Real (64) Common Real (3) Special PROFIBUS Double Byte String (16*n) Single Byte String (8*n) Boolean (1) Date Long Integer (64) Unsigned Short Integer (8) Unsigned Integer (16) Unsigned Double Integer (3) Time (Duration) Unsigned Long Integer (64) Double Integer Short Integer (8) Integer (16) (3) Time of Day Date and Time Octet String (8*n) Σχήµα 30. Συσχετισµός τύπων δεδοµένων 1499 και Profibus. Παρατηρούµε την ύπαρξη τύπων στο 1499 που δεν υποστηρίζονται από το PROFIBUS καθώς και την ύπαρξη special τύπων δεδοµένων που ενώ υποστηρίζονται και από τα δυο συστήµατα έχουν τελικά διαφορετική αναπαράσταση στην µνήµη του υπολογιστή. Οι ειδικοί αυτοί τύποι δεδοµένων και η αναπαράσταση του φαίνεται στο επόµενο σχήµα.

86 ΑΡΤΙΟ Τελική έκθεση 86 Boolean (1) 1499 Boolean (1) (0 FALSE) (1 TRUE) PROFIBUS Boolean (8) (All one TRUE) (All 0 FALSE) Octet Bits Date Date (8 byte) Type ULINT Number of milliseconds from :00: to YYYY-MM-DD-00:00: RSV RSV RSV RSV SU RSV RSV RSV Date and Time ms min hours Day of Week/Day Of Month months years Octet Bits Time (Duration) (8 byte) Type LINT representing milliseconds ms Time Difference Days Optional Octet Bits Time of Day Time (1 bytes) Type ULINT representing milliseconds since midnight Time of Day ms since midnight Days since 1/1/1984 (optional) Date and Time Date (0 byte) Type ULINT Number of milliseconds since :00: Same as Date and Time Σχήµα 31. Ειδικοί τύποι δεδοµένων. Είναι απαραίτητη λοιπόν µια φόρµα µετατροπής από την µία µορφή στην άλλη. Ειδικότερα στους µπορούµε να δούµε και τύπους που αλληλεπικαλύπτονται ή πιο ειδικά µπορούµε να δηµιουργήσουµε τον έναν µε χρήση του άλλου (πx Octet String µε χρήση του String). Στο κοινό σύστηµα ανταλλαγής δεδοµένων (Virtual Fieldbus) υπάρχει µια δοµή δεδοµένων που χαρακτηρίζει το κάθε Item. Η δοµή αυτή αποτελείται από τις ιδιότητες Name και ID που είναι µοναδικές για κάθε Item στο εικονικό δίκτυο. Στην συνέχεια βλέπουµε την ύπαρξη του Status που είναι απαραίτητη για την χρήση της τιµής. Η πραγµατική τιµή του item έχει τις ιδιότητες κάποιου από τους κοινούς τύπους δεδοµένων όπως αυτοί εµφανίζονται και µετατρέπονται στο PROFIBUS.

87 ΑΡΤΙΟ Τελική έκθεση 87 Στο παρακάτω διάγραµµα φαίνεται η δοµή και η ιεραρχία των τύπων δεδοµένων που υποστηρίζει το PROFIBUS και η σχέση που θα έχουν οι τύποι αυτοί στο Virtual Fieldbus. PROFIBUS Types Item itemname : string itemid : Unsigned16 = 0 status : Unsigned8 itemtype : Unsigned16 write() read() DaemonItem ItemID ItemName OffsetAddress GetValue() SetValue() TypeTimeDifference value : Tim edifference TypeDate value : Date TypeTimeOfDay value : TimeOfDay MathType upperlim it : float lowerlim it : float units : Unsigned16 TypeOther bitstart : Unsigned8 bitlength : Unsigend8 bytelength : Unsigned8 represantation : Unsigned8 lowerval : Unsigned3 upperval : Unsigned3 TypeFloatingPoint value : Fl oat lowerval : Float upperval : Float TypeInt8 value : Integer8 lowerval : Integer8 upperval : Integer8 TypeUns8 value : Unsigned8 lowerval : Unsigned8 upperval : Unsigned8 TypeInt16 value : Integer16 lowerval : Integer16 upperval : Integer16 TypeUns16 value : Unsigned16 lowerval : Uns igned16 upperval : Unsigned16 TypeInt3 value : Integer3 lowerval : Integer3 uperval : Integer3 TypeUns3 value : Unsigned3 lowerval Unsigned3 upperval : Unsigned3 TypeDigital TypeString TypeBool OctetType value : Octet TypeAnalog Σχήµα 3. οµή και η ιεραρχία των τύπων δεδοµένων που υποστηρίζει το PROFIBUS. Γίνεται κατανοητό ότι όλοι οι τύποι των δεδοµένων θα έχουν την δυνατότητα εγγραφής ή ανάγνωσης (σε σχέση µε την ιδιότητα των αντίστοιχων µεταβλητών). Ένα Item στο VFieldbus θα έχει ένα ID (έναν αύξοντα αριθµό που θα το καθορίζει µοναδικά ανάµεσα στα υπόλοιπα items και πιθανά ένα όνοµα που θα το καθορίζει µοναδικά ανάµεσα στα Items όλων των VFieldbus. Κάθε µεταβλητή που θα κυκλοφορεί στο σύστηµα συνοδεύεται από ένα status byte που δίνει πληροφορίες για την εγκυρότητα της. Στην συνέχεια και µε βάση τον προηγούµενο πίνακα µπορούµε να διακρίνουµε µερικούς βασικούς τύπους δεδοµένων: Λογικοί τύποι Με τιµές True/False αναπαριστούν ψηφιακές τιµές εισόδων ή εξόδων. Μαθηµατικοί τύποι Έχουν χαρακτηριστικό ότι οι τιµές τους ανήκουν σε ένα εύρος τιµών ενώ συνοδεύουν φυσικά µεγέθη που αντιστοιχούν σε φυσικές µονάδες. Η αναπαράσταση τους µπορεί να γίνεται µε χρήση κάποιων βασικών τύπων (Integer8, Unsigned16) ή να αναπαρίστανται µε ένα σύνολο από bit που είναι υποσύνολο σε κάποιο µήκος από byte. Με την χρήση του µαθηµατικού τύπου Float εξάγουµε τελικά τον τύπο της αναλογικής τιµής που θα πρέπει να αναπαριστά κάθε αναλογική τιµή στο VF.

88 ΑΡΤΙΟ Τελική έκθεση 88 Ειδικότερα για τον τύπο TypeIntX έχουµε να δούµε τα εξής. Η τιµή του µεγέθους που αναπαρίσταται από αυτόν τον τύπο κρύβεται σε ένα εύρος από bit και όχι σε ολόκληρο το µέγεθος των Bytes που καθορίζουν την µεταβλητή (είσοδο σε µια συσκευή). Επίσης µπορεί η τιµή αυτή να αναπαρίσταται µε διαφορετικούς τρόπους (binary, amount with sign, complement of twos). Άλλοι τύποι Οι υπόλοιποι τύποι που εµφανίζονται στο διάγραµµα είναι ειδικοί τύποι που καθορίζονται στο DPV1 τόσο ως προς το µήκος των δεδοµένων όσο και ως προς τον τρόπο αναπαράστασης τους. Η πρόταση που γίνεται για το είδος των τιµών που θα κυκλοφορούν στο VF, είναι η εξής: Όλες οι τιµές συνοδεύονται από ένα Status. Αναλογικές τιµές εκφράζονται µε τον τύπου AnalogType (βασισµένο στον Float). Ψηφιακές τιµές εκφράζονται από τον τύπο DigitalType Όλοι οι υπόλοιποι µαθηµατικοί τύποι του διαγράµµατος µεταφράζονται τελικά στον τύπο AnalogType γίνεται δηλαδή µετατροπή της τιµής τους σε Float. Ειδικότερα για τον τύπο TypeIntX η µετατροπή γίνεται σύµφωνα µε το είδος κωδικοποίησης των Bit. Οι υπόλοιποι τύποι πρέπει να εξεταστούν σε σχέση µε την ύπαρξη τους σε άλλα fieldbuses για την χρήση τους στο Vfieldbus 6..7 Αναπαράσταση των τύπων δεδοµένων στο PROFIBUS Για τους τύπους του προηγούµενου διαγράµµατος έχουµε τις εξής αναπαραστάσεις: Integer Αναπαριστά έναν προσηµασµένο αριθµό. Data Type Range Length (octets) Integer8-18 έως 17 1 Integer έως 3767 Integer3-31 έως Η αναπαράσταση των ενός integer16 φαίνεται στο επόµενο σχήµα και ανάλογη είναι και η αναπαράσταση των υπολοίπων. Octet Bits SN Το SN καθορίζει το πρόσηµο του αριθµού. Με SN = 0 έχουµε το µηδέν και τους θετικούς αριθµούς, µε SN =1 έχουµε τους αρνητικούς αριθµούς. Η κωδικοποίηση των αριθµών γίνεται σε twos complement µε το MSB να είναι το πρώτο ψηφίο µετά από το πρόσηµο.

89 ΑΡΤΙΟ Τελική έκθεση Unsigned Αναπαριστά έναν µη προσηµασµένο (θετικό) αριθµό. Data Type Range Length (octets) Unsigned8 0 έως 55 1 Unsigned16 0 έως Unsigned3 0 έως Η αναπαράσταση των ενός Unsigne16 φαίνεται στο επόµενο σχήµα και ανάλογη είναι και η αναπαράσταση των υπολοίπων. Octet Bits Floating Point Αναπαριστά έναν δεκαδικό αριθµό µε τρόπο που φαίνεται στο επόµενο σχήµα. Το εύρος των τιµών του καθορίζεται από το IEEE Std 754 Short Real Number (3 bits) και το ίδιο και ο τρόπος αναπαράστασης του. SN είναι το πρόσηµο. (0 για θετικό αριθµό και 1 για αρνητικό αριθµό). Octet 1 SN Bits Exponent (E) Fraction (F) Visible String/ Octet String Το Visible String αναπαριστά ένα κείµενο. Η κωδικοποίηση του γίνεται σύµφωνα µε το ISO 646 ενώ το µήκος του καθορίζεται τόσο στο ISO 646 όσο και στο ISO 375. Κάθε octet αντιστοιχεί σε ένα χαρακτήρα. To octet string αναπαριστά µια ακολουθία από bytes Date Αναπαριστά µια ηµεροµηνία και αποτελείται από ένα κοµµάτι ηµεροµηνίας και ένα κοµµάτι που αναπαριστά χρόνο. Το εύρος τιµών κυµαίνεται από ms σε 99 χρόνια και αναπαρίσταται σε 7 octets. Parameter Value Range Εξήγηση ms 0 έως Milliseconds min 0 έως 59 Λεπτά SU 0,1 0 Standard time, 1 Daylight saving time RSV Reserved hours 0 έως 3 Ώρες d. of. w. 1 έως 7 Μέρα της εβδοµάδας (1 = ευτέρα) d. of m. 1 έως 31 Μέρα

90 ΑΡΤΙΟ Τελική έκθεση 90 months 1 έως 1 Μήνες years 0 έως 99 Χρόνια (χωρίς τον αιώνα) Η αναπαράσταση φαίνεται στο επόµενο σχήµα. Octet Bits RSV RSV SU RSV RSV RSV RSV RSV ms min hours Day of Week/Day Of Month months years Time of Day Αναπαριστά την ώρα σε µια συγκεκριµένη µέρα. Αποτελείται από ένα δείκτη της ώρας και προεραιτικά από ένα δείκτη της µέρας. Η ώρα µετριέται σε ms που έχουν περάσει από τα µεσάνυχτα.(0 = midnight). Η µέρες µετριούνται µε βάση τις µέρες που έχουν περάσει από την 1/1/1984. Το εύρος των τιµών είναι : 0 έως 8-1 ms και 0 έως 16-1 µέρες. Η ώρα αναπαρίσταται µε µια 3bit τιµή στα πρώτα τέσσερα octets. Η µέρα αναπαρίσταται σαν µια 16 bit τιµή που ακολουθεί προαιρετικά. ηλαδή ο τύπος αυτός µπορεί να παρουσιαστεί µε 4 ή 6 octets. Στο επόµενο σχήµα φαίνεται ο συσχετισµός των bits και των τιµών. Octet Bits ms since midnight Days since 1/1/1984 (optional) Time Difference Αναπαριστά ένα χρόνο σε milliseconds και προαιρετικά ένα δείκτη ηµερών. Η δοµή είναι η ίδια µε του τύπου Time of Day αλλά τώρα δίνεται η έννοια της διαφοράς δύο χρόνων PROFIBUS Wrapper Η µετατροπή των δεδοµένων ενός slave σε items του εικονικού δικτύου απαιτεί τον πλήρη έλεγχο των δεδοµένων εισόδου και εξόδου του slave και είναι εξαρτώµενη από την συσκευή. Οι ιδιότητες των δεδοµένων αυτών λαµβάνονται από το αρχείο περιγραφής του slave που προσφέρει η κάθε κατασκευαστική εταιρία. Όπως φαίνεται από την αρχιτεκτονική του συστήµατος ο PROFIBUS wrapper είναι υπεύθυνος για την µετατροπή των δεδοµένων ενός slave σε διακριτά αντικείµενα που αποτελούν τις µεταβλητές του εικονικού δικτύου.

91 ΑΡΤΙΟ Τελική έκθεση 91 Ο χρήστης µπορεί και ελέγχει τα διακριτά αυτά items αλλά η µετατροπή τους και η ανάγνωση ή η εγγραφή στους slaves είναι µια διαφανείς διαδικασία απέναντι του. Ο wrapper γνωρίζει τον συσχετισµό των αντικειµένων µε τις πραγµατικές συσκευές µέσω της αρχικοποίησης που του γίνεται από το εργαλείο του µηχανικού. Για την πιλοτική εφαρµογή του συστήµατος ορίστηκαν τόσο οι ιδιότητες του αντικειµένου όσο και οι ξεχωριστές ιδιότητες που θα πρέπει να έχει το κάθε αντικείµενο που αφορά ένα δίκτυο PROFIBUS. Σε προηγούµενο κεφάλαιο αναφερθήκαµε στους τύπους των τιµών που υποστηρίζει το PROFIBUS. Παρακάτω θα δείξουµε την υλοποίηση σε γλώσσα C των τύπων αυτών και την χρήση τους στην πιλοτική εφαρµογή της διασύνδεσης των δύο δικτύων. Στην εφαρµογή υλοποιήθηκε η χρήση των πιο συνηθισµένων αριθµητικών τύπων (INT, UINT) και των αναλογικών και ψηφιακών τιµών. Ο Wrapper ενηµερώνει συνεχώς µια λίστα µε τα αντικείµενα που έχουν οριστεί από το εργαλείο του µηχανικού. Τα αντικείµενα αυτά είναι οι διακριτές τιµές των µεταβλητών του εικονικού δικτύου. Σε αυτό το κοµµάτι της εφαρµογής θα εξηγήσουµε µερικά από τα χαρακτηριστικά των αντικειµένων αλλά θα δώσουµε έµφαση στην σχέση που έχουν τα αντικείµενα µε τα πραγµατικά δεδοµένα που κυκλοφορούν στο δίκτυο. Στην πιλοτική εφαρµογή ο PROFIBUS wrapper υλοποιεί τους τύπους τιµών DIGITAL, FLOAT, ANALOG όπως αυτοί παρουσιάζονται στις προηγούµενες ενότητες οµές δεδοµένων για την λειτουργία του PROFIBUS Wrapper Oι δοµές που αναπτύχθηκα για την λειτουργία του PROFIBUS wrapper φαίνονται στο επόµενο σχήµα και εξηγούνται στις επόµενες παραγράφους:

92 ΑΡΤΙΟ Τελική έκθεση 9 TYPE_INT_8 value upper lower TYPE_INT_16 value upper lower TYPE_INT_3 TYPE_UINT_8 TYPE_UINT_16 TYPE_UINT_3 TYPE_FLOAT ItemValue void * CreateItemValueOfTypeID(TYPE_ID typeid) void * CreateItemValueDefault(void) +pitemvalue TYPE_DIGITAL DP_ITEM_DIRECTION VAL_LIMITS INT3 upper INT3 lower ITEM _INFO TYPE_ID itemtype bool bmathtype USIGN8 itemstatus USIGN8 itemlength USIGN16 units ITEM_INFO InitItemInfo() ITEM_INFO * CreateItem InfoDefault() ITEM_INFO * CreateItem InfoOfTypeID() UINT8 GetItemInfoItem Value() UINT8 ChangeItemInfoTypeID() ITEM_NET_INFO ITEM_NET_INFO * CreateItemNetInfoDefault() ITEM_NET_INFO * CreateItemNetInfo() ITEM_NET_INFO * CreateItemNetInfo() UINT8 SetItemNetInfoDPItemPos() UINT8 SetItemNetDPItemSlaveInfo() UINT8 SetItemNetDPItemDirection() UINT8 GetItemNetInfoDPItemPos() UINT8 GetItemNetInfoDPItemSlaveInfo() UINT8 GetItemNetInfoDPItemDirection() DP_ITEM_POS USIGN8 startbyte USIGN8 startbit USIGN8 bytelength USIGN8 bitlength REPRESENTATION representation DP_ITEM_POS InitDPItemPos(void) +piteminfo ITEM USIGN16 itemid itemname[max_item_name] ITEM ResetItem() ITEM * CreateItemDefault() ITEM * CreateItemOfTypeID() UINT8 GetItemID() UINT8 SetItemID() UINT8 GetItemName() UINT8 SetItemName() UINT8 GetItemDPDirection() UINT8 SetItemDPDirection() UINT8 GetItemDPItemPos() UINT8 SetItemDPItemPos() UINT8 GetItemDPSlaveInfo() UINT8 SetItemDPSlaveInfo() UINT8 GetItemItemNetInfoPointer() UINT8 GetItemItemNetInfo() UINT8 SetItemItemNetInfo() UINT8 GetItemItemInfoPointer() UINT8 GetItemItemInfo() UINT8 ChangeItemTypeID() UINT8 SetItemValue() UINT8 SetItemUpper() UINT8 SetItemLower() UINT8 GetItemValue() UINT8 GetItemUpper() UINT8 GetItemLower() UINT8 SetItemValueStruct() UINT8 GetItemValueStruct() +pitemnetinfo #typedef VARIABLE VARIABLE_LIST +pitem VARIABLE_LIST USIGN16 itempos VARIABLE * pnext VARIABLE * pprev DP_ITEM_SLAVE_INFO USIGN8 slaveaddress USIGN16 offsetinputs USIGN16 offsetoutputs USIGN8 numberinputs USIGN8 numberoutputs DP_ITEM_SLAVE_INFO InitDPItemSlaveInfo(void) VARIABLE_LIST * CreateVariableList() UINT16 AddItem() VARIABLE * GetVariableByPos() VARIABLE * GetVariableByItemID() VARIABLE * GetVariableByItemName() ITEM * GetItemByPos() ITEM * GetItemByID() ITEM * GetItemByName() UINT16 * SetItemByPos() UINT16 * SetItemByID() UINT16 * SetItemByName() UINT16 * DelItemByPos() UINT16 * DelItemByID() UINT16 * DelItemByName() Σχήµα 33. οµές λειτουργίας του Wrapper οµή VARIABLE_LIST / VARIABLE Η δοµή αυτή χρησιµοποιείται από την εφαρµογή για την δηµιουργία της λίστας µε τις τιµές των διακριτών µεταβλητών του δικτύου. Με αυτή την δοµή µπορούµε να έχουµε πρόσβαση σε κάθε µεταβλητή αφορά το PROFIBUS δίκτυο. οµή VARIABLE_LIST Περιγραφή: Είναι η δοµή στην οποία αποθηκεύονται τα διακριτά αντικείµενα του εικονικού δικτύου που έχουν σχέση µε το PROFIBUS. Υλοποιήθηκε σαν µια λίστα από pointers στην δοµή ITEM και συνοδεύεται από τις απαραίτητες συναρτήσεις για την διαχείριση της λίστας. Attributes Όνοµα Τύπος Περιγραφή itempos USIGN16 είχνει την θέση του item pointer µέσα στην Λίστα pitem ITEM * είκτης στο Item

93 ΑΡΤΙΟ Τελική έκθεση 93 pnext VARIABLE * είκτης στο επόµενο στοιχείο της λίστας pprev VARIABLE * είκτης στο προηγούµενο στοιχείο της λίστας Functions Όνοµα CreateVariableList AddItem GetVariableByPos Περιγραφή εσµεύει την µνήµη για την δηµιουργία µιας άδειας λίστας. Επιστρέφει τον δείκτη στο πρώτο (άδειο) αντικείµενο της λίστας αυτής. Προσθέτει ένα αντικείµενο τύπου pitem στην λίστα. Επιστρέφει την θέση του αντικειµένου Επιστρέφει το στοιχείο της λίστας που βρίσκεται σε συγκεκριµένη θέση GetVariableByItemID Επιστρέφει το στοιχείο της λίστας που του οποίου το item έχει συγκεκριµένο ID GetVariabeByItemName Επιστρέφει το στοιχείο της λίστας που του οποίου το item GetItemByPos GetItemByID GetItemByName SetItemByPos SetItemByID SetItemByName DelItemByPos DelItemByID DelItemByName έχει συγκεκριµένο όνοµα Επιστρέφει τον δείκτη στο item το οποίο βρίσκεται σε συγκεκριµένη θέση στην λίστα. Επιστρέφει τον δείκτη στο item το οποίο έχει συγκεκριµένο ID. Επιστρέφει τον δείκτη στο item το οποίο έχει συγκεκριµένο όνοµα. Θέτει τον δείκτη του item που βρίσκεται σε συγκεκριµένη θέση σε άλλη τιµή Θέτει τον δείκτη του item που έχει συγκεκριµένο ID σε άλλη τιµή Θέτει τον δείκτη του item που έχει συγκεκριµένο όνοµα σε άλλη τιµή ιαγράφει τον δείκτη του Item που βρίσκεται σε συγκεκριµένη θέση στην λίστα. ( εν διαγράφει το στοιχείο της λίστας) ιαγράφει τον δείκτη του Item που έχει συγκεκριµένο ID. ( εν διαγράφει το στοιχείο της λίστας) ιαγράφει τον δείκτη του Item που έχει συγκεκριµένο όνοµα. ( εν διαγράφει το στοιχείο της λίστας) οµή ITEM_INFO οµή ITEM_INFO Attributes Περιγραφή: οµή που περιέχει τα χαρακτηριστικά της µεταβλητής, όπως τον τύπο της το µέγεθος της κλπ. Όνοµα Τύπος Περιγραφή

94 ΑΡΤΙΟ Τελική έκθεση 94 itemtype TYPE_ID ηλώνει τον τύπο στον οποίο ανήκει η µεταβλητή. Ο τύπος αυτός είναι ένας από τους γενερικούς τύπους που έχουν οριστεί για το εικονικό δίκτυο. Έχουν υλοποιηθεί οι εξής τύποι δεδοµένων: ID_USIGN8 ID_USIGN16 ID_USIGN3 ID_INT8 ID_INT16 ID_INT3 ID_FLOAT ID_ANALOG ID_DIGITAL itemstatus OCTET[x] ηλώνει την κατάσταση της τιµής της µεταβλητής. itemlength USIGN8 ηλώνει το µέγεθος της µεταβλητής σε BYTES units USIGN16 ηλώνει το είδος των µονάδων που συνοδεύουν την τιµή της µεταβλητής. pitemvalue void * είκτης στην δοµή που περιέχει την τιµή της µεταβλητής καθώς και την ανώτερη και την ελάχιστη τιµή που µπορεί να πάρει αυτή. Συναρτήσεις για τον έλεγχο της δοµής ITEM_INFO Συνάρτηση Περιγραφή: InitItemInfo Αρχικοποιεί µια δοµή ITEM_INFO CreateItemInfoDefault εσµεύει χώρο στην µνήµη για µια µεταβλητή τύπου USIGN8, αρχικοποιεί την δοµή ITEM_INFO και επιστρέφει τον δείκτη στην δοµή. CreateItemInfoOfTypeID εσµεύει χώρο στην µνήµη για µια µεταβλητή συγκεκριµένου τύπου, αρχικοποιεί την δοµή ITEM_INFO και επιστρέφει τον δείκτη στην δοµή. GetItemInfoItemValue Παίρνει την τιµή από την µεταβλητή. Επιστρέφει τιµή για την επιτυχία της ενέργειας ChangeItemInfoTypeID Αλλάζει τον τύπο της µεταβλητής σε κάποιον άλλο επιθυµητό. Επιστρέφει τιµή για την επιτυχία της ενέργειας. Ο δείκτης pitemvalue δείχνει απ ευθείας σε κάποιο είδος µεταβλητής ώστε να αποθηκεύεται εκεί τη τιµή της µεταβλητής και τα όρια της. Επειδή έχουµε υλοποιήσει τις µεταβλητές µε δείκτες πρέπει να δεσµεύσουµε την απαραίτητη µνήµη κάθε φορά ώστε να τοποθετήσουµε την τιµή της µεταβλητής. Για τον σκοπό αυτό χρησιµοποιούµε τις δύο συναρτήσεις : Συνάρτηση Περιγραφή: CreateItemValueOfTypeID Συνάρτηση που δεσµεύει τον απαραίτητο χώρο στην µνήµη για την µεταβλητή και επιστρέφει την διεύθυνση στην µνήµη στην οποία καταχωρείται η µεταβλητή.

95 ΑΡΤΙΟ Τελική έκθεση 95 CreateItemValueDefault ηµιουργεί µια µεταβλητή τύπου USIGN οµή ITEM Η δοµή ITEM περιλαµβάνει τα στοιχεία που χρειάζεται το εικονικό δίκτυο για να διακρίνει τις µεταβλητές, καθώς και τις συναρτήσεις εκείνες που χρειάζονται για τον έλεγχο των τιµών αυτών. Κάθε δοµή ITEM εκτός από τις βασικές της ιδιότητες περιέχει και ένα δείκτη στην δοµή ITEM_INFO που περιέχει τις ιδιότητες της µεταβλητής που έχουν να κάνουν µε τον τύπο της. ITEM οµή Attributes Περιγραφή: Κάθε ένα αντικείµενο αυτής της δοµής αντιπροσωπεύει µια µοναδική γενερική µεταβλητή που κυκλοφορεί στο δίκτυο. Όνοµα Τύπος Περιγραφή itemid USIGN16 Αριθµός αναγνώρισης της µεταβλητής στο εικονικό δίκτυο. Ο αριθµός αυτός πρέπει να είναι µοναδικός για κάθε µεταβλητή του δικτύου. itemname OCTET[x] Κείµενο που δηλώνει το όνοµα της µεταβλητής. Επίσης το όνοµα πρέπει να είναι µοναδικό για κάθε µεταβλητή. piteminfo ITEM_INFO * είκτης στην δοµή που δηλώνει τα χαρακτηριστικά της µεταβλητής pitemnetinfo ITEM_NET_INFO * είκτης στην δοµή που συνδέει την µεταβλητή µε κάποια πραγµατική συσκευή του δικτύου PROFIBUS Οι γενικές συναρτήσεις που υλοποιήθηκαν για την δηµιουργία του αντικειµένου ITEM και τον έλεγχο των βασικών ιδιοτήτων του είναι οι εξής: Συνάρτηση ResetItem CreateItemDefault CreateItemOfTypeID SetItemID GetItemID GetItemName SetItemName SetItemValue GetItemValue SetItemUpper GetItemUpper SetItemLower Περιγραφή: Αρχικοποιεί το ITEM ηµιουργεί ένα ITEM που αντιπροσωπεύει µια µεταβλητή τύπου USIGN8 ηµιουργεί ένα ITEM που αντιπροσωπεύει µια µεταβλητή συγκεκριµένου τύπου Θέτει το ID του ITEM Επιστρέφει το ID του ITEM Θέτει το όνοµα του ITEM Επιστρέφει το όνοµα του ITEM Θέτει την τιµή της µεταβλητής του ITEM (όταν γνωρίζουµε τον τύπο της) Επιστρέφει την τιµή της µεταβλητής του ITEM (όταν γνωρίζουµε τον τύπο της) Θέτει την µέγιστη τιµή της µεταβλητής του ITEM Επιστρέφει την µέγιστη τιµή της µεταβλητής του ITEM Θέτει την ελάχιστη τιµή της µεταβλητής του ITEM

96 ΑΡΤΙΟ Τελική έκθεση 96 GetItemLower SetItemValueStruct GetItemValueStruct GetItemItemInfoPointer GetItemItemInfo ChangeItemTypeID Επιστρέφει την ελάχιστη τιµή της µεταβλητής του ITEM Θέτει την τιµή της µεταβλητής του ITEM (όταν δεν γνωρίζουµε τον τύπο της) Επιστρέφει την τιµή της µεταβλητής του ITEM (όταν δεν γνωρίζουµε τον τύπο της) Επιστρέφει τον τιµή του δείκτη piteminfo Επιστρέφει το περιεχόµενο του δείκτη piteminfo Αλλάζει το είδος της µεταβλητής δίνοντας της έναν άλλο τύπο Ο δείκτης pitemnetinfo περιέχει τα χαρακτηριστικά που συνδέουν την τιµή του εικονικού αντικειµένου µε την τιµή του σε κάποια πραγµατική συσκευή του δικτύου. Ο δείκτης αυτός είναι εξαρτώµενος από το δίκτυο και θα έχει διαφορετική µορφή ανάλογα µε το δίκτυο στο οποίο αναφέρεται η µεταβλητή. Έγινε υλοποίηση των περιεχοµένων του δείκτη για το δίκτυο PROFIBUS οµή ITEM_NET_INFO. Η δοµή αυτή περιλαµβάνει τα χαρακτηριστικά εκείνα που καθορίζουν την θέση της µεταβλητής σε µια συσκευή του δικτύου καθώς και την θέση της στην µνήµη αυτής της συσκευής. Μπορούµε να χωρίσουµε τα χαρακτηριστικά αυτά σε τρεις κατηγορίες: DIRECTION : Όπου καθορίζεται αν η µεταβλητή παράγεται ή καταναλώνεται στο PROFIBUS ITEM_SLAVE_INFO: Όπου καθορίζεται η σχέση της µεταβλητής µε την θέση της σε κάποια συγκεκριµένη συσκευή του δικτύου. ITEM_POS: Όπου καθορίζεται η ακριβής θέση της µεταβλητής στην µνήµη εισόδου ή εξόδου της συσκευής καθώς και η αναπαράσταση της στο PROFIBUS. Όνοµα Περιγραφή: DP_ITEM_DIRECTION Παίρνει τρεις τιµές που δηλώνουν : Η µεταβλητή καταναλώνεται στο PROFIBUS Η µεταβλητή παράγεται στο PROFIBUS εν έχει οριστεί ακόµα το είδος της µεταβλητής. οµή Περιγραφή: DP_ITEM_SLAVE_INFO Attributes Όνοµα Τύπος Περιγραφή slaveaddress USIGN8 είχνει σε ποια συσκευή καταναλώνεται ή παράγεται η µεταβλητή offsetinputs USIGN16 είχνει την θέση του Byte στη µνήµη της συσκευής στην οποία ξεκινάνε τα δεδοµένα εισόδου offsetoutputs USIGN16 είχνει την θέση του Byte στη µνήµη της συσκευής στην οποία ξεκινάνε τα δεδοµένα εξόδου

97 ΑΡΤΙΟ Τελική έκθεση 97 numberinputs USIGN8 είχνει τον αριθµό των bytes των δεδοµένων εισόδου numberoutputs USIGN8 είχνει τον αριθµό των bytes των δεδοµένων εξόδου Οι τιµές που δίνονται στην παραπάνω δοµή λαµβάνονται από την αντίστοιχη υπηρεσία του API της κάρτας του PROFIBUS δικτύου. οµή DP_ITEM_POS Attributes Περιγραφή: είχνει την µορφή, το είδος της µεταβλητής όπως αυτό εκφράζεται στο PROFIBUS Όνοµα Τύπος Περιγραφή starbyte USIGN8 είχνει σε πιο byte ξεκινάει η τιµή της µεταβλητής startbit USIGN8 είχνει σε πιο Bit του αρχικού byte ξεκινάει η τιµή της µεταβλητής bytelength USIGN8 είχνει το µήκος των byte στα οποία περιέχεται η µεταβλητή bitlength USIGN8 είχνει τον αριθµό των bit από τα οποία αποτελείται η µεταβλητή representation REPRESENTATION Αν η µεταβλητή εκφράζει αριθµητική τιµή δείχνει µε ποιον δυαδικό τρόπο αυτή κωδικοποιείται στο σύστηµα. Υλοποιούµε τρεις τρόπους κωδικοποίησης: NONE για τιµές που δεν εκφράζουν αρ. τιµή BINARY COMPLEMENT AMOUNT_SIGN Στην περίπτωση η µεταβλητή εκφράζει αριθµητική τιµή σε δυαδικό σύστηµα τότε µπορούµε να ορίσουµε την µέγιστη και την ελάχιστη τιµή της. Με αυτό τον τρόπο µπορεί να γίνει η αποκωδικοποίηση της τιµής στην αναλογική τιµή που εκφράζει το γενερικό αντικείµενο. Τα παραπάνω στοιχεία λαµβάνονται από τον έλεγχο του αρχείου περιγραφής του slave. Το εργαλείο του µηχανικού µε ανάλυση του αρχείου περιγραφής θα πρέπει να είναι σε θέση να δώσει αρχικές τιµές σε αυτά τα στοιχεία και στην συνέχεια µε χρήσητου API να γίνει η ανάγνωση και η εγγραφή της τιµής. Ορισµένα παραδείγµατα συσχετισµών τιµών στο PROFIBUS και γενερικών τιµών ειναι τα παρακάτω. Τύπος ITEM PROFIBUS TYPE_DIGITAL typeid = USIGN8 value = USIGN8 typelength = 1 starbyte = 3 startbit = 4 bytelength = 0

98 ΑΡΤΙΟ Τελική έκθεση 98 TYPE_ΑNALOG units = 0 bitlength = 1 representation = none upper = 0 lower = 0 typeid = ANALOG value = FLOAT typelength = 4 units = 4 (mm) upper = (FLOAT) 14,5 lower = (FLOAT) 3 starbyte = 1 startbit = 3 bytelength = 3 bitlength = 11 representation = BINARY upper = 55 lower = 0 TYPE_INT8 typeid = INT8 value = INT8 typelength = 1 units = 4 (mm) upper = (INT8) 0 lower = (INT8) -3 starbyte = 1 startbit = 0 bytelength = 1 bitlength = 8 representation = BINARY upper = 55 lower = οµή και λειτουργία του PROFIBUS wrapper Ο profibus wrapper υλοποιήθηκε ως ένα process στο LINUX. Η επικοινωνία του µε τα άλλα process γίνεται µέσα από RTFIFOS όπως αυτό εξηγείται στην αρχιτεκτονική του συστήµατος. Στην πιλοτική εφαρµογή υποθέτουµε ότι οι δοµές µε τις λίστες των µεταβλητών που παρουσιάστηκαν πιο πάνω είναι έτοιµες για να χρησιµοποιηθούν (δηµιουργούνται αυτόµατα κατά την αρχικοποίηση του συστήµατος). Στην συνέχεια µε χρήση του API της SOFTING το δίκτυο αρχικοποιείται και τίθεται σε λειτουργία. Με την γνώση που έχει ο wrapper για τον συσχετισµό των µεταβλητών του δικτύου και των συσκευών του δικτύου ενηµερώνονται τόσο οι slaves του profibus µε τις καινούργιες τιµές εξόδου όσο και το υπόλοιπο σύστηµα µε τις ανανεωµένες τιµές εισόδου. Η πιλοτική εφαρµογή είχε ως σκοπό την διασύνδεση δύο οµοειδών PROFIBUS δικτύων τα οποία ελέγχονται από αντίστοιχες κάρτες της SOFTING σε δυο αποµακρυσµένους υπολογιστές που συνδέονται µεταξύ τους µέσω ενός ATM switch. Το process που υλοποιεί τον wrapper αποτελείται από 4 κυρίως threads. Στην αρχή γίνεται η αρχικοποίηση του συστήµατος και στην συνέχεια αυτά τα 4 threads αναλαµβάνουν την διακίνηση και µετατροπή της πληροφορίας. Προκειµένου να µην είναι το σύστηµα συνεχώς φορτωµένο µε τιµές που έχουν αποσταλεί προηγουµένως και δεν έχουν ακόµα αλλάξει επιλέχτηκε η χρήση σηµάτων µεταξύ των διαφόρων threads. Με την δηµιουργία ενός σήµατος η καινούργια τιµή ελέγχεται σε σχέση µε την παλιά και αποστέλλεται µονάχα όταν είναι διαφορετική από την υπάρχουσα. Προκειµένου να γίνει αυτός ο έλεγχος ο wrapper δηµιουργεί µια ενδιάµεση µνήµη στην οποία αποθηκεύει όλα τα items µε τις τιµές τους. Το block διάγραµµα λειτουργίας του wrapper φαίνεται στο επόµενο σχήµα.

99 ΑΡΤΙΟ Τελική έκθεση 99 Αρχικοποίηση Λιστών Αρχικοποίηση Ενδιάµεσης µνήµης Άνοιγµα Καναλιών Επικοινωνίας (FIFOS, QUEES) Ορισµός των ITEMS και τοποθέτηση τους στην λίστα Αρχικοποίηση του DP (Άνοιγµα του protocol stack) (Ορισµός τωνπαραµέτρων του δικτύου) (Ορισµός των slave συσκευών) Ανάκτηση της δοµής DP_ITEM_SLAVE_INFO και τοποθέτηση της στην λίστα µε τα ITEMS Αρχικοποίηση της ενδιάµεσης µνήµης βασισµένη στα ITEMS (ορισµός ενεργών slave) (τοποθέτηση των δεικτών των ITEMSγια γρήγορη πρόσβαση) Ενεργοποίηση του thread WriteDP Ενεργοποίηση του thread ReadFifo Ενεργοποίηση του thread WriteFifo Ενεργοποίηση του thread ReadDP Έλεγχος για τερµατισµό των threads και έξοδος όταν γίνει αυτό Στην εφαρµογή η αρχικοποίηση των λιστών µε τα ITEMS γίνεται από τον χρήστη. Πιο γενικά όµως η δοµή αυτή θα πρέπει να προσφέρεται µε χρήση των απαραίτητων υπηρεσιών µέσα από το περιβάλλον ελέγχου του wrapper.

100 ΑΡΤΙΟ Τελική έκθεση 100 Η αρχικοποίηση του DP προϋποθέτει την ύπαρξη δοµών απαραίτητων στο δίκτυο οι οποίες θα πρέπει να προσφέρονται επίσης από την εφαρµογή ελέγχου του wrapper. Μετά την αρχικοποίηση του Protocol stack και την ενεργοποίηση των παραµέτρων των slaves που υπάρχουν στο δίκτυο η εφαρµογή µπορεί να ανακτήσει την απαραίτητη πληροφορία σχετικά µε τις θέσεις των δεδοµένων εισόδου-εξόδου του δικτύου και να συµπληρώσει την δοµή ελέγχου του κάθε item. Η ενδιάµεση µνήµη που δηµιουργείται χρησιµεύει για την αποθήκευση των προσωρινών τιµών εισόδου ή εξόδου, τον ορισµό των slave που παίρνουν µέρος στην διαδικασία (ενώ λειτουργεί σαν ένα container όλων των δεικτών των item ώστε να είναι δυνατός ο έλεγχος τους µε κριτήριο τον slave στον οποίο ανήκει το item). Με το πέρας της αρχικοποίησης ο wrapper γνωρίζει οτιδήποτε είναι απαραίτητο για να ξεκινήσει την διαδικασία εγγραφής και ανάγνωσης, έτσι ενεργοποιούνται τα τέσσερα threads που εξυπηρετούν αυτή την επικοινωνία. Το thread WriteDP χρησιµοποιεί το API της κάρτας έτσι ώστε να γράψει στον εκάστοτε slave την τιµή της µεταβλητής όποτε αυτό κριθεί απαραίτητο. Το thread ReadFifo υλοποιεί την επικοινωνία µε το υπόλοιπο σύστηµα. Σε αυτό έρχεται η πληροφορία σχετικά µε το item που πρέπει να εγγραφεί στο DP και την τιµή του. Η τιµή ελέγχεται σε σχέση µε την προηγούµενη και αν είναι διαφορετική εγγράφεται στην ενδιάµεση µνήµη. Από εκεί µεταφέρεται στον slave από το thread WriteDP. Το thread ReadDP αναλαµβάνει να ενηµερώσει την ενδιάµεση µνήµη µε τα δεδοµένα εισόδου. Αν κάποια τιµή είναι διαφορετική το thread WriteFifo ενεργοποιείται για να περάσει αυτή την τιµή στο υπόλοιπο σύστηµα. Ο µηχανισµός αυτός και η εσωτερική λειτουργία του κάθε thread φαίνεται στο επόµενο block διάγραµµα InterThread Communication Τα threads εν γένει µπορούν να λειτουργούν ανεξάρτητα το ένα από το άλλο, προκειµένου όµως να καταµεριστεί ο χρόνος χρήσης της cpu οµοιόµορφα έτσι ώστε τα δυο threads που υλοποιούν την ανάγνωση από το DP και την ανάγνωση από το σύστηµα να χρησιµοποιούν το µεγαλύτερο χρόνο ενώ τα άλλα δυο να λειτουργούν µόνο όταν αυτό είναι απαραίτητο, επιλέχθηκε τα threads να επικοινωνούν µεταξύ τους µε έναν µηχανισµό µηνυµάτων. Ο µηχανισµός αυτός φαίνεται στο επόµενο σχήµα.

101 ΑΡΤΙΟ Τελική έκθεση 101 (R_DP) ReadDP WriteDP (W_FIFO, slaveaddress) (R_FIFO) (R_DP) (W_DP, slaveaddress) WriteFifo ReadFifo (R_FIFO) Σχήµα 34. Μηχανισµός επικοινωνίας των threads. Τα δύο threads ReadDP και ReadFifo εναλλάσσονται µεταξύ τους και χρησιµοποιούν τα υπόλοιπα µόνο όταν τα δεδοµένα που λαµβάνουν είναι διαφορετικά από τα υπάρχοντα. Το thread ReadDP λαµβάνει τα δεδοµένα από τον slave για κάθε slave ξεχωριστά. Στην συνέχεια τα συγκρίνει µε τα δεδοµένα που διάβασε την προηγούµενη φορά. Τα δεδοµένα εδώ βρίσκονται στην µορφή που καθορίζει το profibus ανεξάρτητα από τα items που έχουν οριστεί. Όταν τα δεδοµένα είναι διαφορετικά τότε ενεργοποιείται το thread WriteFifo. Το µήνυµα που το ενεργοποιεί έχει ως παράµετρο την διεύθυνση του slave που έχει τα διαφορετικά δεδοµένα. Με την βοήθεια αυτής της παραµέτρου το WriteFifo θα ελέγξει ένα ένα τα items που συνδέονται µε αυτόν τον slave και στην συνέχεια όταν η τιµή κάποιου item βρεθεί διαφορετική από την προηγούµενη αυτό και µόνο αυτό θα περάσει στο υπόλοιπο σύστηµα µέσω της fifo. Μετά το πέρας του ελέγχου όλων των item που σχετίζονται µε τον slave ενεργοποιείται το ReadFifo. Αυτό µε την σειρά του θα ενεργοποιήσει το ReadDP αν δεν λάβει κανένα µήνυµα από το εξωτερικό σύστηµα ή θα λάβει κάποιο µήνυµα που αφορά την τιµή ενός item. Η τιµή αυτή θα ελεγχθεί σε σχέση µε την προηγούµενη και µόνο όταν είναι διαφορετική θα µετατραπεί στην µορφή που ορίζει το profibus και θα τοποθετηθεί στην ενδιάµεση µνήµη. Στην συνέχεια θα ενεργοποιηθεί το WriteDP µε παράµετρο τον slave του οποίου τα δεδοµένα πρέπει να αλλάξουν ώστε να γραφτούν αυτά στο DP. Από τα παραπάνω φαίνεται ότι η ενδιάµεση µνήµη που χρησιµοποιείται περιλαµβάνει όλες τις τιµές εισόδων και εξόδων τόσο στην µορφή που καθορίζει το profibus όσο και στην µορφή που καθορίζεται από το γενερικό σύστηµα. Το thread WriteDP γράφει κάθε φορά ολόκληρο το frame των δεδοµένων εξόδου του slave ενώ το ReadDP διαβάζει ολόκληρο το frame των δεδοµένων εισόδου. Αυτό

102 ΑΡΤΙΟ Τελική έκθεση 10 γίνεται διότι η επανάληψη πολλών read για µεµονωµένα κοµµάτια που αντιπροσωπεύουν ένα αντικείµενο τελικά δηµιουργεί καθυστερήσεις στο σύστηµα. Επίσης θα πρέπει να τονιστεί ότι όλα τα threads έχουν πρόσβαση σε µια κοινή µνήµη. Για να αποφευχθούν conflicts χρησιµοποιούνται semaphores ώστε κάθε φορά ένα µόνο thread να έχει την αποκλειστική πρόσβαση στην κοινή µνήµη Thread ReadDP To thread ενεργοποιείται και βρίσκεται στην αναµονή ενός µηνύµατος µε τύπο R_DP (read_dp) αφού έχει θέσει ότι ο πρώτος slave ο οποίος θα αναγνωστεί έχει την διεύθυνση µηδέν.. Όταν αυτό το µήνυµα έρθει τότε από την κοινή µνήµη θα αντλήσει τις πληροφορίες που χρειάζεται για τον τρέχοντα slave. ( οµή DP_ITEM_SLAVE_INFO). Start slaveaddress = 0 OXI Wait Msg msg type == R_DP NAI Slave (slaveaddress) == Active inputdata > 0 ; Read Slave Data OXI OXI current SlaveData == previous Slave Data NAI Copy Data to intermidiate memory Send Msg type R_FIFO Send Msg type (W_FIFO,slaveAddress) SlaveAddress ++; if (slaveaddress > 16){ slaveaddress = 0; }

103 ΑΡΤΙΟ Τελική έκθεση 103 Αν ο slave έχει δηλωθεί ως active ( δηλαδή υπάρχουν items που σχετίζονται µε αυτόν) και αν έχει δεδοµένα εισόδου τότε αυτά τα δεδοµένα θα διαβαστούν. Στην συνέχεια θα συγκριθούν µε τα υπάρχοντα στην κοινή µνήµη (πάντα σε είπεδο πακέτων profibus). Αν τα δεδοµένα είναι τα ίδια τότε θα ενεργοποιηθεί το thread ReadFifo Αν τα δεδοµένα είναι διαφορετικά σηµαίνει ότι κάποιο από τα items που σχετίζονται µε τον slave έχει αλλάξει τιµή (δεν ξέρουµε ακόµα ποιο). Σε αυτή την περίπτωση τα δεδοµένα αντιγράφονται στην κοινή µνήµη και ενεργοποιείται το thread WriteFifo µε παράµετρο την διεύθυνση του slave. Με την έξοδο του το thread καθορίζει ότι την επόµενη φορά που θα ενεργοποιηθεί θα ελεγχθεί ο επόµενος κατά σειρά slave Thread WriteFifo Το thread ξεκινάει και τίθεται σε αναµονή ενός µηνύµατος µε τύπο W_FIFO και παράµετρο την διεύθυνση κάποιου slave. Όταν το µήνυµα αυτό έρθει ελέγχει ένα ένα τα items που σχετίζονται µε αυτή την διεύθυνση. Για κάθε item κάνει την µετατροπή από το PROFIBUS στο IEC της τιµής της µεταβλητής. Στην συνέχεια η τιµή αυτή συγκρίνεται µε την προηγούµενη. Αν αυτή είναι διαφορετική τότε το item γράφεται στην fifo. Το thread ενεργοποιεί το R_FIFO όταν ελέγξει όλα τα items που σχετίζονται µε τον slave.

104 ΑΡΤΙΟ Τελική έκθεση 104 Start OXI Wait Msg msg type == W_FIFO NAI Get slaveaddress take first item of slave ProfiToItem current Item vallue == previous Item value take next Item OXI Write Item to fifo NAI NAI more items? OXI Send MSG (R_FIFO) Thread ReadFifo Το thread βρίσκεται σε αναµονή ενός µηνύµατος τύπου R_FIFO. Στην συνέχεια θα προσπαθήσει να ελέγξει αν στην fifo έχει έρθει κάποιο item. Το ID του item θα δώσει στο thread την απαραίτητη πληροφορία για να αντλήσει από την κοινή µνήµη τις παραµέτρους που χρειάζονται για τον έλεγχο του item. Η τιµή του item που έχει έρθει θα συγκριθεί µε την προηγούµενη. Στην συνέχεια και αν είναι διαφορετική θα µεταφρασθεί στην αναπαράσταση του PROFIBUS και θα ενσωµατωθεί στο πακέτο µε τα δεδοµένα εξόδου του αντίστοιχου slave µε το οποίο είναι συνδεδεµένο. Στην συνέχεια θα ενεργοποιηθεί το thread WriteDP για να γράψει ολόκληρο το πακέτο στον slave.

105 ΑΡΤΙΟ Τελική έκθεση 105 Start slaveaddress = 0 OXI Wait Msg msg type == R_FIFO NAI current IEC vallue == previous IEC value OXI IEC To PROFI NAI Send Msg type (W_DP, slaveaddress) Thread WriteDP Send Msg type R_FIFO Το thread ξεκινάει µε την αναµονή ενός µηνύµατος τύπου W_DP. Όταν αυτό έρθει θα ληφθεί ως παράµετρος η διεύθυνση του slave στον οποίο πρέπει να γίνει η εγγραφή. Τα δεδοµένα τα οποία θα γραφτούν στον slave θα ληφθούν από την ενδιάµεση µνήµη στην οποία έχουν τοποθετηθεί από το προηγούµενο thread. Τα δεδοµένα θα γραφτούν στον σωστό slave και στην συνέχεια θα ενεργοποιηθεί το thread R_DP. Start OXI Wait Msg msg type == W_DP NAI Get slaveaddress Get Data to be written Write Data Send MSG (R_DP)

106 ΑΡΤΙΟ Τελική έκθεση οµή της ενδιάµεσης µνήµης Όπως αναφέρθηκε παραπάνω κατά την αρχικοποίηση δηµιουργείται µια ενδιάµεση µνήµη µέσω της οποίας µπορούµε να έχουµε πρόσβαση τόσο στα χαρακτηριστικά των item όσο και στα χαρακτηριστικά των slave του δικτύου. Η ενδιάµεση αυτή µνήµη συγκεντρώνει όλες τις απαραίτητες πληροφορίες ή τους δείκτες προς τις πληροφορίες και η δοµή της φαίνεται στο επόµενο σχήµα. Slave 0 Slave Active Slave Info address offsetinput offsetoutput numberinput numberoutput PROFI Data num Items num Items pitem 1 pitem Σχήµα 35.Η δοµή της ενδιάµεσης µνήµης. Στο επόµενο σχήµα φαίνεται αναλυτικότερα επίσης η δοµή ενός pointer σε item.

107 ΑΡΤΙΟ Τελική έκθεση 107 pitem 1 itemid item Name piteminfo itemtype itemstatus itemlength units pitemvalue value pitemnetinfo direction Slave Info itempos upper lower address offsetinput offsetoutput numberinput numberoutput startbyte startbit bytelength bitlength representation limits upper lower 6.3 Lonworks Σχήµα 36.Η δοµή ενός pointer σε item. Προκειµένου να υλοποιηθεί η διασύνδεση του δικτύου Lonworks στο ΑΡΤΙΟ Gateway εκτελέσθηκαν χονδρικά τα παρακάτω έργα: Μελέτη του protocol stack και του Lonworks API, υπηρεσίες, πηγαίος κώδικας, και porting σε RT Linux Μελέτη της κάρτας του δικτύου Lonworks (στο κεντρικό PC ελέγχου του δικτύου και αξιολόγηση της δυνατότητα πρόσβασης στo hardware (dual port RAM κλπ.) Αναπαράσταση της διακινούµενης RT πληροφορίας, τύποι, κ.λ.π. Εφαρµογή των παραπάνω στην αρχική διασύνδεση δύο δικτύων Lonworks διαµέσου RT Linux. Ethernet - RT Linux.. Υλοποίηση του ΑΡΤΙΟ Gateway Αξιολόγηση τρόπου (mode) λειτουργίας Αρχικοποίηση και λειτουργία ενός προγράµµατος Στο επόµενο σχήµα φαίνεται η ακολουθία των ενεργειών και η χρήση των διαθέσιµων υπηρεσιών προκειµένου η κάρτα του δικτύου Lonworks να τεθεί στην κατάσταση λειτουργίας.

108 ΑΡΤΙΟ Τελική έκθεση 108 OFFLINE OPEN() INIT_NODE SEND_LOCAL (INITIALISE) LOAN_NV_CONFIG READ_MESSAGE EXECUTE MESSAGE ORDER RESPOND TO MESSAGE Η κατάσταση του λογισµικού ελέγχου που τρέχει στην κάρτα εξαρτάται από τις εντολές ελέγχου του χρήστη και µερικώς από την κατάσταση του status των ενεργοποιηµένων κόµβων και των αντίστοιχων εισόδων τους. Κατά την κατάσταση λειτουργίας το σύστηµα µπορεί και ανταλλάσσει δεδοµένα µεταξύ της κάρτας, των κόµβων και των υπολοίπων σταθµών των υποστηριζόµενων δικτύων Αναπαράσταση µεταβλητών Σύµφωνα µε όσα προδιαγράφονται στο πρωτόκολλο του δικτύου η πληροφορία που διακινείται στο δίκτυο παρέχει στον χρήστη πλήρως αναγνωρίσιµες τιµές. Κάθε συσκευή µε την προµήθεια της συνοδεύεται από το σχετικό manual και τα σχετικά αρχεία όπου δίνονται περιγραφές σχετικά µε τις µεταβλητές δικτύου που χρησιµοποιούνται για την επικοινωνία της συσκευής µε το υπόλοιπο περιβάλλον του δικτύου ελέγχου Ανάγνωση της πληροφορίας από την κάρτα Σε κάθε κάρτα πού εδώ έχει και τον ρόλο του Network Manager, αντιστοιχούν κάποιοι κόµβοι. Η κάρτα είναι υπεύθυνη για τη ανάγνωσή της πληροφορίας από τους κόµβους.

109 ΑΡΤΙΟ Τελική έκθεση 109 Η ανάγνωση των εισόδων ή η εγγραφή των εξόδων ενός κόµβου µπορεί να γίνει µε δύο τρόπους: Με απ ευθείας µετάδοση της τιµής στο δίκτυο αµέσως µετά την ενηµέρωση της µεταβλητής Με ανάγνωση ή εγγραφή κάνοντας χρήση της ρουτίνας ανάκτησης τιµής Αναγνώριση και µετατροπή µεταβλητών Κατά την διάρκεια της διαµόρφωσης του συστήµατος θα πρέπει να γίνει ένας διαχωρισµός των µεταβλητών που κρύβονται µέσα στο string που αντιπροσωπεύει τις τιµές των µεταβλητών που εκπέµπονται. Για τον λόγο αυτό υπάρχει ένας δαίµονας που αναλαµβάνει να διαβάζει τα inputs που προέρχονται από τους κόµβους και γνωρίζοντας την δοµή και το είδος των δεδοµένων να τα µετατρέπει σε µεταβλητές που θα χρησιµοποιηθούν από το σύστηµα. Ο δαίµονας αυτός παρουσιάζεται και ως LonWrapper στην αρχιτεκτονική του δικτύου. Variable 1 Variable Variable 3 Variable n daemon Node 1 data Node data Σχήµα 37. Mapping των εισόδων και εξόδων των κόµβων σε διακριτές µεταβλητές. Σε ένα Lonworks δίκτυο οι κύριες µεταβλητές που κυκλοφορούν αφορούν τιµές αναλογικές ή ψηφιακές είτε εισόδων είτε εξόδων. Με την χρήση του ARTIO σκοπός είναι οι µεταβλητές να έχουν µία κοινή µορφή ώστε να µπορούν να αποκτούν υπόσταση διαφανώς και σε άλλα συστήµατα Τύποι εδοµένων Γενερικοί τύποι δεδοµένων και Lonworks Για την διασύνδεση ετερογενών δικτύων είναι επιθυµητή η ύπαρξη γενικών τύπων δεδοµένων ώστε να υποστηρίζονται από όλα τα δίκτυα. Η οµογενοποίηση αυτή γίνεται µε την υιοθέτηση των τύπων δεδοµένων του προτύπου 1499 και την µεταφορά σε αυτό των τύπων δεδοµένων που υπάρχουν στο Lonworks. Στο επόµενο σχήµα φαίνεται ο συσχετισµός των τύπων στα δύο συστήµατα.:

110 ΑΡΤΙΟ Τελική έκθεση Bit String (8) Bit String (16) Bit String (3) Bit String (64) Long Real (64) Double Byte String (16*n) Common Real (3) Single Byte String (8*n) Unsigned Short Integer (8) Special LonWorks Short Integer (8) Date Signed Char (8) Long Integer (64) Unsigned Integer (16) Time (Duration) Unsigned Char (8) Unsigned Long Integer (64) Unsigned Double Integer (3) Integer (16) Date and Time String (8*n) Double Integer (3) Float (3) Σχήµα 38. Ο συσχετισµός τύπων δεδοµένων µεταξύ 1499 και Lonworks. Παρατηρούµε την ύπαρξη τύπων στο 1499 που δεν υποστηρίζονται από το Lonworks καθώς και την ύπαρξη special τύπων δεδοµένων που ενώ υποστηρίζονται και από τα δυο συστήµατα έχουν τελικά διαφορετική αναπαράσταση στην µνήµη του υπολογιστή. Οι ειδικοί αυτοί τύποι δεδοµένων και η αναπαράσταση του φαίνεται στο επόµενο σχήµα.

111 ΑΡΤΙΟ Τελική έκθεση LonWorks Octet Bits Date Date (8 byte) Type ULINT Number of milliseconds from :00: to YYYY-MM-DD-00:00: SNVT_time_stamp Year (0-3000) Month (1-1) Day (0-31) Hour (0-3) Minute (0-59) Second (0-59) Date and Time Date (0 byte) Type ULINT Number of milliseconds since :00: Same as Date and Time SNVT_date_time Time (Duration) Time (1 bytes) Type ULINT representing milliseconds since midnight Octet Bits SNVT_elapsed_time Day ( Hour (0-3) 1 0 Minute (0-59) 1 0 Second (0-59) Millisecond (0-999) Σχήµα 39. Οι ειδικοί τύποι δεδοµένων. Είναι απαραίτητη λοιπόν µια φόρµα µετατροπής από την µία µορφή στην άλλη. Στο κοινό σύστηµα ανταλλαγής δεδοµένων (Virtual Fieldbus) υπάρχει µια δοµή δεδοµένων που χαρακτηρίζει το κάθε Item. Η δοµή αυτή αποτελείται από τις ιδιότητες Name και ID που είναι µοναδικές για κάθε Item στο εικονικό δίκτυο. Στην συνέχεια βλέπουµε την ύπαρξη του Status που είναι απαραίτητη για την χρήση της τιµής. Η πραγµατική τιµή του item έχει τις ιδιότητες κάποιου από τους κοινούς τύπους δεδοµένων όπως αυτοί εµφανίζονται και µετατρέπονται στο Lonworks. Στο παρακάτω διάγραµµα φαίνεται η δοµή και η ιεραρχία των τύπων δεδοµένων που υποστηρίζει το Lonworks και η σχέση που θα έχουν οι τύποι αυτοί στο Virtual Fieldbus.

112 ΑΡΤΙΟ Τελική έκθεση 11 Σχήµα 40. Η δοµή και ιεραρχία τύπων δεδοµένων (Virtual Fieldbus). Γίνεται κατανοητό ότι όλοι οι τύποι δεδοµένων (SNVTs) θα έχουν την δυνατότητα εγγραφής ή ανάγνωσης (σε σχέση µε την ιδιότητα των αντίστοιχων µεταβλητών). Ένα Item στο VFieldbus θα έχει ένα ID (έναν αύξοντα αριθµό που θα το καθορίζει µοναδικά ανάµεσα στα υπόλοιπα items και πιθανά ένα όνοµα που θα το καθορίζει µοναδικά ανάµεσα στα Items όλων των VFieldbus. Κάθε µεταβλητή που θα κυκλοφορεί στο σύστηµα συνοδεύεται από ένα status byte που δίνει πληροφορίες για την εγκυρότητα της. Η πρόταση που γίνεται για το είδος των τιµών που θα κυκλοφορούν στο VF, είναι η εξής: Όλες οι τιµές συνοδεύονται από ένα Status. Αναλογικές τιµές εκφράζονται µε τον τύπου AnalogType (βασισµένο στον Float). Ψηφιακές τιµές εκφράζονται από τον τύπο DigitalType και µεταφράζονται σε καάποιο τύπο integerx Όλοι οι υπόλοιποι µαθηµατικοί τύποι του διαγράµµατος µεταφράζονται τελικά στον τύπο AnalogType γίνεται δηλαδή µετατροπή της τιµής τους σε Float. Ειδικότερα για τον τύπο TypeIntX η µετατροπή γίνεται σύµφωνα µε το είδος κωδικοποίησης των Bit. Οι υπόλοιποι τύποι πρέπει να εξεταστούν σε σχέση µε την ύπαρξη τους σε άλλα fieldbuses για την χρήση τους στο VFieldbus

113 ΑΡΤΙΟ Τελική έκθεση Αναπαράσταση των τύπων δεδοµένων στο Lonworks Για τους τύπους του προηγούµενου διαγράµµατος έχουµε τις εξής αναπαραστάσεις: Integer Αναπαριστά έναν προσηµασµένο αριθµό. Data Type Range Length (octets) Integer8-18 έως 17 1 Integer έως 3767 Integer3-31 έως Η αναπαράσταση των ενός integer16 φαίνεται στο επόµενο σχήµα και ανάλογη είναι και η αναπαράσταση των υπολοίπων. Το SN καθορίζει το πρόσηµο του αριθµού. Με SN = 0 έχουµε το µηδέν και τους θετικούς αριθµούς, µε SN =1 έχουµε τους αρνητικούς αριθµούς. Η κωδικοποίηση των αριθµών γίνεται σε twos complement µε το MSB να είναι το πρώτο ψηφίο µετά από το πρόσηµο. Octet Bits SN Unsigned Αναπαριστά έναν µη προσηµασµένο (θετικό) αριθµό. Data Type Range Length (octets) Unsigned8 0 έως 55 1 Unsigned16 0 έως Η αναπαράσταση των ενός Unsigne16 φαίνεται στο επόµενο σχήµα και ανάλογη είναι και η αναπαράσταση του Unsigned 8. Octet Bits Floating Point Αναπαριστά έναν δεκαδικό αριθµό µε τρόπο που φαίνεται στο επόµενο σχήµα. Το εύρος των τιµών του καθορίζεται από το IEEE Std 754 Short Real Number (3 bits) και το ίδιο και ο τρόπος αναπαράστασης του. SN είναι το πρόσηµο. (0 για θετικό αριθµό και 1 για αρνητικό αριθµό).

114 ΑΡΤΙΟ Τελική έκθεση 114 Octet 1 SN Bits Exponent (E) Fraction (F) Visible String/ Octet String Το Visible String αναπαριστά ένα κείµενο. Η κωδικοποίηση του γίνεται σύµφωνα µε το ISO 646 ενώ το µήκος του καθορίζεται τόσο στο ISO 646 όσο και στο ISO 375. Κάθε octet αντιστοιχεί σε ένα χαρακτήρα. To octet string αναπαριστά µια ακολουθία από bytes Date Αναπαριστά µια ηµεροµηνία και αποτελείται από ένα κοµµάτι ηµεροµηνίας και ένα κοµµάτι που αναπαριστά χρόνο. Η αναπαράσταση φαίνεται στο επόµενο σχήµα. Octet Bits Year (0-3000) Month (1-1) Day (0-31) Hour (0-3) Minute (0-59) Second (0-59) Time of Day Αναπαριστά την ώρα σε µια συγκεκριµένη µέρα. Σε προηγούµενο σχήµα φαίνεται ο συσχετισµός των bits και των τιµών Time Difference Αναπαριστά ένα χρόνο σε µέρες, ώρες seconds και milliseconds. Η δοµή του τύπου Time Difference φαίνεται σε προηγούµενο σχήµα Lonworks Wrapper Η µετατροπή των δεδοµένων ενός Lonworks κόµβου σε items του εικονικού δικτύου απαιτεί τον πλήρη έλεγχο των δεδοµένων εισόδου και εξόδου του κόµβου και είναι εξαρτώµενη από την συσκευή. Οι ιδιότητες των δεδοµένων αυτών λαµβάνονται από το αρχείο περιγραφής του κόµβου που προσφέρει η κάθε κατασκευαστική εταιρία. Όπως φαίνεται από την αρχιτεκτονική του συστήµατος ο Lonworks wrapper είναι υπεύθυνος για την µετατροπή των δεδοµένων ενός κόµβου σε διακριτά αντικείµενα που αποτελούν τις µεταβλητές του εικονικού δικτύου. Ο χρήστης µπορεί και ελέγχει τα διακριτά αυτά items αλλά η µετατροπή τους και η ανάγνωση ή η εγγραφή στους κόµβους είναι µια διαφανείς διαδικασία απέναντι του. Ο wrapper γνωρίζει τον συσχετισµό των αντικειµένων µε τις πραγµατικές συσκευές µέσω της αρχικοποίησης που του γίνεται από το εργαλείο του µηχανικού.

115 ΑΡΤΙΟ Τελική έκθεση 115 Για την πιλοτική εφαρµογή του συστήµατος ορίστηκαν τόσο οι ιδιότητες του αντικειµένου όσο και οι ξεχωριστές ιδιότητες που θα πρέπει να έχει το κάθε αντικείµενο που αφορά ένα δίκτυο Lonworks. Σε προηγούµενο κεφάλαιο αναφερθήκαµε στους τύπους των τιµών που υποστηρίζει το Lonworks. Παρακάτω θα δείξουµε την υλοποίηση σε γλώσσα C των τύπων αυτών και την χρήση τους στην πιλοτική εφαρµογή της διασύνδεσης των δύο δικτύων. Στην εφαρµογή υλοποιήθηκε η χρήση των πιο συνηθισµένων αριθµητικών τύπων (INT, UINT) και των αναλογικών και ψηφιακών τιµών. Ο Wrapper ενηµερώνει συνεχώς µια λίστα µε τα αντικείµενα που έχουν οριστεί από το εργαλείο του µηχανικού. Τα αντικείµενα αυτά είναι οι διακριτές τιµές των µεταβλητών του εικονικού δικτύου. Σε αυτό το κοµµάτι της εφαρµογής θα εξηγήσουµε µερικά από τα χαρακτηριστικά των αντικειµένων αλλά θα δώσουµε έµφαση στην σχέση που έχουν τα αντικείµενα µε τα πραγµατικά δεδοµένα που κυκλοφορούν στο δίκτυο. Στην πιλοτική εφαρµογή ο Lonworks wrapper υλοποιεί τους τύπους τιµών DIGITAL, FLOAT, ANALOG όπως αυτοί παρουσιάζονται στις προηγούµενες ενότητες οµές δεδοµένων για την λειτουργία του LONWORKS Wrapper Οι δοµές που αναπτύχθηκαν για την λειτουργία του LONWORKS wrapper φαίνονται στο επόµενο σχήµα και εξηγούνται στις επόµενες παραγράφους: Σχήµα 41.Οι δοµές του Lonworks Wrapper.

116 ΑΡΤΙΟ Τελική έκθεση οµή VARIABLE_LIST / VARIABLE Η δοµή αυτή χρησιµοποιείται από την εφαρµογή για την δηµιουργία της λίστας µε τις τιµές των διακριτών µεταβλητών του δικτύου. Με αυτή την δοµή µπορούµε να έχουµε πρόσβαση σε κάθε µεταβλητή αφορά το LONWORKS δίκτυο. οµή VARIABLE_LIST Περιγραφή: Είναι η δοµή στην οποία αποθηκεύονται τα διακριτά αντικείµενα του εικονικού δικτύου που έχουν σχέση µε το LONWORKS. Υλοποιήθηκε σαν µια λίστα από pointers στην δοµή ITEM και συνοδεύεται από τις απαραίτητες συναρτήσεις για την διαχείριση της λίστας. Attributes Όνοµα Τύπος Περιγραφή ItemPos USIGN16 είχνει την θέση του item pointer µέσα στην Λίστα PItem ITEM * είκτης στο Item PNext VARIABLE * είκτης στο επόµενο στοιχείο της λίστας PPrev VARIABLE * είκτης στο προηγούµενο στοιχείο της λίστας Functions Όνοµα CreateVariableList AddItem GetVariableByPos Περιγραφή εσµεύει την µνήµη για την δηµιουργία µιας άδειας λίστας. Επιστρέφει τον δείκτη στο πρώτο (άδειο) αντικείµενο της λίστας αυτής. Προσθέτει ένα αντικείµενο τύπου pitem στην λίστα. Επιστρέφει την θέση του αντικειµένου Επιστρέφει το στοιχείο της λίστας που βρίσκεται σε συγκεκριµένη θέση GetVariableByItemID Επιστρέφει το στοιχείο της λίστας που του οποίου το item έχει συγκεκριµένο ID GetVariabeByItemName Επιστρέφει το στοιχείο της λίστας που του οποίου το item GetItemByPos GetItemByID GetItemByName SetItemByPos SetItemByID SetItemByName DelItemByPos έχει συγκεκριµένο όνοµα Επιστρέφει τον δείκτη στο item το οποίο βρίσκεται σε συγκεκριµένη θέση στην λίστα. Επιστρέφει τον δείκτη στο item το οποίο έχει συγκεκριµένο ID. Επιστρέφει τον δείκτη στο item το οποίο έχει συγκεκριµένο όνοµα. Θέτει τον δείκτη του item που βρίσκεται σε συγκεκριµένη θέση σε άλλη τιµή Θέτει τον δείκτη του item που έχει συγκεκριµένο ID σε άλλη τιµή Θέτει τον δείκτη του item που έχει συγκεκριµένο όνοµα σε άλλη τιµή ιαγράφει τον δείκτη του Item που βρίσκεται σε συγκεκριµένη θέση στην λίστα. ( εν διαγράφει το στοιχείο της λίστας)

117 ΑΡΤΙΟ Τελική έκθεση 117 DelItemByID DelItemByName ιαγράφει τον δείκτη του Item που έχει συγκεκριµένο ID. ( εν διαγράφει το στοιχείο της λίστας) ιαγράφει τον δείκτη του Item που έχει συγκεκριµένο όνοµα. ( εν διαγράφει το στοιχείο της λίστας) οµή ITEM_INFO οµή ITEM_INFO Attributes Περιγραφή: οµή που περιέχει τα χαρακτηριστικά της µεταβλητής, όπως τον τύπο της το µέγεθος της κλπ. Όνοµα Τύπος Περιγραφή ItemType TYPE_ID ηλώνει τον τύπο στον οποίο ανήκει η µεταβλητή. Ο τύπος αυτός είναι ένας από τους γενερικούς τύπους που έχουν οριστεί για το εικονικό δίκτυο. Έχουν υλοποιηθεί οι εξής τύποι δεδοµένων: ID_USIGN8 ID_USIGN16 ID_INT8 ID_INT16 ID_FLOAT itemstatus OCTET[x] ηλώνει την κατάσταση της τιµής της µεταβλητής. itemlength USIGN8 ηλώνει το µέγεθος της µεταβλητής σε BYTES units USIGN16 ηλώνει το είδος των µονάδων που συνοδεύουν την τιµή της µεταβλητής. pitemvalue void * είκτης στην δοµή που περιέχει την τιµή της µεταβλητής καθώς και την ανώτερη και την ελάχιστη τιµή που µπορεί να πάρει αυτή. Συναρτήσεις για τον έλεγχο της δοµής ITEM_INFO Συνάρτηση InitItemInfo CreateItemInfoDefault CreateItemInfoOfTypeID GetItemInfoItemValue ChangeItemInfoTypeID Περιγραφή: Αρχικοποιεί µια δοµή ITEM_INFO εσµεύει χώρο στην µνήµη για µια µεταβλητή τύπου USIGN8, αρχικοποιεί την δοµή ITEM_INFO και επιστρέφει τον δείκτη στην δοµή. εσµεύει χώρο στην µνήµη για µια µεταβλητή συγκεκριµένου τύπου, αρχικοποιεί την δοµή ITEM_INFO και επιστρέφει τον δείκτη στην δοµή. Παίρνει την τιµή από την µεταβλητή. Επιστρέφει τιµή για την επιτυχία της ενέργειας Αλλάζει τον τύπο της µεταβλητής σε κάποιον άλλο επιθυµητό. Επιστρέφει τιµή για την επιτυχία της ενέργειας. Ο δείκτης pitemvalue δείχνει απ ευθείας σε κάποιο είδος µεταβλητής ώστε να αποθηκεύεται εκεί τη τιµή της µεταβλητής και τα όρια της. Επειδή έχουµε υλοποιήσει

118 ΑΡΤΙΟ Τελική έκθεση 118 τις µεταβλητές µε δείκτες πρέπει να δεσµεύσουµε την απαραίτητη µνήµη κάθε φορά ώστε να τοποθετήσουµε την τιµή της µεταβλητής. Για τον σκοπό αυτό χρησιµοποιούµε τις δύο συναρτήσεις : Συνάρτηση Περιγραφή: CreateItemValueOfTypeID Συνάρτηση που δεσµεύει τον απαραίτητο χώρο στην µνήµη για την µεταβλητή και επιστρέφει την διεύθυνση στην µνήµη στην οποία καταχωρείται η µεταβλητή. CreateItemValueDefault ηµιουργεί µια µεταβλητή τύπου USIGN οµή ITEM Η δοµή ITEM περιλαµβάνει τα στοιχεία που χρειάζεται το εικονικό δίκτυο για να διακρίνει τις µεταβλητές, καθώς και τις συναρτήσεις εκείνες που χρειάζονται για τον έλεγχο των τιµών αυτών. Κάθε δοµή ITEM εκτός από τις βασικές της ιδιότητες περιέχει και ένα δείκτη στην δοµή ITEM_INFO που περιέχει τις ιδιότητες της µεταβλητής που έχουν να κάνουν µε τον τύπο της. ITEM οµή Attributes Περιγραφή: Κάθε ένα αντικείµενο αυτής της δοµής αντιπροσωπεύει µια µοναδική γενερική µεταβλητή που κυκλοφορεί στο δίκτυο. Όνοµα Τύπος Περιγραφή itemid USIGN16 Αριθµός αναγνώρισης της µεταβλητής στο εικονικό δίκτυο. Ο αριθµός αυτός πρέπει να είναι µοναδικός για κάθε µεταβλητή του δικτύου. itemname OCTET[x] Κείµενο που δηλώνει το όνοµα της µεταβλητής. Επίσης το όνοµα πρέπει να είναι µοναδικό για κάθε µεταβλητή. piteminfo ITEM_INFO * είκτης στην δοµή που δηλώνει τα χαρακτηριστικά της µεταβλητής pitemnetinfo ITEM_NET_INFO * είκτης στην δοµή που συνδέει την µεταβλητή µε κάποια πραγµατική συσκευή του δικτύου LONWORKS Οι γενικές συναρτήσεις που υλοποιήθηκαν για την δηµιουργία του αντικειµένου ITEM και τον έλεγχο των βασικών ιδιοτήτων του είναι οι εξής: Συνάρτηση ResetItem CreateItemDefault CreateItemOfTypeID SetItemID Περιγραφή: Αρχικοποιεί το ITEM ηµιουργεί ένα ITEM που αντιπροσωπεύει µια µεταβλητή τύπου USIGN8 ηµιουργεί ένα ITEM που αντιπροσωπεύει µια µεταβλητή συγκεκριµένου τύπου Θέτει το ID του ITEM

119 ΑΡΤΙΟ Τελική έκθεση 119 GetItemID GetItemName SetItemName SetItemValue GetItemValue SetItemUpper GetItemUpper SetItemLower GetItemLower SetItemValueStruct GetItemValueStruct GetItemItemInfoPointer GetItemItemInfo ChangeItemTypeID Επιστρέφει το ID του ITEM Θέτει το όνοµα του ITEM Επιστρέφει το όνοµα του ITEM Θέτει την τιµή της µεταβλητής του ITEM (όταν γνωρίζουµε τον τύπο της) Επιστρέφει την τιµή της µεταβλητής του ITEM (όταν γνωρίζουµε τον τύπο της) Θέτει την µέγιστη τιµή της µεταβλητής του ITEM Επιστρέφει την µέγιστη τιµή της µεταβλητής του ITEM Θέτει την ελάχιστη τιµή της µεταβλητής του ITEM Επιστρέφει την ελάχιστη τιµή της µεταβλητής του ITEM Θέτει την τιµή της µεταβλητής του ITEM (όταν δεν γνωρίζουµε τον τύπο της) Επιστρέφει την τιµή της µεταβλητής του ITEM (όταν δεν γνωρίζουµε τον τύπο της) Επιστρέφει τον τιµή του δείκτη piteminfo Επιστρέφει το περιεχόµενο του δείκτη piteminfo Αλλάζει το είδος της µεταβλητής δίνοντας της έναν άλλο τύπο Ο δείκτης pitemnetinfo περιέχει τα χαρακτηριστικά που συνδέουν την τιµή του εικονικού αντικειµένου µε την τιµή του σε κάποια πραγµατική συσκευή του δικτύου. Ο δείκτης αυτός είναι εξαρτώµενος από το δίκτυο και θα έχει διαφορετική µορφή ανάλογα µε το δίκτυο στο οποίο αναφέρεται η µεταβλητή. Έγινε υλοποίηση των περιεχοµένων του δείκτη για το δίκτυο LONWORKS οµή ITEM_NET_INFO. Η δοµή αυτή περιλαµβάνει τα χαρακτηριστικά εκείνα που καθορίζουν την θέση της µεταβλητής σε µια συσκευή του δικτύου. Μπορούµε να χωρίσουµε τα χαρακτηριστικά αυτά σε δύο κατηγορίες: DIRECTION : Όπου καθορίζεται αν η µεταβλητή παράγεται ή καταναλώνεται στο LONWORKS ITEM_POS: Όπου καθορίζεται η ακριβής θέση της µεταβλητής στη συσκευή καθώς και η αναπαράσταση της στο LONWORKS. Όνοµα Περιγραφή: ITEM_DIRECTION Παίρνει τρεις τιµές που δηλώνουν : Η µεταβλητή καταναλώνεται στο LONWORKS Η µεταβλητή παράγεται στο LONWORKS εν έχει οριστεί ακόµα το είδος της µεταβλητής. οµή Περιγραφή: ITEM_NODE_INFO Attributes Όνοµα Τύπος Περιγραφή NodeAddress USIGN8 είχνει σε ποια συσκευή καταναλώνεται ή παράγεται η µεταβλητή

120 ΑΡΤΙΟ Τελική έκθεση 10 Offset USIGN16 είχνει πια θέση στην διάταξη των µεταβλητών της συσκευής έχει η µεταβλητή Lenth USIGN8 είχνει τον αριθµό των bytes των δεδοµένων Τα παραπάνω στοιχεία λαµβάνονται από τον έλεγχο του αρχείου περιγραφής του κόµβου. Το εργαλείο του µηχανικού µε ανάλυση του αρχείου περιγραφής θα πρέπει να είναι σε θέση να δώσει αρχικές τιµές σε αυτά τα στοιχεία και στην συνέχεια µε χρήσητου API να γίνει η ανάγνωση και η εγγραφή της τιµής οµή και λειτουργία του LONWORKS wrapper Ο Lonworks wrapper υλοποιήθηκε ως ένα process στο LINUX. Η επικοινωνία του µε τα άλλα process γίνεται µέσα από RTFIFOS όπως αυτό εξηγείται στην αρχιτεκτονική του συστήµατος. Στην πιλοτική εφαρµογή υποθέτουµε ότι οι δοµές µε τις λίστες των µεταβλητών που παρουσιάστηκαν πιο πάνω είναι έτοιµες για να χρησιµοποιηθούν (δηµιουργούνται αυτόµατα κατά την αρχικοποίηση του συστήµατος). Στην συνέχεια µε χρήση του Driver της Gesytec το δίκτυο αρχικοποιείται και τίθεται σε λειτουργία. Με την γνώση που έχει ο wrapper για τον συσχετισµό των µεταβλητών του δικτύου και των συσκευών του δικτύου ενηµερώνονται τόσο οι κόµβοι του Lonworks µε τις καινούργιες τιµές εξόδου όσο και το υπόλοιπο σύστηµα µε τις ανανεωµένες τιµές εισόδου. Η πιλοτική εφαρµογή είχε ως σκοπό την διασύνδεση δύο οµοειδών LONWORKS δικτύων τα οποία ελέγχονται από αντίστοιχες κάρτες Easylon της Gesytec σε δυο αποµακρυσµένους υπολογιστές που συνδέονται µεταξύ τους µέσω ενός ATM switch. Το process που υλοποιεί τον wrapper αποτελείται από 4 κυρίως threads. Στην αρχή γίνεται η αρχικοποίηση του συστήµατος και στην συνέχεια αυτά τα 4 threads αναλαµβάνουν την διακίνηση και µετατροπή της πληροφορίας. Προκειµένου να µην είναι το σύστηµα συνεχώς φορτωµένο µε τιµές που έχουν αποσταλεί προηγουµένως και δεν έχουν ακόµα αλλάξει επιλέχτηκε η χρήση σηµάτων µεταξύ των διαφόρων threads. Με την δηµιουργία ενός σήµατος η καινούργια τιµή ελέγχεται σε σχέση µε την παλιά και αποστέλλεται µονάχα όταν είναι διαφορετική από την υπάρχουσα. Προκειµένου να γίνει αυτός ο έλεγχος ο wrapper δηµιουργεί µια ενδιάµεση µνήµη στην οποία αποθηκεύει όλα τα items µε τις τιµές τους.

121 ΑΡΤΙΟ Τελική έκθεση 11 Αρχικοποίηση Λιστών Αρχικοποίηση Ενδιάµεσης µνήµης Άνοιγµα Καναλιών Επικοινωνίας (FIFOS, QUEES) Ορισµός των ITEMS και τοποθέτηση τους στην λίστα Αρχικοποίηση του LonWorks (Άνοιγµα του protocol stack) (Ορισµός των παραµέτρων του δικτύου) (Ορισµός των κόµβων) Ανάκτηση της δοµής ITEM_INFO και τοποθέτηση της στην λίστα µε τα ITEMS Αρχικοποίηση της ενδιάµεσης µνήµης βασισµένη στα ITEMS (τοποθέτηση των δεικτών των ITEMSγια γρήγορη πρόσβαση) Ενεργοποίηση του thread WriteLON Ενεργοποίηση του thread ReadFifo Ενεργοποίηση του thread WriteFifo Ενεργοποίηση του thread ReadLON Έλεγχος για τερµατισµό των threads και έξοδος όταν γίνει αυτό Το block διάγραµµα λειτουργίας του wrapper φαίνεται στο διπλανό σχήµα. Στην εφαρµογή η αρχικοποίηση των λιστών µε τα ITEMS γίνεται από τον χρήστη. Πιο γενικά όµως η δοµή αυτή θα πρέπει να προσφέρεται µε χρήση των απαραίτητων υπηρεσιών µέσα από το περιβάλλον ελέγχου του wrapper. Η αρχικοποίηση του Lonworks προϋποθέτει την ύπαρξη δοµών απαραίτητων στο δίκτυο οι οποίες θα πρέπει να προσφέρονται επίσης από την εφαρµογή ελέγχου του wrapper. Μετά την αρχικοποίηση του Protocol stack και την ενεργοποίηση των παραµέτρων των slave που υπάρχουν στο δίκτυο η εφαρµογή µπορεί να ανακτήσει την απαραίτητη πληροφορία σχετικά µε τις θέσεις των δεδοµένων εισόδου-εξόδου του δικτύου και να συµπληρώσει την δοµή ελέγχου του κάθε item. Η ενδιάµεση µνήµη που δηµιουργείται χρησιµεύει για την αποθήκευση των προσωρινών τιµών εισόδου ή εξόδου, τον ορισµό των κόµβων που παίρνουν µέρος στην διαδικασία (ενώ λειτουργεί σαν ένα container όλων των δεικτών των item ώστε να είναι δυνατός ο έλεγχος τους µε κριτήριο τον κόµβο στον οποίο ανήκει το item). Με το πέρας της αρχικοποίησης ο wrapper γνωρίζει οτιδήποτε είναι απαραίτητο για να ξεκινήσει την διαδικασία εγγραφής και ανάγνωσης, έτσι ενεργοποιούνται τα τέσσερα threads που εξυπηρετούν αυτή την επικοινωνία.

122 ΑΡΤΙΟ Τελική έκθεση 1 Το thread WriteLON χρησιµοποιεί το API που έχει γραφτεί για την κάρτα έτσι ώστε να γράψει στον εκάστοτε κόµβο την τιµή της µεταβλητής όποτε αυτό κριθεί απαραίτητο. Το thread ReadFifo υλοποιεί την επικοινωνία µε το υπόλοιπο σύστηµα. Σε αυτό έρχεται η πληροφορία σχετικά µε το item που πρέπει να εγγραφεί στο LON και την τιµή του. Η τιµή ελέγχεται σε σχέση µε την προηγούµενη και αν είναι διαφορετική εγγράφεται στην ενδιάµεση µνήµη. Από εκεί µεταφέρεται στον κόµβο από το thread WriteLON. Το thread ReadLON αναλαµβάνει να ενηµερώσει την ενδιάµεση µνήµη µε τα δεδοµένα εισόδου. Αν κάποια τιµή είναι διαφορετική το thread WriteFifo ενεργοποιείται για να περάσει αυτή την τιµή στο υπόλοιπο σύστηµα. Ο µηχανισµός αυτός και η εσωτερική λειτουργία του κάθε thread φαίνεται στο επόµενο block διάγραµµα InterThread Communication Τα threads εν γένει µπορούν να λειτουργούν ανεξάρτητα το ένα από το άλλο, προκειµένου όµως να καταµεριστεί ο χρόνος χρήσης της cpu οµοιόµορφα έτσι ώστε τα δυο threads που υλοποιούν την ανάγνωση από το DP και την ανάγνωση από το σύστηµα να χρησιµοποιούν το µεγαλύτερο χρόνο ενώ τα άλλα δυο να λειτουργούν µόνο όταν αυτό είναι απαραίτητο, επιλέχθηκε τα threads να επικοινωνούν µεταξύ τους µε έναν µηχανισµό µηνυµάτων. Ο µηχανισµός αυτός φαίνεται στο επόµενο σχήµα. (R_LON) ReadLON WriteLON (W_FIFO,Address) (R_FIFO) (R_LON) (W _LON, Address) WriteFifo ReadFifo (R_FIFO) Σχήµα 4.Ο µηχανισµός επικοινωνίας των threads. Τα δύο threads ReadLON και ReadFifo εναλλάσσονται µεταξύ τους και χρησιµοποιούν τα υπόλοιπα µόνο όταν τα δεδοµένα που λαµβάνουν είναι διαφορετικά από τα υπάρχοντα.

123 ΑΡΤΙΟ Τελική έκθεση 13 Το thread ReadLON λαµβάνει τα δεδοµένα από τον κόµβο για κάθε κόµβο ξεχωριστά. Στην συνέχεια τα συγκρίνει µε τα δεδοµένα που διάβασε την προηγούµενη φορά. Τα δεδοµένα εδώ βρίσκονται στην µορφή που καθορίζει το Lonworks ανεξάρτητα από τα items που έχουν οριστεί. Όταν τα δεδοµένα είναι διαφορετικά τότε ενεργοποιείται το thread WriteFifo. Το µήνυµα που το ενεργοποιεί έχει ως παράµετρο την διεύθυνση του κόµβο που έχει τα διαφορετικά δεδοµένα. Με την βοήθεια αυτής της παραµέτρου το WriteFifo θα ελέγξει ένα ένα τα items που συνδέονται µε αυτόν τον κόµβο και στην συνέχεια όταν η τιµή κάποιου item βρεθεί διαφορετική από την προηγούµενη αυτό και µόνο αυτό θα περάσει στο υπόλοιπο σύστηµα µέσω της fifo. Μετά το πέρας του ελέγχου όλων των item που σχετίζονται µε τον κόµβο ενεργοποιείται το ReadFifo. Αυτό µε την σειρά του θα ενεργοποιήσει το ReadLON αν δεν λάβει κανένα µήνυµα από το εξωτερικό σύστηµα ή θα λάβει κάποιο µήνυµα που αφορά την τιµή ενός item. Η τιµή αυτή θα ελεγχθεί σε σχέση µε την προηγούµενη και µόνο όταν είναι διαφορετική θα µετατραπεί στην µορφή που ορίζει το Lonworks και θα τοποθετηθεί στην ενδιάµεση µνήµη. Στην συνέχεια θα ενεργοποιηθεί το WriteLON µε παράµετρο τον κόµβο του οποίου τα δεδοµένα πρέπει να αλλάξουν ώστε να γραφτούν αυτά στο LON. Από τα παραπάνω φαίνεται ότι η ενδιάµεση µνήµη που χρησιµοποιείται περιλαµβάνει όλες τις τιµές εισόδων και εξόδων τόσο στην µορφή που καθορίζει το Lonworks όσο και στην µορφή που καθορίζεται από το γενερικό σύστηµα. Το thread WriteLON γράφει κάθε φορά ολόκληρο το frame των δεδοµένων εξόδου του κόµβου ενώ το ReadLON διαβάζει ολόκληρο το frame των δεδοµένων εισόδου. Αυτό γίνεται διότι η επανάληψη πολλών read για µεµονωµένα κοµµάτια που αντιπροσωπεύουν ένα αντικείµενο τελικά δηµιουργεί καθυστερήσεις στο σύστηµα. Επίσης θα πρέπει να τονιστεί ότι όλα τα threads έχουν πρόσβαση σε µια κοινή µνήµη. Για να αποφευχθούν conflicts χρησιµοποιούνται semaphores ώστε κάθε φορά ένα µόνο thread να έχει την αποκλειστική πρόσβαση στην κοινή µνήµη Thread ReadLON To thread ενεργοποιείται και βρίσκεται στην αναµονή ενός µηνύµατος µε τύπο R_LON (read_lon) αφού έχει θέσει ότι ο πρώτος κόµβος ο οποίος θα αναγνωστεί έχει την διεύθυνση µηδέν. Όταν αυτό το µήνυµα έρθει τότε από την κοινή µνήµη θα αντλήσει τις πληροφορίες που χρειάζεται για τον τρέχοντα κόµβο. ( οµή ITEM_INFO).

124 ΑΡΤΙΟ Τελική έκθεση 14 Start NodeAddress = 0 OXI Wait Msg msg type == R_DP NAI Node (NodeAddress) == Active inputdata > 0 ; Read Node Data OXI OXI current Node Data == previous Node Data NAI Copy Data to intermidiate memory Send Msg type R_FIFO Send Msg type (W_FIFO,Node Address) NodeAddress ++; if (NodeAddress > 16){ NodeAddress = 0;} Αν ο κόµβος έχει δηλωθεί ως active ( δηλαδή υπάρχουν items που σχετίζονται µε αυτόν) και αν έχει δεδοµένα εισόδου τότε αυτά τα δεδοµένα θα διαβαστούν. Στην συνέχεια θα συγκριθούν µε τα υπάρχοντα στην κοινή µνήµη (πάντα σε επίπεδο πακέτων Lonworks). Αν τα δεδοµένα είναι τα ίδια τότε θα ενεργοποιηθεί το thread ReadFifo Αν τα δεδοµένα είναι διαφορετικά σηµαίνει ότι κάποιο από τα items που σχετίζονται µε τον κόµβο έχει αλλάξει τιµή (δεν ξέρουµε ακόµα ποιο). Σε αυτή την περίπτωση τα δεδοµένα αντιγράφονται στην κοινή µνήµη και ενεργοποιείται το thread WriteFifo µε παράµετρο την διεύθυνση του κόµβου.

125 ΑΡΤΙΟ Τελική έκθεση 15 Με την έξοδο του το thread καθορίζει ότι την επόµενη φορά που θα ενεργοποιηθεί θα ελεγχθεί ο επόµενος κατά σειρά κόµβου Thread WriteFifo Το thread ξεκινάει και τίθεται σε αναµονή ενός µηνύµατος µε τύπο W_FIFO και παράµετρο την διεύθυνση κάποιου κόµβου. Όταν το µήνυµα αυτό έρθει ελέγχει ένα ένα τα items που σχετίζονται µε αυτή την διεύθυνση. Για κάθε item κάνει την µετατροπή από το LONWORKS στο IEC της τιµής της µεταβλητής. Στην συνέχεια η τιµή αυτή συγκρίνεται µε την προηγούµενη. Αν αυτή είναι διαφορετική τότε το item γράφεται στην fifo. Το thread ενεργοποιεί το R_FIFO όταν ελέγξει όλα τα items που σχετίζονται µε τον κόµβο. Start OXI Wait Msg msg type == W_FIFO NAI Get Node Address take first item of Node ProfiToItem current Item vallue == previous Item value take next Item OXI W rite Item to fifo NAI NAI more items? OXI Send MSG (R_FIFO) Thread ReadFifo Το thread βρίσκεται σε αναµονή ενός µηνύµατος τύπου R_FIFO. Στην συνέχεια θα προσπαθήσει να ελέγξει αν στην fifo έχει έρθει κάποιο item. Το ID του item θα δώσει στο thread την απαραίτητη πληροφορία για να αντλήσει από την κοινή µνήµη τις παραµέτρους που χρειάζονται για τον έλεγχο του item.

126 ΑΡΤΙΟ Τελική έκθεση 16 Η τιµή του item που έχει έρθει θα συγκριθεί µε την προηγούµενη. Στην συνέχεια και αν είναι διαφορετική θα µεταφρασθεί στην αναπαράσταση του Lonworks και θα ενσωµατωθεί στο πακέτο µε τα δεδοµένα εξόδου του αντίστοιχου Node µε το οποίο είναι συνδεδεµένο. Στην συνέχεια θα ενεργοποιηθεί το thread WriteDP για να γράψει ολόκληρο το πακέτο στον Node. Start NodeAddress = 0 OXI Wait Msg msg type == R_FIFO NAI current IEC vallue == previous IEC value OXI IEC To PROFI NAI Send Msg type (W_DP, NodeAddress) Send Msg type R_FIFO Thread WriteDP Το thread ξεκινάει µε την αναµονή ενός µηνύµατος τύπου W_LON. Όταν αυτό έρθει θα ληφθεί ως παράµετρος η διεύθυνση του Node στον οποίο πρέπει να γίνει η εγγραφή. Τα δεδοµένα τα οποία θα γραφτούν στον slave θα ληφθούν από την ενδιάµεση µνήµη στην οποία έχουν τοποθετηθεί από το προηγούµενο thread. Τα δεδοµένα θα γραφτούν στον σωστό Node και στην συνέχεια θα ενεργοποιηθεί το thread R_DP.

127 ΑΡΤΙΟ Τελική έκθεση 17 Start OXI Wait Msg msg type == W_LON NAI Get NodeAddress Get Data to be written Write Data Send MSG (R_LON) οµή της ενδιάµεσης µνήµης Όπως ειπώθηκε παραπάνω κατά την αρχικοποίηση δηµιουργείται µια ενδιάµεση µνήµη µέσω της οποίας µπορούµε να έχουµε πρόσβαση τόσο στα χαρακτηριστικά των item όσο και στα χαρακτηριστικά των Node του δικτύου. Η ενδιάµεση αυτή µνήµη συγκεντρώνει όλες τις απαραίτητες πληροφορίες ή τους δείκτες προς τις πληροφορίες και η δοµή της φαίνεται στο επόµενο σχήµα. Node 0 Node Active Node Info address offset Length LonWorks Data num Items num Items pitem 1 pitem Σχήµα 43.Η δοµή της ενδιάµεσης µνήµης. Στο επόµενο σχήµα φαίνεται αναλυτικότερα επίσης η δοµή ενός pointer σε item.

128 ΑΡΤΙΟ Τελική έκθεση 18 pitem 1 itemid item Name piteminfo itemtype itemstatus itemlength units pitemvalue value pitemnetinfo direction Node Info upper lower Node address offset Length Σχήµα 44.Η δοµήενός pointer σε item. 7 Υλοποίηση OPC server 7.1 Γενικά Η προδιαγραφή OPC προσφέρει ένα τυποποιηµένο τρόπο για την εξαγωγή των παραµέτρων παρακάµπτοντας κλειστούς και ιδιοκτησιακούς τρόπους επικοινωνίας µεταξύ εφαρµογών και βιοµηχανικής διεργασίας. Η προδιαγραφή OPC που στηρίζεται στις τεχνολογίες COM και DCOM της Microsoft υπαγορεύει κατά κύριο λόγο το πλαίσιο προσπέλασης εφαρµογών σε δεδοµένα (data access) που αφορούν σε µια βιοµηχανική διεργασία κατά τη φάση εκτέλεσής της. Υπεύθυνος για την εξαγωγή των παραµέτρων από το δίκτυο πεδίου είναι ο OPC server. Αναλυτική αναφορά στο OPC γίνεται στη συνέχεια. Σήµερα οι περισσότεροι από τους κατασκευαστές βιοµηχανικού λογισµικού υποστηρίζουν τη τεχνολογία OPC στα προϊόντα τους. Σαν αποτέλεσµα η συντριπτική πλειοψηφία των clients που είναι διαθέσιµοι στην αγορά και επιτρέπουν παρακολούθηση και έλεγχο βιοµηχανικής διεργασίες είναι βασισµένοι στην OPC διεπαφή. Το γεγονός αυτό µας οδήγησε στην απόφαση να υιοθετήσουµε την OPC διεπαφή και να διατηρήσουµε συµβατότητα προς αυτή. Με λίγα λόγια το ΑΡΤΙΟ Gateway είναι OPC compliant. Η προδιαγραφή OPC υπαγορεύει κατά κύριο λόγο το πλαίσιο προσπέλασης εφαρµογών σε δεδοµένα (data access) που αφορούν σε µια βιοµηχανική διεργασία κατά τη φάση εκτέλεσής της. Τα δεδοµένα δηµιουργούνται σε πραγµατικό χρόνο από τη βιοµηχανική διεργασία (π.χ. ένας βρόχος ελέγχου PID). Η εποπτεία κρίσιµων παραµέτρων είναι επιτακτική ανάγκη σ ένα σύστηµα βιοµηχανικής αυτοµατοποίησης και ως εκ τούτου, η προδιαγραφή OPC δηµιουργεί ένα παράθυρο στην εξέλιξη της διεργασίας, για τη παρακολούθησή της, χωρίς βέβαια να παραβιάζει

129 ΑΡΤΙΟ Τελική έκθεση 19 η λειτουργία της. Με το τρόπο αυτό οι τιµές των παραµέτρων της διεργασίας εξάγονται από τη κλειστή νησίδα αυτοµατοποίησης και προσφέρονται σε εφαρµογές παρακολούθησης, ελέγχου, οπτικοποίησης και αποθήκευσης. Η προδιαγραφή OPC προσφέρει ένα µοναδικό και τυποποιηµένο τρόπο για την εξαγωγή των παραµέτρων παρακάµπτοντας κλειστούς και ιδιοκτησιακούς τρόπους επικοινωνίας µεταξύ εφαρµογών και διεργασίας. Η προδιαγραφή OPC στηρίζεται στις τεχνολογίες COM και DCOM της Microsoft. Συγκεκριµένα, υπεύθυνος για την εξαγωγή των παραµέτρων µε τη µορφή αντικειµένων είναι ο OPC server. Τυπικό είναι το σενάριο διαφορετικών OPC clients (όπως εφαρµογές Scada, Excel) να συνδέονται µέσω του δικτύου µε τον OPC server. Λόγω του ότι τα προϊόντα της Microsoft είναι αρκετά δηµοφιλή, ανάλογη είναι και η υιοθέτηση του OPC. Σήµερα οι περισσότεροι από τους κατασκευαστές βιοµηχανικού λογισµικού υποστηρίζουν τη τεχνολογία OPC στα προϊόντα τους. Στα πλαίσια του έργου, απαιτείται τόσο η παρακολούθηση δεδοµένων όσο και η παραµετροποίηση αυτών από απόσταση. Η προδιαγραφή OPC και το DCOM µας βοήθησαν στην δηµιουργία ενός διακοµιστή σε κάθε ένα από τα gateways του δικτύου που θέλουµε να ελέγξουµε. Επιπλέον, η από απόσταση παρακολούθηση του δικτύου (µέσο Internet) µας επιτραπεί, προσφέροντας σε clients που θα συνδεθούν στον διακοµιστή τόσο την δυνατότητα του ελέγχου όσο και την δυνατότητα διαµόρφωσης σε δεδοµένα που θα βρίσκονται στο δίκτυο. Ο client µπορεί να συνδεθεί στο gateway µέσω µιας OPC διεπαφής έτσι ώστε να παρέχει την δυνατότητα παρακολούθησης οποιασδήποτε συσκευής (ενεργοποιητή ή αισθητή), ενώ κατά την διαδικασία διαµόρφωσης του δικτύου µπορεί να ορίσει καινούριους βρόχους ελέγχου, από ένα δίκτυο πεδίου σε ένα άλλο. Το OPC µας επιτρέπει να πραγµατοποιήσουµε αυτή την διαδικασία διάφανα ως προς τον client κρύβοντας τις ιδιαιτερότητες του κάθε δικτύου πεδίου. Όπως είναι γνωστό το πρώτυπο OPC (OLE for Process Control) βασίζεται στην τεχνολογία COM(ActiveX) και DCOM (Distributed COM) της Microsoft. Το OPC σε πλατφόρµα Linux έχει αναπτυχθεί πρόσφατα και βασίζεται στην προδιαγραφή EntireX DCOM, προϊόν της εταιρείας Software AG. Είναι επέκταση της προδιαγραφής DCOM, που υλοποιήθηκε για Windows, για συστήµατα και εφαρµογές Unix, ώστε να επιτρέπει την ενσωµατωσή τους από τις επιχειρήσεις. Σε υψηλό επίπεδο, ένας OPC server αποτελείται από διάφορα αντικείµενα: τον server, την οµάδα (group), και το Item. Τo αντικείµενo του OPC server διατηρεί πληροφορίες σχετικά µε τον server και χρησιµεύει ως ένα σύνολο από OPC οµάδες. Οι OPC οµάδες διατηρούν τις πληροφορίες για τις ίδιες και παρέχουν τους µηχανισµούς συλλογής και λογικής οργάνωσης OPC Items. Οι OPC οµάδες παρέχουν έναν τρόπο οργάνωσης δεδοµένων προς τους χρήστες. Παραδείγµατος χάριν, η οµάδα µπορεί να αντιπροσωπεύει Items σε µια ιδιαίτερη συσκευή απεικόνισης ή αναφοράς. εδοµένα µπορούν να αναγνωσθούν και να γραφτούν. Συνδέσεις βασισµένες σε εξαιρέσεις µπορούν, επίσης, να δηµιουργηθούν µεταξύ του χρήστη και των αντικειµένων της οµάδας και µπορούν να επιτραπούν και να τεθούν εκτός λειτουργίας όπως απαιτείται. Ένας OPC χρήστης µπορεί να διαµορφώσει το ποσοστό από τις αλλαγές στοιχείων που παρέχει ένας OPC server στον OPC client. Υπάρχουν δύο τύποι οµάδων (group), οι δηµόσιες και οι τοπικές (Local). Οι δηµόσιες είναι υπεύθυνες για τη διανοµή σε πολλαπλούς χρήστες, ενώ οι τοπικές σε έναν χρήστη.

130 Fisher ΑΡΤΙΟ Τελική έκθεση Περιγραφή της προδιαγραφής OPC Η προδιαγραφή OPC όπως έχει ήδη αναφερθεί έχει σαν κύριο στόχο την προσπέλαση σε πολυπληθείς πηγές δεδοµένων που αφορούν βιοµηχανικές διεργασίες. Η αρχιτεκτονική της παρεχόµενης πληροφορίας σε βιοµηχανικό επίπεδο (επόµενο σχήµα) αποτελείται από τρία επίπεδα: ιαχείριση πεδίου (Field Management). Με την εµφάνιση των έξυπνων µηχανών ( smart field devices) δίνεται η δυνατότητα άντλησης µεγάλου αριθµού πληροφοριών, όπως η φυσική κατάσταση της µηχανής, οι παράµετροι διαµόρφωσής της, κλπ. Όλη αυτή η πληροφορία πρέπει να δίνεται στον χρήστη µε έναν µοναδικό και τυποποιηµένο τρόπο. ιαχείριση διεργασίας (Process Management). Με την εγκατάσταση των κατανεµηµένων συστηµάτων ελέγχου (DCS) και των SCADA εργαλείων παρέχεται η δυνατότητα ηλεκτρονικής συλλογής των δεδοµένων που έχουν σχέση µε την παρακολούθηση και έλεγχο των βιοµηχανικών διεργασιών. ιαχείριση εργασίας (Business Management). Με την εγκατάσταση των συστηµάτων ελέγχου τα κέρδη που µπορούν να αποκοµιστούν µπορεί να είναι πολλά. Αυτό µπορεί να επιτευχθεί µε την παροχή µε έναν µοναδικό και τυποποιηµένο τρόπο των αντλούµενων πληροφοριών που συλλέγονται από µια βιοµηχανική διεργασία, στα συστήµατα εργασίας τα οποία είναι υπεύθυνα για την διαχείριση της διεργασίας. Windows 3.1 Windows-95 Windows NT Client Applications Windows NT Operator Console Windows NT RT/History Data Server Process Management Fieldbus Measurement -Pressure -Temp -Flow -Level Valves Positioners Coriolis PD Meters Common Head Analytical -Simple -Analog I/O -Complex-Discrete I/O -TC/RTD Field Management Handheld PDA Configuration and Maintenance Σχήµα 45. Αρχιτεκτονική της πληροφορίας ελέγχου βιοµηχανικής διεργασίας Όπως έχει ήδη αναφερθεί αυτό που χρειάζεται είναι ένας µοναδικός και τυποποιηµένος τρόπος µε τον οποίο οι εφαρµογές να µπορούν να προσπελαύνουν

131 ΑΡΤΙΟ Τελική έκθεση 131 δεδοµένα από οποιαδήποτε πηγή δεδοµένων. Αυτός είναι και ο βασικός σκοπός για τον οποίο σχεδιάστηκε η προδιαγραφή OPC. Η τρέχουσα έκδοση της προδιαγραφής OPC έχοντας σαν βασικό σκοπό την λειτουργικότητα που παρέχεται σε βιοµηχανικό επίπεδο εστιάζεται στα παρακάτω: Online DataAccess. Έχει σαν βασικό στόχο την αποτελεσµατική ανάγνωση/εγγραφή των δεδοµένων µεταξύ της εφαρµογής και της βιοµηχανικής διεργασίας ελέγχου. Alarm and Event Handling. Παρέχει τους µηχανισµούς ειδοποίησης στους OPC clients για την εµφάνιση συγκεκριµένων γεγονότων και συναγερµών. Historical Data Access. Έχει σαν βασικό στόχο την διαχείριση ιστορικών δεδοµένων µιας µηχανής. Μηχανισµοί όπως ασφάλεια και διαχείριση ιστορικών δεδοµένων που έχουν σχέση µε τα γεγονότα και τους συναγερµούς (historical alarm and event data access) δεν συµπεριλαµβάνονται στην τρέχουσα έκδοση της προδιαγραφής. 7.3 Βασικά στοιχεία της προδιαγραφής OPC Η προδιαγραφή OPC βασίζεται στις τεχνολογίες COM και DCOM της Microsoft. Η τρέχουσα προδιαγραφή περιγράφει τα OPC COM objects και οι διεπαφές, τα οποία υλοποιούνται από τους OPC servers. Άρα υπεύθυνος για την παροχή όλων των dεδοµένων που έχουν σχέση µε τη διεργασία, µε τη µορφή αντικειµένων είναι ο OPC server. Τυπικά είναι τα σενάρια διασύνδεσης ενός OPC client µε διαφορετικούς OPC servers, καθώς και διαφορετικών OPC clients στον ίδιο OPC server Περιγραφή του OPC DataAccess Σε υψηλό επίπεδο ένας OPC DataAccess server αποτελείται από τα ακόλουθα αντικείµενα : το server, το group και το item. Το αντικείµενο server παρέχει πληροφορίες σχετικές µε τον OPC server και λειτουργεί σαν container για το αντικείµενο group. Το αντικείµενο group παρέχει το µηχανισµό µε τον οποίο συνδέονται και οργανώνονται τα OPC items. Τα OPC groups δίνουν την δυνατότητα στους clients για οργάνωση των δεδοµένων τους. Τα δεδοµένα µπορούν απλώς να απεικονιστούν καθώς και να τροποποιηθούν. Είναι σηµαντικό να αναφερθεί ότι ο OPC client έχει τη δυνατότητα να καθορίσει τον ρυθµό µε τον οποίο ο OPC server του παρέχει τις µεταβολές των δεδοµένων. Υπάρχουν δύο τύποι από groups : τα public και τα local (ή private) groups. Τα public είναι αυτά που µπορούν να χρησιµοποιηθούν από πολλούς clients, ενώ τα local αυτά που µπορεί να χρησιµοποιήσει µόνο ένας client. Σε κάθε group, ένας OPC client µπορεί να ορίσει ένα ή περισσότερα OPC items. Η σχέση που υπάρχει ανάµεσα στο OPC group και στο OPC item αναπαριστάται στο επόµενο σχήµα.

132 ΑΡΤΙΟ Τελική έκθεση 13 Group Item 1 Item Item 3 Σχήµα 46. Σχέση OPC group και OPC item Τα OPC items αναπαριστούν τις συνδέσεις στις πηγές δεδοµένων του OPC server. Η προσπέλαση σε ένα OPC item γίνεται µέσω του αντικειµένου OPC group το οποίο περιέχει το συγκεκριµένο item Περιγραφή του OPC Alarm and Event Handling Αυτές οι διεπαφές παρέχουν τους µηχανισµούς µε τους οποίους οι OPC clients ενηµερώνονται για την εµφάνιση συγκεκριµένων γεγονότων και συναγερµών. Παρέχουν επίσης τις υπηρεσίες µε τις οποίες ένας OPC client µπορεί να καθορίσει κάποια από τα γεγονότα και τους συναγερµούς που υποστηρίζονται από τον OPC server και να ενηµερώνεται για την τρέχουσα κατάστασή τους. Στην προδιαγραφή OPC ένα συναγερµός (alarm) ορίζεται σαν µια µη φυσιολογική κατάσταση (abnormal condition) και κατά συνέπεια αποτελεί µια ειδική περίπτωση της κατάστασης. Σαν κατάσταση (condition) µπορεί να θεωρηθεί κάποια από τα αντικείµενα του OPC Event server τα οποία µπορούν να χρησιµοποιηθούν από τους OPC clients. Σαν γεγονός ορίζεται σαν ένα γεγονός προς επιτήρηση, το οποίο είναι µεγάλης σηµασίας για τον OPC server, για την µηχανή που αναπαριστά καθώς και για τους OPC clients που ενδιαφέρονται για την ενηµέρωση του συγκεκριµένου γεγονότος. Πρέπει να αναφερθεί ένα γεγονός µπορεί να συνδεθεί και µια κατάσταση. Η OPC server διεπαφή παρέχει µεθόδους µε τις οποίες ο OPC client µπορεί: να προσδιορίσει τους τύπους των γεγονότων που υποστηρίζει ο OPC server. να καθορίσει τα συγκεκριµένα γεγονότα για τα οποία µπορεί να ενηµερώνεται για την κατάστασή τους. να έχει πρόσβαση και δυνατότητα µεταβολής των καταστάσεων που υλοποιούνται από τον OPC server Περιγραφή του OPC Historical Data Access Οι µηχανές που είναι υπεύθυνες για την διαχείριση ιστορικών δεδοµένων παρέχουν την πληροφορία σε χρήστες που ενδιαφέρονται για αυτήν. Στην πραγµατικότητα όµως οι περισσότερες µηχανές ιστορικών δεδοµένων χρησιµοποιούν ιδιοκτησιακές διεπαφές για να παρέχουν την πληροφορία στους χρήστες. Αυτό έχει σαν αποτέλεσµα, η ανάπτυξη των client εφαρµογών να στηρίζεται στην εκάστοτε διεπαφή που παρέχει η κάθε εταιρία για την δυνατότητα προσπέλασης των δεδοµένων.

133 ΑΡΤΙΟ Τελική έκθεση 133 Εποµένως κρίνεται αναγκαίο να υπάρχει µια µοναδική και τυποποιηµένη διεπαφή µε το οποίο να δίνεται η δυνατότητα προσπέλασης σε διαφορετικές µηχανές ιστορικές δεδοµένων. Αυτός είναι και ο βασικός σκοπός που σχεδιάστηκε το OPC Historical Data Access interface. Οι τύποι δεδοµένων που υποστηρίζονται από Historical Data Access interface αποτελούνται από καθαρά ιστορικά δεδοµένα και προαιρετικά από υπολογιστικά δεδοµένα όπως µεγαλύτερο (max), µικρότερο(min), µέσος όρος (average) κλπ. Ακολουθώντας την λογική του Data Access interface, η µεταδιδόµενη πληροφορία από τον OPC server στους OPC clients πρέπει να δοµηθεί µε βάση την ιδέα των groups και των items. Μόνο που στην συγκεκριµένη περίπτωση δεν χρειάζεται η ενηµέρωση των δεδοµένων να γίνεται σε πραγµατικό χρόνο. Είναι αξιοσηµείωτο να αναφερθεί ότι στην συγκεκριµένη έκδοση της προδιαγραφής OPC δεν είναι πλήρως καθορισµένο το Historical Data Access interface Αρχιτεκτονική και δοµοστοιχεία του OPC Η προδιαγραφή OPC περιέχει δύο τύπους από διεπαφές. Τα Custom interfaces και τα Automation interfaces. Η συσχέτιση των παραπάνω τύπων διεπαφών µε τους OPC clients και servers φαίνεται στο επόµενο σχήµα. OPC I/F SCADA System Physical I/F Physical I/O Application OPC I/F OPC Server Physical I/F Physical I/O Σχήµα 47. OPC interfaces Από την προδιαγραφή OPC καθορίζονται οι COM διεπαφές, ως προς τον τρόπο χρησιµοποίησής τους από τους OPC clients και όχι ως προς τον τρόπο υλοποίησής τους. Σε αντιστοιχία µε τις υλοποιήσεις του COM, η αρχιτεκτονική του OPC βασίζεται στο γνωστό µοντέλο client-server µε βάση το οποίο ο OPC server παρέχει µια διεπαφή για την διαχείριση των OPC αντικειµένων. Η επικοινωνία µεταξύ του OPC client και του OPC server γίνεται µε την χρήση των καθορισµένων custom και automation interfaces. Οι OPC servers θα πρέπει να έχουν υλοποιηµένο το custom interface και προαιρετικά το automation interface. Σε πολλές περιπτώσεις παρέχεται ένας τυπικός automation interface wrapper, ο οποίος µπορεί να χρησιµοποιηθεί από συγκεκριµένους OPC clients. Στο επόµενο σχήµα δίνεται µια τυπική OPC αρχιτεκτονική.

134 ΑΡΤΙΟ Τελική έκθεση 134 VB Application OPC Automation Interface OPC Automation Local or Remote OPC Server (Shared by many clients) C++ Application OPC Custom Interface Server Data Cache Physical Device/ Data Σχήµα 48. Τυπική OPC αρχιτεκτονική 7.4 Χρήση του OPC server για την καταγραφή της λειτουργίας της εφαρµογής Το βασικό δοµικό στοιχείο της προδιαγραφής OPC είναι το Item. Ενα χαρακτηριστικό OPC ItemID µπορεί να είναι το FIC101.CV. Αυτό θα µπορούσε να αντιπροσωπεύει την παρούσα τιµή µιας εττικέτας ή ενός Function Block αποκαλούµενο FIC101. Το Function Block µπορεί να περιέχει τα όρια συναγερµών, ένα σηµείο σύνδεσης, παραµέτρους συντονισµού, καθώς επίσης παραποµπές τεκµηρίωσης, πληροφορίες συντήρησης, οθόνες οδηγιών και ένα απεριόριστο σύνολο άλλων λειτουργιών. Στην προτεινόµενη αρχιτεκτονική του έργου το δοµικό στοιχείο OPC Server βρίσκεται στην µονάδα αλληλεπίδρασης και ενεργοποιείται όταν ζητηθεί από κάποιον OPC client να συνδεθεί στην διαδικασία ελέγχου. Το OPC Server δοµικό στοιχείο λειτουργεί σαν wrapper ο οποίος παρέχει διεπαφή συµβατή µε την OPC προδιαγραφή. Οι απαιτήσεις που έχουµε από τον OPC Server είναι : - σύγχρονη / ασύγχρονη ανάγνωση / εγγραφή των δεδοµένων - ανανέωση των εγγραφών - δυνατότητα προώθησης των δεδοµένων σε clients όποτε του ζητηθεί - δυνατότητα να κρατάει τις αιτήσεις για απόκτηση δεδοµένων που έχει, σε ουρά και να τις εξυπηρετεί µε την σειρά που έχει δεχτεί τις αιτήσεις. - να προσφέρει µια ασφαλή διαδικασία κλεισίµατος. Για την επικοινωνία του OPC Server µε τα υπόλοιπα δοµικά στοιχεία της µονάδας διεργασίας υπάρχει ένας πίνακας συνδέσεων συµβάντων ECT (Event Connection Table).Όταν ο OPC Server ζητήσει να κάνει κάποιες εγγραφές στέλνει µια αίτηση στον δαίµονα ο οποίος θα χειριστεί το συµβάν. Παίρνει την αίτηση που έχει καταγραφεί στον ECT του OPC server και την προωθεί στο δοµικό στοιχείο προορισµού. Ο Πίνακας ιασύνδεσης εδοµένων (Data Connection Table, DCT) περιέχει την πληροφορία που πρέπει να συνοδεύει την διασύνδεση δεδοµένων από

135 ΑΡΤΙΟ Τελική έκθεση 135 Function Block εξόδου σε άλλα Function Block εισόδου και µπορεί να είναι κάποια τιµή, χρόνος, κατάσταση. Όταν ο OPC Server ζητήσει κάποιες εγγραφές, οι οποίες χρειάζονται πληροφορίες από άλλα δοµικά στοιχεία, κάνει µια αίτηση στον δαίµονα, εξυπηρέτησης. Όταν ο δαίµονας ειδοποιηθεί για την ύπαρξη των στοιχείων που ζητήθηκαν, προσπελαύνει στο ECT του server και µε την χρήση αυτής της πληροφορίας συλλέγει τα δεδοµένα από τον DCT και δηµιουργεί ένα πακέτο που στέλνει στο δοµικό στοιχείο προορισµού. 8 Υλοποίηση Σταθµών ικτύων Profibus, LonWorks Η ολοκληρωµένη αντιµετώπιση του προβλήµατος της διαλειτουργικότητας που διαπραγµατεύεται το παρόν πρόγραµµα απαιτεί την ύπαρξη σταθµών δικτύου πεδίου στους οποίους µπορεί να εκτελείται ο κώδικας του ΑΡΤΙΟ, δηλαδή ο κώδικας που υλοποιεί τα Function Blocks που παράγονται από το Εργαλείο Μηχανικού (στην περίπτωση της κατανεµηµένης αρχιτεκτονικής ελέγχου). Για το σκοπό αυτό απαιτείται η ύπαρξη της δυνατότητας δυναµικού προγραµµατισµού των σταθµών των διασυνδεδεµένων δικτύων πεδίου, κάτι που δεν είναι πάντα εφικτό, ιδιαίτερα για δίκτυα πεδίου όπου οι κόµβοι δεν είναι ανοιχτοί, δηλαδή δεν παρέχουν τη δυνατότητα προγραµµατισµού τους µε γενικού σκοπού λογισµικό που παράγεται για τις ανάγκες συγκεκριµένης εφαρµογής. Ως εκ τούτου, στα πλαίσια του ΑΡΤΙΟ, έγινε η ανάπτυξη ενός πρότυπου συστήµατος υλοποίησης προγραµµατιζόµενου σταθµού (εξαρτηµένου) για το δίκτυο Profibus, διότι για τους υπάρχοντες (στην αγορά) σταθµούς Profibus έχει υιοθετηθεί η κλειστή αρχιτεκτονική, γεγονός που εµποδίζει τον δυναµικό προγραµµατισµό τους. Συµπληρωµατικά, δίνονται οι κατευθύνσεις για την υλοποίηση σταθµού για το δίκτυο Lonworks, δεδοµένου ότι το δίκτυο Lonworks παρέχει µια ανοιχτή αρχιτεκτονική που επιτρέπει γενικά τον δυναµικό προγραµµατισµό τους. 8.1 Υλοποίηση Εξαρτηµένων (Slave) Σταθµών ικτύου Profibus Γενικά Το δίκτυο PROFIBUS (PROCESS FIELD BUS) αποτελεί το γερµανικό πρότυπο δικτύων πεδίου (DIN ,) και έχει υιοθετηθεί ως µέρος του αντίστοιχου Ευρωπαϊκού προτύπου (ΕΝ50170) για τις βιοµηχανικές επικοινωνίες. Στο πρότυπο αυτό περιγράφονται τα τεχνικά και λειτουργικά χαρακτηριστικά ενός σειριακού δικτύου το οποίο διασυνδέει κατανεµηµένους σταθµούς στο χαµηλότερο επίπεδο, δηλ. το επίπεδο µονάδων πεδίου µέχρι και το κατασκευαστικό επίπεδο (shop floor) ή επίπεδο κυττάρου (cell), όπως φαίνεται στο επόµενο σχήµα. Το σύστηµα περιέχει τόσο κύριους ή κεντρικούς (master) όσο και εξαρτηµένους σταθµούς (slaves). Ένας κεντρικός σταθµός είναι ικανός να ελέγχει το κανάλι µετάδοσης, π.χ. να µεταδίδει µηνύµατα χωρίς αίτηση, όταν έχει το δικαίωµα. Το δικαίωµα χρήσης του καναλιού (και επικοινωνίας µε τους εξαρτηµένους τους σταθµούς) οι κύριοι σταθµοί το αποκτούν µε την χρήση του πρωτοκόλλου κουπονιού (token). Οι κύριοι ονοµάζονται και ενεργοί σταθµοί και µπορεί να είναι PLC s, CNC s και ελεγκτές - κυττάρου. Ένας εξαρτηµένος (ή δευτερεύων) σταθµός είναι συνήθως µια απλή συσκευή, π.χ. αισθητές, ενεργοποιητές, και δεν έχει δικαίωµα χρήσης του καναλιού

136 ΑΡΤΙΟ Τελική έκθεση 136 παρά µόνο όταν απαντά ή επιβεβαιώνει µηνύµατα που προέρχονται από κάποιον κύριο σταθµό, ο οποίος µε τη χρήση του πρωτοκόλλου polling προσπελαύνει (επικοινωνεί µε) επιλεγµένους εξαρτηµένους σταθµούς Επιλογή Πλατφόρµας Υλοποίησης H φάση της µελέτης των εξαρτηµένων σταθµών Profibus που υπάρχουν στην αγορά, έδειξε ότι η κλειστή νοοτροπία που έχει εφαρµοστεί στην υλοποίησή τους δεν παρέχει τη δυνατότητα δυναµικού επαναπρογραµµατισµού τους και άρα τη τη γενικού σκοπού χρήση τους. Για αυτό το σκοπό αποφασίστηκε η υλοποίηση ενός έξυπνου εξαρτηµένου σταθµού, ο οποίος είναι δυνατό να επαναπρογραµµατίζεται, ώστε να είναι δυνατό να προγραµµατίζεται µε το ΑΡΤΙΟ λογισµικό. Με βάση τα παραπάνω εξετάστηκαν διάφορα σενάρια που θα εξασφάλιζαν απόλυτα ανοιχτή αρχιτεκτονική, όπως α) ανάπτυξη ενός πρότυπου ολοκληρωµένουσυστήµατος (System On A Chip), β) η ανάπτυξη ενός εξειδικευµένου υλικού που θα διασυνδέει ένα µικροελεγκτή µε κάποιο ολοκληρωµένο κύκλωµα που θα επιτελεί τις λειτουργίες επιπέδου 1 του Profibus DP πρωτοκόλλου και γ) η διασύνδεση ενός µικροελεγκτή µε ένα ολοκληρωµένο κύκλωµα που επιτελεί τις λειτουργίες µέχρι και το επίπεδο του Profibus DP. Η λύση που αφορούσε την ανάπτυξη ενός πρότυπου ολοκληρωµένου-συστήµατος απορρίφθηκε εξαιτίας του µεγάλου χρόνου εξέλιξης που θα απαιτούσε αλλά και του µεγάλου κόστους υλοποίησης ενός ολοκληρωµένου κυκλώµατος. Επίσης, η πιθανότητα ύπαρξης σχεδιαστικών λαθών που θα εµφανίζονταν µετά την παραγωγή του ολοκληρωµένου κυκλώµατος θα προκαλούσε υπέρβαση των προσφερόµενων κονδυλίων του προγράµµατος αλλά και υπέρβαση του χρόνου σχεδιασµού. Για παρόµοιους λόγους απορρίφθηκε και η δεύτερη προσέγγιση. Η τρίτη λύση παρουσιάζει σηµαντικά προτερήµατα ως προς την ευκολία και το κόστος υλοποίησης, το χρόνο σχεδιασµού και τις δυνατότητες διόρθωσης πιθανών σχεδιαστικών σφαλµάτων. Παράλληλα η σχεδιαστική προσπάθεια επικεντρώνεται στη σωστή διασύνδεση των ήδη λειτουργικών κοµµατιών µε αποτέλεσµα γρήγορη προτυποποίηση. Στα πλαίσια της παραπάνω λύσης εξετάστηκαν οι παρακάτω µικροελεγκτές: 68HC11 της Motorola, οι µικροελεγκτές της οικογένειας 8051 της Intel, AVR της Atmel, της Intel, η οικογένεια MCS 51 της Intel και οι επεξεργαστές 8086 της Intel και ARM της οµώνυµης εταιρείας Η σύγκριση των παραπάνω µικροελεγκτών οδήγησε στην επιλογή της οικογένειας MCS 51 για τους παρακάτω λόγους: παρουσιάζει προς τα πίσω συµβατότητα µε την οικογένεια 8051, καθώς έχει αρτηρία δεδοµένων εύρους 8 bit, µε αποτέλεσµα να υπάρχει µια πλούσια γκάµα περιφερειακών αλλά και έτοιµων προγραµµάτων για διάφορες εφαρµογές, ενσωµατώνει 16 bit αρχιτεκτονική εσωτερικά η οποία σε συνδυασµό µε το pipeline των 6 βαθµίδων εξασφαλίζει αυξηµένες επιδόσεις σε σχέση µε την οικογένεια 8051 αλλά και µελών της οικογένειας 68HC11,

137 ΑΡΤΙΟ Τελική έκθεση 137 ενσωµατώνει µια σειριακή θύρα η οποία µπορεί να προγραµµατιστεί για διάφορους ρυθµούς µετάδοσης αλλά και για σύγχρονη ή ασύγχρονη µετάδοση δεδοµένων. Για την υλοποίηση των λειτουργιών µέχρι και το επίπεδο του Profibus DP επιλέχτηκε το ολοκληρωµένο κύκλωµα SPC4 της Siemens καθώς προσφέρει εύκολη διασύνδεση µε διάφορες οικογένειες µικροελεγκτών αλλά και εκείνες τις δυνατότητες που είναι απαραίτητες για την υλοποίηση του έξυπνου εξαρτηµένου σταθµού Υλοποίηση πρότυπου συστήµατος Γενική µορφή πρότυπης πλατφόρµας Στα πλαίσια του προγράµµατος έχει υλοποιηθεί η επαναπρογραµµατιζόµενη πλατφόρµα του έξυπνου εξαρτηµένου σταθµού, βασισµένη στον µικροελεγκτή 80C51SB ο οποίος έχει τα παρακάτω χαρακτηριστικά: δεν περιλαµβάνει εσωτερική ROM που µπορεί να επαναπρογραµµατιστεί, περιλαµβάνει 1 KΒ εσωτερικής RAM, συχνότητα λειτουργίας µέχρι 16 MHz (Περισσότερες λεπτοµέρειες για τα χαρακτηριστικά του παραπάνω µικροελεγκτή µπορούν να βρεθούν στο: ftp://download.intel.com/design/mcs51/manuals/77950.pdf) Το γενικό διάγραµµα της πλατφόρµας φαίνεται στο παρακάτω σχήµα.

138

139 ΑΡΤΙΟ Τελική έκθεση 139 RXD Serial TXD Interface RXD TXD XTAL1 XTAL 80C51SB EA~ RST RD~ RST Reset Circuitry P0.7:0 ALE P.7:0 PSEN~ WR~ XT1 Clock XT Generator D7:0 AD7:0 A7:0 Latch C A15:8 Power Supply Vcc GND D7:0 A7:0 A15:0 A15:14 A16 ALE Decode Logic C0 C1 CRAM DRAM ROM RD WR Configuration Bytes CON0 CON1 Memory System CRAM DRAM ROM Σχήµα 49. Μπλοκ διάγραµµα επαναπρογραµµατιζόµενης πλατφόρµας (το ~ δηλώνει αρνητική λογική)

140 ΑΡΤΙΟ Τελική έκθεση 140 Όπως φαίνεται από το προηγούµενο σχήµα η επαναπρογραµµατιζόµενη πλατφόρµα αποτελείται από τα εξής τµήµατα: τον µικροελεγκτή 80C51SB, το τµήµα διασύνδεσης µε τη σειριακή θύρα του µικροελεγκτή (Serial Interface), το τµήµα απόπλεξης της αρτηρίας διευθύνσεων από την αρτηρία δεδοµένων (Latch), το σύστηµα της µνήµης (Memory System) και τη λογική αποκωδικοποίησης (Decode Logic) που το υποστηρίζει, το τµήµα παραµέτρων που θέτουν τον µικροελεγκτή σε µια συγκεκριµένη κατάσταση λειτουργίας (Configuration Bytes) και έναν αριθµό από µικρότερα κυκλώµατα που αναλαµβάνουν να παράγουν την τροφοδοσία των 5V (Power Supply), τους παλµούς ρολογιού (Clock Generator) και το σήµα αρχικοποίησης (Reset) του συστήµατος (Reset Circuitry) Στο παραπάνω λοιπόν σχήµα, ο µικροελεγκτής αποτελεί το κεντρικό στοιχείο του συστήµατος. Μέσω των αρτηριών δεδοµένων και διευθύνσεων οι οποίες πρώτα αποπλέκονται µέσω του τµήµατος Latch, ανταλλάσσονται δεδοµένα µεταξύ του συστήµατος µνήµης, του τµήµατος παραµέτρων και του µικροελεγκτή. Η σωστή συνεργασία των τµηµάτων µνήµης και παραµέτρων επιτυγχάνεται µε τη λογική αποκωδικοποίησης που τροφοδοτείται από ένα τµήµα της αρτηρίας διευθύνσεων και το σήµα ALE και παράγει τα σήµατα ενεργοποίησης των επιµέρους αυτών τµηµάτων. Επίσης µέσω της σειριακής θύρας του µικροελεγκτή που απαρτίζεται από τα σήµατα RXD, TXD επιτυγχάνεται επικοινωνία µε οποιονδήποτε υπολογιστή που υποστηρίζει το πρότυπο RS3. Τα σήµατα αυτά γίνονται συµβατά µε το πρότυπο RS3 µέσω του κυκλώµατος διασύνδεσης της σειριακής θύρας (Serial Interface) που οδηγεί σε ένα DB-9 θηλυκό connector. Τέλος, τα κυκλώµατα επανεκκίνησης (Reset Circuitry), παραγωγής παλµών (Clock Generator) και τροφοδοσίας (Power Supply) συνδέονται στα RST, XTAL1, XTAL, Vcc και GND Ο µικροελεγκτής 80C51SB Πριν υλοποιηθεί η πρότυπη πλατφόρµα µελετήθηκαν οι διάφορες διαµορφώσεις λειτουργίας του µικροελεγκτή, όπως το πόση µνήµη µπορεί να προσπελαστεί, αν θα χρειαστεί να εισαχθούν Wait States ή όχι, αν η αρτηρία διευθύνσεων θα βρίσκεται σε page mode ή non-page mode και κάποια άλλα χαρακτηριστικά λειτουργίας. Κάποιες από τις παραπάνω λειτουργίες µπορούν να καθοριστούν µε απευθείας σύνδεση κάποιων ακροδεκτών του ολοκληρωµένου κυκλώµατος στις κατάλληλες τιµές ενώ οι περισσότερες καθορίζονται από δύο Configuration Bytes τα οποία βρίσκονται έξω από το χώρο διευθύνσεων που µπορεί να προσπελάσει ο χρήστης. Τα δύο αυτά Bytes (CONFIG0 και CONFIG1) έχουν υλοποιηθεί µε το τµήµα Configuration Bytes το οποίο θα περιγραφεί παρακάτω. Ο µικροελεγκτής επιλέχθηκε να έχει χώρο διευθύνσεων µεγέθους 18 ΚΒ που αντιστοιχεί σε αρτηρία διευθύνσεων εύρους 17 bit. Για αυτό το λόγο η ακίδα P3.7 (επόµενο σχήµα) σε συνδυασµό µε τα Α15-Α8 και Α7-Α0 σχηµατίζουν τα 17 bit Α16-Α0 της αρτηρίας διευθύνσεων. Η επιλογή αυτή στερεί την ύπαρξη του RD# σήµατος καθώς αυτό πολυπλέκεται µε το Α16 στην ακίδα Ρ3.7 και για να αντιµετωπιστεί αυτό χρησιµοποιείται το PSEN# που δίνει το απαραίτητο σήµα ανάγνωσης στο σύστηµα µνήµης. Οι παραπάνω επιλογές καθορίζονται από το αν στα περιεχόµενα του CONFIG0 υπάρχουν τα RD1=0 και RD0=1. Ο µικροελεγκτής έχει

141 ΑΡΤΙΟ Τελική έκθεση 141 δύο διαµορφώσεις λειτουργίας της αρτηρίας διευθύνσεων που καθορίζονται από το bit PAGE του CONFIG0: 1. non-page mode (PAGE=0) όπου τα λιγότερο σηµαντικά bit της αρτηρίας διευθύνσεων (Α7-Α0) είναι πολυπλεγµένα µαζί µε την αρτηρία δεδοµένων (D7-D0) στις ακίδες Ρ0.7-Ρ0.0 και. page mode (PAGE=1) όπου τα περισσότερο σηµαντικά bit της αρτηρίας διευθύνσεων (Α15-Α8) είναι πολυπλεγµένα µαζί µε την αρτηρία δεδοµένων (D7-D0) στις ακίδες Ρ.7-Ρ.0. Η κατάσταση της ακίδας Ρ3.7 δεν επηρεάζεται από το παραπάνω bit. Κάποιες άλλες παράµετροι που αφορούν το σύστηµα µνήµης είναι η εισαγωγή Wait States (bit WSA του CONFIG0 και WSB του CONFIG1), η επιµήκυνση της διάρκειας του παλµού του ALE (bit XALE του CONFIG0) και η αντιστοίχιση των πάνω 8 ΚΒ της εσωτερικής µνήµης κώδικα σε διαφορετικό region του χώρου διευθύνσεων (bit EMAP του CONFIG1). Οι παράµετροι αυτές δε χρειάστηκε να ενεργοποιηθούν καθώς τα περιφερειακά που χρησιµοποιούνται (µνήµες, Latches, tri-state buffers) έχουν τις κατάλληλες επιδόσεις και έτσι τα παραπάνω bit πήραν την τιµή 1. Καθώς ο µικροελεγκτής δεν ενσωµατώνει OTPROM στην οποία µπορεί να αποθηκευτεί εκτελέσιµος κώδικας, η ακίδα ΕΑ# συνδέεται µε τη γείωση. Σχήµα 50. Τοπολογία ακίδων του 80C51SB (το # συµβολίζει αρνητική λογική) Τέλος, υπάρχουν δύο παράµετροι που αφορούν την εκτέλεση του κώδικα από τον µικροελεγκτή. Καθώς η οικογένεια MCS 51 είναι προς τα πίσω συµβατή, κάθε µικροελεγκτής που ανήκει σε αυτή µπορεί να εκτελέσει κώδικα µικροελεγκτή της οικογένειας Αυτό επιτυγχάνεται όταν τεθεί στο 0 το SRC bit του CONFIG0. Η διαµόρφωση όµως αυτή οδηγεί σε µικρότερη ταχύτητα εκτέλεσης των προγραµµάτων σε περίπτωση που οι περισσότερες εντολές προέρχονται από την MCS 51 αρχιτεκτονική. Στη συγκεκριµένη περίπτωση το SRC bit τίθεται στο 1 καθώς τα χρησιµοποιούµενα εργαλεία παραγωγής κώδικα µηχανής στοχεύουν στην MCS 51 αρχιτεκτονική. Η δεύτερη παράµετρος, το bit INTR του CONFIG1, τέθηκε στην τιµή

142 ΑΡΤΙΟ Τελική έκθεση 14 1 που σηµαίνει ότι ο µικροελεγκτής όταν θα κληθεί να εκτελέσει µια ρουτίνα διακοπής θα αποθηκεύσει στη σωρό 4 byte, τα 3 που απαρτίζουν τον program counter (PC) και τον Program Status καταχωρητή. Με βάση τα παραπάνω οι τιµές που αποθηκεύονται στα Configuration Bytes είναι οι CONFIG0: και CONFIG1: Serial Interface Το τµήµα διασύνδεσης µε τη σειριακή θύρα του µικροελεγκτή παρουσιάζεται στο επόµενο σχήµα. Το συγκεκριµένο κύκλωµα αναλαµβάνει να κάνει συµβατά τα σήµατα που δέχεται και στέλνει η σειριακή θύρα του µικροελεγκτή µε τα επίπεδα δυναµικού του RS3 προτύπου. Για αυτό το λόγο χρησιµοποιείται ένα ολοκληρωµένο που έχει τα χαρακτηριστικά του ολοκληρωµένου κυκλώµατος ΜΑΧ3. Η συνδεσµολογία που υλοποιήθηκε προτείνεται στο data sheet του ΜΑΧ3, µε τη διαφορά ότι η ακίδα συνδέεται µέσω ενός πυκνωτή στη γείωση και όχι στα 5V, για αποφυγή σύζευξης της ακίδας τροφοδοσίας µε την ακίδα V+ η οποία είναι φορέας θορύβου που προκαλείται από υψηλή συχνότητα εναλλαγής καταστάσεων. F C 1 =1µ =1µ =1µ =1µ C F C3 F C 4 F 1 C1+ V+ 3 C1-4 C+ 5 C- 6 V- 7 To 8 Ri MAX3 Vcc 16 GND 15 T1o R1i 1 R1o 11 T1i 10 Ti Ro 9 TXD RXD Σχήµα 51. Κύκλωµα διασύνδεσης µε σειριακή θύρα (Περισσότερες πληροφορίες για το ΜΑΧ3 µπορούν να βρεθούν στο: Κύκλωµα απόπλεξης αρτηριών διευθύνσεων και δεδοµένων Όπως ήδη αναφέρθηκε ο µικροελεγκτής χρησιµοποιεί πολυπλεξία στις αρτηρίες δεδοµένων και διευθύνσεων µε αποτέλεσµα να απαιτείται η ύπαρξη µιας λογικής που διαχωρίζει τις δύο αυτές αρτηρίες ώστε να είναι δυνατή η σωστή προσπέλαση των διαφόρων περιφερειακών του συστήµατος. Η πολυπλεξία που εφαρµόζεται από το µικροελεγκτή έχει σαν συνέπεια την εµφάνιση των τιµών των 8 λιγότερο σηµαντικών ψηφιών της διεύθυνσης ακολουθούµενα στη συνέχεια από τα εύρους 8 bit δεδοµένα. Πρέπει λοιπόν µε κάποιο τρόπο η λογική διαχωρισµού να αποθηκεύει τις τιµές της αρτηρίας διευθύνσεων ώστε αυτές να είναι διαθέσιµες όταν εµφανιστούν οι τιµές στην αρτηρία δεδοµένων. Έτσι, η λογική αυτή αποτελείται από 8 ενεργοποιούµενα από στάθµη δυναµικού (level triggered) φλιπ-φλοπ, τα οποία µε βάση τη στάθµη του

143 ΑΡΤΙΟ Τελική έκθεση 143 σήµατος C αποθηκεύουν τις τιµές των εισόδων τους. Τα 8 αυτά φλιπ-φλοπ βρίσκονται όλα σε ένα ολοκληρωµένο κύκλωµα το 74LS373 (επόµενο σχήµα) του οποίου το σήµα C συνδέεται µε το σήµα ALE του µικροελεγκτή. 1 OC~ Vcc 0 A0 1Q 8Q 19 A7 AD0 AD1 A1 A AD AD3 3 1D 4 D 5 Q 6 3Q 7 3D 8 4D 74LS373N 8D 18 7D 7Q 6Q 6D D 13 AD7 AD6 A6 A5 AD5 AD4 A3 9 4Q A4 10 GND 5Q 1 C 11 C Σχήµα 5. Κύκλωµα απόπλεξης αρτηριών διευθύνσεων-δεδοµένων Σύστηµα µνήµης - λογική αποκωδικοποίησης Το σύστηµα µνήµης περιλαµβάνει τα περιφερειακά εκείνα που έχουν συνδεθεί ή προβλέπεται να συνδεθούν στην πρότυπη πλατφόρµα. Για τη σύνδεση αυτών των περιφερειακών χρησιµοποιείται η λογική αποκωδικοποίησης που αναλαµβάνει να ενεργοποιεί το καθένα από αυτά µε τέτοιο τρόπο ώστε µόνο αυτό να έχει υπό τον έλεγχό του την αρτηρία δεδοµένων. Τα περιφερειακά που περιλαµβάνονται στο σύστηµα µνήµης είναι µια µνήµη ανάγνωσης µόνο (ROM) και δύο µνήµες τυχαίας προσπέλασης (RAM), όπως φαίνεται στο επόµενο σχήµα. Τυπικά και το τµήµα παραµέτρων αποτελεί µέρος του συστήµατος µνήµης αλλά καθώς πρόκειται για διαφορετικό κύκλωµα, παρουσιάζεται σε άλλη υποενότητα. Τα 18 ΚΒ µνήµης που αποτελούν το χώρο διευθύνσεων έχουν χωριστεί ως εξής. στις διευθύνσεις FFF βρίσκεται µια RAM µεγέθους 3 ΚΒ και είναι διαθέσιµη για τα δεδοµένα του χρήστη. Το ολοκληρωµένο που έχει χρησιµοποιηθεί σε αυτή την περίπτωση είναι το CY656 µε χρόνο προσπέλασης τα 70 ns, µε αποτέλεσµα να µην απαιτείται εισαγωγή Wait States. Η µνήµη αυτή ενεργοποιείται από το σήµα DRAM όπως αυτό παράγεται από τη λογική αποκωδικοποίησης (Σχήµα 54) και ο τρόπος σύνδεσής της φαίνεται στο Σχήµα 53. στις διευθύνσεις BFFF αποδόθηκε χώρος για το SPC4 που είναι ένα ολοκληρωµένο το οποίο υλοποιεί τις λειτουργίες µέχρι και το επίπεδο του δικτύου Profibus. Το συγκεκριµένο ολοκληρωµένο έχει εσωτερικά 1,5 ΚΒ µνήµης RAM αλλά εξωτερικά καταλαµβάνει χώρο διευθύνσεων ίσο µε 1 ΚΒ. Το σήµα της λογικής αποκωδικοποίησης που έχει προβλεφθεί να το ενεργοποιεί είναι το SPC4. οι διευθύνσεις 0C000-0FFFF έχουν αφεθεί ελεύθερες για διασύνδεση οποιουδήποτε περιφερειακού επιθυµεί ο χρήστης. Για αυτό το σκοπό θα πρέπει ο χρήστης να υλοποιεί και τη λογική αποκωδικοποίησης χρησιµοποιώντας κάποια

144 ΑΡΤΙΟ Τελική έκθεση 144 από τα σήµατα της αρτηρίας διευθύνσεων. Ο χώρος αυτός των 16 ΚΒ κρίνεται επαρκής για οποιαδήποτε περιφερειακή συσκευή επιθυµεί ο χρήστης. οι διευθύνσεις FFF καταλαµβάνονται από µια EEPROM, την AT8HC64/L µεγέθους 16 ΚΒ και ταχύτητας προσπέλασης 55 ns, η οποία περιέχει τον κώδικα του λογισµικού ελέγχου και επαναπρογραµµατισµού της πρότυπης πλακέτας. Η ενεργοποίηση της µνήµης αυτής γίνεται µε το σήµα ROM που παράγεται από τη λογική αποκωδικοποίησης και το οποίο έχει και τη λειτουργία του σήµατος ανάγνωσης. Η συνδεσµολογία φαίνεται στο Σχήµα 53. µία ακόµη RAM µεγέθους 3 ΚΒ (CY656) έχει αντιστοιχηθεί στις διευθύνσεις BFFF και χρησιµοποιείται για την αποθήκευση του κώδικα του χρήστη. Ενεργοποιείται µε το σήµα CRAM. τέλος οι διευθύνσεις 1C000-1FFFF, που αντιστοιχούν σε µέγεθος 16 ΚΒ, έχουν αποδοθεί στο τµήµα παραµέτρων και το οποίο θα παρουσιαστεί αναλυτικότερα στην επόµενη υποενότητα. A14:A0 D7:0 ROM CRAM DRAM Code ROM CE~ AT8HC64/L OE~ A1:A0 I/O7:0 WE~ Code RAM CE~ A14:A0 CY656 Data RAM CE~ A14:A0 CY656 OE~ I/O7:0 WE~ OE~ I/O7:0 WE~ Vcc RD WR RD WR D7:0 Σχήµα 53. Σύστηµα µνήµης Στο Σχήµα 53 τα σήµατα RD και WR τροφοδοτούνται από τα σήµατα PSEN# και WR# του µικροελεγκτή αντίστοιχα, ενώ η λογική αποκωδικοποίησης έχει υλοποιηθεί µε απλές πύλες για σκοπούς εύκολης εύρεσης σχεδιαστικών σφαλµάτων.

145 ΑΡΤΙΟ Τελική έκθεση 145 Σχήµα 54. Λογική αποκωδικοποίησης Τµήµα παραµέτρων Το τµήµα παραµέτρων αποσκοπεί στον καθορισµό των τιµών των Configuration Bytes που περιέχουν τις απαραίτητες τιµές για σωστή λειτουργία του µικροελεγκτή και κατά συνέπεια της πρότυπης πλακέτας. Η υλοποίησή του έγινε µε δύο οχτάδες διακοπτών δύο θέσεων (DIP Switches) που στην ουσία αναπαριστούν τα δύο αυτά bytes και 16 tri-state buffers που περνούν την είσοδό τους στην έξοδο µε βάση κάποια σήµατα ενεργοποίησης. Οι 16 tri-state buffers βρίσκονται σε δύο ολοκληρωµένα 74LS44N (επόµενο σχήµα), τα οποία ενεργοποιούνται από τα σήµατα CON0 και CON1 που παράγονται από τη λογική αποκωδικοποίησης ως CONFIG0 και CONFIG1 αντίστοιχα. Η λογική αποκωδικοποίησης έχει υλοποιηθεί έτσι ώστε για τις µονές διευθύνσεις του εύρους 1C000-1FFFF να ενεργοποιείται το σήµα CONFIG0 και για τις ζυγές το CONFIG1. Αυτό που πρέπει να παρατηρηθεί στην υλοποίηση του συγκεκριµένου κυκλώµατος είναι ότι οι διακόπτες δύο θέσεων συνοδεύονται από δύο resistor arrays του 1ΚΩ οι άκρες των οποίων έχουν συνδεθεί µεταξύ της γείωσης και των γραµµών που ξεκινούν από τους διακόπτες και καταλήγουν στις εισόδους των tri-state buffers. Ο σκοπός τους είναι να εµποδίσουν την ύπαρξη βραχυκυκλώµατος µεταξύ τροφοδοσίας και γείωσης όταν ένας διακόπτης είναι στη θέση ΟΝ.

146 ΑΡΤΙΟ Τελική έκθεση 146 Vcc 8 1kΩ 1G~ G~ CON0 74LS44N DIP Switches MSB... LSB 1A1:1A4, A4:A1 74LS44N 1Y1:1Y4, Y4:Y1 Vcc 8 D7:0 1kΩ 1G~ G~ CON1 DIP Switches MSB... LSB 1A1:1A4, A4:A1 1Y1:1Y4, Y4:Y1 Σχήµα 55. Τµήµα παραµέτρων ευτερεύοντα κυκλώµατα Το κύκλωµα παραγωγής της τροφοδοσίας (επόµενο σχήµα) δέχεται σαν είσοδο στον connector JP1 εξωτερική τροφοδοσία µέχρι 1V και παράγει την τροφοδοσία των 5V και τη γείωση που είναι απαραίτητες για τα υπόλοιπα τµήµατα της πρότυπης πλακέτας. Το στοιχείο 7805 αναλαµβάνει την παραγωγή της σταθερής τάσης και οι πυκνωτές χρησιµοποιούνται για σκοπούς αποσύζευξης. Η δίοδος αποτρέπει την ανάστροφη πόλωση του Vcc=5V GND N5819 JP1 + - C 3 =10µF C =10µF C 1 =10µF Σχήµα 56. Κύκλωµα παραγωγής τροφοδοσίας Το κύκλωµα παραγωγής παλµών ρολογιού αναλαµβάνει την τροφοδότηση του µικροελεγκτή µε τους κατάλληλους παλµούς. Για αυτό το λόγο χρησιµοποιείται ένας κρύσταλλος 11,059 MHz, δύο αντιστάσεις και δύο πυκνωτές στη συνδεσµολογία του επόµενου σχήµατος.

147 ΑΡΤΙΟ Τελική έκθεση 147 XT XT1 R =1kΩ R 1 =1MΩ MHz C 1 =7pF C =7pF Σχήµα 57. Κύκλωµα παραγωγής παλµών ρολογιού Τέλος, το κύκλωµα παραγωγής του σήµατος αρχικοποίησης του συστήµατος αποτελείται από έναν πυκνωτή και µια αντίσταση στη συνδεσµολογία του επόµενου σχήµατος. Σκοπός αυτού του κυκλώµατος είναι, όταν πατηθεί ο διακόπτης η γραµµή RST του µικροελεγκτή να µείνει στο 0 για χρονικό διάστηµα ίσο µε 64 περιόδους ρολογιού ώστε να ολοκληρωθεί η διαδικασία αρχικοποίησής του. Για την επίτευξη του χρονικού διαστήµατος αυτού επιλέχθηκαν µία αντίσταση των 10 ΚΩ και ένας πυκνωτής των 10µF. Vcc R 1 =10kΩ C 1 =10µF RST Σχήµα 58. Κύκλωµα αρχικοποίησης Περιγραφή λογισµικού του επαναπρογραµµατιζόµενου συστήµατος (πλακέτας) Απαιτήσεις - Στόχοι Για τη συγγραφή τόσο του λογισµικού ελέγχου και επαναπρογραµµατισµού της πρότυπης πλακέτας, όσο και των εφαρµογών που έτρεξαν σε αυτή (εφαρµογές χρήστη) χρησιµοποιήθηκε το ολοκληρωµένο περιβάλλον "Embedded Development Environment" (EDE) της εταιρείας Tasking (έκδοση.0 r5). Η αλυσίδα προγραµµάτων (toolchain) από την οποία συνοδευόταν βρισκόταν και αυτή στην έκδοση.0 (r0). To toolchain αυτό περιλαµβάνει µία σειρά από προγράµµατα (compilers, assembler, linker, locator κτλ) καθώς και τις απαραίτητες βιβλιοθήκες µε τη βοήθεια των οποίων ο χρήστης µπορεί να γράψει µία εφαρµογή σε υψηλό επίπεδο (γλώσσα προγραµµατισµού C), να παράγει µία πληθώρα αρχείων εξόδου (διάφορα formats), καθώς και να κάνει αποσφαλµάτωση (debugging) της εφαρµογής µέσω του εργαλείου CrossView Pro. Η κύρια απαίτηση που έπρεπε να ικανοποιεί το λογισµικό ελέγχου και επαναπρογραµµατισµού (από το σηµείο αυτό και µετά θα αναφέρεται απλά σαν λογισµικό ελέγχου) της πρότυπης πλακέτας ήταν να διατηρηθεί η ευκολία και η ευελιξία που παρέχει το EDE στον χρήστη κατά τη συγγραφή εφαρµογών. Οι

148 ΑΡΤΙΟ Τελική έκθεση 148 εφαρµογές αυτές θα αποτελούν τις διαφορετικές διαµορφώσεις (configurations) του επαναπρογραµµατιζόµενου εξαρτηµένου σταθµού του δικτύου Profibus. Θα θέλαµε λοιπόν να έχει κανείς τους λιγότερους δυνατούς περιορισµούς όταν θα χρειαστεί να γράψει κώδικα για να προγραµµατίσει το σταθµό και αυτό θέσαµε σαν πρώτο µας στόχο. Ένας δεύτερος στόχος ήταν η παροχή κάποιων «κανόνων» µε βάση τους οποίους θα έπρεπε κάποιος χρήστης να γράψει την εφαρµογή του, έτσι ώστε αυτή να συνεργάζεται µε το λογισµικό ελέγχου. Καταλαβαίνουµε ότι τέτοιοι κανόνες είναι απαραίτητοι αφού το λογισµικό ελέγχου παίζει το ρόλο ενός πολύ απλού λειτουργικού συστήµατος της πρότυπης πλακέτας. Είναι προφανές λοιπόν ότι αφού ο compiler που χρησιµοποιείται δε λαµβάνει υπόψη του τα χαρακτηριστικά του λειτουργικού αυτού συστήµατος (άλλωστε και αυτό δηµιουργήθηκε µε τη βοήθεια του ίδιου compiler), αυτό πρέπει να γίνει µέσω κάποιων κανόνων. Για να µην υπάρχει σύγκρουση µε τον πρώτο στόχο καταβλήθηκε προσπάθεια έτσι ώστε οι κανόνες αυτοί να είναι όσο το δυνατόν πιο απλοί και να αλλάζουν όσο το δυνατόν λιγότερο τη µορφή του πηγαίου κώδικα των εφαρµογών χρήστη. Οι κανόνες αυτοί έχουν να κάνουν αφενός µε κάποια χαρακτηριστικά που θα πρέπει να ενσωµατώνονται στον κώδικα των εφαρµογών και αφετέρου µε τη διαµόρφωση µνήµης που θα πρέπει να έχουν οι εφαρµογές αυτές. Περισσότερες λεπτοµέρειες θα δοθούν σε επόµενη παράγραφο Επικοινωνία µέσω σειριακής θύρας Για την επικοινωνία της πρότυπης πλακέτας µε το PC επιλέξαµε να χρησιµοποιήσουµε την εφαρµογή των Windows HyperTerminal. Ο λόγος ήταν ότι, από τη µία, η εφαρµογή αυτή καλύπτει πλήρως τις ανάγκες µας, όσο αφορά τον επαναπρογραµµατισµό της πλακέτας µέσω της σειριακής θύρας του PC και, από την άλλη, ότι παρέχεται µαζί µε τα Windows και άρα µπορεί να βρεθεί εύκολα σε κάθε PC. Ξεκινώντας λοιπόν κανείς θα πρέπει να ορίσει µία νέα σύνδεση στο HyperTerminal και να προσδιορίσει τη σειριακή θύρα (COM1, COM κτλ) στην οποία θα συνδεθεί η πλακέτα. Κατόπιν θα πρέπει να ρυθµιστούν οι παράµετροι της σύνδεσης αυτής. Τα bits δεδοµένων (data bits) πρέπει να είναι οκτώ, το bit διακοπής (stop bit) πρέπει να είναι 1, ενώ δε θα πρέπει να υπάρχουν bits ισοτιµίας (parity: none) και έλεγχος ροής (flow control: none). H ταχύτητα σύνδεσης που υποστηρίζεται αυτή τη στιγµή από το λογισµικό ελέγχου είναι τα 1900 bits per second. Αν κριθεί σκόπιµο, η τιµή αυτή µπορεί να αλλάξει στη συνέχεια και να γίνει µεγαλύτερη. Με τις ρυθµίσεις αυτές απλοποιείται αρκετά η επικοινωνία µεταξύ πλακέτας και PC µε αποτέλεσµα να απλοποιείται αντίστοιχα και το λογισµικό ελέγχου της πλακέτας. Θα πρέπει να αναφέρουµε στο σηµείο αυτό ότι τα αρχεία µε τα οποία επαναπρογραµµατίζεται η πρότυπη πλακέτα είναι αρχεία κειµένου (text) µε συγκεκριµένο format (Intel hex format) τα οποία παράγονται από τον locator (περιέχουν δηλαδή και τις θέσεις µνήµης στις οποίες πρέπει να αποθηκευθούν τα αντίστοιχα δεδοµένα). Για την αποστολή ενός τέτοιου αρχείου θα πρέπει από το µενού "Transfer" του HyperTerminal να επιλέξουµε "Send Text File" (σηµειώνουµε ότι πρόκειται για text αρχεία παρά το γεγονός ότι φέρουν την προέκταση.hex) Κατανοµή του χώρου διευθύνσεων Στην παράγραφο αυτή θα εξηγηθούν οι λόγοι για τους οποίους ο χώρος διευθύνσεων χωρίστηκε µε τον τρόπο που περιγράφηκε στην παράγραφο Πριν

149 ΑΡΤΙΟ Τελική έκθεση 149 προχωρήσουµε όµως θα πρέπει να εξηγήσουµε ορισµένα πράγµατα σε σχέση µε το χώρο διευθύνσεων που µπορεί να δει ο συγκεκριµένος µικροελεγκτής που χρησιµοποιήθηκε στα πλαίσια του προγράµµατος. Γενικά, οι µικροελεγκτές της οικογένειας MCS 51 της Intel βλέπουν χώρο διευθύνσεων µεγέθους 16 Mbytes, ο οποίος, για λόγους ευκολίας, χωρίζεται σε 56 περιοχές (00: - FF:) των 64 Kbytes. Θα πρέπει να σηµειωθεί ότι ο χώρος διευθύνσεων αυτός είναι γραµµικός και ότι για την προσπέλαση του δε χρησιµοποιούνται segment registers. O χωρισµός στις περιοχές (regions) 00: έως FF: γίνεται καθαρά και µόνο για λόγους ευκολίας. Ο συγκεκριµένος µικροελεγκτής που χρησιµοποιούµε (80C51SB), από τις 56 αυτές περιοχές, βλέπει εσωτερικά (internal space) τέσσερις (4): τις 00:, 01:, FE: και FF:. Οι υπόλοιπες είναι δεσµευµένες. Εξωτερικά, ο µέγιστος χώρος που µπορεί να χρησιµοποιηθεί (external space) είναι 18 Kbytes. Επειδή είναι απαραίτητο να µπορεί να εκτελεστεί κώδικας από περιοχές φυσικής µνήµης στις οποίες µπορούµε να γράφουµε δεδοµένα (γιατί µόνο έτσι µπορούµε να «φορτώνουµε» τις εφαρµογές του χρήστη), επιλέξαµε τα bits RD0 και RD1 του καταχωρητή CONFIG0 να έχουν τις τιµές 1 και 0 αντίστοιχα. Σε αυτή τη διαµόρφωση στα χαµηλότερα 64 Κbytes εξωτερικής µνήµης αντιστοιχίζονται τα regions 00: και FE:, ενώ στα υπόλοιπα 64 Kbytes αντιστοιχίζονται τα regions 01: και FF:, όπως φαίνεται στο επόµενο σχήµα. Σχήµα 59. Εσωτερικός και φυσικός χώρος διευθύνσεων για RD0 = 1 και RD1 = 0 Από τα τέσσερα regions της εσωτερικής µνήµης, τα 00: και 01: χρησιµοποιούνται σαν µνήµη δεδοµένων (data memory), ενώ τα FE: και FF: χρησιµοποιούνται σαν µνήµη εκτέλεσης κώδικα (code memory). Έτσι, αν χρειαστεί να φορτωθεί εκτελέσιµος κώδικας στην περιοχή φυσικής µνήµης 1, τότε αυτός φορτώνεται σαν να πρόκειται για δεδοµένα στο εσωτερικό region 01: και εκτελείται από το region FF:. Αυτό το οποίο µένει να εξηγηθεί είναι γιατί δεν επιλέχθηκε η λύση του να υπάρχουν µόνο 64 Kbytes εξωτερικής µνήµης στα οποία να φορτώνεται και να εκτελείται κώδικας (RD0 = 0, RD1 = 1). Ο λόγος για τον οποίο δεν επιλέχθηκε αυτή η λύση είναι ότι δεν µπορούσε να υποστηριχθεί από τον compiler που παρείχε το EDE. Το πρόβληµα το οποίο υπήρχε ήταν ότι αν στα memory settings κάποιας εφαρµογής δεν οριζόταν µία περιοχή µνήµης η οποία θα ξεκινούσε από τη διεύθυνση 00:0000 σαν µνήµη δεδοµένων, τότε ο compiler δεν αναγνώριζε και συνεπώς δεν µπορούσε να χρησιµοποιήσει κάποιους από τους εσωτερικούς καταχωρητές του Για να αποφύγουµε λοιπόν το πρόβληµα αυτό, δώσαµε 3 Κbytes από το region FF: (FF: FF:BFFF) στις εφαρµογές του χρήστη σαν µνήµη εκτέλεσης κώδικα και τα χαµηλότερα 3 Κbytes του region 00: (00: :7FFF) σαν µνήµη δεδοµένων.

150 ΑΡΤΙΟ Τελική έκθεση 150 Από εκεί και πέρα, τα χαµηλότερα 16 Κbytes του FF: (FF: FF:3FFF) παραχωρήθηκαν στο λογισµικό ελέγχου της πλακέτας (bootstrap ROM) εξαιτίας του ότι ο 8051 ξεκινάει την εκτέλεση κώδικα, µετά από reset, από τη διεύθυνση FF:0000, ενώ τα υψηλότερα 16 Κbytes του FF: (FF:C000 - FF:FFFF) χρησιµοποιήθηκαν για την αποθήκευση του configuration του µικροελεγκτή, αφού αυτός διαβάζει τα configuration bytes (CONFIG0 και CONFIG1) από τις θέσεις FF:FFF8 και FF:FFF9 αντίστοιχα. Τέλος τα 3 υψηλότερα Kbytes του region 00: (00: :FFFF) µοιράστηκαν εξίσου µεταξύ του SPC4 και άλλων περιφερειακών συσκευών που µπορεί να τοποθετηθούν µελλοντικά To λογισµικό ελέγχου της πλακέτας Το λογισµικό ελέγχου, όπως αναφέρθηκε και προηγουµένως, αποτελεί στην ουσία το λειτουργικό σύστηµα της πλακέτας το οποίο αναλαµβάνει την αρχικοποίηση του συστήµατος, τον επαναπρογραµµατισµό του µε τη µεταφορά κώδικα σε αυτό µέσω της σειριακής θύρας και την προετοιµασία των interrupts έτσι ώστε αυτά να µπορούν στη συνέχεια να χρησιµοποιηθούν από τις εφαρµογές του χρήστη. Σε αυτά τα τρία σηµεία θα επικεντρωθεί και η δική µας αναφορά δίνοντας έµφαση στο κοµµάτι το οποίο αφορά τα interrupts. Η αρχικοποίηση του συστήµατος, στην ουσία ανάγεται στην αρχικοποίηση του UART του µικροελεγκτή για λήψη και αποστολή δεδοµένων. Το configuration του ίδιου του µικροελεγκτή γίνεται µε τη βοήθεια των Configuration Bytes CONFIG0 και CONFIG1, τα οποία είτε αποθηκεύονται σε µία ROM, είτε, αν θέλουµε να υπάρχει µεγαλύτερη ευελιξία, µπορούν να προσδιορίζονται και µε τη βοήθεια DIP switches (τακτική που ακολουθήθηκε και κατά την ανάπτυξη της πρότυπης πλακέτας). Όσο για την αρχικοποίηση του UART, αυτή έγκειται στην επιλογή του κατάλληλου mode λειτουργίας τόσο του ίδιου του UART όσο και του timer ο οποίος χρησιµοποιείται σαν baud rate generator (συγκεκριµένα ο Timer 1) καθώς και στην ενεργοποίηση των απαραίτητων interrupts. Μετά τις αρχικοποιήσεις, και αφού εκτυπωθεί κάποιο µήνυµα στο τερµατικό µε το οποίο επικοινωνεί η πλακέτα (στη δική µας την περίπτωση το HyperTerminal), το σύστηµα περιµένει να πατήσει ο χρήστης το πλήκτρο 'c' (configure), έτσι ώστε να µπει σε κατάσταση κατεβάσµατος κώδικα. Ο χρήστης πρέπει να επιλέξει το κατάλληλο.hex αρχείο (Intel hex format) και να το αποστείλει προς την πλακέτα. Όταν τελειώσει η διαδικασία του downloading και αν δεν έχει συµβεί κάποιο λάθος, το λογισµικό ελέγχου ενηµερώνει τον χρήστη ότι όλα πήγαν καλά και κάνει JUMP στη θέση FF:4000 όπου και βρίσκεται η πρώτη εντολή του προγράµµατος το οποίο φορτώθηκε. Η µορφή την οποία έχουν τα Intel hex αρχεία είναι αρκετά απλή και σκοπός του κειµένου αυτού δεν είναι να την αναλύσει. Θα σταθούµε απλά σε δύο σηµεία τα οποία πρέπει να σχολιαστούν. Το πρώτο είναι ότι ο κώδικας ο οποίος περιέχεται σε αυτά, όπως αναφέρθηκε και προηγουµένως, δεν είναι relocatable. Το λογισµικό ελέγχου της πλακέτας χρησιµοποιεί τις διευθύνσεις που περιέχονται στο αρχείο για να τοποθετήσει τον κώδικα στις σωστές θέσεις µνήµης. Το πώς µπορεί να καθορίσει ο χρήστης τις περιοχές µνήµης στις οποίες θα τοποθετηθεί ο κώδικας από τον compiler, θα εξηγηθεί στην επόµενη παράγραφο. Το δεύτερο σηµείο το οποίο πρέπει να αναφέρουµε είναι η ύπαρξη ενός πεδίου checksum στο τέλος κάθε γραµµής του.hex αρχείου. Το άθροισµα του πεδίου αυτού µε τα υπόλοιπα bytes της γραµµής θα πρέπει να δίνει αποτέλεσµα ίσο µε 0. Το λογισµικό ελέγχου πραγµατοποιεί τον έλεγχο αυτό και αν κάπου βρεθεί λάθος, ζητάει από τον χρήστη να ξαναστείλει το αρχείο. Σηµειώνεται ότι όλη η επεξεργασία των δεδοµένων

151 ΑΡΤΙΟ Τελική έκθεση 151 που µεταφέρονται µέσω της σειριακής θύρας στην πρότυπη πλακέτα, γίνεται από την interrupt ρουτίνα της σειριακής θύρας, η οποία µένει ενεργή και µετά το φόρτωµα κάποιας εφαρµογής. Αποµένει να εξηγήσουµε τον τρόπο µε τον οποίο χειρίζεται τα interrupts το λογισµικό ελέγχου της πλακέτας. Το interrupt vector του 8051 βρίσκεται στην περιοχή της bootstrap ROM και πιο συγκεκριµένα στις θέσεις µνήµης FF: FF:0033. Σε καθένα από τα επτά (7) interrupts του 8051 αντιστοιχεί χώρος ίσος µε 8 bytes. Αν κάποια ρουτίνα εξυπηρέτησης interrupt (interrupt service routine) ξεπερνάει σε µέγεθος τα οκτώ αυτά bytes, τότε η ρουτίνα αυτή καθεαυτή τοποθετείται σε κάποια ελεύθερη περιοχή µέσα στο χώρο διευθύνσεων του 8051 και στο interrupt vector γίνεται απλά ένα JUMP στη διεύθυνση της πρώτης θέσης της περιοχής αυτής. Το πρόγραµµα ελέγχου της πρότυπης πλακέτας δεσµεύει 14 θέσεις µνήµης (00: :043D), οι οποίες αντιστοιχούν ανά ζεύγη σε ένα interrupt (π.χ. οι διευθύνσεις 00: αντιστοιχούν στο INT0#). Tα προγράµµατα των χρηστών θα πρέπει να αποθηκεύσουν στις θέσεις µνήµης που αντιστοιχούν στα interrupts που χρησιµοποιούν, τις διευθύνσεις των πρώτων εντολών των ρουτινών που τα υλοποιούν. O τρόπος µε τον οποίο µπορεί να γίνει κάτι τέτοιο θα εξηγηθεί στην επόµενη παράγραφο. Πρέπει να τονισθεί ότι οι ρουτίνες αυτές δεν περιγράφονται στη C σαν interrupts αλλά σαν κανονικές ρουτίνες οι οποίες προφανώς δε χρησιµοποιούνται πουθενά µέσα στο κυρίως πρόγραµµα. Όταν συµβεί ένα interrupt κατά την εκτέλεση κάποιου προγράµµατος χρήστη, τότε ο έλεγχος µεταφέρεται στην αντίστοιχη περιοχή της ROM, η οποία µε τη σειρά της κάνει CALL τη ρουτίνα που έχει γράψει ο χρήστης. Η διεύθυνση της ρουτίνας αυτής βρίσκεται αποθηκευµένη στις αντίστοιχες θέσεις της περιοχής 00: :043D. Με άλλα λόγια ένα interrupt του προγράµµατος ελέγχου αποτελείται απλά από ένα CALL στη θέση µνήµης που είναι αποθηκευµένη στις αντίστοιχες θέσεις του vector 00: :043D. Π.χ. για το INT0# θα έχουµε: void _interrupt(0) INT_0(void) { } #pragma asm MOV WR4,0430h #pragma endasm Ο WR4 είναι ένας register του 8051 ο οποίος έχει εύρος 16 bit Οι εφαρµογές χρήστη Σε αυτή την παράγραφο περιγράφουµε τον τρόπο µε τον οποίο θα πρέπει να γραφεί µία εφαρµογή έτσι ώστε να µπορεί να συνεργάζεται µε το λογισµικό ελέγχου της πρότυπης πλακέτας. Γενικά µία τέτοια εφαρµογή θα πρέπει να ελέγχει κατά διαστήµατα τη θέση µνήµης 00:03F5. Η θέση µνήµης αυτή είναι δεσµευµένη από το λογισµικό ελέγχου και αν πατηθεί το πλήκτρο 'c' τίθεται από τη ρουτίνα interrupt της σειριακής ίση µε 1. Αν

152 ΑΡΤΙΟ Τελική έκθεση 15 βρισκόµαστε στο πρόγραµµα ελέγχου, αυτό έχει σαν συνέπεια την αναµονή για µετάδοση κώδικα επαναπρογραµµατισµού. Αν βρισκόµαστε σε πρόγραµµα χρήστη, αυτό σηµαίνει ότι πρέπει ο κώδικας αυτός να τερµατίσει, να επιστρέψει ο έλεγχος στο λειτουργικό (JUMP FF:0000) και να ξεκινήσει από την αρχή µια νέα διαδικασία επαναπρογραµµατισµού. Οι ρουτίνες που θα υλοποιούν τα interrupts θα πρέπει να έχουν την ακόλουθη µορφή: void timer0_int( void ) #pragma asm timer0_label: #pragma endasm {... } Βλέπουµε ότι πρόκειται για µία κανονική συνάρτηση της C στην αρχή της οποίας ορίζεται ένα label. Με τη βοήθεια του label αυτού µπορούµε να αποθηκεύσουµε τη διεύθυνση της πρώτης εντολής στις θέσεις µνήµης που επιθυµούµε. Αυτό γίνεται µε δύο εντολές assembly κατά τις αρχικοποιήσεις του αντίστοιχου προγράµµατος. Πιο συγκεκριµένα: #pragma asm MOV WR4,#timer0_label MOV 043h,WR4 #pragma endasm Το interrupt του Timer 0 αντιστοιχεί στις θέσεις µνήµης 00: Τέλος, οι ρυθµίσεις που πρέπει να γίνουν έτσι ώστε τα προγράµµατα των χρηστών να ανταποκρίνονται στη διαµόρφωση µνήµης της πρότυπης πλακέτας φαίνονται στo επόµενο σχήµα.

153 ΑΡΤΙΟ Τελική έκθεση 153 Σχήµα 60. Ρυθµίσεις µνήµης εφαρµογών χρήστη Επέκτασεις της πλατφόρµας Η εξέταση της διασύνδεσης του ολοκληρωµένου κυκλώµατος SPC4 µε την πρότυπη πλακέτα έτσι ώστε να καταστεί δυνατή η επικοινωνία του σταθµού µε το δίκτυο Profibus, είναι στα άµεσα σχέδια της ερευνητικής οµάδας του ΙΤΥ. Στις µελλοντικές επεκτάσεις περιλαµβάνονται η υλοποίηση της λογικής αποκωδικοποίησης µε κάποια προγραµµατιζόµενη συσκευή και η ενσωµάτωση των παραµέτρων που βρίσκονται στα Configuration Bytes στη µνήµη ROM µε κατάλληλη χρήση της λογικής αποκωδικοποίησης. Τέλος, µπορεί να µελετηθεί η δυνατότητα επαναπρογραµµατισµού του έξυπνου σταθµού-υπηρέτη µέσω του δικτύου Profibus. 8. Υλοποίηση Σταθµών ικτύου Lonworks 8..1 Γενικά Το δίκτυο LONWORKS έχει αναπτυχθεί από την εταιρεία Echelon και αποτελεί µία ολοκληρωµένη δικτυακή πλατφόρµα για εφαρµογές ελέγχου, µε έµφαση στις δικτυακές εφαρµογές αυτοµατισµού κτιρίων και οικιών, αλλά και στις βιοµηχανικές εφαρµογές. Το δίκτυο, σε αντίθεση µε άλλα δίκτυα πεδίου, υλοποιεί το πλήρες OSI- RM των επτά επιπέδων, τα οποία συνιστούν το πρωτόκολλο LONTALK και παρουσιάζονται περιληπτικά στη συνέχεια αυτής της ενότητας. Σε αντίθεση µε το Profibus δίκτυο, οι σταθµοί του LonWorks είναι ενιαίοι και δεν διακρίνονται σε κύριους και εξαρτηµένους. H τεχνολογία LONWORKS περιλαµβάνει όλα τα στοιχεία που απαιτούνται για την σχεδίαση, ανάπτυξη και υποστήριξη εφαρµογών ελέγχου και συγκεκριµένα τα εξής: MC και MC14310 NEURON CHIPS Πρωτόκολλο LONTALK LONWORKS Tranceivers

154 ΑΡΤΙΟ Τελική έκθεση 154 Αναπτυξιακά εργαλεία (LONBUILDER, NODEBUILDER) To NEURON CHIP είναι ένας VLSI ελεγκτής ο οποίος εκτελεί ολοκληρωµένα αφ ενός το δικτυακό έργο (υλοποίηση του LONTALK πρωτοκόλλου) και αφ ετέρου το τοπικό έργο της εφαρµογής ελέγχου. Η βασική αρχιτεκτονική του NEURON CHIP παρουσιάζεται στο επόµενο σχήµα. Σχήµα 61. Το NEURON chip του LonWorks

155 ΑΡΤΙΟ Τελική έκθεση 155 Ενας τυπικός κόµβος του δικτύου LONWORKS αποτελείται από ένα NEURON CHIP, µία πηγή τροφοδοσίας, ένα tranceiver ειδικό για τον κάθε τύπο καναλιού επικοινωνίας και ένα κυκλωµατικό για την διασύνδεση µε την(ις) συσκευή(ές) πεδίου που θα διασυνδεθούν στον κόµβο, όπως φαίνεται στο επόµενο σχήµα. Σχήµα 6. Η αρχιτεκτονική του κόµβου LonWorks 8.. Αρχές Υλοποίησης LonWorks Σταθµού Το Visual Control graphical Programming είναι ένα γραφικό περιβάλλον που µπορεί να χρησιµοποιηθεί από τον προγραµµατιστή για την σχεδίαση της εφαρµογής χρησιµοποιώντας προκαθορισµένα Function Blocks. Στο περιβάλλον αυτό υπάρχουν περισσότερα από 90 έτοιµα Function Blocks (τύπου drag/drop/connect) τα οποία περιορίζουν την ανάγκη χρήσης κάποιας γλώσσας προγραµµατισµού (Neuron C). Στο VCGP υπάρχει η δυνατότητα σχεδιασµού καινούριων Functional Profiles που µπορούν να σχεδιαστούν από τα ήδη υπάρχοντα. Το περιβάλλον προγραµµατισµού µπορεί να θεωρηθεί ως ένα CASE (Computer Aided Software Engineering) εργαλείο το οποίο επιτρέπει σχεδιασµό ελέγχου και προγραµµατισµό µικροεπεξεργαστών που βρίσκονται στους κόµβους των δικτύων. Το VCGP είναι ένα πρόγραµµα που χρησιµοποιείται για ανάπτυξη εφαρµογών σε δίκτυα LonWorks. Το περιβάλλον του, πέραν της δυνατότητας σχεδιασµού και ανάπτυξης µίας εφαρµογής και την δυνατότητα του προγραµµατισµού των κόµβων, προσφέρει στον προγραµµατιστή την δυνατότητα υλοποίησης του Managing του δικτύου. Μία οθόνη του VCGP φαίνεται στο παρακάτω σχήµα όπου µπορούν να γίνουν φανερές οι λειτουργίες που περιγράφηκαν παραπάνω.

156 ΑΡΤΙΟ Τελική έκθεση 156 Το περιβάλλον ανάπτυξης εφαρµογών του VCGP παρέχει δυνατότητες οπτικού προγραµµατισµού η οποία είναι παρόµοια µε την IEC Τα Function Blocks που χρησιµοποιούνται εδώ έχουν ίδια δοµή, αποδίδονται και σε αυτά ιδιότητες που έχουν να κάνουν µε τις µεταβλητές τους και γίνεται η διασύνδεση των µεταβλητών τους οι οποίες δεν ανήκουν απαραίτητα στον ίδιο κόµβο. Τέλος, όπως προαναφέρθηκε υπάρχει και η δυνατότητα σχεδίασης καινούριων FB που αποτελούνται παραπάνω από ένα πρωτογενές FB. Ως εκ τούτου, ένα εργαλείο ανάπτυξης εφαρµογών, βασισµένο σε Function Blocks (IEEE 1449 ή IEC ), θα παρέχει τη δυνατότητα σχεδίασης της εφαρµογής µε γραφικό τρόπο, συνδυάζοντας τις λειτουργίες των FBs και θα παράγει εκτελέσιµο κώδικα (π.χ.,.nxe για Neuron Chip). Το αρχείο αυτό θα κατεβαίνει στους κόµβους όπου θα γίνεται η διασύνδεση (binding) των δικτυακών µεταβλητών εισόδου/εξόδου για την υλοποίηση της δικτυακής εφαρµογής. Σηµειώνεται ότι οι φορείς του προγράµµατος (και ιδιαίτερα το ΙΝΒΙΣ) έχουν µεγάλη εµπειρία στην ανάπτυξη προγραµµατιζόµενων σταθµών Lonworks µε αποτέλεσµα να έχουν υλοποιήσει ήδη τέτοιους σταθµούς και άρα δίκτυο Lonworks. Ως εκ τούτου δεν αναφέρεται αναλυτικά η διαδικασία ανάπτυξης τέτοιων σταθµών (και η αντίστοιχη χρήση των προαναφεροµένων εργαλείων ανάπτυξης) δεδοµένου ότι η τεχνολογία αυτή είναι ανοιχτή, σε αντίθεση µε αυτή του Profibus η οποία, όπως έχει αναφερθεί, είναι κλειστή (και δεν παρέχει δυνατότητες επαναπρογραµµατισµού).