FreeRTOS vs VxWorks vs QNX vs Zephyr: összehasonlítás az RTOS kiválasztásához

A valós idejű operációs rendszer kiválasztása nem triviális: Az RTOS határozza meg a teljesítményt, megbízhatóság és a költség a teljes beágyazott projektedről. A FreeRTOS, a VxWorks, a QNX és a Zephyr között nagyon eltérő filozófiák, licencek és ökoszisztémák léteznek, amelyeket érdemes alaposan megismerni.

Az utóbbi években a fórumokon és közösségekben heves viták alakultak ki: azoktól, akik azt állítják, hogy a FreeRTOS elegendő, egészen addig, akik azt állítják, hogy A kereskedelmi forgalomban kapható RTOS-ok akkor számítanak, ha vannak tanúsítványok és támogatás. a tét. Itt összegyűjtjük és összehasonlítjuk az összes információt, hogy találgatás nélkül hozhass döntést.

Mit hasonlítunk össze, és miért fontos

A konkrét referenciaértékeken túl érdemes összehasonlítani a kernel architektúra, licencek, tanúsítványok, ökoszisztéma és fejlesztési tapasztalatEgy BLE-vel ellátott viselhető eszköz nem ugyanaz, mint egy DAL A repülőgép-rendszer vagy egy ISO 26262 szabványnak megfelelő motorvezérlő.

A piac nagyon is él: a FreeRTOS most az Amazon alatt van, a ThreadX pedig folyamatosan fejlődik Eclipse ThreadX, nyílt kezdeményezések, mint például a Zephyr, amelyet a Linux Foundation, valamint a hagyományos vezető cégek, mint a VxWorks vagy a QNX, amelyek évtizedek óta kritikus telepítésekkel rendelkeznek.

Ezenkívül vannak olyan árnyalatok, amelyek megváltoztatják a játékot: néhány RTOS Egységenként jogdíjat számítanak fel, mások MIT/Apache; némelyik POSIX-os mikrokernelre, mások minimális kernellel és moduláris kiterjesztésekkel támaszkodnak.

Az RTOS jelenlegi panorámája

A piackutatás (AspenCore Embedded Markets Study, VDC Research) és a műszaki listák egyetértenek: A FreeRTOS a legszélesebb körben elterjedt RTOS az MCU-lefedettség szerinti mennyiségben, míg a VxWorks és a QNX a szabályozott szektorokban vezet. A Zephyr „ökoszisztéma-platformként” növekszik az IoT számára.

A gyártók és a közösségek számos tényezőt említenek. népszerű lehetőségekTöbbek között Deos (DDC-I), embOS (SEGGER), FreeRTOS (Amazon), INTEGRITY (Green Hills), Keil RTX (Arm), LynxOS/LynxOS-178 (Lynx), MQX (NXP), Nucleus (Mentor/Siemens), Neutrino/QNX (BlackBerry), PikeOS (SYSGO), SAFERTOS (WITTENSTEIN), ThreadX (Microsoft/Eclipse), µC/OS (Micrium/Silicon Labs), VxWorks (Wind River) és Zephyr (Linux Foundation).

Légy óvatos a Linuxszal nehéz valós idejű környezetben: a funkcionális biztonsági réteg esetében A szokásos dolog egy RTOS vagy biztonsági partíció.és a Linux a gazdag párhuzamos funkcionalitásért egy hipervizoron keresztül; ez a hibrid architektúra az ipari, az autóipari és a védelmi iparban látható.

RTOS típusok és mikor kell őket használni

Hard valós idejű rendszerekben a határidő elmulasztása rendszerhiba: avionika, ABS fékek, robotok ipariAz elszántság és a tanúsítványok kulcsfontosságúak itt, és az olyan RTOS-ok, mint a Deos, az INTEGRITY, a VxWorks, a QNX vagy a LynxOS-178, gyakoriak.

Lágy valós időben a kis késések a minőséget rontják, nem a biztonságot: folyó, útvonaltervezés, infotainmentLehetőség van könnyű kernelek vagy általános célú operációs rendszerek kiterjesztésekkel történő fejlesztésére.

A cég valós idejű működésében a határidő számít, de az elmulasztása nem katasztrofális: üzemautomatizálás, multimédiaA választás a kiszámíthatóság, a költségek és a karbantarthatóság körül forog.

Főbb alkatrészek és az RTOS működése

Egy RTOS determinisztikus ütemezőt kínál (RMS, EDF, fix prioritások) a következővel: korlátozott késleltetések és megszakításkezelés Nagyon hatékony. A cél a legrosszabb eset biztosítása, nem csak az átlagok.

A szinkronizáció szemaforokat, mutexeket és sorokat használ; a feladatok közötti kommunikáció pedig üzenetsorok és eseményekA memóriakezelés minimalizálja a fragmentációt és a jittert a kiszámítható időzítés fenntartása érdekében.

Továbbá a hardverbázist HAL-okkal vagy hordozható API-kkal absztrahálják; a modern platformokon ezt láthatjuk Részleges vagy teljes POSIXés a keretrendszerek csomagtartó biztonságos, kripto és OTA frissítések integrált.

FreeRTOS vs VxWorks vs QNX vs Zephyr, fej-fej mellett

FreeRTOS Ez egy minimalista, moduláris és magas portolási szintű kernel. 2017 óta az Amazon is támogatja, integrálva van az AWS-sel (pl. Greengrass), és hatalmas közösséggel rendelkezik.

• A legjobb: minimális rezsi, nagyszerű támogatás az MCU SDK-kban (Az ESP-IDF integrálja az Espressif és az Amazon SMP variánsait), valamint a szabadságot, hogy „csak azt tedd be, amire szükséged van”. Az ESP32 projektekben az SMP, a részleges POSIX primitívek és a platformfüggetlen C/C++ könyvtártámogatás előnyeit élvezheted.
• A legkevésbé ideális: hiányzik belőle egy egységes „szabványos csomag” mindenhez (illesztőprogramok, fájlrendszerek, kapcsolatok) és Az integrációk a szállítótól függenekNem elegendő, ha azonnal használható biztonsági tanúsítványokra van szüksége.

VxWorks Az ipari RTOS-t évtizedes múltra visszatekintő szolgáltatásként jelöli. Kiemelkedik fejlett hibakereső eszközeivel, professzionális támogatásával és... tanúsítási lehetőségekJelen van a repülőgépiparban, a védelemben, az orvostudományban és az iparban, több architektúrát (ARM, x86, POWER, RISC-V) és SMP/AMP/vegyes módú modelleket támogatva.

• Előnyök: Nagyon kifinomult RT teljesítmény, kiforrott ökoszisztéma és egyértelmű út a tanúsítványhozHátrányok: Kereskedelmi licenc egységenkénti jogdíjjal és kisebb felhasználói rugalmassággal a mag módosításában.

QNX (Neutrino) Egy rendkívül robusztus és megbízható POSIX mikrokernelre támaszkodik, amely jól bevált az autóiparban és az ipari irányítástechnikai iparban. Ez egy tankönyvi mikrokernel: szolgáltatások a felhasználói térben, izoláció és hibatűrés.

• Előnyök: Kiszámíthatóság, stabilitás és tanúsítványok; Hátrányok: lezárt és kifizetett, és kevésbé feltörhető, mint egy nyílt RTOS. Ez egy etalon a motorok és az infotainment rendszerek terén, szilárd autóipari múlttal.

Zefír, amelyet a Linux Foundation üzemeltet, nem csupán egy kernel: egy komplett ökoszisztéma Devicetree-vel, Kconfig-gal, illesztőprogramokkal, BLE/Wi-Fi-vel, parancsértelmezővel, naplózással, MCUBoot-tal és modern szerszámok (nyugaton a multirepo és a twister a tesztekhez).

• Előnyök: Szabványosított API-k, integrált biztonság és valódi MCU-közi hordozhatóságHátrányok: Meredek tanulási görbe (Devicetree/Kconfig), eszközigény Piton és egy „Zephyr-módszer”, amely fegyelmet igényel. Akkor ragyog fel, amikor a projekt komoly csatlakozási, tesztelési és CI/CD-igényeket támaszt.

Kereskedelmi és nyílt forráskódú RTOS-ok, amiket nem szabad kihagyni

• ThreadX / Azure RTOS / Eclipse ThreadX: csökkentett helyigény, több milliárd eszközön telepítve, fejlett ütemezéssel (előzetes engedélyezési küszöbérték), eseményláncolással és nyomkövetéssel. Az Azure-fázis után fejlődik az Eclipse-ben, ami utat nyithat egy átláthatóbb OSS modell felé.
• BIZTONSÁGOS RTOS-ok (WITTENSTEIN): funkcionális biztonságra tervezve IEC 61508 SIL3 és ISO 26262 ASIL D előtanúsítványFunkcionális modellt oszt meg a FreeRTOS-szal, és támogatott migrációs útvonalat kínál.
• domborít (SEGGER): veterán, rendkívül optimalizált és jogdíjmentes reklámKülönösen jól alkalmazható az autóiparban és az iparban; nulla megszakítási késleltetést, minimális memóriahasználatot kínál, és támogatja a 8/16/32 bites verziókat.
• Keil RTX (Kar): szabad és jogdíjmentes Cortex-M esetében rugalmas ütemezéssel (körkörös, preemptív, kooperatív) és jó hibakeresési integrációval az MDK-ARM-ban; ez a jövőben nem az Arm fő stratégiai fókusza.
• MQX (NXP): szilárd alap, de egy szilíciumgyártóhoz kötődik, bezárkózási aggodalmak egyes OEM-eknél. NXP környezetben ez nagyon praktikus lehet.
• Atommag (Mentor/Siemens): Évekkel ezelőtt „az RTOS” volt a modell alatt jogdíjmentes forráskóddal; ma már kisebb a jelenléte, miután a Mentor más szoftvervonalak felé fordult.
• LynxOS és LynxOS‑178 (Lynx Software Technologies): natív POSIX, valós idejű és DO‑178B/C DAL A tanúsítványA LynxOS‑178 rendelkezik FAA RSC-vel, ami egy ritka COTS szakvélemény a tanúsítható újrafelhasználhatóság terén.
• PikeOS (SYSGO): Particionálásra és hipervizorra fókuszálva; nagyon tanúsítás-orientált vegyes rendszerek, ahol az RTOS és a Linux/egyéb vendég operációs rendszerek együtt élnek.
• Az istenek (DDC-I): Repülőgép-/védelmi célpont DO-178-cal; modell egységenkénti jogdíjak és nagyon specifikus A&D fókusz.
• µC/OS / Micrium OS (Silicon Labs): Történelmileg széles körben használták orvosi és ipari alkalmazásokban; ma már elérhetősége és cím a Silabs univerzumon kívül kétségeket kelthet egyes csapatokban.
• TI-RTOS (Texas Instruments): Felgyorsítja a TI MCU-kon történő fejlesztést RTOS kernel + köztes szoftverek és illesztőprogramok segítségével; elősegíti az energiahatékonyságot és gyors kilépés az IT ökoszisztémába.
• Contiki-NG: IoT-csomag, hangsúlyt fektetve a hálózatépítésre; a Docker és a reprodukálható környezetek népszerűsítése, ideális konnektivitás-orientált projektekhez és a kísérletezés.
• RIOTGNU Make, szabványos eszközláncok és rengeteg dokumentáció; jó OSS alternatíva amikor valami a csupasz fém és a teljes értékű Zephyr között van.
• NuttXnagyon rátermett és POSIX-ízű, de a Kconfig használatával és a környezeti követelmények bonyolíthatják bizonyos integrációkat és folyamatokat Windows.
• ChibiOS/RTkönnyű és gyors; egyes áramlásokban úgy tűnik fogadj adott IDE-kre/eszközökre, ami ütközhet a már meglévő csővezetékekkel.
• DuinOS: többszálú működés kompatibilis alaplapokon Arduino FreeRTOS-on alapul; hasznos oktatásban vagy prototípusok keresésében fejlődj ki az Arduinoból valódi RTOS felé.

Fejlesztői tapasztalat: eszközláncok, CI/CD és portolás

A csapat tapasztalata ugyanolyan fontos, mint az adatlapok: egy sima görbületű RTOS és szabványos szerszámok Hetek munkáját takaríthatja meg. A FreeRTOS szinte bármivel lefordul, és „láthatatlanná teszi magát”, megkönnyítve a munkafolyamatokat C/C++-val és egyszerű szerkesztőkkel.

Zephyr ragyog vele west, twister, Devicetree és Kconfig, ideális folyamatos szállítási gyakorlatok és validáció egy panelfarmon. Cserébe meg kell tanulni a hardverleírás és a funkciók konfigurálásának módját, és ez Pythonon alapul.

Az ESP-IDF-ben a FreeRTOS jól integrált SMP variánsokat, részleges POSIX-ot és hatalmas közösséget kínál; ha több platformon átívelő könyvtárakat (pl. POCO) használsz újra, akkor… oszd meg a kód egy jó részét asztali számítógéppel, a részleteket a rendszerindításra és a perifériákra korlátozva.

A reklámokban az érték a támogatásban, a nyomokban és probléma diagnózis Alacsony szinten. Amikor a határidők és a szabványok betartása nem hagy teret a meglepetéseknek, akkor egy beszállító támogatása megváltoztatja a játékszabályokat.

Tanúsítványok, biztonság és vegyes architektúra

Ha az orvostudomány, az autóipar vagy a repüléstechnika területére összpontosítasz, tekintsd át a következőket a kezdetektől fogva: tanúsítási bizonyíték Elérhető: DO‑178C (repülőelektronika), IEC 61508 (ipari), ISO 26262 (autóipar). Az olyan termékek, mint a LynxOS‑178, a VxWorks, az INTEGRITY, a Deos vagy a SAFE RTOS, már rendelkeznek kiépített útvonalakkal.

Biztonság terén a Zephyr integrálja a következőket: MCUBoot, mbedTLS és PSA Crypto, és betartja a helyes konfigurációs gyakorlatokat; a FreeRTOS AWS-kész csomagokat és biztonságos rendszerindítási lehetőségeket kínál a gyártótól függően.

A Linux és az RTOS kombinálásához a természetes módszer a hipervizor/particionálás (pl. PikeOS, LYNX MOSA.ic). Tehát a kritikus részt tartsd fenn egy RTOS-ra, és a felhasználói felületet, a csatlakoztathatóságot és a gazdag funkciókat a Linuxra hagyja.

Jogdíjak, licencek és teljes költség

A népszerű lehetőségek közül általában a következőket kínálják: egységenkénti jogdíjakVxWorks, QNX/Neutrino, INTEGRITY, PikeOS, LynxOS, Deos. Jogdíjmentes: FreeRTOS (MIT), Zephyr (Apache), embOS (jogdíjmentes üzleti modell), Keil RTX, MQX, Nucleus, µC/OS, SAFE RTOS és ThreadX különböző verziói.

A teljes költség nem csak a licencből áll: tartalmazza integrációs idő, validáció, támogatás és kockázatA támogatásért fizetni olcsó lehet, ha hetekig tartó bizonytalanságot takarít meg a tanúsítvánnyal vagy egy nehezen megtalálható hibával kapcsolatban.

Hogyan döntsünk: platform, követelmények és felszerelés

Ha a hardvered Cortex-A/x86, és összetett illesztőprogramokra van szükséged, akkor jobb lehet egy teljes operációs rendszerrel vagy egy Kereskedelmi RTOS POSIX-szal és támogatás. Ha memóriával korlátozott MCU-ról van szó, a FreeRTOS vagy az embOS könnyű választás.

Ha a projekted BLE-t, Wi-Fi-t, FS-t, shell-t, automatizált tesztelést és reprodukálható buildet igényel, a Zephyr csökkenti az integráció nehézségeit a következőknek köszönhetően: Konzisztens API-k és eszközökHa szabályozott tevékenységet folytatsz, először ellenőrizd a tanúsítási útvonalat, mielőtt beírnád az első sort a kódban.

Csapatkultúra szerint: ha mindenki folyékonyan beszéli a CMake/GNU Make-et és kerüli a Python függőségeket, akkor egy „láthatatlan” kernel, mint például a FreeRTOS, jobban megfelel; ha a csapatod egy CI / CD és DevOpsA Zephyr középtávon boldoggá tesz.

Tartsd szem előtt a szilícium és az eszközök „kötését”: egy RTOS, amely egy gyártóhoz vagy egy zárt lakosztály bonyolíthatja a jövőbeli migrációkat. Kezdetben, amikor csak lehetséges, törekedjen a szabványos HAL-okra és API-kra.

Használati esetek iparáganként

• Autóipar: a motorvezérlés, az ADAS és az infotainment rendszer általában megosztott. Tanúsított RTOS és a POSIX mikrokernel; a QNX és a VxWorks dominál, a SAFE RTOS/INTEGRITY megjelenik a biztonsági láncokban, a Linux pedig együtt létezik az infotainmentben.
• Ipari: CNC-k, robotok, PLC-k és átjárók kombinálják a determinisztikus RTOS-t a Linux a csatlakozáshozEz magában foglalja a VxWorks, INTEGRITY, LynxOS‑178, PikeOS és OSS opciókat, mint például a FreeRTOS/Zephyr, a kockázattól és a költségektől függően.
• Orvos: Az infúziós pumpák, monitorok és beültethető eszközök... nyomon követhetőség és bizonyítékokA SAFE RTOS, a VxWorks, a QNX, az INTEGRITY és a µC/OS nagy népszerűségnek örvend.
• IoT és fogyasztás: a viselhető eszközök, érzékelők és okosotthonok gyakran a helyigény, a csatlakoztathatóság és a költségek prioritását helyezik előtérbe: FreeRTOS és Zephyr gyakoriak, a ThreadX számos kereskedelmi forgalomban kapható elemben megtalálható.

Közösségi jegyzetek és tanulságok

A műszaki közösségekben erős vélemények vannak: állítólag A FreeRTOS „jónak tűnik”, ha még nem játszottál reklámokkal, mások pedig az MCU és a gyártói támogatás terén való valódi rugalmasságával válaszolnak (erre kiváló példa az ESP-IDF).

A ThreadX-en az Eclipse-re való átállás utat nyit a következőknek: nagyobb átláthatóság, bár egyes csapatok szétszórt dokumentációról számolnak be az Azure-beli szakaszban. A kulcs: értékelje a repo jelenlegi állapotát és a példáit az MCU-hoz.

Zephyrrel kapcsolatban az a visszatérő kritika, hogy tanulási görbe (Devicetree, Kconfig), de a jutalom egy hosszú távon karbantarthatóbb projekt és kevesebb házilag készített „ragasztó”.

És a FreeRTOS-ban a „csak azt tedd be, amire szükséged van„elkerüli a bináris fájl túlterhelését, és lehetővé teszi az ütemező, a halom és az illesztőprogramok gond nélküli testreszabását.”

Csak egyetlen recepthez ragaszkodni önámítás lenne: Minden RTOS egy adott kontextusban ragyogHa tanúsításra és támogatásra van szüksége, egy értékesítési képviselő a legjobb választás; ha minimális helyigényű rendszert vagy szabványosított OSS ökoszisztémát keres, a FreeRTOS vagy a Zephyr jó választás. Azoknak a csapatoknak, akik nagyra értékelik a CI/CD-t és a hordozhatóságot, a Zephyr egy nagyon stabil, mindent egyben megoldást kínál; azoknak, akik a finomhangolt vezérlést és a minimális súrlódást helyezik előtérbe, a FreeRTOS szabad utat enged.

Kapcsolódó cikk:

Fix kiadás vs. Rolling kiadás vs. Development ág, Éjszakai buildek és folyamatos szállítás: a stratégiák különbségei és összehasonlítása

Izsák

Szenvedélyes író a bájtok és általában a technológia világáról. Szeretem megosztani tudásomat írásban, és ezt fogom tenni ebben a blogban, megmutatom a legérdekesebb dolgokat a kütyükről, szoftverekről, hardverekről, technológiai trendekről stb. Célom, hogy egyszerű és szórakoztató módon segítsek eligazodni a digitális világban.