Realaus laiko elektroninės sistemos: pagrindai, planavimas ir taikymas

Informatec Digital » Ištekliai » Realaus laiko elektroninės sistemos: pagrindai, planavimas ir taikymas

Realaus laiko elektroninės sistemos yra giliai įsišaknijusios mūsų kasdieniame gyvenime, nors dažnai lieka nepastebėtos. Nuo automobilių oro pagalvių iki oro eismo kontrolės ir net paprastos mikrobangų krosnelės – viskas priklauso nuo kompiuterinės sistemos ne tik nuo teisingo veikimo, bet ir nuo to, ar ji atlieka veiksmus tiksliu momentu . Jei laikas viršijamas, net ir šiek tiek, tai laikoma gedimu, net jei skaičiavimas yra tikslus.

Šių sistemų grožis (ir iššūkis) slypi tame, kad jos turi sąveikauti su fiziniu pasauliu labai konkrečiu laiku . Vien „greitumo“ nepakanka: jos turi būti nuspėjamos, stabilios ir sinchronizuotos su tuo, kas vyksta už kompiuterio ribų. Štai kodėl realaus laiko sistemos projektavimas, analizė ir testavimas yra gerokai sudėtingesni nei įprastos, bendrosios paskirties sistemos.

Kas yra realaus laiko sistema ir kuo ji skiriasi nuo greitos sistemos?

Realaus laiko sistema (RTS) iš esmės yra skaitmeninė sistema, kuri valdo arba stebi fizinį procesą su aiškiais laiko apribojimais. Ji turi ne tik pateikti logiškai teisingus rezultatus, bet ir garantuoti, kad atsakymas bus gautas per nustatytą laiką; šio termino nesilaikymas laikomas sistemos gedimu.

Aiškūs tokio elgesio pavyzdžiai: automobilio oro pagalvės ar ABS suveikimas , roboto bandymas pagauti kamuolį ore arba šiuolaikinės transporto priemonės variklio valdymo sistema. Visais šiais atvejais uždelsta reakcija, net ir keliomis milisekundėmis, gali būti nenaudinga ar net pavojinga.

Žodis „laikas“ šiame kontekste reiškia, kad teisingas veikimas priklauso nuo to, kada įvyksta reakcija , o ne tik nuo to, kokia ji yra. O „tikras“ reiškia, kad sistema turi reaguoti į išorinius įvykius jų realios evoliucijos metu, naudodama laiko skalę, atitinkančią jos kontroliuojamos fizinės aplinkos laiko skalę.

Tai skiriasi nuo tiesiog „greitos“ sistemos, kur svarbu tik tai, kad išvestis būtų rodoma kuo greičiau, nereikia jos sinchronizuoti su išoriniu pasauliu. Labai galingas žiniatinklio serveris gali būti greitas, tačiau jis nebūtinai yra realaus laiko sistema, jei neturi griežtų terminų, susietų su fiziniais įvykiais.

Taip pat svarbu jas atskirti nuo internetinių sistemų : jos visada gali būti prijungtos ir atsakyti į užklausas (pavyzdžiui, naršyklė ar rezervavimo sistema), tačiau joms nereikia laikytis griežtų terminų, suderintų su fiziniais procesais, todėl jos nėra automatiškai realaus laiko sistemos; tačiau šiuolaikinėse žiniatinklio programose realaus laiko paieškai gali reikėti panašių vėlavimų ir garantijų.

Praktinis pavyzdys: šviesoforo valdymas sankryžoje

Labai iliustruojantis realaus laiko elektroninių sistemų pavyzdys yra šviesoforų valdymo sistema judrioje sankryžoje . Vien tik laiku keisti šviesoforus „daugiau ar mažiau“ nepakanka; sprendimai turi būti priimami nuolat, atsižvelgiant į tai, kas vyksta gatvėje.

Pirmiausia stebimas eismas . Eismo juostose ir pėsčiųjų perėjose įrengiami jutikliai (indukcinės kilpos, kameros, infraraudonųjų spindulių jutikliai ir kt.), skirti aptikti transporto priemones ir žmones. Šie įrenginiai nuolat siunčia duomenis centriniam valdikliui, kuris taip gauna naujausią informaciją apie aplinką.

Valdymo centre integruotas kompiuteris realiuoju laiku apdoroja duomenis, taikydamas algoritmus , kurie apskaičiuoja eilėje esančių transporto priemonių skaičių, kiekvienos eismo juostos užimtumą ir laukiančių pėsčiųjų skaičių. Turėdamas šią informaciją, jis nustato, kiek laiko kiekviena šviesoforo fazė turėtų veikti kiekviena kryptimi.

Toliau seka sprendimų priėmimas . Pavyzdžiui, sistema nusprendžia pratęsti žalią šviesoforo signalą labiausiai apkrauta kryptimi, kad sumažintų eismo spūstis, arba suteikti pirmenybę pėsčiųjų perėjai, jei ji per ilgai laukė. Šie sprendimai priimami remiantis iš anksto nustatytomis optimizavimo politikomis ir saugos bei eismo srauto reikalavimais.

Priėmus sprendimą, valdiklis veikia šviesoforų valdymo pavaras . Jis keičia šviesoforų būseną milisekundės tikslumu, atsižvelgdamas į geltoną, raudoną šviesą, blokavimo įtaisus ir kitus saugos reikalavimus, užtikrindamas sklandų perėjimą tarp fazių.

Visa tai pasiekiama nuolat optimizuojant : sistema stebi eismą be pertraukų ir realiuoju laiku koreguoja žalio, geltono ir raudono šviesoforo signalų laiką, kad prisitaikytų prie staigių pokyčių (spūsties, pravažiuojančios greitosios pagalbos mašinos, eismo srauto pokyčių tam tikru paros metu ir pan.). Tai aiškiai parodo, kodėl kalbame apie realųjį laiką: valdymo logika prasminga tik tuo atveju, jei sprendimai įgyvendinami per tam tikrą laiką.

Realaus laiko sistemų istorija ir evoliucija

Realaus laiko skaičiavimo ištakos yra glaudžiai susijusios su pramonės ir aviacijos bei kosmoso procesų valdymu XX a. antroje pusėje. Šių sistemų pamatai buvo paskelbti jau 1965 m., o netrukus po to, 1973 m., Liu ir Layland formalizavo matematinį planavimo apibrėžimą griežtose ir lanksčiose realaus laiko sistemose.

Kompiuteriniame modeliavime terminas „realaus laiko modeliavimas“ pradėtas vartoti, kai kompiuterinis modelis veikė taip greitai, kaip ir fizinis procesas, kurį jis reprezentavo. Tai iškėlė klasikinę dilemą: arba padidinti modelio tikslumą greičio sąskaita, arba sumažinti tikslumą, kad būtų pasiektas arba pranoktas realaus laiko našumas.

Tas pats nutiko ir su grafinėmis sąsajomis bei žaidimų varikliais : kad patirtis būtų sklandi, jie turi pakankamai greitai reaguoti į vartotojo įvestį ir scenos pokyčius, išlaikydami didelį ir pastovų kadrų skaičių per sekundę.

Nuo septintojo ir aštuntojo dešimtmečių realaus laiko sistemos subrendo dėka pamokų, išmoktų iš didelio atgarsio sulaukusių realaus pasaulio atvejų, kai kurie iš jų buvo beveik katastrofiški, kurie padėjo patobulinti laiko analizės ir planavimo metodus.

Svarbūs atvejai: „Apollo 11“ ir „Mars Pathfinder“

Vienas garsiausių incidentų ankstyvojoje realaus laiko skaičiavimo istorijoje buvo „Apollo 11“ mėnulio modulio kompiuterio perkrova . Nusileidimo metu valdymo sistema pradėjo skleisti pavojaus signalus (pvz., garsųjį 1202), rodančius, kad procesorius atsilieka nuo savo darbo krūvio.

Misijos ataskaitose teigiama, kad jei šie pavojaus signalai būtų išlikę, įgulos navigacijos duomenų patikimumas būtų buvęs pažeistas, o misija galėjo būti nutraukta. Galiausiai, remiantis ankstesnėmis simuliacijomis ir patirtimi, buvo priimtas sprendimas tęsti skrydį, ir „Eagle“ modulis sėkmingai nusileido Mėnulyje.

Iš esmės tai buvo procesoriaus perkrovos atvejis : buvo atlikta daugiau skaičiavimų, nei centrinis procesorius galėjo apdoroti per skirtą laiką, ypač kai su aliarmu susijęs apdorojimas buvo pridėtas prie įprasto darbo krūvio. Šis incidentas pabrėžė, kaip svarbu išlaikyti pakankamas išteklių atsargas sistemose, kuriose gedimo kaina yra nepriimtina.

Kitas gerai ištirtas atvejis yra „ Mars Pathfinder“ erdvėlaivis . Čia problema buvo ne tiek neapdorotų duomenų perkrova, kiek reiškinys, žinomas kaip prioritetų inversija, dėl kurio buvo praleisti terminai, nors procesoriaus pajėgumų atsarga, regis, buvo pakankama.

Išankstinio planavimo sistemoje prioritetų inversija įvyksta, kai aukšto prioriteto užduotį blokuoja žemo prioriteto užduotis, kuriai priklauso bendras išteklius (pvz., „mutex“), o tuo tarpu vidutinio prioriteto užduotis pertraukia žemo prioriteto užduotį. Dėl to kritinę užduotį netiesiogiai blokuoja mažiau svarbi užduotis, pažeidžiant realaus laiko garantijas.

Siekiant sumažinti šią riziką, naudojamas prioritetų paveldėjimo protokolas . Kai aukšto prioriteto užduotį blokuoja žemo prioriteto užduotis, planuoklė laikinai padidina žemo prioriteto užduoties prioritetą iki aukšto prioriteto užduoties lygio. Tai neleidžia vidutinio prioriteto užduotims jos pertraukti, leidžia jai kuo greičiau atlaisvinti išteklius ir grįžti prie pradinio prioriteto.

Šie atvejai aiškiai parodė, kad STR projektavimas reiškia ne tik „pakankamą procesoriaus pajėgumų rezervą“, bet ir planavimo bei laiko teorijos supratimą bei laikiną visos sistemos (aparatinės, programinės ir aparatinės įrangos) testavimą kartu.

Pagrindiniai realaus laiko sistemos komponentai

Tipinį STR sudaro specializuotos aparatinės ir programinės įrangos bei sąsajos su fiziniu procesu elementų derinys . Tai ne šiaip programa; tai integruota sistema, kuri turi reaguoti į išorinius dirgiklius per žinomą laiką.

Fizinėje pusėje sistema yra valdoma : tai gali būti bet koks reguliuojamas procesas, pavyzdžiui, pramonės įmonė, variklis, gamybos linija, šviesoforas, robotas ar medicinos įranga. STR matuoja jos būseną ir taiko valdymo veiksmus, kad ji išliktų norimuose parametruose.

Tarp fizinio pasaulio ir kompiuterio yra signalo sąsaja , sudaryta iš analoginių-skaitmeninių keitiklių (ADC) ir skaitmeninių-analoginių keitiklių (DAC), taip pat iš kondicionavimo grandinės. Šis sluoksnis pritaiko įtampas, sroves ir signalo formatus, kad juos galėtų nuskaityti ir generuoti skaitmeninė sistema.

Svarbus elementas yra realaus laiko laikrodis , kuris periodiškai generuoja pertraukimus kiekviename atrankos periode. Jis sinchronizuoja duomenų rinkimo, valdymo ir vykdymo užduotis, užtikrindamas, kad matavimai ir komandos būtų atliekamos tiksliai tada, kada turėtų būti atliekamos.

Sistemą paprastai sudaro žmogaus operatoriaus pultas su paleidimo ir stabdymo valdikliais, sąsajos parametrams reguliuoti ir mechanizmai rankiniam režimui įjungti. Be to, ekranuose rodomos būsenos, pavojaus signalai, tendencijos ir kita svarbi informacija, skirta procesui stebėti.

Svarbūs būsenos pakeitimai saugomi realiuoju laiku veikiančioje duomenų bazėje , leidžiančioje įrašyti, kas įvyko, tirti gedimus ir išgauti statistiką, siekiant pagerinti valdymą. Ši istorinė informacija laikui bėgant auga ir informuoja apie priežiūros, optimizavimo ir pertvarkymo sprendimus.

Daugelyje pramoninių aplinkų yra nuotolinio stebėjimo sistema , leidžianti prižiūrėti ir kai kuriais atvejais valdyti gamyklą iš paskirstytų valdymo centrų. Tai labai svarbu, kai vienas objektas priklauso nuo kito (pavyzdžiui, gamykla, tiekianti žaliavas kitai), o viename objekte priimti sprendimai turi įtakos visai grandinei.

STR centre yra įterptinis kompiuteris , kurio programinė įranga paprastai skirstoma į kelių tipų modulius: skaitmeninius valdymo algoritmus (reguliatorius, filtrus, grįžtamojo ryšio kilpas), duomenų registravimą, adresų ir valdymo sąsajas bei tiesioginę sąveiką su operatoriumi.

Pagrindinės savybės: laikas, lygiagretumas, saugumas ir efektyvumas

Realaus laiko sistemos paprastai sprendžia dideles ir sudėtingas problemas , susijusias su daugybe kintamųjų, išoriniais įrenginiais ir besikeičiančiomis sąlygomis. Todėl reikia atidžiai atkreipti dėmesį į architektūrą, planavimą ir komunikacijos mechanizmus tarp užduočių.

Kadangi duomenys gaunami iš fizinio pasaulio, sistema turi apdoroti realiuosius skaičius (slankiojo kablelio, fiksuoto mastelio ir kt.), kurie vaizduoja tokius dydžius kaip temperatūra, slėgis, greitis ar įtampa. Vaizdavimo ir skaičiavimo tikslumas gali būti labai svarbus valdymo kokybei.

Saugumas ir patikimumas paprastai yra labai svarbūs: gedimas gali sukelti didelių ekonominių nuostolių, žalos turtui, sužalojimų ar poveikio aplinkai. Štai kodėl integruojami gedimų toleravimo metodai, perteklinis aprūpinimas ir kontroliuojamo blogėjimo strategijos.

Lygiagretumas yra dar viena apibrėžianti savybė. STR paprastai logiškai lygiagrečiai vykdo kelias užduotis: jutiklių nuskaitymą, valdymą, ryšį, registravimą , vartotojo sąsają ir kt. Dėl to reikia valdyti bendrus išteklius, vengti lenktynių sąlygų ir užtikrinti, kad svarbiausios dalys neviršytų terminų.

Efektyvumas nėra prabanga, tai būtinybė. STR turi būti logiškai ir laikiškai teisingas , bet taip pat optimizuotas, kad būtų galima visapusiškai išnaudoti procesoriaus, atminties ir įvesties/išvesties įrenginių galimybes. Iššūkis yra rasti pusiausvyrą tarp laiko ribos, aparatinės įrangos kainos ir programinės įrangos sudėtingumo.

Įvesties / išvesties įrenginiai paprastai yra specializuoti ir glaudžiai susieti su fiziniu procesu . Kalbame ne tik apie bendrinius prievadus, bet ir apie lauko magistrales, išmaniuosius jutiklius ir ryšio protokolus, sukurtus siekiant sumažinti delsą ir užtikrinti trumpą pristatymo laiką.

Realaus laiko sistemų tipai: kietosios, minkštosios ir fiksuotosios

Priklausomai nuo laiko klaidų apdorojimo sunkumo, STR skirstomi į kelias kategorijas. Griežtoje realaus laiko sistemoje visi terminai turi būti įvykdyti be išimties. Net vienas gedimas gali sukelti rimtų pasekmių arba bent jau panaikinti rezultatą.

Tipiniai kietojo realaus laiko sistemų pavyzdžiai yra skrydžių valdymas, tam tikros kritinės medicinos sistemos ir elektros infrastruktūros apsauga. Tokiais atvejais teisingas, bet uždelstas rezultatas yra nenaudingas; sistema turi būti suprojektuota taip, kad jokiu numatomu scenarijumi ji neįvykdytų nustatyto laiko limito.

Minkštos realaus laiko sistemos leidžia naudoti retkarčiais pasitaikančius vėlavimus. Rezultato naudingumas mažėja didėjant vėlavimui, tačiau jis vis tiek gali būti naudojamas. Taip yra multimedijos ar duomenų rinkimo programose, kur keli prarasti kadrai ar uždelsti pavyzdžiai pablogina kokybę, tačiau sistema toliau veikia.

Tarp šių dviejų kraštutinumų yra tvirtos realaus laiko sistemos . Jose retkarčiais pasitaikantys vėlavimai yra toleruojami, tačiau kai atsakymas gaunamas pavėluotai, jis tampa bevertis ir atmetamas. Klasikiniai pavyzdžiai yra realaus laiko vaizdo arba telekomunikacijų sistemos: pavėluotas kadras yra atmetamas, kad būtų išlaikyta sinchronizacija.

Architektūros: atvira/uždara ir centralizuota/paskirstyta

Realaus laiko sistemas taip pat galima klasifikuoti pagal jų technologinio atvirumo laipsnį . Nuosavybės teise saugomos sistemos naudoja uždaras technologijas ir protokolus, kuriuos kontroliuoja vienas tiekėjas, o tai gali užtikrinti gerą našumą, tačiau riboja sąveikumą ir evoliuciją.

Priešingai, atviros sistemos naudoja viešuosius standartus ir protokolus , kurie palengvina skirtingų gamintojų komponentų integravimą, programinės įrangos pakartotinį naudojimą ir laipsnišką perkėlimą į naujas platformas.

Kitas svarbus skirtumas yra tarp centralizuotų ir paskirstytų sistemų . Centralizuotame metode pagrindinis mazgas yra atsakingas už komunikacijos ir kritinio apdorojimo koordinavimą, o kiti mazgai veikia kaip gana paprasti terminalai arba periferiniai įrenginiai.

Paskirstytoje architektūroje apdorojimas ir komunikacija yra paskirstyti tarp kelių išmaniųjų mazgų, kurie bendradarbiauja daugiau ar mažiau autonomiškai. Tai leidžia užtikrinti mastelio keitimą, perteklių ir artumą prie fizinio proceso, tačiau apsunkina laiko sinchronizavimą ir bendrą koordinavimą.

Determinizmas, pertraukimų delsa ir reagavimas

Determinizmas yra pagrindinis SRT atributas: tai gebėjimas su didele tikimybe numatyti, kiek laiko užtruks užduoties pradžia ir pabaiga . Svarbu ne kuo greičiau atlikti užduotį, o turėti žinomą ir ribotą reakcijos laiką.

Pertraukimo delsa matuoja laiką nuo išorinio pertraukimo sugeneravimo (pavyzdžiui, jutiklio pranešimo apie įvykį) iki to laiko, kai sistema pradeda jį apdoroti. Ši vertė yra labai svarbi, nes daugelis paslaugų užklausų kyla iš fizinės aplinkos ir negali toleruoti savavališkų vėlavimų.

Reagavimo geba apima laiką, per kurį užduotis įvykdoma, kai pertraukimas priimamas . Tai apima tokius veiksnius kaip aptarnavimo rutinos pradžios laikas, susijusio apdorojimo trukmė ir įterptųjų pertraukimų ar išankstinių nuostatų poveikis.

Paprastai atliekama kiekybinė determinizmo ir reagavimo analizė, siekiant apibūdinti sistemą: pavyzdžiui, gali būti reikalaujama, kad 95 % užduočių būtų atliktos per tam tikrą laiką . Todėl RTOS veikiančios programos turi būti suprojektuotos taip, kad nepatektų į blogiausio atvejo numatomą našumo diapazoną.

Sistemos valdymas pagal procesus ir patikimumą

Daugelyje pažangių realaus laiko sistemų patys programų procesai labai tiksliai kontroliuoja sistemą . Jie gali aiškiai nurodyti savo prioritetą, atminties reikalavimus (kuri dalis turėtų būti kaupiama talpykloje, kokia keitimo politika leidžiama ir pan.) ir reikalingas teises.

Nors iš pirmo žvilgsnio tai gali atrodyti kaip anarchinis modelis, iš tikrųjų jis pagrįstas aiškiai apibrėžtais procesų tipais ir aiškiais apribojimais . Įprasta nustatyti tokius reikalavimus kaip: „priežiūros procesai neturi viršyti 3 % procesoriaus apkrovos, išskyrus aiškiai apibrėžtus mažo apkrovimo laikotarpius“.

Patikimumas – tai daugiau nei vien tik atsitiktinių gedimų nebuvimas. Tinklo paslaugų teikėjas (NSP) privalo palaikyti paslaugų kokybę sutartose ribose ilgą laiką, užtikrindamas, kad reagavimo laikas atitiktų specifikacijas net ir esant pagrįstiems sutrikimams.

Be to, reikalingas atsparumas gedimams : jei iškyla rimta problema (aparatinės įrangos gedimas, žmogaus klaida, išorinis trikdis), sistema turi išsaugoti kuo daugiau duomenų ir funkcijų bei pabloginti savo veikimą, teikdama pirmenybę svarbiausioms užduotims.

Kalbos ir programavimas realiuoju laiku

Praktiškai daugelis realaus laiko sistemų (RTS) yra įterptosios ir turi sąveikauti su daugybe išorinių komponentų, todėl būtinas lygiagretus programavimas ir tiesioginis įrenginio valdymas . Šiuolaikinės kalbos siūlo primityvus elementus sriegimui, komunikacijai ir sinchronizavimui, tačiau realaus laiko programose, ypač žiniatinklio sistemose ir realaus laiko paslaugose, tokiose kaip „Laravel“, juos reikia naudoti labai atsargiai.

Svarbiausia yra įgyvendinimo efektyvumas: „gražios“ kalbos funkcijos gali brangiai kainuoti, kalbant apie atsako laiką, procesoriaus naudojimą ar atminties naudojimą . Štai kodėl įterptosiose sistemose kiekviena abstrakcija yra kruopščiai įvertinama prieš ją pritaikant.

Dvi kalbos, turinčios didelę įtaką realiojo laiko pasaulyje, yra „Ada“ ir „Java“ su realaus laiko plėtiniais . „Ada“ buvo specialiai sukurta kritinėms sistemoms palaikyti ir joje buvo įdiegti patobulinimai, siekiant sustiprinti jos galimybes šioje srityje.

„Java“ atveju realaus laiko funkcijos buvo pridėtos vėliau, pateikiant tokias specifikacijas kaip „Java“ realaus laiko specifikacija ir „Real-Time Core Extension“, kurios pristato atminties ir planavimo modelius, geriau tinkančius RTOS.

Realaus laiko operacinės sistemos (RTOS)

Realaus laiko operacinė sistema (RTOS) yra pagrindinė programinė įranga, suteikianti pagrindą, kuriuo remiantis kuriamos programos su griežtais terminais. Reikalaujama, kad jos paslaugos (planavimas, pertraukimai, sinchronizavimas, įvestis/išvestis ir kt.) veiktų nuspėjamai.

Skirtingai nuo bendrosios paskirties operacinės sistemos, RTOS yra optimizuota vykdyti pasikartojančias užduotis per labai trumpą laiką . Tikslas yra ne „atlikti daug dalykų“, o užtikrinti, kad svarbiausia užduotis būtų vykdoma tada, kada turėtų, be netikėtumų.

Todėl jos paprastai yra daug lengvesnės sistemos, be grafinių puošmenų ar nereikalingų paslaugų, vos kelių megabaitų dydžio ir minimalistinio dizaino filosofijos. Mažiau kodo reiškia mažesnį netikėtą delsą ir mažiau gedimų taškų , o tai atitinka realaus laiko reikalavimus.

Istoriškai RTOS pradėtos kurti septintajame ir aštuntajame dešimtmečiuose karinėms, aviacijos ir kosmoso bei pramonės reikmėms. Vėlesniais dešimtmečiais atsirado komercinių produktų, tokių kaip „VxWorks“, „QNX“ ir realaus laiko „Solaris“ variantai , plačiai naudojami telekomunikacijose, automobilių pramonėje ir įterptosiose sistemose.

2000-aisiais ir 2010-aisiais, išpopuliarėjus daiktų internetui (IoT), lengvos RTOS, tokios kaip „FreeRTOS“, tapo labai populiarios mažos galios prijungtuose įrenginiuose. Tuo pačiu metu buvo pasiūlyti realaus laiko POSIX plėtiniai, skirti suvienodinti sąsajas ir palengvinti programinės įrangos perkeliamumą.

Šiandien daugelis RTOS integruojasi su dirbtinio intelekto ir mašininio mokymosi metodais , kad optimizuotų planavimą, numatytų gedimus ir pritaikytų valdymo parametrus veikimo metu. Visa tai, žinoma, išlaikant dėmesį laiko garantijoms.

RTOS rinka yra verta kelių milijardų dolerių ir tikimasi, kad ateinančiais metais ji nuolat augs, o tai skatins medicinos prietaisai, pramoninė automatizacija, automobilių pramonė ir kritinės infrastruktūros sistemos.

Reikalavimai, kuriuos turi atitikti geras RTOS

Šiuolaikinė RTOS turi būti daugiaprogramė ir prevencinė , kad galėtų aplenkti žemesnio prioriteto užduotis, kad nedelsdama atliktų skubesnes. Vyraujanti paradigma yra prioritetais pagrįstas planavimas: jis visada vykdo svarbiausią užduotį, kuri yra paruošta vykdyti.

Be to, jis turi užtikrinti komunikacijos ir sinchronizavimo mechanizmus (eiles, semaforus, muteksus, įvykius), skirtus sumažinti nereikalingą blokavimą ir išvengti tokių reiškinių kaip prioritetų inversija, taikant paveldėjimo protokolus arba prioritetų ribojimą, kai tai tinkama.

Labai svarbu gerai suprasti RTOS laiko elgseną : maksimalų pertraukimų delsos laiką, konteksto perjungimo laiką, sinchronizavimo primityvų vykdymo laiką ir kt. Be šių duomenų neįmanoma įrodyti, kad programa laikosi savo terminų.

Planavimo algoritmai: EDF ir kiti modeliai

Užduočių planavimas yra vienas iš realaus laiko sistemų kertinių akmenų. Vienas iš labiausiai tyrinėjamų algoritmų yra „Earliest Deadline First“ (EDF) – dinamiškai prioritetizuotas planuoklis, optimalus daugelyje realaus laiko kontekstų.

EDF prioritetizuoja užduotis pagal jų absoliutų įvykdymo terminą : užduotis su artimiausiu terminu bet kuriuo metu turi aukščiausią prioritetą. Tai tam tikromis sąlygomis užtikrina, kad jei yra įgyvendinamas planas, atitinkantis visus terminus, EDF jį suras.

Šis algoritmas yra prevencinis: jei užduoties vykdymo metu atsiranda kita užduotis su sunkesniu terminu, sistema gali nutraukti dabartinę užduotį ir paskirti procesorių naujai. EDF paprastai įgyvendinamas naudojant prioritetų eilę, surūšiuotą pagal likusį laiką iki termino.

Vienas iš EDF privalumų yra tas, kad jis gali pasiekti beveik 100 % procesoriaus panaudojimą , laikantis terminų, jei užduočių rinkinį galima suplanuoti. Be to, jis gerai prisitaiko prie dinamiškos aplinkos, kurioje keičiasi terminai ar numatomas vykdymo laikas.

Pavyzdžiui, jei turime du procesus P1 ir P2 su skirtingais periodais ir skaičiavimo laikais, EDF visada teiks pirmenybę tam egzemplioriui, kurio absoliutus terminas yra arčiau, pakaitomis vykdydamas jį , kai gaunami nauji aktyvavimai ir perskaičiuojami terminai.

Vis dėlto EDF neturi ir trūkumų. Esant itin dideliam darbo krūviui ir dažniems keitimams, jį gali būti sudėtinga efektyviai įdiegti, o tam tikromis sąlygomis atliekant užduotis su gana ilgais terminais gali kilti badavimo problemų.

Kiti gerai žinomi realaus laiko algoritmai yra „Rate Monotonic“ (RM) ir „Deadline Monotonic“ (DM) , kurie naudoja fiksuotus prioritetus, pagrįstus užduočių laikotarpiu arba santykiniu laiko tarpu. Kiekvienas turi savo optimalumo sąlygas ir pageidaujamą taikymo sritį.

Tipiniai realaus laiko sistemų taikymai

STR yra visur. Apdorojimo pramonėje jie naudojami maisto, gėrimų, cheminių medžiagų, vaistų ir kt. gamybos linijoms valdyti ir stebėti, užtikrinant, kad pagrindiniai kintamieji neviršytų ribų ir kad galutinis produktas atitiktų laukiamą kokybę.

Transporto sektoriuje lėktuvai, traukiniai, automobiliai ir laivai naudoja realaus laiko navigacijos, valdymo ir saugos sistemas . Jos apima ABS stabdžių sistemas, traukos ir stabilumo kontrolės sistemas, taip pat geležinkelių ir jūrų eismo valdymo sistemas.

Šiuolaikinės telekomunikacijos remiasi informacijos srautų valdymu realiuoju laiku didelės spartos tinkluose: paketų komutavimas, tiesioginis balso ir vaizdo perdavimas, paslaugų kokybės užtikrinimas ir delsos mažinimas yra užduotys, kurioms atlikti būtina laikytis terminų.

Gynybos sektoriuje stebėjimo, radarų, elektroninės kovos ir kibernetinio saugumo sistemos naudoja realaus laiko platformas, kad aptiktų grėsmes ir reaguotų į jas per milisekundes ar greičiau, apsaugodamos ypatingos svarbos infrastruktūrą ir strateginius išteklius.

Medicinoje tokia įranga kaip gyvybinių požymių monitoriai, dirbtinės plaučių ventiliacijos aparatai, širdies stimuliatoriai ar infuziniai siurbliai veikia su realaus laiko programine įranga, kuri turi saugiai reaguoti į paciento būklės pokyčius, o praleidus terminus, dažnai kyla gyvybei ar mirčiai pavojingų pasekmių.

Be skaitmeninio pasaulio, realų laiką galima stebėti ir biologiniuose procesuose. Pavyzdžiui, sėkla sudygsta tik tada, kai aplinkos sąlygos patenka į tam tikrus diapazonus ir laiko intervalus (drėgmė, temperatūra, šviesa). Jei ji sudygtų vos palietusi žemę, nesilaikant šių laiko intervalų, greičiausiai neišgyventų. Tai naudinga metafora, parodanti, kaip gali žlugti sistema, kuri neprisitaiko prie savo laikinės aplinkos.

Žvelgiant į platesnį vaizdą, STR apima telekomunikacijas, multimediją, pramoninį valdymą, robotiką, avioniką, geležinkelius, automobilių pramonę, buitinius prietaisus, mokslinius eksperimentus ir medicinos sistemas . Ir šis sąrašas toliau pildomas, kuriant naujas technologijas.

Visose šiose aplinkose reikalingi specialūs realaus laiko ryšio protokolai , tokie kaip CAN, žetonų magistralė, TDMA-TTP, pritaikytos CSMA/CD arba teigiamo patvirtinimo arba pakartotinio perdavimo (PAR) schemos, kurios sutrumpina perdavimo laiką ir suteikia garantijas dėl duomenų atvykimo laiko.

Be viso to, buvo patobulinta patentuota realaus laiko programinės įrangos inžinerija, pritaikant duomenų srauto metodologijas, duomenų struktūras ir objektinę orientaciją, kad būtų galima atvaizduoti trikdžius, konteksto pokyčius, asinchroninį ryšį ir atkūrimą po klaidų, atsižvelgiant į sudėtingus laiko reikalavimus.

Atsižvelgiant į visa tai, kas išdėstyta pirmiau, tampa aiškiau, kodėl realaus laiko sistemos dabar yra esminė šiuolaikinės technologinės infrastruktūros dalis: jos yra atsakingos už tūkstančius svarbių ir kasdienių procesų, kurie veikia saugiai, patikimai ir be to, kad vartotojui nereikėtų galvoti apie viską, kas vyksta „užkulisiuose“ per sekundės dalis.