Παρουσιάστηκε η κριτική συγκριτικά χαρακτηριστικάΤο RTOS είναι παρόν στη ρωσική αγορά, σε σχέση με τη χρήση σε συστήματα ελέγχου αεροπορίας.

05/05/2008, Δευτέρα, 23:56, ώρα Μόσχας

Χάρη στην ανάπτυξη της τεχνολογίας υπολογιστών στο ΠρόσφαταΈχει καταστεί δυνατή η ανάθεση εργασιών σε μία μονάδα που εκτελούνταν προηγουμένως από πολλές μονάδες επεξεργαστή, βελτιώνοντας παράλληλα τα χαρακτηριστικά βάρους και μεγέθους του συστήματος ελέγχου και μειώνοντας το κόστος του. Αυτή η τάση στην τεχνολογία της αεροπορίας οδήγησε στην εμφάνιση της έννοιας των ολοκληρωμένων αρθρωτών αεροηλεκτρονικών συστημάτων - IMA (Integrated Modular Avionics, IMA).

Το πρόβλημα της ενσωμάτωσης των λειτουργιών ελέγχου σε μια ενιαία μονάδα είναι ότι είναι απαραίτητο να διαχωριστεί το τώρα κοινόχρηστους πόρους(χρόνος επεξεργαστή, μνήμη, κανάλια επικοινωνίας) μεταξύ διαφορετικών εργασιών, παρέχοντας παράλληλα το ίδιο επίπεδο αξιοπιστίας και ανεξαρτησίας λειτουργιών με πριν. Το λειτουργικό σύστημα σε πραγματικό χρόνο παίζει βασικό ρόλο στην επίλυση αυτού του προβλήματος.

Επί του παρόντος, υπάρχουν πολλά εμπορικά RTOS για κρίσιμες εφαρμογές στην παγκόσμια αγορά (Πίνακας 1). Αυτό το άρθρο παρέχει μια επισκόπηση των RTOS που είναι διαθέσιμα στη ρωσική αγορά, με βάση πληροφορίες από ανοιχτές πηγές και προσωπική εμπειρίασυγγραφείς.

Έγγραφα που ρυθμίζουν τις απαιτήσεις για RTOS

Το πρότυπο DO-178 (Software Consideration in Airborne Systems and Equipment Certification) καθορίζει τις απαιτήσεις για τη διαδικασία ανάπτυξης λογισμικού και την πληρότητα της επαλήθευσής του ανάλογα με το επίπεδο κρισιμότητας. Το επίπεδο κρισιμότητας του λογισμικού καθορίζεται με βάση μια ανάλυση της σοβαρότητας των συνεπειών μιας αποτυχίας λογισμικού. Υπάρχουν πέντε επίπεδα κρισιμότητας λογισμικού συνολικά (από το Α έως το Ε).

Το MILS (Πολλαπλά Ανεξάρτητα Επίπεδα Ασφάλειας) είναι μια ειδική προσέγγιση στο σχεδιασμό του λειτουργικού συστήματος που αποτρέπει τη διάδοση σφαλμάτων λογισμικού εφαρμογών κατά τη διάρκεια του χρόνου εκτέλεσης και επίσης απλοποιεί την επαλήθευση του προγράμματος λόγω της σπονδυλωτότητας του λογισμικού. Όλες οι εφαρμογές τοποθετούνται στις λεγόμενες ενότητες (partitions). Τα διαμερίσματα έχουν κατανείμει πόρους (περιοχή μνήμης, χρόνος επεξεργαστή κατά τη διάρκεια κάθε κύκλου συστήματος, πρόσβαση σε κανάλια επικοινωνίας κ.λπ.). Η πρόσβαση στους κατανεμημένους πόρους είναι εγγυημένη από το λειτουργικό σύστημα που εκτελείται σε λειτουργία επόπτη. Έτσι, το λογισμικό εφαρμογών διαφορετικών επιπέδων κρισιμότητας μπορεί να εκτελεστεί σε μία μονάδα επεξεργαστή που εκτελεί ένα λειτουργικό σύστημα - εάν συμβεί βλάβη σε λιγότερο κρίσιμο (και, κατά συνέπεια, λιγότερο δοκιμασμένο) λογισμικό, αυτό δεν θα επηρεάσει σε καμία περίπτωση τη λειτουργία άλλων ενοτήτων, καθώς απόπειρες «σφαιρετισμού» πόρων άλλων ανθρώπων θα αποκλειστούν από το λειτουργικό σύστημα. Οι ιδέες του MILS απηχούν εκείνες του IMA και του DO-178B.

Σφάλμα 404: Δεν είναι δυνατή η εύρεση της σελίδας.

Αυτό μπορεί να συνέβη για έναν από τους εξής λόγους:

– σφάλμα κατά την πληκτρολόγηση της διεύθυνσης σελίδας (URL)
– ακολουθώντας έναν «σπασμένο» (δεν λειτουργεί, λανθασμένο) σύνδεσμο
– η σελίδα που ζητήσατε δεν ήταν ποτέ στον ιστότοπο ή διαγράφηκε

Μπορείς:

– επιστρέψτε χρησιμοποιώντας το κουμπί Πίσω του προγράμματος περιήγησης
– ελέγξτε τη σωστή ορθογραφία της διεύθυνσης της σελίδας (URL)
– χρησιμοποιήστε τον χάρτη τοποθεσίας ή μεταβείτε στην κύρια σελίδα

Το πρότυπο ARINC-653 (Avionics Application Software Standard Interface) καθορίζει μια διεπαφή λογισμικού εφαρμογής APEX που υποστηρίζει μια ιδέα διαμερισμάτων τύπου MILS. Αυτή η διεπαφή περιλαμβάνει λειτουργίες διαχείρισης κατατμήσεων, διεργασιών, κοινής χρήσης χρόνου, επικοινωνιών μεταξύ και εντός διαμερισμάτων και παρακολούθησης της κατάστασης του συστήματος. Θα πρέπει να σημειωθεί ότι το πρότυπο ARINC-653 περιγράφει μια γενικά αποδεκτή προσέγγιση για την υλοποίηση ιδεών MILS για το IMA, αν και μπορεί να υπάρχουν και άλλες υλοποιήσεις. Ένα αεροπορικό RTOS που συμμορφώνεται με το ARINC-653 έχει πλεονεκτήματα επειδή αυτό το πρότυπο είναι ευρέως γνωστό και κατανοητό από τους διεθνείς οργανισμούς πιστοποίησης, επομένως είναι ευκολότερο να αποκτήσετε πιστοποιητικό συμμόρφωσης DO-178B για ένα σύστημα κατασκευασμένο σύμφωνα με αυτό το πρότυπο.

Πρότυπο επαναχρησιμοποιήσιμων εξαρτημάτων λογισμικού. Σύμφωνα με το DO-178B, το λογισμικό ενός συγκεκριμένου συστήματος αεροπορικών εφαρμογών υποβάλλεται σε ολόκληρη τη διαδικασία πιστοποίησης, ακόμη και αν χρησιμοποιεί ενότητες (εξαρτήματα) που έχουν ήδη πιστοποιηθεί προηγουμένως ως μέρος άλλου συστήματος. Μία από τις πιο πρόσφατες πρωτοβουλίες της FAA (Federal Aviation Certification Agency, ΗΠΑ) είναι ο καθορισμός κριτηρίων για την επαναχρησιμοποίηση λογισμικού χωρίς επαναπιστοποίηση. Τα στοιχεία που ενδέχεται να μην επαναπιστοποιηθούν ονομάζονται RSC (Reusable Software Components). Χρειάζεται περισσότερη προσπάθεια για να αποκτήσετε πιστοποίηση RSC, αλλά στη συνέχεια η RSC παρέχει σημαντική εξοικονόμηση πόρων.

Ρωσικά έγγραφα που καθορίζουν τις απαιτήσεις λογισμικού (συμπεριλαμβανομένου του RTOS):

• GOST R ISO/IEC 51904-2002 («Λογισμικό για ενσωματωμένα συστήματα. Γενικές Προϋποθέσειςγια ανάπτυξη και τεκμηρίωση") - ένα ανάλογο του DO-178B για στρατιωτική αεροπορία.
• KT-178A ("Προϋποθέσεις προσόντων μέρος 178A") - ένα ανάλογο του DO-178B για την πολιτική αεροπορία.
• GOST R ISO/IEC 12207-99 ("Τεχνολογία πληροφοριών. Διαδικασίες κύκλος ζωής λογισμικό").

Η σύγκριση του RT OS πραγματοποιήθηκε σύμφωνα με 13 παραμέτρους, οι οποίες λαμβάνουν υπόψη τεχνικά κριτήρια, ευκολία ανάπτυξης και οικονομικές παραμέτρους.

Παράμετροι χρονισμού του λειτουργικού συστήματος

Μία από τις κύριες απαιτήσεις για το RT OS είναι ο ελάχιστος χρόνος καθυστέρησης για την επεξεργασία ενός συμβάντος. Στην πράξη, αυτό σημαίνει ότι οι ακόλουθες παράμετροι πρέπει να είναι μικρές:

• χρόνος απόκρισης διακοπής - ο χρόνος μεταξύ της πραγματικής εμφάνισης της διακοπής και της έναρξης της επεξεργασίας της πρώτης εντολής του χειριστή διακοπής.
• έλεγχος χρόνου μεταγωγής νήματος - χρόνος εναλλαγής μεταξύ δύο νημάτων σε μία διαδικασία.
• χρόνος εναλλαγής περιβάλλοντος διεργασίας (μόνο για λειτουργικά συστήματα που υποστηρίζουν το μοντέλο διεργασίας) - χρόνος εναλλαγής μεταξύ δύο νημάτων ελέγχου που ανήκουν σε δύο διαφορετικές διεργασίες.

Δυστυχώς, δεν είναι εύκολο να συγκρίνουμε αντικειμενικά αυτές τις παραμέτρους διαφορετικών λειτουργικών συστημάτων RT, επειδή αυτές οι παράμετροι εξαρτώνται όχι μόνο από την ποιότητα του λειτουργικού συστήματος, αλλά και από τις δυνατότητες της πλατφόρμας υλικού που χρησιμοποιείται. Στην ιδανική περίπτωση, όλα τα λειτουργικά συστήματα που συγκρίνονται θα πρέπει να είναι εγκατεστημένα στην ίδια πλατφόρμα υλικού, μετά την οποία θα πρέπει να γίνονται οι κατάλληλες μετρήσεις. Αλλά ακόμη και αυτές οι μετρήσεις δεν θα δώσουν ένα αντικειμενικό αποτέλεσμα, επειδή διαφορετικά λειτουργικά συστήματα μπορούν λίγο πολύ να προσαρμοστούν σε συγκεκριμένο υλικό.

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

Τα αποτελέσματα που προέκυψαν από τους ειδικούς του περιοδικού Dedicated System, οι οποίοι πραγματοποίησαν δοκιμές και πρακτική σύγκριση QNX RTOS 6.1, VxWorks AE 1.1 και Windows CE.NET στην πλατφόρμα x86. Αν και αυτά τα δεδομένα είναι επί του παρόντος ξεπερασμένα, οι συντάκτες αυτού του άρθρου δεν μπόρεσαν να βρουν πιο πρόσφατο υλικό. Στον πίνακα Το Σχήμα 2 δείχνει επιλεγμένα δεδομένα σύγκρισης απόδοσης μεταξύ του QNX Neutrino 6.1 και του VxWorks AE 1.1. Η αναφορά Dedicated Systems προτιμούσε το QNX ως προς την απόδοση, με την αναλογία βαθμολογίας να ορίζεται στο 9:5 (QNX:VxWorks), επειδή κατά τη διάρκεια της δοκιμής ανακαλύφθηκαν δύο σφάλματα στο VxWorks, για τα οποία ήταν απαραίτητο να επικοινωνήσετε με την υποστήριξη για τη διόρθωσή τους.

Στον πίνακα 3 δείχνει δεδομένα για τα χαρακτηριστικά του LynxOS. Η σύνθεση των δοκιμών που χρησιμοποιήθηκαν δεν προσδιορίζεται. Όσον αφορά τα δεδομένα για τα χαρακτηριστικά του LynxOS, η τέταρτη στήλη (δοκιμή στην πλατφόρμα x86) είναι ενδιαφέρουσα. Σε σύγκριση με το VxWorks και το QNX, το LynxOS RT OS παρουσιάζει τεράστια καθυστέρηση στην απόκριση σε διακοπές (πάνω από 5 φορές). Ο χρόνος εναλλαγής περιβάλλοντος (που σημαίνει ο χρόνος εναλλαγής μεταξύ δύο νημάτων σε μία διεργασία) είναι ίδιος με το QNX και είναι περίπου 1,5 φορές μικρότερος από το VxWorks.

Σταθερότητα παραμέτρων χρονισμού

Εκτός από τα χαρακτηριστικά χρονισμού, η σταθερότητα αυτών των χαρακτηριστικών είναι επίσης σημαντική για το RT OS. Αυτό το κριτήριο είναι που καθορίζει σε μεγάλο βαθμό την «ακαμψία» του RT OS, δηλ. προβλεψιμότητα του χρόνου επεξεργασίας δεδομένων, της στιγμής έκδοσης των αποτελεσμάτων κ.λπ.

Με βάση δεδομένα από το αρχείο καταγραφής Dedicated System, το QNX προηγείται του VxWorks σε αυτό το κριτήριο τόσο ως προς την κατανομή των χαρακτηριστικών σε μια σειρά παρόμοιων δοκιμών (ο λόγος του μέγιστου χρόνου προς τη μέση τιμή είναι σημαντικά μικρότερος) όσο και με αυξανόμενο φορτίο (Ο χρόνος εναλλαγής νημάτων όταν ο αριθμός των νημάτων αυξάνεται 2...128 μονάδες για το QNX αυξήθηκε μόνο 1,65 φορές, ενώ για το VxWorks - 2,24 φορές).

Σύμφωνα με δεδομένα που ελήφθησαν από το RTSoft, είναι γνωστό ότι το LynxOS έχει περίπου τα ίδια χαρακτηριστικά με το VxWorks.

Διαχείριση πρόσβασης σε πόρους

Ας αξιολογήσουμε την ποιότητα του ελέγχου πρόσβασης που προσφέρει το ένα ή το άλλο RT OS σε κρίσιμους πόρους του υπολογιστικού συστήματος, όπως η μνήμη και ο χρόνος επεξεργαστή.

Το πρώτο ερώτημα που πρέπει να απαντηθεί είναι εάν το λειτουργικό σύστημα υποστηρίζει το μοντέλο διαδικασίας. Μια διεργασία είναι μια λογική οντότητα που κατέχει ένα ή περισσότερα νήματα, τους συσχετιζόμενους πόρους και το πλαίσιο - τα περιεχόμενα των καταχωρητών και των μετρητών ανά πάσα στιγμή.

Το καθήκον των διαδικασιών είναι:

• στην οριοθέτηση της πρόσβασης στη μνήμη RAM μεταξύ διαφορετικών προγραμμάτων κατά την εκτέλεση.
• στην οριοθέτηση του εύρους των καθολικών μεταβλητών κατά τη στιγμή της μεταγλώττισης (κρίσιμο εάν το λογισμικό εφαρμογής είναι γραμμένο στη γλώσσα C, η οποία δεν υποστηρίζει τέτοια οριοθέτηση).

Η τμηματοποίηση παρέχει επίσης διαχωρισμό των χώρων διευθύνσεων (με αυτή την έννοια, οι δυνατότητες διαμοιρασμού και διεργασιών διπλασιάζονται). Επιπλέον, ο διαμοιρασμός παρέχει σε κάθε τμήμα που περιέχει μία ή περισσότερες διεργασίες (ή νήματα εάν το λειτουργικό σύστημα δεν υποστηρίζει το μοντέλο διεργασίας) έναν εγγυημένο προϋπολογισμό χρόνου. Με αυτόν τον τρόπο, εάν ένα νήμα υψηλής προτεραιότητας εισέλθει σε έναν βρόχο και διαταράξει το τμήμα του, όλα τα άλλα τμήματα θα λάβουν χρόνο CPU σύμφωνα με τις ρυθμίσεις χρόνου σχεδίασης και θα συνεχίσουν να λειτουργούν κανονικά.

Το LynxOS και το QNX υποστηρίζουν τόσο το μοντέλο διεργασίας όσο και την κοινή χρήση. Το VxWorks OS διαθέτει μηχανισμό διαμοιρασμού, αλλά δεν υποστηρίζει το μοντέλο διαδικασίας. Σε γενικές γραμμές, αυτό είναι αποδεκτό επειδή η κοινή χρήση παρέχει διαχωρισμό των χώρων διευθύνσεων. Αλλά η έλλειψη διαδικασιών φέρνει κάποιες ενοχλήσεις. Συνήθως, η διαίρεση σε τμήματα πραγματοποιείται με βάση τον επιδιωκόμενο σκοπό του λογισμικού και την κρισιμότητα του. Για παράδειγμα, κάποιο τμήμα μπορεί να περιέχει λογισμικό ελέγχου για ένα σύστημα πλοήγησης πτήσης που έχει υψηλό επίπεδο κρισιμότητας. Αλλά αυτό το λογισμικό είναι επίσης ένα αρκετά περίπλοκο σύνθετο, το οποίο θα ήταν λογικό να χωριστεί σε ανεξάρτητες μονάδες (μνήμης). Το λειτουργικό σύστημα VxWorks δεν παρέχει αυτή τη δυνατότητα, δηλαδή, το τμήμα θα αποτελείται από νήματα με κοινόχρηστη μνήμη, γεγονός που περιπλέκει την οργάνωση της παράλληλης ανάπτυξης και, τελικά, μειώνει την αξιοπιστία του λογισμικού.

Υποστήριξη πολυεπεξεργαστικών και κατανεμημένων συστημάτων

Το κόστος των μονάδων πολλαπλών επεξεργαστών έχει πρόσφατα μειωθεί σημαντικά, και ως εκ τούτου χρησιμοποιούνται όλο και περισσότερο σε ενσωματωμένα συστήματα. Φυσικά, το RT OS πρέπει να παρέχει υποστήριξη για τέτοιες πλακέτες.

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

Το QNX RTOS προσφέρει υποστήριξη για πλακέτες πολλαπλών επεξεργαστών. Για το VxWorks, μια τέτοια υποστήριξη μόλις ανακοινώθηκε. Δεν υπάρχει ακόμα αεροπορική έκδοση του LynxOS με υποστήριξη για πλακέτες πολλαπλών επεξεργαστών.

Όσον αφορά την υποστήριξη για πρωτόκολλα δικτύου, θα πρέπει να σημειωθεί ότι τα RT OS LynxOS, VxWorks και QNX έχουν περίπου ίσες (και ευρείες) δυνατότητες. Ένα επιπλέον πλεονέκτημα του QNX RT OS είναι η ειδική αρχιτεκτονική του υποσυστήματος δικτύου, η οποία διασφαλίζει τη «διαφάνεια» του δικτύου των προγραμμάτων εφαρμογής: κάθε διεργασία μπορεί να καλέσει μια άλλη διεργασία σε μια απομακρυσμένη μονάδα με τον ίδιο τρόπο όπως μια διεργασία σε μια τοπική μονάδα.

Υποστήριξη συστήματος αρχείων

Η δυνατότητα αποθήκευσης πληροφοριών με τη μορφή αρχείων είναι βολική και παραδοσιακή. Αντίθετα, η έλλειψη μιας τέτοιας δυνατότητας δημιουργεί δυσκολίες κατά την αποθήκευση δεδομένων που αλλάζουν σπάνια και τη δημιουργία κατανεμημένων συστημάτων.

Στον πίνακα Το σχήμα 4 δείχνει την υποστήριξη του συστήματος αρχείων για καθένα από τα λειτουργικά συστήματα που εξετάζουμε.

Το QNX έχει την πιο εκτεταμένη υποστήριξη για συστήματα αρχείων. Επιπλέον, το σύστημα αρχείων flash του είναι ανεκτικό σε σφάλματα.

Ποιότητα τεκμηρίωσης

Η ποιότητα της τεκμηρίωσης για τα RT OS LynxOS, VxWorks, QNX είναι αρκετά υψηλή. Ωστόσο, υπάρχουν και παράπονα σχετικά με την τεκμηρίωση:

• Το QNX είναι μια εξαιρετική περιγραφή της αρχιτεκτονικής και των αρχών σχεδιασμού, αλλά μια ανεπαρκής περιγραφή της διεπαφής προγραμματισμού της εφαρμογής (δεν περιγράφονται όλες οι παράμετροι, υπάρχουν ασυνέπειες).
• VxWorks - καμία εξήγηση των αρχών λειτουργίας και ανεπαρκής περιγραφή πολύπλοκη διαδικασίαΔιαμόρφωση λειτουργικού συστήματος.

Ωστόσο, οι εταιρείες εργάζονται για την ποιότητα του υλικού. Η τεκμηρίωση για την τρέχουσα έκδοση του QNX (6.3.2) έχει επεκταθεί σημαντικά και ορισμένα μέρη έχουν επεξεργαστεί εκ νέου.

Ποιότητα τεχνικής υποστήριξης

Όσον αφορά την ποιότητα της επίσημης τεχνικής υποστήριξης, ο αναμφισβήτητος ηγέτης είναι το LynxOS. Το LynuxWorks υπόσχεται να απαντήσει σε οποιαδήποτε τεχνική ερώτηση εντός 4 ωρών από τη δημοσίευση του αιτήματος. Το LynxOS διανέμεται στη Ρωσία από την RTSoft, η οποία διαθέτει μεγάλο προσωπικό ικανό να παρέχει εξειδικευμένη βοήθεια. Το μειονέκτημα του LynxOS είναι ότι το λειτουργικό σύστημα δεν είναι ακόμη πολύ διαδεδομένο στη Ρωσία· συνεπώς, δεν υπάρχει καθιερωμένη κοινότητα χρηστών και δεν υπάρχει καν ένα φόρουμ στη ρωσική γλώσσα.

Το QSS (ο κατασκευαστής του QNX) προσφέρει επίσης καλή τεχνική υποστήριξη, αλλά οι γρήγοροι χρόνοι απόκρισης δεν είναι εγγυημένοι. Σε αντίθεση με το LynxOS, το QNX RT OS έχει μια καλά οργανωμένη κοινότητα χρηστών τόσο στο εξωτερικό όσο και στη Ρωσία. Απαντήσεις στις περισσότερες ερωτήσεις μπορείτε να βρείτε σε αυτά τα φόρουμ. Το QNX στη χώρα μας διανέμεται από την SVD Embedded Systems, οι εργαζόμενοι της οποίας είναι σε θέση να παρέχουν επαρκή τεχνική υποστήριξη και να πραγματοποιούν εργασίες προσαρμογής του λειτουργικού συστήματος σε συγκεκριμένες πλακέτες επεξεργαστών. Επιπλέον, η εταιρεία έχει άμεσες επαφές με την QSS και μπορεί να λάβει συμβουλές για πολύπλοκα ζητήματα από τον προγραμματιστή του QNX RT OS.

Η WindRiver, ο προγραμματιστής του VxWorks, ακολουθεί παραδοσιακά μια κλειστή τεχνική πολιτική, δηλαδή, είναι αρκετά δύσκολο να ληφθούν πληροφορίες σχετικά με τις αρχές λειτουργίας του λειτουργικού συστήματος. Αυτό το λειτουργικό σύστημα δεν διαθέτει επίσης ρωσόφωνο φόρουμ. Το VxWorks RT OS διανέμεται στη χώρα μας από την εταιρεία AVD Systems, η οποία ασχολείται κυρίως με τις πωλήσεις έτοιμων λύσεων λογισμικού και υλικού ξένης προέλευσης.

Ανοιχτή πηγή

Ένα ανοιχτό λειτουργικό σύστημα RT έχει τουλάχιστον τρία πλεονεκτήματα:

• Οι προγραμματιστές λογισμικού εφαρμογών μπορούν να καταλάβουν σύνθετα προβλήματαχωρίς να περιλαμβάνει τεχνική υποστήριξη·
• ευκολότερη πιστοποίηση (χωρίς σελιδοδείκτες κ.λπ.).
• πιο δυναμική ανάπτυξη, καθώς η εταιρεία προγραμματιστών RT OS λαμβάνει συχνά όχι μόνο αιτήματα για διορθώσεις σφαλμάτων, αλλά και προτάσεις για την εξάλειψη σφαλμάτων και τη βελτίωση του συστήματος. Οι κοινότητες προγραμματιστών RTOS ανοιχτού κώδικα, κατά κανόνα, αναπτύσσονται πολύ πιο γρήγορα και είναι καλύτερα οργανωμένες. Ανεξάρτητοι ειδικοί φαίνεται να βοηθούν στην επίλυση των προβλημάτων της υπηρεσίας τεχνικής υποστήριξης και να συμμετέχουν στην ανάπτυξη, τον εντοπισμό σφαλμάτων και τη δοκιμή του συστήματος.

Από τον Σεπτέμβριο του 2007, η QSS έχει ανοιχτού κώδικα τον πυρήνα QNX (συμπεριλαμβανομένου του πακέτου Adaptive Partitioning, High Availability πακέτου). Λίγο αργότερα άνοιξαν οι πηγαίοι κώδικες του υποσυστήματος δικτύου. Επί του παρόντος, η beta έκδοση 6.4.0 είναι διαθέσιμη για λήψη στον επίσημο ιστότοπο.

Θα πρέπει να σημειωθεί ότι σήμερα δεν είναι ανοιχτές όλες οι μονάδες QNX (για παράδειγμα, δεν υπάρχουν κωδικοί για γραφικά και συστήματα αρχείων) και η άδεια επιβάλλει περιορισμό στη χρήση του "πηγαίου κώδικα": μόνο για μη εμπορική χρήση. Ωστόσο, ο χρήστης του QNX λαμβάνει τα παραπάνω οφέλη δωρεάν.

Οι πηγαίοι κώδικες LynxOS και VxWorks είναι διαθέσιμοι στο εμπόριο. Η τιμή για ένα τέτοιο προϊόν είναι συζητήσιμη.

Εργαλεία

Διαθεσιμότητα αγαθών εργαλείακαθορίζει σε μεγάλο βαθμό την ποιότητα και την ταχύτητα ανάπτυξης των προγραμμάτων εφαρμογών για ένα συγκεκριμένο ΛΣ. Θα πρέπει να σημειωθεί ότι τα LynxOS, VxWorks και QNX παρέχουν αυτήν τη στιγμή καλής ποιότηταςεργαλεία που περιλαμβάνουν ολοκληρωμένο περιβάλλον ανάπτυξης (IDE) και εντοπισμό σφαλμάτων λογισμικού εφαρμογών, εργαλεία διαμόρφωσης προφίλ προγραμμάτων (για τον εντοπισμό σημείων συμφόρησης στην απόδοση, τη μνήμη κ.λπ.). Η εργονομία του ISD για αυτά τα RT OS δεν είναι γενικά κατώτερη από τα αναπτυγμένα εργαλεία ανάπτυξης για συμβατικά λειτουργικά συστήματα (για παράδειγμα, MS Windows).

Φορητότητα λογισμικού εφαρμογής

Η φορητότητα του λογισμικού εφαρμογής καθιστά δυνατή τη χρήση του σε άλλα λειτουργικά συστήματα (συμπεριλαμβανομένου του λειτουργικού συστήματος που δεν είναι RT). Η φορητότητα δίνει στον προγραμματιστή λογισμικού εφαρμογών μια ορισμένη ανεξαρτησία από το λειτουργικό σύστημα RT: εάν είναι απαραίτητο, μπορείτε να μεταβείτε σε άλλο λειτουργικό σύστημα με χαμηλό κόστος.

Η δυνατότητα εγγραφής φορητού λογισμικού επί του παρόντος καθορίζεται από τη συμμόρφωση Πρότυπο POSIX. Όλα τα θεωρούμενα λειτουργικά συστήματα RT υποστηρίζουν το πρότυπο POSIX 1003.1. Το LynxOS έχει ένα πλεονέκτημα - αυτό το λειτουργικό σύστημα είναι δυαδικό συμβατό με Linux. Αυτό είναι εφαρμογές Linuxμπορεί να εκτελεστεί στο LynxOS χωρίς επαναμεταγλώττιση. Αντίθετα, οι εφαρμογές LynxOS μπορούν να εκτελεστούν σε Linux (έκδοση 2.4.x με τη βιβλιοθήκη γλώσσας glibs C έκδοση 2.2.2).

Τα υπόλοιπα λειτουργικά συστήματα RT απαιτούν την εκ νέου μεταγλώττιση τους για την εκτέλεση εφαρμογών Linux. Σε αυτήν την περίπτωση, η διαδικασία μεταφοράς ακόμη και εφαρμογών που είναι συμβατές με το POSIX μπορεί συχνά να γίνει αρκετά απαιτητική λόγω διαφορών στην υλοποίηση βιβλιοθηκών και μεταγλωττιστών.

Υποστήριξη αρχιτεκτονικής επεξεργαστή

Οι εγχώριοι προγραμματιστές συστημάτων ελέγχου για την αεροπορία στη σημερινή περίοδο μετάβασης από τα εσωτερικά λειτουργικά συστήματα στα εμπορικά συχνά βρίσκονται σε μια κατάσταση όπου πρέπει να επιλέξουν και να προσαρμόσουν ένα RTOS σε μια υπάρχουσα πλακέτα επεξεργαστή. Σε αυτήν την περίπτωση, ένα από τα βασικά επιχειρήματα κατά την επιλογή ενός λειτουργικού συστήματος είναι η υποστήριξη για την αρχιτεκτονική του επεξεργαστή που χρησιμοποιείται στην πλακέτα.

Συμμόρφωση με τα αεροπορικά πρότυπα

Στην ξένη πρακτική, το λογισμικό για ηλεκτρονικά συστήματα πρέπει να διαθέτει πιστοποιητικό συμμόρφωσης με το πρότυπο DO-178B. Εάν το λογισμικό διαφορετικών επιπέδων κρισιμότητας εκτελείται στην ίδια μονάδα επεξεργαστή, τότε το RTOS που χρησιμοποιείται πρέπει να υποστηρίζει την έννοια των κατατμήσεων. (Διαφορετικά είναι σχεδόν αδύνατο να αποδειχθεί η μη διάδοση του λάθους). Όπως ήδη αναφέρθηκε, είναι καλύτερο η διεπαφή προγραμματισμού RTOS να συμμορφώνεται με το πρότυπο ARINC-653, καθώς το πρότυπο είναι πολύ γνωστό σε ξένους φορείς πιστοποίησης.

Το LynxOS είναι πρωτοπόρος όσον αφορά τη συμμόρφωση με τα πρότυπα. Υποστηρίζει ARINC-653 και υπάρχουν πολλά παραδείγματα συστημάτων με πιστοποίηση DO-178B που είναι κατασκευασμένα σε αυτό. Το βασικό σημείο είναι ότι το LynuxWorks προσφέρει ένα σύνολο RSC (αν και οι συντάκτες του άρθρου δεν γνωρίζουν τίποτα για την τιμή).

Το VxWorks συμμορφώνεται με το πρότυπο ARINC-653 και τα συστήματα που κατασκευάζονται στη βάση του μπορούν να πιστοποιηθούν σύμφωνα με το πρότυπο DO-178B (υπάρχει μεγάλος αριθμόςπαραδείγματα).

Το QNX δεν συμμορφώνεται με το ARINC-653 και δεν υπάρχουν ακόμη συστήματα με πιστοποίηση DO-178B που να βασίζονται σε αυτό.

Θα πρέπει να σημειωθεί ότι τα συστήματα QNX μπορούν καταρχήν να χρησιμοποιηθούν για την κατασκευή ενός IMA, επειδή το QNX υποστηρίζει τη δική του μέθοδο παροχής της ιδέας διαμερισμάτων, η οποία είναι μια πολύ καλή εναλλακτική του ARINC-653 και, επιπλέον, σας επιτρέπει να εξοικονομήσετε χρόνο επεξεργαστή .

Όσον αφορά παρόμοια ρωσικά πρότυπα για τη στρατιωτική αεροπορία (GOST R ISO/IEC 51904-2002), δεν υπάρχει ακόμη ένα παράδειγμα πιστοποιημένου συστήματος, αν και κατ' αρχήν ένα τέτοιο σύστημα μπορεί να αναπτυχθεί με βάση οποιοδήποτε από τα υπό εξέταση ΛΣ. Για το QNX RT OS, επί του παρόντος βρίσκονται σε εξέλιξη εργασίες για την προετοιμασία των κύριων λειτουργικών μονάδων για πιστοποίηση.

Ανάπτυξη του συστήματος εξειδικευμένης εκπαίδευσης

Η ταχύτητα και η ποιότητα της εκπαίδευσης του προσωπικού που εργάζεται με το RT OS και διάφορα εργαλεία ανάπτυξης λογισμικού και εντοπισμού σφαλμάτων σχετίζεται άμεσα με την ταχύτητα ανάπτυξης λογισμικού και την ποιότητά του. Κορυφαίες εταιρείες στον τομέα του ενσωματωμένου λογισμικού και του λογισμικού συστήματος, όπως οι WindRiver, LynuxWorks, QSS, πραγματοποιούν ένα μεγάλο πρόγραμμα μαθημάτων και εκπαιδεύσεων για τη μελέτη της χρήσης των προϊόντων της εταιρείας, συμπεριλαμβανομένου του RT OS.

Αποτελέσματα σύγκρισης

Το QNX Neutrino RTOS είναι το πιο προηγμένο λειτουργικό σύστημα από τεχνική άποψη καλό σετεργαλεία, έχει σχετικά χαμηλή τιμή. Η αρχιτεκτονική του μικροπυρήνα εξασφαλίζει υψηλή αξιοπιστία και σπονδυλωτότητα των ανεπτυγμένων συστημάτων. Ένα επιπλέον πλεονέκτημα είναι ο ανοιχτός κώδικας. Αλλά υπάρχει επίσης μια "μύγα στην αλοιφή": επί του παρόντος το QNX πρακτικά δεν χρησιμοποιείται πουθενά στην αεροπορία και από αυτή την άποψη αυτό το λειτουργικό σύστημα χάνει από τους ανταγωνιστές του (LynxOS και VxWorks). Ένα επιπλέον μειονέκτημα του QNX: μη συμμόρφωση με το πρότυπο ARINC-653.

Πρέπει να σημειωθεί ότι, καταρχήν, το QNX Neutrino διαθέτει όλους τους απαραίτητους μηχανισμούς για εργασία σε συστήματα αεροηλεκτρονικής. Επιπλέον, η αξιοπιστία και η υψηλή διαθεσιμότητα συστημάτων που βασίζονται σε QNX έχει αποδειχθεί σε άλλους κλάδους όπου το κόστος του σφάλματος είναι ακόμη υψηλότερο από ό,τι στην αεροπορία (έλεγχος πυρηνικών αντιδραστήρων).

Η SWD Software πραγματοποιεί εργασίες προετοιμασίας για την πιστοποίηση του QNX Neutrino σύμφωνα με τις απαιτήσεις των εγχώριων αεροπορικών προτύπων.

Το RTOS LynxOS-178, αντίθετα, διαθέτει όλα τα απαραίτητα πιστοποιητικά στο εξωτερικό, αν και σύμφωνα με πολλά άλλα κριτήρια φαίνεται λιγότερο προτιμότερο από το QNX Neutrino. Σημειώστε ότι για χρήση στη ρωσική αεροπορική βιομηχανία, το LynxOS-178 RTOS πρέπει επίσης να είναι πιστοποιημένο σύμφωνα με εγχώριους GOST.

Το VxWorks OS έχει μακρά ιστορία χρήσης σε κρίσιμες εφαρμογές στο εξωτερικό. Ωστόσο, η ανάλυσή μας δείχνει ότι φαίνεται λιγότερο προτιμότερο από τα δύο πρώτα λειτουργικά συστήματα σύμφωνα με πολλά κριτήρια. Επιπλέον, η αξιοπιστία της VxWorks υπονομεύεται από την κλειστή αναπτυξιακή στρατηγική της.

Ομάδα εμπειρογνωμόνων / R&D.CNews

Τυπώνω

Παρουσιάζεται μια επισκόπηση των συγκριτικών χαρακτηριστικών του RT OS που υπάρχει στη ρωσική αγορά σε σχέση με τη χρήση σε συστήματα ελέγχου της αεροπορίας.

Χάρη στην ανάπτυξη της τεχνολογίας υπολογιστών, πρόσφατα κατέστη δυνατή η ανάθεση εργασιών σε μία μονάδα που εκτελούνταν προηγουμένως από πολλές μονάδες επεξεργαστή, βελτιώνοντας παράλληλα τα χαρακτηριστικά βάρους και μεγέθους του συστήματος ελέγχου και μειώνοντας το κόστος του. Αυτή η τάση στην τεχνολογία της αεροπορίας οδήγησε στην εμφάνιση της έννοιας των ολοκληρωμένων αρθρωτών αεροηλεκτρονικών συστημάτων - IMA (Integrated Modular Avionics, IMA).

Το πρόβλημα της ενσωμάτωσης των λειτουργιών ελέγχου σε μια ενιαία μονάδα είναι ότι είναι απαραίτητο να μοιράζονται οι πλέον κοινοί πόροι (χρόνος επεξεργαστή, μνήμη, κανάλια επικοινωνίας) μεταξύ διαφόρων εργασιών, διασφαλίζοντας παράλληλα το ίδιο επίπεδο αξιοπιστίας και ανεξαρτησίας λειτουργιών όπως πριν. Το λειτουργικό σύστημα σε πραγματικό χρόνο παίζει βασικό ρόλο στην επίλυση αυτού του προβλήματος.

Επί του παρόντος, υπάρχουν πολλά εμπορικά RTOS για κρίσιμες εφαρμογές στην παγκόσμια αγορά (Πίνακας 1). Αυτό το άρθρο παρέχει μια επισκόπηση των RTOS που διατίθενται στη ρωσική αγορά, με βάση πληροφορίες από ανοιχτές πηγές και την προσωπική εμπειρία των συγγραφέων.

Έγγραφα που ρυθμίζουν τις απαιτήσεις για RTOS

• Το πρότυπο DO-178 (Software Consideration in Airborne Systems and Equipment Certification) καθορίζει τις απαιτήσεις για τη διαδικασία ανάπτυξης λογισμικού και την πληρότητα της επαλήθευσής του ανάλογα με το επίπεδο κρισιμότητας. Το επίπεδο κρισιμότητας του λογισμικού καθορίζεται με βάση μια ανάλυση της σοβαρότητας των συνεπειών μιας αποτυχίας λογισμικού. Υπάρχουν πέντε επίπεδα κρισιμότητας λογισμικού συνολικά (από το Α έως το Ε).
• Το MILS (Πολλαπλά Ανεξάρτητα Επίπεδα Ασφάλειας) είναι μια ειδική προσέγγιση στο σχεδιασμό του λειτουργικού συστήματος που αποτρέπει τη διάδοση σφαλμάτων λογισμικού εφαρμογών κατά τη διάρκεια του χρόνου εκτέλεσης και επίσης απλοποιεί την επαλήθευση του προγράμματος λόγω της σπονδυλωτότητας του λογισμικού. Όλες οι εφαρμογές τοποθετούνται στις λεγόμενες ενότητες (partitions). Τα διαμερίσματα έχουν κατανείμει πόρους (περιοχή μνήμης, χρόνος επεξεργαστή κατά τη διάρκεια κάθε κύκλου συστήματος, πρόσβαση σε κανάλια επικοινωνίας κ.λπ.). Η πρόσβαση στους κατανεμημένους πόρους είναι εγγυημένη από το λειτουργικό σύστημα που εκτελείται σε λειτουργία επόπτη. Έτσι, το λογισμικό εφαρμογών διαφορετικών επιπέδων κρισιμότητας μπορεί να εκτελεστεί σε μία μονάδα επεξεργαστή που εκτελεί ένα λειτουργικό σύστημα - εάν συμβεί βλάβη σε λιγότερο κρίσιμο (και, κατά συνέπεια, λιγότερο δοκιμασμένο) λογισμικό, αυτό δεν θα επηρεάσει σε καμία περίπτωση τη λειτουργία άλλων ενοτήτων, καθώς απόπειρες «σφαιρετισμού» πόρων άλλων ανθρώπων θα αποκλειστούν από το λειτουργικό σύστημα. Οι ιδέες του MILS απηχούν εκείνες του IMA και του DO-178B.
• Το πρότυπο ARINC-653 (Avionics Application Software Standard Interface) καθορίζει μια διεπαφή λογισμικού εφαρμογής APEX που υποστηρίζει μια ιδέα διαμερισμάτων τύπου MILS. Αυτή η διεπαφή περιλαμβάνει λειτουργίες διαχείρισης κατατμήσεων, διεργασιών, κοινής χρήσης χρόνου, επικοινωνιών μεταξύ και εντός διαμερισμάτων και παρακολούθησης της κατάστασης του συστήματος. Θα πρέπει να σημειωθεί ότι το πρότυπο ARINC-653 περιγράφει μια γενικά αποδεκτή προσέγγιση για την υλοποίηση ιδεών MILS για το IMA, αν και μπορεί να υπάρχουν και άλλες υλοποιήσεις. Ένα αεροπορικό RTOS που συμμορφώνεται με το ARINC-653 έχει πλεονεκτήματα επειδή αυτό το πρότυπο είναι ευρέως γνωστό και κατανοητό από τους διεθνείς οργανισμούς πιστοποίησης, επομένως είναι ευκολότερο να αποκτήσετε πιστοποιητικό συμμόρφωσης DO-178B για ένα σύστημα κατασκευασμένο σύμφωνα με αυτό το πρότυπο.
• Πρότυπο επαναχρησιμοποιήσιμων εξαρτημάτων λογισμικού. Σύμφωνα με το DO-178B, το λογισμικό ενός συγκεκριμένου συστήματος αεροπορικών εφαρμογών υποβάλλεται σε ολόκληρη τη διαδικασία πιστοποίησης, ακόμη και αν χρησιμοποιεί ενότητες (εξαρτήματα) που έχουν ήδη πιστοποιηθεί προηγουμένως ως μέρος άλλου συστήματος. Μία από τις πιο πρόσφατες πρωτοβουλίες της FAA (Federal Aviation Certification Agency, ΗΠΑ) είναι ο καθορισμός κριτηρίων για την επαναχρησιμοποίηση λογισμικού χωρίς επαναπιστοποίηση. Τα στοιχεία που ενδέχεται να μην επαναπιστοποιηθούν ονομάζονται RSC (Reusable Software Components). Χρειάζεται περισσότερη προσπάθεια για να αποκτήσετε πιστοποίηση RSC, αλλά στη συνέχεια η RSC παρέχει σημαντική εξοικονόμηση πόρων.

Ρωσικά έγγραφα που καθορίζουν τις απαιτήσεις λογισμικού (συμπεριλαμβανομένου του RTOS):

• GOST R ISO/IEC 51904-2002 ("Ενσωματωμένο λογισμικό συστημάτων. Γενικές απαιτήσεις για ανάπτυξη και τεκμηρίωση") - ένα ανάλογο του DO-178B για στρατιωτική αεροπορία.
• KT-178A ("Προϋποθέσεις προσόντων μέρος 178A") - ένα ανάλογο του DO-178B για την πολιτική αεροπορία.
• GOST R ISO/IEC 12207-99 («Τεχνολογία πληροφοριών. Διαδικασίες κύκλου ζωής λογισμικού»).

Η σύγκριση του RT OS πραγματοποιήθηκε σύμφωνα με 13 παραμέτρους, οι οποίες λαμβάνουν υπόψη τεχνικά κριτήρια, ευκολία ανάπτυξης και οικονομικές παραμέτρους.

Παράμετροι χρονισμού του λειτουργικού συστήματος

Μία από τις κύριες απαιτήσεις για το RT OS είναι ο ελάχιστος χρόνος καθυστέρησης για την επεξεργασία ενός συμβάντος. Στην πράξη, αυτό σημαίνει ότι οι ακόλουθες παράμετροι πρέπει να είναι μικρές:

• χρόνος απόκρισης διακοπής - ο χρόνος μεταξύ της πραγματικής εμφάνισης της διακοπής και της έναρξης της επεξεργασίας της πρώτης εντολής του χειριστή διακοπής.
• έλεγχος χρόνου μεταγωγής νήματος - χρόνος εναλλαγής μεταξύ δύο νημάτων σε μία διαδικασία.
• χρόνος εναλλαγής περιβάλλοντος διεργασίας (μόνο για λειτουργικά συστήματα που υποστηρίζουν το μοντέλο διεργασίας) - χρόνος εναλλαγής μεταξύ δύο νημάτων ελέγχου που ανήκουν σε δύο διαφορετικές διεργασίες.

Δυστυχώς, δεν είναι εύκολο να συγκρίνουμε αντικειμενικά αυτές τις παραμέτρους διαφορετικών λειτουργικών συστημάτων RT, επειδή αυτές οι παράμετροι εξαρτώνται όχι μόνο από την ποιότητα του λειτουργικού συστήματος, αλλά και από τις δυνατότητες της πλατφόρμας υλικού που χρησιμοποιείται. Στην ιδανική περίπτωση, όλα τα λειτουργικά συστήματα που συγκρίνονται θα πρέπει να είναι εγκατεστημένα στην ίδια πλατφόρμα υλικού, μετά την οποία θα πρέπει να γίνονται οι κατάλληλες μετρήσεις. Αλλά ακόμη και αυτές οι μετρήσεις δεν θα δώσουν ένα αντικειμενικό αποτέλεσμα, επειδή διαφορετικά λειτουργικά συστήματα μπορούν λίγο πολύ να προσαρμοστούν σε συγκεκριμένο υλικό.

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

Αρκετά αντικειμενικά δεδομένα μπορούν να θεωρηθούν τα αποτελέσματα που ελήφθησαν από ειδικούς από το περιοδικό Dedicated System, οι οποίοι πραγματοποίησαν δοκιμές και πρακτική σύγκριση των QNX RTOS 6.1, VxWorks AE 1.1 και Windows CE.NET στην πλατφόρμα x86. Αν και αυτά τα δεδομένα είναι επί του παρόντος ξεπερασμένα, οι συντάκτες αυτού του άρθρου δεν μπόρεσαν να βρουν πιο πρόσφατο υλικό. Στον πίνακα Το Σχήμα 2 δείχνει επιλεγμένα δεδομένα σύγκρισης απόδοσης μεταξύ του QNX Neutrino 6.1 και του VxWorks AE 1.1. Η αναφορά Dedicated Systems προτιμούσε το QNX ως προς την απόδοση, με την αναλογία βαθμολογίας να ορίζεται στο 9:5 (QNX:VxWorks), επειδή κατά τη διάρκεια της δοκιμής ανακαλύφθηκαν δύο σφάλματα στο VxWorks, για τα οποία ήταν απαραίτητο να επικοινωνήσετε με την υποστήριξη για τη διόρθωσή τους.

Στον πίνακα 3 δείχνει δεδομένα για τα χαρακτηριστικά του LynxOS. Η σύνθεση των δοκιμών που χρησιμοποιήθηκαν δεν προσδιορίζεται. Όσον αφορά τα δεδομένα για τα χαρακτηριστικά του LynxOS, η τέταρτη στήλη (δοκιμή στην πλατφόρμα x86) είναι ενδιαφέρουσα. Σε σύγκριση με το VxWorks και το QNX, το LynxOS RT OS παρουσιάζει τεράστια καθυστέρηση στην απόκριση σε διακοπές (πάνω από 5 φορές). Ο χρόνος εναλλαγής περιβάλλοντος (δηλαδή ο χρόνος εναλλαγής μεταξύ δύο νημάτων στην ίδια διαδικασία) είναι ίδιος με το QNX και περίπου 1,5 φορές μικρότερος από το VxWorks.

Σταθερότητα παραμέτρων χρονισμού

Εκτός από τα χαρακτηριστικά χρονισμού, η σταθερότητα αυτών των χαρακτηριστικών είναι επίσης σημαντική για το RT OS. Αυτό το κριτήριο είναι που καθορίζει σε μεγάλο βαθμό την «ακαμψία» του RT OS, δηλ. προβλεψιμότητα του χρόνου επεξεργασίας δεδομένων, της στιγμής έκδοσης των αποτελεσμάτων κ.λπ.

Με βάση δεδομένα από το περιοδικό Dedicated System, το QNX προηγείται του VxWorks σε αυτό το κριτήριο τόσο ως προς την κατανομή των χαρακτηριστικών σε μια σειρά παρόμοιων δοκιμών (ο λόγος του μέγιστου χρόνου προς τη μέση τιμή είναι σημαντικά μικρότερος) όσο και με αυξανόμενο φορτίο (χρόνος εναλλαγής νημάτων όταν ο αριθμός των νημάτων αυξάνεται από 2 σε 128 μονάδες. Το QNX αυξήθηκε μόνο 1,65 φορές, ενώ το VxWorks αυξήθηκε 2,24 φορές).

Σύμφωνα με δεδομένα που ελήφθησαν από το RTSoft, είναι γνωστό ότι το LynxOS έχει περίπου τα ίδια χαρακτηριστικά με το VxWorks.

Διαχείριση πρόσβασης σε πόρους

Ας αξιολογήσουμε την ποιότητα του ελέγχου πρόσβασης που προσφέρει το ένα ή το άλλο RT OS σε κρίσιμους πόρους του υπολογιστικού συστήματος, όπως η μνήμη και ο χρόνος επεξεργαστή.

Το πρώτο ερώτημα που πρέπει να απαντηθεί είναι εάν το λειτουργικό σύστημα υποστηρίζει το μοντέλο διαδικασίας. Μια διεργασία είναι μια λογική οντότητα που κατέχει ένα ή περισσότερα νήματα, τους συσχετιζόμενους πόρους και το πλαίσιο - τα περιεχόμενα των καταχωρητών και των μετρητών ανά πάσα στιγμή.

Το καθήκον των διαδικασιών είναι:

• στην οριοθέτηση της πρόσβασης στη μνήμη RAM μεταξύ διαφορετικών προγραμμάτων κατά την εκτέλεση.
• στην οριοθέτηση του εύρους των καθολικών μεταβλητών κατά τη στιγμή της μεταγλώττισης (κρίσιμο εάν το λογισμικό εφαρμογής είναι γραμμένο στη γλώσσα C, η οποία δεν υποστηρίζει τέτοια οριοθέτηση).

Η τμηματοποίηση παρέχει επίσης διαχωρισμό των χώρων διευθύνσεων (με αυτή την έννοια, οι δυνατότητες διαμοιρασμού και διεργασιών διπλασιάζονται). Επιπλέον, ο διαμοιρασμός παρέχει σε κάθε τμήμα που περιέχει μία ή περισσότερες διεργασίες (ή νήματα εάν το λειτουργικό σύστημα δεν υποστηρίζει το μοντέλο διεργασίας) έναν εγγυημένο προϋπολογισμό χρόνου. Με αυτόν τον τρόπο, εάν ένα νήμα υψηλής προτεραιότητας εισέλθει σε έναν βρόχο και διαταράξει το τμήμα του, όλα τα άλλα τμήματα θα λάβουν χρόνο CPU σύμφωνα με τις ρυθμίσεις χρόνου σχεδίασης και θα συνεχίσουν να λειτουργούν κανονικά.

Το LynxOS και το QNX υποστηρίζουν τόσο το μοντέλο διεργασίας όσο και την κοινή χρήση. Το VxWorks OS διαθέτει μηχανισμό διαμοιρασμού, αλλά δεν υποστηρίζει το μοντέλο διαδικασίας. Σε γενικές γραμμές, αυτό είναι αποδεκτό επειδή η κοινή χρήση παρέχει διαχωρισμό των χώρων διευθύνσεων. Αλλά η έλλειψη διαδικασιών φέρνει κάποιες ενοχλήσεις. Συνήθως, η διαίρεση σε τμήματα πραγματοποιείται με βάση τον επιδιωκόμενο σκοπό του λογισμικού και την κρισιμότητα του. Για παράδειγμα, κάποιο τμήμα μπορεί να περιέχει λογισμικό ελέγχου για ένα σύστημα πλοήγησης πτήσης που έχει υψηλό επίπεδο κρισιμότητας. Αλλά αυτό το λογισμικό είναι επίσης ένα αρκετά περίπλοκο σύνθετο, το οποίο θα ήταν λογικό να χωριστεί σε ανεξάρτητες μονάδες (μνήμης). Το λειτουργικό σύστημα VxWorks δεν παρέχει αυτή τη δυνατότητα, δηλαδή, το τμήμα θα αποτελείται από νήματα με κοινόχρηστη μνήμη, γεγονός που περιπλέκει την οργάνωση της παράλληλης ανάπτυξης και, τελικά, μειώνει την αξιοπιστία του λογισμικού.

Υποστήριξη πολυεπεξεργαστικών και κατανεμημένων συστημάτων

Το κόστος των μονάδων πολλαπλών επεξεργαστών έχει πρόσφατα μειωθεί σημαντικά, και ως εκ τούτου χρησιμοποιούνται όλο και περισσότερο σε ενσωματωμένα συστήματα. Φυσικά, το RT OS πρέπει να παρέχει υποστήριξη για τέτοιες πλακέτες.

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

Το QNX RTOS προσφέρει υποστήριξη για πλακέτες πολλαπλών επεξεργαστών. Για το VxWorks, μια τέτοια υποστήριξη μόλις ανακοινώθηκε. Δεν υπάρχει ακόμα αεροπορική έκδοση του LynxOS με υποστήριξη για πλακέτες πολλαπλών επεξεργαστών.

Όσον αφορά την υποστήριξη για πρωτόκολλα δικτύου, θα πρέπει να σημειωθεί ότι τα RT OS LynxOS, VxWorks και QNX έχουν περίπου ίσες (και ευρείες) δυνατότητες. Ένα επιπλέον πλεονέκτημα του QNX RT OS είναι η ειδική αρχιτεκτονική του υποσυστήματος δικτύου, η οποία διασφαλίζει τη «διαφάνεια» του δικτύου των προγραμμάτων εφαρμογής: κάθε διεργασία μπορεί να καλέσει μια άλλη διεργασία σε μια απομακρυσμένη μονάδα με τον ίδιο τρόπο όπως μια διεργασία σε μια τοπική μονάδα.

Υποστήριξη συστήματος αρχείων

Η δυνατότητα αποθήκευσης πληροφοριών με τη μορφή αρχείων είναι βολική και παραδοσιακή. Αντίθετα, η έλλειψη μιας τέτοιας δυνατότητας δημιουργεί δυσκολίες κατά την αποθήκευση δεδομένων που αλλάζουν σπάνια και τη δημιουργία κατανεμημένων συστημάτων.

Στον πίνακα Το σχήμα 4 δείχνει την υποστήριξη του συστήματος αρχείων για καθένα από τα λειτουργικά συστήματα που εξετάζουμε.

Το QNX έχει την πιο εκτεταμένη υποστήριξη για συστήματα αρχείων. Επιπλέον, το σύστημα αρχείων flash του είναι ανεκτικό σε σφάλματα.

Ποιότητα τεκμηρίωσης

Η ποιότητα της τεκμηρίωσης για τα RT OS LynxOS, VxWorks, QNX είναι αρκετά υψηλή. Ωστόσο, υπάρχουν και παράπονα σχετικά με την τεκμηρίωση:

• Το QNX είναι μια εξαιρετική περιγραφή της αρχιτεκτονικής και των αρχών σχεδιασμού, αλλά μια ανεπαρκής περιγραφή της διεπαφής προγραμματισμού της εφαρμογής (δεν περιγράφονται όλες οι παράμετροι, υπάρχουν ασυνέπειες).
• VxWorks - καμία εξήγηση για το πώς λειτουργεί και ανεπαρκής περιγραφή της περίπλοκης διαδικασίας διαμόρφωσης του λειτουργικού συστήματος.

Ωστόσο, οι εταιρείες εργάζονται για την ποιότητα του υλικού. Η τεκμηρίωση για την τρέχουσα έκδοση του QNX (6.3.2) έχει επεκταθεί σημαντικά και ορισμένα μέρη έχουν επεξεργαστεί εκ νέου.

Ποιότητα τεχνικής υποστήριξης

Όσον αφορά την ποιότητα της επίσημης τεχνικής υποστήριξης, ο αναμφισβήτητος ηγέτης είναι το LynxOS. Το LynuxWorks υπόσχεται να απαντήσει σε οποιαδήποτε τεχνική ερώτηση εντός 4 ωρών από τη δημοσίευση του αιτήματος. Το LynxOS διανέμεται στη Ρωσία από την RTSoft, η οποία διαθέτει μεγάλο προσωπικό ικανό να παρέχει εξειδικευμένη βοήθεια. Το μειονέκτημα του LynxOS είναι ότι το λειτουργικό σύστημα δεν είναι ακόμη πολύ διαδεδομένο στη Ρωσία· συνεπώς, δεν υπάρχει καθιερωμένη κοινότητα χρηστών και δεν υπάρχει καν ένα φόρουμ στη ρωσική γλώσσα.

Το QSS (ο κατασκευαστής του QNX) προσφέρει επίσης καλή τεχνική υποστήριξη, αλλά οι γρήγοροι χρόνοι απόκρισης δεν είναι εγγυημένοι. Σε αντίθεση με το LynxOS, το QNX RT OS έχει μια καλά οργανωμένη κοινότητα χρηστών τόσο στο εξωτερικό όσο και στη Ρωσία. Απαντήσεις στις περισσότερες ερωτήσεις μπορείτε να βρείτε σε αυτά τα φόρουμ. Το QNX στη χώρα μας διανέμεται από την SVD Embedded Systems, οι εργαζόμενοι της οποίας είναι σε θέση να παρέχουν επαρκή τεχνική υποστήριξη και να πραγματοποιούν εργασίες προσαρμογής του λειτουργικού συστήματος σε συγκεκριμένες πλακέτες επεξεργαστών. Επιπλέον, η εταιρεία έχει άμεσες επαφές με την QSS και μπορεί να λάβει συμβουλές για πολύπλοκα ζητήματα από τον προγραμματιστή του QNX RT OS.

Η WindRiver, ο προγραμματιστής του VxWorks, ακολουθεί παραδοσιακά μια κλειστή τεχνική πολιτική, δηλαδή, είναι αρκετά δύσκολο να ληφθούν πληροφορίες σχετικά με τις αρχές λειτουργίας του λειτουργικού συστήματος. Αυτό το λειτουργικό σύστημα δεν διαθέτει επίσης ρωσόφωνο φόρουμ. Το VxWorks RT OS διανέμεται στη χώρα μας από την εταιρεία AVD Systems, η οποία ασχολείται κυρίως με τις πωλήσεις έτοιμων λύσεων λογισμικού και υλικού ξένης προέλευσης.

Ανοιχτή πηγή

Ένα ανοιχτό λειτουργικό σύστημα RT έχει τουλάχιστον τρία πλεονεκτήματα:

• Οι προγραμματιστές λογισμικού εφαρμογών μπορούν να κατανοήσουν πολύπλοκα προβλήματα χωρίς να περιλαμβάνουν τεχνική υποστήριξη.
• ευκολότερη πιστοποίηση (χωρίς σελιδοδείκτες κ.λπ.).
• πιο δυναμική ανάπτυξη, καθώς η εταιρεία προγραμματιστών RT OS λαμβάνει συχνά όχι μόνο αιτήματα για διορθώσεις σφαλμάτων, αλλά και προτάσεις για την εξάλειψη σφαλμάτων και τη βελτίωση του συστήματος. Οι κοινότητες προγραμματιστών RTOS ανοιχτού κώδικα, κατά κανόνα, αναπτύσσονται πολύ πιο γρήγορα και είναι καλύτερα οργανωμένες. Ανεξάρτητοι ειδικοί φαίνεται να βοηθούν στην επίλυση των προβλημάτων της υπηρεσίας τεχνικής υποστήριξης και να συμμετέχουν στην ανάπτυξη, τον εντοπισμό σφαλμάτων και τη δοκιμή του συστήματος.

Από τον Σεπτέμβριο του 2007, η QSS έχει ανοιχτού κώδικα τον πυρήνα QNX (συμπεριλαμβανομένου του πακέτου Adaptive Partitioning, High Availability πακέτου). Λίγο αργότερα άνοιξαν οι πηγαίοι κώδικες του υποσυστήματος δικτύου. Επί του παρόντος, η beta έκδοση 6.4.0 είναι διαθέσιμη για λήψη στον επίσημο ιστότοπο.

Θα πρέπει να σημειωθεί ότι σήμερα δεν είναι ανοιχτές όλες οι μονάδες QNX (για παράδειγμα, δεν υπάρχουν κωδικοί για γραφικά και συστήματα αρχείων) και η άδεια επιβάλλει περιορισμό στη χρήση του "πηγαίου κώδικα": μόνο για μη εμπορική χρήση. Ωστόσο, ο χρήστης του QNX λαμβάνει τα παραπάνω οφέλη δωρεάν.

Οι πηγαίοι κώδικες LynxOS και VxWorks είναι διαθέσιμοι στο εμπόριο. Η τιμή για ένα τέτοιο προϊόν είναι συζητήσιμη.

Εργαλεία

Η διαθεσιμότητα καλών εργαλείων καθορίζει σε μεγάλο βαθμό την ποιότητα και την ταχύτητα ανάπτυξης των προγραμμάτων εφαρμογών για ένα συγκεκριμένο λειτουργικό σύστημα. Θα πρέπει να σημειωθεί ότι τα LynxOS, VxWorks και QNX παρέχουν σήμερα εργαλεία καλής ποιότητας που περιλαμβάνουν ολοκληρωμένο περιβάλλον ανάπτυξης (IDE) και εντοπισμό σφαλμάτων λογισμικού εφαρμογών, εργαλεία προφίλ προγράμματος (για τον εντοπισμό σημείων συμφόρησης στην απόδοση, τη μνήμη κ.λπ.). Η εργονομία του ISD για αυτά τα RT OS δεν είναι γενικά κατώτερη από τα αναπτυγμένα εργαλεία ανάπτυξης για συμβατικά λειτουργικά συστήματα (για παράδειγμα, MS Windows).

Φορητότητα λογισμικού εφαρμογής

Η φορητότητα του λογισμικού εφαρμογής καθιστά δυνατή τη χρήση του σε άλλα λειτουργικά συστήματα (συμπεριλαμβανομένου του λειτουργικού συστήματος που δεν είναι RT). Η φορητότητα δίνει στον προγραμματιστή λογισμικού εφαρμογών μια ορισμένη ανεξαρτησία από το λειτουργικό σύστημα RT: εάν είναι απαραίτητο, μπορείτε να μεταβείτε σε άλλο λειτουργικό σύστημα με χαμηλό κόστος.

Η δυνατότητα εγγραφής φορητού λογισμικού επί του παρόντος καθορίζεται από τη συμμόρφωση με το πρότυπο POSIX. Όλα τα θεωρούμενα λειτουργικά συστήματα RT υποστηρίζουν το πρότυπο POSIX 1003.1. Το LynxOS έχει ένα πλεονέκτημα - αυτό το λειτουργικό σύστημα είναι δυαδικό συμβατό με Linux. Δηλαδή, οι εφαρμογές Linux μπορούν να εκτελεστούν στο LynxOS χωρίς επαναμεταγλώττιση. Αντίθετα, οι εφαρμογές LynxOS μπορούν να εκτελεστούν σε Linux (έκδοση 2.4.x με τη βιβλιοθήκη γλώσσας glibs C έκδοση 2.2.2).

Τα υπόλοιπα λειτουργικά συστήματα RT απαιτούν την εκ νέου μεταγλώττιση τους για την εκτέλεση εφαρμογών Linux. Σε αυτήν την περίπτωση, η διαδικασία μεταφοράς ακόμη και εφαρμογών που είναι συμβατές με το POSIX μπορεί συχνά να γίνει αρκετά απαιτητική λόγω διαφορών στην υλοποίηση βιβλιοθηκών και μεταγλωττιστών.

Υποστήριξη αρχιτεκτονικής επεξεργαστή

Οι εγχώριοι προγραμματιστές συστημάτων ελέγχου για την αεροπορία στη σημερινή περίοδο μετάβασης από τα εσωτερικά λειτουργικά συστήματα στα εμπορικά συχνά βρίσκονται σε μια κατάσταση όπου πρέπει να επιλέξουν και να προσαρμόσουν ένα RTOS σε μια υπάρχουσα πλακέτα επεξεργαστή. Σε αυτήν την περίπτωση, ένα από τα βασικά επιχειρήματα κατά την επιλογή ενός λειτουργικού συστήματος είναι η υποστήριξη για την αρχιτεκτονική του επεξεργαστή που χρησιμοποιείται στην πλακέτα.

Συμμόρφωση με τα αεροπορικά πρότυπα

Στην ξένη πρακτική, το λογισμικό για ηλεκτρονικά συστήματα πρέπει να διαθέτει πιστοποιητικό συμμόρφωσης με το πρότυπο DO-178B. Εάν το λογισμικό διαφορετικών επιπέδων κρισιμότητας εκτελείται στην ίδια μονάδα επεξεργαστή, τότε το RTOS που χρησιμοποιείται πρέπει να υποστηρίζει την έννοια των κατατμήσεων. (Διαφορετικά είναι σχεδόν αδύνατο να αποδειχθεί η μη διάδοση του λάθους). Όπως ήδη αναφέρθηκε, είναι καλύτερο η διεπαφή προγραμματισμού RTOS να συμμορφώνεται με το πρότυπο ARINC-653, καθώς το πρότυπο είναι πολύ γνωστό σε ξένους φορείς πιστοποίησης.

Το LynxOS είναι πρωτοπόρος όσον αφορά τη συμμόρφωση με τα πρότυπα. Υποστηρίζει ARINC-653 και υπάρχουν πολλά παραδείγματα συστημάτων πιστοποιημένων DO-178B που είναι κατασκευασμένα σε αυτό. Το βασικό σημείο είναι ότι το LynuxWorks προσφέρει ένα σύνολο RSC (αν και οι συντάκτες του άρθρου δεν γνωρίζουν τίποτα για την τιμή).

Το VxWorks συμμορφώνεται με το πρότυπο ARINC-653 και τα συστήματα που είναι κατασκευασμένα πάνω του μπορούν να πιστοποιηθούν με DO-178B (υπάρχουν πολλά παραδείγματα).

Το QNX δεν συμμορφώνεται με το ARINC-653 και δεν υπάρχουν ακόμη συστήματα με πιστοποίηση DO-178B που να βασίζονται σε αυτά.

Θα πρέπει να σημειωθεί ότι τα συστήματα QNX μπορούν καταρχήν να χρησιμοποιηθούν για την κατασκευή ενός IMA, επειδή το QNX υποστηρίζει τη δική του μέθοδο παροχής της ιδέας διαμερισμάτων, η οποία είναι μια πολύ καλή εναλλακτική του ARINC-653 και, επιπλέον, σας επιτρέπει να εξοικονομήσετε χρόνο επεξεργαστή .

Όσον αφορά παρόμοια ρωσικά πρότυπα για τη στρατιωτική αεροπορία (GOST R ISO/IEC 51904-2002), δεν υπάρχει ακόμη ένα παράδειγμα πιστοποιημένου συστήματος, αν και κατ' αρχήν ένα τέτοιο σύστημα μπορεί να αναπτυχθεί με βάση οποιοδήποτε από τα υπό εξέταση ΛΣ. Για το QNX RT OS, επί του παρόντος βρίσκονται σε εξέλιξη εργασίες για την προετοιμασία των κύριων λειτουργικών μονάδων για πιστοποίηση.

Ανάπτυξη του συστήματος εξειδικευμένης εκπαίδευσης

Η ταχύτητα και η ποιότητα της εκπαίδευσης του προσωπικού που εργάζεται με το RT OS και διάφορα εργαλεία ανάπτυξης λογισμικού και εντοπισμού σφαλμάτων σχετίζεται άμεσα με την ταχύτητα ανάπτυξης λογισμικού και την ποιότητά του. Κορυφαίες εταιρείες στον τομέα του ενσωματωμένου λογισμικού και του λογισμικού συστήματος, όπως οι WindRiver, LynuxWorks, QSS, πραγματοποιούν ένα μεγάλο πρόγραμμα μαθημάτων και εκπαιδεύσεων για τη μελέτη της χρήσης των προϊόντων της εταιρείας, συμπεριλαμβανομένου του RT OS.

Αποτελέσματα σύγκρισης

Το QNX Neutrino RTOS είναι το πιο προηγμένο λειτουργικό σύστημα από τεχνική άποψη, έχει ένα καλό σύνολο εργαλείων και έχει σχετικά χαμηλή τιμή. Η αρχιτεκτονική του μικροπυρήνα εξασφαλίζει υψηλή αξιοπιστία και σπονδυλωτότητα των ανεπτυγμένων συστημάτων. Ένα επιπλέον πλεονέκτημα είναι ο ανοιχτός κώδικας. Αλλά υπάρχει επίσης μια "μύγα στην αλοιφή": επί του παρόντος το QNX πρακτικά δεν χρησιμοποιείται πουθενά στην αεροπορία και από αυτή την άποψη αυτό το λειτουργικό σύστημα χάνει από τους ανταγωνιστές του (LynxOS και VxWorks). Πρόσθετο μειονέκτημα του QNX: μη συμμόρφωση με το πρότυπο ARINC-653.

Πρέπει να σημειωθεί ότι, καταρχήν, το QNX Neutrino διαθέτει όλους τους απαραίτητους μηχανισμούς για εργασία σε συστήματα αεροηλεκτρονικής. Επιπλέον, η αξιοπιστία και η υψηλή διαθεσιμότητα συστημάτων που βασίζονται σε QNX έχει αποδειχθεί σε άλλους κλάδους όπου το κόστος του σφάλματος είναι ακόμη υψηλότερο από ό,τι στην αεροπορία (έλεγχος πυρηνικών αντιδραστήρων).

Η SWD Software πραγματοποιεί εργασίες προετοιμασίας για την πιστοποίηση του QNX Neutrino σύμφωνα με τις απαιτήσεις των εγχώριων αεροπορικών προτύπων.

Το RTOS LynxOS-178, αντίθετα, διαθέτει όλα τα απαραίτητα πιστοποιητικά στο εξωτερικό, αν και σύμφωνα με πολλά άλλα κριτήρια φαίνεται λιγότερο προτιμότερο από το QNX Neutrino. Σημειώστε ότι για χρήση στη ρωσική αεροπορική βιομηχανία, το LynxOS-178 RTOS πρέπει επίσης να είναι πιστοποιημένο σύμφωνα με εγχώριους GOST.

Το VxWorks OS έχει μακρά ιστορία χρήσης σε κρίσιμες εφαρμογές στο εξωτερικό. Ωστόσο, η ανάλυσή μας δείχνει ότι φαίνεται λιγότερο προτιμότερο από τα δύο πρώτα λειτουργικά συστήματα σύμφωνα με πολλά κριτήρια. Επιπλέον, η αξιοπιστία της VxWorks υπονομεύεται από την κλειστή αναπτυξιακή στρατηγική της.

Λειτουργικά συστήματα σε πραγματικό χρόνο

1. Εισαγωγή: Χαρακτηριστικά λειτουργικών συστημάτων σε πραγματικό χρόνο

1.1. Διαδικασίες, νήματα, εργασίες

1.2. Προγραμματισμός, προτεραιότητες

1.3. Μνήμη

1.4. Διακόπτει

1.5. Ρολόγια και χρονόμετρα

1.6. Πρότυπα RTOS

1.6.1. POSIX

1.6.2. DO-178B

1.6.3. ARINC-653

1.6.4. ΟΣΕΚ

1.6.5. Πρότυπα Ασφαλείας

1.7. Προσαρμογή λειτουργικού συστήματος

2. Σύντομα χαρακτηριστικά των πιο κοινών RTOS

2.1. VxWorks

2.2. QNX Neutrino RTOS

2.3. RTEMS

2.4. ChorusOS

2.5. Επεκτάσεις σε πραγματικό χρόνο για Windows NT

2.5.1. RTXΓιαWindows NT

2.5.2. Εγκαίρως

2.5.3. Microsoft Windows Embedded

2.6. TinyOS

2.7. OSEK/VDX

2.8. ΟΣΕ ΡΤΟΣ

2.9. Κοντίκι

2.10. pSOS

2.11. ΑΚΕΡΑΙΟΤΗΤΑ

2.12. LynxOS

2.13. Microware OS-9

2.14. GRACE-OS

2.15. Γ ΣΤΕΛΕΧΟΣ

2.16. CMX-RTX

2.16.1. CMX-TINY+

2.17. Κόλαση

3. ΛΣ σχεδιασμένο ειδικά για φορητές συσκευές

3.1. ITRON

3.2. Windows CE

3.3. JavaOS

3.4. Jbed

3.5. Πυρήνας RTOS

3.6. ΣΜΑΡΑΛΔΙΑ

3.7. ΦΛΟΙΟΣ

3.8. DeltaOS

3.9. Palm OS

3.10. Symbian OS (EPOC)

4. Προσαρμογή λειτουργικών συστημάτων

4.1. Προσαρμογή του ανθρώπου

4.1.1. Στατική προσαρμογή με πρωτοβουλία του σχεδιαστή

4.1.2. Δυναμική προσαρμογή που ξεκίνησε από τον διαχειριστή

4.2. Η εφαρμογή ξεκίνησε προσαρμογή

4.2.1. Προσαρμογή από το επίπεδο εφαρμογής

4.2.2. Προσαρμογή επιπέδου πυρήνα

4.3. Αυτόματη προσαρμογή

5. Συνοπτικοί πίνακες χαρακτηριστικών ιδιοτήτων RTOS

Παράρτημα Α. Κατάλογος συντομογραφιών

Παράρτημα Β. Ορολογία

Βιβλιογραφία

Κατάλογος των RTOS που αναφέρονται σε αυτό το κείμενο, σε έντυπη μορφή και στο Διαδίκτυο

1. Εισαγωγή: Χαρακτηριστικά λειτουργικών συστημάτων σε πραγματικό χρόνο

Τα λειτουργικά συστήματα σε πραγματικό χρόνο (RTOS) έχουν σχεδιαστεί για να παρέχουν μια διεπαφή με τους πόρους των κρίσιμων για το χρόνο συστημάτων σε πραγματικό χρόνο. Το κύριο καθήκον σε τέτοια συστήματα είναι η επικαιρότητα της επεξεργασίας δεδομένων.

Η κύρια απαίτηση για ένα RTOS είναι η διασφάλιση προβλεψιμότηταή αιτιοκρατίασυμπεριφορά του συστήματος στις χειρότερες εξωτερικές συνθήκες, η οποία διαφέρει σημαντικά από τις απαιτήσεις απόδοσης και ταχύτητας των καθολικών λειτουργικών συστημάτων. Ένα καλό RTOS έχει προβλέψιμη συμπεριφορά σε όλα τα σενάρια φόρτωσης συστήματος (ταυτόχρονες διακοπές και εκτέλεση νημάτων).

Υπάρχει κάποια διαφορά μεταξύ συστημάτων πραγματικού χρόνου και ενσωματωμένων συστημάτων. Ένα ενσωματωμένο σύστημα δεν απαιτείται πάντα να έχει προβλέψιμη συμπεριφορά, οπότε δεν είναι σύστημα σε πραγματικό χρόνο. Ωστόσο, ακόμη και μια γρήγορη ματιά σε πιθανά ενσωματωμένα συστήματα υποδηλώνει ότι τα περισσότερα ενσωματωμένα συστήματα απαιτούν προβλέψιμη συμπεριφορά για τουλάχιστον κάποια λειτουργικότητα, και έτσι αυτά τα συστήματα μπορούν να ταξινομηθούν ως συστήματα πραγματικού χρόνου.

Είναι σύνηθες να γίνεται διάκριση μεταξύ μαλακών και σκληρών συστημάτων σε πραγματικό χρόνο. Σε σκληρά συστήματα πραγματικού χρόνου, η αδυναμία παροχής απάντησης σε οποιαδήποτε γεγονότα σε μια δεδομένη στιγμή οδηγεί σε αποτυχίες και αδυναμία ολοκλήρωσης της εργασίας που έχει ανατεθεί. Στην πλειονότητα της ρωσόφωνης βιβλιογραφίας, τέτοια συστήματα ονομάζονται συστήματα με ντετερμινιστικό χρόνο. Σε πρακτικές εφαρμογές, ο χρόνος αντίδρασης πρέπει να είναι ελάχιστος. Τα μαλακά συστήματα σε πραγματικό χρόνο είναι συστήματα που δεν εμπίπτουν στον ορισμό του «σκληρού», επειδή Δεν υπάρχει ακόμη σαφής ορισμός για αυτά στη βιβλιογραφία. Τα μαλακά συστήματα σε πραγματικό χρόνο μπορεί να μην έχουν χρόνο να λύσουν ένα πρόβλημα, αλλά αυτό δεν οδηγεί σε αστοχία του συστήματος στο σύνολό του. Σε συστήματα πραγματικού χρόνου, είναι απαραίτητο να εισαχθεί μια ορισμένη προθεσμία (στην αγγλική βιβλιογραφία - προθεσμία), πριν από τη λήξη της οποίας πρέπει απαραίτητα να έχει ολοκληρωθεί η εργασία (για μαλακά συστήματα πραγματικού χρόνου - κατά προτίμηση). Αυτή η προθεσμία χρησιμοποιείται από τον προγραμματιστή εργασιών τόσο για την ανάθεση προτεραιότητας σε μια εργασία κατά την εκκίνηση και κατά την επιλογή μιας εργασίας προς εκτέλεση.

Ο Martin Timmerman διατύπωσε τις ακόλουθες απαραίτητες απαιτήσεις για ένα RTOS:

Το λειτουργικό σύστημα πρέπει να είναι multitasking και προκαταρκτικό,

Το λειτουργικό σύστημα πρέπει να έχει μια έννοια προτεραιότητας για τα νήματα,

Το ΛΣ πρέπει να υποστηρίζει προβλέψιμους μηχανισμούς συγχρονισμού,

Το ΛΣ πρέπει να παρέχει έναν μηχανισμό κληρονομιάς προτεραιοτήτων,

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

Τα τελευταία 25-30 χρόνια, η δομή των λειτουργικών συστημάτων έχει εξελιχθεί από μονολιθική σε πολυεπίπεδη δομή λειτουργικού συστήματος σε αρχιτεκτονική πελάτη-διακομιστή. Σε μια μονολιθική δομή, το λειτουργικό σύστημα αποτελείται από ένα σύνολο μονάδων και οι αλλαγές σε μια λειτουργική μονάδα επηρεάζουν άλλες μονάδες. Όσο περισσότερες μονάδες, τόσο περισσότερο χάος υπάρχει κατά τη λειτουργία ενός τέτοιου συστήματος. Επιπλέον, δεν είναι δυνατή η διανομή του λειτουργικού συστήματος σε ένα σύστημα πολλαπλών επεξεργαστών. Σε μια πολυστρωματική δομή, οι αλλαγές σε ένα στρώμα επηρεάζουν τα γειτονικά στρώματα. Επιπλέον, η αναστροφή μέσω του στρώματος δεν είναι δυνατή. Για συστήματα σε πραγματικό χρόνο, πρέπει να παρέχεται άμεση πρόσβαση σε κάθε επίπεδο του λειτουργικού συστήματος, και μερικές φορές απευθείας στο υλικό.

Η κύρια ιδέα της τεχνολογίας πελάτη-διακομιστή σε ένα λειτουργικό σύστημα είναι η μείωση της βάσης του λειτουργικού συστήματος στο ελάχιστο (προγραμματιστής και πρωτόγονοι συγχρονισμού). Όλες οι άλλες λειτουργίες μετακινούνται σε άλλο επίπεδο και υλοποιούνται μέσω νημάτων ή εργασιών. Ένα σύνολο τέτοιων εργασιών διακομιστή είναι υπεύθυνο για κλήσεις συστήματος. Οι εφαρμογές είναι πελάτες που ζητούν υπηρεσίες μέσω κλήσεων συστήματος.

Η τεχνολογία πελάτη-διακομιστή επιτρέπει τη δημιουργία επεκτάσιμων λειτουργικών συστημάτων και απλοποιεί τη διανομή σε ένα σύστημα πολλαπλών επεξεργαστών. Κατά τη λειτουργία του συστήματος, η αντικατάσταση μιας μονάδας δεν προκαλεί φαινόμενο «χιονόμπαλας». Επιπλέον, μια αστοχία μονάδας δεν συνεπάγεται πάντα αποτυχία του συστήματος στο σύνολό του. Υπάρχει πλέον η δυνατότητα δυναμικής φόρτωσης και εκφόρτωσης μονάδων. Το κύριο ζήτημα σε αυτό το μοντέλο είναι η προστασία της μνήμης, καθώς οι διαδικασίες διακομιστή πρέπει να προστατεύονται. Κάθε φορά που υποβάλλεται ένα αίτημα υπηρεσίας, το σύστημα πρέπει να μεταβαίνει από το περιβάλλον εφαρμογής στο περιβάλλον διακομιστή. Με την υποστήριξη προστασίας μνήμης, ο χρόνος εναλλαγής από τη μια διαδικασία στην άλλη αυξάνεται.

Κατά κανόνα, τα περισσότερα σύγχρονα RTOS κατασκευάζονται με βάση έναν μικροπυρήνα (πυρήνα ή πυρήνας), ο οποίος παρέχει προγραμματισμό και αποστολή εργασιών, καθώς και την αλληλεπίδρασή τους. Παρόλο που ο πυρήνας ελαχιστοποιεί τις αφαιρέσεις του λειτουργικού συστήματος, ο μικροπυρήνας πρέπει ακόμα να κατανοεί τις αφαιρέσεις διεργασιών. Όλες οι άλλες εννοιολογικές αφαιρέσεις λειτουργικών συστημάτων μετακινούνται εκτός του πυρήνα, καλούνται κατόπιν αιτήματος και εκτελούνται ως εφαρμογές.

Ας δούμε τις εννοιολογικές αφαιρέσεις του λειτουργικού συστήματος μέσα από το πρίσμα των απαιτήσεων για συστήματα σε πραγματικό χρόνο.

Διακριτικά χαρακτηριστικά του RTOS από το OS γενικού σκοπού

Στοχεύουν λειτουργικά συστήματα γενικής χρήσης, ειδικά σε πολλαπλούς χρήστες όπως το UNIX βέλτιστη κατανομήπόρους υπολογιστή μεταξύ των χρηστών και των εργασιών. Στα λειτουργικά συστήματα σε πραγματικό χρόνο, μια τέτοια εργασία σβήνει στο παρασκήνιο - όλα υποχωρούν πριν κύρια δραστηριότητα- έχετε χρόνο να αντιδράσετε σε γεγονότα που συμβαίνουν στην εγκατάσταση Μια άλλη διαφορά είναι ότι η χρήση ενός λειτουργικού συστήματος σε πραγματικό χρόνο σχετίζεται πάντα με τον εξοπλισμό, με το αντικείμενο, με τα γεγονότα που συμβαίνουν στην εγκατάσταση. Ένα λειτουργικό σύστημα σε πραγματικό χρόνο εστιάζει στην επεξεργασία εξωτερικών συμβάντων. Ένα λειτουργικό σύστημα σε πραγματικό χρόνο μπορεί να έχει διεπαφή χρήστη παρόμοιο με ένα λειτουργικό σύστημα γενικής χρήσης, αλλά έχει σχεδιαστεί εντελώς διαφορετικά.Επιπλέον, η εφαρμογή λειτουργικών συστημάτων σε πραγματικό χρόνο είναι πάντα συγκεκριμένη. Εάν ένα λειτουργικό σύστημα γενικής χρήσης γίνεται αντιληπτό από τους χρήστες (όχι τους προγραμματιστές) ως ένα έτοιμο σύνολο εφαρμογών, τότε ένα λειτουργικό σύστημα σε πραγματικό χρόνο χρησιμεύει μόνο ως εργαλείο για τη δημιουργία ενός συγκεκριμένου συγκροτήματος υλικού και λογισμικού σε πραγματικό χρόνο. Και επομένως, η ευρύτερη κατηγορία χρηστών λειτουργικών συστημάτων σε πραγματικό χρόνο είναι προγραμματιστές συστημάτων σε πραγματικό χρόνο, άνθρωποι που σχεδιάζουν συστήματα ελέγχου και απόκτησης δεδομένων. Κατά το σχεδιασμό και την ανάπτυξη ενός συγκεκριμένου συστήματος σε πραγματικό χρόνο, ο προγραμματιστής γνωρίζει πάντα ακριβώς ποια συμβάντα μπορούν να συμβούν στην εγκατάσταση και γνωρίζει το κρίσιμο χρονικό πλαίσιο για την εξυπηρέτηση καθενός από αυτά τα συμβάντα. Το σύστημα RT πρέπει να έχει χρόνο για να ανταποκριθεί σε ένα γεγονός που συνέβη στις εγκαταστάσεις εντός του κρίσιμου χρόνου για αυτό το γεγονός. Η τιμή του κρίσιμου χρόνου για κάθε συμβάν καθορίζεται από το αντικείμενο και το ίδιο το συμβάν και μπορεί να είναι διαφορετική, αλλά ο χρόνος αντίδρασης του συστήματος πρέπει να προβλεφθεί (υπολογιστεί) κατά τη δημιουργία του συστήματος. Η αποτυχία απόκρισης στον προβλεπόμενο χρόνο θεωρείται σφάλμα για συστήματα πραγματικού χρόνου. Το σύστημα πρέπει να μπορεί να ανταποκρίνεται σε συμβάντα που συμβαίνουν ταυτόχρονα. Ακόμα κι αν δύο ή περισσότερα εξωτερικά συμβάντα συμβαίνουν ταυτόχρονα, το σύστημα πρέπει να έχει χρόνο να αντιδράσει σε καθένα από αυτά μέσα στα κρίσιμα χρονικά διαστήματα για αυτά τα συμβάντα.

	ΛΣ σε πραγματικό χρόνο	ΛΣ γενικής χρήσης
Το κύριο καθήκον	Έχετε χρόνο να αντιδράσετε σε γεγονότα που συμβαίνουν στον εξοπλισμό	Βέλτιστη διανομή των πόρων του υπολογιστή μεταξύ των χρηστών και των εργασιών
Σε τι επικεντρώνεται;	Χειρισμός εξωτερικών συμβάντων	Επεξεργασία ενεργειών χρήστη
Πώς τοποθετείται	Ένα εργαλείο για τη δημιουργία ενός συγκεκριμένου συγκροτήματος υλικού και λογισμικού σε πραγματικό χρόνο	Γίνεται αντιληπτό από το χρήστη ως ένα σύνολο εφαρμογών έτοιμων προς χρήση
Σε ποιον προορίζεται;	Πιστοποιημένος προγραμματιστής	Ενδιάμεσος χρήστης

Σκληρά και μαλακά συστήματα σε πραγματικό χρόνο

Υπάρχουν δύο τύποι συστημάτων πραγματικού χρόνου - σκληρά συστήματα πραγματικού χρόνου και μαλακά συστήματα πραγματικού χρόνου.

Τα σκληρά συστήματα πραγματικού χρόνου δεν επιτρέπουν καμία καθυστέρηση στην απόκριση του συστήματος σε καμία περίπτωση επειδή:

• τα αποτελέσματα μπορεί να είναι άχρηστα εάν καθυστερήσουν
• μπορεί να συμβεί καταστροφή εάν καθυστερήσει η αντίδραση

• το κόστος της καθυστέρησης μπορεί να είναι άπειρο.

Παραδείγματα σκληρών συστημάτων σε πραγματικό χρόνο - εποχούμενα συστήματασυστήματα ελέγχου, συστήματα προστασίας έκτακτης ανάγκης, καταγραφείς συμβάντων έκτακτης ανάγκης.

Τα μαλακά συστήματα πραγματικού χρόνου χαρακτηρίζονται από το γεγονός ότι η καθυστέρηση απόκρισης δεν είναι κρίσιμη, αν και μπορεί να οδηγήσει σε αύξηση του κόστους των αποτελεσμάτων και μείωση της απόδοσης του συστήματος συνολικά. Ένα παράδειγμα είναι η λειτουργία δικτύου. Εάν το σύστημα δεν έχει χρόνο να επεξεργαστεί το επόμενο ληφθέν πακέτο, αυτό θα οδηγήσει σε ένα χρονικό όριο στην πλευρά αποστολής και στην εκ νέου αποστολή (ανάλογα με το πρωτόκολλο, φυσικά). Τα δεδομένα δεν χάνονται, αλλά η απόδοση του δικτύου μειώνεται. Η κύρια διαφορά μεταξύ σκληρών και μαλακών συστημάτων σε πραγματικό χρόνο μπορεί να εκφραστεί ως εξής: ένα σκληρό σύστημα σε πραγματικό χρόνο δεν πρέπει ποτέ να καθυστερεί να ανταποκριθεί σε ένα συμβάν, ένα μαλακό σύστημα σε πραγματικό χρόνο δεν πρέπει ποτέ να καθυστερεί να απαντήσει σε ένα γεγονός

Πυρήνας λειτουργικού συστήματος

Ο πυρήνας είναι το κεντρικό τμήμα του λειτουργικού συστήματος (OS), παρέχοντας εφαρμογές με συντονισμένη πρόσβαση σε πόρους υπολογιστή, μνήμη, εξωτερικό υλικό, εξωτερικές συσκευές εισόδου και εξόδου, μεταφράζοντας εντολές γλώσσας εφαρμογής σε γλώσσα δυαδικού κώδικα που κατανοεί ο υπολογιστής. στοιχείο του λειτουργικού συστήματος, ο πυρήνας αντιπροσωπεύει το χαμηλότερο επίπεδο αφαίρεσης για τις εφαρμογές για πρόσβαση στους πόρους του συστήματος που απαιτούνται για τη λειτουργία τους. Τυπικά, ο πυρήνας παρέχει τέτοια πρόσβαση στις διεργασίες εκτέλεσης των αντίστοιχων εφαρμογών μέσω της χρήσης μηχανισμών επικοινωνίας μεταξύ διεργασιών και κλήσεων εφαρμογών σε κλήσεις συστήματος λειτουργικού συστήματος.

Μονολιθικός πυρήνας

Ο μονολιθικός πυρήνας παρέχει ένα πλούσιο σύνολο από αφαιρέσεις υλικού. Όλα τα μέρη ενός μονολιθικού πυρήνα λειτουργούν στον ίδιο χώρο διευθύνσεων. Αυτό είναι ένα σχήμα ενός λειτουργικού συστήματος στο οποίο όλα τα στοιχεία του πυρήνα του είναι στοιχεία ενός προγράμματος. γενικές δομέςδεδομένα και αλληλεπιδρούν μεταξύ τους καλώντας απευθείας διαδικασίες. Μονολιθικός πυρήνας - ο αρχαιότερος τρόποςοργάνωση λειτουργικών συστημάτων. Ένα παράδειγμα συστημάτων με μονολιθικό πυρήνα είναι τα περισσότερα συστήματα UNIX.

Πλεονεκτήματα: Ταχύτητα λειτουργίας, απλοποιημένη ανάπτυξη μονάδων.

Ελαττώματα: Εφόσον ολόκληρος ο πυρήνας λειτουργεί στον ίδιο χώρο διευθύνσεων, μια αποτυχία σε ένα από τα στοιχεία μπορεί να διαταράξει ολόκληρο το σύστημα.

Ορισμένοι παλιοί μονολιθικοί πυρήνες, ειδικά συστήματα κλάσης UNIX/Linux, απαιτούσαν εκ νέου μεταγλώττιση κάθε φορά που άλλαζε η σύνθεση του υλικού. Οι περισσότεροι σύγχρονοι πυρήνες σάς επιτρέπουν να φορτώνετε μονάδες κατά τη λειτουργία που εκτελούν μέρος των λειτουργιών του πυρήνα. Σε αυτήν την περίπτωση, τα στοιχεία του λειτουργικού συστήματος δεν είναι ανεξάρτητες μονάδες, αλλά στοιχεία μιας μεγάλο πρόγραμμαονομάζεται μονολιθικός πυρήνας, ο οποίος είναι ένα σύνολο διαδικασιών, καθεμία από τις οποίες μπορεί να καλέσει την καθεμία. Όλες οι διαδικασίες εκτελούνται σε προνομιακή λειτουργία.

Μικροπυρήνα

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

Πλεονεκτήματα: Αντοχή σε αστοχίες υλικού και σφάλματα σε στοιχεία του συστήματος. Το κύριο πλεονέκτημα της αρχιτεκτονικής μικροπυρήνα είναι ο υψηλός βαθμός αρθρωτής δομής του πυρήνα του λειτουργικού συστήματος. Αυτό καθιστά πολύ πιο εύκολη την προσθήκη νέων στοιχείων σε αυτό. Σε ένα λειτουργικό σύστημα μικροπυρήνα, μπορείτε να φορτώσετε και να ξεφορτώσετε νέα προγράμματα οδήγησης χωρίς να διακόψετε τη λειτουργία του, συστήματα αρχείωνκ.λπ. Η διαδικασία εντοπισμού σφαλμάτων των στοιχείων του πυρήνα είναι πολύ απλοποιημένη, αφού μια νέα έκδοσηΤα προγράμματα οδήγησης μπορούν να φορτωθούν χωρίς επανεκκίνηση ολόκληρου του λειτουργικού συστήματος. Τα στοιχεία του πυρήνα του λειτουργικού συστήματος δεν διαφέρουν ουσιαστικά από τα προγράμματα χρηστών, επομένως μπορείτε να χρησιμοποιήσετε συνηθισμένα εργαλεία για να τα διορθώσετε. Η αρχιτεκτονική του μικροπυρήνα βελτιώνει την αξιοπιστία του συστήματος επειδή μια αποτυχία σε επίπεδο προγράμματος χωρίς προνόμια είναι λιγότερο επικίνδυνη από μια αποτυχία σε επίπεδο λειτουργίας πυρήνα.

Ελαττώματα: Η διαβίβαση δεδομένων μεταξύ διεργασιών απαιτεί επιβάρυνση.

Περιβάλλον χρόνου εκτέλεσης

Οι απαιτήσεις για το περιβάλλον εκτέλεσης συστημάτων σε πραγματικό χρόνο είναι οι εξής:

• μικρή μνήμη συστήματος - για τη δυνατότητα ενσωμάτωσής της.
• το σύστημα πρέπει να είναι πλήρως ενσωματωμένο στη μνήμη για να αποφευχθεί η εναλλαγή ή η αλλαγή σελίδας μνήμης.
• το σύστημα πρέπει να είναι πολλαπλών εργασιών - για να διασφαλιστεί η αποτελεσματικότερη χρήση όλων των πόρων του συστήματος.
• πυρήνα με προτεραιότητα για διακοπές συντήρησης. Προτεραιότητα διακοπής σημαίνει ότι μια διεργασία που είναι έτοιμη για εκτέλεση και έχει μια συγκεκριμένη προτεραιότητα έχει απαραίτητα προτεραιότητα στην ουρά έναντι μιας διεργασίας με χαμηλότερη προτεραιότητα, αντικαθιστά γρήγορα την τελευταία και προχωρά στην εκτέλεση. Ο πυρήνας ολοκληρώνει οποιαδήποτε εργασία υπηρεσίας μόλις φτάσει μια εργασία με την υψηλότερη προτεραιότητα. Αυτό διασφαλίζει την προβλεψιμότητα του συστήματος.
• διαχειριστής προτεραιότητας - επιτρέπει στον προγραμματιστή της εφαρμογής να εκχωρήσει σε κάθε μονάδα εκκίνησης μια προτεραιότητα που δεν υπόκειται στο σύστημα. Η εκχώρηση προτεραιότητας χρησιμοποιείται για τον καθορισμό της σειράς με την οποία εκτελούνται τα προγράμματα που είναι έτοιμα να εκτελεστούν. Μια εναλλακτική σε αυτόν τον τύπο προγραμματισμού είναι ο προγραμματισμός καρουζέλ, στον οποίο κάθε πρόγραμμα που είναι έτοιμο να συνεχίσει έχει ίσες πιθανότητες εκτέλεσης. Με αυτή τη μέθοδο, δεν υπάρχει έλεγχος για το ποιο πρόγραμμα θα εκτελεστεί και πότε. Αυτό είναι απαράδεκτο σε περιβάλλον πραγματικού χρόνου. Η αποστολή βάσει προτεραιότητας και ένας πυρήνας προτεραιότητας διακοπής δίνουν στον προγραμματιστή της εφαρμογής πλήρη έλεγχο του συστήματος. Εάν προκύψει ένα συμβάν υψηλότερης προτεραιότητας, το σύστημα σταματά την επεξεργασία της εργασίας χαμηλότερης προτεραιότητας και ανταποκρίνεται στο αίτημα που ελήφθη πρόσφατα.

Ο συνδυασμός των ιδιοτήτων που περιγράφονται παραπάνω δημιουργεί ένα ισχυρό και αποτελεσματικό περιβάλλον εκτέλεσης σε πραγματικό χρόνο.

Εκτός από τις ιδιότητες του περιβάλλοντος χρόνου εκτέλεσης, είναι επίσης απαραίτητο να ληφθεί υπόψη η υπηρεσία που παρέχεται από τον πυρήνα του λειτουργικού συστήματος σε πραγματικό χρόνο. Ο πυρήνας οποιουδήποτε περιβάλλοντος χρόνου εκτέλεσης σε πραγματικό χρόνο είναι ο πυρήνας ή ο διεκπεραιωτής. Ο πυρήνας ελέγχει το υλικό του υπολογιστή προορισμού: κεντρικός επεξεργαστής, συσκευές μνήμης και εισόδου/εξόδου. ελέγχει τη λειτουργία όλων των άλλων συστημάτων και λογισμικού εφαρμογών. Σε ένα σύστημα πραγματικού χρόνου, ο διεκπεραιωτής βρίσκεται μεταξύ του υλικού του υπολογιστή-στόχου και του λογισμικού εφαρμογής. Παρέχει ειδική υπηρεσία, απαραίτητο για την εκτέλεση εφαρμογών σε πραγματικό χρόνο. Η υπηρεσία που παρέχεται από τον πυρήνα δίνει στα προγράμματα εφαρμογών πρόσβαση σε πόρους του συστήματος, όπως μνήμη ή συσκευές εισόδου/εξόδου.

Ο πυρήνας μπορεί να παρέχει διαφορετικούς τύπους υπηρεσιών:

• Ανταλλαγή μεταξύ εργασιών. Συχνά είναι απαραίτητη η μεταφορά δεδομένων μεταξύ προγραμμάτων εντός του ίδιου συστήματος.Επιπλέον, πολλές εφαρμογές πρέπει να επικοινωνούν με άλλα συστήματα μέσω ενός δικτύου. Η εσωτερική επικοινωνία μπορεί να πραγματοποιηθεί μέσω ενός συστήματος ανταλλαγής μηνυμάτων. Εξωτερικές επικοινωνίεςμπορεί να οργανωθεί είτε μέσω datagram (καλύτερη μέθοδος παράδοσης) είτε μέσω γραμμών επικοινωνίας (εγγυημένη παράδοση). Η επιλογή μιας ή άλλης μεθόδου εξαρτάται από το πρωτόκολλο επικοινωνίας.
• Διαχωρισμός δεδομένων. Σε εφαρμογές σε πραγματικό χρόνο, η συλλογή δεδομένων διαρκεί τον μεγαλύτερο χρόνο. Τα δεδομένα είναι συχνά απαραίτητα για τη λειτουργία άλλων προγραμμάτων ή χρειάζονται από το σύστημα για την εκτέλεση ορισμένων από τις λειτουργίες του. Πολλά συστήματα παρέχουν πρόσβαση σε τμήματα κοινής μνήμης. Η ουρά δεδομένων είναι ευρέως διαδεδομένη. Υπάρχουν πολλά είδη ουρών σε χρήση, καθένα από τα οποία έχει τα δικά του πλεονεκτήματα.
• Επεξεργασία αιτημάτων από εξωτερικές συσκευές. Κάθε πρόγραμμα εφαρμογής συνδέεται σε πραγματικό χρόνο με μια εξωτερική συσκευή κάποιου τύπου. Ο πυρήνας πρέπει να παρέχει υπηρεσίες εισόδου/εξόδου που επιτρέπουν σε προγράμματα εφαρμογών να διαβάζουν και να γράφουν σε αυτές τις συσκευές. Για εφαρμογές σε πραγματικό χρόνο, είναι σύνηθες να υπάρχει μια εξωτερική συσκευή για συγκεκριμένη εφαρμογή. Ο πυρήνας πρέπει να παρέχει μια υπηρεσία που διευκολύνει την εργασία με προγράμματα οδήγησης συσκευών. Για παράδειγμα, παρέχετε τη δυνατότητα να γράφετε σε γλώσσες υψηλού επιπέδου - όπως C ή Pascal.
• Αντιμετώπιση ειδικών καταστάσεων. Εξαίρεση αποτελεί ένα συμβάν που συμβαίνει κατά την εκτέλεση του προγράμματος. Μπορεί να είναι σύγχρονο εάν η εμφάνισή του είναι προβλέψιμη, όπως διαίρεση με το μηδέν. Και μπορεί επίσης να είναι ασύγχρονο εάν συμβεί απρόβλεπτα, όπως πτώση τάσης. Η παροχή της δυνατότητας χειρισμού αυτών των τύπων συμβάντων επιτρέπει στις εφαρμογές σε πραγματικό χρόνο να ανταποκρίνονται γρήγορα και προβλέψιμα σε εσωτερικά και εξωτερικά συμβάντα. Υπάρχουν δύο μέθοδοι για τον χειρισμό εξαιρέσεων - χρήση τιμών κατάστασης για τον εντοπισμό συνθηκών σφάλματος και χρήση ενός χειριστή εξαιρέσεων για την παγίδευση συνθηκών σφαλμάτων και τη διόρθωσή τους.

Επισκόπηση των αρχιτεκτονικών RTOS

Κατά τη διάρκεια της ιστορίας της, η αρχιτεκτονική του λειτουργικού συστήματος έχει υποστεί σημαντική ανάπτυξη. Μία από τις πρώτες αρχές κατασκευής, μονολιθικόςΤο ΛΣ (Εικόνα 1) συνίστατο στην παρουσίαση του ΛΣ ως ένα σύνολο μονάδων που αλληλεπιδρούν μεταξύ τους με διάφορους τρόπους εντός του πυρήνα του συστήματος και παρέχουν σε προγράμματα εφαρμογών διεπαφές εισόδου για πρόσβαση στο υλικό.

επίπεδο ΛΣ (Εικόνα 2) Ένα παράδειγμα τέτοιου ΛΣ είναι καλό γνωστό σύστημα MS-DOS. Σε συστήματα αυτής της κλάσης, οι εφαρμογές εφαρμογών μπορούσαν να έχουν πρόσβαση στο υλικό όχι μόνο μέσω του πυρήνα του συστήματος ή των υπηρεσιών του, αλλά και απευθείας. Τα RTOS έχουν χτιστεί πάνω σε αυτή την αρχή εδώ και πολλά χρόνια. Σε σύγκριση με τα μονολιθικά λειτουργικά συστήματα, αυτή η αρχιτεκτονική παρέχει σημαντικά μεγαλύτερο βαθμό προβλεψιμότητας των αντιδράσεων του συστήματος και επιτρέπει επίσης στις εφαρμογές εφαρμογών να έχουν γρήγορη πρόσβαση στο υλικό. Μειονέκτημα

Αυτό που κάνει τέτοια συστήματα τόσο άσχημα είναι η έλλειψη πολλαπλών εργασιών. Μέσα σε αυτήν την αρχιτεκτονική, το πρόβλημα της επεξεργασίας ασύγχρονων γεγονότων περιορίστηκε στην αποθήκευση μηνυμάτων στην προσωρινή μνήμη και στη συνέχεια στη διαδοχική δημοσκόπηση των buffer και στην επεξεργασία τους. Ταυτόχρονα, η συμμόρφωση με τις κρίσιμες προθεσμίες εξυπηρέτησης διασφαλίζεται από την υψηλή απόδοση του συμπλέγματος υπολογιστών σε σύγκριση με την ταχύτητα των εξωτερικών διεργασιών.

Εικόνα 2. Αρχιτεκτονική λειτουργικού συστήματος σε επίπεδα

Μία από τις πιο αποτελεσματικές αρχιτεκτονικές για την κατασκευή λειτουργικών συστημάτων σε πραγματικό χρόνο είναι η αρχιτεκτονική πελάτη-διακομιστή. Γενικό σχήμαΈνα λειτουργικό σύστημα που λειτουργεί χρησιμοποιώντας αυτήν την τεχνολογία φαίνεται στο Σχήμα 3. Η κύρια αρχή αυτής της αρχιτεκτονικής είναι η μεταφορά των υπηρεσιών OS με τη μορφή διακομιστών στο επίπεδο χρήστη και ο μικροπυρήνας λειτουργεί ως διαχειριστής μηνυμάτων μεταξύ προγραμμάτων-πελάτη χρηστών και διακομιστών - συστήματος Υπηρεσίες. Αυτή η αρχιτεκτονική παρέχει πολλά πλεονεκτήματα όσον αφορά τις απαιτήσεις για RTOS και ενσωματωμένα συστήματα. Μεταξύ αυτών των πλεονεκτημάτων είναι:

1. Η αξιοπιστία του ΛΣ αυξάνεται, γιατί Κάθε υπηρεσία είναι, στην πραγματικότητα, μια ανεξάρτητη εφαρμογή και είναι πιο εύκολο να εντοπιστούν σφάλματα και να παρακολουθηθούν σφάλματα.

2. Ένα τέτοιο σύστημα κλιμακώνεται καλύτερα γιατί περιττές υπηρεσίεςμπορεί να αποκλειστεί από το σύστημα χωρίς να επηρεαστεί η απόδοσή του.

3. Η ανοχή σφαλμάτων του συστήματος αυξάνεται, γιατί Μια παγωμένη υπηρεσία μπορεί να επανεκκινηθεί χωρίς

επανεκκινήστε το σύστημα.

Εικόνα 3. Δημιουργία λειτουργικού συστήματος χρησιμοποιώντας αρχιτεκτονική πελάτη-διακομιστή

Δυστυχώς, σήμερα δεν υπάρχουν πολλά λειτουργικά συστήματα που εφαρμόζονται στην αρχή πελάτη-διακομιστή. Μεταξύ των γνωστών RTOS που υλοποιούν αρχιτεκτονική μικροπυρήνων είναι το OS9 και το QNX.

Λίστα χρησιμοποιημένης βιβλιογραφίας:

1) http://ru.wikipedia.org/wiki/Real_time_operating system

2) http://www.asutp.ru/?p=600591

3) http://www.mka.ru/?p=40774

4) http://www.4stud.info/rtos/lecture1.html

5)http://www.ozon.ru/context/detail/id/3092042/

Η επιλογή για αεροπορική υπηρεσία είναι εξαιρετικά αυστηρή και αφορά όχι μόνο το προσωπικό πτήσης, αλλά και τα λειτουργικά συστήματα σε πραγματικό χρόνο (RT OS). Ας εξετάσουμε ποιες απαιτήσεις επιβάλλονται στα συστήματα εμπορικής αεροπορίας από οργανισμούς που είναι υπεύθυνοι για την ασφάλεια των πτήσεων. Χωρίς αμφιβολία, αυτό θα βοηθήσει στην κατανόηση των απαιτήσεων που είναι απαραίτητες για πολλούς άλλους κλάδους - όπου απαιτείται γρήγορη ανταπόκριση σε γεγονότα, υψηλή αξιοπιστία, δυνατότητα επιβίωσης και ασφάλεια των εργαλείων που χρησιμοποιούνται, συμπεριλαμβανομένου του λογισμικού.

Η Ομοσπονδιακή Υπηρεσία Αεροπορίας των ΗΠΑ, ένας από τους έγκυρους οργανισμούς που είναι υπεύθυνοι για την ασφάλεια των πτήσεων, έχει αυστηρές απαιτήσεις για εμπορικά λειτουργικά συστήματα σε πραγματικό χρόνο που υιοθετούνται για λειτουργία (ειδικά για την πολιτική αεροπορία, όπου η ζωή εκατοντάδων επιβατών εξαρτάται από τη λειτουργία τους). Ανάμεσα τους:

• «σκληρές» απαιτήσεις σε πραγματικό χρόνο. ντετερμινιστική συμπεριφορά κάτω από διάφορα φορτία συστήματος, που απαιτείται σε κρίσιμες για την αποστολή εφαρμογές και συστήματα υψηλής διαθεσιμότητας.
• υψηλή «επιβιωσιμότητα» έτσι ώστε εάν κάποιο μέρος του λογισμικού αποτύχει, το άλλο μέρος συνεχίζει να λειτουργεί κανονικά.
• αυστηρές απαιτήσεις ποιότητας, που σημαίνει συμμόρφωση με διάφορα βιομηχανικά, εθνικά και διεθνή πρότυπα.
• απαιτήσεις αξιοπιστίας· η πιθανότητα αποτυχίας προγράμματος πρέπει να είναι πολύ μικρή.
• απαιτήσεις για την ασφάλεια και το απόρρητο δεδομένων· Το σύστημα πρέπει να παρέχει μέσα για την προστασία των πιο σημαντικών πληροφοριών.

Σύστημα ρύθμισης απαιτήσεων

Ας απαριθμήσουμε τα κύρια έγγραφα που ρυθμίζουν τις απαιτήσεις για λειτουργικά συστήματα σε πραγματικό χρόνο στον τομέα της αεροπορίας.

Πρότυπο DO-178 - Εξέταση λογισμικού σε αερομεταφερόμενα συστήματα και πιστοποίηση εξοπλισμού.Αναπτύχθηκε και συντηρείται από την Ραδιοτεχνική Επιτροπή Αεροναυπηγικής (RTCA, www.rtca.org). Το πρότυπο ορίζει πέντε επίπεδα σοβαρότητας αστοχίας, για καθένα από τα οποία καθορίζεται ένα σύνολο απαιτήσεων λογισμικού, σχεδιασμένων να διασφαλίζουν τη λειτουργικότητα ολόκληρου του συστήματος στο σύνολό του όταν συμβαίνουν αστοχίες αυτού του επιπέδου:

επίπεδο Α- προστασία από αστοχίες που οδηγούν σε καταστροφικές συνέπειες.

επίπεδο Β- προστασία από αστοχίες που οδηγούν σε επικίνδυνες συνέπειες.

επίπεδο Γ- προστασία από αστοχίες που οδηγούν σε μεγάλες συνέπειες.

επίπεδο Δ- προστασία από αστοχίες που οδηγούν σε ελάχιστες συνέπειες.

επίπεδο Ε- προστασία από βλάβες που δεν έχουν συνέπειες.

Πρότυπο ED-12B.Ευρωπαϊκό ανάλογο του DO-178B. Καθορίστηκε από την ένωση The European Organization for Civil Aviation Equipment (EUROCAE, www.eurocae.org).

RTCA DO-248B - Τελική ετήσια έκθεση για διευκρίνιση του DO-178B.Επεξηγηματικό έγγραφο για το DO-178B. Τα κύρια θέματα του περιλαμβάνουν τομείς όπως λογισμικό που έχει αναπτυχθεί προηγουμένως, εμπορικά προϊόντα λογισμικού, διαδικασίες επαλήθευσης, ιστορικές πληροφορίες, αυτοματοποιημένα εργαλεία κ.λπ.

Πρότυπο DO-254 - Οδηγίες διασφάλισης σχεδίασης για αερομεταφερόμενο ηλεκτρονικό υλικό.Αναπτύχθηκε και συντηρείται από την RTCA. Το έγγραφο έχει σχεδιαστεί για να βοηθήσει τους κατασκευαστές αεροσκαφών και τους προμηθευτές ηλεκτρονικών ειδών να διασφαλίσουν ότι ο ηλεκτρονικός εξοπλισμός τους εκτελεί με ασφάλεια τις απαιτούμενες λειτουργίες του. Το έγγραφο ρυθμίζει τις διαδικασίες του κύκλου ζωής του υλικού και περιγράφει τρόπους διασφάλισης των απαιτούμενων ιδιοτήτων των προϊόντων προκειμένου να πιστοποιηθούν σύμφωνα με τις απαιτήσεις.

ARINC 653 - Τυπική διεπαφή λογισμικού εφαρμογής Avionics.Αναπτύχθηκε από την ARINC το 1997 και ορίζει μια διεπαφή λογισμικού καθολικής εφαρμογής APEX (Application/EXecutive) μεταξύ του λειτουργικού συστήματος του υπολογιστή και του λογισμικού εφαρμογής. Οι απαιτήσεις διεπαφής ορίζονται για να επιτρέπουν στα προγράμματα εφαρμογής να ελέγχουν την αποστολή, την επικοινωνία και την κατάσταση των στοιχείων εσωτερικής επεξεργασίας. Ως μία από τις βασικές απαιτήσεις για λειτουργικά συστήματα σε πραγματικό χρόνο στην αεροπορία, το ARINC 653 εισάγει μια αρχιτεκτονική εικονικής μηχανής διαμερισμάτων.

Κοινά κριτήρια για την αξιολόγηση του απορρήτου των τεχνολογιών πληροφοριών (Κοινά Κριτήρια για πληροφορίεςΑξιολόγηση Τεχνολογικής Ασφάλειας). Ένα σύνολο απαιτήσεων και όρων μυστικότητας ( www.commoncriteria.org), εγκεκριμένο από την Υπηρεσία Εθνικής Ασφάλειας των ΗΠΑ και το Εθνικό Ινστιτούτο Προτύπων και Τεχνολογίας των ΗΠΑ, καθώς και από αρμόδιες αρχές σε άλλες χώρες (επί του παρόντος 13 άλλες χώρες εκτός από τις ΗΠΑ). Το 1999, τα «Γενικά Κριτήρια» έλαβαν το καθεστώς του διεθνούς προτύπου ISO 15408.

MILS - Πολλαπλά ανεξάρτητα επίπεδα ασφάλειας/ασφάλειας.Αναπτύσσεται μέσω των προσπαθειών ενδιαφερόμενων οργανισμών, όπως το Ερευνητικό Εργαστήριο Πολεμικής Αεροπορίας των ΗΠΑ, η Lockheed Martin, η Υπηρεσία Εθνικής Ασφάλειας των ΗΠΑ κ.λπ. Το έργο MILS καθιστά δυνατή τη μαθηματική επαλήθευση του πυρήνα λογισμικού ενός συστήματος μειώνοντας τη λειτουργικότητα κατά επιβάλλοντας τέσσερις υποχρεωτικές ομάδες απαιτήσεων στα συστήματα (Ροή πληροφοριών, Απομόνωση δεδομένων, Επεξεργασία περιόδου, Περιορισμός ζημιών). Η αρχιτεκτονική MILS είναι ένα σύστημα με μεμονωμένα διαμερίσματα, καθένα από τα οποία περιλαμβάνει τον πυρήνα, το ενδιάμεσο λογισμικό και την εφαρμογή (Εικόνα 1).

Ρύζι. 1. Αρχιτεκτονική MILS

POSIX - Διασύνδεση φορητού λειτουργικού συστήματος για unIX.Καθορίζει μια φορητή διεπαφή λειτουργικού συστήματος σε επίπεδο κείμενα πηγής. Η βασική προδιαγραφή έχει αναπτυχθεί ως IEEE 1003.1 και έχει εγκριθεί ως Διεθνές πρότυπο ISO/IEC 9945-1:1990. Από την άποψη των λειτουργικών συστημάτων σε πραγματικό χρόνο, τρία πρότυπα παρουσιάζουν μεγαλύτερο ενδιαφέρον: 1003.1a (Ορισμός λειτουργικού συστήματος), 1003.1b (Επεκτάσεις σε πραγματικό χρόνο) και 1003.1c (Νήματα).

Έννοια μεμονωμένης κατάτμησης

Από πολλές απόψεις, τα κανονιστικά έγγραφα αλληλοεπικαλύπτονται και αλληλοσυμπληρώνονται. Ως αποτέλεσμα πολυάριθμων μελετών, η έννοια των μεμονωμένων κατατμήσεων υιοθετήθηκε ως η κύρια. Η ικανοποίηση των απαιτήσεων σκληρής απομόνωσης πρέπει να «αποδεικνύεται» από τους παρόχους λύσεων λογισμικού σύμφωνα με τη μεθοδολογία πιστοποίησης που περιγράφεται στο DO-178B. Υπάρχουν διάφορες προσεγγίσεις για την υλοποίηση μεμονωμένων κατατμήσεων, αλλά σήμερα η αρχιτεκτονική που υιοθετείται είναι η ARINC 653, η οποία ορίζει την υποστήριξη απομόνωσης για ένα λειτουργικό σύστημα σε πραγματικό χρόνο και χρησιμοποιεί C και Ada-95 ως γλώσσα περιγραφής.

Από την σκοπιά ενός χρήστη, το ARINC 653 είναι μια προδιαγραφή διεπαφής APEX (εφαρμογή/EXecutive) και δεν καθορίζει την υλοποίησή του. Έτσι, ορισμένοι προμηθευτές λογισμικού υλοποιούν την αποστολή χρησιμοποιώντας έναν αποστολέα ενός επιπέδου, άλλοι χρησιμοποιώντας έναν αποστολέα δύο επιπέδων, όταν το πρώτο επίπεδο διαχειρίζεται κατατμήσεις και το δεύτερο διαχειρίζεται διεργασίες σε κάθε διαμέρισμα. Αυτή η κατάσταση με την υποστήριξη ARINC 653 συνεπάγεται δυσκολίες πιστοποίησης προϊόντα λογισμικούσυμβατό μόνο με το ARINC 653 - το ίδιο API μπορεί να αντιστοιχιστεί σε διαφορετικές προσεγγίσεις υλοποίησης. Ως αποτέλεσμα, έχουν προκύψει πολλά πολύ διαφορετικά λειτουργικά συστήματα σε πραγματικό χρόνο, τα οποία ωστόσο συμμορφώνονται με την προδιαγραφή ARINC 653.

Στο Σχ. Το σχήμα 2 δείχνει την αρχιτεκτονική ενός συστήματος με πολλά απομονωμένα διαμερίσματα, καθένα από τα οποία αντιπροσωπεύει μια ανεξάρτητη εφαρμογή. Όλα τα δεδομένα και ο κώδικας σε κάθε ενότητα συλλέγονται μαζί και εκτελούνται σε λειτουργία χρήστη. Τα στοιχεία Module Operating System (MOS) και Board Support Package (BSP) εκτελούνται σε λειτουργία επόπτη. Επιπλέον, μπορεί να υπάρχει μια ειδική ενότητα με ορισμένες ειδικά χαρακτηριστικά, όπως εγκαταστάσεις εισόδου/εξόδου και εναλλαγής λειτουργίας.

Το ARINC 653 ορίζει με ακρίβεια τη διεπαφή για την ανταλλαγή πληροφοριών μεταξύ των κατατμήσεων, καθένα από τα οποία αντιπροσωπεύει μια εφαρμογή συν το λειτουργικό σύστημα διαμερισμάτων (POS). Αυτή η διεπαφή πρέπει να διασφαλίζει την απομόνωση των ακόλουθων στοιχείων.

ΕΜΒΟΛΟ.Σε κάθε διαμέρισμα εκχωρείται ένας συνεχόμενος γραμμικός φυσικός χώρος διευθύνσεων, τα όρια του οποίου δεν μπορούν να αλλάξουν κατά τη λειτουργία του συστήματος. Για κάθε διαμέρισμα, η εκχώρηση και η εκχώρηση μνήμης εκτελούνται και ελέγχονται από το MOS. Το λειτουργικό σύστημα σε πραγματικό χρόνο πρέπει να παρέχει απομόνωση πληροφοριών στο χώρο διευθύνσεων μέσα σε ένα γραμμικό «κομμάτι» που εκχωρείται σε κάθε τμήμα. Αυτό ισχύει για τον κώδικα προγράμματος, τις σταθερές, τα στατικά δεδομένα, τη στοίβα και το σωρό (την περιοχή από την οποία λαμβάνεται η μνήμη όταν ζητηθεί).

Χρόνος χρήσης CPU.Οι διεργασίες σε ένα διαμέρισμα μπορεί είτε να μην επηρεάζουν καθόλου τη συμπεριφορά των διεργασιών σε ένα άλλο διαμέρισμα είτε να τις επηρεάζουν με προκαθορισμένο και ελεγχόμενο τρόπο (για παράδειγμα, ορίζοντας ορισμένες σημαίες ή συνθήκες). Το ARINC 653 απαιτεί ο χρόνος του επεξεργαστή να κατανέμεται σε κάθε διαμέρισμα σε αυστηρά κυκλική βάση και ο χρόνος ιδιοκτησίας του επεξεργαστή για κάθε διαμέρισμα πρέπει να προσδιορίζεται εκ των προτέρων στον πίνακα διαμόρφωσης. Μέσα σε κάθε διαμέρισμα, οι διεργασίες μπορούν να ανταγωνίζονται για τον χρόνο της CPU με βάση τις προτεραιότητες ("preempt") χρησιμοποιώντας τον προγραμματισμό προληπτικής προτεραιότητας.

Κωδικός προγράμματος.Για ορισμένες περιοχές μνήμης, το MOS ορίζει το χαρακτηριστικό "execute-only" σε λειτουργία επόπτη. Αυτό σημαίνει ότι οι εφαρμογές λειτουργίας χρήστη δεν μπορούν να καταστρέψουν την περιοχή κώδικα.

Διακόπτει.Οι διακοπές είναι ασύγχρονα συμβάντα που απαιτούν ιδιαίτερη προσοχή για να διασφαλιστεί η απομόνωση του τμήματος. Είναι σημαντικό να μην «παραβιάζουν» τον χρόνο και τη μνήμη σε άλλη ενότητα. Ενας από πιθανές πηγέςΟι διακοπές είναι χρονόμετροι που ελέγχουν την αποστολή των συμβάντων τόσο εντός του POS όσο και εντός του MOS.

Έχουν εγκριθεί ορισμένες συμβάσεις για την παροχή απομόνωσης διακοπών. Οι διακοπές του χρονοδιακόπτη συμβαίνουν μόνο σε λειτουργία επόπτη. Δεν είναι δυνατή η άμεση πρόσβαση στο ρολόι σε λειτουργία χρήστη. Εάν το POS και το MOS βρίσκονται σε διαφορετικά επίπεδα ασφάλειας, τότε πρέπει να παρέχεται ένας μηχανισμός για τη διανομή πληροφοριών σχετικά με προσωρινά συμβάντα σε διαμερίσματα εφαρμογών που εκτελούνται σε λειτουργία χρήστη. Σε εκείνες τις στιγμές που η ενότητα είναι ενεργή (κατέχει την ώρα του επεξεργαστή), όλα τα χρονικά συμβάντα που σχετίζονται με αυτήν θα πρέπει να μεταδίδονται σε αυτήν. Όταν ένα διαμέρισμα είναι ανενεργό, όλα τα προσωρινά συμβάντα που σχετίζονται με αυτό πρέπει να αποθηκευτούν και στη συνέχεια να μεταφερθούν σε αυτό όταν ενεργοποιηθεί.

Μια άλλη πηγή διακοπών είναι οι εξωτερικές συσκευές I/O. Σύμφωνα με τις απαιτήσεις του ARINC 653, συνιστάται η χρήση αλγόριθμου ψηφοφορίας συσκευών για συσκευές με σύγχρονη μεταφορά δεδομένων. Ωστόσο, ορισμένες συσκευές απαιτούν χειρισμό διακοπών. Αυτές οι διακοπές πρέπει να αντιμετωπίζονται από το MOS και στη συνέχεια να μεταδοθούν στο POS όταν ενεργοποιηθεί το διαμέρισμα. Προφανώς, μπορεί να προκύψουν χρονικές καθυστερήσεις, ακόμη και απώλεια πληροφοριών, και ως εκ τούτου ο σχεδιαστής πρέπει να το λάβει υπόψη του.

Το ARINC 653 ορίζει όχι μόνο τις απαιτήσεις για την απομόνωση των κατατμήσεων, αλλά και τους μηχανισμούς αλληλεπίδρασης μεταξύ τους. Εισήχθη παρακάτω λειτουργίεςαλληλεπιδράσεις μεταξύ των τμημάτων:

ανταλλαγή μηνυμάτωνμε τη δημιουργία ενός καναλιού επικοινωνίας, το οποίο πρέπει να περιγραφεί εκ των προτέρων στον πίνακα διαμόρφωσης του συστήματος.

ανταλλαγή μέσω buffer, στο οποίο μόνο ένα διαμέρισμα μπορεί να γράψει σε ένα συγκεκριμένο buffer και όλα τα άλλα μπορούν μόνο να διαβάσουν. Αυτό παρέχει τη δυνατότητα μετάδοσης πληροφοριών μεταξύ των κατατμήσεων.

Πρότυπο DO-178B

Το πρότυπο DO-178B περιγράφει τεχνικές και μεθόδους για τη διασφάλιση της ακεραιότητας και της αξιοπιστίας του λογισμικού, καλύπτοντας όλα τα στάδια του κύκλου ζωής του - σχεδιασμό, ανάπτυξη απαιτήσεων, σχεδιασμό, κωδικοποίηση, ενοποίηση και δοκιμή.

Ο σχεδιασμός του DO-178B πρέπει να περιλαμβάνει τα ακόλουθα σχέδια: ένα σχέδιο για πτυχές του προγράμματοςπιστοποίηση; σχέδιο έργου λογισμικού· σχέδιο επαλήθευσης λογισμικού· σχέδιο διαχείρισης διαμόρφωσης λογισμικού· σχέδιο διασφάλισης ποιότητας λογισμικού. Καθ' όλη τη διάρκεια του κύκλου ζωής, πρέπει να διασφαλίζεται η συμμόρφωση με το πρότυπο DO-178 στους τομείς της δήλωσης απαιτήσεων, του σχεδιασμού, της κωδικοποίησης, της επαλήθευσης και της τεκμηρίωσης. Πρέπει να αναπτυχθούν απαιτήσεις λογισμικού (απαιτήσεις υψηλού επιπέδου), σχεδιασμός λογισμικού (απαιτήσεις και αρχιτεκτονική), κώδικας προγράμματος σε μορφή πηγής και αντικειμένου. Κάθε ένα από τα αναπτυγμένα στοιχεία πρέπει να επαληθεύεται σύμφωνα με διάφορα κριτήρια. Η επαλήθευση των απαιτήσεων λογισμικού υψηλού επιπέδου περιλαμβάνει τον έλεγχο των ακόλουθων συνθηκών: οι απαιτήσεις πληρούν τις απαιτήσεις του συστήματος και είναι διαθέσιμες για ανάλυση μαζί με Απαιτήσεις συστήματος; οι απαιτήσεις είναι ακριβείς και συνεπείς· οι απαιτήσεις είναι συμβατές με το υλικό και επομένως πρέπει να υποστηρίζονται από αποτελέσματα.

Η επαλήθευση σχεδίασης λογισμικού περιλαμβάνει την επαλήθευση ότι οι απαιτήσεις σχεδιασμού πληρούν τις απαιτήσεις υψηλού επιπέδου και μπορούν να αναλυθούν, να είναι ακριβείς και συνεπείς και επομένως μπορούν να υποστηριχθούν από αποτελέσματα. Ομοίως, η αρχιτεκτονική και ο κώδικας λογισμικού πρέπει να επαληθεύονται και πρέπει επίσης να πληρούν τις απαιτήσεις που ορίζονται στο DO-178B. Αυτό το πρότυπο ορίζει τη διαδικασία επαλήθευσης του σταδίου ενοποίησης λογισμικού, ελέγχοντας την πληρότητα της ίδιας της διαδικασίας επαλήθευσης, παρέχοντας διαχείριση διαμόρφωσης (συμπεριλαμβανομένου του ελέγχου έκδοσης) και πιστοποιώντας αυτοματοποιημένα εργαλεία.

Το πρότυπο ορίζει τρία επίπεδα δοκιμής δομικού κώδικα:

• Κάλυψη δήλωσης σημαίνει ότι κάθε δήλωση σε ένα πρόγραμμα καλείται τουλάχιστον μία φορά.
• κάλυψη απόφασης σημαίνει ότι κάθε σημείο εισόδου και εξόδου στο πρόγραμμα εκτελέστηκε τουλάχιστον μία φορά και ότι κάθε απόφαση στο πρόγραμμα λάμβανε όλες τις πιθανές (Boolean) τιμές εξόδου τουλάχιστον μία φορά.
• Η κάλυψη λύσεων με μια τροποποιήσιμη συνθήκη σημαίνει ότι κάθε σημείο εισόδου και εξόδου στο πρόγραμμα εκτελέστηκε τουλάχιστον μία φορά, ότι κάθε απόφαση στο πρόγραμμα λάμβανε όλες τις πιθανές (Boolean) τιμές εξόδου τουλάχιστον μία φορά και ότι κάθε συνθήκη στη λύση είχε ως αποτέλεσμα σε μια ανεξάρτητη αλλαγή στις έννοιες εξόδου.

Τα επίπεδα πιστοποίησης που ορίζονται στο DO-178B διαφέρουν ως προς τον αριθμό των απαιτήσεων (βάθος επαλήθευσης) που πρέπει να ικανοποιεί το λογισμικό. Οι θεωρητικές πτυχές της επαλήθευσης του κώδικα παρουσιάζονται σε διάφορες θεμελιώδεις μονογραφίες, ιδίως στο έργο.

Η πιστοποίηση στο DO-178B πρέπει να διενεργείται από τους λεγόμενους Αντιπροσώπους Μηχανικών, οι οποίοι διορίζονται από την FAA για να επανεξετάσουν τα δεδομένα που χρησιμοποιούνται στην πιστοποίηση. Ο προγραμματιστής επιδιώκει να λάβει πιστοποίηση του λογισμικού του σύμφωνα με το DO-178B προκειμένου να λάβει άδεια χρήσης του λογισμικού του (συμπεριλαμβανομένου του λειτουργικού συστήματος σε πραγματικό χρόνο) στην αεροπορία. Η άδεια ισχύει όχι μόνο για το λογισμικό, αλλά για ολόκληρο το προϊόν (έργο) ως σύνολο. Για να ξεκινήσει η διαδικασία πιστοποίησης, ένας προγραμματιστής πρέπει πρώτα να «ανοίξει» ένα έργο και να λάβει έναν επίσημο αριθμό έργου από την FAA ή να συμμετάσχει σε ένα υπάρχον έργο με έναν ήδη εκδοθέν αριθμό έργου. Για να "ανοίξετε" ένα έργο, πρέπει να αποκτήσετε ένα πιστοποιητικό τύπου ή ένα πρόσθετο πιστοποιητικό τύπου. Συνήθως, ένα πιστοποιητικό τύπου εκχωρείται σε ένα αεροσκάφος και όλος ο εξοπλισμός σε αυτό συνοδεύεται από αυτό το πιστοποιητικό. Ένα πρόσθετο πιστοποιητικό τύπου χορηγείται σε πρόσθετο εξοπλισμό στο αεροσκάφος, συμπεριλαμβανομένου λογισμικού.

«Γενικά κριτήρια» για την αξιολόγηση του απορρήτου

Τα Κοινά Κριτήρια ορίζουν τα Επίπεδα Διασφάλισης Αξιολόγησης (EAL) και αξιολογούν όχι μόνο την ασφάλεια και την αξιοπιστία των προϊόντων, αλλά και τις διαδικασίες ανάπτυξης και υποστήριξής τους για να διασφαλιστεί ότι τα προβλήματα επιλύονται γρήγορα. Για λειτουργικά συστήματα, οι απαιτήσεις των Γενικών Κριτηρίων αναφέρονται αναλυτικά στο . Υπάρχουν επτά επίπεδα εγγύησης απορρήτου:

EAL1 (λειτουργικά ελεγμένο)- ισχύει όταν απαιτείται ελάχιστη εμπιστευτικότητα, αλλά το απόρρητο δεν θεωρείται σημαντική απαίτηση.

EAL2 (δομικά ελεγμένο)- ισχύει σε περιπτώσεις όπου οι προγραμματιστές ή οι χρήστες απαιτούν ένα μέσο επίπεδο εγγυημένης μυστικότητας ελλείψει πλήρεις πληροφορίεςγια όλες τις διαδικασίες ανάπτυξης·

EAL3 (μεθοδικά ελεγμένο και ελεγμένο)- ισχύει όταν οι προγραμματιστές ή οι χρήστες απαιτούν μεσαίο επίπεδο εγγυημένης μυστικότητας και απαιτούν εξαντλητική μελέτη του λειτουργικού συστήματος και των σταδίων ανάπτυξής του, χωρίς όμως να καταφεύγουν σε σημαντική επανεπεξεργασία του λειτουργικού συστήματος.

EAL4 (μεθοδικά σχεδιασμένο, δοκιμασμένο και αναθεωρημένο)- ισχύει σε περιπτώσεις όπου οι προγραμματιστές ή οι χρήστες απαιτούν υψηλό επίπεδο εγγυημένης μυστικότητας του λειτουργικού συστήματος και απαιτούν ειδική τροποποίηση του υπάρχοντος λειτουργικού συστήματος για την ικανοποίηση αυτών των απαιτήσεων.

EAL5 (ημιεπίσημα σχεδιασμένο και δοκιμασμένο)- ισχύει όταν οι προγραμματιστές ή οι χρήστες απαιτούν υψηλό επίπεδο εγγυημένης μυστικότητας του λειτουργικού συστήματος και αυστηρή προσέγγιση στο σχεδιασμό, έτσι ώστε αυτές οι ιδιότητες να ενσωματώνονται ήδη στο στάδιο του σχεδιασμού, χρησιμοποιώντας ειδικά μέσα διασφάλισης του απορρήτου.

EAL6 (ημιεπίσημα επαληθευμένο, σχεδιασμένο και δοκιμασμένο)- εφαρμόζεται όταν υπάρχει υψηλό επίπεδο επικίνδυνων καταστάσεων και όπου δικαιολογείται υψηλό κόστος προστασίας από μη εξουσιοδοτημένη πρόσβαση·

EAL7 (επίσημα επαληθευμένο, σχεδιασμένο και δοκιμασμένο)- θα πρέπει να χρησιμοποιείται σε εφαρμογές με πολύ υψηλό κόστος σε περίπτωση μη εξουσιοδοτημένης πρόσβασης.

Το επίπεδο EAL επιβεβαιώνεται από ειδικό εργαστήριο, το Common Criteria Testing Lab.

Ο πίνακας δείχνει μια λίστα με τις μέγιστες απαιτήσεις εγγύησης ασφάλειας που πρέπει να πληροί το σύστημα σε επίπεδο EAL7.

Σύστημα LynxOS-178

Το LynxOS-178 βασίζεται στο λειτουργικό σύστημα LynxOS v.3 σε πραγματικό χρόνο, το οποίο εκτελείται σε ένα απομονωμένο διαμέρισμα. Το LynxOS v.3 είναι πιστοποιημένο με POSIX 1003.1-1996 στις πλατφόρμες Intel και PowerPC.

Ένα βασικό χαρακτηριστικό του LynxOS-178 είναι η υποστήριξη πολλαπλών κατατμήσεων που διαχωρίζονται πλήρως σε χρόνο, μνήμη και πόρους σύμφωνα με τις απαιτήσεις του ARINC 653. Το LynxOS-178 (έκδοση 2.0) υποστηρίζει: έως και 16 κατατμήσεις (εικονικές μηχανές), συμπεριλαμβανομένων το ριζικό διαμέρισμα. έως 64 διαδικασίες. έως 51 νήματα σε κάθε διαδικασία. αποστολή νημάτων σε ένα διαμέρισμα σε πραγματικό χρόνο. λειτουργίες επικοινωνίας μεταξύ διεργασιών μέσα σε ένα διαμέρισμα.

Κάθε διαμέρισμα είναι εντελώς απομονωμένο, καθιστώντας αδύνατη τη διάδοση σφαλμάτων μεταξύ των κατατμήσεων.

Με το LynxOS-178, τα σταθερά διαμερίσματα εξυπηρετούνται ως εικονικές μηχανές LynxOS. Κάθε διαδικασία εφαρμογής λειτουργεί μέσα στο δικό της περιβάλλον λειτουργικού συστήματος σαν να εκτελείται στον δικό της επεξεργαστή. Αυτό ισχύει για όλους τους πόρους της CPU και τους ονομασμένους χώρους. Αυτή η αφαίρεση προστατεύει τον προγραμματιστή της εφαρμογής από πρόσθετη προσπάθεια προγραμματισμού. πολύπλοκο σύστημα. Η διαχείριση διαμερισμάτων ελέγχεται μέσω του πίνακα ρύθμισης παραμέτρων εικονικής μηχανής (VCT) και είναι υποχρεωτική στο περιβάλλον LynxOS-178, επιτρέποντας στον προγραμματιστή εφαρμογών να επικεντρωθεί στην ανάπτυξη εφαρμογών αντί στην κατάτμηση του συστήματος. Επιπλέον, το LynxOS-178 υποστηρίζει διαμερισμό συστημάτων συμβατά με RTCA DO-255, επιτρέποντας σε λογισμικό με διαφορετικά επίπεδα ασφάλειας DO-178B να εκτελούνται σε διαφορετικά διαμερίσματα (εικονικές μηχανές). Αυτό σημαίνει ότι το λειτουργικό σύστημα μπορεί να εκτελέσει μια εφαρμογή επιπέδου Α (DO-178B) σε μια εικονική μηχανή και μια εφαρμογή επιπέδου Γ σε μια άλλη, με τις δύο εφαρμογές να εκτελούνται στον ίδιο επεξεργαστή στο ίδιο σύστημα.

Η έκδοση του LynxOS-178 που περιλαμβάνεται σε διάφορα προϊόντα (για παράδειγμα, το αεροσκάφος Bombardier Challenger 300 από την Rockwell Collins) είναι πιστοποιημένη σύμφωνα με το πρότυπο DO-178B και η αρχιτεκτονική του ίδιου του λειτουργικού συστήματος ( ρύζι. 3) πληροί τις απαιτήσεις ARINC 653.

Το LynxOS-178 παρέχει τις ακόλουθες ομάδες υπηρεσιών συστήματος σύμφωνα με το ARINC 653: Διαχείριση διαμερισμάτων - διαχείριση διαμερισμάτων, Διαχείριση διεργασιών - διαχείριση διαδικασιών, διαχείριση χρόνου - διαχείριση χρόνου, επικοινωνία διαμερισμάτων - αλληλεπίδραση διαδικασιών σε διαφορετικές ενότητες (Υπηρεσίες λιμένων δειγματοληψίας και θύρα αναμονής Υπηρεσίες), Intrapartition Communication - αλληλεπίδραση διεργασιών σε ένα διαμέρισμα (Buffer Services, Blackboard Services, Semaphore Services, Event Services), Health Monitoring - παρακολούθηση της υγείας του λειτουργικού συστήματος ή του εξοπλισμού.

Ένα πρωτότυπο λειτουργικό σύστημα που συναντά το EAL7 πρόκειται να κυκλοφορήσει το 2006. αναπτύσσεται ένας νέος πυρήνας LynxSecure, συμβατός με τις απαιτήσεις MILS, ο οποίος θα περιέχει μόνο 8 χιλιάδες γραμμές πηγαίος κώδικαςκαι θα συμμορφώνεται με τις απαιτήσεις EAL7.

Χωρίς αμφιβολία, οι εξεταζόμενες απαιτήσεις για λειτουργικά συστήματα σε πραγματικό χρόνο είναι πολύ σημαντικές για πολλές άλλες βιομηχανίες, όπως το ναυτικό, ο στρατός και διαστημικά συστήματα, συστήματα επικοινωνίας, εξοπλισμός υποστήριξης ζωής, συστήματα που προορίζονται για χρήση σε καταστάσεις έκτακτης ανάγκης - όπου απαιτείται γρήγορη απόκριση σε γεγονότα, υψηλή αξιοπιστία, ανθεκτικότητα και ασφάλεια των εργαλείων που χρησιμοποιούνται, συμπεριλαμβανομένου του λογισμικού.

Βιβλιογραφία

1. Εμπορικό Λειτουργικό Σύστημα Πραγματικού Χρόνου και Αρχιτεκτονική Θεώρηση. Τελική Έκθεση, Η.Π.Α. Ομοσπονδιακή Διοίκηση Αεροπορίας, DOT/FAA/AR-03/77, Φεβρουάριος 2004.
2. Διαμέριση στην αεροηλεκτρονική. Αρχιτεκτονική: Απαιτήσεις, Μηχανική και Διασφάλιση. Τελική Έκθεση, Εθνική Διοίκηση Αεροναυτικής και Διαστήματος, DOT/FAA/AR-99/58, NASA/CR-1999-209347, Μάρτιος 2000.
3. Μελέτη Εμπορικού Off-The-Self (COTS) Λειτουργικό Σύστημα Πραγματικού Χρόνου (RTOS) σε Εφαρμογή Αεροπορίας. Τελική Έκθεση, Η.Π.Α. Ομοσπονδιακή Διοίκηση Αεροπορίας, DOT/FAA/AR-02/118, Δεκέμβριος 2002.
4. Αξιολόγηση λειτουργικών συστημάτων σε πραγματικό χρόνο - ο ρόλος των προτύπων. Επιτροπή Τυποποίησης συστημάτων αεροσκαφών (ASSC), Doc No: ASSC/330/2/141, Μάρτιος 1997.
5. G. Mayers, The art of Software Testing. John Wiley & Sons, 1979.
6. COTS Security Protection Profile - Operating Systems (CSPP-OS), NISTIR 6985, Απρίλιος 2003.
7. Κοινά κριτήρια για την αξιολόγηση της ασφάλειας της πληροφορικής. Μέρος 3: Απαιτήσεις διασφάλισης ασφάλειας. Αύγουστος 1999, Έκδοση 2.1, CCIMB-99-033.

Σεργκέι Ζολοτάρεφ (ζ [email προστατευμένο]) - υπάλληλος της εταιρείας RTSoft (Μόσχα).

Αποφασίστηκε η αναβάθμιση του στρατηγικού βομβαρδιστικού ανεφοδιασμού μεγάλης εμβέλειας KC-135 Stratotanker για να διασφαλιστεί η συμμόρφωση με τους διεθνείς κανονισμούς διαχείρισης της εναέριας κυκλοφορίας και τις απαιτήσεις του προτύπου DO-178B. Το υλικό του Integrated Processing Center, που αναπτύχθηκε από την Rockwell Collins, παρέχει υπολογιστικές και δικτυακές δυνατότητες που μπορούν να χρησιμοποιηθούν για την εκτέλεση ποικίλων διαφορετικών εργασιών (υποστήριξη αποστολής, έλεγχος πτήσης, υποστήριξη οθόνης). Βασική λειτουργικότηταεπεκτείνεται, επιτρέποντας την υλοποίηση πρόσθετων εφαρμογών. Η ανταλλαγή δεδομένων με άλλο εξοπλισμό πραγματοποιείται μέσω της έκδοσης «αεροπορίας» του δικτύου Ethernet. Υπάρχουν αρκετές μονάδες με δυνατότητα αντικατάστασης γραμμής διαθέσιμες μέσα στο Ενσωματωμένο Κέντρο Επεξεργασίας. Το πιστοποιημένο λειτουργικό σύστημα σε πραγματικό χρόνο LynxOS-178 εκτελείται στην Κοινή Υπολογιστική Μονάδα και στη Μονάδα Συγκεντρωτή Εισόδου/Εξόδου.

Το αεροσκάφος δεξαμενόπλοιο KC-767, το οποίο χρησιμοποιεί επίσης το λειτουργικό σύστημα LynxOS-178, είναι έτοιμο να ανεβάσει τον εναέριο ανεφοδιασμό της Πολεμικής Αεροπορίας στο επόμενο επίπεδο και να αποσύρει τα κληρονομιά δεξαμενόπλοια KC-135E που βρίσκονται σε υπηρεσία για περισσότερες από τέσσερις δεκαετίες. Το νέο σκάφος δεν είναι μόνο πιο ευρύχωρο, αλλά και πιο αξιόπιστο, καθιστώντας το κατάλληλο για ένα ευρύτερο φάσμα λειτουργιών. Στην πραγματικότητα, το KC-767 είναι τέσσερα διαφορετικά αεροσκάφη σε ένα. Το κατάστρωμα όπου βρίσκεται η καμπίνα του πληρώματος μπορεί εύκολα να εξοπλιστεί για τη μεταφορά επιβατών ή φορτίου χωρίς να διακυβεύεται η λειτουργικότητα του δεξαμενόπλοιου. Επιπλέον, μπορεί να γίνει έτσι ώστε, ανάλογα με την περίπτωση, το πλοίο να είναι είτε επιβάτης, είτε φορτίο, είτε μεταφορέας μικτού τύπου.

Στην αγγλόφωνη βιβλιογραφία, χρησιμοποιούνται δύο όροι - ασφάλεια και ασφάλεια, οι οποίοι μπορούν να μεταφραστούν ομοίως στα ρωσικά. Ωστόσο, σημαίνουν διαφορετικά πράγματα, και σε αυτό το άρθρο θα χρησιμοποιήσουμε την ασφάλεια ως συνώνυμο της ασφάλειας και την ασφάλεια ως συνώνυμο της μυστικότητας. - Σημείωση αυτο