RTOS (operační systémy reálného času): principy, implementace a determinismus

Internet věcí (IoT), embedded a hardware
Natália Šimková
RTOS (Real-Time Operační Systémy): Principy, implementace a determinismus

Co je RTOS a proč jej používat

RTOS (Real-Time Operating System) je operační systém navržený pro deterministické chování – tedy schopnost garantovat časově omezenou odezvu na události. Na rozdíl od obecného operačního systému (Windows, Linux bez rozšíření pro práci v reálném čase) klade RTOS důraz na přesné plánování úloh, předvídatelnost latencí a řízení zdrojů tak, aby kritické funkce systému (řízení motoru, brzd, ovládání robotu, audio pipeline, rádiová komunikace) splnily své časové termíny.

  • Determinismus: chování úloh je analyticky předvídatelné (WCET, doba odezvy).
  • Malá paměťová stopa: nízké nároky na paměť (desítky až stovky kB), běh na MCU bez MMU.
  • Modularita: jádro, plánovač, synchronizační primitiva, IPC, časovače, ovladače.
  • Bezpečnost: izolace, MPU/MMU, watchdog, obsluha chyb, certifikované varianty.

Typy požadavků na práci v reálném čase

  • Hard real-time: zmeškání termínu je nepřijatelné (brzdový systém, kardiostimulátor). Návrh musí prokázat splnitelnost termínů v nejhorším případě.
  • Firm real-time: občasné zmeškání je tolerovatelné, ale snižuje užitek (síťová brána s QoS).
  • Soft real-time: upřednostňuje se nízká latence a kolísání, ale zmeškání termínu není fatální (streamování audia).

Časování, latence a metriky

  • WCET (Worst-Case Execution Time): horní mez doby běhu úlohy na dané konfiguraci procesoru a kompilátoru.
  • Latence ISR: doba od vzniku přerušení do jeho obsluhy (ovlivňují ji maskování, priorita a kritické sekce).
  • Latence plánování: doba od uvolnění úlohy s nejvyšší prioritou ve stavu ready do jejího spuštění (přepnutí kontextu, preempce).
  • Kolísání: změna periody či odezvy; minimalizuje se výběrem plánovače, režimem tickless a omezením kritických sekcí.

Plánovací algoritmy v RTOS

Volba plánovače ovlivňuje předvídatelnost a využití CPU. Běžně se používají:

  • Pevné priority (preemptivní): každé úloze je přiřazena priorita; vždy běží úloha s nejvyšší prioritou, která je ve stavu ready. Často se doplňuje o dědění priority, které pomáhá předcházet inverzi priorit.
  • Rate-Monotonic (RM): úlohám s kratší periodou se přiděluje vyšší priorita (pevná); splnitelnost lze analyticky prokázat pomocí využití CPU.
  • Deadline-Monotonic (DM): kratší termín ⇒ vyšší priorita (pevná).
  • Earliest Deadline First (EDF): dynamický algoritmus, při němž vždy běží úloha s nejbližším termínem; pro jednojádrový systém je při nízké režii optimální.
  • Round-Robin: časové dělení mezi úlohy se stejnou prioritou; často se kombinuje s pevnými prioritami.

Analýza splnitelnosti (schedulability)

U systémů typu hard real-time se formálně ověřuje, zda všechny úlohy splní své termíny i v nejhorším případě.

  • Testy využití (Liu & Layland): pro RM platí mez pro n periodických úloh U ≤ n(2^{1/n} − 1).
  • Analýza doby odezvy (RTA): iterativně se počítá nejhorší doba odezvy úlohy včetně interference úloh s vyšší prioritou a blokování na mutexech.
  • Úlohy s jedním účelem a sporadické servery: návrh pro obsluhu aperiodických požadavků bez ohrožení periodických úloh.

Úlohy, vlákna a stavy

  • Stavy: running, ready, blocked (na semaforu/frontě), suspended, delayed (časovač), terminated.
  • Atributy: priorita, zásobník (stack), afinita k jádru (SMP), perioda/termín, hook pro sledování.
  • Životní cyklus: vytvoření/zrušení, suspend/resume, odložení, změna priority, běh řízený událostmi.

Přerušení (ISR) a přepínání kontextu

ISR musí být co nejkratší: pouze přečíst či uložit data, odmaskovat přerušení a upozornit úlohu (semaforem, frontou, příznakem události). Náročnější zpracování je třeba přesunout do úloh s nižší prioritou. Je nutné:

  • Minimalizovat dobu, po kterou jsou přerušení zakázána.
  • Nepoužívat blokující volání RTOS z ISR, pokud nejsou výslovně povolena.
  • Správně mapovat priority NVIC (ARM Cortex-M) a prioritní úrovně RTOS.

Synchronizační primitiva a IPC

  • Mutex: výhradní přístup s využitím dědění priority nebo stropu priority k prevenci inverze priorit.
  • Binární semafor: signalizace události (typicky z ISR úloze).
  • Počítaný semafor: omezená kapacita zdroje (např. kanály DMA).
  • Fronty (message queues): přenos struktur/dat mezi úlohami, často s kopírováním nebo bez kopírování (zero-copy).
  • Skupiny událostí: bitová maska pro agregaci signálů z více zdrojů.
  • Poštovní schránky/proudové buffery: efektivní přenos proudových dat (UART, audio).
  • Časovače (softwarové časovače): odložené akce a periodické úkoly bez aktivního čekání.

Inverze priorit: detekce a zmírnění

Inverze priorit nastává, když úloha s nízkou prioritou blokuje úlohu s vysokou prioritou kvůli sdílenému zámku. Řešení:

  • Dědění priority: dočasné zvýšení priority úlohy, která drží zámek.
  • Strop priority: zámek má „strop“ priority; při jeho uzamčení se priorita úlohy změní na tuto hodnotu.
  • Bez zámků/RCU: tam, kde je to vhodné a bezpečné, volit struktury bez zámků.

Paměť a ochrana

  • Statická alokace: v bezpečnostně kritických systémech má přednost, protože je předvídatelná.
  • Dynamická alokace: pokud je nutná, použít deterministický alokátor (TLSF) a pooly bloků pevné velikosti.
  • MPU/MMU: ochrana proti přetečení zásobníku, izolace úloh/ovladačů, sandboxing.
  • Dimenzování zásobníku: měření maximálního využití zásobníku (high watermark), ochranná oblast, detekce přetečení.

Tick vs. tickless, časování a spotřeba

  • Řízení tikem: periodický systémový tik (např. 1 ms). Je jednodušší, ale zvyšuje kolísání a spotřebu.
  • Tickless: plánovač nastavuje nejbližší budík; nižší spotřeba a menší kolísání za cenu vyšší složitosti.
  • RTC/nízkoenergetické časovače: pro uspání MCU a přesné probouzení; je nutná synchronizace s jádrem RTOS.

Ovladače, DMA a práce s periferiemi

Při návrhu RTOS se doporučuje vrstvená architektura: ISR → lehký HAL/BSP → fronty/události → úlohy. DMA snižuje zatížení CPU a kolísání, ale vyžaduje správu cache a paměťových bariér (u MCU s cache). Paměťové překryvy, dvojité bufferování a techniky „ping-pong“ jsou standardem pro datové proudy (ADC, I2S, UART).

Síťování a průmyslové protokoly

  • Sada protokolů TCP/IP: lwIP, IPv4/IPv6, offload TLS, MQTT.
  • Průmyslové protokoly: CAN/CAN-FD, LIN, Modbus, EtherCAT; důraz na přesné cykly a nízké latence.
  • TSN (Time-Sensitive Networking): deterministický Ethernet (časová synchronizace, plánování).

Multiprocesorové RTOS: SMP vs. AMP

  • SMP: jeden plánovač pro více CPU; sdílené fronty, afinity, zámky, koherence cache.
  • AMP: na každém jádře běží vlastní OS/RTOS; komunikace prostřednictvím RPMsg, poštovních schránek a sdílené paměti.
  • Heterogenní SoC: jádro A (Linux) + jádro M (RTOS) s remoteproc a kanály virtio.

Hypervizory a systémy se smíšenou kritičností

Pro konsolidaci funkcí a oddělení domén lze použít lehké hypervizory (rozdělení na úrovni bare metal, typ 1). Umožňují souběžný běh bezpečnostně kritických částí (ASIL, DAL) s méně kritickými aplikacemi bez vzájemného rušení.

Linux pro práci v reálném čase vs. RTOS

  • PREEMPT_RT: zlepšuje latence Linuxu; je vhodný pro vyšší vrstvy a složité sady protokolů.
  • RTOS: nižší režie, menší paměťová stopa, větší kontrola nad časováním. Často spolupracuje s Linuxem běžícím na jiném jádře.

Bezpečnost a spolehlivost

  • Watchdog a ochrana proti poklesu napětí: zotavení ze záseků a poklesu napětí.
  • Bezpečný režim při poruše a pokračování v provozu při poruše: definujte bezpečný stav a degradované režimy.
  • Ochrana před útoky: bezpečné spouštění, kryptografické podpisy, řízení oprávnění úloh, ASLR (pokud je k dispozici), aktualizace OTA s možností návratu k předchozí verzi.
  • Standardy: MISRA C/C++, CERT C, ISO 26262 (automobilový průmysl), IEC 61508 (průmysl), DO-178C (letectví), IEC 62304 (zdravotnictví).

Volba RTOS a ekosystém

  • FreeRTOS/Azure RTOS ThreadX: široká podpora MCU, velká komunita, nástroje pro trasování.
  • Zephyr: modulární systém, device tree, rozsáhlé subsystémy (BLE, TCP/IP, senzory).
  • VxWorks, QNX: komerční řešení s možností certifikace, bohatými nástroji a dlouhodobou podporou.
  • RTEMS, NuttX, μC/OS: další osvědčené varianty podle požadavků na licence a funkce.

Build, CI/CD a aktualizace

  • Reprodukovatelné buildy: pevně stanovit verzi toolchainu, využívat kontejnerizaci a hermetické skripty.
  • Testy v CI: jednotkové (Ceedling/CppUTest), integrační, regresní, testy pokrytí kódu.
  • HIL (Hardware-in-the-Loop): automatizované scénáře se skutečnou deskou, měření latencí.
  • OTA: sloty A/B, kryptografické podpisy, bezpečný zavaděč, spolehlivý návrat k předchozí verzi.

Diagnostika a trasování v RTOS

  • Statistiky za běhu: využití CPU jednotlivými úlohami, délky front, maximální využití zásobníků.
  • Trasování: sledování přepínání úloh, ISR a blokování; nástroje jako ITM/SWO, ETM a knihovny pro trasování.
  • Nezablokující logování: kruhový buffer, DMA do UART/USB, časová razítka s vysokým rozlišením.

Doba zavádění a spouštění systému

  • Inicializace časovačů a NVIC: přednostně inicializovat kritické periferie před méně důležitými.
  • Minimalizace doby do stavu „ready“: odložená inicializace, odložené zpracování v úlohách s nízkou prioritou.
  • Vlastní testy: CRC firmwaru, testy RAM, základní kontroly periferií.

Návrhové vzory pro aplikace RTOS

  • Producent–konzument: ISR nebo senzory vkládají data do front; zpracování probíhá v pracovní úloze.
  • Dispečer příkazů: fronta příkazů pro ovladač/sadu komunikačních protokolů.
  • Stavový automat pro každou úlohu: každá úloha implementuje explicitní automaty; zvyšuje to přehlednost kódu.
  • Architektura řízená časem: cyklické spouštění úloh v přesně vymezených intervalech (hlavní a dílčí cyklus).

Typické pasti a jak se jim vyhnout

  • Nadměrné používání mutexů ⇒ uváznutí a kolísání. Upřednostňujte fronty a postupy bez zámků.
  • Dlouhé ISR a příliš široké maskování přerušení ⇒ vysoké latence.
  • Nesprávné dimenzování zásobníků ⇒ záhadné pády; sledujte maximální využití zásobníků.
  • Neřízená dynamická alokace ⇒ fragmentace; používejte pooly a statickou alokaci.
  • Nepřihlédnutí ke cache a bariérám při použití DMA ⇒ nekonzistentní data.

Ukázková architektura malé aplikace RTOS

  • Úlohy: CommTask (vysoká priorita) pro RX/TX, ControlTask (střední priorita) pro regulaci, LoggerTask (nízká priorita) pro záznam.
  • ISR: ISR UART RX plní proudový buffer, časovač generuje tik pro regulátor, ISR DMA pro ADC signalizuje dokončení.
  • IPC: fronty pro příkazy, semafory pro dokončení převodů, skupina událostí pro stav subsystémů.
  • Bezpečnost: watchdog, segmentace zásobníků pomocí MPU, bezpečné spouštění v zavaděči.

Testování a verifikace

  • Jednotkové testy: logika stavových automatů, parsování protokolů, matematické knihovny.
  • Integrační testy s RTOS: simulace zatížení, vkládání přerušení ISR, testy přerušení a preempce.
  • Zátěžové a časové testy: měření latencí, kolísání, propustnosti pipeline, testy hraničních stavů.
  • Formální metody: ověřování modelů pro kritické části a protokoly.

Licenční a komerční aspekty

  • Open-source licence: MIT/BSD (jádro FreeRTOS), Apache-2.0 (Zephyr), GPL/LGPL u některých komponent.
  • Komerční podpora: SLA, dlouhodobě podporované verze LTS, certifikované buildy pro bezpečnostní domény.

Osvědčené postupy – kontrolní seznam

  • Definujte kritičnost úloh a jejich termíny, proveďte analýzu RTA.
  • Minimalizujte ISR; náročnější zpracování delegujte na úlohy.
  • Pro sdílené zdroje používejte dědění nebo strop priority.
  • Měřte a zaznamenávejte latence, maximální využití zásobníků, délky front a zatížení CPU.
  • Upřednostňujte statickou alokaci a deterministické alokátory.
  • Zapněte MPU (pokud je k dispozici) a watchdog.
  • Oddělte bezpečnostně kritické části (izolace, hypervizor/AMP).
  • Automatizujte testy v CI a používejte HIL.

Slovníček pojmů

  • Termín (deadline): čas, do kterého musí být úloha dokončena.
  • Preempce: schopnost plánovače přednostně spustit úlohu s vyšší prioritou.
  • Splnitelnost (schedulability): schopnost celé sady úloh dodržet časová omezení.
  • Tickless: režim bez periodického tikání, v němž se budík nastavuje podle nejbližší události.

Závěr

RTOS je klíčovým stavebním prvkem vestavěných systémů s přísnými časovými požadavky. Úspěch skutečného projektu závisí na správné volbě plánovače, disciplinovaném používání synchronizačních primitiv, promyšlené správě paměti a důsledném měření časování. Spolu s bezpečnostními mechanismy a aktualizacemi tvoří RTOS solidní základ pro spolehlivá a bezpečně provozovaná zařízení v průmyslu, automobilovém sektoru, zdravotnictví i IoT.