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 zdá zbytečné, dokud nedojde k situaci, kdy zmeškaný deadline způsobí, že robotické rameno narazí do člověka nebo se 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 a 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 její překročení 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 obecně použitelných operačních systémů jsou navrženy jako férové plánovače, tedy tak, aby rozdělovaly prostředky mezi procesy, zpracovávaly přerušení, spravovaly paměť a průměrně optimalizovaly 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, jsou takové výkyvy nepřijatelné. Výkyv 2 ms zde nevyhnutelně vede k hardwarové poruše.
RTOS (Real-Time Operating System), jako je FreeRTOS, Zephyr nebo VxWorks, využívá prioritní plánovač s deterministickým zpracováním přerušení. Nejhorší latence přerušení je ohraničená a měřitelná. Úloha s vyšší prioritou okamžitě přebírá procesor od méně důležité úlohy, nikoli až ve chvíli, kdy se plánovač dostane na řadu.
V Consilia jsou rozhodnutí o softwarové architektuře vedena přímo analýzou deadlinů. Například v projektu TETRA základnové stanice záměrně využíváme dvouprocesorovou architekturu platformy Zynq: jedno jádro ARM provozuje RTOS pro nízkoúrovňové zpracování signálu, kde načasování není předmětem diskuse, zatímco druhé provozuje Linux pro služby vyšší úrovně, kde je důležitější flexibilita než přesnost na úrovni mikrosekund.
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 toto číslo 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ý cloudové řízení nemůže dosáhnout 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. V průmyslových a bezpečnostně kritických systémech je kombinace správného RTOS a edge processingu předpokladem deterministického chování i jeho certifikovatelnosti.