Συνεχίζοντας το θέμα , ας δούμε το πρόβλημα της μαθηματικής μοντελοποίησης από την άλλη πλευρά. Αφού πειστούμε ότι το μοντέλο αντιστοιχεί στην κατ' οίκον αλήθεια της ζωής, μπορούμε να απαντήσουμε στο κύριο ερώτημα: "τι ακριβώς έχουμε εδώ;" Όταν δημιουργούμε ένα μοντέλο ενός τεχνικού αντικειμένου, συνήθως θέλουμε να βεβαιωθούμε ότι αυτό το αντικείμενο θα ανταποκριθεί στις προσδοκίες μας. Για το σκοπό αυτό γίνονται δυναμικοί υπολογισμοί διεργασιών και το αποτέλεσμα συγκρίνεται με τις απαιτήσεις. Αυτό είναι ένα ψηφιακό δίδυμο, ένα εικονικό πρωτότυπο κ.λπ. μοντέρνα μικρά παιδιά που, στο στάδιο του σχεδιασμού, λύνουν το πρόβλημα του πώς να βεβαιωθούμε ότι θα έχουμε αυτό που σχεδιάζαμε.
Πώς μπορούμε γρήγορα να βεβαιωθούμε ότι το σύστημά μας είναι ακριβώς αυτό που σχεδιάζουμε, θα πετάξει ή θα επιπλεύσει το σχέδιό μας; Και αν πετάξει, πόσο ψηλά; Και αν επιπλέει, πόσο βαθιά;
Αυτό το άρθρο εξετάζει την αυτοματοποίηση της επαλήθευσης της συμμόρφωσης με τις απαιτήσεις ενός τεχνικού κτιρίου κατά τη δημιουργία δυναμικών μοντέλων τεχνικών συστημάτων. Για παράδειγμα, ας δούμε ένα στοιχείο της τεχνικής προδιαγραφής για ένα σύστημα ψύξης αέρα αεροσκάφους.
Θεωρούμε εκείνες τις απαιτήσεις που μπορούν να εκφραστούν αριθμητικά και να επαληθευτούν μαθηματικά με βάση ένα συγκεκριμένο μοντέλο υπολογισμού. Είναι σαφές ότι αυτό είναι μόνο μέρος των γενικών απαιτήσεων για οποιοδήποτε τεχνικό σύστημα, αλλά για τον έλεγχο τους ξοδεύουμε χρόνο, νεύρα και χρήματα για τη δημιουργία δυναμικών μοντέλων του αντικειμένου.
Κατά την περιγραφή των τεχνικών απαιτήσεων με τη μορφή ενός εγγράφου, μπορούν να διακριθούν αρκετοί τύποι διαφορετικών απαιτήσεων, καθεμία από τις οποίες απαιτεί διαφορετικές προσεγγίσεις για το σχηματισμό αυτόματης επαλήθευσης της εκπλήρωσης των απαιτήσεων.
Για παράδειγμα, εξετάστε αυτό το μικρό αλλά ρεαλιστικό σύνολο απαιτήσεων:
- Θερμοκρασία ατμοσφαιρικού αέρα στην είσοδο του συστήματος επεξεργασίας νερού:
στο πάρκινγκ - από μείον 35 έως 35 ºС,
κατά την πτήση - από μείον 35 έως 39 ºС. - Η στατική πίεση του ατμοσφαιρικού αέρα κατά την πτήση είναι από 700 έως 1013 GPa (από 526 έως 760 mm Hg).
- Η συνολική πίεση αέρα στην είσοδο της εισαγωγής αέρα SVO κατά την πτήση είναι από 754 έως 1200 GPa (από 566 έως 1050 mm Hg).
- Θερμοκρασία αέρα ψύξης:
στο χώρο στάθμευσης - όχι περισσότερο από 27 ºС, για τεχνικά μπλοκ - όχι περισσότερο από 29 ºС,
κατά την πτήση - όχι περισσότερο από 25 ºС, για τεχνικά μπλοκ - όχι περισσότερο από 27 ºС. - Ροή αέρα ψύξης:
όταν είναι σταθμευμένο - τουλάχιστον 708 kg/h,
κατά την πτήση - όχι λιγότερο από 660 kg/h. - Η θερμοκρασία του αέρα στους χώρους οργάνων δεν είναι μεγαλύτερη από 60 ºС.
- Η ποσότητα της λεπτής ελεύθερης υγρασίας στον αέρα ψύξης δεν υπερβαίνει τα 2 g/kg ξηρού αέρα.
Ακόμη και μέσα σε αυτό το περιορισμένο σύνολο απαιτήσεων, υπάρχουν τουλάχιστον δύο κατηγορίες που πρέπει να αντιμετωπίζονται διαφορετικά στο σύστημα:
- απαιτήσεις για τις συνθήκες λειτουργίας του συστήματος (ρήτρες 1-3).
- παραμετρικές απαιτήσεις για το σύστημα (ρήτρες 3-7).
Απαιτήσεις συνθηκών λειτουργίας συστήματος
Οι εξωτερικές συνθήκες για το σύστημα που αναπτύσσεται κατά τη μοντελοποίηση μπορούν να προσδιοριστούν ως οριακές συνθήκες ή ως αποτέλεσμα της λειτουργίας του γενικού συστήματος.
Στη δυναμική προσομοίωση, είναι απαραίτητο να διασφαλιστεί ότι οι καθορισμένες συνθήκες λειτουργίας καλύπτονται από τη διαδικασία προσομοίωσης.
Απαιτήσεις παραμετρικών συστημάτων
Αυτές οι απαιτήσεις είναι παράμετροι που παρέχονται από το ίδιο το σύστημα. Κατά τη διαδικασία μοντελοποίησης, μπορούμε να λάβουμε αυτές τις παραμέτρους ως αποτελέσματα υπολογισμού και να βεβαιωθούμε ότι πληρούνται οι απαιτήσεις σε κάθε συγκεκριμένο υπολογισμό.
Αναγνώριση και κωδικοποίηση απαιτήσεων
Για ευκολία στην εργασία με τις απαιτήσεις, τα υπάρχοντα πρότυπα συνιστούν την εκχώρηση ενός αναγνωριστικού σε κάθε απαίτηση. Κατά την εκχώρηση αναγνωριστικών, είναι ιδιαίτερα επιθυμητό να χρησιμοποιείται ένα ενοποιημένο σύστημα κωδικοποίησης.
Ο κωδικός απαίτησης μπορεί να είναι απλώς ένας αριθμός που αντιπροσωπεύει τον αριθμό παραγγελίας της απαίτησης ή μπορεί να περιέχει έναν κωδικό για τον τύπο της απαίτησης, έναν κωδικό για το σύστημα ή τη μονάδα στην οποία εφαρμόζεται, έναν κωδικό παραμέτρου, έναν κωδικό τοποθεσίας και οτιδήποτε άλλο μπορεί να φανταστεί ο μηχανικός. (δείτε το άρθρο για τη χρήση της κωδικοποίησης)
Ο Πίνακας 1 παρέχει ένα απλό παράδειγμα κωδικοποίησης απαιτήσεων.
- κωδικός της πηγής απαιτήσεων R-απαιτήσεις TK.
- κωδικός τύπος απαιτήσεων E - απαιτήσεις - περιβαλλοντικές παράμετροι ή συνθήκες λειτουργίας
S - απαιτήσεις που παρέχονται από το σύστημα. - κωδικός κατάστασης αεροσκάφους 0 – οποιοδήποτε, G – σταθμευμένο, F – κατά την πτήση.
- Κωδικός τύπου φυσικής παραμέτρου T – θερμοκρασία, P – πίεση, G – ρυθμός ροής, υγρασία H;
- σειριακό αριθμό της απαίτησης.
| ID Απαιτήσεις |
Περιγραφή | Παράμετρος |
| REGT01 | Θερμοκρασία περιβάλλοντος αέρα στην είσοδο του συστήματος ψύξης νερού: στο χώρο στάθμευσης - από μείον 35ºС. έως 35 ºС. | |
| REFT01 | Θερμοκρασία ατμοσφαιρικού αέρα στην είσοδο του συστήματος αεράμυνας: κατά την πτήση - από μείον 35 ºС έως 39 ºС. | |
| REFP01 | Η στατική ατμοσφαιρική πίεση κατά την πτήση είναι από 700 έως 1013 hPa (από 526 έως 760 mm Hg). | |
| REFP02 | Η συνολική πίεση αέρα στην είσοδο της εισαγωγής αέρα SVO κατά την πτήση είναι από 754 έως 1200 hPa (από 566 έως 1050 mm Hg). | |
| RSGT01 | Θερμοκρασία αέρα ψύξης: όταν είναι σταθμευμένο όχι περισσότερο από 27 ºС | |
| RSGT02 | Θερμοκρασία αέρα ψύξης: στο χώρο στάθμευσης, για τεχνικές μονάδες όχι μεγαλύτερη από 29 ºС | |
| RSFT01 | Θερμοκρασία αέρα ψύξης κατά την πτήση όχι μεγαλύτερη από 25 ºС | |
| RSFT02 | Θερμοκρασία αέρα ψύξης: κατά την πτήση, για τεχνικές μονάδες όχι μεγαλύτερη από 27 ºС | |
| RSGG01 | Ροή αέρα ψύξης: όταν είναι σταθμευμένο όχι λιγότερο από 708 kg/h | |
| RSFG01 | Ροή αέρα ψύξης: κατά την πτήση όχι λιγότερο από 660 kg/h | |
| RS0T01 | Θερμοκρασία αέρα στους χώρους οργάνων όχι μεγαλύτερη από 60 ºС | |
| RSH01 | Η ποσότητα της λεπτής ελεύθερης υγρασίας στον αέρα ψύξης δεν υπερβαίνει τα 2 g/kg ξηρού αέρα |
Σχεδιασμός συστήματος επαλήθευσης απαιτήσεων.
Για κάθε απαίτηση σχεδιασμού υπάρχει ένας αλγόριθμος για την αξιολόγηση της αντιστοιχίας των παραμέτρων σχεδιασμού και των παραμέτρων που καθορίζονται στην απαίτηση. Σε γενικές γραμμές, οποιοδήποτε σύστημα ελέγχου περιέχει πάντα αλγόριθμους για τον έλεγχο των απαιτήσεων απλά από προεπιλογή. Και ακόμη και οποιοσδήποτε ρυθμιστής τα περιέχει. Αν η θερμοκρασία ξεφύγει από τα όρια, το κλιματιστικό ανάβει. Έτσι, το πρώτο στάδιο οποιασδήποτε ρύθμισης είναι να ελεγχθεί εάν οι παράμετροι πληρούν τις απαιτήσεις.
Και εφόσον η επαλήθευση είναι ένας αλγόριθμος, τότε μπορούμε να χρησιμοποιήσουμε τα ίδια εργαλεία και εργαλεία που χρησιμοποιούμε για τη δημιουργία προγραμμάτων ελέγχου. Για παράδειγμα, το περιβάλλον SimInTech σάς επιτρέπει να δημιουργείτε πακέτα έργων που περιέχουν διάφορα μέρη του μοντέλου, που εκτελούνται με τη μορφή ξεχωριστών έργων (μοντέλο αντικειμένου, μοντέλο συστήματος ελέγχου, μοντέλο περιβάλλοντος κ.λπ.).
Το έργο επαλήθευσης απαιτήσεων σε αυτήν την περίπτωση γίνεται το ίδιο έργο αλγορίθμου και συνδέεται με το πακέτο μοντέλου. Και στη λειτουργία δυναμικής μοντελοποίησης εκτελεί ανάλυση συμμόρφωσης με τις απαιτήσεις των τεχνικών προδιαγραφών.
Ένα πιθανό παράδειγμα σχεδιασμού συστήματος φαίνεται στο σχήμα 1.
Εικόνα 1. Παράδειγμα σχεδιασμού έργου επαλήθευσης.
Ακριβώς όπως για τους αλγόριθμους ελέγχου, οι απαιτήσεις μπορούν να συνταχθούν ως ένα σύνολο φύλλων. Για την ευκολία της εργασίας με αλγόριθμους σε περιβάλλοντα δομικής μοντελοποίησης όπως SimInTech, Simulink, AmeSim, χρησιμοποιείται η δυνατότητα δημιουργίας δομών πολλαπλών επιπέδων με τη μορφή υπομοντέλων. Αυτή η οργάνωση καθιστά δυνατή την ομαδοποίηση διαφόρων απαιτήσεων σε σύνολα για την απλοποίηση της εργασίας με μια σειρά απαιτήσεων, όπως γίνεται για τους αλγόριθμους ελέγχου (βλ. Εικ. 2).
Εικόνα 2. Ιεραρχική δομή του μοντέλου επαλήθευσης απαιτήσεων.
Για παράδειγμα, στην υπό εξέταση περίπτωση, διακρίνονται δύο ομάδες: απαιτήσεις για το περιβάλλον και απαιτήσεις απευθείας για το σύστημα. Επομένως, χρησιμοποιείται μια δομή δεδομένων δύο επιπέδων: δύο ομάδες, καθεμία από τις οποίες είναι ένα φύλλο του αλγορίθμου.
Για τη σύνδεση δεδομένων με το μοντέλο, χρησιμοποιείται ένα τυπικό σχήμα για τη δημιουργία μιας βάσης δεδομένων σημάτων, το οποίο αποθηκεύει δεδομένα για ανταλλαγή μεταξύ τμημάτων του έργου.
Κατά τη δημιουργία και τη δοκιμή λογισμικού, οι μετρήσεις των αισθητήρων (αναλόγων πραγματικών αισθητήρων συστήματος) που χρησιμοποιούνται από το σύστημα ελέγχου τοποθετούνται σε αυτή τη βάση δεδομένων.
Για ένα δοκιμαστικό έργο, τυχόν παράμετροι που υπολογίζονται στο δυναμικό μοντέλο μπορούν να αποθηκευτούν στην ίδια βάση δεδομένων και έτσι να χρησιμοποιηθούν για να ελεγχθεί εάν πληρούνται οι απαιτήσεις.
Σε αυτή την περίπτωση, το ίδιο το δυναμικό μοντέλο μπορεί να εκτελεστεί σε οποιοδήποτε μαθηματικό σύστημα μοντελοποίησης ή ακόμα και με τη μορφή εκτελέσιμου προγράμματος. Η μόνη απαίτηση είναι η παρουσία διεπαφών λογισμικού για την έκδοση δεδομένων μοντελοποίησης στο εξωτερικό περιβάλλον.
Εικόνα 3. Σύνδεση του έργου επαλήθευσης με το σύνθετο μοντέλο.
Ένα παράδειγμα φύλλου επαλήθευσης βασικών απαιτήσεων παρουσιάζεται στο Σχήμα 4. Από την πλευρά του προγραμματιστή, είναι ένα συμβατικό υπολογιστικό διάγραμμα στο οποίο παρουσιάζεται γραφικά ο αλγόριθμος επαλήθευσης απαιτήσεων.
Εικόνα 4. Φύλλο ελέγχου απαιτήσεων.
Τα κύρια μέρη του φύλλου ελέγχου περιγράφονται στο Σχήμα 5. Ο αλγόριθμος ελέγχου διαμορφώνεται παρόμοια με τα διαγράμματα σχεδιασμού των αλγορίθμων ελέγχου. Στη δεξιά πλευρά υπάρχει ένα μπλοκ για την ανάγνωση σημάτων από τη βάση δεδομένων. Αυτό το μπλοκ έχει πρόσβαση στη βάση δεδομένων σημάτων κατά τη διάρκεια της προσομοίωσης.
Τα λαμβανόμενα σήματα αναλύονται για τον υπολογισμό των συνθηκών επαλήθευσης απαιτήσεων. Σε αυτή την περίπτωση, γίνεται ανάλυση υψομέτρου για τον προσδιορισμό της θέσης του αεροσκάφους (είτε είναι σταθμευμένο είτε σε πτήση). Για το σκοπό αυτό, μπορείτε να χρησιμοποιήσετε άλλα σήματα και υπολογισμένες παραμέτρους του μοντέλου.
Οι συνθήκες επαλήθευσης και οι παράμετροι που ελέγχονται μεταφέρονται σε τυπικά μπλοκ επαλήθευσης, στα οποία αυτές οι παράμετροι αναλύονται ως προς τη συμμόρφωση με τις καθορισμένες απαιτήσεις. Τα αποτελέσματα καταγράφονται στη βάση δεδομένων σημάτων με τέτοιο τρόπο ώστε να μπορούν να χρησιμοποιηθούν για την αυτόματη δημιουργία μιας λίστας ελέγχου.
Εικόνα 5. Δομή του φύλλου υπολογισμού επαλήθευσης απαιτήσεων.
Οι παράμετροι που θα ελεγχθούν δεν χρησιμοποιούν απαραίτητα σήματα που περιέχονται στη βάση δεδομένων, τα οποία ελέγχονται από παραμέτρους που υπολογίζονται κατά τη διαδικασία προσομοίωσης. Τίποτα δεν μας εμποδίζει να πραγματοποιήσουμε πρόσθετους υπολογισμούς στο πλαίσιο των προσχεδίων απαιτήσεων, όπως ακριβώς υπολογίζουμε τις συνθήκες επαλήθευσης.
Για παράδειγμα, αυτή η απαίτηση:
Ο αριθμός των ενεργοποιήσεων του συστήματος διόρθωσης κατά τη διάρκεια της πτήσης προς τον στόχο δεν πρέπει να υπερβαίνει τις 5 και ο συνολικός χρόνος λειτουργίας του συστήματος διόρθωσης δεν πρέπει να υπερβαίνει τα 30 δευτερόλεπτα.
Σε αυτή την περίπτωση, ένας αλγόριθμος για την αντιστάθμιση του αριθμού των εκκινήσεων και του συνολικού χρόνου λειτουργίας προστίθεται στο διάγραμμα σχεδιασμού των απαιτήσεων.
Μπλοκ επαλήθευσης τυπικών απαιτήσεων.
Κάθε πλαίσιο ελέγχου τυπικής απαίτησης έχει σχεδιαστεί για να υπολογίζει την εκπλήρωση μιας απαίτησης συγκεκριμένου τύπου. Για παράδειγμα, οι περιβαλλοντικές απαιτήσεις περιλαμβάνουν μια σειρά από θερμοκρασίες λειτουργίας περιβάλλοντος όταν είναι σταθμευμένο και κατά την πτήση. Αυτό το μπλοκ πρέπει να λάβει τη θερμοκρασία του αέρα στο μοντέλο ως παράμετρο και να καθορίσει εάν αυτή η παράμετρος καλύπτει το καθορισμένο εύρος θερμοκρασίας./p>
Το μπλοκ περιέχει δύο θύρες εισόδου, την παράμετρο και την κατάσταση.
Το πρώτο τροφοδοτείται με την παράμετρο υπό έλεγχο. Σε αυτήν την περίπτωση, "Εξωτερική θερμοκρασία".
Μια μεταβλητή Boolean παρέχεται στη δεύτερη θύρα - η συνθήκη για την εκτέλεση του ελέγχου.
Εάν ληφθεί TRUE (1) στη δεύτερη είσοδο, τότε το μπλοκ εκτελεί έναν υπολογισμό επαλήθευσης απαίτησης.
Εάν η δεύτερη είσοδος λάβει FALSE (0), τότε οι συνθήκες δοκιμής δεν πληρούνται. Αυτό είναι απαραίτητο για να μπορούν να ληφθούν υπόψη οι συνθήκες υπολογισμού. Στην περίπτωσή μας, αυτή η είσοδος χρησιμοποιείται για την ενεργοποίηση ή απενεργοποίηση του ελέγχου ανάλογα με την κατάσταση του μοντέλου. Εάν το αεροσκάφος βρίσκεται στο έδαφος κατά τη διάρκεια της προσομοίωσης, τότε δεν ελέγχονται οι απαιτήσεις που σχετίζονται με την πτήση και αντίστροφα - εάν το αεροσκάφος βρίσκεται σε πτήση, τότε δεν ελέγχονται οι απαιτήσεις που σχετίζονται με τη λειτουργία σε στάση.
Αυτή η είσοδος μπορεί επίσης να χρησιμοποιηθεί κατά τη ρύθμιση του μοντέλου, για παράδειγμα στο αρχικό στάδιο του υπολογισμού. Όταν το μοντέλο φέρεται στην απαιτούμενη κατάσταση, τα μπλοκ ελέγχου απενεργοποιούνται, αλλά μόλις το σύστημα φτάσει στον απαιτούμενο τρόπο λειτουργίας, τα μπλοκ ελέγχου ενεργοποιούνται.
Οι παράμετροι αυτού του μπλοκ είναι:
- οριακές συνθήκες: ανώτερο (UpLimit) και κατώτερο (DownLimit) όρια εύρους που πρέπει να ελεγχθούν.
- απαιτούμενος χρόνος έκθεσης συστήματος στις οριακές περιοχές (TimeInterval) σε δευτερόλεπτα.
- Αναγνωριστικό αιτήματος ReqName;
- Επιτρεπτότητα υπέρβασης του εύρους Το Out_range είναι μια μεταβλητή Boolean που καθορίζει εάν μια τιμή που υπερβαίνει το ελεγμένο εύρος αποτελεί παραβίαση της απαίτησης.
Σε ορισμένες περιπτώσεις, η έξοδος της τιμής δοκιμής υποδεικνύει ότι το σύστημα έχει κάποιο περιθώριο και μπορεί να λειτουργεί εκτός του εύρους λειτουργίας του. Σε άλλες περιπτώσεις, μια έξοδος σημαίνει ότι το σύστημα δεν μπορεί να διατηρήσει τα σημεία ρύθμισης εντός εύρους.
Εικόνα 6. Ένα τυπικό μπλοκ ελέγχου ιδιοτήτων στο διάγραμμα και τις παραμέτρους του.
Ως αποτέλεσμα του υπολογισμού αυτού του μπλοκ, η μεταβλητή Result σχηματίζεται στην έξοδο, η οποία λαμβάνει τις ακόλουθες τιμές:
- 0 – rΚαμία, η τιμή δεν έχει καθοριστεί.
- 1 – rDone, η απαίτηση πληρούται.
- 2 – rΣφάλμα, η απαίτηση δεν πληρούται.
Η εικόνα του μπλοκ περιέχει:
- Κείμενο αναγνωριστικού·
- ψηφιακές ενδείξεις παραμέτρων ορίων μέτρησης.
- αναγνωριστικό χρώματος της κατάστασης παραμέτρου.
Μέσα στο μπλοκ μπορεί να υπάρχει ένα μάλλον πολύπλοκο λογικό κύκλωμα συμπερασμάτων.
Για παράδειγμα, για να ελέγξετε το εύρος θερμοκρασίας λειτουργίας της μονάδας που φαίνεται στο σχήμα 6, το εσωτερικό κύκλωμα φαίνεται στο σχήμα 7.
Εικόνα 7. Εσωτερικό διάγραμμα της μονάδας προσδιορισμού εύρους θερμοκρασίας.
Μέσα στο μπλοκ κυκλώματος, χρησιμοποιούνται οι ιδιότητες που καθορίζονται στις παραμέτρους του μπλοκ.
Εκτός από την ανάλυση της συμμόρφωσης με τις απαιτήσεις, το εσωτερικό διάγραμμα του μπλοκ περιέχει ένα γράφημα απαραίτητο για την εμφάνιση των αποτελεσμάτων της προσομοίωσης. Αυτό το γράφημα μπορεί να χρησιμοποιηθεί τόσο για προβολή κατά τον υπολογισμό όσο και για ανάλυση των αποτελεσμάτων μετά τον υπολογισμό.
Τα αποτελέσματα υπολογισμού μεταδίδονται στην έξοδο του μπλοκ και καταγράφονται ταυτόχρονα σε ένα αρχείο γενικής αναφοράς, το οποίο δημιουργείται με βάση τα αποτελέσματα για ολόκληρο το έργο. (βλ. Εικ. 8)
Ένα παράδειγμα αναφοράς που δημιουργήθηκε με βάση τα αποτελέσματα της προσομοίωσης είναι ένα αρχείο html που δημιουργήθηκε σύμφωνα με μια δεδομένη μορφή. Η μορφή μπορεί να διαμορφωθεί αυθαίρετα στη μορφή που είναι αποδεκτή από έναν συγκεκριμένο οργανισμό.
Μέσα στο μπλοκ κυκλώματος, χρησιμοποιούνται οι ιδιότητες που καθορίζονται στις παραμέτρους του μπλοκ.
Εκτός από την ανάλυση της συμμόρφωσης με τις απαιτήσεις, το εσωτερικό διάγραμμα του μπλοκ περιέχει ένα γράφημα απαραίτητο για την εμφάνιση των αποτελεσμάτων της προσομοίωσης. Αυτό το γράφημα μπορεί να χρησιμοποιηθεί τόσο για προβολή κατά τον υπολογισμό όσο και για ανάλυση των αποτελεσμάτων μετά τον υπολογισμό.
Τα αποτελέσματα υπολογισμού μεταδίδονται στην έξοδο του μπλοκ και καταγράφονται ταυτόχρονα σε ένα αρχείο γενικής αναφοράς, το οποίο δημιουργείται με βάση τα αποτελέσματα για ολόκληρο το έργο. (βλ. Εικ. 8)
Ένα παράδειγμα αναφοράς που δημιουργήθηκε με βάση τα αποτελέσματα της προσομοίωσης είναι ένα αρχείο html που δημιουργήθηκε σύμφωνα με μια δεδομένη μορφή. Η μορφή μπορεί να διαμορφωθεί αυθαίρετα στη μορφή που είναι αποδεκτή από έναν συγκεκριμένο οργανισμό.
Εικόνα 8. Παράδειγμα αρχείου αναφοράς που βασίζεται σε αποτελέσματα προσομοίωσης.
Σε αυτό το παράδειγμα, η φόρμα αναφοράς διαμορφώνεται απευθείας στις ιδιότητες του έργου και η μορφή στον πίνακα ορίζεται ως καθολικά σήματα έργου. Σε αυτήν την περίπτωση, το ίδιο το SimInTech επιλύει το πρόβλημα της ρύθμισης της αναφοράς και το μπλοκ για την εγγραφή αποτελεσμάτων σε ένα αρχείο χρησιμοποιεί αυτές τις γραμμές για να γράψει στο αρχείο αναφοράς.
Εικόνα 9. Ρύθμιση της μορφής αναφοράς σε καθολικά σήματα έργου
Χρήση βάσης δεδομένων σημάτων για απαιτήσεις.
Για την αυτοματοποίηση της εργασίας με τις ρυθμίσεις ιδιοτήτων, δημιουργείται μια τυπική δομή στη βάση δεδομένων σημάτων για κάθε τυπικό μπλοκ. (βλ. Εικ. 10)
Εικόνα 10. Παράδειγμα της δομής ενός μπλοκ ελέγχου απαίτησης σε μια βάση δεδομένων σημάτων.
Η βάση δεδομένων σημάτων παρέχει:
- Αποθήκευση όλων των απαραίτητων παραμέτρων απαιτήσεων συστήματος.
- Βολική προβολή των υφιστάμενων απαιτήσεων του έργου από καθορισμένες παραμέτρους και τρέχοντα αποτελέσματα μοντελοποίησης.
- Ρύθμιση ενός μπλοκ ή μιας ομάδας μπλοκ χρησιμοποιώντας μια γλώσσα προγραμματισμού δέσμης ενεργειών. Οι αλλαγές στη βάση δεδομένων σημάτων οδηγούν σε αλλαγές στις τιμές των ιδιοτήτων μπλοκ στο διάγραμμα.
- Αποθήκευση περιγραφών κειμένου, συνδέσμων προς στοιχεία τεχνικών προδιαγραφών ή αναγνωριστικών στο σύστημα διαχείρισης απαιτήσεων.
Οι δομές βάσης δεδομένων σημάτων για απαιτήσεις μπορούν εύκολα να διαμορφωθούν ώστε να λειτουργούν με ένα σύστημα διαχείρισης απαιτήσεων τρίτου μέρους. Ένα γενικό διάγραμμα αλληλεπίδρασης με συστήματα διαχείρισης απαιτήσεων παρουσιάζεται στην Εικόνα 11.
Εικόνα 11. Διάγραμμα αλληλεπίδρασης με το σύστημα διαχείρισης απαιτήσεων.
Η ακολουθία αλληλεπίδρασης μεταξύ του έργου δοκιμής SimInTech και του συστήματος ελέγχου απαιτήσεων είναι η εξής:
- Οι όροι αναφοράς αναλύονται σε απαιτήσεις.
- Προσδιορίζονται οι απαιτήσεις των τεχνικών προδιαγραφών που μπορούν να επαληθευτούν με μαθηματική μοντελοποίηση τεχνικών διαδικασιών.
- Τα χαρακτηριστικά των επιλεγμένων απαιτήσεων μεταφέρονται στη βάση δεδομένων σημάτων SimInTech στη δομή τυπικών μπλοκ (για παράδειγμα, μέγιστη και ελάχιστη θερμοκρασία).
- Κατά τη διαδικασία υπολογισμού, τα δεδομένα δομής μεταφέρονται σε διαγράμματα σχεδιασμού μπλοκ, πραγματοποιείται ανάλυση και τα αποτελέσματα αποθηκεύονται σε μια βάση δεδομένων σημάτων.
- Μόλις ολοκληρωθεί ο υπολογισμός, τα αποτελέσματα της ανάλυσης μεταφέρονται στο σύστημα διαχείρισης απαιτήσεων.
Τα βήματα 3 έως 5 των απαιτήσεων μπορούν να επαναληφθούν κατά τη διάρκεια της διαδικασίας σχεδιασμού, όταν προκύψουν αλλαγές στη σχεδίαση ή/και απαιτήσεις και ο αντίκτυπος των αλλαγών πρέπει να επανεξεταστεί.
Συμπεράσματα.
- Το δημιουργημένο πρωτότυπο του συστήματος παρέχει σημαντική μείωση του χρόνου ανάλυσης των υπαρχόντων μοντέλων για συμμόρφωση με τις απαιτήσεις των τεχνικών προδιαγραφών.
- Η προτεινόμενη τεχνολογία δοκιμών χρησιμοποιεί ήδη υπάρχοντα δυναμικά μοντέλα και μπορεί να χρησιμοποιηθεί ακόμη και για οποιαδήποτε δυναμικά μοντέλα, συμπεριλαμβανομένων εκείνων που δεν εκτελούνται στο περιβάλλον SimInTech.
- Η χρήση της οργάνωσης δεδομένων παρτίδας σάς επιτρέπει να δημιουργείτε πακέτα επαλήθευσης απαιτήσεων παράλληλα με την ανάπτυξη μοντέλων ή ακόμη και να χρησιμοποιείτε αυτά τα πακέτα ως τεχνικές προδιαγραφές για την ανάπτυξη μοντέλων.
- Η τεχνολογία μπορεί να ενσωματωθεί στα υπάρχοντα συστήματα διαχείρισης απαιτήσεων χωρίς σημαντικό κόστος.
Για όσους διαβάσουν μέχρι το τέλος,
Πηγή: www.habr.com