Reāllaika elektroniskās sistēmas: pamati, plānošana un pielietojums

Informatec Digital » Resursi » Reāllaika elektroniskās sistēmas: pamati, plānošana un pielietojums

L reāllaika elektroniskās sistēmas Tie ir dziļi iesakņojušies mūsu ikdienas dzīvē, lai gan bieži vien paliek nepamanīti. Sākot ar automašīnu drošības spilveniem un beidzot ar gaisa satiksmes vadību un pat vienkāršu mikroviļņu krāsni, viss ir atkarīgs no datorsistēmas, kas ne tikai dara lietas pareizi, bet arī faktiski tās dara. īstajā laikāJa laika limits tiek pārsniegts, pat nedaudz, tas tiek uzskatīts par neizdošanos, pat ja aprēķins ir perfekts.

Šo sistēmu skaistums (un grūtības) slēpjas faktā, ka tām ir jāmijiedarbojas ar fiziskajā pasaulē, ievērojot ļoti konkrētus termiņusNepietiek tikai ar "ātrumu": tiem jābūt paredzamiem, stabiliem un sinhronizētiem ar to, kas notiek ārpus datora. Tāpēc reāllaika sistēmas projektēšana, analīze un testēšana ir ievērojami delikātāka nekā parastā, vispārējas nozīmes sistēmā.

Kas ir reāllaika sistēma un kā tā atšķiras no ātrās sistēmas?

Reāllaika sistēma (RTS) būtībā ir digitāla sistēma, kas kontrolē vai uzrauga fiziskus procesus ar skaidriem laika ierobežojumiem. Tam ne tikai jārada loģiski pareizi rezultāti, bet arī jāgarantē, ka atbilde tiek saņemta noteiktā laika posmā; šī termiņa neievērošana tiek uzskatīta par sistēmas kļūmi.

Ļoti spilgti šīs uzvedības piemēri ir automašīnas drošības spilvena vai ABS aktivizēšanaRobots, kuram jānoķer bumba gaisā, vai mūsdienu transportlīdzekļa dzinēja vadības sistēma. Visos šajos gadījumos aizkavēta reakcija, pat ja tā notiek dažas milisekundes vēlāk, var būt bezjēdzīga vai pat bīstama.

Vārds “laiks” šajā kontekstā nozīmē, ka pareiza darbība ir atkarīga no kad rodas reakcijane tikai to, kas tā ir. Un “reāls” nozīmē, ka sistēmai tās faktiskās evolūcijas laikā ir jāreaģē uz ārējiem notikumiem, izmantojot laika skalu, kas atbilst tās kontrolētās fiziskās vides laika skalai.

Tas ir pretstatā vienkārši “ātrai” sistēmai, kur vienīgais svarīgais ir tas, lai izvade parādītos pēc iespējas ātrāk, bez nepieciešamības sinhronizēties ar ārpasauli. Ļoti jaudīgs tīmekļa serveris var būt ātrs, taču tas nav obligāti reāllaika sistēma ja tam nav stingru termiņu, kas saistīti ar fiziskiem notikumiem.

Ir arī svarīgi tos atšķirt no tiešsaistes sistēmasŠīs sistēmas vienmēr var būt savienotas un reaģēt uz pieprasījumiem (piemēram, pārlūkprogramma vai rezervēšanas sistēma), taču tām nav obligāti jāievēro stingri termiņi, kas saskaņoti ar fiziskajiem procesiem, tāpēc tās automātiski nav reāllaika sistēmas; tomēr mūsdienu tīmekļa lietojumprogrammās, reāllaika meklēšana var būt nepieciešami līdzīgi latentuma laiki un garantijas.

Praktisks piemērs: luksofora vadība krustojumā

Ļoti ilustratīvs reāllaika piemērs elektroniskajās sistēmās ir a luksoforu vadības sistēma noslogotā krustojumāNepietiek tikai mainīt gaismas "vairāk vai mazāk" laikā: lēmumi jāpieņem nepārtraukti, pamatojoties uz to, kas notiek uz ielas.

Pirmkārt, satiksmes skaitīšanaJoslās un gājēju pārejās tiek novietoti sensori (induktīvās cilpas, kameras, infrasarkanie sensori utt.), lai noteiktu transportlīdzekļus un cilvēkus. Šīs ierīces pastāvīgi sūta datus centrālajam kontrolierim, kas tādējādi saņem aktuālu informāciju par vidi.

Vadības centrā iegultais dators apstrādā datus reāllaikā, pielietojot algoritmus Šīs sistēmas aprēķina rindā esošo transportlīdzekļu skaitu, katras joslas aizņemtību un gaidošo gājēju skaitu. Izmantojot šo informāciju, tās nosaka, cik ilgi jādarbojas katrai luksofora fāzei katrā virzienā.

Tad nāk lēmumu pieņemšanaPiemēram, sistēma nolemj pagarināt zaļo gaismu visvairāk noslogotajā virzienā, lai samazinātu satiksmes sastrēgumus, vai piešķirt prioritāti gājēju pārejai, ja tā ir pārāk ilgi gaidījusi. Šie lēmumi ir balstīti uz iepriekš definētām optimizācijas politikām un drošības un satiksmes plūsmas prasībām.

Kad lēmums ir pieņemts, kontrolieris rīkojas saskaņā ar to. izpildmehānismi, kas kontrolē gaismasTas maina luksoforu stāvokli ar milisekundes precizitāti, ievērojot dzelteno un sarkano gaismu, bloķēšanas mehānismus un citas drošības prasības, nodrošinot vienmērīgu pāreju starp fāzēm.

Tas viss tiek darīts ar nepārtraukta optimizācijaSistēma nepārtraukti uzrauga satiksmi un reāllaikā pielāgo zaļās, dzeltenās un sarkanās gaismas laikus, lai pielāgotos pēkšņām izmaiņām (satiksmes sastrēgumam, garāmbraucošai ātrajai palīdzībai, satiksmes plūsmas izmaiņām dažādos diennakts laikos utt.). Tas skaidri parāda, kāpēc mēs runājam par reāllaiku: vadības loģikai ir jēga tikai tad, ja lēmumi tiek izpildīti noteiktā laika posmā.

Reālā laika sistēmu vēsture un evolūcija

Reāllaika skaitļošanas izcelsme ir cieši saistīta ar rūpniecisko un kosmosa procesu vadība 20. gadsimta otrajā pusē. Jau 1965. gadā tika publicēti uzziņu teksti, kas lika pamatus šīm sistēmām, un neilgi pēc tam, 1973. gadā, Liu un Leilends formalizēja plānošanas matemātisko definīciju stingrās un elastīgās reāllaika sistēmās.

Datorsimulācijā terminu "reālā laika simulācijas" sāka lietot, kad Datora modelis darbojās tikpat ātri kā fiziskais process. ko tas pārstāvēja. Šeit parādījās klasiska dilemma: vai nu palielināt modeļa precizitāti un upurēt ātrumu, vai arī samazināt precizitāti, lai sasniegtu vai pārsniegtu reāllaiku.

Tas pats notika ar grafiskās saskarnes un videospēļu dzinējiLai nodrošinātu vienmērīgu pieredzi, tiem ir pietiekami ātri jāreaģē uz lietotāja ievadi un ainas izmaiņām, saglabājot augstu un nemainīgu kadru skaitu sekundē.

Kopš 20. gs. sešdesmitajiem un septiņdesmitajiem gadiem reāllaika sistēmas ir attīstījušās, pateicoties gūtās mācības no augsta līmeņa reālās dzīves gadījumiem, daži gandrīz katastrofāli, kas palīdzēja pilnveidot laika analīzes un plānošanas metodes.

Ievērojami gadījumi: Apollo 11 un Mars Pathfinder

Viens no slavenākajiem incidentiem reāllaika televīzijas agrīnajā vēsturē bija Apollo 11 Mēness moduļa datora pārslodzeNolaišanās laikā vadības sistēma sāka izdot trauksmes signālus (piemēram, slaveno 1202), kas norādīja, ka centrālais procesors atpaliek no savas darba slodzes.

Saskaņā ar misijas ziņojumiem, ja šīs trauksmes būtu turpinājušās, navigācijas datu uzticamība Apkalpes drošība būtu apdraudēta, un misija varētu tikt atcelta. Galu galā, pamatojoties uz iepriekšējām simulācijām un pieredzi, tika pieņemts lēmums turpināt, un Eagle modulis veiksmīgi nolaidās uz Mēness.

Būtībā tas bija procesora pārslodzes situācijaBija vairāk aprēķinu, nekā centrālais procesors spēja apstrādāt atvēlētajā laikā, īpaši, ja parastajai darba slodzei tika pievienota ar trauksmi saistīta apstrāde. Šis incidents uzsvēra pietiekamu resursu rezervju uzturēšanas nozīmi sistēmās, kurās kļūmes izmaksas ir nepieņemamas.

Vēl viens daudz pētīts gadījums ir par Marsa kosmosa kuģis PathfinderProblēma šeit nebija tik daudz neapstrādātu datu pārslodze, bet gan parādība, kas pazīstama kā prioritātes inversija, kas izraisīja nokavētus termiņus, pat ja centrālajam procesoram bija šķietami saprātīga jaudas rezerve.

Sistēmā ar preventīvu plānošanu prioritātes inversija notiek, ja Augstas prioritātes uzdevumu bloķē zemas prioritātes uzdevums. kam ir koplietots resurss (piemēram, savstarpējas darbības (mutex) uzdevums), un tikmēr vidējas prioritātes uzdevums pārtrauc zemas prioritātes uzdevumu. Rezultātā kritisko uzdevumu netieši bloķē mazāk svarīgs uzdevums, tādējādi pārkāpjot reāllaika garantijas.

Lai mazinātu šo risku, tiek izmantoti šādi līdzekļi: prioritātes mantošanas protokolsKad augstas prioritātes uzdevumu bloķē zemākas prioritātes uzdevums, plānotājs īslaicīgi paaugstina zemas prioritātes uzdevuma prioritāti līdz augstas prioritātes uzdevuma līmenim. Tas neļauj vidējas prioritātes uzdevumiem to pārtraukt, ļaujot tam pēc iespējas ātrāk atbrīvot resursu un pēc tam atgriezties pie sākotnējās prioritātes.

Šie gadījumi skaidri parādīja, ka STR izstrāde nenozīmē tikai "pietiekamu CPU brīvo jaudu", bet arī Plānošanas un sinhronizācijas teorijas izpratneun īslaicīgi pārbaudiet visu sistēmu (aparatūru, programmaparatūru un programmatūru) kopā.

Reāllaika sistēmas pamatkomponenti

Tipisks STR sastāv no šādu elementu kombinācijas: specifiski aparatūras, programmatūras un saskarnes elementi ar fizisko procesu. Tā neaprobežojas tikai ar vienkāršu programmu: tā ir integrēta sistēma, kurai jāreaģē uz ārējiem stimuliem zināmos laika posmos.

Fiziskajā pusē mēs atrodam sistēma, kas jākontrolēTas var būt jebkurš regulējams process, piemēram, rūpniecības iekārta, dzinējs, ražošanas līnija, luksofors, robots vai medicīnas iekārta. STR mēra tā stāvokli un veic vadības darbības, lai to uzturētu vēlamajos parametros.

Starp fizisko pasauli un datoru pastāv signāla saskarneŠis slānis sastāv no analogciparu pārveidotājiem (ADC) un ciparu-analogajiem pārveidotājiem (DAC), kā arī no kondicionēšanas shēmām. Tas pielāgo spriegumus, strāvas un signālu formātus, lai tos varētu nolasīt un ģenerēt digitālā sistēma.

Galvenais elements ir reāllaika pulkstenisŠī sistēma ģenerē periodiskus pārtraukumus katra paraugu ņemšanas perioda laikā. Tā sinhronizē datu iegūšanas, vadības un izpildes uzdevumus, nodrošinot, ka mērījumi un komandas tiek izdotas precīzi tad, kad tas nepieciešams.

Sistēma parasti ietver konsole cilvēka operatoramTam ir ieslēgšanas un izslēgšanas vadības ierīces, saskarnes parametru pielāgošanai un mehānismi manuālo režīmu piespiešanai. Turklāt ekrāni tiek izmantoti, lai parādītu statusus, trauksmes signālus, tendences un jebkādu citu svarīgu informāciju procesa uzraudzībai.

Svarīgas stāvokļa izmaiņas tiek saglabātas reāllaika datubāzeTas ļauj atcerēties notikušo, izmeklēt kļūmes un iegūt statistiku, lai uzlabotu pārvaldību. Šī vēsturiskā informācija laika gaitā pieaug un ietekmē apkopes, optimizācijas vai pārveidošanas lēmumus.

Daudzās rūpnieciskās vidēs tālvadības uzraudzības sistēmaTas ļauj veikt uzraudzību un dažos gadījumos iejaukšanos rūpnīcā no izkliedētiem vadības centriem. Tas ir ļoti svarīgi, ja viena iekārta ir atkarīga no citas (piemēram, rūpnīca, kas piegādā izejvielas citai), un vienā pieņemtie lēmumi ietekmē visu ķēdi.

STR centrā ir iegultais datorskura programmatūra parasti tiek sadalīta vairāku veidu moduļos: digitālās vadības algoritmi (regulatori, filtri, atgriezeniskās saites cilpas), datu reģistrēšana, vadības un virziena saskarnes un tieša mijiedarbība ar operatoru.

Galvenās iezīmes: laiks, vienlaicīgums, drošība un efektivitāte

Reāllaika sistēmas parasti risina problēmas, kas saistītas ar liels izmērs un sarežģītībaar vairākiem mainīgajiem, ārējām ierīcēm un mainīgiem apstākļiem. Tas prasa rūpīgu uzmanību arhitektūrai, plānošanai un komunikācijas mehānismiem starp uzdevumiem.

Tā kā dati nāk no fiziskās pasaules, sistēmai ir jāapstrādā reālie skaitļi (peldošie punkti, fiksētas skalas utt.), kas attēlo tādus lielumus kā temperatūra, spiediens, ātrums vai spriegums. Attēlojuma un aprēķinu precizitāte var būt izšķiroša vadības kvalitātei.

La drošība un uzticamība Šīs sistēmas parasti ir kritiskas: kļūme var izraisīt nopietnus ekonomiskus zaudējumus, materiālus bojājumus, miesas bojājumus vai ietekmi uz vidi. Tāpēc tiek integrētas kļūdu tolerances metodes, redundance un kontrolētas degradācijas stratēģijas.

Vienlaicīgums ir vēl viena raksturīga iezīme. STR parasti loģiski paralēli izpilda vairākus uzdevumus: sensoru nolasīšana, vadība, sakari, ierakstīšanalietotāja saskarne utt. Tas prasa pārvaldīt koplietotos resursus, izvairīties no sacensības nosacījumiem un nodrošināt, ka kritiskās sadaļas nepārkāpj termiņus.

Efektivitāte nav greznība, tā ir nepieciešamība. STR ir jābūt loģiski un laika ziņā pareizibet arī optimizēts, lai pilnībā izmantotu centrālā procesora, atmiņas un I/O ierīču priekšrocības. Izaicinājums ir atrast līdzsvaru starp laika posmu, aparatūras izmaksām un programmatūras sarežģītību.

Ievades/izvades ierīces parasti ir specializēta un cieši saistīta ar fizisko procesuMēs nerunājam tikai par vispārīgām pieslēgvietām, bet gan par lauka kopnēm, viedajiem sensoriem un komunikācijas protokoliem, kas izstrādāti, lai samazinātu latentumu un nodrošinātu īsus piegādes laikus.

Reālā laika sistēmu veidi: cietās, mīkstās un stingrās

Atkarībā no tā, cik nopietni tie apstrādā laika kļūdas, STR tiek klasificēti vairākās kategorijās. Sistēmā, kurā ir grūti reāllaikāVisi termiņi ir jāievēro bez izņēmuma. Pat viena termiņa neievērošana var radīt nopietnas sekas vai vismaz padarīt rezultātu nederīgu.

Tipiski stingrā reāllaika piemēri ir šādi: lidojumu vadība, noteiktas kritiski svarīgas medicīnas sistēmasvai elektriskās infrastruktūras aizsardzību. Šādos gadījumos pareizs, bet novēlots rezultāts ir bezjēdzīgs; sistēmai jābūt projektētai tā, lai nekādā paredzamā scenārijā tā neievērotu laika ierobežojumu.

Sistēmas mīksts reāllaiks Tie pieļauj neregulāras aizkaves. Rezultāta lietderība samazinās līdz ar aizkavi, taču to joprojām var izmantot. Tas attiecas uz multimediju vai datu ieguves lietojumprogrammām, kur daži pazaudēti kadri vai aizkavēti paraugi pasliktina kvalitāti, bet sistēma turpina darboties.

Starp šīm divām galējībām atrodas sistēmas, kas stingrs reāllaikaŠeit tiek pieļauti neregulāri termiņu nokavējumi, bet, ja atbilde pienāk ar nokavēšanos, tā zaudē visu vērtību un tiek atmesta. Klasisks piemērs ir reāllaika video vai telekomunikāciju sistēmas: kadrs, kas pienāk ar nokavēšanos, tiek atmests, lai saglabātu straumes sinhronizāciju.

Arhitektūras: atvērta/slēgta un centralizēta/izkliedēta

Reālā laika sistēmas var klasificēt arī pēc to pakāpes tehnoloģiskā atvērtībaPatentētas sistēmas izmanto slēgtas tehnoloģijas un protokolus, kurus kontrolē viens pakalpojumu sniedzējs, kas var nodrošināt labu veiktspēju, bet ierobežo sadarbspēju un attīstību.

Turpretī atvērtās sistēmas izmanto publiskie standarti un protokoli kas atvieglo dažādu ražotāju komponentu integrāciju, programmatūras atkārtotu izmantošanu un pakāpenisku migrāciju uz jaunām platformām.

Vēl viena svarīga atšķirība ir starp sistēmām centralizēta un izplatītaCentralizētā pieejā galvenais mezgls ir atbildīgs par komunikācijas un kritiskās apstrādes koordinēšanu, bet pārējie mezgli darbojas kā relatīvi vienkārši termināļi vai perifērijas ierīces.

Izplatītā arhitektūrā apstrāde un komunikācija ir sadalītas starp vairākiem intelektuāliem mezgliem, kas sadarbojas vairāk vai mazāk autonomi. Tas nodrošina mērogojamību, redundanci un tuvumu fiziskajam procesam, bet sarežģī laika sinhronizāciju un globālo koordināciju.

Determinisms, pārtraukuma latentums un reaģētspēja

Determinisms ir STR centrālais atribūts: tā ir spēja Ar lielu varbūtību prognozēt, cik ilgs laiks būs nepieciešams uzdevuma uzsākšanai un pabeigšanaiRuna nav par to, lai būtu pēc iespējas ātrāks, bet gan par zināmu un ierobežotu reakcijas laiku.

Pārtraukuma latentums mēra laiks kopš ārēja pārtraukuma (piemēram, sensors, kas ziņo par notikumu), līdz sistēma sāk to apstrādāt. Šī vērtība ir kritiski svarīga, jo daudzi pakalpojumu pieprasījumi rodas no fiziskās vides un nevar pieļaut patvaļīgas kavēšanās.

Reaģēšanas spēja koncentrējas uz laiku, kas nepieciešams uzdevuma izpildei jāizpilda, tiklīdz pārtraukums ir pieņemtsTas ietver tādus faktorus kā apkalpošanas rutīnas palaišanas laiks, saistītās apstrādes ilgums un ligzdotu pārtraukumu vai priekšnosacījumu ietekme.

Sistēmas raksturošanai parasti tiek veikta determinisma un reaģētspējas kvantitatīva analīze: piemēram, var būt nepieciešams, lai 95% uzdevumu tiks izpildīti noteiktā laika posmāTurpmāk lietojumprogrammas, kas darbojas RTOS, ir jāprojektē tā, lai izvairītos no nonākšanas sliktākajā paredzamajā veiktspējas diapazonā.

Sistēmas vadība pēc procesiem un uzticamība

Daudzās progresīvās reāllaika sistēmās pašiem lietojumprogrammu procesiem ir ļoti smalka sistēmas kontroleViņi var skaidri deklarēt savu prioritāti, atmiņas prasības (kurai daļai jāpaliek kešatmiņā, kāda mijmaiņas politika tiek atbalstīta utt.) un nepieciešamās privilēģijas.

Lai gan no pirmā acu uzmetiena tas var šķist anarhisks modelis, patiesībā tas ir balstīts uz precīzi definēti procesu veidi un skaidri ierobežojumiIr ierasts noteikt tādas prasības kā: "apkopes procesi nedrīkst pārsniegt 3% centrālā procesora noslodzes, izņemot skaidri definētus zemas slodzes logus".

Uzticamība ir kas vairāk nekā tikai neregulāru kļūmju neesamība. STR ir jāuztur pakalpojuma kvalitāte saskaņotajās robežās ilgstoši, garantējot reakcijas laikus atbilstoši specifikācijām pat saprātīgu traucējumu gadījumā.

Turklāt ir nepieciešams Kļūdu toleranceJa rodas nopietna problēma (aparatūras kļūme, cilvēciska kļūda, ārēji traucējumi), sistēmai ir jāsaglabā pēc iespējas vairāk datu un funkcionalitātes, kā arī jāsamazina tās darbība, piešķirot prioritāti visaugstākās prioritātes kritiskajiem uzdevumiem.

Valodas un reāllaika programmēšana

Praksē daudzi STR ir iegulti un tiem ir jāmijiedarbojas ar daudziem ārējiem komponentiem, tāpēc vienlaicīga programmēšana un tieša ierīces vadība Tie ir fundamentāli. Mūsdienu valodas piedāvā primitīvus pavedienu veidošanai, saziņai un sinhronizācijai, taču reāllaikā tie jāizmanto ļoti uzmanīgi, īpaši tīmekļa sistēmās un pakalpojumos, piemēram, Laravel reāllaikā.

Īstenošanas efektivitāte ir galvenais: “jaukas” valodas funkcijas var galu galā būt dārgas. reakcijas laiks, centrālā procesora noslodze vai atmiņas patēriņšTāpēc iegultās sistēmās katra abstrakcija tiek rūpīgi izvērtēta pirms tās pieņemšanas.

Divas valodas ar ievērojamu klātbūtni reāllaika pasaulē ir Ada un Java ar reāllaika paplašinājumiemAda tika izveidota tieši ar nolūku atbalstīt kritiski svarīgas sistēmas, un tajā ir ieviesti uzlabojumi, lai stiprinātu tās iespējas šajā jomā.

Java gadījumā reāllaika funkcijas tika pievienotas vēlāk ar tādām specifikācijām kā Java reāllaika specifikācija un reāllaika kodola paplašinājumu, kas ievieš atmiņas un plānošanas modeļus, kas ir labāk piemēroti RTOS.

Reāllaika operētājsistēmas (RTOS)

Reāllaika operētājsistēma (RTOS) ir pamata programmatūra, kas nodrošina ietvaru uz kuras tiek veidotas lietojumprogrammas ar stingriem termiņiem. Ir nepieciešams, lai tās pakalpojumi (plānošana, pārtraukumi, sinhronizācija, I/O utt.) darbotos paredzami.

Atšķirībā no vispārējas nozīmes operētājsistēmas, RTOS ir optimizācija atkārtotu uzdevumu izpildei ļoti īsos termiņosMērķis nav "izdarīt daudz lietu", bet gan nodrošināt, lai vissvarīgākais uzdevums tiktu veikts tad, kad tas ir jāveic, bez pārsteigumiem.

Tāpēc tās parasti ir daudz vieglākas sistēmas bez grafiskiem papildinājumiem vai nevajadzīgiem pakalpojumiem, ar tikai dažu megabaitu izmēru un minimālistisku dizaina filozofiju. Mazāk koda nozīmē mazāka negaidīta latentuma un mazāk kļūmju punktukas atbilst reāllaika vajadzībām.

Vēsturiski RTOS izstrāde sākās 20. gs. sešdesmitajos un septiņdesmitajos gados militāriem, kosmosa un rūpniecības lietojumiem. Turpmākajās desmitgadēs parādījās komerciāli produkti, kas pazīstami kā VxWorks, QNX vai reāllaika Solaris varianti, plaši izmanto telekomunikācijās, autobūves un iegultajās sistēmās.

Līdz ar lietu interneta (IoT) pieaugumu 2000. un 2010. gados, tādas vieglas RTOS kā FreeRTOS Tie ir kļuvuši ļoti populāri mazjaudas savienotajās ierīcēs. Vienlaikus ir ierosināti reāllaika POSIX paplašinājumi, lai vienādotu saskarnes un atvieglotu programmatūras pārnesamību.

Mūsdienās daudzas RTOS integrējas ar mākslīgais intelekts un mašīnmācīšanās metodes lai optimizētu plānošanu, prognozētu kļūmes vai pielāgotu vadības parametrus izpildes laikā. Tas viss, protams, nezaudējot no redzesloka laika garantijas.

RTOS tirgus vērtība ir vairāki miljardi dolāru, un paredzams, ka turpmākajos gados tas pastāvīgi pieaugs, pateicoties medicīnas ierīces, rūpnieciskā automatizācija, autobūve un kritiskās infrastruktūras sistēmas.

Prasības, kurām jāatbilst labam RTOS

Mūsdienīgai RTOS ir jābūt daudzuzdevumu veikšana un preventīva darbībaTas ļauj tai atlikt zemākas prioritātes uzdevumus, lai nekavējoties izpildītu steidzamāku. Prioritātēs balstīta plānošana ir dominējošā paradigma: tā vienmēr izpilda vissvarīgāko uzdevumu, kas ir gatavs izpildei.

Turklāt tam ir jānodrošina komunikācijas un sinhronizācijas mehānismi (rindas, semafori, savstarpējas apmaiņas (muteksi), notikumi), kas paredzēti, lai samazinātu nevajadzīgu bloķēšanu un izvairītos no tādām parādībām kā prioritātes inversija, attiecīgā gadījumā piemērojot mantojuma protokolus vai prioritātes ierobežošanu.

Ir svarīgi, lai RTOS laika uzvedība ir labi zināma.Maksimālie pārtraukumu latentumi, konteksta pārslēgšanas laiki, sinhronizācijas primitīvu izpildes laiki utt. Bez šiem datiem nav iespējams pierādīt, ka lietojumprogramma ievēro savus termiņus.

Plānošanas algoritmi: EDF un citi modeļi

Uzdevumu plānošana ir viens no SRT stūrakmeņiem. Starp visvairāk pētītajiem algoritmiem izceļas šāds: Agrākais termiņš vispirms (EDF), optimāls dinamiskās prioritātes plānotājs daudzos reāllaika kontekstos.

EDF prioritizē uzdevumus, pamatojoties uz to absolūtais izpildes termiņšUzdevumam ar tuvāko termiņu jebkurā laikā ir visaugstākā prioritāte. Tas noteiktos apstākļos nodrošina, ka, ja pastāv izpildāms plāns, kas atbilst visiem termiņiem, EDF to atradīs.

Šis algoritms ir preventīvs: ja uzdevuma izpildes laikā pienāk cits uzdevums ar steidzamāku termiņu, sistēma var pārtraukt pašreizējo uzdevumu un atbrīvot centrālo procesoru uz jauno. Lai ieviestu EDF, parasti tiek izmantota prioritārā rinda, kas sakārtota pēc atlikušā laika līdz termiņa beigām.

Viena no EDF priekšrocībām ir tā, ka tā var sasniegt CPU noslodze tuvu 100% Termiņu ievērošana, ja vien uzdevumu kopums ir plānojams. Turklāt tas labi pielāgojas dinamiskai videi, kurā mainās termiņi vai paredzamais izpildes laiks.

Piemēram, ja mums ir divi procesi P1 un P2 ar atšķirīgiem periodiem un aprēķina laikiem, EDF vienmēr dos priekšroku instancei, kuras absolūtais termiņš ir vistuvākais. mainīgu tā izpildi jo tiek veiktas jaunas aktivizācijas un termiņi tiek pārrēķināti.

Tomēr EDF nav bez saviem trūkumiem. Situācijās ar ārkārtīgi liela darba slodze un biežas izmaiņas To var sarežģīt efektīvi ieviest, un noteiktos apstākļos uzdevumiem ar relatīvi gariem termiņiem var rasties resursu trūkuma problēmas.

Citi labi zināmi reāllaika algoritmi ietver Monotoniskā likme (RM) un Monotoniskais termiņš (DM)Šīs sistēmas izmanto fiksētas prioritātes, kuru pamatā ir uzdevumu periods vai relatīvais laika grafiks. Katrai no tām ir savi optimalitātes nosacījumi un vēlamā pielietojuma joma.

Reāllaika sistēmu tipiskie pielietojumi

STR ir visur. Iekšpusē apstrādes rūpniecība Tos izmanto, lai kontrolētu un uzraudzītu pārtikas, dzērienu, ķīmisko vielu, farmaceitisko līdzekļu u. c. ražošanas līnijas, nodrošinot, ka galvenie mainīgie lielumi tiek saglabāti to robežās un ka gala produktam ir paredzētā kvalitāte.

Transportā lidmašīnas, vilcieni, automašīnas un kuģi ir atkarīgi no reāllaika navigācijas, vadības un drošības sistēmasNo ABS bremžu sistēmām līdz vilkmes un stabilitātes kontrolei, tostarp dzelzceļa vai jūras satiksmes vadības sistēmām.

the telekomunikācijas Mūsdienu sistēmas balstās uz informācijas plūsmas pārvaldību reāllaikā ātrgaitas tīklos: pakešu komutācija, tiešraides balss un video pārraide, pakalpojumu kvalitātes nodrošināšana un latentuma samazināšana ir uzdevumi, kuros termiņu ievērošana ir būtiska.

Aizsardzības, novērošanas, radaru, elektroniskās kara un kiberdrošības sistēmu izmantošanas jomā reāllaika platformas draudu atklāšanai un reaģēšanai uz tiem dažu milisekundžu vai īsākā laikā, aizsargājot kritisko infrastruktūru un stratēģiskos resursus.

Medicīnā tādas iekārtas kā dzīvības pazīmju monitori, ventilatori, elektrokardiostimulatori vai infūzijas sūkņi Tie darbojas ar reāllaika programmatūru, kurai droši jāreaģē uz izmaiņām pacienta stāvoklī, bieži vien ar dzīvībai vai nāvei bīstamām sekām, ja termiņi netiek ievēroti.

Papildus digitālajai pasaulei reāllaiku var novērot arī bioloģiskajos procesos. Piemēram, sēkla dīgst tikai kad vides apstākļi ir noteiktos diapazonos un laikos (mitrums, temperatūra, gaisma). Ja tas uzdīgtu, tiklīdz pieskārās augsnei, neievērojot šos laika ierobežojumus, tas, iespējams, neizdzīvotu. Tā ir noderīga metafora tam, kā sistēma, kas nepielāgojas savai laika videi, var neizdoties.

Raugoties kopumā, STR attiecas uz telekomunikācijas, multimediji, rūpnieciskā vadība, robotika, aviācijas elektronika, dzelzceļi, autobūve, sadzīves tehnika, zinātniskie eksperimenti un medicīnas sistēmasUn saraksts turpina pieaugt, attīstoties jaunām tehnoloģijām.

Visās šajās vidēs ir nepieciešams sekojošais: īpaši reāllaika saziņas protokoli, piemēram, CAN, Token Bus, TDMA-TTP, pielāgotas CSMA/CD vai pozitīvas apstiprināšanas vai atkārtotas pārraides (PAR) shēmas, kas samazina pārraides laiku un sniedz garantijas par datu piegādes laiku.

Līdztekus tam visam ir pilnveidota patentēta reāllaika programmatūras inženierijas metodoloģija, izmantojot metodoloģijas, kas iegūtas no datu plūsma, datu struktūras un objektu orientācija pielāgots pārtraukumu, konteksta pārslēgšanas, asinhronas komunikācijas un kļūdu atgūšanas attēlošanai ar stingrām laika noteikšanas prasībām.

Ņemot vērā visu iepriekš minēto, kļūst skaidrāks, kāpēc reāllaika sistēmas tagad ir būtiska mūsdienu tehnoloģiskās infrastruktūras sastāvdaļa: tās ir atbildīgas par tūkstošiem kritiskie un ikdienas procesi darboties droši, uzticami un bez nepieciešamības lietotājam domāt par visu, kas notiek "aizkulisēs" sekundes daļās.