Διπλωματική Εργασία : Σαρακατσάνος Ορέστης Επιβλέπων καθηγητής: Γεώργιος Χασάπης Καθηγητής

Transcript

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

2 2

3 Ευχαριστίες Η παρούσα διπλωματική εργασία ξεκίνησε τον Απρίλη του 2016 έχοντας παράλληλα κάποια ακόμα χρωστούμενα μαθήματα, οπότε κατά κύριο λόγο η εκπόνηση της έγινε το καλοκαίρι και το χειμερινό εξάμηνο του Πριν παρουσιαστεί η δουλεία που έγινε θα ήθελα να ευχαριστήσω κάποια συγκεκριμένα πρόσωπα που με βοηθήσαν κατά τη διάρκεια της. Αρχικά βεβαίως θα ήθελα να ευχαριστήσω τον υπεύθυνο Καθηγητή και πρόεδρο του τμήματος κ. Γεώργιο Χασάπη για τη λεπτομερή επεξήγηση της δουλείας που είχα να ολοκληρώσω όταν ανέλαβα την διπλωματική αυτή και την βοήθεια και διαθεσιμότητα του ανά πάσα στιγμή που χρειάστηκα επεξηγήσεις και οδηγίες. Ένα μεγάλο ευχαριστώ επίσης, στην οικογένεια μου. Για την βοήθεια, συμπαράσταση και κυρίως υπομονή και εμπιστοσύνη στις πολλές δυσκολίες που προέκυψαν καθ όλη τη διάρκεια των σπουδών μου. Τέλος, οφείλω να ευχαριστήσω τους φίλους μου που με άντεξαν και ήταν σχεδόν πάντα πρόθυμοι να βοηθήσουν και να με υποστηρίξουν κάθε στιγμή που τους ζητούσα και όχι μόνο. Στοιχεία συγγραφέα: Ορέστης Σαρακατσάνος: Προπτυχιακός φοιτητής του Τμήματος Ηλεκτρολόγων Μηχανικών και Μηχανικών Η/Υ Διεύθυνση κατοικίας: Κυθήρων 11, 54638, Θεσσαλονίκη Ηλεκτρονική Διεύθυνση: 3

4 Περίληψη Ο βασικός σκοπός της εργασίας αυτής ήταν η παρουσίαση μια μεθόδου που μετατρέπει ένα οποιοδήποτε δίκτυο συναρτησιακών διαγραμμάτων(fb), γραμμένου σύμφωνα με τις συστάσεις του προτύπου IEC61499, το οποίο συνιστά το λογισμικό ελέγχου μιας βιομηχανικής διαδικασίας, στο ισοδύναμο δίκτυο χρονικών αυτομάτων. Η μετατροπή αυτή επιτρέπει την ανάλυση του δικτύου των χρονικών αυτομάτων με μαθηματική λογική με στόχο να επαληθευθεί η ορθή εκτέλεση του λογισμικού που αντιστοιχεί σε αυτό το ισοδύναμο δίκτυο των χρονικών αυτομάτων και η οποία επαλήθευση, λόγω της μη φορμαλιστικής δομής της γλώσσας των FB, δεν μπορεί να γίνει με μαθηματική ανάλυση. Σύμφωνα με την προτεινόμενη μέθοδο πρώτα δημιουργείται ισοδύναμο με κάθε FB, μοντέλο χρονικών αυτομάτων. που περιγράφει τη λειτουργία μιας FB. Στη συνέχεια δημιουργούνται αρχεία γλώσσας XML που κωδικοποιούν τα αυτόματα αυτά και στα οποία στηρίζεται η κατασκευή ενός άλλου αρχείου XML που περιλαμβάνει και την περιγραφή του τρόπου διασύνδεσης των μοντέλων των χρονικών αυτομάτων που αντιστοιχούν στα FB ενός προγράμματος, όπως αυτός ο τρόπος καθορίζεται από το συνολικό πρόγραμμα μιας εφαρμογής. Περιγράφεται επίσης η λειτουργία και οι δυνατότητες του προγράμματος Uppaal το οποίο αποτελεί το εργαλείο μέσω του οποίου μπορεί να αναλυθεί και προσομοιωθεί η εκτέλεση κάθε δικτύου χρονικών αυτομάτων με στόχο την επαλήθευση της ορθής και ασφαλούς λειτουργίας του λογισμικού που αντιστοιχεί στο συγκεκριμένο μοντέλο χρονικών αυτομάτων. Η εφαρμογή της μεθόδου και η χρήση του UPPAAL για την επαλήθευση μερικών σεναρίων ορθής εκτέλεσης λογισμικού ελέγχου βιομηχανικών διεργασιών επιδεικνύεται μέσω ενός παραδείγματος. 4

5 ARISTOTLE UNIVERSITY OF THESSALONIKI FACULTY OF ENGINEERING DEPARTEMNT OF ELECTRICAL AND COMPUTER ENGINEERING Verification of a software s proper functionality which is written according to IEC61499 Standard by its transformation into a network of Timed Automata Diploma Thesis : Sarakatsanos Orestis Supervisor: Georgios Chasapis Professor Thessaloniki, February

6 6

7 Abstract The main purpose of this work is to propose a method which converts any given network of Function Block diagrams, which constitutes the control software of an industrial process, to an equivalent network of timed automata. This conversion allows the analysis of the network of timed automata by using mathematical logic and aims at verifying the correct execution of the software that corresponds to the equivalent network of timed automata. Such a software cannot be mathematically analyzed and proved to run correctly under any possible scenarios of operation because of the informal structure of the FB language. According to the proposed method, first the network of timed automata is formed which is equivalent to each FB of the application software. Next, XML files are created coding these FB timed automata. On the basis of these automata another XML file is formed including the description of the interconnections among the various FBs of the application software. Also in this work, the functions of the UPPAAL suite of verification tools is presented. This suite can be used to analyze, simulate and verify by the use of tree logic the execution of any network of timed automata that corresponds to a FBbased application software. The implementation of the proposed method and the use of UPPAAL to verify a few operating scenario of control software is demonstrated through a simple example. 7

8 Περιεχόμενα Ευχαριστίες... 3 Περίληψη... 4 Abstract... 7 Συντομογραφίες-Abbreviations Εισαγωγή Αντικείμενο της Διπλωματικής Εργασίας Στόχοι της Διπλωματικής Εργασίας Δομή της Διπλωματικής Εργασίας Δομή των Function Block[1,11] Εισαγωγή στη λογική των FB FB με βάση το πρότυπο IEC Μοντέλο Εκτέλεσης των FB Τύποι FB Βασικά FB Ορισμός Εσωτερικής Συμπεριφοράς ενός βασικού FB Ορισμός σύνθετων FB FB Υπηρεσιών Διασύνδεσης (Communication Service Interface FB) Κατασκευή ισοδύναμου Χρονικού Αυτομάτου μιας Συναρτησιακής Οντότητας Εισαγωγή Χρήση χρονικών αυτομάτων για επαλήθευση εφαρμογών του προτύπου IEC61499[3] UPPAAL

9 4.1 Εισαγωγή Χρονικά Αυτόματα στο Uppaal Εκφράσεις στο Uppaal Γλώσσα Ερωτημάτων Επισκόπηση της Εργαλειοθήκης του UPPAAL Editor Προσομοιωτής (Simulator) Επαληθευτής (Verifier) Κατασκευή των αρχείων XML των χρονικών αυτομάτων που αντιστοιχούν σε λογισμικό FB Παράδειγμα Επαλήθευση της ορθής λειτουργίας του λογισμικού μιας απλής εφαρμογής ελέγχου διεργασίας Συγγραφή XML Εισαγωγή ερωτημάτων στον Επαληθευτή του Uppaal Επαλήθευση σωστής λειτουργίας του δικτύου Εισαγωγή εκούσιων σφαλμάτων Συμπεράσματα Μελλοντικές Επεκτάσεις Βιβλιογραφία

10 Συντομογραφίες-Abbreviations FB - Function Block TA Timed Automata UPPAAL- Uppsala and Aaalborg (University) XML Extensible Markup Language IEC- International Electrotechnical Commission I/O Input-Output 10

11 1 Εισαγωγή 1.1 Αντικείμενο της Διπλωματικής Εργασίας Τα τελευταία χρόνια υπάρχει ιδιαίτερο ενδιαφέρον στην κατασκευή νέων εξελιγμένων κατανεμημένων βιομηχανικών συστημάτων ελέγχου. Το λογισμικό σε αυτά τα συστήματα θα είναι οργανωμένο σε σύνολα συστατικών (components) και όχι μια ενιαία οντότητα. Η ανάπτυξη των βιομηχανικών συστημάτων ελέγχου μέχρι πρόσφατα, στηριζόταν στις τεχνολογίες των κατανεμημένων συστημάτων ελέγχου (Distributed Control Systems) και στους προγραμματιζόμενους λογικούς ελεγκτές (PLC). Χαρακτηριστικό και των δύο αυτών ειδών συστημάτων είναι ότι το λογισμικό τους γράφεται σε μεγάλα μονολιθικά πακέτα που μπορούν με δυσκολία να χρησιμοποιηθούν ξανά σε καινούριες εφαρμογές και αδυνατούν να συνεργαστούν μεταξύ τους. Για την κατασκευή νέων ευέλικτων συστημάτων τα οποία μπορούν να τροποποιηθούν σύμφωνα με τις νέες ανάγκες βιομηχανικού ελέγχου, ήταν αναγκαία η ανάπτυξη μιας τεχνολογίας με στόχο την συνεργασία των κατανεμημένων αντικειμένων. Είναι πλέον αποδεκτό από την βιομηχανική κοινότητα ότι η άμεση διασύνδεση συστατικών λογισμικού, όπως οι συναρτησιακές οντότητες (Function Blocks-FB) έχει να προσφέρει πολλά οφέλη στους χρήστες. Το πρότυπο IEC 61499[1] λοιπόν δημιουργήθηκε με σκοπό να καλύψει αυτές τις νέες ανάγκες. Προτείνει μια μεθοδολογία και μοντέλο για την ανάπτυξη της αρχιτεκτονικής του λογισμικού ενός κατανεμημένου υπολογιστικού συστήματος βιομηχανικού ελέγχου βασισμένη στο βασικό δομικό στοιχείο που είναι η συναρτησιακή οντότητα (Function Block (FB). Περιέχει ένα μοντέλο εφαρμογών και επαναχρησιμοποιήσιμων τμημάτων λογισμικού με στόχο την ανάπτυξη βιομηχανικών εφαρμογών κατανεμημένου ελέγχου και μετρήσεων επιτρέποντας σαφή προσδιορισμό της σειράς εκτέλεσης των FB. Το πρότυπο αυτό επιτρέπει μια σχεδίαση μέσω της οποίας μια η περισσότερες εφαρμογές, που προσδιορίζονται από δίκτυα διασυνδεδεμένων FB, δημιουργούνται για όλο το σύστημα και κατά συνέπεια διανέμονται σε όλες τις διαθέσιμες συσκευές. Ένα βασικό πρόβλημα του λογισμικού συστημάτων ελέγχου βιομηχανικών διεργασιών είναι η επαλήθευση της εκτέλεσής του σύμφωνα με τις προδιαγραφές που έχουν τεθεί να ικανοποιεί και η απόδειξη ότι δεν υπάρχει κίνδυνος να βρεθεί 11

12 σε καταστάσεις που μπορούν να οδηγήσουν τις ελεγχόμενες βιομηχανικές διατάξεις σε επικίνδυνη και καταστροφική λειτουργία. Η απόδειξη αυτή γίνεται με την εφαρμογή τυπικών μεθόδων επαλήθευσης (formal methods), οι οποίες προσπαθούν να περιγράψουν με μαθηματικό τρόπο τις λειτουργίες που επιτελεί ο κώδικας του λογισμικού και στη συνέχεια να διεξάγουν μια εξαντλητική ανάλυση των καταστάσεων στις οποίες μπορεί να βρεθεί ο κώδικας κατά την εκτέλεσή του κάτω από όλα τα πιθανά σενάρια. Η απόδειξη ότι κατά εκτέλεση όλων αυτών των πιθανών σεναρίων δεν θα βρεθεί το λογισμικό σε καταστάσεις που αντιστοιχούν σε ανασφαλή λειτουργία του ελεγχόμενου συστήματος, συνιστά την επαλήθευση της ορθής λειτουργίας του λογισμικού. Το αντικείμενο της εργασίας αυτής ήταν να προταθεί μια μέθοδος μετατροπής λογισμικού γραμμένου στη γλώσσα των συναρτησιακών οντοτήτων που ορίζεται στο πρότυπο IEC σε ένα ισοδύναμο φορμαλιστικό μοντέλο από την ανάλυση των καταστάσεων του οποίου θα μπορούσε να συναχθεί συμπέρασμα ως προς την ασφαλή ή όχι λειτουργία του ελεγχόμενου συστήματος. Η επιλογή του φορμαλισμού έγινε με βάση την ύπαρξη ώριμων λογισμικών εργαλείων που επιτελούν την ανάλυση των καταστάσεων. Ένα τέτοιο λογισμικό εργαλείο είναι το UPPAAL[5,6,9], που αναλύει δίκτυα χρονικών αυτομάτων. Για το λόγο αυτό προτείνεται στην εργασία αυτή μια τεχνική μετατροπής των δικτύων των συναρτησιακών διαγραμμάτων σε ισοδύναμα δίκτυα χρονικών αυτομάτων και κατασκευή σχετικού λογισμικού που αυτοματοποιεί τη μετατροπή αυτή και δημιουργεί μορφοποιημένο αρχείο κατάλληλο να αναγνωστεί από το UPPAAL για να μπορέσει να αναλυθεί. Η μέθοδος προβλέπει την καταρχήν δημιουργία μια βιβλιοθήκης χρονικών αυτομάτων σε XML για κάθε ένα τύπο συναρτησιακού διαγράμματος του προτύπου IEC Στη συνέχεια προβλέπει τη δημιουργία ενός νέου αρχείου XML το οποίο θα προκύπτει από την περιγραφή του δικτύου των συναρτησιακών διαγραμμάτων μιας εφαρμογής και τα αρχείο XML ενός εκάστου συναρτησιακού διαγράμματος της βιβλιοθήκης. Το εν λόγω αρχείο XML θα αντιστοιχεί πρακτικά στο ισοδύναμο ολοκληρωμένο δίκτυο χρονικών αυτομάτων του προγράμματος της εφαρμογής που έχει γραφεί σύμφωνα με τις συστάσεις του προτύπου ΙΕC Το εν λόγω αρχείο XML είναι αναγνώσιμο από το UPPAAL και κατά συνέπεια μπορεί να γίνει ανάλυση των καταστάσεων του δικτύου των χρονικών αυτομάτων και να συναχθούν συμπεράσματα ως προς την ασφαλή ή όχι 12

13 λειτουργία του ισοδύναμου λογισμικού της εφαρμογής που γράφτηκε στη γλώσσα του προτύπου IEC Στόχοι της Διπλωματικής Εργασίας Ο βασικός στόχος της εργασίας ήταν να επιδειχθεί η δυνατότητα υλοποίησης της παραπάνω ιδέας (proof of concept) και όχι η πλήρης ανάπτυξη της βιβλιοθήκης των ισοδύναμων χρονικών αυτομάτων όλων των συναρτησιακών διαγραμμάτων του προτύπου IEC61499 που απαιτεί μεγάλο όγκο εργασίας και δεν μπορεί να υλοποιηθεί μέσα στα χρονικά πλαίσια μιας διπλωματικής εργασίας. Για το σκοπό αναπτύχθηκαν τα χρονικά αυτόματα των πλέον βασικών συναρτησιακών διαγραμμάτων και χρησιμοποιήθηκε μια απλή εφαρμογή αυτοματισμού για να επιδειχθεί η δυνατότητα υλοποίησης της ιδέας της επαλήθευσης λογισμικού γραμμένου σύμφωνα με τις συστάσεις του προτύπου IEC61499 με την προτεινόμενη τεχνική. Η επίδειξη της δυνατότητας υλοποίησης της παραπάνω ιδέας θα έπρεπε να γίνει μέσω της ακόλουθης εφαρμογής. Ένα δίκτυο συναρτησιακών διαγραμμάτων λαμβάνει μια τιμή τάσης από ένα αισθητήριο θερμοκρασίας και την πολλαπλασιάζει με μία σταθερά για να υπολογίσει τη τιμή της θερμοκρασίας που αντιστοιχεί στη λαμβανόμενη τάση (με την υπόθεση ότι η χαρακτηριστική καμπύλη του αισθητηρίου είναι γραμμική). Στη συνέχεια υπολογίζει τη διαφορά από μία επιθυμητή θερμοκρασία και την πολλαπλασιάζει με ένα κέρδος για να υπολογίσει την τιμή μιας υποτιθέμενης χειριζόμενης μεταβλητής που επηρεάζει τη ροή καυσίμων σε έναν λέβητα στον οποίο θερμαίνεται νερό, τη θερμοκρασία του οποίου μετρά το αισθητήριο. 13

14 Αναλυτικότερα, επαλήθευση της ορθής λειτουργίας του θα πρέπει να γίνει με τα εξής βήματα: Κατασκευή της μορφής του χρονικού αυτομάτου (Timed Automaton) για κάθε FB. Συγγραφή αρχείων XML που περιγράφει τα αυτόματα, αρχικά ένα για κάθε FB και τελικώς ένα ενιαίο αρχείο ολόκληρου του δικτύου και Εισαγωγή του ενιαίου αρχείου XML στο πρόγραμμα Uppaal και επαλήθευση των ζητουμένων μας μέσω αυτού. 14

15 1.3 Δομή της Διπλωματικής Εργασίας Μετά το τρέχον πρώτο εισαγωγικό Κεφάλαιο, η διπλωματική εργασία ακολουθεί την εξής δομή: Στο Δεύτερο Κεφάλαιο παρουσιάζεται η δομή, ο τρόπος λειτουργίας και το θεωρητικό υπόβαθρο της γλώσσας των συναρτησιακών διαγραμμάτων (Function Blocks (FB). Εξηγείται η λογική και ο τρόπος λειτουργίας τους σύμφωνα με το πρότυπο IEC61499 και παρουσιάζεται ο τρόπος συγγραφής λογισμικού ελέγχου βιομηχανικών διεργασιών. Στο Τρίτο Κεφάλαιο παρουσιάζεται μια μεθοδολογία σύμφωνα με την οποία μπορεί να δημιουργηθεί ένα σύνολο χρονικών αυτομάτων ισοδύναμο λειτουργικά με ένα FB. Περιγράφονται τα βήματα που πρέπει να ακολουθηθούν ώστε να δημιουργηθούν καταρχάς αυτόματα ισοδύναμα του ενός FB και στη συνέχεια για ένα ολόκληρο δίκτυο διασυνδεδεμένων χρονικών αυτομάτων που αντιστοιχεί σε ένα ολοκληρωμένο δίκτυο FB λογισμικού ελέγχου βιομηχανικής διεργασίας.. Στο Τέταρτο Κεφάλαιο περιγράφεται το εργαλείο Uppaal. Εξηγούνται οι δυνατότητες του και ο τρόπος λειτουργίας του. Στο Πέμπτο Κεφάλαιο περιγράφεται η γενική μορφή της γλώσσας XML που διαβάζεται από το Uppaal και παρουσιάζονται τα χαρακτηριστικά της και ο τρόπος συγγραφής των αρχείων XML που περιγράφουν τα ζητούμενα χρονικά αυτόματα. Στο Έκτο Κεφάλαιο παρουσιάζεται ένα παράδειγμα μέσω του οποίου έγινε προσπάθεια απόδειξης της ορθότητας της προτεινόμενης μεθόδου. Παρουσιάζεται το δίκτυο του παραδείγματος, και περιγράφονται λεπτομερώς τα χαρακτηριστικά των αυτομάτων για το κάθε FB του δικτύου αυτού, και οι τρόποι σύνδεσης και επικοινωνίας μεταξύ των αυτομάτων. Εισάγονται ερωτήματα σε έναν επαληθευτή που περιέχει το εργαλείο του Uppaal μέσω των οποίων προσπαθούμε να πάρουμε τα ζητούμενα αποτελέσματα που αποδεικνύουν την ορθότητα της προτεινόμενης μεθόδου. Τέλος παρατίθενται τα συμπεράσματα που προέκυψαν και γίνεται μια μικρή συζήτηση για πιθανές μελλοντικές χρήσεις και βελτιώσεις. 15

16 2 Δομή των Function Block[1,11] 2.1 Εισαγωγή στη λογική των FB Ένα Function Block (FB) ορίζεται ως η βασική οντότητα μιας γραφικής γλώσσας για τη συγγραφή λογισμικού προγραμματιζόμενων λογικών ελεγκτών (PLC) και κατανεμημένων συστημάτων βιομηχανικού ελέγχου. Μπορούν να περιγράψουν την αλγοριθμική σχέση που υπάρχει μεταξύ των μεταβλητών εισόδου και εξόδου του FB και να διασυνδεθούν μεταξύ τους με γραμμές σύνδεσης. Χρησιμοποιούν ένα διάγραμμα καταστάσεων μηχανής (Execution Control Chart-ECC) για τον καθορισμό του ελέγχου εκτέλεσης των αλγορίθμων τους. Τα FB επιτρέπουν τους αλγόριθμους να περιγραφούν σε μια μορφή εύκολα αναγνώσιμη και κατανοητή από άτομα μη εξοικειωμένα με τη συγγραφή και ανάγνωση αλγορίθμων. Κάθε FB έχει έναν προκαθορισμένο αριθμό εισόδων δεδομένων που διαβάζονται κατά την εκτέλεση του εσωτερικού αλγορίθμου και τα αποτελέσματα της εκτέλεσης εμφανίζονται ως νέα δεδομένα στις εξόδους του. Συνδέοντας εισόδους FB με εξόδους άλλων μπορούμε να σχηματίσουμε δίκτυα FB τα οποία εκτελούν σύνθετες λειτουργίες ελέγχου και αυτοματοποίησης. 2.2 FB με βάση το πρότυπο IEC Το πρότυπο IEC ορίζει ένα γενικό μοντέλο και μεθοδολογία περιγραφής των FB σε μορφή ανεξάρτητη της υλοποίησης τους και εισάγει μια σειρά από ορισμούς που σχετίζονται με τις φυσικές συσκευές και FB. Σύμφωνα με την διαδικασία που προτείνεται στο πρότυπο η σχεδίαση λογισμικού μιας εφαρμογής αρχίζει με τον ορισμό του μοντέλου του συστήματος μέσα στο οποίο ορίζονται οι συσκευές που το αποτελούν, το δίκτυο με το οποίο επικοινωνούν και οι εφαρμογές που θα εκτελεστούν. Το μοντέλο θεωρείται ένας υπολογιστής με επεξεργαστή, μνήμη και δίκτυο επικοινωνίας. Ως συσκευές θεωρούνται τα PLC που λειτουργούν με βάση κάποια λογική ελέγχου και διατάξεις όπως οι έξυπνοι ενεργοποιητές, έξυπνες βαλβίδες, έξυπνα αισθητήρια κλπ. Κάθε σύστημα είναι ικανό να υποστηρίξει εκτέλεση πολλών εφαρμογών και κάθε 16

17 εφαρμογή μπορεί να τρέξει είτε σε μία συσκευή είτε σε πολλές που μοιράζονται το φορτίο της. Η Εικόνα 2.1 παρουσιάζει ένα μικρό δίκτυο τριών FB μεταξύ των οποίων υπάρχουν συνδέσεις που αντιπροσωπεύουν τον τρόπο επικοινωνίας μεταξύ των FB καθώς και η ροή γεγονότων και δεδομένων. Εικόνα 2.1 Παράδειγμα δικτύου τριών συναρτησιακών οντοτήτων. Για παράδειγμα μπορούμε να θεωρήσουμε ότι το αριστερό FB διαβάζει μια τιμή φυσικής μεταβλητής, το μεσαίο υπολογίζει με βάση έναν αλγόριθμο τις πράξεις και διορθώσεις που πρέπει να κάνει στην χειριζόμενη μεταβλητή και τέλος το δεξιά FB μετατρέπει την τιμή της διόρθωσης στη ζητούμενη τιμή που πρέπει να έχει το ηλεκτρικό σήμα στον ενεργοποιητή του τελικού στοιχείου. Η ροή των γεγονότων δείχνει τη δρομολόγηση της εκτέλεσης κάθε FB του δικτύου. 17

18 Με βάση όσα ορίζονται στο πρότυπο IEC το κάθε FB πρέπει να έχει τα ακόλουθα κύρια χαρακτηριστικά: Κάθε FB έχει όνομα του είδους του και το όνομα του στιγμιότυπού του. Κάθε FB μπορεί να έχει εισόδους και εξόδους γεγονότων, οι οποίες μπορούν να δέχονται και να διαδίδουν αντίστοιχα, γεγονότα από και προς άλλα FB μέσω των μεταξύ τους διασυνδέσεων. Κάθε FB μπορεί να έχει εισόδους και εξόδους δεδομένων οι οποίες επιτρέπουν τιμές δεδομένων να διαβάζονται και να στέλνονται από και προς αντίστοιχα άλλα FB. Γεγονότα μπορούν να συσχετιστούν με δεδομένα χρησιμοποιώντας τη λέξη WITH. Στη γραφική απεικόνιση του FB η συσχέτιση αυτή παρουσιάζεται ως ένας μικρός τετραγωνικός σύνδεσμος της κάθετης γραμμής η οποία ξεκινά από την είσοδο του γεγονότος με την είσοδο των δεδομένων. Με τη συσχέτιση αυτή, στην περίπτωση εμφάνισης γεγονότος η είσοδος που σχετίζεται με το γεγονός επικαιροποιείται αλλά οι άλλες είσοδοι διατηρούν τις προηγούμενες τιμές τους, ενώ στην περίπτωση των εξόδων η συσχέτιση αυτή ισοδυναμεί με το ότι τα δεδομένα αυτών είναι διαθέσιμα σε άλλα FB. Δηλαδή σε περίπτωση που μια είσοδος ή έξοδος δεδομένων δε συσχετίζεται με κάποιο γεγονός, τότε δε μπορεί να συνδεθεί με άλλο FB και πρέπει να θεωρηθεί ότι διατηρεί μια σταθερή τιμή καθ όλη τη διάρκεια της εκτέλεσης της εφαρμογής. Συνεπάγεται λοιπόν ότι το FB πρέπει να διαθέτη και κάποια μνήμη αποθήκευσης αυτών των τιμών. Σε περίπτωση που το FB δέχεται γεγονότα με ρυθμό μεγαλύτερο απ ότι μπορεί να αποθηκεύσει και να επεξεργαστεί, το πρότυπο προβλέπει τον καθορισμό της προτεραιότητας εκτέλεσης του ώστε να αποφευχθούν καταστάσεις υπερφόρτωσης. Κάθε FB περιλαμβάνει αλγορίθμους με εσωτερικές μεταβλητές και οι λειτουργίες των αλγορίθμων αυτών είναι εξαρτώμενες από τον τύπο του FB. Κάθε τέτοιος αλγόριθμος έχει πρόσβαση μόνο στις εισόδους, εξόδους και εσωτερικές μεταβλητές του FB. Μεταξύ διαδοχικών κλήσεων ενός στιγμιότυπου του FB, διατηρούνται οι τιμές όλων των δεδομένων. 18

19 Ένα FB έχει την παρακάτω γενική μορφή: Εικόνα 2.2 Γενική μορφή FB Το πάνω τμήμα που ονομάζεται «τμήμα ελέγχου εκτέλεσης» περιγράφει τον τρόπο που οι λειτουργίες των προγραμμάτων ενεργοποιούνται από τα γεγονότα. Ορίζει δηλαδή ποια λειτουργία ενεργοποιείται με την άφιξη κάθε γεγονότος στο τμήμα και ποια γεγονότα εξόδου παράγονται. Το κάτω τμήμα περιέχει το σύνολο των προγραμμάτων που προβλέπονται από τον συγκεκριμένο τύπο του FB και τα πιθανά εσωτερικά δεδομένα. Το πρότυπο προτείνει να παρέχονται πόροι που επιτρέπουν πρόσβαση στο εσωτερικό του στιγμιότυπου του FB για την ανάγνωση εσωτερικών μεταβλητών και κυρίως για εξυπηρέτηση αναγκών συντήρησης. 19

20 2.3 Μοντέλο Εκτέλεσης των FB Η παρακάτω εικόνα εμφανίζει τις φάσεις εκτέλεσης των διάφορων τμημάτων ενός FB. Η υπηρεσία δρομολόγησης με βάση την οποία εκτελείται το περιβάλλον ορίζει τα χρονικά όρια εκτέλεσης της κάθε φάσης του. Εικόνα 2.3 Οι φάσεις που απεικονίζονται εκτελούνται με την εξής σειρά: 1. Εισερχόμενα δεδομένα από άλλα FB καθίστανται διαθέσιμα στις εισόδους του συγκεκριμένου FB. 2. Σύμφωνα με το γεγονός που φτάνει ενεργοποιούνται αντίστοιχα οι είσοδοι που είναι συσχετισμένες με αυτό. 3. Το τμήμα ελέγχου της εκτέλεσης σηματοδοτεί στο δρομολογητή ότι είναι έτοιμη να πραγματοποιηθεί μία δράση της εσώκλειστης λειτουργικότητας. 4. Μετά από ένα χρονικό διάστημα ο δρομολογητής αρχίζει την εκτέλεση της συγκεκριμένης δράσης. 5. Η εσώκλειστη δράση προσπελάσει και επεξεργάζεται τις τιμές των συσχετισμένων εισόδων, καθώς και τις εσωτερικά αποθηκευμένες τιμές όταν αυτό είναι απαραίτητο και υπολογίζει τις νέες τιμές που γράφονται στις εξόδους του FB. 6. Ολοκληρώνεται η τρέχουσα εκτέλεση και ενημερώνει τον δρομολογητή ότι οι νέες τιμές εξόδων είναι έτοιμης για περαιτέρω χρήση. 20

21 7. Καλείται το τμήμα ελέγχου της εκτέλεσης και ενημερώνεται για ολοκλήρωση της εκτέλεσης και αυτό με τη σειρά του δημιουργεί το γεγονός εξόδου. 8. Το τμήμα ελέγχου εκτέλεσης στη συνέχεια δημιουργεί ένα γεγονός εξόδου και οι συσχετιζόμενοι έξοδοι του FB καθίστανται διαθέσιμες στις σχετικές εισόδους του επόμενου FB. To πρότυπο υποθέτει ότι δεν υπάρχουν ουρές γεγονότων εισόδου και δεδομένων για ένα FB. Αυτός ο περιορισμός θα πρέπει να εξασφαλίζεται από το περιβάλλον μέσα στο οποίο εκτελείται το κάθε στιγμιότυπο του FB. Προαιρετικά όμως μπορούν να δημιουργηθούν ουρές γεγονότων και δεδομένων με σκοπό την αποφυγή απώλειας τους και με κατάλληλο ορισμό προτεραιοτήτων μπορούν να αποφευχθούν προβλήματα υπερφόρτωσης των επεξεργαστών. 2.4 Τύποι FB H συμπεριφορά και ο τρόπος λειτουργίας ενός FB ορίζεται από τον τύπο του, κάτι που ισοδυναμεί με τον ορισμό της τάξης του αντικειμένου στον αντικειμενοστραφή προγραμματισμό. Ο τύπος ενός FB προσδιορίζεται από ένα όνομα, ορισμούς γεγονότων και δεδομένων εισόδου και εξόδου. Κάθε διαφορετικός τύπος FB ισοδυναμεί με διαφορετική εσωτερική συμπεριφορά. Σε γενικές γραμμές τα FB χωρίζονται σε τρία είδη: 1. Βασικοί τύποι: Η συμπεριφορά τους καθορίζεται από τους αλγορίθμους που εκτελούνται κατά την ενεργοποίηση ενός γεγονότος εισόδου. Η εκτέλεση αλγορίθμου προκαλεί τη δημιουργία γεγονότων εξόδου και σηματοδοτείται η αλλαγή κάποιας κατάστασης στο εσωτερικό του FB. Η αντιστοίχιση των γεγονότων με τους αλγορίθμους που πρέπει να εκτελεστούν καθορίζεται με βάση το διάγραμμα μεταβολής καταστάσεων (ECC) που αναφέρθηκε εν συντομία προηγουμένως. 2. Σύνθετοι τύποι: O ορισμός τους περιλαμβάνει διασυνδέσεις δεδομένων και γεγονότων και η συμπεριφορά τους καθορίζεται από ένα δίκτυο στιγμιότυπων FB. 3. Τύποι υπηρεσιών διασύνδεσης: Αυτός ο τύπος FB παρέχει μια διεπαφή επικοινωνίας μεταξύ των λειτουργιών που εκτελεί κάθε FB και των εξωτερικών υπηρεσιών που χρειάζεται για τις λειτουργίες αυτές. Η λειτουργία τους περιγράφεται με ακολουθιακά διαγράμματα. 21

22 2.5 Βασικά FB Ένα βασικό FB ορίζεται με τον προσδιορισμό της εξωτερικής του διεπαφής, του ECC και των αλγορίθμων που περιγράφουν την λειτουργικότητα του. Οι αλγόριθμοι μπορούν να γραφούν σε οποιαδήποτε γλώσσα δομημένου κειμένου, Java, C. Τα γεγονότα μπορούν να οριστούν ώστε να επιτρέπουν λήψη μόνο συγκεκριμένου τύπου. Σε περίπτωση που δεν προσδιοριστεί κάποιος τύπος, ένα γεγονός θεωρείται ότι είναι γενικού τύπου EVENT, και κάθε είσοδος γεγονότων μπορεί να δεχτεί γεγονότα οποιουδήποτε τύπου. Εικόνα 2.4 Τμήματα ενός FB που ορίζονται Στην παραπάνω εικόνα φαίνονται τα τμήματα ενός FB που πρέπει να ορισθούν. Γενικά σε κάθε βασικό FB πρέπει να πληρούνται τα εξής χαρακτηριστικά : Το όνομα του τύπου του FB ορίζεται στο κέντρο, στη θέση του κειμένου «FB_Type_Name». Οι είσοδοι βρίσκονται πάντα στην αριστερή πλευρά και οι έξοδοι στη δεξιά. Τα ονόματα των εσωτερικών και εξωτερικών μεταβλητών της κάθε γραμμής εισόδου και εξόδου, αναγράφονται στο εσωτερικό της αριστερής και δεξιάς πλευράς αντίστοιχα. Οι τύποι δεδομένων εισόδων και εξόδων γράφονται αριστερά και δεξιά από τις γραμμές σύνδεσης εισόδων και εξόδων όπως φαίνονται στο σχήμα. Παρόλο που η παραπάνω γραφική απεικόνιση ενός FB παρέχει θεωρητικά ικανοποιητική πληροφορία για την περιγραφή και δήλωση του, ο βασικός στόχος του προτύπου είναι το κάθε FB να μπορεί να αναπαρασταθεί και με κείμενο ή γλώσσα XML. 22

23 2.5.1 Ορισμός Εσωτερικής Συμπεριφοράς ενός βασικού FB Η εσωτερική συμπεριφορά κάθε βασικού FB προσδιορίζεται από τις δράσεις του αλγορίθμου και από το διάγραμμα ελέγχου ECC που τη χαρακτηρίζει. Το ECC περιγράφει τη σχέση μεταξύ γεγονότων και εκτέλεσης του αλγορίθμου, και μπορεί επίσης να απεικονιστεί είτε με γραφικό τρόπο είτε να οριστεί με κείμενο. Κάθε ECC ορίζει : Τις εσωτερικές καταστάσεις του FB. Τον τρόπο αντίδρασης του σε κάθε εισερχόμενο γεγονός. Ποιοι αλγόριθμοι θα ενεργοποιηθούν σε σχέση με τα εισερχόμενα γεγονότα, και με ποια σειρά. Ποια εξερχόμενα γεγονότα θα παραχθούν όταν οι σχετικοί με αυτά τα γεγονότα αλγόριθμοι ολοκληρωθούν. Η εικόνα 2.5 παρουσιάζει ένα παράδειγμα ECC. Απεικονίζονται οι τέσσερις καταστάσεις START, State1, State2, State3 που πρακτικά αντιστοιχούν στις τέσσερις καταστάσεις που μπορεί να βρεθεί ένα FB. H κατάσταση START αποτελεί την αρχική κατάσταση του FB. Με την είσοδο στην κατάσταση State1 ο αλγόριθμος Alg1 θα εκτελεστεί και θα παράγει το γεγονός EO1. Αντίστοιχα ο Alg2 θα εκτελεστεί όταν το FB μεταβεί στην State2. Η μετάβαση από τη μία κατάσταση στην άλλη μπορεί να προκληθεί από: a) Ένα γεγονός b) Ένα γεγονός σε συνδυασμό με την ικανοποίηση μιας λογικής δυαδικής σχέσης c) Από μια την ικανοποίηση μιας λογικής σχέσης d) Από καμία συνθήκη 23

24 Εικόνα 2.5 Παράδειγμα λειτουργίας ενός FB. Όπως φαίνεται και στην Εικόνα 2.5, η μετάβαση από την κατάσταση START στην State1 θα πραγματοποιηθεί όταν συμβεί το γεγονός EI1 ενώ από την START στην State2 όταν συμβεί το γεγονός EI2 ενώ παράλληλα η τιμή της εισόδου DI2 είναι μεγαλύτερη του μηδενός. Τέλος, οι γενικοί κανόνες χρήσης του ECC είναι οι εξής: Κάθε FB έχει αποκλειστικά μόνο ένα ECC, το οποία σύμφωνα με τους κανόνες του προτύπου IEC61499 μπορεί να ορίζεται είτε γραφικά, είτε με συγκεκριμένες εντολές και κανόνες που προβλέπονται από το πρότυπο. Κάθε ECC έχει μόνο μία αρχική κατάσταση η οποία γραφικά παριστάνεται με ένα παραλληλόγραμμο με διπλές γραμμές των πλευρών του. Αντίθετα μπορεί να έχει μία ή περισσότερες καταστάσεις που γραφικά αναπαρίστανται με παραλληλόγραμμα ή κύκλους. Κάθε κατάσταση μπορεί να αντιστοιχεί από καμία ως πολλές δράσεις. Κάθε δράση συνήθως σχετίζεται με έναν αλγόριθμο και ένα εξερχόμενο γεγονός. Τυπικά μια κατάσταση του FB θα έχει τουλάχιστον μία δράση που διεγείρει ένα εξερχόμενο γεγονός το οποίο ενημερώνει ότι ορισμένες έξοδοι έχουν νέα δεδομένα. Το ECC μπορεί να χρησιμοποιεί μεταβλητές που έχουν οριστεί μέσα στο FB αλλά δε μπορεί να τις τροποποιήσει. 24

25 Διάφορες μεταβάσεις μπορούν να καταλήγουν στην ίδια κατάσταση, ενώ επίσης διαφορετικές μεταβάσεις με άλλες συνθήκες μπορούν να ξεκινούν από την ίδια κατάσταση. Η κάθε μετάβαση πραγματοποιείται με βάση την προτεραιότητα της, που σημειώνεται με έναν αύξοντα αριθμό σε κύκλο. 2.6 Ορισμός σύνθετων FB Σύνθετοι τύποι FB μπορούν να κατασκευαστούν με τη διασύνδεση βασικών τύπω, άλλων σύνθετων FB και FB διασύνδεσης υπηρεσιών. Η γενική μορφή είναι η εξής: Εικόνα 2.6 Βασική μορφή ενός σύνθετου FB. Ενώ οι κανόνες για τον ορισμό των συνδέσεων των γεγονότων είναι οι παρακάτω: Κάθε είσοδος γεγονότων του σύνθετου FB πρέπει να συνδέεται σε μία είσοδο γεγονότων ενός εσωτερικού FB ή διαφορετικά θα πρέπει να διαπερνά το σύνθετο FB και να συνδέεται σε μια έξοδο του για γεγονότα. Είναι αδύνατο να συνδεθεί μια είσοδος γεγονότων του σύνθετου FB με πολλές εισόδους γεγονότων εσωτερικών FB ταυτόχρονα. Ωστόσο υπάρχει μια ειδική μορφή FB, το Ε_SPLIT το οποίο επιτρέπει τη δημιουργία πολλών ανεξάρτητων γραμμών γεγονότων από τη γραμμή εισόδου, όταν αυτό είναι απαραίτητο. 25

26 Κάθε είσοδος γεγονότων ενός εσωτερικού βασικού ή σύνθετου FB πρέπει να συνδέεται μόνο σε μία έξοδο γεγονότων που ανήκει σε άλλο εσωτερικό FB,βασικό η σύνθετο που περιέχεται στο αρχικό σύνθετο. Αντίστοιχα κάθε έξοδος γεγονότων ενός εσωτερικού βασικού ή σύνθετου FB, μπορεί να συνδέεται μόνο σε μια είσοδο γεγονότων άλλου εσωτερικού βασικού ή σύνθετου FB, που περιέχεται στο σύνθετο αρχικό. Τέλος κάθε έξοδος γεγονότων του σύνθετου FB πρέπει να συνδέεται μόνο με μία έξοδο γεγονότων ενός εσωτερικού βασικού ή σύνθετου FB ή να προέρχεται κατευθείαν από είσοδο γεγονότων του σύνθετου FB. Είναι πιθανό είσοδοι και έξοδοι κάποιων από τα εσωτερικά FB να μένουν ασύνδετες. Σε αυτή την περίπτωση οι αλγόριθμοι που αντιστοιχούν σε αυτές δεν εκτελούνται όπως είναι αναμενόμενο. Σε γενικές γραμμές όλες οι ιδιότητες και τρόποι λειτουργίας, καθώς και ο τρόπος διασύνδεσης των εισόδων και εξόδων που περιγράφηκαν σχετικά με τα βασικά FB περιγράφουν με πανομοιότυπο τρόπο και την λειτουργία των σύνθετων FB Υπηρεσιών Διασύνδεσης (Communication Service Interface FB) Κάθε εφαρμογή χαρακτηρίζεται από την ανάγκη ανταλλαγής δεδομένων μεταξύ των βασικών FB που την απαρτίζουν, των πόρων της συσκευής που τα φιλοξενεί, και των αισθητήρια και ενεργοποιητών που χαρακτηρίζουν φυσικές διατάξεις όπως οι βαλβίδες, θερμαντήρες, αντλίες, κινητήρες και σταθμούς εποπτείας και χειρισμών. Αυτή η ανταλλαγή δεδομένων μπορεί να γίνει με μια ειδική κατηγορία FB τα Communication Service Function Blocks(CSIFB). Σε αντίθεση με ότι έχουμε αναφέρει ως τώρα, η λειτουργικότητα των CSIFB δεν καθορίζεται από το πρότυπο αλλά είναι στην ευχέρεια του χρήστη να τη διαμορφώσει όπως επιθυμεί. 26

27 Τυποποιημένες είσοδοι και έξοδοι των CSIFB Είσοδοι γεγονότων: INIT Χρησιμοποιείται για να αρχικοποιήσει την υπηρεσία που προσφέρει το FB. Π.χ. η έναρξη της υπηρεσίας αποστολής δεδομένων μέσω μιας σειριακής σύνδεσης. REQ Ισοδυναμεί με την αίτηση λήψης δεδομένων από μία άλλη συσκευή όπως για παράδειγμα η λήψη δεδομένων από ένα αισθητήριο RSP Αντιστοιχεί σε αίτηση αποστολής δεδομένων σε μια άλλη συσκευή. Για παράδειγμα η αποστολή δεδομένων σε μια συσκευή επικοινωνίας ανθρώπουμηχανής. Έξοδοι γεγονότων: INITO Ισοδυναμεί με την ολοκλήρωση της αρχικοποίησης ενός FB, ως αποτέλεσμα επιτυχούς λήψης γεγονότος στην είσοδο INIT, χωρίς αυτό να σημαίνει ότι η υπηρεσία έχει αρχικοποιηθεί επιτυχώς. Γι αυτό και υπάρχει και μια άλλη έξοδος, η STATUS για το σκοπό αυτό. CNF Αποτελεί το γεγονός της επιβεβαίωσης όταν το FB έχει πραγματοποιήσει την αποστολή της αίτησης σε μια εξωτερική συσκευή. Για παράδειγμα θα μπορούσε να χρησιμοποιηθεί για να υποδείξει ότι η αίτηση για ανάγνωση μιας φυσικής πύλης εισόδου/εξόδου έχει γίνει δεκτή από το σύστημα εισόδου/εξόδου του ελεγκτή. IND Αποτελεί την ένδειξη ότι το CSIFB έχει λάβει απάντηση από μια άλλη διαφορετική εξωτερική συσκευή. Η εμφάνιση γεγονότος σε αυτή την έξοδο, μπορεί για παράδειγμα να προκληθεί όταν έχει ληφθεί η τιμή ενός επιλεγέντος αισθητηρίου. 27

28 Είσοδοι δεδομένων: QI : BOOL Η είσοδος αυτή λειτουργεί ως ένας απλός προσδιοριστής εισόδου σε συνδυασμό με τα εισερχόμενα γεγονότα. Μια τιμή TRUE σε συνεργασία με ένα γεγονός στην είσοδο INPUT, ισοδυναμεί με έναρξη της προβλεπόμενης λειτουργίας του FB ενώ μια τιμή FALSE ισοδυναμεί με τερματισμό της υπηρεσίας. PARΑMS : ANY Αναφέρεται σε δομή δεδομένων με τιμές σχετικές με την υπηρεσία του CSIFB και τα χαρακτηριστικά της. Αυτή η είσοδος είναι αυστηρά σε συνεργασία μόνο με την είσοδο ΙΝΙΤ και χρησιμοποιείται για την αρχικοποίηση της υπηρεσίας. Κάθε CSIFB θα ορίσει τη δομή της εισόδου PARAMS και τις αρχικές τιμές των παραμέτρων στο εσωτερικό της. SD_1,, SD_m : ANY Χρησιμοποιούνται για την αποστολή δεδομένων μέσω αιτήσεων και αποκρίσεων και ο ακριβής αριθμός των εισόδων εξαρτάται από τον τύπο της υπηρεσίας του CSIFB. Έξοδοι δεδομένων: QO : BOOL Προσδιορίζει αν η υπηρεσία έχει ολοκληρωθεί επιτυχώς μετά την ενεργοποίησης της από ένα γεγονός. Η τιμή TRUE θα ισοδυναμούσε με μια επιτυχή έναρξη μιας υπηρεσίας που φτάνει στην είσοδο INIT ενώ μια τιμή FALSE θα σήμαινε ότι η υπηρεσία απέτυχε να ξεκινήσει. STATUS : ANY Μπορεί να συνδυαστεί με οποιοδήποτε από τα γεγονότα εισόδου και χρησιμοποιείται για να παρέχει την κατάσταση της προσπέλασης του τελευταίου γεγονότος εισόδου. Για παράδειγμα, η κατάσταση θα ορίζεται όταν τίθεται μια τιμή κατά την εκκίνηση μιας υπηρεσίας από την είσοδο ΙΝΙΤ που ήταν ανεπιτυχής. Αντίστοιχα, όταν ένα γεγονός στην είσοδο REQ αποτύχει η διεκπεραιωθεί, η έξοδος Status παρέχει πληροφορία σχετική με την αιτία της αποτυχίας αυτής. RD_1,, RD_n : ANY Αυτές οι έξοδοι χρησιμοποιούνται για να εκφράσουν δεδομένα που λήφθηκαν από διαβεβαιώσεις και ενδείξεις. Σε αντιστοίχιση με τις εισόδους SD_1,, SD_m, ο αριθμός των εξόδων και ο τύπος δεδομένων τους θα εξαρτάται από την ειδική υπηρεσία που εξυπηρετούν. Για παράδειγμα όταν μια αίτηση πρόκειται να διαβάσει τις τιμές δέκα εισόδων, ένα γεγονός CNF θα πραγματοποιηθεί όταν γίνει η λήψη αυτών των τιμών και καθίστανται διαθέσιμες στις εξόδους RD_1,, RD_10. 28

29 H γενική μορφή των CSIFB, όπως αυτή ορίζεται από το πρότυπο IEC περιγράφεται από δύο γενικά templates, REQUESTER και RESPONDER: Εικόνα 2.7 Γενική μορφή των FB Requester και Respoder Ο REQUESTER παρέχει «αλληλεπίδραση προκαλούμενη από την εφαρμογή» που ισοδυναμεί με το αίτημα για εξωτερικά δεδομένα που προκαλείται από γεγονός παραγόμενο μέσα στην εφαρμογή. Αντίστοιχα ο RESPONDER παρέχει «αλληλεπίδραση προκαλούμενη από πόρο». Το αίτημα δεδομένων δηλαδή που φτάνει στο FB από έναν εξωτερικό πόρο ισοδυναμεί με τη δημιουργία ενός γεγονότος στην είσοδο IND. 29

30 3. Κατασκευή ισοδύναμου Χρονικού Αυτομάτου μιας Συναρτησιακής Οντότητας. 3.1 Εισαγωγή Στη θεωρία των αυτομάτων, ένα χρονικό αυτόματο (ΤΑ) είναι ένα πεπερασμένο αυτόματο, το οποίο επίσης περιέχει ένα πεπερασμένο σύνολο ρολογιών πραγματικού χρόνου. Κατά την εκτέλεση ενός ΤΑ, οι τιμές των ρολογιών αυξάνονται όλες με την ίδια ταχύτητα. Κατά μήκος των μεταβάσεων του αυτομάτου, οι τιμές των ρολογιών μπορούν να συγκριθούν με ακεραίους και οι συγκρίσεις αυτές μπορούν με τη βοήθεια φρουρών να ενεργοποιήσουν ή να απενεργοποιήσουν μεταβάσεις που καθορίζουν την συμπεριφορά του αυτομάτου. Τα χρονικά αυτόματα μπορούν να χρησιμοποιηθούν για την ανάλυση και μοντελοποίηση της χρονικής συμπεριφοράς υπολογιστικών συστημάτων, όπως συστήματα και δίκτυα πραγματικού χρόνου. Ο γενικός ορισμός ενός ΤΑ είναι ένα σύνολο Α = (Q, Σ, C, E, q0) που περιγράφεται ως εξής: 1. Q είναι ένα πεπερασμένο σύνολο. Τα στοιχεία του συνόλου Q αποτελούν τις τοποθεσίες του Α. 2. Σ είναι ένα πεπερασμένο σύνολο που καλείται το «αλφάβητο» η «δράση» του Α. 3. C αποτελεί ένα πεπερασμένο σύνολο των ρολογιών του A. 4. E Q Σ B(C) P(C) Q είναι ένα σύνολο ακμών που καλούνται μεταβάσεις του Α, όπου: Β(C) είναι το σύνολο των περιορισμών δυαδικών ρολογιών που περιέχει ρολόγια του C. P(C) είναι το υπερσύνολο του C. 5. q0 είναι ένα στοιχείο του Q που αποτελεί την αρχική τοποθεσία. Για παράδειγμα, μια ακμή (q, a, g, r, q ) του Ε είναι μία μετάβαση από την κατάσταση q στην q με δράση a, φρουρό g και επαναφορά ρολογιού r. 30

31 3.2 Χρήση χρονικών αυτομάτων για επαλήθευση εφαρμογών του προτύπου IEC61499[2] Μια εφαρμογή βασισμένη στο πρότυπο IEC λειτουργεί σε δύο ξεχωριστά βήματα. Αρχικά περιγράφεται κάθε ξεχωριστό FB που χρησιμοποιείται και μετά κατασκευάζεται η γενική εφαρμογή, συναρμολογώντας κατάλληλα τις συνδέσεις μεταξύ των FB που πρόκειται να χρησιμοποιηθούν. Όπως έχει αναφερθεί προηγουμένως ένα FB προσδιορίζεται από τη μία από το τμήμα αλγορίθμων του και από την άλλη από το τμήμα ελέγχου του που καθορίζει πώς και πότε αυτοί οι αλγόριθμοι εκτελούνται με βάση τα γεγονότα ελέγχου εισόδου και λειτουργεί με βάση το διάγραμμα ελέγχου εκτέλεσης (ECC). Στο άρθρο των Stanica, M. & Guegen, H.[2] προτείνεται ένα τρόπος κατασκευής του ισοδύναμου δικτύου αυτομάτων που αντιστοιχεί σε κάποιο FB. Συγκεκριμένα κάθε FB χαρακτηρίζεται από πλήθος αυτομάτων. Το πρώτο αυτόματο που χρησιμοποιείται είναι αυτό που προσομοιώνει τα γεγονότα εισόδου. Διαβάζει και εισάγει τις αρχικές τιμές και είναι υπεύθυνο για την περαιτέρω προσπέλαση του FB. Καλεί ένα ενδιάμεσο αυτομάτου που εκτελεί χρέη συγχρονισμού και διαβάζει την αίτηση για εκτέλεση του ECC. Το αυτόματο του ECC στη συνέχεια αποτελεί το μεγαλύτερο και κυριότερο αυτόματο κάθε συναρτησιακής οντότητας. Εκεί ουσιαστικά εισάγονται τα χαρακτηριστικά και ο τρόπος λειτουργίας της. Καλούνται οι αλγόριθμοι εκτέλεσης συγχρονίζοντας το με το αυτόματο εκτέλεσης αλγορίθμων και εισάγονται ρολόγια σύμφωνα με τα οποία εκτελούνται οι αλγόριθμοι αυτοί. Με την κατάλληλη εισαγωγή κανόνων, που αφορούν κυρίως συγχρονισμούς στις μεταβάσεις των αυτομάτων επιτυγχάνεται η σωστή επικοινωνία μεταξύ των τεσσάρων αυτομάτων του κάθε FB και των νέων αυτομάτων για κάθε νέα εισαγωγή ενός FB στο δίκτυο που κατασκευάζεται. 31

32 Συγκεκριμένα δηλαδή έχουμε τα παρακάτω αυτόματα, που συνδυαστικά όλα μαζί ισοδυναμούν με μία συναρτησιακή οντότητα(σημειώνεται ότι όλα τα παρακάτω αυτόματα σχεδιάστηκαν στο πρόγραμμα Uppal οι δυνατότητες του οποίου περιγράφονται στο επόμενο κεφάλαιο): Γεγονότα εισόδου: Όταν μία είσοδος ενεργοποιείται, γίνεται αίτηση χρήσης του ECC το οποίο όμως εκείνη τη στιγμή μπορεί να είναι απασχολημένο και αναγκαστικά η αίτηση πρέπει να αποθηκευτεί στη μνήμη και να εκτελεστεί αργότερα. Το γενικό μοντέλο του αυτομάτου που περιγράφει ένα γεγονός εισόδου, σύμφωνα με το [2], φαίνεται στην Εικόνα 3.1 Εικόνα 3.1 Γενική μορφή Αυτομάτου Γεγονότος Εισόδου Το κανάλι ExtEvent χρησιμοποιείται για να συγχρονιστεί με το εξωτερικό του FB όταν συμβεί ένα γεγονός ενώ το IntEvent χρησιμοποιείται για το συγχρονισμό της αντίδρασης του ECC όταν είναι η σειρά του γεγονότος να εκτελεστεί. Η τοποθεσία callecc είναι στη συνέχεια δεσμευμένη (περιγράφεται στο παρακάτω κεφάλαιο, 32

33 στον τρόπο λειτουργίας του Uppaal και ισοδυναμεί με μια τοποθεσία που δεν μπορεί να παραμείνει ενεργή με το πέρασμα του χρόνου). Χρησιμοποιείται για την επίτευξη συγχρονισμού μεταξύ του ExtEvent και του ECCReq. Το κανάλι noevent περιγράφει μια κατάσταση στην οποία δεν έχει ενεργοποιηθεί κάποιο γεγονός ενώ το clear, ισοδυναμεί με ένα reset των γεγονότων. Πρακτικά τα δύο αυτά κανάλια ισοδυναμούν με τη δυνατότητα μετάβασης στην τοποθεσία callecc και στην συνέχεια στην αίτηση λειτουργίας του ECC μέσω του καναλιού συγχρονισμού ECCReq. Το αυτόματο παραμένει στη συνέχεια στην τοποθεσία action μέχρις ότου το γεγονός ολοκληρωθεί ή γίνει επαναφορά του, και το αυτόματο μπορεί να επιστρέψει στην αρχική του κατάσταση. Αυτόματο κλήσης του ECC: Εισάγεται για κάθε FB με σκοπό να αποθηκεύσει αιτήσεις χρήσης του ECC και στη συνέχεια να καλέσει το ECC όταν αυτό είναι έτοιμο. Όταν στο αυτόματο εισόδου γίνει η μετάβαση από την τοποθεσία callecc προς την action καλείται το παρακάτω αυτόματο το οποίο ενεργοποιεί τη χρήση του ECC που εξηγείται αμέσως μετά. Εικόνα 3.2 Γενική μορφή Αυτομάτου κλήσης του ECC 33

34 Διάγραμμα Ελέγχου Εκτέλεσης (ECC): Το αυτόματο που περιγράφει το ECC αποτελεί τον πυρήνα της μοντελοποίησης και οφείλει να συγχρονίζεται με τα υπόλοιπα. Το ECC που προκύπτει σύμφωνα με το γενικό FB της εικόνας 3.3 έχει την μορφή της εικόνας 3.4 Εικόνα 3.3 Γενική μορφή ενός FB Εικόνα 3.4 Γενική μορφή Αυτομάτου για το ECC 34

35 Με το συγχρονισμό των καναλιών callecc της Εικόνας 3.4 το ECC προχωράει στην επόμενη τοποθεσία (Decide1) στην οποία περιμένει την ενεργοποίηση ενός η κανενός εκ των δύο γεγονότων του FB της Εικόνας 3.3. Σε κάθε περίπτωση η επόμενη τοποθεσία είναι δεσμευμένη καθώς περιμένει το συγχρονισμό του γεγονότος και γίνεται καθαρισμός των αιτήσεων γεγονότων καθώς κινούμαστε είτε προς την τοποθεσία Await1 είτε προς την Await2. Σε αυτό το σημείο γίνεται αίτηση συγχρονισμού με το αυτόματο που περιγράφει την λειτουργία του εσωτερικού αλγορίθμου του Uppaal ενώ ταυτόχρονα εισάγεται γίνεται μηδενισμός ενός ρολογιού (clock). Kαι στις δύο περιπτώσεις γεγονότος, η επόμενη τοποθεσία αποτελεί το σημείο κλήσης του αντίστοιχου αλγορίθμου. Για την δεξιά πλευρά η χρήση του χρονικού φρουρού (έννοια που εξηγείται στην ενότητα του Uppaal) οδηγεί πίσω στην αρχική κατάσταση. Αντίθετα στην αριστερή πλευρά οδηγούμαστε σε μια επείγουσα κατάσταση και η μετάβαση πίσω στην αρχή του ECC συνοδεύεται με την ενεργοποίηση της εξόδου του γεγονότος. Από αυτό το σημείο και μετά το ECC είναι ξανά διαθέσιμο για καινούριο γεγονός. Σημειώνεται ότι σε FB με ένα γεγονός εισόδου, πχ μόνο το EventC, η αριστερή πλευρά της Εικόνας 3.3 μπορεί να παραληφθεί εντελώς και ο συγχρονισμός του καναλιού callecc μπορεί να οδηγήσει κατευθείαν στην επόμενη τοποθεσία χωρίς την αναμονή για κάποια απόφαση. 35

36 Αυτόματο προσομοίωσης εκτέλεσης αλγορίθμου: Ισοδυναμεί με την κλήση και εκτέλεση του αντίστοιχου αλγορίθμου του γεγονότος και η εκτέλεση του βασίζεται στους χρονικούς περιορισμούς και φρουρούς που εισάχθηκαν στο αυτόματου του ECC. Συγχρονίζεται με τα αντίστοιχα κανάλια του ECC αυτομάτου και η ολοκλήρωση του ισοδυναμεί με την ενεργοποίηση του αντίστοιχου γεγονότος εξόδου. Εικόνα 3.5 Αυτόματο προσομοίωσης Εκτέλεσης Αλγορίθμου. FB υπηρεσιών διασύνδεσης: Η μορφή του είναι ιδιαίτερα απλή και περιέχει συγχρονισμούς των καναλιών REQ και IND. Ένα ρολόι clock αρχικά μηδενίζεται, στη συνέχεια στην τοποθεσία send υπάρχει ο χρονικός περιορισμός ότι το αυτόματο δε μπορεί να καθυστερήσει παραπάνω από μία χρονική τιμή ενώ η τελευταία μετάβαση γίνεται αφού περάσει ένας ελάχιστος απαιτούμενος χρόνος. Στα πλαίσια αυτής της εργασίας ωστόσο δε θα συναντηθεί κάπου το αυτόματο αυτό. Εικόνα 3.6 Αυτόματο ενός FB υπηρεσιών διασύνδεσης. Το σύνολο των αυτομάτων που περιγράφηκαν παραπάνω εξυπηρετούν τη σχεδίαση ενός μόνο FB. Για την κατασκευή μιας εφαρμογής που αποτελείται από δίκτυα FB πρέπει όλα αυτά τα αυτόματα να συνδεθούν με τα κατάλληλα κανάλια συγχρονισμού. Παρόλα αυτά για λόγους που καθιστούν τη χρήση και ανάγνωση των αυτομάτων στο Uppaal ευκολότερη, τα παραπάνω αυτόματα μπορούν να απλοποιηθούν και να τροποποιηθούν σύμφωνα με τις προτιμήσεις του χρήστη. 36

37 4. UPPAAL 4.1 Εισαγωγή Το Uppaal είναι ένα εργαλείο επαλήθευσης συστημάτων πραγματικού χρόνου που μοντελοποιούνται ως δίκτυα ΤΑ. Αναπτύχθηκε από τα πανεπιστήμια της Uppsala και Aalborg και έχει χρησιμοποιηθεί επιτυχώς σε διάφορες μελέτες που ποικίλουν από πρωτόκολλα επικοινωνίας ως και εφαρμογές πολυμέσων. Βασικός του σκοπός είναι η επαλήθευση συστημάτων μοντελοποιημένων με δίκτυα ΤΑ που επεκτείνονται με μεταβλητές ακεραίων, δομές δεδομένων, συναρτήσεις ορισμένες από το χρήστη και συγχρονισμό καναλιών. Η πρώτη έκδοση του Uppaal εμφανίστηκε το 1995 και από τότε είναι σε συνεχή βελτίωση. 4.2 Χρονικά Αυτόματα στο Uppaal O ελεγκτής μοντέλων του Uppaal βασίζεται στη θεωρία των ΤΑ και η γλώσσα μοντελοποίησης του προσφέρει επιπλέον λειτουργίες όπως μεταβλητές ακεραίων με όρια και ορισμό σημείων ως επείγοντα (urgent). Η γλώσσα ερωτημάτων του Uppaal είναι ένα υποσύνολο της TCTL (Timed Computation Tree Llogic) που χρησιμοποιείται για το ορισμό των ιδιοτήτων που πρόκειται να ελεγχθούν και προσδίδει στην θεωρία των ΤΑ τα ακόλουθα επιπλέον χαρακτηριστικά: Πρότυπα (Templates): Τα πρότυπα ορίζονται από ένα σύνολο παραμέτρων διάφορων τύπων (int, chan ) που τους δίνονται στοιχεία και τιμές στη διαδικασία δήλωσης μεταβλητών. Το κάθε πρότυπο ουσιαστικά αφορά ένα αυτόματο που πρόκειται να περιγραφεί. Μεταβλητές (Constants): Ορίζονται ως const name value και πρέπει εξ ορισμού να έχουν ακέραιη τιμή. Ακέραιες μεταβλητές με Όριο (Bounded integer variables): Ορίζονται στη μορφή int[min, max]. Οι «φρουροί»(guards), οι αμετάβλητες (invariants) και οι αναθέσεις μπορούν να χρησιμοποιήσουν εκφράσεις ακέραιων μεταβλητών με όριο, με έλεγχο των ορίων στη διαδικασία της επαλήθευσης και σε περίπτωση παραβίασης τους το σύστημα οδηγείται σε άκυρη κατάσταση που απορρίπτεται. 37

38 Κανάλια Δυαδικού Συγχρονισμού (Binary Synchronization Channels): τα κανάλια ορίζονται στη μορφή chan c. Μια ακμή c! συγχρονίζεται με την c? και οι μεταβάσεις εκτελούνται ταυτόχρονα. Σε περίπτωση πολλών συνδυασμών ακμών συγχρονισμού το ζευγάρι επιλέγεται μη ντετερμινιστικά. Κανάλια μετάδοσης (Broadcast Channels): Δηλώνονται ως broadcast chan c και κάθε αποστολέας c! μπορεί να συγχρονιστεί με αυθαίρετο αριθμό παραληπτών c?. Σε περίπτωση που δεν υπάρχουν παραλήπτες, ο αποστολές μπορεί ακόμα να εκτελέσει την πράξη c!, δηλαδή η μετάδοση αποστολής δεν εμποδίζεται. Κανάλια επείγοντος συγχρονισμού (Urgent Synchronization Channels): Ορίζονται βάζοντας πριν τον ορισμό του καναλιού την λέξη κλειδί urgent και δεν επιτρέπονται καθυστερήσεις. Γι αυτό το λόγο αυτά τα κανάλια δεν πρέπει να έχουν χρονικούς περιορισμούς, δηλαδή guards ρολογιών. Επείγουσες τοποθεσίες (Urgent Locations): Είναι σημασιολογικά ισοδύναμες με ένα επιπλέον ρολόι clock x, το οποίο μηδενίζεται σε όλες τις εισερχόμενες ακμές, και με μια αμετάβλητη x<=0 στην τοποθεσία. Δεν επιτρέπεται δηλαδή να περάσει χρόνος όταν το σύστημα βρίσκεται σε μια τέτοια τοποθεσία. Δεσμευμένες Τοποθεσίες (Committed Locations): Είναι ακόμα πιο περιοριστικές στην εκτέλεση σε σχέση με τις επείγουσες. Μια δεσμευμένη κατάσταση δεν μπορεί να καθυστερήσει και η επόμενη της μετάβαση πρέπει να περιλαμβάνει μια εξερχόμενη ακμή από τουλάχιστον μια δεσμευμένη τοποθεσία. Πίνακες (Arrays): Επιτρέπονται για ρολόγια, ακεραίες μεταβλητές, σταθερές και κανάλια. Ορίζονται δίνοντας ένα μέγεθος δίπλα στο όνομα της μεταβλητής όπως chan[4]; clock a[2]; Int[3,5]. Αρχικοποιήσεις (Initializers): Χρησιμοποιούνται για την αρχικοποίηση τιμών ακεραίων ή πινάκων ακεραίων μεταβλητών π.χ. int = 2; int i[3]={1,2,3} Τύπους Αρχείων (Record Types): Ορίζονται με τη δομή struct όπως περίπου και στη γλώσσα C. Ειδικούς τύπους (Custom Types): Ξανά, όπως περίπου και στη C ορίζονται με τη δομή typedef. Μπορεί να οριστεί οποιοσδήποτε ειδικός τύπος με χρήση οποιονδήποτε από τους βασικούς τύπους θεωρείται απαραίτητο. 38

39 Συναρτήσεις ορισμένες από τον Χρήστη (User Functions): Ορίζονται είτε συνολικά (globally) είτε τοπικά στο πρότυπο. Οι παράμετροι των προτύπων μπορούν να προσπελαστούν από τις τοπικές μεταβλητές. 4.3 Εκφράσεις στο Uppaal Στο Uppaal χρησιμοποιούνται οι ακόλουθες εκφράσεις κατά τη μετάβαση μέσω μιας ακμής από τη μια τοποθεσία στην άλλη: Επιλογή (Select): Η ετικέτα επιλογής περιέχει μια λίστα εκφράσεων της μορφής name: type, όπου name το όνομα της μεταβλητής και type ένας καθορισμένος τύπος (βασικός η ειδικός). Οι μεταβλητές αυτές είναι προσβάσιμες μόνο από τη συνδεόμενη ακμή και επιλέγουν μη ντετερμινιστικά μια τιμή από το εύρος τιμών του τύπου τους με τη μορφή: i: int [0,3] που επιλέγει τυχαία μια ακέραια τιμή από το 0 ως το 3. Φρουρός (Guard): Ο «φρουρός» είναι μια συγκεκριμένη έκφραση διατυπώνει τις συνθήκες κάτω από τις οποίες η μετάβαση είναι εκτελέσιμη. Αποτελούν συζεύξεις απλών συνθηκών σε ρολόγια η διαφορά τιμής δύο ρολογιών, λογικές εκφράσεις χωρίς ρολόγια και τα όρια στις συνθήκες πρέπει να είναι εκφράσεις πάνω σε ακέραιες τιμές π.χ. x>=1 && x<=2, (i[0]+1)!=(i[1]*10). Συγχρονισμός (Synchronization): Όπως περιγράφηκε και παραπάνω ο συγχρονισμός περιέχει το όνομα μιας ενέργειας της οποίας η μετάβαση θα πρέπει να συγχρονιστεί με κάποια άλλο αυτόματο. Ο συγχρονισμός δηλώνεται με τη μορφή c? και c! και οι μεταβάσεις του εκτελούνται ταυτόχρονα. Ενημέρωση (Update): Αποτελούν τις εκφράσεις που εκτελούνται κατά την εκτέλεση μιας μετάβασης. Οι εκφράσεις πρέπει να αναφέρονται μόνο σε ρολόγια, μεταβλητές ακεραίων και σταθερές και πρέπει μόνο να δίνουν ακέραιες τιμές στα ρολόγια. Παράδειγμα: x=0 x=1, y=2*x Μπορούν επίσης να καλέσουν συναρτήσεις και οι εκφράσεις εκτελούνται σειριακά π.χ. στην ενημέρωση x=1, y=2*x θα εκτελεστεί πρώτα το x=1 και μετά το y=2*x. 39

40 Αμετάβλητη (Invariant): Η αμετάβλητη (ιδιότητα κατάστασης) είναι μια έκφραση που πληροί τις ακόλουθες συνθήκες: Μη αιτιοκρατική Μόνο ρολόγια, ακέραιοι και σταθερές Είναι μια ένωση συνθηκών της μορφής x<e η <=e όπου x είναι αναφορά σε ρολόι και e ακέραιος. Μπορεί να καλέσεις μια μη αιτιοκρατική συνάρτηση δυαδικού αριθμού αλλά οι περιορισμοί ρολογιών δεν υποστηρίζονται σε αυτή την περίπτωση. Όλες οι παραπάνω εκφράσεις μετάβασης μέσω μιας ακμής μπορούν να οριστούν με το παρακάτω παράθυρο: Εικόνα 4.1 Παράθυρο ρύθμισης μεταβάσεων στο Uppaal. 40

41 Αντίστοιχα το παράθυρο επεξεργασίας μιας τοποθεσίας έχει την μορφή της εικόνας 4.2 Παρατηρούμε ότι μπορούμε να δηλώσουμε το είδος της κάθε τοποθεσίας (αρχική, επείγουσα, κρίσιμη) και να ορίσουμε πιθανή αμετάβλητη της ιδιότητα. Εικόνα 4.2 Παράθυρο επεξεργασίας τοποθεσιών στο Uppaal. 41

42 4.4 Γλώσσα Ερωτημάτων Ο κύριο σκοπός του ελεγκτή μοντέλων είναι η επαλήθευση της λειτουργικότητας του μοντέλου με βάση μια απαίτηση μας. Αυτή η απαίτηση προδιαγραφής πρέπει να εκφραστεί επίσημα και καλά ορισμένα σε μια γλώσσα που διαβάζει η μηχανή. Το Uppaal χρησιμοποιεί μια απλοποιημένη έκδοση της γλώσσας TCTL (Timed Computation Tree Logic) που βασίζεται σε τύπους καταστάσεων και τύπου μονοπατιών. Τύποι κατάστασης (State Formulae): Αποτελεί μια έκφραση που μπορεί να ελεγχθεί χωρίς να γίνει ανάγνωση ολόκληρου του μοντέλου και αποτελούν μεμονωμένες καταστάσεις. Είναι δυνατό να ελεγχθεί αν μια συγκεκριμένη διεργασία βρίσκεται στην ζητούμενη τοποθεσία χρησιμοποιώντας την έκφραση P.I όπου P η διεργασία και I η τοποθεσία. Τύποι μονοπατιών (Path Formulae): Οι τύποι μονοπατιών μπορούν να χωριστούν σε τρεις καταστάσεις : i. Ιδιότητες προσβασιμότητας: Αποτελούν την απλούστερη μορφή ιδιοτήτων. Ρωτούν αν ένα δοσμένος τύπος κατάστασης φ μπορεί να πραγματοποιηθεί από οποιαδήποτε προσβάσιμη κατάσταση. Στο Uppaal αυτή η ερώτηση έχει σύνταξη της μορφής : Ε<>φ. ii. Ιδιότητες Ασφάλειας: Είναι της μορφής «κάτι κακό δεν πρόκειται ποτέ να συμβεί». Για παράδειγμα σε ένα πυρηνικό εργοστάσιο μια ιδιότητα ασφαλείας μπορεί να είναι ότι η θερμοκρασία λειτουργίας είναι πάντοτε κάτω από ένα ορισμένο όριο. Μια μικρή παραλλαγή της ιδιότητας αυτής είναι το «κάτι πιθανότατα να μην συμβεί ποτέ». Για παράδειγμα σε ένα παιχνίδι μια ασφαλής κατάσταση είναι να κερδίσει κάποιος το παιχνίδι, συνεπώς δηλαδή δεν θα χάσει. Στο Uppaal αυτές οι ιδιότητες γράφονται με τη μορφή Α[]φ και Ε[φ], που ισοδυναμούν με «η φ είναι αληθής για όλες τις προσβάσιμες καταστάσεις» και «υπάρχει ένα τουλάχιστον μονοπάτι κατά το οποίο η φ είναι αληθής» αντίστοιχα. iii. Ιδιότητες ζωντάνιας: Είναι της μορφής «κάτι τελικά θα συμβεί», όπως το πάτημα του on στο χειριστήριο της τηλεόρασης και κατά συνέπεια το άνοιγμα της τηλεόρασης. Στο Uppaal αυτό το ερώτημα έχει τη μορφή A<>φ και φ --> ψ, που ισοδυναμεί με «κάθε φορά που το φ ικανοποιείται πρέπει να ικανοποιείται και το ψ». 42

43 Συνοπτικά έχουμε τον παρακάτω πίνακα: Α[]φ : Σε κάθε εκτέλεση και κάθε κατάσταση αυτής ισχύει το φ. Ε<>φ : Υπάρχει εκτέλεση όπου στο μέλλον φ. Ε[]φ: Υπάρχει εκτέλεση όπου σε κάθε κατάσταση αυτής ισχύει το φ. Α<>φ: Σε κάθε εκτέλεση στο μέλλον φ. φ ψ: Σε κάθε εκτέλεση και πάντοτε αν φ τότε σε κάθε εκτέλεση στο μέλλον ψ. 43

44 4.5 Επισκόπηση της Εργαλειοθήκης του UPPAAL To Uppaal χρησιμοποιεί μια αρχιτεκτονική χρήστη-διακομιστή, που χωρίζεται σε μια διεπαφή χρήστη και μια μηχανή ελέγχου μοντέλων. Η διεπαφή του χρήστη είναι εφαρμοσμένη σε Java και η μηχανή είναι διαθέσιμη σε διάφορες πλατφόρμες (Linux, Windows, Solaris). Η λογική του εργαλείου είναι η μοντελοποίηση ενός συστήματος με ΤΑ μέσω της χρήσης ενός editor γραφικών, που επικυρώνει και επαληθεύει ότι η προσομοίωση της λειτουργίας λειτουργεί όπως θέλουμε. Το γραφικό περιβάλλον λοιπόν παρουσιάζει αυτή την ιδέα σε τρία κομμάτια: 1. Editor 2. Simulator 3. Verifier Editor Tο σύστημα ορίζεται ως ένα δίκτυο από ΤΑ που τοποθετούνται παράλληλα και ονομάζονται διαδικασίες. Μια διαδικασία αρχικοποιείται σε ένα παραμετροποιημένο πρότυπο. Ο editor χωρίζεται σε δύο μέρη, ένα παράθυρο μορφής δέντρου που προσφέρει εύκολη πρόσβαση στο κάθε πρότυπο και τις δηλώσεις του και σε ένα παράθυρο σχεδίασης. Οι τοποθεσίες ορίζονται με ονόματα και ιδιότητες κατάστασης ενώ οι ακμές με καταστάσεις guard (πχ e==id), με συγχρονισμούς (πχ c?) και αναθέσεις (πχ x:=0). Το δέντρο στα αριστερά του εργαλείου δίνει πρόσβαση στα μέρη που περιγράφουν το σύστημα : Γενικές Δηλώσεις (Global Declarations): Περιέχουν γενικές μεταβλητές ακεραίων, ρολόγια, κανάλια συγχρονισμού και σταθερές. Πρότυπα (Templates): Το κάθε διαφορετικά παραμετροποιημένο ΤΑ, που μπορεί να περιέχει τις δικές του τοπικές μεταβλητές, ρολόγια και σταθερές. Αναθέσεις Διεργασιών (Process Assignments): Τα πρότυπα αρχικοποιούνται σε διεργασίες μέσω δηλώσεων για αυτά τα στιγμιότυπα. 44

45 Ορισμός Συστημάτων (System definition): Η λίστα με όλες τις διεργασίες του συστήματος. Η σειρά της δήλωσης τους ορίζει και τη σειρά με την οποία μετά αναμένεται να διαβαστούν στον simulator. Σημειώνεται ότι το Uppaal λειτουργεί ουσιαστικά με αρχεία σε γλώσσα XML. Η δουλεία του χρήστη αποθηκεύεται σε XML. Κυρίως όμως υπάρχει η δυνατότητα φόρτωσης κατάλληλα γραμμένων αρχείων XML που περιγράφουν δίκτυα ΤΑ πολλαπλών συστημάτων Προσομοιωτής (Simulator) Εκτελεί την προσομοίωση της λειτουργίας ενός μοντέλου. Στο πάνω δεξιά μέρος του, εμφανίζεται το συνολικό δίκτυο των ΤΑ που περιέχονται στο τρέχον μοντέλο. Αριστερά (εικόνα 4.3) βρίσκεται το τμήμα ελέγχου (control part) που επιτρέπει την παρακολούθηση συμπεριφορών, τη μετακίνηση μπρος και πίσω πάνω σε μια εκτέλεση. Στη μέση της οθόνης την φαίνονται οι τιμές των διάφορων μεταβλητών ενώ κάτω από το δίκτυο των ΤΑ γίνεται η παρακολούθηση της επικοινωνίας μεταξύ των διάφορων συνιστωσών μέσω ενός Message Sequence Chart. Σε περίπτωση σφαλμάτων στη σχεδίαση του δικτύου στον editor, ο προσομοιωτής δεν φορτώνει το σχεδιασμένο μοντέλο και εμφανίζει σχετικό μήνυμα σφάλματος Επαληθευτής (Verifier) Επιτρέπει τον έλεγχο ιδιοτήτων ασφαλείας και ζωτικότητας διατυπωμένων όπως αναφέρθηκε και προηγουμένως σε μορφή της γλώσσας TCTL(Time Computation). Τα ερωτήματα εισάγονται και τροποποιούνται από το κατάλογο Query (εικόνα 4.4) και επιλέγονται στον κατάλογο Overview. Ο πίνακας Status εμφανίζει το αποτέλεσμα της επικοινωνίας του ερωτήματος με το server και δείχνει αν το ερώτημα ικανοποιείται από το μοντέλο μας η όχι. 45

46 Εικόνα 4.3 Παράθυρο προσομοιωτή του Uppaal Εικόνα 4.4 Παράθυρο επαληθευτή του Uppaal 46

47 5. Κατασκευή των αρχείων XML των χρονικών αυτομάτων που αντιστοιχούν σε λογισμικό FB. Όπως έχουμε αναφέρει προηγουμένως, βασικός στόχος της διπλωματικής εργασίας, ήταν να προταθεί μια τεχνική μετατροπής ενός οποιοδήποτε δικτύου συναρτησιακών διαγραμμάτων-fb, που αποτελεί λογισμικό ελέγχου μιας βιομηχανικής διεργασίας στο ισοδύναμο δίκτυο χρονικών αυτομάτων με βάση τις προδιαγραφές του προτύπου IEC Στις προηγούμενες ενότητες περιεγράφηκαν κάποια θεωρητικά και μαθηματικά υπόβαθρα, απαραίτητα για την κατανόηση του τρόπου λειτουργίας του προτύπου και των FB καθώς και ο τρόπος λειτουργίας του ως εργαλείου Uppaal. Σε αυτή την ενότητα περιγράφονται οι ιδιομορφίες της γλώσσας XML για το Uppaal καθώς και οι κανόνες που πρέπει να ακολουθηθούν για συγγραφή των αρχείων. Στη συνέχεια παρουσιάζονται τα ερωτήματα που τέθηκαν στον επαληθευτή και τα αποτελέσματα τους. Τελικό ζητούμενο λοιπόν ήταν η κατασκευή των κατάλληλων αρχείων XML που μπορεί να διαβάσει το Uppaal. H XML είναι μια γλώσσα σήμανσης που περιέχει κανόνες για την ηλεκτρονική κωδικοποίηση κειμένων και χρησιμοποιείται κυρίως για την αναπαράσταση δομών δεδομένων. Υπάρχουν αρκετοί διαφορετικοί τρόποι εγγραφής κώδικα στη γλώσσα XML με βάση που επρόκειτο να χρησιμοποιηθούν. Το Uppaal λοιπόν απαιτεί ειδικά γραμμένα αρχεία XML ώστε να μπορεί να τα εκτελέσει. Σύμφωνα με την αναφορά[10 ]τα γενικά χαρακτηριστικά είναι τα εξής: Συντενταγμένες: Για όλα τα στοιχεία χρησιμοποιούνται συντεταγμένες y και x για το δύο-διαστάσεων γράφημα που εμφανίζεται στο Uppaal. <nta>,</nta>: Ορίζει την αρχή και το τέλος του κώδικα που γράφηκε. <label>: Χρησιμοποιήθηκε στις τοποθεσίες και τις μεταβάσεις για να οριστούν τα χαρακτηριστικά και οι διάφορες τιμές τους. Επίσης τους δίνεται ένας από τους τύπους κανόνων που ορίζει το Uppaal: <label y="110" x="200" kind="select">i: int [0,3]</label> <label y="120" x="200" kind="guard">a>=5</label> <label y="130" x="200" kind="synchronization">example?</label> <label y="140" x="200" kind="assignment"a=5></label> 47

48 και <label y="150" x="200" kind="invariant">6>=y</label> Όπου select ο κανόνας Επιλογής, guard ο κανόνας Φρουρού, Sychronisation. Στα πλαίσια της διπλωματικής για τον έλεγχο των μεταβάσεων που ορίσαμε χρησιμοποιήθηκαν παντού κανάλια συγχονισμού. Τα κανάλια αυτά περιγράφουν την επικοινωνία του κάθε αυτομάτου με το άλλο, και περιγράφεται στην 6 η ενότητα ο τρόπος που επιτυγχάνεται η μετάβαση από το ένα FB στο επόμενο. <declaration>: Δηλώνει τις μεταβλητές, ρολόγια και κανάλια που πρόκειται να χρησιμοποιηθούν. Χρησιμοποιείται αρχικά για τη δήλωση των γενικών μεταβλητών και εσωτερικά σε κάθε πρότυπο για τις τοπικές: <declaration> chan example, clock timer, int a;</declaration>. Με αυτή την εντολή δηλώνεται ένα κανάλι συγχρονισμού με όνομα example, ένα ρολόι με όνομα timer και μια ακέραια μεταβλητή a. <template>: Ορίζει το κάθε διαφορετικό αυτόματο που χρησιμοποιείται και περιγράφει τις τοποθεσίες και μεταβάσεις του καθενός. Για κάθε FB έχουμε πει ότι χρησιμοποιούνται τέσσερα αυτόματα συνεπώς απαιτούνται και τέσσερα templates που περιγράφουν με τη σειρά τα αυτόματα: εισόδου, κλήσης του ECC, εκτέλεσης του ECC και εκτέλεσης του αλγορίθμου, όπως περιγράφηκαν στην ενότητα 3. Μέσα στο κάθε template ορίζονται τα παρακάτω χαρακτηριστικά που περιγράφουν τη γραφική απεικόνιση του αυτομάτου στο Uppal: <name>: Θέτει το όνομα της κάθε τοποθεσίας. Πχ: <name y="150" x="250">test</name> <location>: Δέχεται πληροφορίες σχετικά με τη θέση της που θα εμφανιστεί η κάθε τοποθεσία στο Uppaal. Δέχεται έναν αριθμό id που χρησιμοποιείται για τις μεταβάσεις. Μια αρχική τοποθεσία δηλώνεται με τον κώδικα <init ref=id/>, ενώ μια δεσμευμένη και επείγουσα τοποθεσία ορίζεται ως <commited/> και <urgent/> αντίστοιχα, ακριβώς κάτω από το όνομα της.. Σημειώνουμε ότι μία τοποθεσία δεν μπορεί να είναι επείγουσα και δεσμευμένη ταυτόχρονα. 48

49 <location y="-192" x="-256" id="id2"> <name y="-222" x="-266">example</name> </location> <transition>: Ορίζει τη μετάβαση από μία τοποθεσία σε μία άλλη και τους κανόνες κάτω από τους οποίους θα εκτελεστεί η μετάβαση αυτή. Κάθε μετάβαση μπορεί να έχει τέσσερις πιθανές ετικέτες: select, guard, sychronization, Update με χρήση του κατάλληλου <label>. Για να οριστεί ποιες τοποθεσίες αφορά μια μετάβαση χρησιμοποιούνται οι αριθμοί id που δηλώθηκαν κατά τη δήλωση τους. Η επικοινωνία για παράδειγμα μιας τοποθεσίας με id0 και μιας με id1 γίνεται ως εξής: <source ref="id0"/> <target ref="id1"/> Σύμφωνα με τις δύο παραπάνω γραμμές ορίζεται μία μετάβαση από την τοποθεσία id0 προς την id1 και στην συνέχεια ορίζονται οι κανόνες μετάβασης με χρήση του αντίστοιχου <label>. <Nail>: Αποτελούν συντεταγμένες κορυφών στην απεικόνιση του Uppaal από τις οποίες περνάει μια μετάβαση και η σύνταξη τους είναι για παράδειγμα: <nail y="150" x="250"/>. Με αυτή την εντολή ορίζεται ότι η γραμμή μετάβασης θα περάσει από το σημείο (x,y)=)=(150,250) του δισδιάστατου γραφήματος στο Uppaal. Βοηθάει απλά στην καλύτερη εμφάνιση των ακμών. Μπορούν να μην χρησιμοποιηθούν καν αλλά μπορούν να χρησιμοποιηθούν και πολλαπλά ανάλογα με τη μορφή που θέλουμε να δώσουμε στην ακμή μετάβασης. <system>: Ορίζει τα αυτόματα που πρόκειται να φορτωθούν στον προσομοιωτή(simulator) του Uppal. Συγκεκριμένα στην καρτέλα αυτή αναφέρονται όλα τα αυτόματα που πρόκειται να συντελέσουν το δίκτυο. Ουσιαστικά δηλαδή στην καρτέλα <system> ορίζονται ξανά όλα τα διαφορετικά templates που περιέχονται στο XML αρχείο. Για αναπαράσταση ενός FB δηλαδή εισάγονται τα τέσσερα βασικά του και από κει και πέρα για κάθε FB που θέλουμε να προσθέσουμε στο δίκτυο που περιγράφεται από το XML προστίθενται άλλα τέσσερα κάθε φορά. Είναι προφανώς δυνατό να μην καταγραφεί σε αυτή την καρτέλα κάποιο template αλλά αυτό θα έχει ως αποτέλεσμα την μη φόρτωση του 49

50 στον προσομοιωτή γεγονός που με βάση την τεχνική που προτείνεται στη διπλωματική δεν θα έπρεπε να συμβεί ποτέ. <!--> </-->: Με αυτή τη εντολή μπορούν να εισαχθούν σχόλια (comments). Για κάθε λοιπόν αρχείο XML η σειρά εγγραφής των παραπάνω είναι συγκεκριμένη. Αρχικά ξεκινάμε όπως είπαμε με την ετικέτα <nta> και στη συνέχεια γράφονται οι γενικές δηλώσεις. Έπειτα για κάθε αυτόματο που περιέχεται στο συνολικό αρχείο, ορίζεται το πρότυπο (template), οι τοπικές δηλώσεις και όλες οι τοποθεσίες (επείγουσες, δεσμευμένες η όχι), μετά η αρχική τοποθεσία και τέλος οι μεταβάσεις με βάση τα αντίστοιχα label που χρειάζονται. Σημειώνεται ότι το label για ορισμό αμετάβλητης (Invartiant) γίνεται στη δήλωση των τοποθεσιών. Αφού τελειώσει η κωδικοποίηση ενός template, προχωρούμε στο επόμενο με τα ίδια βήματα. Τονίζεται ότι οι γενικές μεταβλητές είναι αναγνώσιμες και μπορεί να γίνει χρήση τους από κάθε template σε αντίθεση με τις τοπικές που αφορούν μόνο το template μέσα στο οποίο ορίζονται. Σύμφωνα με την τεχνική που ακολουθείτε ο αριθμός των templates πρέπει ουσιαστικά πάντα να είναι πολλαπλάσιος του τέσσερα αφού για κάθε νέο FB που πρόκειται να εισαχθεί απαιτείται ο συγκεκριμένος αριθμός αυτομάτων. Αφού περιγραφούν και κωδικοποιηθούν όλα τα templates ακολουθεί η γραμμή των συστημάτων <system> όπως αναφέρθηκε και τέλος ο κώδικας κλείνει με την εντολή </nta>. Ακολουθώντας τους παραπάνω κανόνες αρχικά κατασκευάστηκαν ξεχωριστά αρχεία XML για κάθε διαφορετικό FB που επρόκειτο να χρησιμοποιηθεί, για την εφαρμογή που κατασκευάστηκε όπως εξηγείται παρακάτω. Στη συνέχεια ενώθηκαν όλα μαζί σε ένα ενιαίο αρχείο που αποτέλεσε το τελικό αρχείο XML που εισάχθηκε στο Uppaal. Τα ονόματα, οι μεταβάσεις, τα ρολόγια και τα κανάλια είναι διαφορετικές για κάθε τύπο FB. Γενικά πάντως είναι δυνατό να κατασκευαστεί οποιασδήποτε μορφής FB απλά επιλέχθηκαν κάποια με βάση ένα δίκτυο που προσομοιώθηκε. Δημιουργήθηκε δηλαδή μια μορφή βιβλιοθήκης από διαφορετικά FB που χρησιμοποιούνται στην παρακάτω εφαρμογή. Για τη δημιουργία ενός άλλου δικτύου που περιέχει διαφορετικά FB θα πρέπει να ακολουθηθούν τα ίδια βήματα που κωδικοποιούν τα αυτόματα σε γλώσσα XML. 50

51 Παρατίθεται ένα παράδειγμα κώδικα XML που δείχνει τον ορισμό ενός template στη γενική του μορφή. Η μορφή αυτή εφαρμόζεται για την κατασκευή κάθε FB θέλουμε να εισαχθεί και να αναπαρασταθεί στο Uppaal: Οι παραπάνω γραμμές κώδικα αποτελούν το «καλούπι» με βάση το οποίο κατασκευάζονται τα χρονικά αυτόματα που περιγράφουν ένα FB. Στις παρενθέσεις με μαύρα γράμματα σημειώνεται ο τρόπος που πρέπει να συμπληρωθεί η αντίστοιχη θέση και στις κενές παρενθέσεις οι συντεταγμένες της συγκεκριμένης θέσης. Τονίζεται ότι κάθε Template ισοδυναμεί με ένα αυτόματο: <nta> <declaration>(οι γενικές μεταβλητές που χωρίζονται μεταξύ τους με ένα «,» Οι μεταβλητές που ορίζονται εδώ είναι αναγνώσιμες από όλα τα templates του συστήματος);</declaration> <template> (ορισμός του προτύπου που αφορά το αυτόματο) <name x="(άξονας x στο δισδιάστατο γράφημα)" y="(άξονας y)">(όνομα του προτύπου. Στην περίπτωση μας τα ονόματα για κάθε FB είναι τα τέσσερα αυτόματα INPUT, ECC_Invocation_Request_Automaton, Algorithm που έχουν περιγραφεί στην ενότητα 3. Κατασκευάζονται δηλαδή τέσσερα templates )</name> <declaration>(τοπικές μεταβλητές που χωρίζονται ξανά με «,»);</declaration> <location id= (ορίζεται ο αριθμός id της τοποθεσίας) x="()" y="()"> <name x="()" y="()">(όνομα τοποθεσίας) </name> (Στη συνέχεια ορίζεται αν η τοποθεσία θα είναι δεσμευμένη η επείγουσα αν χρειάζεται) <committed/> <urgent/> </location> <init ref="(id της αρχικής)" /> <transition> <source ref="(ορισμός του id της τοποθεσίας που ξεκινά η μετάβαση)" /> <target ref="(ορισμός του id της τοποθεσίας που καταλήγει η μετάβαση)" /> <label x="()" y="()" kind="select">(χρήση έκφρασης select του Uppaal)</label> <label x="()" y="() kind ="guard">(χρήση έκφρασης φρουρού)</label> <label x="()" y="()" kind="synchronisation">(χρήση έκφρασης συγχρονισμού.)</label> <label x="()" y="()" kind="assignment">(χρήση έκφρασης ενημέρωσης)</label> 51

52 <nail x="()" y="()"/> (Όπως αναφέρθηκε η χρήση τους είναι απλά «διακοσμητική» μπορούν να παραληφθούν η να χρησιμοποιηθούν πολλαπλά) </transition> </template>(εδώ τελειώνει η περιγραφή του συγκεκριμένου αυτομάτου. Για την εισαγωγή νέου χρησιμοποιείται πάλι η εντολή <template> στην επόμενη γραμμή και ακολουθούνται τα ίδια βήματα) <system>(δηλώνονται τα διαφορετικά αυτόματα που περιγράφουν το σύστημα και πρόκειται να φορτωθούν στον προσομοιωτή. Ορίζονται με τη μορφή: system Template1, Template2, Template3,Template4; (το «;» στο τέλος είναι σημαντικό)</system></nta> Με βάση τις παραπάνω γραμμές κώδικα, και δημιουργώντας τέσσερα διαφορετικά template που αφορούν τα αυτόματα που περιγράφηκαν στην ενότητα 3 μπορεί να κατασκευαστεί οποιαδήποτε μορφή FB του προτύπου IEC61499 σε ένα αρχείο XML. Στο τέλος στην καρτέλα system ορίζονται τα τέσσερα αυτόματα Εισόδου, Κλήσης ECC, εκτέλεσης ECC και Αλγορίθμου που αφορούν τα ορισμένα προηγουμένως template. Στην εισαγωγική ενότητα της εργασίας αναφέρθηκε ότι η δημιουργία όλων των FB που ορίζονται από το πρότυπο ξεπερνάει τα χρονικά όρια της διπλωματικής και συνεπώς στο επόμενο κεφάλαιο παρουσιάζεται ένα παράδειγμα που κάνει χρήση κάποιων συγκεκριμένων FB που απαρτίζουν ένα δίκτυο λογισμικού ελέγχου βιομηχανικής διαδικασίας. Στο επόμενο κεφάλαιο παρουσιάζεται ένα παράδειγμα δικτύου FB και το XML που το περιγράφει. 52

53 6. Παράδειγμα Σε αυτό το κεφάλαιο θα γίνει η περιγραφή ενός παραδείγματος δικτύου που σχεδιάστηκε και αφορά μια βιομηχανική εφαρμογή. Σύμφωνα με τους κανόνες που παρουσιάστηκαν στα προηγούμενα κεφάλαια και τα χαρακτηριστικά της κατάλληλης γλώσσας XML για το Uppaal, κατασκευάστηκε το τελικό αρχείο που περιγράφει το δίκτυο της εικόνας 6.1. Στη συνέχεια εισάχθηκαν τα κατάλληλα ερωτήματα για επαλήθευση ορθότητας της μεθόδου και παρουσιάζονται κάποια συμπεράσματα που προκύπτουν από τα αποτελέσματα αυτά. 6.1 Επαλήθευση της ορθής λειτουργίας του λογισμικού μιας απλής εφαρμογής ελέγχου διεργασίας. Κατασκευάσαμε λοιπόν, μια εφαρμογή βασισμένη στο πρότυπο αυτό, που αποτελεί ένα πρόγραμμα ελέγχου μιας βιομηχανικής διεργασίας γραμμένο στη γλώσσα FB. Σκοπός μας ήταν η επαλήθευση της λειτουργικότητας της εφαρμογής αυτής και η αντιστοίχιση του δικτύου FB με ένα αληθινό δίκτυο και ο παραλληλισμός των σφαλμάτων που προκύπταν με πιθανά πραγματικά σφάλματα και η επεξήγηση τους. Σχεδιάστηκε λοιπόν το δίκτυο της Εικόνας 6.1 που ελέγχει τη θερμοκρασία και τη ροή καυσίμων σε έναν λέβητα. Περιλαμβάνονται δεκατέσσερα FB, τα τέσσερα εκ των οποίων είναι FB_Label που όπως θα εξηγηθεί παρακάτω, παραλείπονται στην κατασκευή των XML αρχείων. Κάθε FB του δικτύου έχει ένα σύνολο παραμέτρων εισόδου και εξόδου που ορίζουν τη διεπαφή των στιγμιότυπων του FB και ένα σώμα που ορίζει την συμπεριφορά τους. 53

54 Εικόνα 6.1 Το δίκτυο των FB που κατασκευάστηκε και προσομοιώθηκε στο Uppaal. 54

55 Η Εικόνα 6.1 αποτελεί ένα πρόγραμμα σχεδιασμένο στο πρόγραμμα 4DIAC, σε γλώσσα FB. Το πρόγραμμα μπορεί να περιγραφεί στα παρακάτω βήματα : i. Λήψη μιας τιμής τάσης από ένα υποτιθέμενο αισθητήριο θερμοκρασίας. ii. Πολλαπλασιασμός της τάσης αυτής με μία σταθερά (π.χ. 20), υπολογίζοντας έτσι την θερμοκρασία που της αντιστοιχεί (υποθέτουμε ότι η χαρακτηριστική καμπύλη του αισθητηρίου είναι γραμμική). iii. Υπολογισμός της διαφορά της θερμοκρασίας αυτής από την επιθυμητή θερμοκρασία. iv. Πολλαπλασιασμός της επί ένα κέρδος (π.χ. 2) για τον υπολογισμό μιας υποτιθέμενης χειριζόμενης μεταβλητής που θεωρούμε ότι επηρεάζει τη ροή καυσίμων σε έναν λέβητα που θερμαίνεται το νερό και τη θερμοκρασία του οποίου μετράει το αισθητήριο μας. Συγκεκριμένα η λειτουργία του κάθε FB του δικτύου είναι η εξής: VoltsSimul: Είναι FB τύπου ΙΝ_ANY, που δέχεται τιμή ενός πραγματικού αριθμού που ισοδυναμεί στην τάση εισόδου. Η αρχική του τιμή είναι 0.9 και ενεργοποιείται και αρχικοποιείται από το FB_LABEL. Send: Είναι FB τύπου REAL2REAL που λειτουργεί ως διαμεσολαβητής και στέλνει τα δεδομένα του VoltsSimul στον πολλαπλασιαστή τάσης. FB_MUL_REAL: Αποτελεί τον πολλαπλασιαστή της αρχικής τάσης με το 20 που ενεργοποιείται από το FB Send. Rcv: Ένα ακόμα FB τύπου REAL2REAL που στέλνει τη νέα τιμή τάσης στο TempOut. TempOut: FB τύπου OUT_ANY, που ουσιαστικά υπολογίζει την τιμή της τρέχουσας θερμοκρασίας σύμφωνα με την τάση που είχαμε δώσει στο VoltsSimul. TargetTemp: Εισάγεται τη τιμή της ζητούμενης θερμοκρασίας που θέλουμε στο αισθητήριο μας. Στη συγκεκριμένη περίπτωση 22.5 C. REAL2REAL: Ίδια λειτουργία διαμεσολαβητή που διαβιβάζει την τιμή της ζητούμενης θερμοκρασίας. Err0r: FB τύπου FB_SUB_REAL, που διαβάζει και συγκρίνει τις τιμές της τρέχουσας θερμοκρασίας και της ζητούμενης αφαιρώντας τες. 55

56 GAIN_MUL: Ένας δεύτερος πολλαπλασιαστής με το 2 που αποτελεί το κέρδος για τον υπολογισμό της χειριζόμενης μεταβλητής. CorrectionOut: FΒ τύπου OUT_ANY που σύμφωνα με όλα τα προηγούμενα δεδομένα κάνει τις κατάλληλες τροποποιήσεις ώστε να πάρουμε τη ζητούμενη τιμή στο αισθητήριο. FB_LABEL: Αποτελούν βοηθητικά FB στο δίκτυο μας, που περιγράφουν γενικά την αλληλεπίδραση του χρήση με την εφαρμογή και αποτελούν ουσιαστικά γραφικά στοιχεία για την καλύτερη κατανόηση της λειτουργίας και σειράς εκτέλεσης του δικτύου. Στην συγγραφή του δικτύου σε γλώσσα XML και εισαγωγή του στο Uppaal, τα συγκεκριμένα FB παραλήφθηκαν. 6.2 Συγγραφή XML Το πρώτο βήμα για την μοντελοποίηση του δικτύου ήταν η συγγραφή του κάθε FB σε γλώσσα XML με βάση τους κανόνες της 5 ης ενότητας με σκοπό την κατόπιν εισαγωγή του στο Uppaal. Σύμφωνα με τη μεθοδολογία των χρονικών αυτομάτων που παρουσιάστηκε στην 3 η ενότητα κάθε FB περιγράφηκε από τέσσερα TA που στον Editor του Uppaal εμφανίζονται όπως παρακάτω (εικόνα 6.2). Εικόνα 6.2 Χρονικά αυτόματα για κάθε FB Σχεδιάστηκαν συνολικά δέκα FB, το καθένα από τα οποία αποτελείται από τα τέσσερα TA που φαίνονται στην εικόνα 6.2. Σύνολο δηλαδή υλοποιήθηκαν σαράντα αυτόματα για την περιγραφή του δικτύου. Ακολουθεί μια λεπτομερέστερη ανάλυση του κώδικα XML που περιγράφει το κάθε αυτόματο. Πριν την δημιουργία του τελικού XML αρχείου, το κάθε FB της εικόνας 6.1 συγγράφηκε σε ξεχωριστό αρχείο XML. Συνολικά δέκα ξεχωριστά αρχεία XML ενώ 56

57 κάποια από αυτά είναι πανομοιότυπα καθώς πρόκειται για τον ίδιο τύπο FB και ουσιαστικά αλλάζει μόνο το όνομα τους. Αυτά τα αρχεία XML ουσιαστικά μπορούν να αποτελέσουν βιβλιοθήκη FB και μπορούν να χρησιμοποιηθούν με τροποποίηση των συγχρονισμών τους σε κάθε άλλο δίκτυο μιας βιομηχανικής εφαρμογής σαν την εικόνα 6.1. Για το τελικό XML αρχείο θα έχουμε: Αρχικά καθώς επιθυμούμε επικοινωνία μεταξύ όλων των αυτομάτων, τα κανάλια συγχρονισμού και τα ρολόγια για κάθε αυτόματο ορίστηκαν στις γενικές μεταβλητές. Στο τελικό αρχείο που έχουμε εισάγονται δηλαδή όλες οι γενικές μεταβλητές που είχαν οριστεί στο καθένα από τα δέκα ξεχωριστά FB. <declaration>// Place global declarations here.; chan ECCinvocationREQ1, invokeecc1, event11, execalg1, endexecution1, eccinv1; clock ht1; chan ECCinvocationREQ2, invokeecc2, event22, execalg2, endexecution2, eccinv2, event2; clock ht2; chan ECCinvocationREQ3, invokeecc3,event33, execalg3, endexecution3, eccinv3, event3; clock ht3; chan ECCinvocationREQ4, invokeecc4, event44, execalg4, endexecution4, eccinv4, event4; clock ht4; chan ECCinvocationREQ5, invokeecc5, event55, execalg5, endexecution5, eccinv5,event5; clock ht5; chan ECCinvocationREQ6, invokeecc6, event66, execalg6, endexecution6,eccinv6,event6; clock ht6; chan ECCinvocationREQ7, invokeecc7, event77, execalg7, endexecution7,eccinv7,event7; clock ht7; chan ECCinvocationREQ8, invokeecc8, event88, execalg8, endexecution8, eccinv8,event8; clock ht8; chan ECCinvocationREQ9, invokeecc9, event99, execalg9, endexecution9,eccinv9,event9; clock ht9; chan ECCinvocationREQ10, invokeecc10,event1010,execalg10, endexecution10,eccinv10,event10; clock ht10; </declaration> 57

58 Στη συνέχεια προχωρήσαμε στη δημιουργία των templates που αφορούν τα αυτόματα. Όλα τα template που ορίστηκαν εισάχθηκαν στο τελικό XML αρχείο. INPUT: Περιγράφει το αυτόματο που προσομοιώνει ένα γεγονός εισόδου όπως περιγράφηκε στην ενότητα 3. Με εξαίρεση το INPUT αυτόματο του πρώτου FB (VoltsSimul), όλα τα υπόλοιπα ακολουθούν την μορφή της εικόνας 6.3 Εικόνα 6.3 Γενική μορφή αυτομάτου εισόδου. Με y ορίζεται ο αύξων αριθμός του προηγούμενου FB και με x ο αύξων αριθμός του τρέχοντος Η λογική που ακολουθήθηκε εξηγείται παρακάτω. Αναφέρεται ως παράδειγμα ο κώδικας που περιγράφει το αυτόματου εισόδου του 2 ου FB του δικτύου. Ο κώδικας που περιγράφει τα αντίστοιχα αυτόματα των υπόλοιπων FB έχει την ίδια μορφή με διαφορετικά απλά ονόματα. Συγκεκριμένα: <!--> Send </--> <!--> TEMPLATE-INPUT2 </--> <!--> LOCATIONS </--> <template> <name x="5" y="5">input2</name> <declaration>// Place local declarations here.; </declaration> <location id="id0" x="-600" y="-600"> <name x="-640" y="-610">idle</name> </location> 58

59 <location id="id1" x="-600" y="-500"> <name x="-720" y="-512">requesting_ecc</name> <committed/> </location> <location id="id2" x="-600" y="-400"><name x="-655" y="- 410">Action</name> </location> <location id="id3" x="-500" y="-500"> </location> <init ref="id0"/> <!--> TRANSITIONS </--> <transition> <source ref="id0"/> <target ref="id1"/> <label kind="synchronisation" x="-660" y="-550">event11!</label> </transition> <transition> <source ref="id1"/> <target ref="id2"/> <label kind="synchronisation" x="-660" y="-465">eccinv2?</label> </transition> <transition> <source ref="id2"/> <target ref="id3"/> <label kind="synchronisation" x="-560" y="-465">event2!</label> </transition> <transition> <source ref="id3"/> <target ref="id0"/> <label kind="synchronisation" x="-560" y="-555">event22?</label> </transition> </template> 59

60 Για το VoltsSimul η μορφή είναι η: Εικόνα 6.4 Αυτόματο εισόδου για το VoltsSimul. Δεν υπάρχει όπως φαίνεται κάποιο κανάλι συγχρονισμού για μετάβαση στην τοποθεσία Requesting_ECC καθώς θεωρείται ότι το εξωτερικό γεγονός που ενεργοποιεί τη μετάβαση αυτή και κατά συνέπεια εμμέσως όλο το δίκτυο είναι ο χρήστης. Ουσιαστικά λοιπόν με την επιλογή εκτέλεσης του δικτύου στον προσομοιωτή του Uppaal, εκτελείται το εξωτερικό γεγονός που οδηγεί στην Requesting_ECC. Επίσης παρατηρείται ότι δεν υπάρχει κάποια ενδιάμεση τοποθεσία μετά την Action για επιστροφή του αυτομάτου στην αρχική θέση. Ο λόγος εισαγωγής αυτής της τοποθεσίας στα υπόλοιπα αυτόματα INPUT είναι πρακτικός και αφορά το συγχρονισμό και μετάβαση στο επόμενο FB. To αντίστοιχο κομμάτι κώδικα: <!--> TEMPLATE- INPUT1 </--> <!-- > LOCATIONS </--> <template> <name x="5" y="5">input1</name> <declaration>// Place local declarations here.; </declaration> <location id="id0" x="-600" y="-600"> <name x="-640" y="-610">idle</name> </location> <location id="id1" x="-600" y="-500"> 60

61 <name x="-720" y="-512">requesting_ecc</name> <committed/> </location> <location id="id2" x="-600" y="-400"><name x="-655" y="- 410">Action</name> </location> <init ref="id0"/> <!--> TRANSITIONS </--> <transition> <source ref="id0"/> <target ref="id1"/> </transition> <transition> <source ref="id1"/> <target ref="id2"/> <label kind="synchronisation" x="-660" y="-465">eccinv1?</label> </transition> <transition> <source ref="id2"/> <target ref="id0"/> <label kind="synchronisation" x="-544" y="-496">event1010!</label> <nail x="-550" y="-450"/> <nail x="-550" y="-550"/> </transition> </template> ECC_Invocation_request_Automaton: Αποτελεί το αυτόματο που καλεί το διάγραμμα ελέγχου εκτέλεσης (ECC) μέσω συγχρονισμού το με τα αυτόματα INPUT και ECC. Εικόνα 6.5 Γενική μορφή αυτομάτου αίτησης του ECC. 61

62 Και το αντίστοιχο κομμάτι κώδικα XML που περιγράφει το αυτόματο αυτό πάλι για το δεύτερο FB: <!--> TEMPLATE-ECC_Invocation_Request_Automaton </--> <!--> LOCATIONS </--> <templa <name x="5" y="5">ecc_invocation_request_automaton2</name> <declaration>// Place local declarations here.; </declaration> <location id="id3" x="-250" y="-288"> <name x="-270" y="-318">invoke</name> </location> <location id="id4" x="-50" y="-288"> <name x="-70" y="-318">memorised</name> </location> <init ref="id3"/> <!--> TRANSITIONS </--> <transition> <source ref="id3"/> <target ref="id4"/> <label kind="synchronisation" x="-208" y="-256">eccinv2!</label> <nail x="-220" y="-258"/> <nail x="-80" y="-258"/> </transition> <transition> <source ref="id4"/> <target ref="id3"/> <label kind="synchronisation" x="-192" y="- 352">invokeECC2?</label> <nail x="-80" y="-328"/><nail x="-220" y="-328"/> </transition> </template> 62

63 ECC: Ορίζει το αυτόματο το οποίο ουσιαστικά εκτελεί την λειτουργία του εκάστοτε FB το οποίο προσπελάσουμε εκείνη τη στιγμή. Φαίνεται στην εικόνα 6.7 και παρατηρούμε ότι η μορφή της είναι λίγο διαφορετική από τη μορφή της εικόνας 3.4 που είχαμε ορίσει στην ενότητα 3 σχετικά με το αυτόματο του ECC. Αυτό οφείλεται στο ότι ουσιαστικά χρησιμοποιείται ένα γεγονός εισόδου κάθε φορά σε όλα τα FB (αφού τα FB_LABEL θεωρείται ότι αγνοούνται). Η προσπέλαση του ξεκινάει με το συγχρονισμό invokeecc. Μετά την τοποθεσία Await γίνεται μηδενισμός ενός ρολογιού (h) που αντιστοιχεί στον χρόνο εκτέλεσης του αλγορίθμου κάθε FB. Για κάθε διαφορετικό είδος FB που έχουμε ο χρόνος εκτέλεσης είναι διαφορετικός(talg). Σημειώνεται ότι οι χρονικές τιμές είναι x 10-5 καθώς το Uppaal μπορεί να δεχτεί μόνο κανάλια ακεραίων. Στη συνέχεια γίνεται συγχρονισμός με το αυτόματο που εκτελεί αυτόν τον εκάστοτε αλγόριθμο σύμφωνα και με το φρουρό που εισάγεται προς την τοποθεσία issueevent. Tέλος, υπάρχει ένα τελικό κανάλι συγχρονισμού το eventx που συγχρονίζεται με το αυτόματου INPUT. Αναλύεται παρακάτω πιο λεπτομερώς. Θεωρούμε ότι αυτό το κανάλι αντιπροσωπεύει το confirmation signal δηλαδή τη δημιουργίας γεγονότος εξόδου και συνεπώς την ολοκλήρωση της χρήσης του παρόντος FB. O κώδικας που αφορά το συγκεκριμένο αυτόματο πάλι για το 2 ο FB είναι: <!--> TEMPLATE1-ECC </--> <!--> LOCATIONS1 </--> <template> <name x="5" y="5">ecc2</name> <declaration>// Place local declarations here.; </declaration> <location id="id5" x="-250" y="-288"> <name x="-270" y="-318">start</name> </location> <location id="id6" x="-250" y="-200"> <name x="-270" y="-230">decision</name> <committed/> </location> <location id="id7" x="-350" y="0"> <name x="-370" y="10">await</name> </location> 63

64 <location id="id8" x="-350" y="100"> <name x="-336" y="104">processalg</name> </location> <location id="id9" x="-350" y="200"> <name x="-370" y="210">issueevent</name> <urgent/> </location> <init ref="id5"/> <!--> TRANSITIONS </--> <transition> <source ref="id6"/> <target ref="id7"/> </transition> <transition> <source ref="id5"/> <target ref="id6"/> <label kind="synchronisation" x="-328" y="- 272">invokeECC2!</label> </transition> <transition> <source ref="id7"/> <target ref="id8"/> <label kind="synchronisation" x="-345" y="30">execalg2?</label> <label kind="assignment" x="-344" y="48">ht2:=0</label> </transition> <transition> <source ref="id8"/> <target ref="id9"/> <label kind="guard" x="-345" y="123">ht2>=120</label> <label kind="synchronisation" x="-345" y="140">endexecution2!</label> </transition> <transition> <source ref="id9"/> <target ref="id5"/> <label kind="synchronisation" x="-505" y="-70">event2?</label> <nail x="-450" y="200"/><nail x="-450" y="-288"/> </transition> </template> 64

65 Algorithm: Αποτελεί το τελευταίο αυτόματο του κάθε FB (εικόνα) 6.6 και προσομοιώνει την εκτέλεση του αλγορίθμου του εκάστοτε FB. Εικόνα 6.6 Γενική μορφή Αυτομάτου προσομοίωσης εκτέλεσης αλγορίθμου. Γι αυτό το αυτόματο ο κώδικας XML είναι παίρνοντας πάλι το 2 ο του δικτύου ως παράδειγμα: <!--> TEMPLATE1-Algorithm </--> <!--> LOCATIONS </--> <template> <name x="5" y="5">algorithm2</name> <declaration>// Place local declarations here.;</declaration> <location id="id10" x="-250" y="-288"> <name x="-270" y="-318">executing</name> </location> <location id="id11" x="-50" y="-288"> <name x="-70" y="-318">idle</name> </location> <init ref="id11"/> <!--> TRANSITIONS </--> <transition> <source ref="id10"/> <target ref="id11"/> <label kind="synchronisation" x="-192" y="- 256">endExecution2?</label> <nail x="-220" y="-258"/> <nail x="-80" y="-258"/> </transition> <transition> <source ref="id11"/> <target ref="id10"/> <label kind="synchronisation" x="-192" y="-352">execalg2!</label> <nail x="-80" y="-328"/> <nail x="-220" y="-328"/> </transition> </template> 65

66 Εικόνα 6.7 Γενική μορφή αυτομάτου εκτέλεσης του ECC. Παραπάνω δόθηκαν τα κομμάτια του XML αρχείου που περιγράφουν τα τέσσερα αυτόματα που σχηματίζουν το 2 ο FB της εικόνας 6.1, Send. Φαίνονταιi οι ορισμοί των τοποθεσιών και οι συγχρονισμοί των μεταβάσεων με χρήση καναλιών συγχρονισμού για καθένα από τα αυτόματα αυτά. Για τα υπόλοιπα FB του δικτύου ακολουθείται ο αντίστοιχος τρόπος συγγραφής. Αναφέρεται μια διαφορά στη δομή του 1 ου INPUT αυτομάτου συγκριτικά με τα υπόλοιπα 10. Η διαφορά βρίσκεται στο ότι δεν υπάρχει αρχικός συγχρονισμός με κάποιο εξωτερικό γεγονός και ότι η μετάβαση προς το 2 ο FB γίνεται απευθείας μέσω του καναλιού event11? που βρίσκεται στο ECC1 σε αντίθεση με τα υπόλοιπα FB όπου το αυτόματο ECC κάθε φορά επιστρέφει στο αντίστοιχο INPUT και από εκεί εκτελείται ο συγχρονισμός μετάβασης στο επόμενο FB. Συγκεκριμένα: 66

67 <transition> <source ref="id9"/> <target ref="id5"/> <label kind="synchronisation" x="-505" y="-70">event11?</label> <nail x="-450" y="200"/><nail x="-450" y="-288"/> </transition> Σύμφωνα με τις παραπάνω γραμμές τα κανάλια event11? του ECC1 και το κανάλι event11! του INPUT2, συγχρονίζονται ώστε να επιτευχθεί η μετάβαση στο από το 1 ο FB στο 2 ο. Για μετάβαση στο 3 ο FB το κανάλι event2? του ECC2 συγχρονίζεται με το event2! του INPUT2. Επιστρέφει δηλαδή στο αυτόματο εισόδου και από εκεί στη συνέχεια το event22? συγχρονίζεται με το κανάλι event22! του INPUT3 σύμφωνα με τις παρακάτω γραμμές κώδικα. <transition> <source ref="id0"/> <target ref="id1"/> <label kind="synchronisation" x="-660" y="-550">event22!</label> </transition> Αυτός ο τρόπος μετάβασης, συνεχίζεται από το 2 ο μέχρι το 10 ο και τελευταίο FB του δικτύου και με την ίδια λογική συνεχίζεται η εγγραφή όλων των templates και για τα 10 FB. Το κάθε FB συγχρονίζεται με το επόμενο. Μοναδική διαφορά αποτελεί το 10 ο και τελευταίο FB, όπου αυτή τη φορά το event1010? του ECC10 συγχρονίζεται με το event1010! του INPUT1 γεγονός που όπως επεξηγείται αμέσως μετά ισοδυναμεί με επανεκκίνηση λειτουργίας του δικτύου. Στο τέλος του αρχείου, πριν την εντολή </nta> ορίζονται όπως είπαμε πριν τα όλα συστήματα που θα φορτωθούν στον προσομοιωτή. Στην περίπτωση μας τα συστήματα αφορούν και τα σαράντα αυτόματα που δημιουργήθηκαν, 4 για κάθε FB. Συνεπώς η δήλωση θα έχει τη μορφή: <system> system INPUT1, ECC_Invocation_Request_Automaton1, ECC1, Algorithm1, INPUT2,ECC_Invocation_Request_Automaton2,ECC2,Algorithm2,INPUT3,ECC_In vocation_request_automaton3,ecc3,algorithm3,input4,ecc_invocation_requ est_automaton4,ecc4,algorithm4,input5,ecc_invocation_request_automaton 5,ECC5,Algorithm5,INPUT6,ECC_Invocation_Request_Automaton6,ECC6,Algori thm6,input7,ecc_invocation_request_automaton7,ecc7,algorithm7,input8,e CC_Invocation_Request_Automaton8,ECC8,Algorithm8,INPUT9,ECC_Invocation _Request_Automaton9,ECC9,Algorithm9,INPUT10,ECC_Invocation_Request_Aut omaton10,ecc10,algorithm10; </system> 67

68 Πιο συνοπτικά και συγκεκριμένα η γενική λειτουργία του δικτύου είναι η εξής: Ξεκινώντας από το αυτόματο εισόδου του πρώτου FB(VoltsSimul) δεν υπάρχει εξωτερικό γεγονός συγχρονισμού για το 1 ο FB για μετάβαση στην τοποθεσία RequestingECC καθώς όπως αναφέρθηκε θεωρείται ότι αυτό το εξωτερικό γεγονός ισοδυναμεί με το χρήστη που εκτελεί το δίκτυο στον προσομοιωτή του Uppaal. Γίνεται λοιπόν συγχρονισμός με το αυτόματο αίτησης του ECC. Το κανάλι δηλαδή eccinv1 του INPUT1 (εικόνα 6.4) συγχρονίζεται με το αντίστοιχο κανάλι του ECC_Invocation_Request_Automaton1. Αυτό με τη σειρά του συγχρονίζεται μέσω του καναλιού invokeecc1 με το αυτόματο που εκτελεί το ECC1. Ακολουθώντας τη ροή του δικτύου της εικόνας 6.1, γίνεται εισαγωγή ενός ρολογιού που αφορά το μέγιστο αποδεκτό χρόνο εκτέλεσης του συγκεκριμένου αλγορίθμου, ανάλογα με το FB που βρισκόμαστε την κάθε στιγμή. Αφού στη συνέχεια καλεστεί το αυτόματο του αλγορίθμου και επιστρέψουμε στο αυτόματο του ECC, υπάρχει μια τελική μετάβαση event11? που συγχρονίζεται με το event11! του αυτομάτου εισόδου του δεύτερου FB (Send). Έτσι πλέον βρισκόμαστε στο δεύτερο FB. Αναφέρθηκε και προηγουμένως η διαφορετική μορφή του αυτομάτου εισόδου συγκριτικά με τα υπόλοιπα. Συγκεκριμένα ακολουθώντας τα κανάλια συγχρονισμού που αφορούν τα αυτόματα του 2 ου FB και όντας πλέον στο αυτόματο ECC2 του FB Send, υπάρχει μετάβαση που αυτή τη φορά επιστρέφει στο αυτόματο εισόδου INPUT2 του Send. Το κανάλι δηλαδή event2 αυτή τη φορά δεν οδηγεί στο τρίτο FB αλλά επιστρέφει στο INPUT2 και από εκεί μετά ακολουθεί συγχρονισμός και μετάβαση στο τρίτο μέσω του καναλιού event22. Ο λόγος δημιουργίας αυτού το ενδιάμεσου κόμβου, είναι ότι Uppaal σε περίπτωση συγχρονισμού περισσότερο από 2 μεταβάσεων, η επιλογή της μετάβασης γίνεται μη ντετερμινιστικά γεγονός που θα οδηγήσει σε αδυναμία ελέγχου και σφάλμα της ροής του δικτύου FB. H διαδικασία μετάβασης από το FB Send προς το 3 ο FB_MUL_REAL ακολουθείτε με τον ίδιο ακριβώς τρόπο μέχρι και το τελευταίο FB (CorrectionOut). Το αυτόματο ECC του τελευταίου FB, συγχρονίζεται με το 1 ο (VoltsSimul). Συγκεκριμένα το κανάλι event1010 του ECC10 επιστρέφει στο INPUT1 και το ΙNPUT1 επιστρέφει στην αρχική του τοποθεσία. Σε αυτό το σημείο το δίκτυο βρίσκεται στην κατάσταση που μπορεί να δεχτεί νέα τιμή από το αισθητήριο ώστε να εισαχθεί στο δίκτυο και να ξαναλειτουργήσει από την αρχή. Η τελευταία δηλαδή μετάβαση συγχρονισμού του καναλιού event1010 προσφέρει δηλαδή ένα αυτόματο reset στο δίκτυο μας και μπορεί να επανεκκινηθεί η λειτουργία του. 68

69 Αυτός ο τρόπος προσπέλασης των αυτομάτων με βάση τα όσα περιγράφηκαν, μπορεί να εφαρμοστεί για οποιονδήποτε αριθμό FB αποτελούν ένα δίκτυο. Παρουσιάστηκε απλά ως παράδειγμα ο τρόπος με τον οποίο δημιουργήθηκε το XML που περιγράφει την εικόνα 6.1. Για κάθε άλλο δίκτυο, τα FB θα επικοινωνούν μεταξύ τους με τον ίδιο τρόπο που περιγράφεται για το συγκεκριμένο παράδειγμα αρκεί να διατηρείται ο κανόνας των τεσσάρων αυτομάτων για κάθε FB. Σημειώνεται ότι δεν παρουσιάζεται κάπου η ακριβής εκτέλεση των επιμέρους αλγορίθμων κάθε FB. Σκοπός μας ήταν να αποδείξουμε τον ορθό τρόπο επικοινωνίας μεταξύ των FB και την απουσία σφαλμάτων στον Επαληθευτή. Στα πλαίσια αυτής της διπλωματικής εργασίας ασχοληθήκαμε μόνο με την περιγραφή των συγκεκριμένων δέκα FB, ακολουθώντας όμως την ίδια διαδικασία και μεθοδολογία μπορεί να κατασκευαστεί οποιοδήποτε FB που ορίζεται στο πρότυπο IEC

70 6.3 Εισαγωγή ερωτημάτων στον Επαληθευτή του Uppaal Όπως έχει αναφερθεί ο επαληθευτής (Verifier) του Uppaal επιτρέπει την εισαγωγή ερωτημάτων που επαληθεύουν ή όχι την ορθότητα του δικτύου αυτομάτων που έχει φορτωθεί. Γραμμένα στη μορφή που παρουσιάστηκε στην ενότητα 4.4 εισάγονται κάποια ερωτήματα η επαλήθευση των οποίων κρίθηκε ότι αποδεικνύει επαρκώς τη ζητούμενη λειτουργικότητα της τεχνικής Επαλήθευση σωστής λειτουργίας του δικτύου. Πρώτο βήμα στην επαλήθευση του δικτύου μας ήταν η εγγύηση της απουσίας αδιεξόδου. Πιθανή αδιέξοδος μεταφράζεται ως πλήρης αδυναμία του προγράμματος μας να συνεχίσει πέρα από κάποια κατάσταση και συνεπώς πλήρης αποτυχίας του δικτύου μας να εκτελεστεί στον προσομοιωτή του Uppaal πέρα από την τοποθεσία που συναντάται το αδιέξοδο. To ερώτημα που τέθηκε στην καρτέλα Query του Verifier και απέδειξε την έλλειψη αδιεξόδου είναι το «Α[] not deadlock» και πράγματι πήραμε θετικό αποτέλεσμα: Εικόνα 6.8 Αποτέλεσμα ερωτήματος αδιεξόδου στον επαληθευτή του Uppaal Η εξέταση αδιεξόδου αποτελεί τον αρχικό και βασικό έλεγχο κάθε δικτύου αυτομάτων που πρόκειται να εκτελεστεί. Απουσία αδιεξόδου σημαίνει ότι το πρόγραμμα είναι ικανό να λειτουργήσει. Για την εξακρίβωση όμως ότι το πρόγραμμα εκτελείται με τον τρόπο που θέλουμε εισάγονται κάποια επιπλέον ερωτήματα. Στη συνέχεια θέλαμε να ελέγξουμε αν όλα τα τα FB του δικτύου και κυρίως το αυτόματου που εκτελεί το ECC, προσπελάσονται επιτυχώς. Για κάθε ECC λοιπόν θέσαμε τα ερωτήματα «Ε<> ECC.Start» και «Ε<> ECC.issueEvent» που ισοδυναμούν με προσπέλαση των τοποθεσιών Start και issueevent κάθε FB κάθε φορά που εκτελείται το πρόγραμμα. Εφόσον για καθένα από τα δέκα FB, κάθε φορά που εκτελείται το πρόγραμμα, είναι σίγουρο ότι θα περάσει από την κατάσταση Start του ECC αλλά και από την Issue.event σύμφωνα και με την εικόνα 6.7 τότε η προσπέλαση όλων των FB γίνεται επιτυχώς. 70

71 Για μία περαιτέρω «ασφάλεια» στην εγγύηση των δύο προηγουμένων ερωτημάτων τέθηκε για τον ίδιο σκοπό και το ερώτημα «E<>INPUT.Action» ώστε να ελέγξουμε κατά πόσο κάθε αυτόματο εισόδου για όλα τα FB προσπελάσεται σωστά. Για όλα τα παραπάνω αυτά ερωτήματα λάβαμε θετική απάντηση γεγονός που αποτελεί ακόμα ένα βήμα για την επαλήθευση της τεχνικής. Εικόνα 6.9 Αποτέλεσμα των απεικονιζόντων ερωτημάτων στο Uppaal. 71