Sisteme de operare în timp real. Sisteme de operare în timp real pentru începători

Recenzie prezentată caracteristici comparative RTOS prezent pe piața rusă, în raport cu utilizarea în sistemele de control al aviației.

05.05.2008, Luni, 23:56, ora Moscovei

Datorită dezvoltării tehnologiei informatice în În ultima vreme A devenit posibilă atribuirea unui singur modul sarcini efectuate anterior de mai multe module de procesor, îmbunătățind în același timp caracteristicile de greutate și dimensiune ale sistemului de control și reducând costul acestuia. Această tendință în tehnologia aviației a dus la apariția conceptului de avionică modulară integrată - IMA (Integrated Modular Avionics, IMA).

Problema integrării funcțiilor de control într-un singur modul este că este necesar să se separe acum resurse partajate(timp procesor, memorie, canale de comunicare) între diferite sarcini, asigurând în același timp același nivel de fiabilitate și independență a funcțiilor ca înainte. Sistemul de operare în timp real joacă un rol cheie în rezolvarea acestei probleme.

În prezent, pe piața mondială există mai multe RTOS comerciale pentru aplicații critice (Tabelul 1). Acest articol oferă o prezentare generală a RTOS disponibile pe piața rusă, pe baza informațiilor din surse deschise și experienta personala autorii.

Documente care reglementează cerințele pentru RTOS

Standardul DO-178 (Software Consideration in Airborne Systems and Equipment Certification) definește cerințele pentru procesul de dezvoltare software și minuțiozitatea verificării acestuia în funcție de nivelul său de criticitate. Nivelul de criticitate software este determinat pe baza unei analize a severității consecințelor unei defecțiuni software. Există cinci niveluri de criticitate software în total (de la A la E).

MILS (Multiple Independent Levels of Security) este o abordare specială pentru proiectarea sistemului de operare, care previne propagarea erorilor aplicației software în timpul rulării și, de asemenea, simplifică verificarea programului datorită modularității software-ului. Toate aplicațiile sunt plasate în așa-numitele secțiuni (partiții). Partițiile au resurse alocate (zona de memorie, timpul procesorului în fiecare ciclu de sistem, acces la canalele de comunicație etc.). Accesul la resursele alocate este garantat de sistemul de operare care rulează în modul supervizor. Astfel, aplicațiile software cu diferite niveluri de criticitate pot rula pe un singur modul de procesor care rulează un sistem de operare - dacă apare o defecțiune în software-ul mai puțin critic (și, în consecință, mai puțin testat), acest lucru nu va afecta în niciun fel funcționarea altor secțiuni, deoarece încercările de a „uzurpa” resursele altor persoane vor fi blocate de sistemul de operare. Ideile MILS le fac ecou pe cele ale IMA și DO-178B.

Eroare 404: Pagina nu poate fi găsită.

Este posibil să se fi întâmplat din unul dintre aceste motive:

– eroare la introducerea adresei paginii (URL)
– în urma unui link „întrerupt” (nefuncțional, incorect).
– pagina solicitată nu a fost niciodată pe site sau a fost ștearsă

Puteți:

– reveniți utilizând butonul Înapoi al browserului
– verificați ortografia corectă a adresei paginii (URL)
– utilizați harta site-ului sau accesați pagina principală

Standardul ARINC-653 (Avionics Application Software Standard Interface) specifică o interfață software de aplicație APEX care acceptă un concept de partiție în stil MILS. Această interfață include funcții pentru gestionarea partițiilor, proceselor, partajarea timpului, comunicațiile între și în interiorul partițiilor și monitorizarea stării sistemului. Trebuie remarcat faptul că standardul ARINC-653 descrie o abordare general acceptată pentru implementarea ideilor MILS pentru IMA, deși pot exista și alte implementări. Un RTOS de aviație care respectă ARINC-653 are avantaje deoarece acest standard este bine cunoscut și înțeles de organismele internaționale de certificare, astfel încât este mai ușor să obțineți un certificat de conformitate DO-178B pentru un sistem construit conform acestui standard.

Standard pentru componente software reutilizabile. În conformitate cu DO-178B, software-ul unui anumit sistem de aplicație de aviație este supus întregii proceduri de certificare, chiar dacă utilizează module (componente) care au fost deja certificate anterior ca parte a unui alt sistem. Una dintre cele mai recente inițiative ale FAA (Agenția Federală de Certificare a Aviației, SUA) este definirea criteriilor pentru reutilizarea software-ului fără recertificare. Componentele care nu pot fi recertificate se numesc RSC (Componente software reutilizabile). Este nevoie de mai mult efort pentru a obține certificarea RSC, dar apoi RSC oferă economii semnificative.

Documente rusești care definesc cerințele software (inclusiv RTOS):

GOST R ISO/IEC 51904-2002 („Software pentru sisteme încorporate. Cerințe generale pentru dezvoltare și documentare") - un analog al DO-178B pentru aviația militară;
KT-178A ("Cerințe de calificare partea 178A") - un analog al DO-178B pentru aviația civilă;
GOST R ISO/IEC 12207-99 („Tehnologia informației. Procese ciclu de viață software").

Comparația RT OS a fost efectuată în funcție de 13 parametri, care iau în considerare criterii tehnice, ușurința dezvoltării și parametrii economici.

Parametrii de sincronizare a sistemului de operare

Una dintre principalele cerințe pentru RT OS este timpul minim de întârziere pentru procesarea unui eveniment. În practică, aceasta înseamnă că următorii parametri trebuie să fie mici:

timp de răspuns la întrerupere - timpul dintre apariția efectivă a întreruperii și începerea procesării primei instrucțiuni a operatorului de întrerupere;
control thread switching time - timpul de comutare între două fire într-un singur proces;
timpul de comutare a contextului procesului (numai pentru sistemele de operare care acceptă modelul de proces) - timp de comutare între două fire de control aparținând două procese diferite.

Din păcate, nu este ușor să comparați în mod obiectiv acești parametri ai diferitelor sisteme de operare RT, deoarece acești parametri depind nu numai de calitatea sistemului de operare, ci și de capacitățile platformei hardware utilizate. În mod ideal, toate sistemele de operare comparate ar trebui să fie instalate pe aceeași platformă hardware, după care ar trebui făcute măsurătorile corespunzătoare. Dar nici măcar aceste măsurători nu vor da un rezultat obiectiv, deoarece diferitele sisteme de operare pot fi mai mult sau mai puțin adaptate la un anumit hardware.

Pentru a compara parametrii de sincronizare, acest articol utilizează date fragmentate găsite pe Internet, care sunt adesea obținute la testarea sistemului de operare pe diverse echipamente, în timp ce compoziția și natura testelor nu sunt întotdeauna clare.

Rezultatele obținute de experții revistei Dedicated System, care au efectuat teste și comparatie practica QNX RTOS 6.1, VxWorks AE 1.1 și Windows CE.NET pe platforma x86. Deși aceste date sunt în prezent depășite, autorii acestui articol nu au putut găsi materiale mai recente. În tabel Figura 2 prezintă datele de comparație ale performanței selectate între QNX Neutrino 6.1 și VxWorks AE 1.1. Raportul Dedicated Systems a dat preferință QNX în ceea ce privește performanța, cu raportul de scor setat la 9:5 (QNX:VxWorks), deoarece în timpul testării au fost descoperite două erori în VxWorks, pentru care a fost necesar să contactați suportul pentru a le corecta.

În tabel 3 prezintă date despre caracteristicile LynxOS. Compoziția testelor utilizate nu este specificată. În ceea ce privește datele despre caracteristicile LynxOS, a patra coloană (testare pe platforma x86) este interesantă. În comparație cu VxWorks și QNX, sistemul de operare LynxOS RT prezintă o întârziere uriașă în răspunsul la întreruperi (de peste 5 ori). Timpul de schimbare a contextului (adică timpul de comutare între două fire într-un singur proces) este același cu QNX și este de aproximativ 1,5 ori mai mic decât VxWorks.

Stabilitatea parametrilor de sincronizare

Pe lângă caracteristicile de sincronizare, stabilitatea acestor caracteristici este, de asemenea, importantă pentru RT OS. Acest criteriu este cel care determină în mare măsură „rigiditatea” sistemului de operare RT, adică. predictibilitatea timpului de prelucrare a datelor, momentul emiterii rezultatelor etc.

Pe baza datelor din jurnalul Sistemului Dedicat, QNX este înaintea VxWorks în acest criteriu atât în ceea ce privește răspândirea caracteristicilor într-o serie de teste similare (raportul dintre timpul maxim și valoarea medie este semnificativ mai mic), cât și cu sarcina în creștere. (timpul de comutare a firelor când numărul de fire crește cu 2...128 de unități pentru QNX a crescut de numai 1,65 ori, în timp ce pentru VxWorks - de 2,24 ori).

Conform datelor obținute de la RTSoft, se știe că LynxOS are aproximativ aceleași caracteristici ca și VxWorks.

Gestionarea accesului la resurse

Să evaluăm calitatea controlului accesului oferit de unul sau altul RT OS resurselor critice ale sistemului de calcul, cum ar fi memoria și timpul procesorului.

Prima întrebare la care trebuie să se răspundă este dacă sistemul de operare acceptă modelul de proces. Un proces este o entitate logică care deține unul sau mai multe fire de execuție, resursele asociate acestora și contextul - conținutul registrelor și contoarelor la un moment dat.

Sarcina proceselor este:

în delimitarea accesului la RAM între diferite programe în timpul execuției;
în delimitarea domeniului de aplicare a variabilelor globale în momentul compilării (critic dacă aplicația software este scrisă în limbajul C, care nu suportă o astfel de delimitare).

Segmentarea oferă, de asemenea, separarea spațiilor de adrese (în acest sens, capacitățile de fragmentare și procese sunt duplicate). În plus, sharding oferă fiecărui segment care conține unul sau mai multe procese (sau fire de execuție dacă sistemul de operare nu acceptă modelul de proces) cu un buget de timp garantat. În acest fel, dacă un fir cu prioritate ridicată intră într-o buclă și își întrerupe segmentul, toate celelalte segmente vor primi timp CPU conform setărilor de proiectare și vor continua să funcționeze normal.

LynxOS și QNX acceptă atât modelul de proces, cât și fragmentarea. VxWorks OS are un mecanism de fragmentare, dar nu acceptă modelul de proces. În general, acest lucru este acceptabil deoarece sharding-ul asigură separarea spațiilor de adrese. Dar lipsa proceselor aduce unele inconveniente. În mod obișnuit, împărțirea în segmente se realizează în funcție de scopul propus al software-ului și de criticitatea acestuia. De exemplu, un anumit segment poate conține software de control pentru un sistem de navigație de zbor care are un nivel ridicat de criticitate. Dar acest software este și un complex destul de complex, care ar fi logic să fie împărțit în module independente (de memorie). Sistemul de operare VxWorks nu oferă această caracteristică, adică segmentul va fi format din fire de execuție cu memorie partajată, ceea ce complică organizarea dezvoltării paralele și, în cele din urmă, reduce fiabilitatea software-ului.

Suport pentru multiprocesor și sisteme distribuite

Costul modulelor multiprocesor a scăzut recent semnificativ și, prin urmare, acestea au devenit din ce în ce mai utilizate în sistemele încorporate. Desigur, sistemul de operare RT trebuie să ofere suport pentru astfel de plăci.

Alte direcție promițătoareîn construcția sistemelor de control autopropulsate, acestea sunt sisteme distribuite în care modulele sunt separate în spațiu, iar comunicarea între ele are loc printr-un mediu de rețea. Din nou, RT OS utilizat trebuie să aibă mijloace convenabile și fiabile pentru organizarea interacțiunii modulelor: suport pentru diverse protocoale de rețea, mijloace pentru asigurarea transparenței rețelei.

QNX RT OS oferă suport pentru plăci multiprocesor. Pentru VxWorks, un astfel de suport tocmai a fost anunțat. Nu există încă o versiune de aviație a LynxOS cu suport pentru plăci multiprocesor.

În ceea ce privește suportul pentru protocoalele de rețea, trebuie remarcat faptul că RT OS LynxOS, VxWorks și QNX au capacități aproximativ egale (și largi). Un avantaj suplimentar al sistemului de operare QNX RT este arhitectura specială a subsistemului de rețea, care asigură „transparența” rețelei a programelor de aplicație: orice proces poate apela un alt proces pe un modul la distanță în același mod ca un proces pe un modul local.

Suport pentru sistemul de fișiere

Capacitatea de a stoca informații sub formă de fișiere este convenabilă și tradițională. În schimb, lipsa unei astfel de posibilități creează dificultăți la stocarea datelor rar modificate și la crearea sistemelor distribuite.

În tabel Figura 4 prezintă suportul sistemului de fișiere pentru fiecare dintre sistemele de operare luate în considerare.

QNX are cel mai extins suport pentru sistemele de fișiere. În plus, sistemul său de fișiere flash este tolerant la erori.

Calitatea documentatiei

Calitatea documentației pentru RT OS LynxOS, VxWorks, QNX este destul de ridicată. Cu toate acestea, există și plângeri cu privire la documentație:

QNX este o descriere excelentă a arhitecturii și principiilor de proiectare, dar o descriere insuficientă a interfeței de programare a aplicației (nu sunt descriși toți parametrii, există inconsecvențe);
VxWorks - nicio explicație a principiilor de funcționare și descriere insuficientă proces complex Configurarea sistemului de operare.

Cu toate acestea, companiile lucrează la calitatea materialului. Documentația pentru versiunea curentă a QNX (6.3.2) a fost extinsă semnificativ, iar unele părți au fost reproiectate.

Calitatea suportului tehnic

În ceea ce privește calitatea suportului tehnic oficial, liderul neîndoielnic este LynxOS. LynuxWorks promite să răspundă la orice întrebare tehnică în termen de 4 ore de la postarea cererii. LynxOS este distribuit în Rusia de către RTSoft, care are un personal mare de angajați capabili să ofere asistență calificată. Dezavantajul LynxOS este că sistemul de operare nu este încă foarte răspândit în Rusia, în consecință, nu există o comunitate de utilizatori stabilită și nici măcar nu există un forum în limba rusă.

QSS (producătorul QNX) oferă, de asemenea, suport tehnic bun, dar timpii de răspuns rapid nu sunt garantați. Spre deosebire de LynxOS, sistemul de operare QNX RT are o comunitate de utilizatori bine organizată atât în străinătate, cât și în Rusia. Răspunsurile la majoritatea întrebărilor pot fi găsite pe aceste forumuri. QNX în țara noastră este distribuit de SVD Embedded Systems, ai cărui angajați sunt capabili să ofere suport tehnic competent și să desfășoare lucrări de adaptare a sistemului de operare la anumite plăci de procesor. În plus, compania are contacte directe cu QSS și poate obține sfaturi cu privire la probleme complexe de la dezvoltatorul sistemului de operare QNX RT.

WindRiver, dezvoltatorul VxWorks, aderă în mod tradițional la o politică tehnică închisă, adică informațiile despre principiile de funcționare ale sistemului de operare sunt destul de dificil de obținut. De asemenea, acest sistem de operare nu are un forum în limba rusă. Sistemul de operare VxWorks RT este distribuit în țara noastră de către compania AVD Systems, care se ocupă în principal de vânzarea de soluții software și hardware gata făcute de origine străină.

Sursa deschisa

Un sistem de operare RT deschis are cel puțin trei avantaje:

Dezvoltatorii de aplicații software pot înțelege probleme complexe fără a implica suport tehnic;
mai ușor de certificat (fără marcaje etc.);
dezvoltare mai dinamică, deoarece compania dezvoltatoare RT OS primește adesea nu numai solicitări de corectare a erorilor, ci și propuneri pentru eliminarea erorilor și îmbunătățirea sistemului. Comunitățile de dezvoltatori RTOS open source, de regulă, cresc mult mai repede și sunt mai bine organizate. Experții independenți par să ajute la rezolvarea problemelor serviciului de asistență tehnică și să participe la dezvoltarea, depanarea și testarea sistemului.

Din septembrie 2007, QSS a deschis nucleul QNX (inclusiv pachetul Adaptive Partitioning, pachetul High Availability). Puțin mai târziu, codurile sursă ale subsistemului de rețea au fost deschise. În prezent, versiunea beta 6.4.0 este disponibilă pentru descărcare de pe site-ul oficial.

Trebuie remarcat faptul că astăzi nu toate modulele QNX sunt deschise (de exemplu, nu există coduri pentru grafică și sisteme de fișiere), iar licența impune o restricție privind utilizarea „codului sursă”: numai pentru uz necomercial. Cu toate acestea, utilizatorul QNX primește gratuit beneficiile de mai sus.

Codurile sursă LynxOS și VxWorks sunt disponibile comercial. Pretul unui astfel de produs este negociabil.

Instrumente

Disponibilitatea bunului unelte determină în mare măsură calitatea și viteza de dezvoltare a programelor de aplicație pentru un anumit sistem de operare. Trebuie remarcat faptul că LynxOS, VxWorks și QNX oferă în prezent calitate bună instrumente care includ un mediu de dezvoltare integrat (IDE) și depanare a aplicațiilor software, instrumente de profilare a programelor (pentru a detecta blocajele de performanță, memorie etc.). Ergonomia ISD-ului pentru aceste sisteme de operare RT nu este în general inferioară instrumentelor de dezvoltare dezvoltate pentru sistemele de operare convenționale (de exemplu, MS Windows).

Portabilitatea software-ului de aplicație

Portabilitatea software-ului aplicației face posibilă utilizarea acestuia sub alte sisteme de operare (inclusiv SO non-RT). Portabilitatea oferă dezvoltatorului de aplicații software o anumită independență față de sistemul de operare RT: dacă este necesar, puteți trece la un alt sistem de operare la un cost redus.

Capacitatea de a scrie software portabil este în prezent determinată de conformitate Standardul POSIX. Toate sistemele de operare RT considerate acceptă standardul POSIX 1003.1. LynxOS are un avantaj - acest sistem de operare este compatibil binar cu Linux. Acesta este aplicații Linux poate fi rulat sub LynxOS fără recompilare. În schimb, aplicațiile LynxOS pot fi rulate pe Linux (versiunea 2.4.x cu biblioteca de limbaj C glibs versiunea 2.2.2).

Restul sistemului de operare RT necesită recompilare pentru a rula aplicații Linux. În acest caz, procesul de portare chiar și a aplicațiilor compatibile cu POSIX poate deveni adesea destul de laborios din cauza diferențelor de implementare a bibliotecilor și compilatoarelor.

Suport pentru arhitecturi de procesoare

Dezvoltatorii autohtoni de sisteme de control pentru aviație în perioada actuală de tranziție de la sistemele de operare interne la cele comerciale se găsesc adesea într-o situație în care trebuie să selecteze și să adapteze un RTOS la o placă de procesor existentă. În acest caz, unul dintre argumentele cheie atunci când alegeți un sistem de operare este suportul pentru arhitectura procesorului utilizat pe placă.

Respectarea standardelor aviatice

În practica străină, software-ul pentru sistemele avionice trebuie să aibă un certificat de conformitate cu standardul DO-178B. Dacă software-ul cu diferite niveluri de criticitate este executat pe același modul de procesor, atunci RTOS utilizat trebuie să susțină conceptul de partiții. (În caz contrar, este aproape imposibil să se dovedească nepropagarea erorii). După cum sa menționat deja, este mai bine dacă interfața de programare RTOS respectă standardul ARINC-653, deoarece standardul este bine cunoscut organismelor de certificare străine.

LynxOS este lider în ceea ce privește conformitatea cu standardele. Acceptă ARINC-653 și există o mulțime de exemple de sisteme certificate DO-178B construite pe el. Punctul cheie este că LynuxWorks oferă un set de RSC (deși autorii articolului nu știu nimic despre preț).

VxWorks respectă standardul ARINC-653, iar sistemele construite pe baza acestuia pot fi certificate la DO-178B (există număr mare exemple).

QNX nu respectă ARINC-653 și nu există încă sisteme certificate DO-178B bazate pe acesta.

Trebuie remarcat faptul că sistemele QNX pot fi folosite în principiu pentru a construi un IMA, deoarece QNX acceptă propria metodă de furnizare a conceptului de partiție, care este o alternativă foarte bună la ARINC-653 și, în plus, vă permite să economisiți timp procesorului. .

În ceea ce privește standardele rusești similare pentru aviația militară (GOST R ISO/IEC 51904-2002), nu există încă un singur exemplu de sistem certificat, deși, în principiu, un astfel de sistem poate fi dezvoltat pe baza oricărui sistem de operare luat în considerare. Pentru sistemul de operare QNX RT, se lucrează în prezent pentru pregătirea principalelor module OS pentru certificare.

Dezvoltarea sistemului de formare specializată

Viteza și calitatea instruirii pentru personalul care lucrează cu sistemul de operare RT și diverse instrumente de dezvoltare software și depanare este direct legată de viteza dezvoltării software și de calitatea acestuia. Companiile de vârf în domeniul software-ului încorporat și de sistem, cum ar fi WindRiver, LynuxWorks, QSS, desfășoară un program la scară largă de cursuri și training-uri pentru a studia utilizarea produselor companiei, inclusiv a sistemului de operare RT.

Rezultatele comparației

QNX Neutrino RTOS este cel mai avansat sistem de operare din punct de vedere tehnic set bun unelte, are un preț relativ mic. Arhitectura Microkernel asigură fiabilitate ridicată și modularitate sistemelor dezvoltate. Un avantaj suplimentar este codul open source. Dar există și o „zbură în unguent”: în prezent, QNX nu este practic folosit nicăieri în aviație și, în acest sens, acest sistem de operare pierde în fața concurenților săi (LynxOS și VxWorks). Un dezavantaj suplimentar al QNX: nerespectarea standardului ARINC-653.

Trebuie remarcat faptul că, în principiu, QNX Neutrino dispune de toate mecanismele necesare pentru a lucra în sistemele avionice. În plus, fiabilitatea și disponibilitatea ridicată a sistemelor bazate pe QNX au fost dovedite în alte industrii în care costul erorii este chiar mai mare decât în aviație (controlul reactorului nuclear).

Lucrările de pregătire pentru certificarea QNX Neutrino în conformitate cu cerințele standardelor naționale de aviație sunt în prezent efectuate de SWD Software.

RTOS LynxOS-178, dimpotrivă, are toate certificatele necesare în străinătate, deși după multe alte criterii pare mai puțin preferabil decât QNX Neutrino. Rețineți că pentru utilizare în industria aviației ruse, LynxOS-178 RTOS trebuie, de asemenea, să fie certificat în conformitate cu GOST-urile interne.

VxWorks OS are o istorie lungă de utilizare în aplicații critice din străinătate. Cu toate acestea, analiza noastră arată că pare mai puțin preferabil primelor două sisteme de operare după multe criterii. În plus, credibilitatea VxWorks este subminată de strategia sa de dezvoltare închisă.

Grup de experți / R&D.CNews

Imprimare

O prezentare generală a caracteristicilor comparative ale RT OS prezent pe piața rusă este prezentată în legătură cu utilizarea în sistemele de control al aviației.

Datorită dezvoltării tehnologiei informatice, recent a devenit posibilă atribuirea unui modul de sarcini efectuate anterior de mai multe module de procesor, îmbunătățind în același timp caracteristicile de greutate și dimensiune ale sistemului de control și reducând costul acestuia. Această tendință în tehnologia aviației a dus la apariția conceptului de avionică modulară integrată - IMA (Integrated Modular Avionics, IMA).

Problema integrării funcțiilor de control într-un singur modul este că este necesară împărțirea resurselor acum comune (timp procesor, memorie, canale de comunicare) între diverse sarcini, asigurând în același timp același nivel de fiabilitate și independență a funcțiilor ca înainte. Sistemul de operare în timp real joacă un rol cheie în rezolvarea acestei probleme.

Documente care reglementează cerințele pentru RTOS

Standardul DO-178 (Software Consideration in Airborne Systems and Equipment Certification) definește cerințele pentru procesul de dezvoltare software și minuțiozitatea verificării acestuia în funcție de nivelul său de criticitate. Nivelul de criticitate software este determinat pe baza unei analize a severității consecințelor unei defecțiuni software. Există cinci niveluri de criticitate software în total (de la A la E).
MILS (Multiple Independent Levels of Security) este o abordare specială pentru proiectarea sistemului de operare, care previne propagarea erorilor aplicației software în timpul rulării și, de asemenea, simplifică verificarea programului datorită modularității software-ului. Toate aplicațiile sunt plasate în așa-numitele secțiuni (partiții). Partițiile au resurse alocate (zona de memorie, timpul procesorului în fiecare ciclu de sistem, acces la canalele de comunicație etc.). Accesul la resursele alocate este garantat de sistemul de operare care rulează în modul supervizor. Astfel, aplicațiile software cu diferite niveluri de criticitate pot rula pe un singur modul de procesor care rulează un sistem de operare - dacă apare o defecțiune în software-ul mai puțin critic (și, în consecință, mai puțin testat), acest lucru nu va afecta în niciun fel funcționarea altor secțiuni, deoarece încercările de a „uzurpa” resursele altor persoane vor fi blocate de sistemul de operare. Ideile MILS le fac ecou pe cele ale IMA și DO-178B.
Standardul ARINC-653 (Avionics Application Software Standard Interface) specifică o interfață software de aplicație APEX care acceptă un concept de partiție în stil MILS. Această interfață include funcții pentru gestionarea partițiilor, proceselor, partajarea timpului, comunicațiile între și în interiorul partițiilor și monitorizarea stării sistemului. Trebuie remarcat faptul că standardul ARINC-653 descrie o abordare general acceptată pentru implementarea ideilor MILS pentru IMA, deși pot exista și alte implementări. Un RTOS de aviație care respectă ARINC-653 are avantaje deoarece acest standard este bine cunoscut și înțeles de organismele internaționale de certificare, astfel încât este mai ușor să obțineți un certificat de conformitate DO-178B pentru un sistem construit conform acestui standard.
Standard pentru componente software reutilizabile. În conformitate cu DO-178B, software-ul unui anumit sistem de aplicație de aviație este supus întregii proceduri de certificare, chiar dacă utilizează module (componente) care au fost deja certificate anterior ca parte a unui alt sistem. Una dintre cele mai recente inițiative ale FAA (Agenția Federală de Certificare a Aviației, SUA) este definirea criteriilor pentru reutilizarea software-ului fără recertificare. Componentele care nu pot fi recertificate se numesc RSC (Componente software reutilizabile). Este nevoie de mai mult efort pentru a obține certificarea RSC, dar apoi RSC oferă economii semnificative.

Documente rusești care definesc cerințele software (inclusiv RTOS):

GOST R ISO/IEC 51904-2002 („Software pentru sisteme încorporate. Cerințe generale pentru dezvoltare și documentare”) - un analog al DO-178B pentru aviația militară;
KT-178A („Cerințe de calificare partea 178A”) - un analog al DO-178B pentru aviația civilă;
GOST R ISO/IEC 12207-99 („Tehnologia informației. Procesele ciclului de viață al software-ului”).

Comparația RT OS a fost efectuată în funcție de 13 parametri, care țin cont de criterii tehnice, ușurință de dezvoltare și parametri economici.

Parametrii de sincronizare a sistemului de operare

Una dintre principalele cerințe pentru RT OS este timpul minim de întârziere pentru procesarea unui eveniment. În practică, aceasta înseamnă că următorii parametri trebuie să fie mici:

timp de răspuns la întrerupere - timpul dintre apariția efectivă a întreruperii și începerea procesării primei instrucțiuni a operatorului de întrerupere;
control thread switching time - timpul de comutare între două fire într-un singur proces;
timpul de comutare a contextului procesului (numai pentru sistemele de operare care acceptă modelul de proces) - timp de comutare între două fire de control aparținând două procese diferite.

Date destul de obiective pot fi considerate rezultatele obținute de experții din revista Dedicated System, care au efectuat teste și comparații practice ale QNX RTOS 6.1, VxWorks AE 1.1 și Windows CE.NET pe platforma x86. Deși aceste date sunt în prezent depășite, autorii acestui articol nu au putut găsi materiale mai recente. În tabel Figura 2 prezintă datele de comparație ale performanței selectate între QNX Neutrino 6.1 și VxWorks AE 1.1. Raportul Dedicated Systems a dat preferință QNX în ceea ce privește performanța, cu raportul de scor setat la 9:5 (QNX:VxWorks), deoarece în timpul testării au fost descoperite două erori în VxWorks, pentru care a fost necesar să contactați suportul pentru a le corecta.

În tabel 3 prezintă date despre caracteristicile LynxOS. Compoziția testelor utilizate nu este specificată. În ceea ce privește datele despre caracteristicile LynxOS, a patra coloană (testare pe platforma x86) este interesantă. În comparație cu VxWorks și QNX, sistemul de operare LynxOS RT prezintă o întârziere uriașă în răspunsul la întreruperi (de peste 5 ori). Timpul de schimbare a contextului (adică timpul de comutare între două fire în același proces) este același cu QNX și de aproximativ 1,5 ori mai mic decât VxWorks.

Stabilitatea parametrilor de sincronizare

Pe baza datelor din jurnalul Dedicated System, QNX este înaintea VxWorks la acest criteriu atât în ceea ce privește răspândirea caracteristicilor într-o serie de teste similare (raportul dintre timpul maxim și valoarea medie este semnificativ mai mic), cât și cu sarcina în creștere. (timp de comutare a firelor când numărul de fire crește de la 2 la 128 de unități. QNX a crescut de numai 1,65 ori, în timp ce VxWorks a crescut de 2,24 ori).

Conform datelor obținute de la RTSoft, se știe că LynxOS are aproximativ aceleași caracteristici ca și VxWorks.

Gestionarea accesului la resurse

Să evaluăm calitatea controlului accesului oferit de unul sau altul RT OS resurselor critice ale sistemului de calcul, cum ar fi memoria și timpul procesorului.

Sarcina proceselor este:

în delimitarea accesului la RAM între diferite programe în timpul execuției;
în delimitarea domeniului de aplicare a variabilelor globale în momentul compilării (critic dacă aplicația software este scrisă în limbajul C, care nu suportă o astfel de delimitare).

Suport pentru multiprocesor și sisteme distribuite

O altă direcție promițătoare în construcția sistemelor automate de control este sistemele distribuite, în care modulele sunt separate în spațiu, iar comunicarea între ele are loc printr-un mediu de rețea. Din nou, RT OS utilizat trebuie să aibă mijloace convenabile și fiabile pentru organizarea interacțiunii modulelor: suport pentru diverse protocoale de rețea, mijloace pentru asigurarea transparenței rețelei.

Suport pentru sistemul de fișiere

În tabel Figura 4 prezintă suportul sistemului de fișiere pentru fiecare dintre sistemele de operare luate în considerare.

QNX are cel mai extins suport pentru sistemele de fișiere. În plus, sistemul său de fișiere flash este tolerant la erori.

Calitatea documentatiei

Calitatea documentației pentru RT OS LynxOS, VxWorks, QNX este destul de ridicată. Cu toate acestea, există și plângeri cu privire la documentație:

QNX este o descriere excelentă a arhitecturii și principiilor de proiectare, dar o descriere insuficientă a interfeței de programare a aplicației (nu sunt descriși toți parametrii, există inconsecvențe);
VxWorks - nicio explicație a modului în care funcționează și o descriere insuficientă a procesului complex de configurare a sistemului de operare.

Cu toate acestea, companiile lucrează la calitatea materialului. Documentația pentru versiunea curentă a QNX (6.3.2) a fost extinsă semnificativ, iar unele părți au fost reproiectate.

Calitatea suportului tehnic

Sursa deschisa

Un sistem de operare RT deschis are cel puțin trei avantaje:

dezvoltatorii de aplicații software pot înțelege probleme complexe fără a implica suport tehnic;
mai ușor de certificat (fără marcaje etc.);
dezvoltare mai dinamică, deoarece compania dezvoltatoare RT OS primește adesea nu numai solicitări de corectare a erorilor, ci și propuneri pentru eliminarea erorilor și îmbunătățirea sistemului. Comunitățile de dezvoltatori RTOS open source, de regulă, cresc mult mai repede și sunt mai bine organizate. Experții independenți par să ajute la rezolvarea problemelor serviciului de asistență tehnică și să participe la dezvoltarea, depanarea și testarea sistemului.

Codurile sursă LynxOS și VxWorks sunt disponibile comercial. Pretul unui astfel de produs este negociabil.

Instrumente

Disponibilitatea unor instrumente bune determină în mare măsură calitatea și viteza de dezvoltare a programelor de aplicație pentru un anumit sistem de operare. Trebuie remarcat faptul că LynxOS, VxWorks și QNX oferă în prezent instrumente de bună calitate, care includ un mediu de dezvoltare integrat (IDE) și depanare a aplicațiilor software, instrumente de profilare a programelor (pentru a detecta blocajele de performanță, memorie etc.). Ergonomia ISD-ului pentru aceste sisteme de operare RT nu este în general inferioară instrumentelor de dezvoltare dezvoltate pentru sistemele de operare convenționale (de exemplu, MS Windows).

Portabilitatea software-ului de aplicație

Capacitatea de a scrie software portabil este determinată în prezent de conformitatea cu standardul POSIX. Toate sistemele de operare RT considerate acceptă standardul POSIX 1003.1. LynxOS are un avantaj - acest sistem de operare este compatibil binar cu Linux. Adică, aplicațiile Linux pot fi rulate sub LynxOS fără recompilare. În schimb, aplicațiile LynxOS pot fi rulate pe Linux (versiunea 2.4.x cu biblioteca de limbaj C glibs versiunea 2.2.2).

Suport pentru arhitecturi de procesoare

Respectarea standardelor aviatice

LynxOS este lider în ceea ce privește conformitatea cu standardele. Acceptă ARINC-653 și există multe exemple de sisteme certificate DO-178B construite pe acesta. Punctul cheie este că LynuxWorks oferă un set de RSC (deși autorii articolului nu știu nimic despre preț).

VxWorks respectă standardul ARINC-653, iar sistemele construite pe deasupra pot fi certificate DO-178B (există multe exemple).

QNX nu respectă ARINC-653 și nu există încă sisteme certificate DO-178B bazate pe acestea.

În ceea ce privește standardele rusești similare pentru aviația militară (GOST R ISO/IEC 51904-2002), nu există încă un singur exemplu de sistem certificat, deși, în principiu, un astfel de sistem poate fi dezvoltat pe baza oricăruia dintre sistemele de operare luate în considerare. Pentru sistemul de operare QNX RT, se lucrează în prezent pentru pregătirea principalelor module OS pentru certificare.

Dezvoltarea sistemului de formare specializată

Rezultatele comparației

QNX Neutrino RTOS este cel mai avansat sistem de operare din punct de vedere tehnic, are un set bun de instrumente și are un preț relativ mic. Arhitectura Microkernel asigură fiabilitate ridicată și modularitate sistemelor dezvoltate. Un avantaj suplimentar este codul open source. Dar există și o „zbură în unguent”: în prezent, QNX nu este practic folosit nicăieri în aviație și, în acest sens, acest sistem de operare pierde în fața concurenților săi (LynxOS și VxWorks). Dezavantaj suplimentar al QNX: nerespectarea standardului ARINC-653.

Lucrările de pregătire pentru certificarea QNX Neutrino în conformitate cu cerințele standardelor naționale de aviație sunt în prezent efectuate de SWD Software.

Sisteme de operare în timp real

1. Introducere: Caracteristici ale sistemelor de operare în timp real

1.1. Procese, fire, sarcini

1.2. Planificare, priorități

1.3. Memorie

1.4. întreruperi

1.5. Ceasuri și cronometre

1.6. Standardele RTOS

1.6.1. POSIX

1.6.2. DO-178B

1.6.3. ARINC-653

1.6.4. OSEK

1.6.5. Standarde de siguranță

1.7. Personalizarea sistemului de operare

2. Scurte caracteristici ale celor mai comune RTOS

2.1. VxWorks

2.2. QNX Neutrino RTOS

2.3. RTEMS

2.4. ChorusOS

2.5. Extensii în timp real pentru Windows NT

2.5.1. RTXPentruWindows NT

2.5.2. La timp

2.5.3. Microsoft Windows Embedded

2.6. TinyOS

2.7. OSEK/VDX

2.8. OSE RTOS

2.9. Contiki

2.10. pSOS

2.11. INTEGRITATE

2.12. LynxOS

2.13. Microware OS-9

2.14. GRACE-OS

2.15. C EXECUTIV

2.16. CMX-RTX

2.16.1. CMX-TINY+

2.17. Infern

3. OS conceput special pentru dispozitive portabile

3.1. ITRON

3.2. Windows CE

3.3. JavaOS

3.4. Jbed

3.5. Nucleul RTOS

3.6. SMERALDE

3.7. CORTEX

3.8. DeltaOS

3.9. Palm OS

3.10. Sistem de operare Symbian (EPOC)

4. Personalizarea sistemelor de operare

4.1. Adaptarea umană

4.1.1. Adaptare statică inițiată de proiectant

4.1.2. Adaptare dinamică inițiată de administrator

4.2. Aplicația a inițiat adaptarea

4.2.1. Adaptare de la nivelul aplicației

4.2.2. Adaptare la nivel de kernel

4.3. Adaptare automată

5. Tabele rezumative ale caracteristicilor proprietăților RTOS

Anexa A. Lista abrevierilor

Anexa B. Terminologie

Literatură

Lista RTOS menționate în acest text, în format tipărit și pe Internet

1. Introducere: Caracteristici ale sistemelor de operare în timp real

Sistemele de operare în timp real (RTOS) sunt concepute pentru a oferi o interfață cu resursele sistemelor în timp real critice. Sarcina principală în astfel de sisteme este oportunitatea prelucrării datelor.

Principala cerință pentru un RTOS este asigurarea predictibilitatea sau determinism comportamentul sistemului în cele mai proaste condiții externe, care diferă mult de cerințele de performanță și viteză ale sistemelor de operare universale. Un RTOS bun are un comportament previzibil în toate scenariile de încărcare a sistemului (întreruperi simultane și execuție a firelor).

Există o diferență între sistemele în timp real și sistemele încorporate. Un sistem încorporat nu este întotdeauna necesar să aibă un comportament previzibil, caz în care nu este un sistem în timp real. Cu toate acestea, chiar și o privire rapidă asupra posibilelor sisteme încorporate sugerează că majoritatea sistemelor încorporate necesită un comportament previzibil pentru cel puțin o anumită funcționalitate și astfel aceste sisteme pot fi clasificate ca sisteme în timp real.

Se obișnuiește să se facă distincția între sistemele în timp real soft și hard. În sistemele hard-time real, incapacitatea de a oferi un răspuns la orice eveniment la un moment dat duce la eșecuri și incapacitatea de a finaliza sarcina atribuită. În majoritatea literaturii de limbă rusă, astfel de sisteme sunt numite sisteme cu timp determinist. În aplicațiile practice, timpul de reacție ar trebui să fie minim. Sistemele soft în timp real sunt sisteme care nu se încadrează în definiția de „hard”, deoarece Nu există încă o definiție clară pentru ele în literatură. Este posibil ca sistemele soft în timp real să nu aibă timp să rezolve o problemă, dar acest lucru nu duce la defecțiunea sistemului în ansamblu. În sistemele de timp real, este necesar să se introducă un anumit termen (în literatura engleză - deadline), înainte de expirarea căruia sarcina trebuie neapărat finalizată (pentru sisteme soft în timp real - de preferință). Acest termen limită este folosit de planificatorul de sarcini atât pentru a atribui o prioritate unei sarcini atunci când este lansată, cât și atunci când selectează o sarcină pentru execuție.

Martin Timmerman a formulat următoarele cerințe necesare pentru un RTOS:

Sistemul de operare trebuie să fie multitasking și preempțiabil,

Sistemul de operare trebuie să aibă un concept de prioritate pentru fire,

Sistemul de operare trebuie să suporte mecanisme de sincronizare previzibile,

Sistemul de operare trebuie să ofere un mecanism pentru moștenirea priorităților,

Comportamentul sistemului de operare trebuie să fie cunoscut și previzibil (întârzieri în procesarea întreruperii, întârzieri la schimbarea sarcinilor, întârzieri ale șoferului etc.); aceasta înseamnă că, în toate scenariile de încărcare a sistemului, trebuie determinat timpul maxim de răspuns.

În ultimii 25-30 de ani, structura sistemelor de operare a evoluat de la o structură monolitică la o structură de sistem de operare multistrat și apoi la o arhitectură client-server. Într-o structură monolitică, sistemul de operare constă dintr-un set de module, iar modificările aduse unui modul afectează celelalte module. Cu cât sunt mai multe module, cu atât este mai mult haos când se operează un astfel de sistem. În plus, nu este posibilă distribuirea sistemului de operare pe un sistem multiprocesor. Într-o structură cu mai multe straturi, modificările dintr-un singur strat afectează straturile adiacente; în plus, inversarea prin strat nu este posibilă. Pentru sistemele în timp real, trebuie furnizat acces direct la fiecare strat al sistemului de operare și, uneori, direct la hardware.

Ideea principală a tehnologiei client-server într-un sistem de operare este de a reduce baza sistemului de operare la minim (primitive de planificare și sincronizare). Toate celelalte funcționalități sunt mutate la un alt nivel și implementate prin fire sau sarcini. Un set de astfel de sarcini de server este responsabil pentru apelurile de sistem. Aplicațiile sunt clienți care solicită servicii prin apeluri de sistem.

Tehnologia client-server permite crearea de sisteme de operare scalabile și simplifică distribuția într-un sistem multiprocesor. Când se operează sistemul, înlocuirea unui modul nu provoacă un efect de „bulgăre de zăpadă”; În plus, o defecțiune a unui modul nu implică întotdeauna o defecțiune a sistemului în ansamblu. Acum există posibilitatea de a încărca și descărca dinamic modulele. Principala problemă a acestui model este protecția memoriei, deoarece procesele serverului trebuie protejate. Cu fiecare cerere de serviciu, sistemul trebuie să treacă din contextul aplicației în contextul serverului. Cu suport pentru protecția memoriei, timpul de comutare de la un proces la altul crește.

De regulă, majoritatea RTOS moderne sunt construite pe baza unui microkernel (kernel sau nucleu), care asigură programarea și expedierea sarcinilor, precum și interacțiunea acestora. Chiar dacă nucleul minimizează abstracțiile sistemului de operare, microkernel-ul trebuie să înțeleagă abstracțiile proceselor. Toate celelalte abstractizări conceptuale ale sistemelor de operare sunt mutate în afara nucleului, apelate la cerere și executate ca aplicații.

Să ne uităm la abstracțiile conceptuale ale sistemului de operare prin prisma cerințelor pentru sistemele în timp real.

Caracteristici distinctive ale RTOS de la OS scop general

Sistemele de operare de uz general, în special cele multi-utilizator, cum ar fi UNIX, sunt vizate distributie optima resursele computerului între utilizatori și sarcini. În sistemele de operare în timp real, o astfel de sarcină trece în fundal - totul se retrage înainte sarcina principala- să aibă timp să reacționeze la evenimentele care au loc în instalație. O altă diferență este că utilizarea unui sistem de operare în timp real este întotdeauna asociată cu echipamentul, cu obiectul, cu evenimentele care au loc în instalație. Un sistem de operare în timp real este axat pe procesarea evenimentelor externe. Un sistem de operare în timp real poate fi similar în interfață cu un sistem de operare general, dar este proiectat complet diferit. În plus, aplicarea sistemelor de operare în timp real este întotdeauna specifică. Dacă un sistem de operare cu scop general este de obicei perceput de utilizatori (nu dezvoltatori) ca un set gata de aplicații, atunci un sistem de operare în timp real servește doar ca instrument pentru crearea unui anumit complex hardware și software în timp real. Și, prin urmare, cea mai largă clasă de utilizatori ai sistemelor de operare în timp real sunt dezvoltatorii de sisteme în timp real, oameni care proiectează sisteme de control și achiziție de date. Când proiectează și dezvoltă un sistem specific în timp real, programatorul știe întotdeauna exact ce evenimente pot avea loc la instalație și cunoaște intervalul de timp critic pentru deservirea fiecăruia dintre aceste evenimente. Sistemul RT trebuie să aibă timp să răspundă la un eveniment care a avut loc la instalație în timpul critic pentru acest eveniment. Valoarea timpului critic pentru fiecare eveniment este determinată de obiect și de evenimentul în sine și poate fi diferită, dar timpul de reacție al sistemului trebuie prezis (calculat) la crearea sistemului. Eșecul de a răspunde la ora prevăzută este considerată o eroare pentru sistemele în timp real. Sistemul trebuie să poată răspunde la evenimente care apar simultan. Chiar dacă două sau mai multe evenimente externe au loc simultan, sistemul trebuie să aibă timp să reacționeze la fiecare dintre ele în intervalele de timp critice pentru aceste evenimente.

	Sistem de operare în timp real	OS de uz general
Sarcina principală	Aveți timp să reacționați la evenimentele care au loc pe echipament	Distribuiți în mod optim resursele computerului între utilizatori și sarcini
Pe ce se concentrează?	Gestionarea evenimentelor externe	Procesarea acțiunilor utilizatorului
Cum este pozitionat	Un instrument pentru crearea unui complex hardware și software specific în timp real	Utilizatorul îl percepe ca pe un set de aplicații gata de utilizare
Cui este destinat?	Dezvoltator calificat	Utilizator intermediar

Sisteme hard și soft în timp real

Există două tipuri de sisteme în timp real - sisteme hard în timp real și sisteme soft în timp real.

Sistemele hard în timp real nu permit nicio întârziere în răspunsul sistemului în nicio circumstanță deoarece:

rezultatele pot fi inutile dacă întârzie
dezastrul poate apărea dacă reacția este întârziată

costul întârzierii poate fi infinit.

Exemple de sisteme hard în timp real - sisteme de bord sisteme de control, sisteme de protecție în caz de urgență, înregistratoare de evenimente de urgență.

Sistemele soft în timp real se caracterizează prin faptul că întârzierea răspunsului nu este critică, deși poate duce la o creștere a costului rezultatelor și la o scădere a performanței sistemului în ansamblu. Dacă sistemul nu are timp să proceseze următorul pachet primit, acest lucru va duce la un timeout din partea de trimitere și la retrimitere (în funcție de protocol, desigur). Datele nu se pierd, dar performanța rețelei este redusă Principala diferență dintre sistemele hard și soft în timp real poate fi exprimată după cum urmează: un sistem hard în timp real nu trebuie să întârzie niciodată să răspundă la un eveniment, un sistem soft în timp real. nu ar trebui să întârzie niciodată să răspundă la un eveniment

Nucleul sistemului de operare

Nucleul este partea centrală a sistemului de operare (OS), oferind aplicațiilor acces coordonat la resursele computerului, memorie, hardware extern, dispozitive externe de intrare și ieșire, traducând comenzile din limbajul aplicației în limbaj de cod binar pe care computerul îl înțelege ca element fundamental element al sistemului de operare, nucleul reprezintă cel mai scăzut nivel de abstractizare pentru ca aplicațiile să acceseze resursele de sistem necesare funcționării lor. În mod obișnuit, nucleul oferă un astfel de acces la procesele de execuție ale aplicațiilor corespunzătoare prin utilizarea mecanismelor de comunicare între procese și a apelurilor de aplicație către apelurile de sistem OS.

Miez monolitic

Nucleul monolitic oferă un set bogat de abstracții hardware. Toate părțile unui nucleu monolitic funcționează în același spațiu de adrese. Aceasta este o schemă a unui sistem de operare în care toate componentele nucleului său sunt componente ale unui program, utilizare structuri generale date și interacționează între ele apelând direct proceduri. Miez monolitic - cea mai veche cale organizarea sistemelor de operare. Un exemplu de sisteme cu un nucleu monolitic este majoritatea sistemelor UNIX.

Avantaje: Viteza de funcționare, dezvoltarea simplificată a modulelor.

Defecte: Deoarece întregul nucleu funcționează în același spațiu de adrese, o defecțiune a uneia dintre componente poate perturba întregul sistem.

Unele nuclee monolitice vechi, în special sisteme de clasă UNIX/Linux, au necesitat recompilare ori de câte ori compoziția hardware se schimba. Cele mai multe nuclee moderne vă permit să încărcați module în timpul funcționării care îndeplinesc o parte din funcțiile nucleului. În acest caz, componentele sistemului de operare nu sunt module independente, ci componente ale unuia program mare numit nucleu monolitic, care este un set de proceduri, fiecare dintre acestea putând apela fiecare. Toate procedurile rulează în modul privilegiat.

Microkernel

Microkernel-ul oferă doar funcții de bază de gestionare a proceselor și set minim abstracții pentru lucrul cu echipamente. Cea mai mare parte a muncii este realizată prin procese speciale de utilizator numite servicii. Criteriul decisiv pentru „microkernelism” este plasarea tuturor sau aproape tuturor driverelor și modulelor în procesele de service.

Avantaje: Rezistență la defecțiuni hardware și erori ale componentelor sistemului. Principalul avantaj al arhitecturii microkernel este gradul ridicat de modularitate al nucleului sistemului de operare. Acest lucru face mult mai ușor să adăugați componente noi la acesta. Într-un sistem de operare microkernel, puteți încărca și descărca drivere noi fără a întrerupe funcționarea acestuia, sisteme de fișiere etc. Procesul de depanare a componentelor nucleului este mult simplificat, deoarece o nouă versiune driverele pot fi încărcate fără a reporni întregul sistem de operare. Componentele nucleului sistemului de operare nu sunt fundamental diferite de programele utilizatorului, așa că puteți folosi instrumente obișnuite pentru a le depana. Arhitectura microkernel îmbunătățește fiabilitatea sistemului, deoarece o defecțiune la nivel de program neprivilegiat este mai puțin periculoasă decât o defecțiune la nivelul modului kernel.

Defecte: Transmiterea datelor între procese necesită o suprasarcină.

Mediu de rulare

Cerințele pentru mediul de execuție al sistemelor în timp real sunt următoarele:

memorie de sistem mică - pentru posibilitatea de încorporare a acesteia;
sistemul trebuie să fie complet rezident în memorie pentru a evita schimbarea sau schimbarea paginilor de memorie;
sistemul trebuie să fie multitasking – pentru a asigura utilizarea cât mai eficientă a tuturor resurselor sistemului;
nucleu cu prioritate pentru întreruperile de service. Prioritatea întreruperii înseamnă că un proces care este gata de rulare și are o anumită prioritate are în mod necesar prioritate în coadă față de un proces cu o prioritate mai mică, îl înlocuiește rapid pe acesta din urmă și trece la execuție. Nucleul termină orice lucrare de serviciu imediat ce sosește o sarcină cu cea mai mare prioritate. Acest lucru asigură predictibilitatea sistemului;
manager de priorități - permite dezvoltatorului aplicației să atribuie fiecărui modul de pornire o prioritate care nu este supusă sistemului. Atribuirea priorităților este utilizată pentru a determina ordinea în care sunt executate programele care sunt gata de a fi executate. O alternativă la acest tip de programare este programarea carusel, în care fiecărui program care este gata să continue i se oferă șanse egale de rulare. Cu această metodă, nu există niciun control asupra programului care va fi executat și când. Acest lucru este inacceptabil într-un mediu în timp real. Expedierea bazată pe prioritate și un nucleu cu prioritate de întrerupere oferă dezvoltatorului aplicației control complet asupra sistemului. Dacă are loc un eveniment cu prioritate mai mare, sistemul oprește procesarea sarcinii cu prioritate mai mică și răspunde la cererea recent primită.

Combinația proprietăților descrise mai sus creează un mediu de execuție puternic și eficient în timp real.

Pe lângă proprietățile mediului de rulare, este necesar să se ia în considerare și serviciul oferit de kernel-ul OS în timp real. Miezul oricărui mediu de rulare în timp real este kernel-ul sau dispecerul. Nucleul controlează hardware-ul computerului țintă: procesor central, dispozitive de memorie și de intrare/ieșire; controlează funcționarea tuturor celorlalte sisteme și aplicații software. Într-un sistem în timp real, dispecerul se află între hardware-ul computerului țintă și software-ul aplicației. Oferă serviciu special, necesar pentru rularea aplicațiilor în timp real. Serviciul oferit de kernel oferă programelor de aplicație acces la resursele sistemului, cum ar fi memoria sau dispozitivele de intrare/ieșire.

Nucleul poate oferi diferite tipuri de servicii:

Schimb între sarcini. Este adesea necesar să transferați date între programe în cadrul aceluiași sistem. În plus, multe aplicații trebuie să comunice cu alte sisteme printr-o rețea. Comunicarea internă poate fi efectuată printr-un sistem de mesagerie. Comunicații externe poate fi organizat fie printr-o datagramă (cel mai bun mod de livrare), fie prin linii de comunicare (livrare garantată). Alegerea unei metode sau alteia depinde de protocolul de comunicare.
Separarea datelor. În aplicațiile în timp real, colectarea datelor durează cel mai mult timp. Datele sunt adesea necesare pentru funcționarea altor programe sau sunt necesare sistemului pentru a îndeplini unele dintre funcțiile sale. Multe sisteme oferă acces la secțiunile de memorie partajată. Coada de date este larg răspândită. Există multe tipuri de cozi în uz, fiecare dintre ele având propriile sale avantaje.
Procesarea cererilor de la dispozitive externe. Fiecare program de aplicație este conectat în timp real la un dispozitiv extern de un anumit tip. Nucleul trebuie să ofere servicii I/O care să permită programelor de aplicație să citească și să scrie pe aceste dispozitive. Pentru aplicațiile în timp real, este obișnuit să existe un dispozitiv extern specific aplicației. Nucleul trebuie să ofere un serviciu care facilitează lucrul cu driverele de dispozitiv. De exemplu, oferiți capacitatea de a scrie în limbi de nivel înalt - cum ar fi C sau Pascal.
Gestionarea situațiilor speciale. O excepție este un eveniment care are loc în timpul execuției programului. Poate fi sincron dacă apariția sa este previzibilă, cum ar fi împărțirea la zero. Și poate fi, de asemenea, asincron dacă are loc în mod imprevizibil, cum ar fi o cădere de tensiune. Oferirea capacității de a gestiona aceste tipuri de evenimente permite aplicațiilor în timp real să răspundă rapid și previzibil la evenimentele interne și externe. Există două metode pentru gestionarea excepțiilor - utilizarea valorilor de stare pentru a detecta condițiile de eroare și utilizarea unui handler de excepții pentru a capta condițiile de eroare și a le corecta.

Prezentare generală a arhitecturilor RTOS

De-a lungul istoriei sale, arhitectura sistemului de operare a suferit o dezvoltare semnificativă. Unul dintre primele principii de construcție, monolitic Sistemul de operare (Figura 1) a constat în prezentarea sistemului de operare ca un set de module care interacționează între ele în diferite moduri în cadrul sistemului de bază și oferă programelor de aplicație interfețe de intrare pentru accesarea hardware-ului.

nivel de sistem de operare (Figura 2) Un exemplu de astfel de sistem de operare este bun sistem cunoscut MS-DOS. În sistemele din această clasă, aplicațiile de aplicație ar putea accesa hardware-ul nu numai prin nucleul sistemului sau prin serviciile sale rezidente, ci și direct. RTOS-urile au fost construite pe acest principiu de mulți ani. În comparație cu sistemele de operare monolitice, această arhitectură oferă un grad semnificativ mai mare de predictibilitate a reacțiilor sistemului și, de asemenea, permite aplicațiilor aplicațiilor să acceseze rapid hardware-ul. Dezavantaj

Ceea ce face ca astfel de sisteme să fie atât de proaste este lipsa lor de multitasking. În cadrul acestei arhitecturi, problema procesării evenimentelor asincrone a fost redusă la buffering-ul mesajelor, apoi interogarea secvenţială a bufferelor şi procesarea acestora. În același timp, respectarea termenelor critice de service a fost asigurată de performanța ridicată a complexului de calcul în comparație cu viteza proceselor externe.

Figura 2. Arhitectura sistemului de operare stratificat

Una dintre cele mai eficiente arhitecturi pentru construirea de sisteme de operare în timp real este arhitectura client-server. Schema generala Un sistem de operare care funcționează folosind această tehnologie este prezentat în Figura 3. Principiul principal al acestei arhitecturi este transferul serviciilor de sistem de operare sub formă de servere la nivelul utilizatorului, iar microkernel-ul acționează ca un manager de mesaje între programele client și servere - sistem. Servicii. Această arhitectură oferă o mulțime de avantaje în ceea ce privește cerințele pentru RTOS și sistemele încorporate. Printre aceste avantaje se numără:

1. Fiabilitatea sistemului de operare crește, deoarece Fiecare serviciu este, de fapt, o aplicație independentă și este mai ușor de depanat și de urmărit erorile.

2. Un astfel de sistem se scalează mai bine pentru că servicii inutile poate fi exclus din sistem fără a-i afecta performanța.

3. Toleranța la erori a sistemului crește, deoarece Un serviciu înghețat poate fi repornit fără

reporniți sistemul.

Figura 3. Construirea unui sistem de operare folosind arhitectura client-server

Din păcate, astăzi nu există multe sisteme de operare implementate pe principiul client-server. Printre RTOS-urile bine-cunoscute care implementează arhitectura microkernel sunt OS9 și QNX.

Lista literaturii folosite:

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/

Selecția pentru serviciul de aviație este extrem de strictă și privește nu numai personalul de zbor, ci și sistemele de operare în timp real (RT OS). Să luăm în considerare ce cerințe sunt impuse sistemelor de aviație comercială de către organizațiile responsabile cu siguranța zborului. Fără îndoială, acest lucru va ajuta la înțelegerea cerințelor care sunt esențiale pentru multe alte industrii - oriunde este nevoie de un răspuns rapid la evenimente, fiabilitate ridicată, supraviețuire și siguranță a instrumentelor utilizate, inclusiv software-ul.

Administrația Federală a Aviației din SUA, una dintre organizațiile autorizate responsabile cu siguranța zborului, are cerințe stricte pentru sistemele comerciale de operare în timp real adoptate pentru operare (în special pentru aviația civilă, unde viața a sute de pasageri depinde de funcționarea acestora). Printre ei:

cerințe „grele” în timp real; comportament determinist sub diferite încărcări ale sistemului, necesar în aplicațiile critice și sistemele de înaltă disponibilitate;
„supraviețuire” ridicată, astfel încât, dacă orice parte a software-ului eșuează, cealaltă parte continuă să funcționeze normal;
cerințe stricte de calitate, ceea ce înseamnă respectarea diverselor standarde industriale, naționale și internaționale;
cerințe de fiabilitate; probabilitatea eșecului unui program ar trebui să fie foarte mică;
cerințe pentru securitatea și secretul datelor; Sistemul trebuie să ofere mijloace pentru a proteja cele mai importante informații.

Sistemul de reglementare a cerințelor

Să enumeram principalele documente care reglementează cerințele pentru sistemele de operare în timp real în domeniul aviației.

Standard DO-178 - Considerare software în certificarea sistemelor și echipamentelor aeropurtate. Dezvoltat și întreținut de Comisia Tehnică Radio pentru Aeronautică (RTCA, www.rtca.org). Standardul definește cinci niveluri de severitate a defecțiunilor, pentru fiecare dintre acestea fiind specificat un set de cerințe software, concepute pentru a garanta operabilitatea întregului sistem în ansamblu atunci când apar defecțiuni de acest nivel:

nivelul A- protectie impotriva defectiunilor care conduc la consecinte catastrofale;

nivelul B- protectie impotriva defectiunilor care conduc la consecinte periculoase;

nivelul C- protectie impotriva defectiunilor care conduc la consecinte mari;

nivelul D- protectie impotriva defectiunilor care conduc la consecinte minime;

nivelul E- protectie impotriva defectiunilor care nu conduc la nici o consecinta.

Standard ED-12B. Analog european al DO-178B. Determinat de asociația Organizația Europeană pentru Echipamente de Aviație Civilă (EUROCAE, www.eurocae.org).

RTCA DO-248B - Raport anual final pentru clarificarea DO-178B. Document explicativ pentru DO-178B. Subiectele sale principale includ domenii precum software dezvoltat anterior, produse software comerciale, procese de verificare, informatii istorice, instrumente automate etc.

Standard DO-254 - Ghid de asigurare a designului pentru hardware-ul electronic aeropurtat. Dezvoltat și întreținut de RTCA. Documentul este conceput pentru a ajuta producătorii de avioane și furnizorii de avionică să se asigure că echipamentul lor electronic își îndeplinește în siguranță funcțiile necesare. Documentul reglementează procesele ciclului de viață hardware și descrie modalități de a asigura proprietățile cerute ale produselor pentru a le certifica în conformitate cu cerințele.

ARINC 653 - Interfață standard a software-ului de aplicație pentru aviație. Dezvoltat de ARINC în 1997, definește o interfață software universală APEX (APPLICATION/EXecutive) între sistemul de operare al computerului de bord și aplicația software. Cerințele de interfață sunt definite pentru a permite programelor de aplicație să controleze expedierea, comunicarea și starea elementelor de procesare internă. Ca una dintre cerințele de bază pentru sistemele de operare în timp real din aviație, ARINC 653 introduce o arhitectură de mașină virtuală de partiționare.

Criterii comune de evaluare a secretului tehnologiilor informaționale (Common Criteria pentru informații Evaluarea securității tehnologiei). Un set de cerințe și condiții de secret ( www.commoncriteria.org), aprobat de Agenția de Securitate Națională a SUA și de Institutul Național de Standarde și Tehnologie din SUA, precum și de autoritățile relevante din alte țări (în prezent, alte 13 țări în afară de SUA). În 1999, „Criteriile generale” au primit statutul de standard internațional ISO 15408.

MILS - Mai multe niveluri independente de securitate/siguranță. Acesta este dezvoltat prin eforturile organizațiilor interesate, cum ar fi Laboratorul de Cercetare al Forțelor Aeriene din SUA, Lockheed Martin, Agenția de Securitate Națională a SUA etc. Proiectul MILS face posibilă verificarea matematică a nucleului software al unui sistem prin reducerea funcționalității prin reducerea funcționalității. impunerea a patru grupuri obligatorii de cerințe asupra sistemelor (Fluxul de informații, Izolarea datelor, Procesarea perioadei, Limitarea daunelor). Arhitectura MILS este un sistem cu partiții izolate, fiecare dintre ele include kernel-ul, middleware-ul și aplicația (Figura 1).

Orez. 1. Arhitectura MILS

POSIX - Interfață pentru sistemul de operare portabil pentru unIX. Definește o interfață de sistem de operare portabilă la nivel textele sursă. Specificația de bază este dezvoltată ca IEEE 1003.1 și este aprobată ca standard international ISO/IEC 9945-1:1990. Din punctul de vedere al sistemelor de operare în timp real, trei standarde prezintă cel mai mare interes: 1003.1a (OS Definition), 1003.1b (Realtime Extensions) și 1003.1c (Threads).

Concept de partiție izolată

În multe aspecte, documentele de reglementare se suprapun, completându-se reciproc. Ca urmare a numeroaselor studii, conceptul de partiții izolate a fost adoptat ca principal. Satisfacția cerințelor de izolare rigidă trebuie să fie „dovedită” de furnizorii de soluții software în conformitate cu metodologia de certificare prezentată în DO-178B. Există diverse abordări pentru implementarea partițiilor izolate, dar astăzi arhitectura adoptată este ARINC 653, care definește suportul de izolare pentru un sistem de operare în timp real și folosește C și Ada-95 ca limbaj de descriere.

Din perspectiva utilizatorului, ARINC 653 este o specificație de interfață APEX (Aplicație/EXecutivă) și nu definește implementarea acesteia. Astfel, unii furnizori de software implementează dispeceratul folosind un dispecer cu un singur nivel, alții folosind un dispecer pe două niveluri, când primul nivel gestionează partițiile și al doilea gestionează procesele din cadrul fiecărei partiții. Această situație cu suportul ARINC 653 implică dificultăți de certificare produse software compatibil doar cu ARINC 653 - aceeași API se poate mapa la abordări diferite de implementare. Ca rezultat, au apărut multe sisteme de operare în timp real foarte diferite, care totuși respectă specificația ARINC 653.

În fig. Figura 2 prezintă arhitectura unui sistem cu mai multe partiții izolate, fiecare dintre acestea reprezentând o aplicație independentă. Toate datele și codul din fiecare secțiune sunt colectate împreună și executate în modul utilizator. Componentele Module Operating System (MOS) și Board Support Package (BSP) rulează în modul supervizor. În plus, poate exista o secțiune specială cu unele caracteristici speciale, cum ar fi facilități de intrare/ieșire și comutare de mod.

ARINC 653 specifică interfața pentru schimbul de informații între partiții, fiecare dintre acestea reprezentând o aplicație plus Partition Operating System (POS). Această interfață trebuie să asigure izolarea următoarelor elemente.

RAM. Fiecărei partiții i se alocă un spațiu de adrese fizice liniar contiguu, ale cărui limite nu se pot schimba în timpul funcționării sistemului. Pentru fiecare partiție, alocarea și dealocarea memoriei sunt efectuate și controlate de MOS. Sistemul de operare în timp real trebuie să asigure izolarea informațiilor în spațiul de adresă într-o „bucătură” liniară alocată fiecărei secțiuni. Acest lucru se aplică codului programului, constantelor, datelor statice, stivei și heap-ului (zona din care este preluată memoria atunci când este solicitată).

Timp de utilizare procesor. Procesele dintr-o partiție pot fie să nu afecteze deloc comportamentul proceselor dintr-o altă partiție, fie să le influențeze într-un mod predeterminat și controlat (de exemplu, prin setarea unor steaguri sau condiții). ARINC 653 necesită ca timpul procesorului să fie alocat fiecărei partiții pe o bază strict ciclică, iar timpul de proprietate a procesorului pentru fiecare partiție trebuie specificat în prealabil în tabelul de configurare. În cadrul fiecărei partiții, procesele pot concura pentru timpul CPU pe baza priorităților („preempt”) folosind programarea priorității.

Cod program. Pentru unele zone de memorie, MOS setează atributul „execute-only” în modul supervizor. Aceasta înseamnă că aplicațiile în modul utilizator nu pot distruge regiunea codului.

întreruperi.Întreruperile sunt evenimente asincrone care necesită o atenție specială pentru a asigura izolarea secțiunii. Este important ca acestea să nu „încărceze” timpul și memoria în altă secțiune. Unul dintre surse posibileÎntreruperile sunt temporizatoare care controlează transmiterea evenimentelor atât în POS, cât și în MOS.

Au fost adoptate o serie de convenții pentru a asigura izolarea întreruperii. Întreruperile temporizatorului apar numai în modul supervizor; Accesul direct la ceas în modul utilizator nu este posibil. Dacă POS și MOS sunt la niveluri de securitate diferite, atunci trebuie furnizat un mecanism pentru a distribui informații despre evenimentele temporare către partițiile aplicației care rulează în modul utilizator. În acele momente în care secțiunea este activă (deține timpul procesorului), toate evenimentele de timp legate de aceasta ar trebui să îi fie transmise. Când o partiție este inactivă, toate evenimentele temporare legate de ea trebuie să fie stocate și apoi transferate la ea când este activată.

O altă sursă de întreruperi sunt dispozitivele I/O externe. În conformitate cu cerințele ARINC 653, se recomandă utilizarea unui algoritm de interogare a dispozitivelor pentru dispozitivele cu transfer de date sincron. Cu toate acestea, unele dispozitive necesită gestionarea întreruperilor. Aceste întreruperi trebuie să fie gestionate de MOS și apoi transmise la POS atunci când partiția este activată. Evident, pot apărea întârzieri de timp și chiar pierderi de informații și, prin urmare, proiectantul trebuie să țină cont de acest lucru.

ARINC 653 definește nu numai cerințele pentru izolarea partițiilor, ci și mecanismele de interacțiune dintre ele. Introdus următoarele funcții interacțiuni între secțiuni:

schimb de mesaje prin stabilirea unui canal de comunicare, care trebuie descris în prealabil în tabelul de configurare a sistemului;

schimb prin buffer, în care doar o partiție poate scrie într-un anumit buffer, iar toate celelalte pot doar citi; aceasta oferă posibilitatea de a difuza informații între partiții.

Standardul DO-178B

Standardul DO-178B descrie tehnici și metode pentru a asigura integritatea și fiabilitatea software-ului, acoperind toate etapele ciclului său de viață - planificare, dezvoltarea cerințelor, proiectare, codificare, integrare și testare.

Planificarea DO-178B trebuie să includă următoarele planuri: un plan pentru aspecte ale programului certificare; plan de proiect software; plan de verificare software; plan de management al configurației software; planul de asigurare a calității software. De-a lungul întregului ciclu de viață, trebuie să se asigure conformitatea cu standardul DO-178 în domeniile declarației cerințelor, proiectării, codificării, verificării și documentării. Trebuie dezvoltate cerințe software (cerințe de nivel înalt), design software (cerințe și arhitectură), codul programului în formă sursă și obiect. Fiecare dintre componentele dezvoltate trebuie verificată după diverse criterii. Verificarea cerințelor software de nivel înalt include verificarea următoarelor condiții: cerințele îndeplinesc cerințele de sistem și sunt disponibile pentru analiză împreună cu Cerințe de sistem; cerințele sunt precise și consecvente; cerințele sunt compatibile cu hardware-ul și, prin urmare, trebuie susținute de rezultate.

Verificarea proiectării software implică verificarea faptului că cerințele de proiectare îndeplinesc cerințele de nivel înalt și pot fi analizate, sunt precise și consecvente și, prin urmare, pot fi susținute de rezultate. De asemenea, arhitectura software și codul trebuie verificate și trebuie, de asemenea, să îndeplinească cerințele stabilite în DO-178B. Acest standard definește procesul de verificare a etapei de integrare a software-ului, verificând caracterul complet al procesului de verificare în sine, oferind managementul configurației (inclusiv controlul versiunilor) și calificând instrumente automate.

Standardul definește trei niveluri de testare a codului structural:

Acoperirea declarațiilor înseamnă că fiecare declarație dintr-un program este apelată cel puțin o dată;
acoperirea deciziei înseamnă că fiecare punct de intrare și ieșire din program a fost executat cel puțin o dată și că fiecare decizie din program a luat toate valorile de ieșire (booleene) posibile cel puțin o dată;
Acoperirea soluțiilor cu o condiție modificabilă înseamnă că fiecare punct de intrare și ieșire din program a fost executat cel puțin o dată, că fiecare decizie din program a luat toate valorile de ieșire (booleene) posibile cel puțin o dată și că fiecare condiție din soluție a rezultat într-o schimbare independentă a semnificațiilor de ieșire.

Nivelurile de certificare definite în DO-178B diferă în funcție de numărul de cerințe (profunzimea verificării) pe care software-ul trebuie să le îndeplinească. Aspectele teoretice ale verificării codului sunt prezentate în diferite monografii fundamentale, în special, în lucrare.

Certificarea la DO-178B trebuie să fie efectuată de așa-numiții reprezentanți ai ingineriei desemnați, care sunt numiți de FAA pentru a revizui datele utilizate în certificare. Dezvoltatorul încearcă să obțină certificarea software-ului său în conformitate cu DO-178B pentru a obține permisiunea de a utiliza software-ul său (inclusiv sistemul de operare în timp real) în aviație. Permisiunea se aplică nu numai software-ului, ci și întregului produs (proiect) în ansamblu. Pentru a începe procesul de certificare, un dezvoltator trebuie mai întâi să „deschidă” un proiect și să obțină un număr oficial de proiect de la FAA sau să se alăture unui proiect existent cu un număr de proiect deja emis. Pentru a „deschide” un proiect, trebuie să obțineți un certificat de tip sau un certificat de tip suplimentar. De obicei, un certificat de tip este atribuit unei aeronave și toate echipamentele de pe ea sunt livrate cu acel certificat. Un certificat de tip suplimentar este acordat echipamentelor suplimentare de pe aeronavă, inclusiv software-ul.

„Criterii generale” pentru evaluarea confidențialității

Criteriile comune definesc Evaluation Assurance Levels (EAL) și evaluează nu numai securitatea și fiabilitatea produselor, ci și procesele de dezvoltare și suport ale acestora pentru a se asigura că problemele sunt rezolvate rapid. Pentru sistemele de operare, cerințele Criteriilor generale sunt detaliate în . Există șapte niveluri de garantare a confidențialității:

EAL1 (testat funcțional)- aplicabil acolo unde este necesară confidențialitatea minimă, dar secretul nu este considerat o cerință importantă;

EAL2 (testat structural)- aplicabil în circumstanțe în care dezvoltatorii sau utilizatorii necesită un nivel mediu de secret garantat în absența informatii complete despre toate procedurile de dezvoltare;

EAL3 (testat și verificat metodic)- aplicabil în cazul în care dezvoltatorii sau utilizatorii necesită un nivel mediu de secretizare garantată și necesită un studiu exhaustiv al sistemului de operare și etapele dezvoltării acestuia, dar fără a recurge la o reelaborare semnificativă a OS;

EAL4 (proiectat, testat și revizuit metodic)- aplicabil în circumstanțe în care dezvoltatorii sau utilizatorii solicită un nivel ridicat de secretizare garantată a sistemului de operare și necesită modificarea specială a sistemului de operare existent pentru a îndeplini aceste cerințe;

EAL5 (proiectat și testat semi-formal)- aplicabil acolo unde dezvoltatorii sau utilizatorii cer un nivel ridicat de secretizare garantată a sistemului de operare și o abordare strictă a proiectării, astfel încât aceste proprietăți să fie încorporate deja în faza de proiectare, folosind mijloace speciale de asigurare a secretului;

EAL6 (semi formal verificat, proiectat și testat)- aplicabil acolo unde există un nivel ridicat de situații periculoase și unde sunt justificate costuri mari de protecție împotriva accesului neautorizat;

EAL7 (verificat formal, proiectat și testat)- ar trebui folosit in aplicatii cu un cost foarte mare in cazul accesului neautorizat.

Nivelul EAL este confirmat de un laborator special, Common Criteria Testing Lab.

Tabelul prezintă o listă a cerințelor de garanție maximă de securitate pe care sistemul trebuie să le îndeplinească la nivelul EAL7.

Sistemul LynxOS-178

LynxOS-178 se bazează pe sistemul de operare în timp real LynxOS v.3, care rulează într-o partiție izolată. LynxOS v.3 este certificat la POSIX 1003.1-1996 pe platformele Intel și PowerPC.

O caracteristică cheie a LynxOS-178 este suportul pentru mai multe partiții care sunt complet separate în timp, memorie și resurse în conformitate cu cerințele ARINC 653. LynxOS-178 (versiunea 2.0) acceptă: până la 16 partiții (mașini virtuale), inclusiv partiția rădăcină; până la 64 de procese; până la 51 de fire în cadrul fiecărui proces; expedierea firelor de execuție într-o partiție în timp real; funcțiile de comunicare între procese în cadrul unei partiții.

Fiecare partiție este complet izolată, ceea ce face imposibilă propagarea erorilor între partiții.

Cu LynxOS-178, partițiile fixe sunt servite ca mașini virtuale LynxOS. Fiecare proces de aplicație funcționează în propriul mediu de sistem de operare ca și cum ar rula pe propriul procesor. Acest lucru se aplică tuturor resurselor CPU și spațiilor denumite. Această abstractizare protejează dezvoltatorul de aplicații de efort suplimentar de programare. sistem complex. Gestionarea partițiilor este controlată prin Virtual-Machine Configuration Table (VCT) și este obligatorie în mediul LynxOS-178, permițând dezvoltatorului de aplicații să se concentreze mai degrabă pe dezvoltarea aplicațiilor decât pe partiționarea sistemului. În plus, LynxOS-178 acceptă partiționarea sistemelor compatibile RTCA DO-255, permițând software-ului cu diferite niveluri de securitate DO-178B să ruleze pe diferite partiții (mașini virtuale). Aceasta înseamnă că sistemul de operare poate rula o aplicație de nivel A (DO-178B) pe o mașină virtuală și o aplicație de nivel C pe alta, ambele aplicații rulând pe același procesor în același sistem.

Versiunea LynxOS-178 inclusă în diferite produse (de exemplu, aeronava Bombardier Challenger 300 de la Rockwell Collins) este certificată conform standardului DO-178B și arhitectura sistemului de operare în sine ( orez. 3) îndeplinește cerințele ARINC 653.

LynxOS-178 furnizează următoarele grupuri de servicii de sistem în conformitate cu ARINC 653: Gestionarea partițiilor - managementul partițiilor, Managementul proceselor - managementul proceselor, Managementul timpului - managementul timpului, Comunicarea interpartiției - interacțiunea proceselor în diferite secțiuni (Servicii de eșantionare a portului și Portul de așteptare) Servicii), Comunicare intrapartiție - interacțiunea proceselor într-o singură partiție (Servicii tampon, Servicii Blackboard, Servicii Semaphore, Servicii pentru evenimente), Monitorizarea sănătății - monitorizarea stării de sănătate a sistemului de operare sau a echipamentului.

Un prototip de sistem de operare care îndeplinește EAL7 urmează să fie lansat în 2006; se dezvoltă un nou nucleu LynxSecure, compatibil cu cerințele MILS, care va conține doar 8 mii de linii cod sursași va respecta cerințele EAL7.

Fără îndoială, cerințele luate în considerare pentru sistemele de operare în timp real sunt foarte semnificative pentru multe alte industrii, cum ar fi marina, armata și sisteme spațiale, sisteme de comunicații, echipamente de susținere a vieții, sisteme destinate utilizării în situații de urgență - oriunde este nevoie de un răspuns rapid la evenimente, fiabilitate ridicată, durabilitate și siguranță a instrumentelor utilizate, inclusiv a software-ului.

Literatură

Sistem de operare comercial în timp real și considerație arhitecturală. Raport final, S.U.A. Administrația Federală a Aviației, DOT/FAA/AR-03/77, februarie 2004.
Partitionare in Avionica. Arhitectură: cerințe, mecanică și asigurare. Raport final, National Aeronautics and Space Administration, DOT/FAA/AR-99/58, NASA/CR-1999-209347, martie 2000.
Studiu al sistemului de operare în timp real (RTOS) în aplicația de aviație comercială off-the-self (COTS). Raport final, S.U.A. Administrația Federală a Aviației, DOT/FAA/AR-02/118, decembrie 2002.
Evaluarea sistemelor de operare în timp real – rolul standardelor. Comitetul de standardizare a sistemelor aviatice (ASSC), Doc No: ASSC/330/2/141, martie 1997.
G. Mayers, Arta testării software-ului. John Wiley & Sons, 1979.
Profil de protecție de securitate COTS - Sisteme de operare (CSPP-OS), NISTIR 6985, aprilie 2003.
Criterii comune pentru evaluarea securității tehnologiei informației. Partea 3: Cerințe de asigurare a securității. august 1999, versiunea 2.1, CCIMB-99-033.

Serghei Zolotarev ( [email protected]) - angajat al companiei RTSoft (Moscova).

S-a hotărât să se actualizeze echipamentul de realimentare strategic cu rază lungă de acțiune KC-135 Stratotanker pentru a asigura conformitatea cu reglementările internaționale de management al traficului aerian global și cu cerințele standardului DO-178B. Hardware-ul Centrului de procesare integrat, dezvoltat de Rockwell Collins, oferă capabilități de calcul și de rețea care pot fi utilizate pentru a îndeplini o varietate de sarcini diferite (suport pentru misiuni, controlul zborului, suport pentru afișare). Funcționalitate de bază se extinde, permițând implementarea unor aplicații suplimentare. Schimbul de date cu alte echipamente se realizează prin versiunea „aviație” a rețelei Ethernet. Există mai multe module înlocuibile de linie disponibile în cadrul Centrului de procesare integrat. Sistemul de operare în timp real certificat LynxOS-178 rulează pe modulul de calcul comun și modulul concentrator de intrare/ieșire.

Aeronava tanc KC-767, care rulează și sistemul de operare LynxOS-178, este gata să ducă realimentarea aeriană a Forțelor Aeriene ale SUA la următorul nivel și să retragă tancurile moștenite KC-135E care au fost în serviciu de mai bine de patru decenii. Noul vas nu este doar mai spațios, ci și mai fiabil, făcându-l potrivit pentru o gamă mai largă de operațiuni. De fapt, KC-767 este patru avioane diferite într-una. Puntea unde se află cabina echipajului poate fi echipată cu ușurință pentru a transporta pasageri sau marfă fără a compromite funcționalitatea tancului. Mai mult, se poate face astfel încât, în funcție de situație, nava să fie fie pasager, fie marfă, fie transportator tip mixt.

În literatura în limba engleză, sunt utilizați doi termeni - siguranță și securitate, care pot fi traduși în mod similar în rusă. Cu toate acestea, ele înseamnă lucruri diferite, iar în acest articol vom folosi siguranța ca sinonim pentru securitate și securitate ca sinonim pentru secret. - Notă auto