FMI και η ίδια προσομοίωση παντού
Το μοντέλο δεν πρέπει να αναπτύσσει προσωπικότητα
Ένα μοντέλο προσομοίωσης πρέπει να είναι βαρετό με έναν πολύ συγκεκριμένο τρόπο: ίδια είσοδος, ίδιο μοντέλο, ίδια έξοδος. Αυτό ακούγεται προφανές μέχρι το μοντέλο να μετακινηθεί από έναν σταθμό εργασίας σε ένα σύμπλεγμα υπολογιστών, από έναν φορητό υπολογιστή σε hardware-in-the-loop, από έναν μεταγλωττιστή σε άλλον, ή από ένα εργαλείο προμηθευτή σε ένα γραφείο ασφάλειας που δεν εκτιμά τον ερμηνευτικό χορό. Τότε οι μικροσκοπικές αριθμητικές διαφορές γίνονται συσκέψεις. Οι συσκέψεις γίνονται υπολογιστικά φύλλα συμφωνίας. Τα υπολογιστικά φύλλα συμφωνίας γίνονται το νεκροταφείο όπου πεθαίνουν τα καλά απογεύματα μηχανικής.
Το FMI υπάρχει για να κάνει την ανταλλαγή μοντέλων και τη συν-προσομοίωση πρακτική μεταξύ εργαλείων. Η Διεπαφή Functional Mock-up δίνει στις ομάδες έναν τυποποιημένο τρόπο να συσκευάζουν και να εκτελούν μοντέλα αντί να μεταφέρουν με το χέρι εύθραυστο κώδικα ενοποίησης από το ένα περιβάλλον προσομοίωσης στο επόμενο. Αυτό είναι ήδη χρήσιμο. Αλλά μια τυποποιημένη διεπαφή δεν κάνει αυτόματα την αριθμητική ντετερμινιστική. Οι παραδοσιακές ροές εργασίας FMI συχνά στηρίζονται στη συμπεριφορά κινητής υποδιαστολής IEEE 754, στις βιβλιοθήκες πλατφόρμας, στις επιλογές μεταγλωττιστή, στη σειρά εκτέλεσης και στις διαφορές παρασκηνίου. Τις περισσότερες φορές αυτό είναι εντάξει. Μετά δεν είναι εντάξει, και η διαφορά συνήθως ανακαλύπτεται από κάποιον με προθεσμία και ένα πρόσωπο που λέει ότι οι προμήθειες υποσχέθηκαν ότι αυτό θα ήταν εύκολο.
Το Dweve FMI επιτίθεται στο βαρετό, ακριβό μέρος: την αναπαραγωγιμότητα. Ο ιστότοπος περιγράφει μια υλοποίηση FMI σε Rust για Model Exchange και Co-Simulation με ντετερμινιστική αριθμητική σταθερής υποδιαστολής, χτισμένη πάνω στο Numerus. Η μορφή της υλοποίησης είναι ευρύτερη από ένα demo: ένας χώρος εργασίας FMI πολλαπλών crates με αναπαράσταση μοντέλου, ανάλυση σχήματος, εισαγωγή, εξαγωγή, χρόνο εκτέλεσης, επιλυτή, ενορχήστρωση, μνήμη, παρασκήνια για CPU, GPU, FPGA, edge και κατανεμημένη εκτέλεση, FFI, fuzzing, σημεία αναφοράς, τεκμηρίωση και δοκιμές. Εξαρτάται από τα crates Numerus για αριθμητική σταθερής υποδιαστολής και δεκαδική αριθμητική, συν τη κοινή στοίβα Dweve για προσομοίωση, καταγραφή, διαχείριση σφαλμάτων, μεταφορά, τανυστές και αποθήκευση.
Ο στόχος δεν είναι να ακούγεται μυστικιστική η προσομοίωση. Ο στόχος είναι να σταματήσει το ίδιο FMU να λέει ελαφρώς διαφορετικές ιστορίες επειδή ξύπνησε σε διαφορετική μηχανή.
Το FMI δίνει τον φάκελο, η αριθμητική εξακολουθεί να γράφει την επιταγή
Ένα FMU είναι ένας χρήσιμος φάκελος. Μεταφέρει μια περιγραφή μοντέλου, δυαδικά αρχεία ή τεχνουργήματα πηγαίου κώδικα, πόρους, μεταβλητές, καταστάσεις, ρολόγια, εξαρτήσεις και αρκετά μεταδεδομένα για να μπορέσει ένα άλλο εργαλείο να δημιουργήσει και να εκτελέσει το μοντέλο. Το FMI 3.0 προσθέτει πλουσιότερα ρολόγια, προγραμματισμένη εκτέλεση, βελτιωμένη πληκτρολόγηση μεταβλητών και μηχανισμούς συν-προσομοίωσης. Ο πηγαίος κώδικας του Dweve FMI είναι οργανωμένος γύρω από αυτόν τον φάκελο: το fmi-schema αναλύει και επικυρώνει περιγραφές μοντέλων, το fmi-import φορτώνει αρχεία FMU, το fmi-export δημιουργεί αρχεία, το fmi-model αναπαριστά μεταβλητές και κατάσταση μοντέλου, και το fmi-runtime κατέχει τον κύκλο ζωής, την πρόσβαση σε μεταβλητές, τα ρολόγια, τα συμβάντα, τις παραγώγους και την αποθήκευση ή επαναφορά κατάστασης.
Αυτός ο φάκελος είναι απαραίτητος, αλλά δεν είναι επαρκής. Η αριθμητική από κάτω εξακολουθεί να αποφασίζει αν μια εκτέλεση είναι αναπαραγώγιμη. Η τεκμηρίωση του χρόνου εκτέλεσης λέει ότι η αριθμητική σταθερής υποδιαστολής χρησιμοποιεί το Numerus Q31_32 για ντετερμινιστικό υπολογισμό. Τα μεταδεδομένα του χώρου εργασίας ονομάζουν το Q31.32 ως προεπιλεγμένη μορφή σταθερής υποδιαστολής, το Dec64_6 ως προεπιλεγμένη δεκαδική μορφή και το Q16.16 για τον χρόνο. Η δημόσια σελίδα μιλά για τα προφίλ Q31.32, Q16.16 και Dec64_6, με το MPFR να χρησιμοποιείται ως διαδρομή αναφοράς. Αυτό δίνει στο έργο ένα σαφές συμβόλαιο: η προσομοίωση πραγματικών τιμών θα πρέπει να αντιστοιχίζεται σε ντετερμινιστικά αριθμητικά προφίλ αντί να αφήνει κάθε παρασκήνιο να αυτοσχεδιάζει.
Υπάρχει ένα σημαντικό σημείο ειλικρίνειας εδώ. Τα API και οι επιφάνειες συμβατότητας που απευθύνονται σε FMI ενδέχεται να εξακολουθούν να δέχονται ή να εκπέμπουν τιμές κινητής υποδιαστολής, επειδή το πρότυπο και τα υπάρχοντα εργαλεία τις αναμένουν. Αυτό που έχει σημασία δεν είναι η θεατρική αγνότητα σε κάθε όριο. Αυτό που έχει σημασία είναι ότι ο βασικός ντετερμινιστικός δρόμος είναι χτισμένος γύρω από προφίλ σταθερής υποδιαστολής Numerus και επικύρωση έναντι μιας αναφοράς υψηλής ακρίβειας όπου η σύγκριση έχει νόημα. Οι ακραίοι προσαρμογείς μπορούν να μιλούν την εξωτερική γλώσσα. Η εσωτερική σύμβαση δεν πρέπει να γίνεται ένας ανασήκωμα των ώμων.
Το αριθμητικό προφίλ είναι απόφαση του μοντέλου
Η σταθερή υποδιαστολή δεν είναι μία μαγική ρύθμιση. Ένα μοντέλο που χρειάζεται συμπαγείς τιμές χρόνου, ένα μοντέλο με ευρέα φυσικά εύρη και ένα μοντέλο που αναφέρει δεκαδικές ποσότητες δεν έχουν ταυτόσημες πιέσεις. Τα Q16.16, Q31.32 και Dec64_6 δεν είναι αυτοκόλλητα για μια διαφάνεια. Είναι διαφορετικές συμβάσεις για το εύρος, την ανάλυση, την αναπαράσταση και το πού επιτρέπεται να κατοικούν τα σφάλματα.
Εδώ οι ομάδες προσομοίωσης συχνά γίνονται πολύ πρόχειρες. Αντιμετωπίζουν την αριθμητική συμπεριφορά ως ιδιότητα του εργαλείου και όχι ως ιδιότητα του μοντέλου. Μετά αλλάζει το εργαλείο, ή αλλάζει το backend, ή το μοντέλο ενσωματώνεται, και ξαφνικά η παλιά υπόθεση γίνεται βάρος επικύρωσης. Το Dweve FMI κάνει το αριθμητικό προφίλ μέρος της αρχιτεκτονικής και όχι καιρικό φαινόμενο στο παρασκήνιο. Αυτό είναι λιγότερο εντυπωσιακό από ένα μεγάλο demo. Καλώς. Τα μεγάλα demos σπάνια εξηγούν ποιος κατέχει το όριο στρογγυλοποίησης.
Το crate του επιλυτή λέει την ίδια ιστορία. Εκθέτει χαρακτηριστικά συστημάτων ODE, RK4, RKF45, Euler, διαμόρφωση προσανατολισμένη σε BDF, προσαρμοστικό έλεγχο βήματος, ανίχνευση συμβάντων και ντετερμινιστικό χρόνο επιλυτή. Το crate του runtime κατέχει τον κύκλο ζωής του FMU, τις λειτουργίες συνεχούς χρόνου και συμβάντων, την πρόσβαση σε μεταβλητές, τις παραγώγους εισόδου, τις κατευθυντικές και συζυγείς παραγώγους, την προσωρινή αποθήκευση Jacobian, τα ρολόγια και τη σειριοποίηση κατάστασης. Τίποτα από αυτά δεν είναι χρήσιμο αν το αριθμητικό επίπεδο δεν μπορεί να θεωρηθεί αξιόπιστο όταν μετακινείται μεταξύ υλικού. Ο επιλυτής μπορεί να είναι έξυπνος. Το μοντέλο μπορεί να είναι κομψό. Αν η ίδια εκτέλεση χρειάζεται τρεις συμφιλιώσεις, η κομψότητα είναι κυρίως έπιπλο.
Η συν-προσομοίωση είναι εκεί που τα μικρά ψέματα γίνονται ακριβά
Ένα FMU είναι ήδη αρκετή δουλειά. Πολλά FMU συζευγμένα μεταξύ τους είναι εκεί που τα αριθμητικά και λειτουργικά λάθη γίνονται κοινωνικά. Ένα θερμικό μοντέλο τροφοδοτεί ένα μοντέλο ελέγχου, το μοντέλο ελέγχου τροφοδοτεί ένα μοντέλο ενεργοποιητή, το μοντέλο ενεργοποιητή τροφοδοτεί ένα μηχανικό μοντέλο, και όλοι ελπίζουν ότι η σειρά των βημάτων δεν δημιουργεί σιωπηλά ανοησίες. Η συν-προσομοίωση χρειάζεται διαχείριση συνδέσεων, σειρά εκτέλεσης, ανταλλαγή δεδομένων, συντονισμό βημάτων, χειρισμό αλγεβρικών βρόχων και έναν τρόπο να πει όχι όταν το γράφημα είναι λάθος.
Η πηγή έχει το fmi-orchestration για αυτή τη δουλειά. Χειρίζεται συν-προσομοίωση πολλαπλών FMU, συνδέσεις, ανίχνευση κύκλων, τοπολογική ταξινόμηση, προγραμματισμό κατατμήσεων, ανίχνευση και επίλυση αλγεβρικών βρόχων, ιστορικό τιμών, σειρά εκτέλεσης, χρόνο προσομοίωσης και στατιστικά ενορχήστρωσης. Υπάρχει το fmi-cc για επικοινωνία μεταξύ συζευγμένων FMU και το fmi-dist για κατανεμημένη εκτέλεση με συντονιστές, καταχώριση κόμβων, μηνύματα, αιτήματα βημάτων, αποκρίσεις βημάτων και τιμές κατάστασης. Αυτό είναι το είδος του μηχανισμού που οι άνθρωποι ξεχνούν όταν λένε ότι η ενοποίηση είναι απλώς η σύνδεση εξόδων με εισόδους. Είναι καλωδίωση, ναι. Είναι επίσης χρονισμός, διαχείριση εξαρτήσεων, κατάσταση, αποτυχία και απόδειξη ότι η καλωδίωση έκανε αυτό που έλεγε.
Η συν-προσομοίωση καθιστά επίσης την ντετερμινιστικότητα πιο σημαντική, όχι λιγότερο. Αν ένα FMU αποκλίνει ελαφρώς και αυτή η τιμή τροφοδοτεί ένα άλλο FMU, η διαφωνία μπορεί να διαδοθεί. Αν η σειρά εκτέλεσης αλλάξει μεταξύ κόμβων, η διαφωνία μπορεί να κρυφτεί μέχρι ένα μεταγενέστερο βήμα. Αν ένα backend χρησιμοποιεί μια ελαφρώς διαφορετική μαθηματική διαδρομή, η διαφωνία μπορεί να μοιάζει με συμπεριφορά μοντέλου. Έτσι οι ομάδες καταλήγουν να διορθώνουν φυσική με πρακτικά συσκέψεων. Κανείς δεν θα έπρεπε να χρειάζεται να το κάνει αυτό, εκτός αν έχει υπάρξει πολύ κακός σε προηγούμενη ζωή.
Τα backends είναι επιλογές ανάπτυξης, όχι νέες αλήθειες
Το δέντρο πηγαίου κώδικα διαχωρίζει τους στόχους εκτέλεσης σε crates backends: CPU, GPU, FPGA, edge και κατανεμημένο. Το backend edge εστιάζει σε συσκευές με περιορισμούς, περιορισμένη μνήμη και χαμηλό κόστος. Το backend FPGA αφορά αριθμητική σταθερής υποδιαστολής, μεταφορές DMA, διαχείριση bitstream, εκτέλεση πυρήνα και hardware-in-the-loop. Το κατανεμημένο crate συντονίζει πολλούς κόμβους. Η δημόσια σελίδα περιγράφει τις διαδρομές CPU SIMD, GPU, FPGA, edge και κατανεμημένη. Αυτό δεν σημαίνει ότι κάθε στόχος είναι εξίσου ώριμος για κάθε φόρτο εργασίας. Σημαίνει ότι η αρχιτεκτονική αντιμετωπίζει την επιλογή backend ως ζήτημα πρώτης τάξης.
Η βασική αρχή σχεδιασμού είναι ότι η ανάπτυξη θα πρέπει να αλλάζει το πού εκτελείται η προσομοίωση, όχι το τι σημαίνει η προσομοίωση. Μια διαδρομή CPU μπορεί να είναι η πιο εύκολη για τη συγγραφή και την επαλήθευση. Μια διαδρομή GPU μπορεί να έχει νόημα για μεγάλους παράλληλους φόρτους εργασίας. Μια διαδρομή FPGA μπορεί να χρειάζεται για real-time ή hardware-in-the-loop. Μια διαδρομή edge μπορεί να χρειάζεται κοντά στο μηχάνημα. Η κατανεμημένη εκτέλεση μπορεί να χρειάζεται για μεγάλα συζευγμένα συστήματα. Αυτές είναι επιχειρησιακές επιλογές. Δεν θα πρέπει να δημιουργούν μια νέα αριθμητική ταυτότητα για το μοντέλο.
Εδώ είναι επίσης που έχει σημασία το ανοιχτό λογισμικό. Στην ασφάλεια, την ενέργεια, τη ρομποτική, τις ιατρικές συσκευές, την αυτοκινητοβιομηχανία, την αεροδιαστημική, τον βιομηχανικό έλεγχο και τα ψηφιακά δίδυμα, οι ισχυρισμοί αναπαραγωγιμότητας δεν μπορούν να ζουν μόνο σε διαφάνειες προμηθευτών. Κάποιος πρέπει να επιθεωρήσει την υλοποίηση, να καθορίσει μια έκδοση, να εκτελέσει τις δοκιμές, να διαβάσει τις περιπτώσεις αποτυχίας και να αποφασίσει αν τα στοιχεία είναι αρκετά καλά. Μια υλοποίηση FMI ανοιχτού κώδικα δίνει στις ομάδες καλύτερη διαδρομή προς αυτά τα στοιχεία. Δεν πιστοποιεί μαγικά τίποτα. Κάνει τη δουλειά επιθεωρήσιμη, που είναι το πρώτο χρήσιμο βήμα.
Η επικύρωση θα πρέπει να είναι πύλη, όχι πίνακας ελέγχου
Η ιστορία επικύρωσης του Dweve FMI δεν αφορά μόνο όμορφα ίχνη. Το README και ο ιστότοπος περιγράφουν ελέγχους αναφοράς MPFR, ισοδυναμία μεταξύ backends, ντετερμινιστική αναπαραγωγή, δοκιμές συμμόρφωσης, fuzzing και τυπικές αποτυχίες. Ο πηγαίος κώδικας έχει fmi-test, fmi-fuzz, fmi-bench, fmi-conformance, δοκιμές ιδιοτήτων, harnesses fuzz και σειριοποίηση κατάστασης. Αυτή είναι η σωστή κατεύθυνση. Στην υποδομή προσομοίωσης, η επικύρωση δεν θα πρέπει να είναι ένας πίνακας ελέγχου όπου μια κόκκινη γραμμή φαίνεται ανησυχητική και κάποιος υπόσχεται να την παρακολουθήσει. Θα πρέπει να είναι μια πύλη.
Η πύλη έχει πολλά μέρη. Η εισαγωγή πρέπει να αναλύει σωστά το αρχείο FMU και το modelDescription. Η επικύρωση σχήματος πρέπει να απορρίπτει μη έγκυρους ορισμούς μεταβλητών, εξαρτήσεις, ρολόγια και χαρακτηριστικά. Οι αριθμητικοί έλεγχοι χρειάζονται ένα oracle όταν ο ισχυρισμός είναι ακρίβεια. Η ισοτιμία backend χρειάζεται την ίδια κατάσταση σε όλους τους στόχους εκτέλεσης. Η αναπαραγωγή χρειάζεται αποθηκευμένη κατάσταση και αρχεία καταγραφής συμβάντων για να ανακατασκευάσει την εκτέλεση. Η αποτυχία χρειάζεται τυπικά σφάλματα, όχι μια μυστηριώδη αναφορά αναντιστοιχίας που στέλνει την ομάδα σε εξαντλητική αναζήτηση στα αρχεία καταγραφής. Μια αναντιστοιχία θα πρέπει να μπλοκάρει μια διαδρομή έκδοσης μέχρι να γίνει κατανοητή ή ρητά αποδεκτή. Αυτό ακούγεται σκληρό μόνο αν η εναλλακτική δεν σας έχει χρεώσει ακόμα.
Πού έχει σημασία πρώτα
Οι προφανείς τομείς είναι εκείνοι όπου τα λάθη προσομοίωσης γίνονται φυσικά λάθη: αυτοκινητοβιομηχανία, αεροδιαστημική, βιομηχανικός έλεγχος, ιατρικές συσκευές, ενέργεια, ρομποτική και υποδομές. Ένα μοντέλο φρένων, ένας ελεγκτής αντλίας, ένα μοντέλο δικτύου, ένα ρομποτικό κελί, μια γραμμή παραγωγής ή ένας ελεγκτής HVAC δεν γίνεται ασφαλέστερο επειδή μια παρουσίαση λέει «ψηφιακό δίδυμο». Γίνεται ασφαλέστερο όταν το μοντέλο, οι είσοδοι, το αριθμητικό προφίλ, το backend, η έκδοση και το ίχνος αναπαραγωγής ελέγχονται αρκετά ώστε να μπορούν να διερευνηθούν.
Υπάρχει επίσης μια διάσταση προμηθειών, γιατί φυσικά υπάρχει. Αν κάθε backend απαιτεί ξεχωριστή ιστορία επικύρωσης, κάθε αλλαγή υλικού γίνεται μια μικρή άσκηση επαναπιστοποίησης. Αν το ίδιο FMU μπορεί να αποδειχθεί μία φορά και στη συνέχεια να εκτελεστεί στον στόχο που ταιριάζει στους επιχειρησιακούς περιορισμούς, οι ομάδες αποκτούν ελευθερία χωρίς να προσποιούνται ότι η επικύρωση είναι δωρεάν. Ο ιστότοπος το διατυπώνει ως «απόδειξη μία φορά, εκτέλεση οπουδήποτε». Η μηχανική μετάφραση είναι ελαφρώς λιγότερο ρομαντική: μειώστε τα σημεία όπου το ίδιο μοντέλο μπορεί να διαφωνεί με τον εαυτό του.
Αυτό έχει ιδιαίτερη σημασία στην Ευρώπη. Η κυριαρχία δεν είναι μόνο πού βρίσκεται ο διακομιστής. Είναι επίσης το αν μια υπόθεση ασφάλειας μπορεί να επιθεωρηθεί, να επαναληφθεί και να μετακινηθεί χωρίς να ζητάμε άδεια από έναν προμηθευτή. Μια ανοιχτή υλοποίηση, ντετερμινιστική αριθμητική, αναπαραγώγιμη αναπαραγωγή και ισοτιμία backends δεν λύνουν από μόνα τους την πολιτική. Κάνουν όμως το τεχνικό μέρος λιγότερο εξαρτημένο από ένα μαύρο κουτί με ένα τμήμα πωλήσεων προσαρτημένο.
Τι να ελέγξετε πριν το εμπιστευτείτε
Το πρώτο ερώτημα αναθεώρησης είναι ποιες επιφάνειες FMI 3.0 χρησιμοποιεί πραγματικά το μοντέλο σας. Το Model Exchange, το Co-Simulation, η Scheduled Execution, τα ρολόγια, οι παράγωγοι, τα γεγονότα, οι δυαδικές μεταβλητές, οι συμβολοσειρές, οι πίνακες και οι εξαρτήσεις δεν είναι ο ίδιος φόρτος εργασίας. Ένα απλό FMU και μια συζευγμένη προσομοίωση πολλαπλών FMU ασκούν διαφορετική πίεση στο runtime και στον ενορχηστρωτή.
Το δεύτερο ερώτημα είναι ποιο αριθμητικό προφίλ δηλώνει το μοντέλο και γιατί. Αν η απάντηση είναι «ό,τι προεπιλογή δούλεψε στο παράδειγμα», αυτό δεν είναι σχεδιασμός. Το προφίλ πρέπει να ταιριάζει με το εύρος, την ανάλυση, την αναπαράσταση χρόνου, την ανοχή και τον στόχο ανάπτυξης. Θα πρέπει να είναι αρκετά ορατό ώστε ένας αναθεωρητής να μπορεί να το αμφισβητήσει χωρίς να διαβάσει ολόκληρο τον επιλύτη.
Το τρίτο ερώτημα είναι ποια αποδεικτικά στοιχεία συνοδεύουν ένα αποτέλεσμα. Ποια έκδοση πηγαίου κώδικα; Ποια έκδοση FMU; Ποιο modelDescription; Ποιο προφίλ Numerus; Ποιο backend; Ποιοι έλεγχοι oracle; Ποια κατάσταση αναπαραγωγής; Ποια τεστ συμμόρφωσης ή ιδιοτήτων; Αν αυτές οι απαντήσεις είναι διάσπαρτες σε ένα wiki και στη μνήμη κάποιου, η προσομοίωση δεν είναι ακόμη έτοιμη να θεωρηθεί αξιόπιστη σε μια σοβαρή ροή εργασίας.
Το μάθημα
Το μάθημα του Dweve FMI δεν είναι ότι τα πρότυπα προσομοίωσης είναι βαρετά. Είναι βαρετά με τον ίδιο ακριβώς τρόπο που οι γέφυρες είναι βαρετές όταν στέκονται όρθιες. Το FMI δίνει το περίβλημα ανταλλαγής. Η σταθερή υποδιαστολή με υποστήριξη Numerus δίνει τη ντετερμινιστική αριθμητική στάση. Τα crates runtime και επιλύτη κάνουν το μοντέλο να προχωρά. Η ενορχήστρωση συνδέει τα FMU χωρίς να προσποιείται ότι ο συγχρονισμός είναι τετριμμένος. Τα backends μετακινούν την εκτέλεση στο υλικό που ταιριάζει στη δουλειά. Η επικύρωση μετατρέπει την ομοιότητα σε πύλη αντί για ελπίδα.
Αυτή είναι η δουλειά. Όχι ένας μεγαλειώδης ισχυρισμός ότι τα νούμερα λύθηκαν για πάντα. Όχι ένα λαμπερό demo όπου όλα ταιριάζουν επειδή δοκιμάστηκε μόνο ένα μονοπάτι. Ένα σύστημα προσομοίωσης που γνωρίζει τις μορφές του, δηλώνει το αριθμητικό του συμβόλαιο, εκτελείται σε πολλά backends και αποτυγχάνει ηχηρά όταν το ίδιο μοντέλο παύει να είναι το ίδιο μοντέλο.
Το μοντέλο δεν πρέπει να αναπτύξει προσωπικότητα. Έχουμε αρκετές από αυτές στις συναντήσεις.