Ας πω και εγώ τη γνώμη μου.
Σε προηγούμενα posts έγινε λόγος για την πολυπλοκότητα των σημερινών αεροσκαφών και κατά πόσο αυτή επιδρά στην ασφάλεια των πτήσεων. Εχω πολλές φορές ακούσει την άποψη οτι τα υπολογιστικά συστήματα απλοποιούν τη σχεδίαση και τη δημιουργία ασφαλέστερων αεροσκαφών, άποψη με την οποία διφωνώ. Η αυστηρά προσωπική μου γνώμη είναι πως από τη στιγμή που η διαθέσιμη υπολογιστική ισχύς έγινε τέτοια που να επιτρέπει σε λογικό όγκο και βάρος τον χειρισμό των αλγορίθμων που απαιτούνται για να ελεγχθεί μία πτήση, τότε η πολυπλοκότητα είναι μονόδρομος, ασχέτως της σχεδιαστικής προσέγγισης που επιλεγεί.
Παρατηρήστε ένα F-18 την ώρα που απονειώνεται από τον καταπέλτη ενός αεροπλανοφόρου και δείτε τις επιφάνειες ελέγχου να κάνουν συνεχώς μικροδιορθώσεις στην προσπάθεια να κρατήσουν το αεροσκάφους εντός του φακέλου πτήσης. Οι κινήσεις αυτές είναι αποτέλεσμα των αποφάσεων που παίρνει το λογισμικό πτήσης, αποφάσεις που μεταφράζονται σε ηλεκτρική ισχύ ή/και υδραυλική πίεση για να ελεγχθεί το αεροσκάφος. Αυτό από μόνο του εισάγει έναν τεράστιο βαθμό πολυπλοκότητας όσο και αν ακούγεται απλό. Πρέπει να μετατρέψω ένα ρεύμα της τάξης των nA (δισεκατομυριοστά του Ampere) σε ένα ρεύμα ισχύος ικανής να χειριστεί ένα βηματικό μοτέρ μερικών δεκάδων ίππων ή την ηλεκτροβάνα ελέγχου ενός υδραυλικού συστήματος πίεσης δεκάδων χιλιάδων psi. Ετσι λοιπόν αρχικά πρέπει να μετατρέψω μία ψηφιακή τιμή, γιατί τέτοιες τιμές χειρίζεται και παράγει ο υπολογιστής πτήσης, σε ένα ηλεκτρικό ρεύμα μετατρέποντας το ψηφιακό σήμα σε αναλογικό και μάλιστα αρκετής ισχύος, οπότε πρέπει να έχω έναν σχετικά γρήγορο DAC (Digital to Analog Converter) και ενισχυτικές διατάξεις που να δίνουν την απαιτούμενη ισχύ. Ολα τα παραπάνω πρέπει να λειτουργούν σε ένα ευρύτατο φάσμα θερμοκρασιών και πιέσεων, να λειτουργούν σε μόνιμο καθεστώς μηχανικών ταλαντώσεων με ευρύτατο φάσμα συχνοτήτων, να μονωθούν απέναντι στις στατικές φορτίσεις και στον ηλεκτρομαγνητικό θόρυβο που παράγουν άλλα συστήματα του αεροσκάφους, να έχουν υψηλή αντοχή σε πλήγματα κεραυνών, να έχουν ενσωματωμένους αλγορίθμους αυτοελέγχου και να ειδοποιούν σε περίπτωση δυσλειτουργίας, να είναι ευκόλως προσβάσιμα και επισκευάσιμα, να έχουν απλό και κατανοητό τρόπο αλληλεπίδρασης με το χρήστη αποκλείοντας παρερμηνείες των ενδείξεών τους και σε περίπτωση αστοχίας να βγαίνουν εκτός, αυτόματα ή χειροκίνητα, παραδίδοντας τον έλεγχο στον πιλότο. Αυτά καταλήγουν σε ένα σύνολο εξαρτημάτων εξαιρετικής πολυπλοκότητας αλλά απαραιτήτων αν θέλω να κάνω χρήση υπολογιστών και τα θετικά που αυτοί συνεπάγονται. Και φυσικά δεν έχει να κάνει με την αεροδυναμική προσέγγιση που θα επιλέξω, αν και κάποιες λύσεις απαιτούν περισσότερη υπολογιστική ισχύ από κάποιες άλλες, πχ οι ιπτάμενες πτέρυγες.
Αρα υπολογιστές = πολυπλοκότητα. Οι υπολογιστές μειώνουν το φόρτο του χειριστή και επιτρέπουν σχεδιαστικές προσεγγίσεις που θα ήταν αδύνατες με τα δεδομένα χρονικά όρια αντίδρασης των ανθρωπίνου σώματος, δε μειώνουν όμως την πολυπλοκότητα.
Και μιας και θέλω υπολογιστές στο αεροπλάνο, θέλω και λογισμικό. Σιγά θα μου πείτε. Γράψε το λογισμικό κύριε gkontog, έλεγξέ το και μην κάνεις πολύ φασαρία, να τελειώνουμε. Ωραία, αλλά ας δούμε τι λέει ο Roger Pressman:
For example, consider the 100 line program in the language C. After some basic data declaration, the program contains two nested loops that execute from 1 to 20 times each, depending on conditions specified at input. Inside the interior loop, four if-then-else constructs are required. There are approximately 1014 possible paths that may be executed in this program! To put this number in perspective, we assume that a magic test processor ("magic" because no such processor exists) has been developed for exhaustive testing. The processor can develop a test case, execute it, and evaluate the results in one millisecond. Working 24 hours a day, 365 days a year, the processor would work for 3170 years to test the program. This would, undeniably, cause havoc in most development schedules. Exhaustive testing is impossible for large software systems. Ουπς! 3170 χρόνια για να ελέγξω 100 γραμμούλες κώδικα
Ενα πρόγραμμα ελέγχου αποθήκης και παραγγελιών ξεπερνά τις 100000 γραμμές, ένα λειτουργικό σύστημα είναι μερικά εκατομύρια γραμμές. Ετσι γαι να μη σας κάνει εντύπωση όταν βρίσκεται σφάλματα στα Vista. Αρα η άποψη οτι ο έλεγχος λύνει όλα τα προβλήματα του λογισμικού είναι εσφαλμένη. Οπότε για να ελέγξουμε το λογισμικό, μιας και είναι αδύνατο να ακολουθήσουμε όλα τα μονοπάτια εκτέλεσης (white box testing), αναγκαζόμαστε και δημιουργούμε διαδικασίες ελέγχου για να καλύψουμε τα πλέον πιθανά σενάρια, πχ δεν έχει νόημα να ελέγξω πως θα αντιδράσει το λογσιμικό για τιμές επιτάχυνσης άνω των 12g γιατί οι επιβάτες θα έχουν γίνει μαρμελάδα και το αεροσκάφος σκόνη. Ωραία αλλά όπως αποδεικνύει και ο Mayers στο πολύ καλό The Art of Software Testing (Myers, G., The Art of Software Testing, Wiley, 1979) για κάθε διαδικασία ελέγχου ισχύουν τα παρακάτω:
1. Testing is a process of executing a program with the intent of finding an error.
2. A good test case is one that has a high probability of finding an as-yetundiscovered error.
3. A successful test is one that uncovers an as-yet-undiscovered error.Και να που εισάγεται ο όρος πιθανότητα. Ελέγχω το λογισμικό μου και έχω
πιθανότητες να βρω τα λάθη, ούτε καν τη σιγουριά
Ετσι λοιπόν, με την εισαγωγή των υπολογιστικών συστημάτω στο παιχνίδι η πολυπλοκότητα ΔΕΝ μειώθηκε αλλά αντίθετα, λαμβανομένης υπ' όψη και της αστρονομικής πολυπλοκότητας του λογισμικού, εκτινάχθηκε σε νέα επίπεδα, τάξεις μεγέθους πιο πάνω από την εποχή της μη χρήσης υπολογστικών συστημάτων. Και όλα αυτά ΧΩΡΙΣ να γίνει καμμία αλλαγή στη σχεδιαστική φιλοσοφία των αεροσκαφών.
Σα συμπέρασμα, αυστηρά προσωπικά, μπορώ να πω οτι η πολυπλοκότητα των αεροσκαφών θα αυξάνει συνεχώς και μάλιστα θα ακολουθεί την αύξηση της διαθέσιμης υπολογιστικής ισχύος. Δεν μπορούμε όμως να την κατηγορήσουμε ως παράγοντα μείωσης της ασφαλείας των πτήσεων, ούτε οτι οφείλεται σε συγκεκριμένες σχεδιαστικές λύσεις.
Και αν σας ενδιαφέρει το αντικείμενο, αγοράστε τη "βίβλο" και θα δείτε το λογισμικό με άλλο μάτι...
[amazon]http://www.amazon.com/Software-Engineering-Practitioners-Approach-5th/dp/0073655783/ref=sr_11_1?ie=UTF8&qid=1204652332&sr=11-1[/amazon]
Και για να πιστέψετε οτι δεν υπάρχει λογισμικό χωρίς λάθη, ούτε καν αυτό που ελέγχει αεροσκάφη:
[amazon]http://www.amazon.com/Art-Software-Testing-Second/dp/0471469122/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1204652412&sr=1-1[/amazon]
