Електронски системи у реалном времену: основе, планирање и примене

Информатек Дигитал » Средства » Електронски системи у реалном времену: основе, планирање и примене

Електронски системи у реалном времену су дубоко укорењени у нашем свакодневном животу, иако често остају непримећени. Од ваздушних јастука у аутомобилима до контроле ваздушног саобраћаја, па чак и једноставне микроталасне пећнице, све зависи од тога да рачунарски систем не само да ради ствари исправно, већ да их ради у тачном тренутку . Ако се прекорачи временско ограничење, чак и мало, то се сматра кваром, чак и ако је прорачун савршен.

Лепота (и изазов) ових система лежи у њиховој потреби да интерагују са физичким светом у веома специфичним временским оквирима . Само бити „брз“ није довољно: морају бити предвидљиви, стабилни и синхронизовани са оним што се дешава изван рачунара. Због тога су дизајн, анализа и тестирање система у реалном времену знатно сложенији од оних код конвенционалног система опште намене.

Шта је систем у реалном времену и како се разликује од брзог система?

Систем у реалном времену (RTS) је у суштини дигитални систем који контролише или прати физички процес са јасним временским ограничењима. Он не само да мора да производи логички исправне резултате, већ и да гарантује да одговор стигне у дефинисаном временском оквиру; непоштовање овог рока представља квар система.

Јасни примери овог понашања укључују активирање ваздушног јастука или ABS-а у аутомобилу , робота који покушава да ухвати лопту у ваздуху или систем управљања мотором модерног возила. У свим овим случајевима, одложена реакција, чак и од неколико милисекунди, може бити бескорисна или чак опасна.

Реч „време“ у овом контексту значи да исправно функционисање зависи од тога када се одговор јавља , а не само од тога какав је. А „стварно“ имплицира да систем мора да реагује на спољашње догађаје током њихове стварне еволуције, користећи временску скалу која је у складу са временском скалом физичког окружења које контролише.

Ово је у супротности са једноставно „брзим“ системом, где је једино важно да се излаз појави што је брже могуће, без потребе за синхронизацијом са спољним светом. Веома моћан веб сервер може бити брз, али није нужно систем у реалном времену ако нема строге рокове везане за физичке догађаје.

Такође је важно разликовати их од онлајн система : они могу увек бити повезани и одговарати на захтеве (на пример, прегледач или систем за резервације), али не морају да поштују круте рокове координисане са физичким процесима, тако да нису аутоматски системи у реалном времену; међутим, у модерним веб апликацијама, претрага у реалном времену може захтевати сличне латенције и гаранције.

Практичан пример: контрола семафора на раскрсници

Веома илустративан пример електронских система у реалном времену је систем за управљање семафорима на прометној раскрсници . Само мењање светла „мање-више“ на време није довољно; одлуке се морају доносити континуирано на основу онога што се дешава на улици.

Прво, саобраћај се прати . Сензори (индуктивне петље, камере, инфрацрвени сензори итд.) постављају се у тракама и пешачким прелазима како би детектовали возила и људе. Ови уређаји стално шаљу податке централном контролеру, који тако добија ажуриране информације о окружењу.

У контролном центру, уграђени рачунар обрађује податке у реалном времену, примењујући алгоритме који израчунавају број возила у реду, попуњеност сваке траке и број пешака који чекају. Са овим информацијама, одређује колико дуго свака фаза семафора треба да траје у сваком смеру.

Следи доношење одлука . Систем одлучује, на пример, да продужи зелено светло у најзагушенијем правцу како би смањио гужве у саобраћају или да да приоритет пешачком прелазу ако се предуго чека. Ове одлуке се заснивају на унапред дефинисаним политикама оптимизације и на захтевима безбедности и протока саобраћаја.

Када се одлука донесе, контролер делује на актуаторе који управљају светлима . Мења стање семафора са прецизношћу од милисекунди, поштујући жуто, црвено светло, блокаде и друге безбедносне захтеве, обезбеђујући гладак прелаз између фаза.

Све се ово постиже континуираном оптимизацијом : систем прати саобраћај без прекида и подешава време паљења зеленог, жутог и црвеног светла у реалном времену како би се прилагодио изненадним променама (саобраћајна гужва, пролазак кола хитне помоћи, варијације у протоку саобраћаја током одређеног доба дана итд.). Ово јасно показује зашто говоримо о реалном времену: логика контроле има смисла само ако се одлуке извршавају у одређеним временским оквирима.

Историја и еволуција система реалног времена

Порекло рачунарства у реалном времену уско је повезано са контролом индустријских и ваздухопловних процеса у другој половини 20. века. Референтни текстови који постављају темеље ових система објављени су већ 1965. године, а убрзо након тога, 1973. године, Лиу и Лејланд су формализовали математичку дефиницију распоређивања у строгим и флексибилним системима у реалном времену.

У рачунарској симулацији, термин „симулација у реалном времену“ почео је да се користи када се рачунарски модел извршавао брзо као и физички процес који је представљао. Ово је представљало класичну дилему: или повећати верност модела на рачун брзине, или смањити тачност да би се постигле или надмашиле перформансе у реалном времену.

Исто се догодило и са графичким интерфејсима и гејм енџинима : да би искуство било глатко, морају довољно брзо да реагују на корисничке уносе и промене сцене, одржавајући висок и константан број фрејмова у секунди.

Од 60-их и 70-их, системи у реалном времену су сазрели захваљујући лекцијама наученим из познатих случајева из стварног света, неких готово катастрофалних, што је помогло у усавршавању техника анализе времена и планирања.

Значајни случајеви: Аполо 11 и Марс Патфајндер

Један од најпознатијих инцидената у раној историји рачунарства у реалном времену био је преоптерећење рачунара лунарног модула Аполо 11. Током спуштања, систем за навођење је почео да издаје аларме (као што је чувени 1202) који указују да процесор заостаје за својим оптерећењем.

Према извештајима мисије, да су ти аларми наставили да раде, поузданост навигационих података за посаду би била угрожена и мисија би могла бити прекинута. На крају, на основу претходних симулација и искуства, донета је одлука да се настави, и модул Игл је успешно слетео на Месец.

У суштини, радило се о преоптерећењу процесора : било је више обрачуна него што је процесор могао да обради у предвиђеном времену, посебно када је обрада повезана са алармом додата нормалном оптерећењу. Овај инцидент је истакао важност одржавања довољних маргина ресурса у системима где је цена квара неприхватљива.

Још један добро проучен случај је случај са свемирском летелицом Марс Патфајндер . Овде проблем није био толико ствар преоптерећења, већ феномен познат као инверзија приоритета, који је узроковао пропуштене рокове иако је процесор имао наизглед разумну маргину капацитета.

У систему превентивног заказивања, инверзија приоритета се дешава када задатак високог приоритета блокира задатак ниског приоритета који поседује дељени ресурс (као што је mutex), а у међувремену задатак средњег приоритета прекида задатак ниског приоритета. Резултат је да је критични задатак индиректно блокиран мање важним задатком, кршећи гаранције реалног времена.

Да би се ублажио овај ризик, користи се протокол наслеђивања приоритета . Када задатак високог приоритета блокира задатак нижег приоритета, распоред привремено подиже приоритет задатка ниског приоритета на ниво задатка високог приоритета. Ово спречава да га задаци средњег приоритета прекину, омогућавајући му да што брже ослободи ресурс, а затим се врати на свој првобитни приоритет.

Ови случајеви су јасно показали да дизајнирање STR-а није само питање „имања довољно простора за процесор“, већ и разумевања теорије заказивања и времена , као и привременог тестирања целог система (хардвера, фирмвера и софтвера) заједно.

Основне компоненте система реалног времена

Типична STR се састоји од комбинације специјализованог хардвера, софтвера и елемената интерфејса са физичким процесом. То није само програм; то је интегрисани систем који мора да реагује на спољне стимулусе у познатим временским оквирима.

Са физичке стране, сматрамо да је систем контролисан : то може бити било који процес подложан регулацији, као што је индустријски погон, мотор, производна линија, семафор, робот или медицинска опрема. STR мери своје стање и примењује контролне акције како би га одржао у оквиру жељених параметара.

Између физичког света и рачунара налази се сигнални интерфејс , који се састоји од аналогно-дигиталних претварача (ADC) и дигитално-аналогних претварача (DAC), као и кола за кондиционирање. Овај слој прилагођава напоне, струје и формате сигнала како би их дигитални систем могао да очита и генерише.

Кључни елемент је сат реалног времена , који генерише периодичне прекиде у сваком периоду узорковања. Ово синхронизује задатке аквизиције података, управљања и актуације, осигуравајући да се мерења и команде издају тачно када треба.

Систем обично укључује конзолу људског оператера са контролама за покретање и заустављање, интерфејсе за подешавање параметара и механизме за принудно ручно активирање режима. Поред тога, екрани се користе за приказивање статуса, аларма, трендова и свих других релевантних информација за праћење процеса.

Значајне промене статуса се чувају у бази података у реалном времену , што омогућава евиденцију о томе шта се догодило, истрагу кварова и издвајање статистике ради побољшања управљања. Ове историјске информације се временом повећавају и утичу на одлуке о одржавању, оптимизацији и редизајну.

Многа индустријска окружења имају систем даљинског праћења који омогућава надзор, а у неким случајевима и контролу постројења из дистрибуираних контролних центара. Ово је неопходно када једно постројење зависи од другог (на пример, постројење које снабдева сировинама друго), а одлуке донете у једном утичу на цео ланац.

У срцу STR-а је уграђени рачунар , чији је софтвер обично подељен на неколико врста модула: дигитални алгоритми управљања (регулатори, филтери, повратне петље), евидентирање података, интерфејси за адресирање и управљање и директна интеракција са оператером.

Кључне карактеристике: време, конкурентност, безбедност и ефикасност

Системи у реалном времену се обично баве великим и сложеним проблемима , који укључују више променљивих, спољних уређаја и променљивих услова. То захтева пажљиву пажњу посвећену архитектури, планирању и механизмима комуникације између задатака.

Пошто подаци долазе из физичког света, систем мора да обрађује реалне бројеве (бројеве са покретним зарезом, фиксне скале итд.) који представљају величине као што су температура, притисак, брзина или напон. Тачност представљања и прорачуна може бити кључна за квалитет управљања.

Безбедност и поузданост су обично критичне: квар може проузроковати озбиљне економске губитке, материјалну штету, повреде људи или утицај на животну средину. Зато се интегришу технике толеранције на грешке, редундантност и стратегије контролисане деградације.

Конкурентност је још једна карактеристична одлика. STR обично извршава неколико задатака логички паралелно: очитавање сензора, контролу, комуникацију, евидентирање , кориснички интерфејс итд. То захтева управљање дељеним ресурсима, избегавање услова трке и осигуравање да критични делови не прекораче рокове.

Ефикасност није луксуз, већ нужност. STR мора бити логички и временски исправан , али и оптимизован да би у потпуности искористио CPU, меморију и I/O уређаје. Изазов лежи у проналажењу равнотеже између временске маргине, трошкова хардвера и сложености софтвера.

Улазно/излазни уређаји су обично специјализовани и чврсто повезани са физичким процесом . Не говоримо само о генеричким портовима, већ о магистралама, паметним сензорима и комуникационим протоколима дизајнираним да минимизирају латенцију и обезбеде кратке рокове испоруке.

Врсте система у реалном времену: тврди, меки и чврсти

У зависности од озбиљности којом обрађују грешке у времену, STR-ови се класификују у неколико категорија. У систему чврстог реалног времена , сви рокови морају бити испуњени без изузетка. Један квар може довести до озбиљних последица или, у најмању руку, поништити исход.

Типични примери система у реалном времену укључују контролу лета, одређене критичне медицинске системе и заштиту електричне инфраструктуре. У овим случајевима, тачан, али одложени резултат је бескористан; систем мора бити пројектован тако да, ни у једном предвидљивом сценарију, неће испунити своје временско ограничење.

Системи у реалном времену (soft real-time) дозвољавају повремена кашњења. Корисност резултата се смањује са кашњењем, али он и даље може бити употребљив. То је случај у мултимедијалним или апликацијама за аквизицију података, где неколико изгубљених фрејмова или одложених узорака деградирају квалитет, али систем наставља да функционише.

Између ове две крајности налазе се чврсти системи у реалном времену . Овде се повремена кашњења толеришу, али када одговор стигне касно, постаје безвредан и одбацује се. Класични примери укључују системе за видео у реалном времену или телекомуникационе системе: оквир који стигне касно се одбацује да би се одржала синхронизација.

Архитектуре: отворене/затворене и централизоване/дистрибуиране

Системи у реалном времену могу се класификовати и по степену технолошке отворености . Власнички системи користе затворене технологије и протоколе, којима управља један добављач, што може да обезбеди добре перформансе, али ограничава интероперабилност и еволуцију.

Насупрот томе, отворени системи користе јавне стандарде и протоколе који олакшавају интеграцију компоненти различитих произвођача, поновну употребу софтвера и прогресивну миграцију на нове платформе.

Још једна важна разлика је између централизованих и дистрибуираних система . У централизованом приступу, главни чвор је одговоран за координацију комуникације и критичне обраде, док остали чворови делују као релативно једноставни терминали или периферни уређаји.

У дистрибуираној архитектури, обрада и комуникација су подељени између неколико интелигентних чворова који сарађују мање-више аутономно. Ово омогућава скалабилност, редундантност и близину физичком процесу, али компликује синхронизацију времена и укупну координацију.

Детерминизам, латенција прекида и одзив

Детерминизам је основни атрибут SRT-ова: то је способност да се са високим степеном вероватноће предвиди колико ће времена бити потребно да се задатак почне и заврши . Не ради се о томе да се буде што бржи, већ о томе да се има познато и ограничено време одзива.

Латенција прекида мери време од тренутка када се генерише спољашњи прекид (на пример, сензор пријављује догађај) до тренутка када систем почне да га обрађује. Ова вредност је критична јер многи захтеви за услугом потичу из физичког окружења и не могу толерисати произвољна кашњења.

Брзина одзива се фокусира на време потребно да се задатак изврши након што је прекид прихваћен . Укључује факторе као што су време покретања сервисне рутине, трајање повезане обраде и утицај угнежђених прекида или превенција.

Квантитативна анализа детерминизма и одзива се обично врши да би се окарактерисао систем: на пример, може бити потребно да се 95% задатака заврши у одређеном временском оквиру . Одатле, апликације које раде на RTOS-у морају бити дизајниране тако да избегну пад у најгори могући очекивани опсег перформанси.

Контрола система процесима и поузданост

У многим напредним системима реалног времена, сами апликативни процеси имају веома фину контролу над системом . Они могу експлицитно да декларишу свој приоритет, своје меморијске захтеве (који део треба кеширати, која политика замене је дозвољена итд.) и привилегије које су им потребне.

Иако на први поглед може деловати као анархични модел, он је заправо заснован на добро дефинисаним типовима процеса и јасним ограничењима . Уобичајено је да се успоставе захтеви као што су: „процеси одржавања не смеју прећи 3% коришћења процесора, осим током јасно дефинисаних прозора са малим оптерећењем“.

Поузданост иде даље од пуког одсуства повремених кварова. Пружалац мрежних услуга (NSP) мора одржавати квалитет услуге у оквиру договорених ограничења током дужих периода, гарантујући време одзива које испуњава спецификације чак и у случају разумних прекида.

Поред тога, потребна је толеранција на грешке : ако дође до озбиљног проблема (квар хардвера, људска грешка, спољашњи поремећај), систем мора сачувати што је више могуће података и функционалности и смањити своје понашање дајући приоритет критичним задацима највишег приоритета.

Језици и програмирање у реалном времену

У пракси, многи системи реалног времена (RTS) су уграђени и морају да комуницирају са бројним спољним компонентама, што чини истовремено програмирање и директну контролу уређаја неопходним. Модерни језици нуде примитиве за нити, комуникацију и синхронизацију, али се они морају користити са великим опрезом у апликацијама реалног времена, посебно у веб оквирима и сервисима реалног времена попут Laravel-а.

Ефикасност имплементације је кључна: „лепе“ језичке карактеристике могу имати високу цену у смислу времена одзива, коришћења процесора или потрошње меморије . Зато се у уграђеним системима свака апстракција пажљиво процењује пре него што се усвоји.

Два језика са истакнутим присуством у свету реалног времена су Ада и Јава са екстензијама за реално време . Ада је посебно дизајнирана да подржи критичне системе и укључила је побољшања како би ојачала своје могућности у овој области.

У случају Јаве, функционалности реалног времена су додате касније, са спецификацијама као што су Real-Time Specification for Java и Real-Time Core Extension, које уводе моделе меморије и распоређивања који су боље прилагођени RTOS-у.

Оперативни системи у реалном времену (RTOS)

Оперативни систем у реалном времену (RTOS) је основни софтвер који пружа оквир на којем се граде апликације са строгим роковима. Потребно је да се његове услуге (заказивање, прекиди, синхронизација, улазно/излазни операције итд.) понашају предвидљиво.

За разлику од оперативног система опште намене, RTOS је оптимизован за извршавање понављајућих задатака у веома кратким временским оквирима . Циљ није да се „ради много ствари“, већ да се осигура да се најважнији задатак извршава када треба, без изненађења.

Зато су они обично много лакши системи, без графичких украса или непотребних сервиса, са величином од само неколико мегабајта и минималистичком филозофијом дизајна. Мање кода значи мање неочекиваног кашњења и мање тачака отказа , што се уклапа у захтеве реалног времена.

Историјски гледано, развој RTOS-ова је почео 60-их и 70-их година за војне, ваздухопловне и индустријске примене. У наредним деценијама појавили су се комерцијални производи, као што су VxWorks, QNX и варијанте Солариса за рад у реалном времену , које се широко користе у телекомуникацијама, аутомобилској индустрији и уграђеним системима.

Са порастом Интернета ствари (IoT) током 2000-их и 2010-их, лагани RTOS-ови попут FreeRTOS-а постали су веома популарни код повезаних уређаја мале потрошње енергије. Истовремено, предложена су POSIX проширења за рад у реалном времену како би се унификовали интерфејси и олакшала преносивост софтвера.

Данас се многи RTOS-ови интегришу са вештачком интелигенцијом и техникама машинског учења како би оптимизовали заказивање, предвидели кварове и прилагодили параметре управљања током извршавања. Све ово, наравно, уз одржавање фокуса на временским гаранцијама.

Тржиште RTOS-а вреди неколико милијарди долара и очекује се да ће стално расти у наредним годинама, вођено медицинским уређајима, индустријском аутоматизацијом, аутомобилском индустријом и системима критичне инфраструктуре.

Захтеви које добар RTOS мора да испуни

Модерни RTOS мора бити мултитаскинг и преемптиван , тако да може да преузме задатке нижег приоритета како би одмах извршио хитнији. Заказивање засновано на приоритету је преовлађујућа парадигма: увек се покреће најважнији задатак који је спреман за извршење.

Штавише, мора да обезбеди механизме комуникације и синхронизације (редове чекања, семафоре, мутексе, догађаје) дизајниране да минимизирају непотребно блокирање и избегну феномене као што су инверзија приоритета, примена протокола наслеђивања или ограничавање приоритета где је то потребно.

Битно је да се понашање времена RTOS-а добро разуме : максималне латенције прекида, времена промене контекста, времена извршавања примитива синхронизације итд. Без ових података, немогуће је показати да апликација испуњава своје рокове.

Алгоритми заказивања: EDF и други модели

Заказивање задатака један је од темеља система реалног времена. Међу најпроучаванијим алгоритмима је EDF (Earliest Deadline First) , динамички приоритетизовани распоред који је оптималан у многим контекстима реалног времена.

EDF даје приоритет задацима на основу њиховог апсолутног рока завршетка : задатак са најближим роком има највећи приоритет у било ком тренутку. Ово осигурава, под одређеним условима, да ако постоји изводљив план који испуњава све рокове, EDF ће га пронаћи.

Овај алгоритам је превентиван: ако се током извршавања задатка појави други задатак са хитнијим роком, систем може прекинути текући задатак и доделити процесор новом. EDF се обично имплементира коришћењем реда приоритета поређаног по времену преосталом до рока.

Једна од предности EDF-а је то што може постићи скоро 100% искоришћења процесора уз поштовање рокова, под условом да је скуп задатака заказан. Штавише, добро се прилагођава динамичним окружењима где се рокови или процењено време извршења мењају.

На пример, ако имамо два процеса P1 и P2 са различитим периодима и временима израчунавања, EDF ће увек дати предност инстанци чији је апсолутни рок ближи, наизменично извршавајући је како стижу нове активације и како се рокови поново израчунавају.

Међутим, EDF није без недостатака. У ситуацијама са изузетно великим оптерећењем и честим променама, његова ефикасна имплементација може постати сложена, а под одређеним условима могу се јавити проблеми гладовања за задатке са релативно дугим роковима.

Други познати алгоритми у реалном времену укључују монотони алгоритм са брзином (RM) и монотони алгоритм са роком (DM) , који користе фиксне приоритете на основу периода или релативног временског оквира задатака. Сваки има своје услове оптималности и преферирано подручје примене.

Типичне примене система у реалном времену

СТР су свуда. У процесној индустрији користе се за контролу и праћење производних линија за храну, пића, хемикалије, фармацеутске производе итд., осигуравајући да се кључне варијабле држе у оквиру својих граница и да коначни производ има очекивани квалитет.

У транспорту, авиони, возови, аутомобили и бродови ослањају се на системе за навигацију, контролу и безбедност у реалном времену . То се креће од ABS система кочења до контроле вуче и стабилности, као и система за управљање железничким и поморским саобраћајем.

Модерне телекомуникације се ослањају на управљање протоком информација у реалном времену у мрежама велике брзине: комутација пакета, пренос гласа и видеа уживо, осигурање квалитета услуге и смањење латенције су задаци где је поштовање рокова неопходно.

У сектору одбране, системи за надзор, радар, електронско ратовање и сајбер безбедност користе платформе у реалном времену за откривање и реаговање на претње у милисекундама или мање, штитећи критичну инфраструктуру и стратешке ресурсе.

У медицини, опрема као што су монитори виталних знакова, вентилатори, пејсмејкери или инфузионе пумпе раде са софтвером у реалном времену који мора безбедно да реагује на промене у стању пацијента, често са последицама по живот или смрт ако се рокови пропусте.

Ван дигиталног света, реално време се може посматрати и у биолошким процесима. На пример, семе клија само када услови околине падну у одређене распоне и временске оквире (влажност, температура, светлост). Ако би проклијало чим додирне земљу, без поштовања ових временских оквира, вероватно не би преживело. Ово је корисна метафора за то како систем који се не прилагођава свом временском окружењу може да пропадне.

Посматрајући ширу слику, СТР обухватају телекомуникације, мултимедију, индустријску контролу, роботику, авионику, железнице, аутомобилску индустрију, кућне апарате, научне експерименте и медицинске системе . И листа наставља да расте како се развијају нове технологије.

У свим овим окружењима , потребни су специфични протоколи за комуникацију у реалном времену , као што су CAN, Token Bus, TDMA-TTP, прилагођени CSMA/CD или шеме позитивног потврђивања или поновног слања (PAR), које смањују време преноса и пружају гаранције о томе када подаци стижу.

Уз све ово, усавршен је и сопствени софтверски инжењеринг у реалном времену, са методологијама протока података, структурама података и објектном оријентацијом прилагођеним да представљају прекиде, промене контекста, асинхрону комуникацију и опоравак од грешака са захтевима за тешким временом.

Са свим наведеним, постаје јасније зашто су системи у реалном времену сада суштински део модерне технолошке инфраструктуре: они су одговорни за хиљаде критичних и свакодневних процеса који функционишу безбедно, поуздано и без потребе да корисник размишља о свему што се дешава „иза кулиса“ у делићу секунде.