V inženýrství je rychlá odezva bezvýznamná, pokud ji nelze zaručit. Systém, který reaguje spolehlivě za 50 ms, je více deterministický než ten, který reaguje za 5 ms jen někdy. Toto rozlišení se může zdát zbytečné, dokud nedojde k situaci, kdy zmeškaný deadline způsobí, že robotické rameno zasáhne pracovníka nebo bezpečnostní ventil nestihne zavřít včas.
Determinismus je skutečný požadavek
Zpracování v reálném čase je formálně definováno jako schopnost systému reagovat na vstup v rámci ohraničeného, předvídatelného časového okna, bez ohledu na vytížení systému, teplotní podmínky nebo souběžnou aktivitu. Tato hranice se nazývá deadline a to, zda je překročení tohoto deadlinu přípustné, určuje třídu systému reálného času.
Hard real-time (nulová tolerance zpoždění)
Nulová tolerance pro překročení deadlinu. Zmeškaný deadline znamená selhání systému. Příklady zahrnují systémy řízení letu, aktivaci airbagů, protiblokovací brzdné systémy a chirurgickou robotiku. Zpoždění 1 ms je totéž jako žádná reakce.
Soft real-time (degradace výkonu bez havárie)
Toleruje občasné překročení deadlinu s postupnou degradací výkonu místo katastrofického selhání. Video kodek, který vynechá snímek, způsobí viditelný artefakt, neshodí ale letadlo. Příklady zahrnují zpracování zvuku, průmyslové HMI systémy a síťovou telemetrii.
Firm real-time (pozdní výsledek je bezcenný, ne nebezpečný)
Výsledky doručené pozdě jsou bezcenné, ale nejsou nebezpečné. Příklady zahrnují automatizované obchodní systémy a určité sensor fusion pipeline.
Tyto kategorie přímo ovlivňují inženýrská rozhodnutí. Požadavek hard real-time zpravidla vylučuje standardní Linux jako primární runtime. Požadavek soft real-time nikoli.
Proč standardní operační systémy nesplňují požadavky hard real-time
Linux, Windows a většina univerzálních operačních systémů jsou navrženy jako férové plánovače. Průběžně rozdělují prostředky mezi procesy, zpracovávají přerušení, spravují paměť a optimalizují průměrnou odezvu. Slovo „průměrně“ je zde problémem.
Pod standardním jádrem Linuxu se latence přerušení může pohybovat od několika mikrosekund až po několik milisekund, v závislosti na tom, co systém právě dělá. Pro aplikaci soft real-time je tato variabilita přijatelná. Pro aplikaci hard real-time, jako je řízení výstupního stupně měniče napájení na spínací frekvenci 100 kHz, vede výkyv jitteru 2 ms nevyhnutelně k hardwarové poruše.
Operační systém reálného času (RTOS), jako je FreeRTOS, Zephyr nebo VxWorks, využívá preemptivní prioritní plánovač s deterministickým zpracováním přerušení. Nejhorší latence přerušení je ohraničená a měřitelná. Úlohy s vyšší prioritou přebírají procesor od úloh s nižší prioritou okamžitě, nikoli až ve chvíli, kdy se k tomu plánovač dostane.
Pod úrovní RTOS: DSP a FPGA
Zpracování v reálném čase nezačalo u RTOS. Než byly univerzální procesory dostatečně rychlé na to, aby jim bylo možné svěřit ohraničené doby odezvy, dosahovalo se determinismu vyhrazením křemíku pro danou úlohu.
Digitální signálové procesory, jako je rodina TMS320 od TI nebo procesory SHARC a Blackfin od Analog Devices, byly postaveny kolem jednotky multiply-accumulate pracující v jednom taktu, harvardské architektury paměti, smyček s nulovou režií a kruhového adresování pro zpožďovací linky filtrů. Praktický důsledek je důležitější než výčet vlastností: jádro filtru na DSP běžící bare-metal, bez operačního systému a bez plánovače, vykoná pokaždé stejný pevný počet taktů. Nejhorší doba vykonání se neměří statisticky během dlouhého testovacího běhu; vypočítá se z výpisu instrukcí ještě předtím, než je deska vůbec poprvé zapnuta.
Programovatelné hradlové pole (FPGA) posouvá stejnou myšlenku o krok dál tím, že zcela odstraňuje proud instrukcí. Není zde žádný plánovač, který by úlohy přerušoval, žádný řadič přerušení, který by rozhodoval o pořadí, ani žádná sdílená sběrnice, o kterou by se soupeřilo. Algoritmus místo toho existuje jako paralelní logika a jeho časování je funkcí taktovací frekvence a zpoždění šíření signálu, ověřenou statickou časovou analýzou během syntézy. Jitter se vyjadřuje v taktech, nikoli v mikrosekundách. Právě proto je FPGA jedinou prakticky použitelnou možností pro zpracování na vzorkovací frekvenci desítek či stovek megahertzů, pro časování protokolů s tolerancemi v nanosekundách nebo pro stovky kanálů, které je nutné obsluhovat skutečně současně, nikoli střídáním v čase.
Tyto čtyři možnosti dohromady tvoří škálu, na které se vyměňuje flexibilita za determinismus: GPOS nabízí největší flexibilitu, ale jen statistické záruky časování; RTOS ohraničuje nejhorší latenci na mikrosekundy při zachování známého softwarového modelu; bare-metal DSP poskytuje vykonávání s přesností na takt za cenu podstatně užšího vývojového prostředí; a FPGA zajišťuje determinismus už svou konstrukcí, ovšem s nejvyšší inženýrskou náročností na funkci.
Moderní návrhy si zřídka vybírají jen jednu z nich. Heterogenní SoC umisťují všechny na jediný čip, a právě proto se platforma Zynq hodí pro TETRA základnovou stanici: programovatelná logika obsluhuje nejrychlejší signálovou cestu, jedno jádro ARM provozuje RTOS pro časově kritické řízení a druhé provozuje Linux pro správu a konektivitu. Rozhodnutí nezní, která technologie je nejlepší, ale který deadline patří, na kterou úroveň.
Co systémům reálného času přináší edge processing (zpracování dat na hraničních zařízeních)
Přesunutí zpracování blíže k senzoru eliminuje největší a nejméně předvídatelný zdroj latence ve většině IoT architektur: síť.
Latence zpátečního přenosu přes cloud (obvykle 50–200 ms) není jen pomalá z hlediska reálného času, je nedeterministická. Přetížená síť může tuto latenci posunout na řád sekund.
Edge processing obnovuje determinismus tím, že síť zcela vylučuje z řídicí smyčky. Získáme tím dvě konkrétní výhody:
Zpětná vazba v uzavřené smyčce na úrovni mikrosekund
Senzor může spustit aktuátor, aniž by jakákoli data opustila lokální hardware. Při řízení motoru může měření proudu, výpočet PID a úprava výstupu PWM proběhnout za méně než 10 µs na správně nakonfigurovaném RTOS. To je výkon, kterému se cloudové řízení nemůže přiblížit ani řádově.
Bezpečný provoz při výpadku konektivity
Kritické systémy mohou udržovat bezpečný stav i při výpadku externího připojení. Pojistný ventil přetlaku, který se spustí na základě lokální edge logiky, nezávisí na dostupnosti cloudu. V bezpečnostní certifikaci (IEC 61508, ISO 26262) je to často formální požadavek: bezpečnostní funkce nesmí záviset na externí komunikaci.
Závěr
Zpracování dat v reálném čase je v konečném důsledku o garantovaném chování, nikoli o hrubém výkonu. Zda tato záruka pochází z RTOS, bare-metal DSP, nebo FPGA, vyplývá ze samotného deadlinu, ne z preference jedné technologie před druhou. V průmyslových a bezpečnostně kritických aplikacích je právě spojení správné úrovně determinismu s lokálním zpracováním na edge tím, co dělá deterministické chování dosažitelným a certifikovatelným.
