Valós-idejű szoftver aktivitás definíciója és tulajdonságai

Mi ez? Egy olyan szoftveres kódrészlet, ami egy adott külső esemény hatására, garantált válaszidővel (deadline) fut le, függetlenül a rendszer egyéb állapotától. (Analógia: Képzelj el egy Arduino hardware interruptot, de ha itt a feldolgozás túllépi az előírt mikroszekundumot, a rendszer funkcionálisan elbukik). Hogyan működik? Ahhoz, hogy egy aktivitás valós idejű lehessen, biztosítani kell számára a megadott válaszidőnél rövidebb, determinisztikus végrehajtási időt. Tipikusan “Run-to-completion” (befejezésig fut) elven működik, megszakítás nélkül. Must-know facts:

• A maximális végrehajtási időt WCET-nek (Worst-Case Execution Time) hívják.
• Nem az egész szoftver valós idejű, csak annak jól meghatározott, kritikus részei.
• Az olyan algoritmusok, amik iterációinak száma nem korlátozható (nem determinisztikusak), kizárják a valós idejűséget.

---

Klasszikus és modern végrehajtási környezet hatása a valós-idejű végrehajtásra

Mi ez? Azt írja le, hogy a futtató hardver felépítése mennyire teszi lehetővé a WCET (Worst-Case Execution Time) pontos kiszámítását. Egy klasszikus 8-bites mikrokontroller kiszámítható, de egy modern többmagos processzor kiszámíthatatlan. Hogyan működik? Modern CPU-k (x86, ARM Cortex-A) spekulatív végrehajtást (branch prediction), gyorsítótárakat (CACHE), virtuális memóriát és DMA-t használnak a sebesség növelésére. Ezek miatt a memóriához és perifériákhoz való hozzáférés ideje esetenként nagyságrendekkel eltérhet, tönkretéve a determinizmust. Must-know facts:

• A virtuális tárkezelés (lapozás/swap) teljes mértékben összeférhetetlen a valós-idejűséggel.
• A modern OS overhead-je (a rendszer adminisztrációjára fordított idő) rontja a válaszidőt.
• A megoldás ma a Heterogén architektúra: egy SoC-on belül a komplex operációs rendszer mellett egy különálló, dedikált (egyszerű, cache mentes) RT-mag végzi az időkritikus feladatokat.

---

Feladat fogalma

Mi ez? Az ütemezés szempontjából a végrehajtás legkisebb, CPU-t kapó logikai egységeinek általános megnevezése. Konkrét szoftveres implementációjában lehet folyamat (process) vagy szál (thread) is. Hogyan működik? Amikor a CPU felszabadul, az OS ütemezője (Scheduler) a memóriában lévő (Futásra kész / Ready) feladatok közül választ egyet, és elindítja a processzoron. Must-know facts:

• A feladatok állapotai között az átmenetet kizárólag megszakítások (HW, SW vagy kivétel) vezérlik.

---

Folyamat fogalma, tulajdonságai/értékelése, létrehozás, kommunikációja, befejezése

Mi ez? A folyamat (Process) a végrehajtás alatt álló program egy nehézsúlyú (heavyweight) példánya. (Analógia: Egy elindított, különálló Java JVM instance vagy futó Docker konténer, saját memóriatérrel). Hogyan működik?

1. Létrehozás: UNIX/Linux rendszereken a fork() majd exec() rendszerhívásokkal jön létre. (Lassú, erőforrásigényes).
2. Felépítés: Saját logikai kód-, adat-, heap (halom)- és stack (verem) memóriaterülettel rendelkezik.
3. Védelem: Az MMU (Memory Management Unit) garantálja, hogy nem férhet hozzá más folyamat memóriájához.
4. Kommunikáció (IPC): Mivel izoláltak, csak lassú, operációs rendszeren keresztüli csatornákon (csövek, socketek) tudnak beszélgetni. Must-know facts:

• A szülő folyamat megkapja a gyermek befejezési visszatérési értékét (integer).
• A Process fa épül ki (Linuxon a ps és pstree parancs mutatja).
• Az izoláció biztonságos, de az erőforrásigény és a kontextusváltás lassú.

---

Szál fogalma, tulajdonságai/értékelése, szálak támogatása OS-ekben

Mi ez? A szál (Thread) egy pehelysúlyú folyamat (lightweight process), a processzor-használat alapértelmezett egysége. (Analógia: A normál Java Thread, ami egy alkalmazáson belül fut, megosztva a memóriát). Hogyan működik? Egy folyamaton belül jönnek létre. Megosztják a kód, az adat, a heap memóriaterületet és a nyitott erőforrásokat (fájl leírók). Viszont a párhuzamos futás érdekében minden szálnak saját virtuális CPU-ja és saját verem (stack) memóriája van. Must-know facts:

• Kb. egy nagyságrenddel gyorsabb a létrehozásuk és megszüntetésük, mint a folyamatoké.
• Az azonos kontextusban futó szálak a közös memórián át villámgyorsan kommunikálnak.
• Veszély: A közös memória miatt szinkronizáció (mutex) kell, különben versenyhelyzet (race condition) lép fel.
• Linux alatt a szálakra és folyamatokra egyaránt a task fogalmat használja az ütemező.

---

Folyamat és szál összehasonlítása

Mi ez? A nehézsúlyú izolált entitás (Folyamat) áll szemben a könnyűsúlyú, memóriát megosztó entitással (Szál).

Must-know facts:

• Folyamat: Biztonságos MMU alapú szeparáció, nehézkes kontextusváltás, lassú IPC.
• Szál: Gyors kontextusváltás, gyors kommunikáció a megosztott HEAP-en keresztül, de csak a STACK (verem) specifikus, a többi memóriaterület osztott. Cserébe a programozónak kell a védelemről (lockok) gondoskodni.

---

Ütemezés, ütemezés időskálái

Mi ez? Annak eldöntése, hogy a CPU-ért versengő feladatok közül adott pillanatban melyik kapja meg a processzort. Három idősíkja van, amelyek eltérő problémákat oldanak meg. Hogyan működik?

1. Rövid távú (CPU ütemezés): Milliszekundumonként fut, kiválasztja a “Futásra kész” listából a soron következőt.
2. Középtávú (Swapping): Ha elfogy a fizikai RAM, a tétlen feladatokat kiírja a háttértárra, hogy helyet csináljon.
3. Hosszú távú: Feladatok időzített indítása (pl. cron, systemd). Must-know facts:

• Valós-idejű (beágyazott) rendszerekben a Swapping (középtávú ütemezés) tilos, mert a flash memóriát (eMMC, SD) tönkreteszi, és az időzítés kiszámíthatatlanná válik tőle.
• Az általános CPU ütemezés során a futásra kész lista keresése algoritmus szinten NP-teljes probléma.

---

Ütemező választás, Linux ütemezés, valós-idejű ütemezési osztályok Linux-ban

Mi ez? Nincs univerzális “legjobb” ütemező, az algoritmust a feladathoz kell igazítani. A Linuxban több ütemezési osztály (policy) létezik párhuzamosan, hierarchikus rendszerben. Hogyan működik? A kernel a feladatokat osztályokba sorolja. A prioritás növekvő sorrendjében a legfontosabb osztályok:

1. SCHED_OTHER: A normál asztali/szerver feladatok. (2007-től a CFS - Completely Fair Scheduler kezelte, a 6.12-es kerneltől az EEVDF váltja le).
2. SCHED_RR: Valós-idejű Round-Robin (időszeleteléses azonos prioritáson).
3. SCHED_FIFO: Valós-idejű First-In-First-Out (addig fut, amíg önként át nem adja a CPU-t, vagy jön egy még magasabb prioritású).
4. SCHED_DEADLINE: Valós-idejű Earliest Deadline First (mindig az fut, aminek legközelebb van a határideje). Must-know facts:

• A SCHED_DEADLINE tipikusan nincs alapból befordítva a Linux kernelbe.
• A modern nem-RT Linux ütemező (6.12-es verziótól) az EEVDF (Earliest Eligible Virtual Deadline First).
• A SCHED_OTHER (normál Linux) nem garantál válaszidőt.

---

Preempt-RT patch és szerepe a valós-idejű ütemezésben

Mi ez? Egy kódszintű módosítás (patch), amely a hagyományos Linux kernelt Hard Real-Time (kőkemény valós-idejű) kernellé alakítja azáltal, hogy a kernel belső folyamatait is megszakíthatóvá (preemptable) teszi. Hogyan működik? Normál esetben, ha a Linux kernel épp egy rendszerhívást szolgál ki, egy magas prioritású RT szál nem tudja azonnal elvenni tőle a CPU-t. A Preempt-RT megszakítási pontokat tesz a kernelkódba, így a magas prioritású taszk késleltetése (latency) drasztikusan csökken. Ezzel egyidejűleg a sok kontextusváltás miatt a teljes rendszer áteresztőképessége (throughput) romlik. Must-know facts:

• Optimalizációs trade-off: Áteresztőképesség (throughput) VS Késleltetés (latency) minimalizálása.
• A 6.12-es Linux kerneltől kezdve bekerült a hivatalos kódba (mainline), így már nem kell patchelni, csak kernel konfigurációból bekapcsolni.

---

Többprocesszoros ütemezés, processzor affinitás, terhelés megosztás

Mi ez? Többmagos processzorokon a szálak elosztásának és a CPU gyorsítótárak (CACHE) kihasználásának optimalizálása. (Analógia: ha egy szakács megszokta a saját konyháját, lassabb lesz, ha átteszed egy másik étterembe, mert ott újra ki kell pakolnia az eszközöket). Hogyan működik?

• Processzor affinitás: Annak kikényszerítése/preferálása, hogy egy feladat mindig ugyanazon a CPU magon fusson. Laza (Soft - az OS törekszik rá) vagy Kemény (Hard - rendszerhívással dedikálva).
• Ha egy szál más magra vándorol, elveszíti a lokális CACHE tartalmát, újra kell építenie (lassulás).
• Load balancing: Push (OS kényszeríti át a feladatot egy másik mag sorába) vagy Pull (az üresjáratban lévő, Idle CPU mag maga húz át feladatot a túlterhelt magoktól). Must-know facts:
• NUMA architektúra esetén a CPU affinitás mellett az adott CPU-hoz közeli fizikai memória használata is kritikus a sebességhez.
• A big.LITTLE (heterogén ARM) processzoroknál az ütemezőnek tudnia kell, melyik magnak milyen a fogyasztása/teljesítménye.

---

Lehetőségek a Linux ütemező befolyásolására

Mi ez? Külső beavatkozás egy folyamat ütemezési prioritásába vagy a használt CPU magba, akár a program forráskódjának megváltoztatása nélkül. Hogyan működik? A Linux shellből különböző parancsokkal nyúlhatunk az ütemezőhöz.

• nice: Klasszikus programok alap prioritásának állítása.
• chrt: Egy folyamat valós-idejű osztályba (pl. SCHED_FIFO) rakása. Nem kell hozzá a kód átírása.
• taskset: Processzor affinitás beállítása CLI-ből (adott CPU magra pányvázás). Must-know facts:
• Az RT ütemezési osztályok (SCHED_FIFO, stb.) és az affinitás programozott (rendszerhívás) állításához Root jogosultság szükséges.
• Rendszerhívás szinten az affinitást a sched_setaffinity hívással lehet beállítani C kódból.

---

Időkezelés a kernelben, virtuális/SW timer felépítése és tulajdonságai

Mi ez? A szoftveres várakoztatás (pl. sleep() timeoutok) mögötti mechanizmus az operációs rendszerben. Hogyan működik?

1. A hardveres timer periodikusan megszakításokat (system tick / Linuxban jiffies) generál (alapból pl. 4 ms-enként).
2. Amikor meghívsz egy sleep-et, az OS kiszámolja a futási időpontot (Aktuális idő + Várakozás), és beteszi a feladatot egy futási időpont szerint sorba rendezett láncolt listába.
3. Minden hardveres tick megszakításkor a kernel csak a lista legelejét nézi meg. Ha a megadott idő eltelt, a taszk visszakerül a “Futásra kész” állapotba. Must-know facts:

• A legkisebb mérhető/időzíthető egységet a megszakítás gyakorisága adja meg (kvantálási hiba).
• A taszk a kért idő után csak futásra kész állapotba kerül, hogy mikor kapja meg valójában a CPU-t, az már a processzor ütemezőjétől függ. (A várakozás sosem lesz kevesebb a kértnél, de lehet több).

---

Nagyfelbontású időmérés lehetőségei, a Tickless kernel alapötlete

Mi ez? Két dolog: hogyan mérjünk nanoszekundum pontossággal időt a 4ms-es timer tick ellenére, illetve hogyan spóroljon energiát a kernel, ha épp nincs dolga. Hogyan működik?

• Időmérés: A CPU tartalmaz egy belső 64-bites számlálót (Timestamp Counter, TSC). Ez a bekapcsolás óta eltelt CPU órajel-impulzusokat számolja, függetlenül a külső tickektől, így nanoszekundumos pontosságú lekérdezést ad.
• Tickless kernel: Alacsony terhelésnél a folyamatos 4ms-es megszakítások “felébresztik” a CPU-t, fogyasztva az akkut. A tickless kernel kikapcsolja a periodikus óraütést üresjáratban (Idle állapot), és csak külső eseményre (pl. hálózati csomag, UI érintés, beállított HW timer lejárt) ébred fel. Must-know facts:
• A Tickless kernel elsődleges célja a fogyasztás csökkentése alacsony átlagos terhelésnél (pl. okostelefonoknál kritikus).
• Nanoszekundumos felbontású méréshez a Timestamp Counter (TSC) regisztert olvassák ki.

---

Versenyhelyzet és definíciója, Kiéheztetés és definíciója

Mi ez? Két klasszikus többszálú programozási hiba, amelyek a nem megfelelő erőforrás-megosztásból erednek. Definíciók:

• Versenyhelyzet (Race condition): A párhuzamos program lefutása során a közös erőforrás védelem nélküli használata miatt a kimeneti állapot attól függ, hogy az operációs rendszer ütemezője milyen véletlenszerű sorrendben hajtja végre a szálak utasításait.
• Kiéheztetés (Starvation): Egy futásra kész feladat soha nem jut hozzá a szükséges CPU-időhöz vagy egyéb erőforráshoz (pl. mert a magasabb prioritású taszkok folyamatosan kisajátítják azokat). Must-know facts:
• A versenyhelyzet teljesen eltér a klasszikus hibáktól, mert azonos bemenetre is másként viselkedik (nehezen, csak statisztikailag reprodukálható, időzítéstől függő “Heisenbug”).
• Minden párhuzamos programozási hiba (holtpont stb.) valamilyen szinten versenyhelyzetre vezethető vissza.

---

Holtpont (deadlock) és livelock

Mi ez? A rendszer blokkolódásának két típusa, amikor a feladatok várnak egymásra. (Analógia: Te beviszed a kulcsot, a haverod beviszi a zárat, és mindketten a másikra vártok, hogy nyisson). Hogyan működik?

• Deadlock (Holtpont): Az A feladat lefoglalja az X erőforrást és kéri Y-t. A B feladat lefoglalja az Y erőforrást és kéri X-et. Végtelen blokkolás.
• Livelock: Ha beállítunk egy timeoutot a deadlockra: mindketten elengedik a saját erőforrásukat, majd pontosan egyszerre újra megpróbálják lefoglalni. Folyamatosan dolgoznak, pörög a CPU, de hasznos munka nem történik. (Két ember próbálja kerülgetni egymást az ajtóban, mindig ugyanabba az irányba lépve). Must-know facts:
• Holtpont esetén a rendszerben lévő érintett halmazban nincs futásra kész folyamat, a rendszer nem tud előrelépni, ami egy beágyazott rendszer lefagyását jelenti.
• A livelock többnyire a hibás holtpont-feloldás (kölcsönös kizárás + timeout) eredménye.
• Egyszerű elkerülés: Az erőforrásokat mindig azonos sorrendben kell lefoglalni.

---

Prioritás inverzió és elkerülése, prioritás öröklés és prioritás plafon és működésük

Mi ez? Speciális valós-idejű hiba, amikor egy Alacsony prioritású (L) szál birtokol egy Mutexet, amit a Magas prioritású (H) szál kérne. Közben egy Közepes prioritású (M) CPU-intenzív szál elkezd futni, megszakítva az L-t. Végeredmény: A közepes prioritású feladat blokkolja a legmagasabb prioritásút! (Mars Pathfinder, 1997).

Hogyan oldjuk meg:

• Prioritás öröklés (Priority Inheritance - PI): Ha H vár az R erőforrásra, amit L fog, akkor L dinamikusan, futás közben megörököli H prioritását. Így M már nem tudja L-t elpreemptálni, L gyorsan végez és odaadja a Mutexet H-nak.
• Prioritás plafon (Priority Ceiling - PC): Minden erőforrásnak adnak egy statikus (fordítási időben eldöntött) plafon prioritást (ez egyenlő a legmagasabb prioritású száléval, ami valaha fogja). Ha bárki megfogja a Mutexet, azonnal megkapja ezt a plafon prioritást. Must-know facts:
• A Prioritás inverzió kiéheztetést vagy akár holtpontot is okozhat (Mars Pathfinder reset-eket okozott a Marson).
• A PI futási idejű dinamikus algoritmus, a PC pedig fordítási idejű (paraméter megadást igényel).
• Modern beágyazott OS-ekben a fejlesztő választhat a preemptív ütemezőhöz None, PI vagy PC megoldások közül.

---

PIN azonosítók (Ball number, Signal ID, GPIO PIN ID, CAPE ID)

Mi ez? Egy SoC-on (System on Chip, pl. BeagleBone) a kivezetések sokféleképpen címezhetőek attól függően, hogy a NYÁK tervező, a chip gyártó, vagy a szoftveres nézőpontját vizsgáljuk. Hogyan működik?

• Ball number: Hardveres BGA tokozás koordinátája (pl. A1 oszlop/sor).
• Signal ID / GPIO PIN ID: Szoftveres azonosító, pl. gpio 2.05 vagy lineárisan számolva GPIO69 (mert 2 * 32 + 5 = 69).
• CAPE ID: A fejlesztőlapon (pl. BeagleBone) a műanyag csatlakozó sorának fizikai érintkező száma (pl. P8_19 vagy P9_12). Must-know facts:
• Egy fizikai kivezetésnek (PIN) maximum 8 különböző funkciója (MUX) lehet bekonfigurálva (pl. I2C, SPI, PWM, stb.).
• Reset után az alapértelmezett funkció tipikusan a 7-es, ami a standard GPIO mód. Ilyenkor a lábak védelmi okokból magas impedanciájú bemenetként (input pullup/pulldown) indulnak.
• Minden szoftverkörnyezet (sysfs, chardev, libgpiod) a saját stílusában kéri az azonosítót.

---

GPIO elérés sysfs felhasználásával SHELL scriptben és C programban

Mi ez? A Linux Virtual File System architektúrája, ahol a hardvereket fájlokként mutatja. A /sys/class/gpio mappában fájl műveletekkel (írás/olvasás) lehet pineket billegtetni. (Analógia: Mintha az analogWrite() helyett egy .txt fájlba írnál be egy 1-est). Hogyan működik?

1. Export: Láb átadása a user-space-nek (echo 60 > /sys/class/gpio/export). Ez létrehozza a gpio60 mappát.
2. Direction: Irány beállítása (echo out > direction vagy echo in > direction).
3. Value: Érték megadása Shellből (echo 1 > value), vagy C programból a fájl megnyitásával (fopen, majd fprintf(fp, "1")). Must-know facts:

• Platform és nyelv független megoldás (minden nyelv tud fájlba írni).
• Mára elavultnak számít, mert a modern (4.8-as kerneltől) támogatott megoldás a chardev (karakteres eszköz alapú elérés).
• A sysfs problémás, ha több GPIO-t használó program próbál egyidejű erőforrásokat kezelni.

---

A bufferelés hatása, fflush() rendszerhívás

Mi ez? Amikor C programból (pl. standard I/O fprintf függvénnyel) írunk a value fájlba a LED felkapcsolásához, a libc operációs rendszer alapértelmezetten a RAM-ban gyűjti (buffereli) a karaktereket a gyorsaság érdekében, és nem küldi el azonnal a hardvernek. Hogyan működik? Bár az fprintf(fp, "1"); lefutott, a file-ba ténylegesen még nem íródott be semmi, a LED nem gyullad ki. A puffert üríteni kell az OS felé. Must-know facts:

• Ha C-ből sysfs alapon vezérlünk GPIO-t, az írás után kötelező meghívni az fflush(fp) függvényt, különben az OS bufferelése miatt a hardveres láb állapota nem (vagy csak később) fog megváltozni.

---

Várakozás: sleep(), usleep() és nanosleep() rendszerhívások

Mi ez? Rendszerhívások a folyamat/szál elaltatására (blokkolására) adott másodperc (sleep), mikroszekundum (usleep) vagy nanoszekundum (nanosleep) értékig. (Lásd előadás: virtuális timer). Hogyan működik? Amikor meghívod a függvényt, az OS kiveszi a száladat a CPU-ból (“Futásra kész” állapotból várakozóba teszi), elmenti a lejárati időpontot, és futtat helyette mást. A timer megszakítás visszarakja a ready sorba, ha az idő letelt. Must-know facts:

• Ezek a hívások lemondanak a CPU-ról (nem aktív várakozást “busy waiting” valósítanak meg, hanem sleep-elnek).
• A megadott idő csak a minimális garantált várakozási idő, a valós visszatérés az ütemező (scheduler) kvantálási hibája miatt kicsivel több lesz.

---

A Bluetooth Low Energy (BLE) alkalmazási környezete, célja

Mi ez? Egy vezeték nélküli kommunikációs protokoll, amelyet kifejezetten elemes, alacsony fogyasztású szenzorok és beavatkozók okostelefonokhoz (vagy más központokhoz) való csatlakoztatására terveztek. Olyan, mint a Wi-Fi-n futó REST API, de mikrowattos nagyságrendű fogyasztásra és “készenlétből gyors felébredés, pici adat küldése, majd visszaalvás” ciklusokra optimalizálva.

Hogyan működik? Automatikusan képes működni: az eszközök hirdetik magukat (Advertising), a telefon előzetes tudás nélkül fel ismeri az elérhető eszközöket, letölti a szükséges információkat és használatba veszi őket.

Must-know facts:

• Eredete: 2001-ben kezdődött a Nokia Wibree projektjeként, a Bluetooth SIG később vette át.
• Verziók: Bluetooth Smart (2009), Bluetooth 4.0 része lett (2010), BLE néven Bluetooth 5 (2016).
• Profilok: Léteznek szabványosak (egészségügyi, HID, világítás) és egyedi profilok. (Gyakori vizsgakérdés csapda: “Csak szabványos profilokkal működhet” -> HAMIS, bármikor építhető egyedi protokoll).

---

A BLE alaptulajdonságai

Mi ez? A BLE fizikai és hálózati rétegének specifikációja.

Hogyan működik? A 2.4 GHz-es ISM sávot használja, dedikált mechanizmusokkal a Wi-Fi hálózatokkal való együttélésre (coexistence). Kis áramfogyasztással (kb. 30 mA kommunikáció közben) és extrém gyors felébredési/elalvási időkkel operál.

Must-know facts:

• Sávszélesség: $125 \text{ kbit/s} - 2 \text{ Mbit/s}$. (Nem alkalmas videostreamingre!).
• GAP (Generic Access Profile): A szolgáltatások hirdetéséért és megtalálásáért felel.
• Címzés: 48 bites egyedi Bluetooth MAC cím (hasonló az Ethernet MAC-hez).
• RSSI (Receive Signal Strength Indicator): Távolságfüggő jelerősség. Fontos: negatív érték, minél közelebb van a 0-hoz, annál erősebb (-20 dBm erősebb, mint -40 dBm).

---

A Generic Attribute Profile (GATT) és a GATT tranzakciók

Mi ez? A BLE adatmodellje és kommunikációs struktúrája. Hardveresen egy Master-Slave, szoftveresen egy Kliens-Szerver modell (hasonló egy REST JSON payload struktúrához, csak binárisan és fába rendezve).

Hogyan működik?

A periféria (szenzor) a GATT Szerver, amely az adatokat (Characteristics) tárolja Szolgáltatásokba (Services) csoportosítva. A központi eszköz (telefon) a GATT Kliens, ami ezeket olvassa/írja.

Must-know facts:

• Szerepkörök: Kliens = Nagyteljesítményű (okostelefon, master). Szerver = Kisteljesítményű (szenzor/periféria, slave).
• Tranzakció iniciálás: MINDEN tranzakciót a kliens (master) kezdeményez! A szerver csak kiszolgál.
• Topológia:
• Kapcsolat alapú (Connected): Általános használat, telefon és okosóra között.
• Üzenetszórás alapú (Broadcast): Pl. Apple AirTag (Beacon-ök). A periféria csak ad, bárki veheti (jelenlét + RSSI alapján lokalizáció).
• UUID (Azonosítók):
• 16 bites UUID: Szabványos, Bluetooth SIG által definiált profilokhoz.
• 128 bites UUID: Egyedi, saját fejlesztésű profilokhoz.

---

BLE HW és SW működési modellek, Standalone, NCP és RCP működés

Mi ez? A BLE protokoll stack (rádióvezérlő, link layer, host stack, alkalmazás) fizikai mikrokontrollereken való elosztásának architekturális modelljei.

Hogyan működik? Attól függően, hogy az adott eszközben mennyi számítási kapacitás van, a BLE stack különböző rétegeit leválaszthatjuk a fő processzorról (AP) egy dedikált rádiós mikrokontrollerre (MCU).

Must-know facts:

• Standalone (Egyedülálló): Minden (alkalmazás, GATT, link layer) egyetlen rádiós MCU-n fut. Legolcsóbb, egyszerű szenzoroknál használják.
• NCP (Network Co-Processor): A teljes BLE stack (Host + Controller) a rádiós MCU-n fut. Az üzleti logika (Alkalmazás) egy másik chipen (AP). Kommunikáció: API hívásokkal (pl. UART-on). Tipikus meglévő, buta rendszerek utólagos felokosításánál.
• RCP (Radio Co-Processor): Csak az alacsony szintű link-layer (Controller) fut a rádiós chipes. A teljes BLE protokoll stack és az app a Host processzoron fut (HCI - Host Controller Interface segítségével). Tipikus: Laptopok, okostelefonok.

---

GPIO PIN-ek használata

Mi ez? A mikrokontroller lábainak (PIN) konfigurálása. A BeagleBone Black-en (BBB) egy fizikai lábnak több hardveres funkciója is lehet (multiplexelés), az Arduino egyszerű pinMode-jához képest ez operációs rendszer szintű (devicetree) beállítást igényel.

Hogyan működik? A lábak belső kapcsolómátrixon keresztül köthetők be A/D konverterre, memóriabuszra, PRU-ra vagy sima GPIO-ra (General Purpose I/O).

Must-know facts:

• Funkciók száma: Egy PIN-nek maximum 8 funkciója (0-7) lehet. (Többnyire a 7-es funkció a standard GPIO).
• Reset utáni alapállapot: Többnyire magas impedanciájú bemenet (input), pullup vagy pulldown ellenállással. (Biztonsági okokból, nehogy rövidzárlat legyen).
• A BBB-ben 4 db 32 bites gpiochip van (0-tól 3-ig). A gpiochip0 mindig kap tápot, az alvó rendszer felébresztéséhez ide kell kötni a gombot.

---

A gpioinfo és show-pins programok szerepe

Mi ez? Linux parancssori eszközök, amikkel le lehet kérdezni, hogy az adott fizikai láb éppen milyen funkcióra van konfigurálva az operációs rendszerben.

Hogyan működik?

• gpioinfo: Generikus Linux eszköz (chardev alapú). Megmutatja gpiochip-enként az összes vonalat (line), nevüket, funkciójukat (input/output), polaritásukat (active-high/low) és hogy használatban vannak-e ([used]/unused).
• show-pins: TI (Texas Instruments) és BeagleBone specifikus script. Közvetlenül a processzor regisztereit (pinmux) olvassa ki.

Must-know facts:

• A show-pins | less parancs eltörik a színes karakterkódok miatt, helyette a show-pins | less -R vagy show-pins | more a helyes használat.

---

GPIO használata bemenetként, az lseek() rendszerhívás szerepe

Mi ez? Linux alatt “minden fájl”. A GPIO bemenetet a sysfs fájlrendszeren keresztül, egy sima szöveges fájl (pl. /sys/class/gpio/gpio67/value) olvasásával tudjuk lekérdezni (0 vagy 1).

Hogyan működik? Amikor C kódból kiolvassuk a fájlt (read), a fájlmutató (file pointer) a fájl végére lép. Ha újra ki akarjuk olvasni a gomb állapotát, nem elég újra meghívni a read-et, mert a fájl végén vagyunk (EOF).

Must-know facts:

• lseek() kötelezőség: Olvasás után vissza kell állítani a fájlmutatót az elejére!
• Helyes hívás: lseek(fd, 0, SEEK_SET); (Ezt vizsgán imádják kérdezni, mert e nélkül a sysfs GPIO olvasó végtelen ciklus beragad).

---

Folyamatos lekérdezés, időzített lekérdezés hatása a rendszerteljesítményre

Mi ez? A gomb állapotának vizsgálata szoftveresen (polling).

Hogyan működik? Ha egy while(1) ciklusban várakozás nélkül folyamatosan olvassuk a GPIO-t (Busy waiting), az az adott CPU magot 100%-osan leterheli, nem hagyva időt más taszkoknak.

Must-know facts:

• Delay fv-ek: sleep(), usleep(), nanosleep() beiktatásával drasztikusan csökken a CPU terhelés, de a blokkolás miatt megnő a rendszer reakcióideje (latency). Ha közben érkezik egy POSIX signal, az megszakíthatja a sleep hívást.
• Időmérés: Az aktuális időt a time() (másodperc felbontás) vagy a precízebb clock_gettime(CLOCK_MONOTONIC_RAW, ...) rendszerhívással kérdezzük le.

---

A poll() rendszerhívás használata és megszakítás-alapú bemenet kezelés

Mi ez? Hardveres megszakításra (interrupt) épülő, eseményvezérelt IO kezelés a Linux user space-ben. Pontosan olyan, mint a Java NIO multiplexingje. Ahelyett, hogy a CPU folyamatosan kérdezgetné a lábat (polling), az OS elaltatja a programot, és csak akkor ébreszti fel, ha történt valami.

Hogyan működik?

1. Sysfs-ben beállítjuk, hogy mire kérünk megszakítást: echo 'both' > /sys/class/gpio/gpio67/edge (Értékek: none, rising, falling, both).
2. Létrehozunk egy pollfd struktúra tömböt a figyelt fájlleírókkal.
3. Meghívjuk a poll() függvényt, ami blokkol a megadott timeoutig, vagy amíg esemény nem történik.

Must-know facts:

• A poll() visszatérési értéke:
• -1: Hiba történt.
• 0: Timeout (letelt az idő, nem volt esemény).
• > 0: A kezelhető (eseményt jelző) fájldeszkriptorok száma.
• Miért jobb a poll(), mint a select()? A select() programozási felülete archaikus, a poll() egyszerűbb és hatékonyabb POSIX szabvány. (A Linux-specifikus epoll() még jobb lenne, de a poll() portábilis).
• Architektúra: Egy poll() alapú rendszer lényegében egy véges automatát (FSM) valósít meg, ideális egymagos, kis memóriájú beágyazott Linux rendszerekbe. Eseménykezeléskor a megírt kezelőfüggvénynek teljesen le kell futnia, mielőtt újra meghívnánk a poll()-t.

---

Út a fizikai vezetéktől a virtuális vezetékig, a virtuális vezeték használatának következményei

Mi ez? Az analóg, dedikált kábelezés (pl. 4-20 mA ipari távadók, mint az Arduino analóg pinjeinél) lecserélése egy közös digitális kommunikációs csatornára (buszra/hálózatra). A fizikai rézdrótokat logikai, “virtuális” kapcsolatok váltják fel, ahogy a dedikált kábelekről áttérünk pl. egy I2C-szerű megosztott hálózatra.

Hogyan működik? Több szenzor és beavatkozó jeleit digitálisan “bekódolva” egyetlen vezetékpáron multiplexálják. Az adatok csomagokban utaznak a hálózaton keresztül a célállomások felé.

Must-know facts:

• Előnyök: Kevesebb vezeték, flexibilis architektúra, nagyobb védettség az analóg zavarokkal szemben.
• Hátrányok (következmények): Megjelenik a késleltetés és a késleltetés-ingadozás (jitter).
• A valós idejűség (real-time) kérdésessé válik.
• Nő az adatvesztés és a túlterhelés (packet drop) valószínűsége.

---

A hálózat feladata a beágyazott rendszerben, követelmények

Mi ez? A hálózat fő célja az elosztott beágyazott rendszerekben az állapotinformációk (state replication) másolása a végpontok között. Hasonló egy multiplayer játék netcode-jához, ahol minden kliensnek tudnia kell a pontos globális állapotot, csak itt anyagi kár vagy baleset a tét, ha nagy a “lag”.

Hogyan működik? A szenzorok mérései és a számított adatok meghatározzák a rendszer állapotát egy adott időpontban (State replication scheme). Ezt az állapotot juttatja el a hálózat minden olyan végponthoz (pl. beavatkozókhoz), ahol szükség van rá.

Must-know facts:

• A legfőbb feladat: Állapotinformáció “lemásolása” a rendszer minden szükséges végpontjában.
• A késleltetés (lag) kritikus tényező, determinisztikusnak kell lennie.

---

Vezetékes Ethernet hálózat minimális késleltetésének számítása

Mi ez? A hálózat végpontjai közötti abszolút minimális idő, ami alatt egy csomag átér. Ez a fizikai kábel késleltetéséből és az aktív eszközök (switch-ek) feldolgozási idejéből (residence time) adódik össze.

Hogyan működik? A csomag elindul a kábelen (fénysebességgel, közegtől függően módosítva), majd megérkezik egy switch-hez. A switch beolvassa, feldolgozza a fejlécet, a belső “switch fabric”-on átirányítja, majd a kimeneti porton kiküldi.

Must-know facts:

• Összes késleltetés = Kábelkésleltetés + Aktív hálózati eszközök késleltetése.

---

Vezeték késleltetésének számítása

Mi ez? A jel terjedési sebessége a fizikai közegben. Fizikai korlát, amit nem lehet szoftverből optimalizálni.

Hogyan működik? Az elektromágneses jel terjedési sebessége vákuumban $\approx 300,000 \text{ km/s}$ ($30 \text{ cm/ns}$). Optikai szálban vagy rézvezetőben ez lassabb.

Must-know facts:

• Terjedési sebesség optikai szálban/rézben: $\approx 200,000 \text{ km/s}$, ami $\approx 20 \text{ cm/ns}$.
• Ökölszabály: $200 \text{ m}$ távolság $\approx 1 \ \mu\text{s}$ késleltetés. (Föld másik oldala pl. Új-Zéland $\approx 100 \text{ ms}$).

---

Aktív eszközök késleltetésének számítása a keretméret és a forgalom figyelembe vételével

Mi ez? A switchek, routerek és tűzfalak által okozott időveszteség. Minél magasabb OSI rétegben (Layer 3, 4, 5) dolgozik az eszköz, annál nagyobb a késleltetés, mert szoftveresen, összetettebben dolgozza fel az adatokat.

Hogyan működik?

1. Ingress (Bemenet): A switch beolvassa a keretet.
2. Feldolgozás: Eljuttatja a kimeneti sorba ($t_{proc}$).
3. Sorban állás: A kimeneti bufferben vár, ha nagy a forgalom.
4. Egress (Kimenet): Kiküldi a keretet a következő eszköz felé.

Must-know facts:

• Minimális bemeneti késleltetés ($t_{ingress}$): $t_{ingress} = \frac{1}{B_{ingress}} \times \text{kerethossz}$, ahol $B_{ingress}$ a sávszélesség bit/sec-ben, a kerethossz bitben értendő.
• Maximális késleltetés: Kialakulhat, ha a kimeneti sorban már várnak csomagok. Függ a kimeneti sor kapacitásától ($C_{egress}$). Max késleltetés $\approx \frac{1}{B_{egress}} \times C_{egress}$.
• Késleltetés csökkentése: A sorbaállás miatti késleltetést úgy lehet elkerülni, ha a kimeneti sor kapacitása sokkal nagyobb a kerethossznál ($C_{egress} \gg \text{kerethossz}$).
• A switch típusa számít: a legtöbb store & forward (vár a teljes csomagra), a cut-through ritkább, de gyorsabb (csak a célt olvassa ki, és egyből küldi tovább).

---

Valós-idejű elosztott rendszerek tipikus kommunikáció igényei

Mi ez? Az RT (real-time) rendszerek előre tervezett, determinisztikus hálózati forgalmat igényelnek, szemben a klasszikus, versengéses Ethernet hálózatokkal.

Hogyan működik? Az idő-kritikus üzenetek statikus, előre kiszámolt ütemezést kapnak a hálózaton. A nem idő-kritikus (best-effort) forgalom (pl. management, logolás, nem RT videó) használhatja a maradék sávszélességet, de soha nem blokkolhatja az RT forgalmat.

Must-know facts:

• Előre ismert kommunikációs igények: Ki, mikor, kinek, mennyi adatot küld, és mi az útvonal legrosszabb esete (WCET hálózati megfelelője).
• Határidőkkel és végrehajtási időkkel kalkulálnak; statikus ütemezéssel biztosítják a feltételek teljesülését.

---

Esemény-vezérelt és idő-vezérelt rendszerek és összehasonlításuk

Mi ez? Két alapvető architekturális megközelítés az adatok küldésére. Az Esemény-vezérelt (Event-triggered, ET) olyan, mint egy Arduino megszakítás (interrupt) vagy egy aszinkron Message Broker: csak akkor küld, ha változás van. Az Idő-vezérelt (Time-triggered, TT) olyan, mint egy cron job (@Scheduled Springben): fix időközönként küldi az aktuális állapotot, függetlenül attól, hogy változott-e.

Hogyan működik?

• TT: Minden eszköznek van egy szinkronizált, globális órája. Pontosan tudják, mikor kell adatot küldeniük és fogadniuk.
• ET: Ha megváltozik az állapot (pl. ajtó kinyílik), a rendszer küld egy üzenetet a változásról.

Must-know facts:

• Idő-vezérelt (TT): Ha kimarad egy csomag, a vevő tudja, mert időre kellett volna érkeznie. A rendszer konzisztens marad (tudja, hogy hiba van), valós-idejű, biztonságkritikus működés garantálható.
• Esemény-vezérelt (ET): Ha elvész egy csomag, a vevő nem is tud róla, hogy jönnie kellett volna. Az állapot inkonzisztens lesz. Hibák esetén a valós-idejű működés nem garantálható.

---

Vezetékes és vezeték-nélküli rendszerek tulajdonságainak összehasonlítása

Mi ez? A kábelezett (Ethernet, terepbuszok) és az RF alapú (Wi-Fi, Bluetooth, ZigBee) kommunikáció szembeállítása biztonságkritikus környezetben.

Hogyan működik? A vezetéknélküli hálózatok (főleg a szabadon használható ISM sávokban, mint a 2.4GHz) közös, fizikailag nem elszeparált csatornát használnak, amihez bárki hozzáférhet.

Must-know facts:

• Vezeték nélküli csatorna esetén nincs kontroll a közeg felett.
• Bárki, bármikor zavarhatja (véletlenül pl. mikrohullámú sütővel, vagy tudatosan jamming/spoofing támadással).
• Biztonságkritikus (valós-idejű) architekturába vezetékes megoldás javasolt. Ha mégis wireless kell, ISM helyett fizetős, licencelt frekvenciasávokat kell használni a garanciák miatt.

---

TCP és UDP összehasonlítása

Mi ez? A szállítási réteg protokolljai. A TCP egy megbízható, de overhead-nehéz protokoll (mint a blokkoló REST API hívás retry-okkal), míg az UDP egy “fire-and-forget” csomagalapú protokoll (mint egy aszinkron UDP log vagy pub/sub event).

Hogyan működik? A TCP felépít egy kapcsolatot, és garantálja a sorrendiséget és a megérkezést (ha kell, újra küld). Az UDP csak rábízza a hálózatra a csomagot, nyugtázás nélkül.

Must-know facts:

• TCP: Kapcsolatorientált, megbízható, csak Unicast, van folyamszabályozás, erőforrásigényes. Késleltetése ingadozik (újraadás miatt), ezért BIZTOSAN NEM KÉPES valós-idejű működésre!
• UDP: Üzenetorientált, nem megbízható, de támogatja a Multicast/Broadcast (állapot replikációhoz tökéletes). Egyszerű, nincs újraadás. Kiszámíthatóbb késleltetése miatt KÉPES LEHET valós-idejű működésre.

---

Ethernet és TCP/IP alapú ipari kommunikációs megoldások problémái

Mi ez? A standard Ethernet (IEEE 802.3) és TCP/IP protokollok irodai környezetre (best-effort) lettek tervezve, nem determinisztikusak. Ipari környezetbe implementálva kihívásokba ütköznek.

Hogyan működik? Az iparág gyártói elkezdték a saját hardveres és szoftveres módosításaikat (hack-eket) ráépíteni az Ethernetre, hogy valós-idejűvé tegyék, ami fragmentált, heterogén rendszerekhez vezetett.

Must-know facts:

• Szabványosítás hiánya: Rengeteg gyártóspecifikus, inkompatibilis szabvány létezik (pl. Profinet, EtherCAT).
• A klasszikus Ethernet és TCP/IP önmagában (módosítások nélkül) nem alkalmas egységes, valós-idejű integrációs felületnek. A zárt, biztonságkritikus rendszereket csak átjárókkal (gateway) lehet a nyílt hálózathoz kötni.

---

Valós-idejű Ethernet szabványok

Mi ez? Ipari kommunikációs protokollok, amelyek megpróbálják (több-kevesebb sikerrel) az Ethernetet Real-Time (RTE) képességekkel felruházni (IEC 61158 / IEC 61784 szabványok). A vizsgára tudni kell, hogy melyik képes valóban RT működésre.

Must-know facts:

• Modbus/TCP: “Az abszolút dirty hack”. 501-es TCP portot használ kérés-válasz alapon. NEM valós-idejű! (Nincs felső korlátja az üzenettovábbításnak).
• PROFINET IO (Siemens): 100 Mbit/s, három fázisa van. Képes valós-idejű (RT) és Izoszinkron (IRT - HW switch kell hozzá) működésre is.
• SERCOS III: 100 Mbit/s, daisy chain / gyűrű topológia. Külön IP és RT csatornája van, speciális HW/FPGA kell a hatékony megvalósításhoz. Képes valós-idejű működésre.
• TTEthernet (Time-Triggered Ethernet): SAE AS6802 (autó/űripar, pl. NASA). Globális óraszinkronizációt használ (Idő-vezérelt). 3 forgalom típus (Idővezérlet, Sávszél korlátozott, Best effort). Switch-ek védik a hálózatot a hibás node-októl. Képes valós-idejű működésre.

---

Logikai analizátor használata az ütemezés megfigyelésére

Mi ez? A logikai analizátor (pl. Saleae Logic, sigrok) egy olyan hardveres diagnosztikai eszköz, amely digitális jelek (0 és 1) időbeli változását képes mérni és rögzíteni. Olyan, mint egy oszcilloszkóp, de kifejezetten digitális jelszintekre optimalizálva.

Hogyan működik? Készítünk egy végtelen ciklusú (while 1) feladatot (taskot), ami folyamatosan billent (toggle) egy GPIO kimenetet. A logikai analizátorral rámérünk a GPIO lábra, és figyeljük a jel frekvenciáját.

Must-know facts:

• A GPIO kimenet frekvenciája a szoftveres megoldás sebességét mutatja.
• Több GPIO PIN-nel akár több párhuzamos task ütemezése is megfigyelhető.
• Ha a rögzített jelben kimaradások (szünetek) vannak, az megmutatja, mikor vette el az operációs rendszer (OS scheduler) a futási jogot a taskunktól.

---

A programozási környezet és nyelv szerepe az ütemezés során

Mi ez? Az, hogy a fejlesztő milyen technológiát használ (bash script, C kód sysfs-el, C kód mmap-el), drasztikusan befolyásolja, milyen gyorsan és mennyire determinisztikusan fut le a hardveres művelet.

Hogyan működik? Linux alatt a standard (“sysfs”) GPIO hozzáférés (pl. /sys/class/gpio/gpio66/value írása) fájl-I/O műveletnek számít. Ez operációs rendszer szintű pufferelést használ, amit üríteni kell (fflush()), és minden írás rendszerhívást (syscall-t) igényel, ami kontextusváltással jár (lassú).

Must-know facts:

• A fájl/sysfs/chardev alapú elérés (mint a sima Java FileOutputStream vagy C fprintf) nem túl gyors.
• Az OS puffereit manuálisan üríteni kell (fflush(fd)).
• A lassúság fő oka: a folyamatos rendszerhívások (syscalls) végrehajtása az user space és a kernel space között.

---

A chrt program szerepe, felhasználása

Mi ez? A chrt egy Linux parancssori eszköz, amivel a futó processzek valós-idejű (RT) ütemezési szabályait és prioritását lehet lekérdezni és megváltoztatni. Ezzel megkerülhető a Linux alapértelmezett, nem-determinisztikus (Completely Fair Scheduler - CFS) ütemezője. Hasonló a Java Thread.setPriority()-jához, de OS magasságban, POSIX policy-kkel.

Hogyan működik? A parancs módosítja az adott PID-hez tartozó ütemezési osztályt és prioritást valós-idejű FIFO (First-In-First-Out) vagy RR (Round Robin) típusúra.

Must-know facts:

• chrt -m : Lekérdezi az egyes ütemezési osztályokhoz (policy) tartozó minimum/maximum prioritásokat.
• chrt -p PID : Lekérdezi egy futó program aktuális ütemezését.
• Használható RT osztályok: -f / --fifo (FIFO policy), -r / --rr (Round Robin).
• Kritikus hiba lehetőség: Ha egy végtelen ciklusú (pl. CPU terhelő, hog) taskot valós-idejű (SCHED_FIFO) ütemezéssel futtatunk, kizárhatja a többi processzt, és a terminál/rendszer teljesen lefagyhat (“nem életszerű RT terhelés”).

---

Az mmap() alapú GPIO elérés előnyei és hátrányai

Mi ez? Memóriába ágyazott I/O. Rendszerhívások (syscall fájl I/O) helyett a fizikai memória egy darabját (ahol a GPIO regiszterek vannak) egyenesen bemapeljük a saját C programunk virtuális memóriaterületére (a Linux /dev/mem interfészén és az mmap() C függvényen keresztül). Pontosan olyan gyors, mintha mikrokontrolleren (pl. Arduino) közvetlenül a PORTB regisztert írnánk.

Hogyan működik? Kikeressük a processzor Reference Manualjából a GPIO regiszterek (SET/CLEAR) fizikai memóriacímét. A /dev/mem megnyitása után az mmap()-el virtuális címet kérünk rá. Innentől kezdve egy sima C pointer (*ptr = 1) direktben a hardveres PIN-t billenti, a Linux kernel teljes megkerülésével.

Must-know facts:

• Előny: Kifejezetten gyors, mivel nem kell minden írásnál rendszerhívást (syscall) használni.
• Hátrány: Rendszergazdai (root/sudo) jogosultság kell hozzá. (Ha bárki olvashatná a /dev/mem-et, az a teljes rendszermemória tartalmának, pl. jelszavaknak a kiszivárgásához vezetne, óriási biztonsági kockázat).
• Manuális bit-máglyázást igényel: tudni kell a Memory Map szerinti regisztercímeket (SET, CLEAR) a kézikönyvből.

---

Digitális rendszerek órajelei és azok nem ideális voltának következményei

Mi ez? A komplex digitális rendszereket (processzorok, perifériák, hálózatok) vezérlő négyszögjelek (órajelek) a valóságban sosem tökéletesek. Még ha két hálózati csomópont (node) névlegesen azonos frekvenciájú órajellel is rendelkezik, a valóságban fázisuk és frekvenciájuk is eltér. Olyan ez, mint egy elosztott Java mikroszerviz architektúra, ahol minden szerver saját hardveres órával rendelkezik: szinkronizáció nélkül a log-ok sorrendisége (időbélyegek) szétcsúszik.

Hogyan működik? Egy elosztott rendszerben több óratartomány (clock domain) létezik. Amikor az adat egyikből a másikba lép (Clock domain crossing), szinkronizációs problémák léphetnek fel.

1. Két azonos névleges frekvenciájú órajel fázisban és frekvenciában is aprókat ingadozik (jitter).
2. Ha ezek nem tökéletesen csatoltak (Plesiochronous), idővel fáziscsúszás történik.
3. Ennek következménye a hálózati adatátvitelben: időnként hiányzik egy minta, vagy többlet keletkezik (pl. audio/video stream csúszás).

Must-know facts:

• Frekvencia ofszet: Az átlagos frekvencia eltérése a névlegestől.
• Jitter: A frekvencia ingadozása időtartományban (ns/ps/fs szinten).
• Clock domain: A rendszer azon része, ami ugyanarról az órajelről jár.
• Plesiochronous működés: Majdnem, de nem tökéletesen szinkronizált órajelek (névlegesen azonosak, de van lassú fáziscsúszás).

---

Órajel előállítására szolgáló eszközök és azok alapvető tulajdonságai / Oszcillátorok és tulajdonságaik

Mi ez? A hardveres időmérés “szívverését” adó elektronikai komponensek. Minőségi sorrendben: RC/LC köröktől a kvarckristályokon át a méregdrága atomórákig terjed a skála. Arduino-s tapasztalatodból ismerős lehet a 16 MHz-es kristály oszcillátor; ipari rendszerekben ennek hőmérséklet-kompenzált és atomi változatait is használják.

Hogyan működik? Minden oszcillátor valamilyen fizikai rezonanciát alakít át elektromos négyszögjellé. A környezeti hatások (főleg a hőmérséklet) megváltoztatják a rezonátor fizikai méreteit/tulajdonságait, ami frekvencia elcsúszást (drift) okoz. Ezt az elcsúszást vagy passzív/aktív analóg módon (fűtés, kondenzátorok), vagy szoftveresen kompenzálják.

Must-know facts:

• RC/LC oszcillátorok: Olcsók, beépítettek (MCU belső órajele), de nagyon pontatlanok (százalékos hiba), nagy jitter. Maximum soros portra (UART) jók.
• XO (Quartz oszcillátor): Piezoelektromos kristály. Tűrhető ár, 10-100 PPM (Part Per Million) pontosság. Erősen hőmérsékletfüggő (másod/harmadfokú görbe).
• TCXO (Temperature-Compensated XO): Hőmérséklet méréssel (analóg vagy digitális) kompenzálja a kvarc hibáját. Drágább, 0.5-5 PPM pontosság. Kis méret.
• OCXO (Oven Controlled XO): Fűtött, állandó hőmérsékleten tartott kvarc. Drága (50-100 USD), nagy méretű, sokat fogyaszt (1-5W), cserébe nagyon pontos (1-10 PPB - Part Per Billion).
• Atomi oszcillátorok: Cézium (SI másodperc definíciója, $\approx 80$ ns/nap hiba) vagy Rubídium alapú. Legpontosabbak, de extrém drágák és bizonyos időközönként cserélni kell bennük a csövet. Létezik chip méretű is (CSAC/MAC).

---

Az idő mint fizikai mennyiség és a használata / Idő mérése, kalendáriumok és órák

Mi ez? Az idő az az SI alapegység, amely – speciális relativitástól eltekintve – egyenletesen és megszakítás nélkül folyik. A mérnöki gyakorlatban két fő dologra használjuk: események sorrendbe állítására (időbélyegek) és időtartamok mérésére (két időbélyeg különbsége).

Hogyan működik? Az időmérés technikailag két rétegből áll:

1. Fizikai Óra: Oszcillátor (impulzusforrás) + Számláló (számolja a tickeket a bekapcsolás/epoch óta) + Kijelző/Interfész.
2. Kalendárium: Egy konvenció (pl. Gergely naptár), ami ember számára emészthető formára konvertálja a hardveres számláló értékét (év, hónap, nap, óra, perc).

Must-know facts:

• A beágyazott rendszerekben az időfolytonosság kritikus: az idő sosem ugorhat visszafelé (monotonicity), különben az algoritmusok (pl. PID szabályozó deriváló tagja) összeomlanak. (Analógia: Java System.nanoTime() vs System.currentTimeMillis()).
• Óra jellemzői: Stabilitás (frekvencia eltérése), Pontosság (eltérés a referencia UTC/TAI időtől), Felbontás (finomság, pl. milliszekundum vs nanoszekundum).

---

A gyakorlatban használt kalendáriumunk és a UTC, a UTC és a TAI eltérése

Mi ez? A nemzetközi időszabványok. A TAI (Nemzetközi Atomidő) egy szigorúan, megszakítás nélkül monoton növekvő fizikai idő, míg a UTC (Koordinált Világidő) a Föld forgásához igazított, emberi használatra szánt idő.

Hogyan működik? Mivel a Föld forgása lassul, a tisztán atomórákon alapuló TAI idővel elcsúszna a napkeltétől/napnyugtától. Ennek kompenzálására az UTC-be időnként (szabálytalan időközönként) betoldanak egy-egy ún. szökőmásodpercet (leap second). Ilyenkor egy perc kivételesen 61 másodperces lesz (esetleg 59).

Must-know facts:

• TAI: Sosem ugrik, tökéletesen folytonos. (Ideális gépeknek).
• UTC: Jelenleg kb. 37 másodperccel le van maradva a TAI-tól a szökőmásodpercek miatt. Globálisan ezt használják (NTP, hálózatok, logolás).
• Mivel az UTC tartalmazhat “ugrásokat” (szökőmásodperc), a biztonságkritikus gépi szinkronizációnál (pl. PTP) a háttérben TAI-t (vagy saját PTP epoch-ot) érdemes használni, és csak a kijelzéshez számolni az ofszetet.

---

Órák részei, jellemzői, hibái és azok kiküszöbölésének lehetőségei

Mi ez? Egy óra sosem mutatja a tökéletes időt. Vagy rossz kezdőértékkel indult el (offset hiba), vagy gyorsabban/lassabban jár a kelleténél (frekvencia drift). Ha ezt egyszerűen felülírnánk (mint ahogy beállítod a faliórát), az időbeni ugrás szoftveres katasztrófát okozna a node-on.

Hogyan működik?

1. Hiba detektálása: Valamilyen protokollon (NTP/PTP) keresztül megkapjuk a referencia időt.
2. Kiküszöbölés (Óra szervó): Az órát tilos direktben átállítani (üzem közben). Helyette egy szoftveres PID szabályozóval finoman módosítjuk a hardveres oszcillátor/számláló frekvenciáját. Ha az óránk siet, picit lelassítjuk az órajelet (vagy az inkrementálás mértékét), amíg a referencia “utol nem ér” minket.

Must-know facts:

• Sosem állítunk órát ugrásszerűen! A frekvencia-kompenzáció hatására nem sérül a mért idő folytonossága.
• A hiba akkumulálódik: A PPM-ben megadott hardveres gyártási hiba miatt a számláló értéke folyamatosan elcsúszik.

---

Out of band és in band óraszinkronizációs megoldások

Mi ez? Két architektúra arra, hogyan juttassuk el a referenciaidőt az elosztott rendszer node-jaihoz. Out of band esetén egy teljesen külön fizikai hálózatot építünk ki erre a célra. In band esetén a meglévő, adatok továbbítására használt hálózatot (pl. a sima Ethernetet) használjuk az idő szinkronizálására is.

Hogyan működik?

• Out of band: Minden gép kap egy dedikált kábelezést (pl. egy GPS antenna jele, 1 PPS dedikált koax kábel, vagy IRIG időkód generátor). Brutál pontos (10-100 ns hiba), de nagyon drága, nem skálázható és dupla kábelezést igényel.
• In band: A gépek Ethernet/IP hálózaton küldenek egymásnak UDP/Ethernet csomagokat (NTP, PTP protokollal). A fő kihívás a hálózati switchek/routerek okozta késleltetés és aszimmetria kompenzálása.

Must-know facts:

• Out of band példák: GNSS (GPS vevő PPS jellel), DCF77 (rádióóra), IRIG.
• In band példák: NTP, IEEE 1588 (PTP), SyncE.

---

NTP alapötlete, működése

Mi ez? A Network Time Protocol (NTP) egy szoftveres, rétegzett (Stratum) hálózati protokoll (David L. Mills fejlesztette), amit az internetes PC-k óráinak szinkronizálására találtak ki (emberi léptékű használatra).

Hogyan működik? Alapvetően 4 időbélyegből számol (kérés elküldése, kérés fogadása szerveren, válasz küldése szerverről, válasz fogadása). Feltételezi, hogy a hálózati út oda-vissza (késleltetés) tökéletesen szimmetrikus.

$t = \frac{(t_1 - t_0) + (t_2 - t_3)}{2}$

Must-know facts:

• Célpont: WAN, Internet, emberi PC-k (milliszekundumos pontosság).
• Fő hibaforrása: Nem bírja kezelni a hálózati aszimmetriát. A kliens/szerver operációs rendszer ütemezése (SW jitter) és a switchek sorbanállási késleltetése rontja a mérést.
• Hierarchia: Stratum 0 (Atomóra/GPS) -> Stratum 1 (Referencia szerver) -> Stratum 2, stb.

---

IEEE 1588 (PTP) alapötlete, működése

Mi ez? A Precision Time Protocol (IEEE 1588) az NTP ipari/beágyazott változata. Kifejezetten lokális hálózatokra (LAN) és gépek közötti mikroszekundum alatti (szub-ns is elérhető) szinkronizációra tervezték, szoftver helyett hardveres időbélyegzéssel.

Hogyan működik? Kiküszöböli az operációs rendszer (OS) ütemezési hibáit azáltal, hogy a csomagok időbélyegét maga a hálózati kártya hardvere (MAC vagy PHY) rögzíti abban a nanoszekundumban, amikor a csomag az Ethernet kábelre kerül. Egy Master-Slave architektúrában működik.

Must-know facts:

• BMC (Best Master Clock): Algoritmus, ami automatikusan kiválasztja a hálózatban elérhető legpontosabb órát Grandmaster-nek.
• Célja nem az idő ugrásszerű átállítása, hanem az ofszet megadása (a node feladata, hogy PI szabályozóval a hardveres óráját ehhez igazítsa).
• One-step clock: A szinkronizációs üzenet (Sync) maga tartalmazza az elküldés pontos idejét. (Nagyon nehéz hardveresen implementálni, mert menet közben kell módosítani a csomagot és a CRC-t).
• Two-step clock: A Sync csomag kimegy, a HW rögzíti mikor ment ki. Majd egy második, Follow_up csomagban szoftveresen utánküldik a Sync csomag pontos kilépési idejét. (Ez az elterjedtebb).

---

IEEE 1588 időtartománybeli interfésze, Pulse per Second jel szerepe

Mi ez? Hogyan bizonyítjuk, hogy két gép órája tényleg nanoszekundumra együtt jár? Az Ethernet kábelen futó PTP csomagokat szoftverből “kilesni” lassú. Erre való a hardveres PPS (Pulse Per Second) jel.

Hogyan működik? A referencia óra (Master) és a Slave eszköz is rendelkezik egy fizikai tüskével (GPIO láb), amelyen másodpercenként pontosan egyszer kiadnak egy logikai magas jelet. Ha a PTP jól működik (olyan mintha egy “virtuális vezeték” lenne a két gép között), egy oszcilloszkópon nézve a két gép PPS jelének felutó éle tökéletesen fedi egymást.

Must-know facts:

• A PPS (Pulse Per Second) egy hardveres szinkronizációs és validációs jel.
• PTP hálózatok valós pontosságát kizárólag fizikai 1 PPS jelek (vagy hasonló HW események) oszcilloszkópos összehasonlításával lehet mérni (SW alapú mérés az OS latency miatt megbízhatatlan).

---

End-to-end és Peer-to-peer üzenetváltások (PTP)

Mi ez? Két módszer arra, hogy a PTP hogyan mérje meg a hálózati késleltetést (delay) a hálózaton.

Hogyan működik?

• End-to-end (E2E): A Slave közvetlenül a hálózat túlvégén lévő Masternek küld egy Delay_Req (Kérés) üzenetet, amire a Master Delay_Resp (Válasz) üzenettel válaszol. A teljes út késleltetését méri oda-vissza. Nagyon rosszul skálázódik, mert a Masternek minden egyes Slave-et külön ki kell szolgálnia.
• Peer-to-peer (P2P): Minden hálózati eszköz (switch is!) csak a közvetlen fizikai szomszédjával beszélget (Pdelay_Req / Pdelay_Resp). Ebből kiszámolja a kábel késleltetését a szomszédig. A hálózaton végigfutó időbélyeghez egyszerűen minden csomópont hozzáadja a saját szomszéd-késleltetését.

Must-know facts:

• E2E üzenetek: Delay_Req, Delay_Resp.
• P2P üzenetek: Pdelay_Req, Pdelay_Resp, Pdelay_Resp_Follow_Up.
• P2P jobban skálázódik és jobban bírja a hálózati topológia-változásokat (RSTP átkapcsolás), mert a késleltetés mérése lokális, szomszéd-szomszéd alapú.

---

Boundary clock, End-to-end és Peer-to-peer transparent clock

Mi ez? Ezek azok a hálózati Switchek (vagy Routerek), amelyek hardveresen támogatják az IEEE 1588-at, így megakadályozzák, hogy a Switch belső packet-queue-ja tönkretegye az időszinkront.

Hogyan működik?

1. Boundary Clock (BC): Kettévágja a szinkronizációs láncot. A switch egyik portja felülről Slave-ként rászinkronizál a Grandmasterre. Majd a switch belső órája lesz a Master az összes többi lefelé menő porton lévő gép számára. (Idő-átjáró).
2. Transparent Clock (TC): Nem van saját szinkronizált órája a láncban. Úgy tesz, mintha ott se lenne (átlátszó). Viszont leméri, hogy egy adott PTP csomag mennyi időt töltött a Switch belsejében (residence time), és ezt az időt hozzáadja a csomag belsejében lévő CorrectionField-hez kilépéskor.

• E2E TC: Csak a residence time-ot adja hozzá.
• P2P TC: A residence time mellett a szomszédos linkeken mért kábelkésleltetést is hozzáadja az üzenethez.

Must-know facts:

• Ordinary clock: Egy portos végpont (vagy sima Master, vagy sima Slave).
• BC (Boundary Clock): Lánc megszakító, jól skálázható, portonként külön profilokkal is mehet.
• E2E TC és P2P TC órákat (switcheket) tilos keverni egy hálózati domainen belül.
• A hálózati tranziensekre (szakadás/RSTP újraépülés) a P2P TC reagál a legstabilabban, míg az E2E TC-nél tranziens jelenik meg az időben.

---

Hardver időbélyeg rögzítés, időbélyeg formátuma, TAI64N időformátum

Mi ez? Ahhoz, hogy mikroszekundum alatti pontosságot kapjunk, a mikrokontroller Ethernet perifériájának (MAC vagy PHY) automatikusan ki kell olvasnia a belső hardveres órát pontosan abban a nanoszekundumban, amikor a keret kezdete (Start of Frame) kimegy a lábakon.

Hogyan működik? A HW Timestamping unit az Ethernet MAC/PHY rétegében csücsül. Amikor felismer egy PTP Event csomagot (pl. Sync), automatikusan lementi a jelenlegi hardveres számláló értékét. Vételkor (RX) ez egyszerű (csak hozzácsapják a csomaghoz egy pszeudó fejrészben). Küldéskor (TX) bonyolultabb, mert a szoftvernek el kell küldenie a csomagot, majd várnia kell egy megszakításra/regiszterre, hogy visszakapja, mikor ment ki fizikailag.

Must-know facts:

• Csak az Event message típusú üzenetek kapnak időbélyeget (Sync, Delay_Req, Pdelay_Req, Pdelay_Resp).
• A General message üzenetek nem kapnak (Follow_Up, Announce stb).
• TAI64N formátum: Az IEEE 1588 szabványos HW időformátuma.
• 48 bit: Másodpercek (TAI időszabvány szerint).
• 32 bit: Nanoszekundumok ($0 - 999.999.999$).

---

Frekvencia változtatás lehetőségei számítógép órák esetén

Mi ez? Ha tudjuk, hogy a hardveres óránk késik a Grandmasterhez képest, valahogy fel kell gyorsítanunk, de fizikai kvarckristályt nehéz kalapáccsal finomhangolni menet közben.

Hogyan működik? Két fő módszer létezik a hardveren belül:

1. VCO (Feszültségvezérelt oszcillátor) / Analóg PLL: Hardveres analóg áramkör, aminek a frekvenciáját valóban el lehet tolni egy picit egy feszültség/digitális érték állításával. Drága és komplex.
2. Fractional clock rate control (Aritmetikai óra): Teljesen digitális. Az alap fizikai órajel (pl. fix 125 MHz) egy akkumulátor regisztert növel folyamatosan. Szoftverből nem a frekvenciát módosítjuk, hanem azt az inkrementum értéket, amit minden fix órajel ciklusban hozzáadunk az idő számlálóhoz (pl. “ne 8.000 ns-t adj hozzá, hanem 8.001 ns-t órajelenként”).

Must-know facts:

• Az aritmetikai óra (fractional clock rate) a modern mikrokontrollereknél és hálózati kártyáknál (Intel i210) a legelterjedtebb megoldás.
• Az “Increment Attributes Register” segítségével a nem szinkronizált fix hardveres órajelből tökéletesen vezérelhető, szinkronizált szoftveres-hardveres idő állítható elő.

---

SyncE alapötlete

Mi ez? A Synchronous Ethernet (SyncE) a távközlési világból (SDH hálózatok) átvett megoldás, amely a hálózati eszközök fizikai rétegű (PHY) órajel-frekvenciáját szinkronizálja. Fontos különbség: a SyncE csak frekvenciát (a másodperc hosszát/ütemét) visz át, nem visz át konkrét időbélyeget (Time of Day - ToD). Olyan, mintha a mikroszervizek processzorai tökéletesen azonos sebességgel ketyegnének, de nem tudnák, hány óra van.

Hogyan működik? Normál esetben minden hálózati kártya a saját lokális kvarc oszcillátorát használja (pl. ±25 PPM hibával) az adatok kiküldésére. SyncE esetén az eszköz a beérkező adatfolyamból (RX bitstream) nyeri ki az órajelet, azt egy speciális PLL-lel (Phase-Locked Loop) megtisztítja a jittertől, és ezt az órajelet használja a saját adásához (TX) is. Így az egész hálózat egyetlen precíz központi órajelre (Primary Reference Clock - PRC) van felfűzve.

Must-know facts:

• Csak frekvenciát szinkronizál, abszolút időt (Time of Day) NEM! (Gyakran PTP-vel együtt használják, ahol a SyncE adja a stabil frekvenciát, a PTP pedig az időt).
• SSM (Synchronization Status Message): Szoftveres üzenetek a hálózaton, amik jelzik az órajel minőségét és eredetét (visszavezethetőség biztosítása, hurkok elkerülése).
• Kifejezetten telekommunikációs (Telco) gyökerű (ITU-T G.8261/8262).
• Optikai linkeken az EMC (elektromágneses zavar) nem probléma, így a frekvencia nagyon stabilan átvihető.

---

White Rabbit alapötlete és tulajdonságai

Mi ez? A White Rabbit (WR) egy speciális, Ethernet-alapú helyi hálózat (LAN), amelyet a CERN-ben (Maciej Lipinski és csapata) fejlesztettek ki részecskegyorsítókhoz. Célja a brutálisan pontos, szub-nanoszekundumos óraszinkronizáció és determinisztikus adatátvitel egyidejű biztosítása.

Hogyan működik? A WR szabványos Ethernet kereteket és optikai kábeleket használ (in-band szinkronizáció), de a switchek és node-ok belsejében lévő fizikai réteget (PHY) teljesen átalakították. Hatalmas mennyiségű PLL-t és FPGA-t használnak a hardverben, hogy a PTP protokoll fázishibáit és a hardveres késleltetéseket pikoszekundumos szinten mérjék és kompenzálják.

Must-know facts:

• Pontosság (Accuracy): Worst-case ofszet < 1 ns (1 nanoszekundum alatt).
• Precízió (Jitter): Worst-case jitter < 50 ps (50 pikoszekundum alatt).
• Topológia: Speciális hardvereket (WR switch + WR node) igényel, hagyományos lakossági/vállalati switch-csel nem működik.
• Szabványosított formája az IEEE 1588-2019 (PTPv2.1) High Accuracy profiljába (lényegében a White Rabbit beemelése a hivatalos szabványba).

---

Open Hardware előnyei és hátrányai (White Rabbit kontextusában)

Mi ez? A White Rabbit projekt teljesen nyílt forráskódú, mind szoftveres (Linux driverek, PTP démonok), mind hardveres (Open Hardware) szinten. A NYÁK tervek, FPGA VHDL kódok és kapcsolási rajzok bárki számára letölthetőek (CERN OHL licenc).

Hogyan működik? Mivel a tervek nyilvánosak, elméletileg bárki letöltheti őket, és legyárthatja a saját WR hálózati kártyáját vagy switch-ét, vagy megveheti egy hivatalos szállítótól (pl. Safran / SevenSolutions).

Must-know facts:

• Előnyök: Teljesen transzparens, a mérnöki közösség által auditált, független a gyártói bezártságtól (vendor lock-in), adaptálható.
• Hátrányok/Kihívások: Az idődimenzióban elvárt szigorú specifikációk (< 1 ns hiba) miatt a komponenseket nem lehet szabadon cserélgetni. Ha a tervben lévő drága és specifikus PLL-t vagy PHY chipet másra cseréled, a hardver garantáltan elveszíti a szub-nanoszekundumos képességét. Nem fut el akármilyen olcsó áramköri lapon.

---

PTM alapötlete

Mi ez? A PTM (Precision Time Measurement), más néven PCIe TimeSync, egy hardveres protokoll az x86-os PC/szerver architektúrákban. Célja, hogy a gép központi fizikai rendszeróráját és egy periféria (pl. a PCIe foglalatban lévő Hálózati Kártya / NIC) hardveres óráját tökéletesen szinkronizálja.

Hogyan működik? Olyan, mintha a JVM belső óráját mikroszekundumos pontossággal hardveresen rákötnéd egy külső Arduino interruptjára. A PCIe buszon keresztül az alaplap és a bővítőkártya kicseréli az időbélyegeit, kiszámolja a PCIe busz késleltetését, és a periféria óráját a CPU központi, leállíthatatlan hardveres órájához (ART) igazítja.

Must-know facts:

• x86 Platform sajátosság: Az Intel TCC (Time Coordinated Computing) Tools része, 12. generációs CPU-któl és ipari alaplapoktól érhető el (kommersz gépeken nem feltétlenül).
• ART (Always Running Timer): A CPU központi hardveres rendszerórája, amihez a perifériákat igazítják.
• TGPIO (Time-aware General-Purpose Input/Output): A perifériák szinkronizálásához használt technológia, ami hardveres eseményekhez (interruptokhoz) köt pontos időbélyeget.
• Lényege: Nem a hálózaton lévő más gépekkel, hanem a PC-n belüli hardveres kártyákkal szinkronizál (PCIe buszon).

---

I2C HW és SW felépítése

Mi ez? Inter-Integrated Circuit. A Philips által kitalált, mikrokontrollerek (Master) és szenzorok (Slave) panelen (NYÁK) belüli összekötésére szolgáló népszerű, kétvezetékes soros kommunikációs protokoll (Arduino-n az A4/A5 pinek és a Wire.h könyvtár).

Hogyan működik?

• Hardver (Alacsonyszintű interfész): Mindössze 2 vezetékből áll: SCL (Órajel, mindig a Master vezérli) és SDA (Adatvonal, kétirányú). A busz architektúrája Open-Drain: senki nem hajt fel magas (1-es) logikai szintet. Ha valaki logikai 0-t akar, “lehúzza” a vonalat a földre (GND). Ha 1-et akar (vagy hallgat), elengedi.
• Kellenek rá Felhúzó ellenállások (Pull-up resistors, tipikusan 2-5 kOhm), amik a buszt tápfeszültségre húzzák fel alaphelyzetben.
• Szoftver (Linux): A Linuxnak egy komplett i2c alrendszere van. A mikrokontroller/SoC fizikai I2C busza egy Device Tree (arm) vagy Plug&Play (x86) konfiguráció alapján kernel driverként fut, és megjelenik a /dev/i2c-* fájlként. (Everything is a file in Linux). Ezt a userspace alkalmazások (pl. C program) open() és ioctl() hívásokkal tudják írni/olvasni.

Must-know facts:

• A buszon alapesetben 7 bites címzés van (128 eszköz címezhető maximum).
• Az SCL-t mindig a Master vezérli (100kHz vagy 400kHz jellemzően).
• A felhúzó ellenállás fizikai hiánya (vagy rossz bekötése) esetén az I2C garantáltan nem fog működni, nem lehet logikai 1-es jelszintet mérni.
• Egy Linux alapú rendszeren egy konkrét szenzorhoz vagy van egy kernel driver (pl. hwmon/lmsensors), ami felcsatolja magát, VAGY userspace-ből direktben ioctl hívásokkal mi magunk vezéreljük a /dev/i2c-* fájlon keresztül.

---

Az i2ctools elemei és az elemek használati esetei

Mi ez? Egy Linux parancssoros eszközkészlet (utility bundle), ami elengedhetetlen a NYÁK debuggolásához és az I2C szenzorok teszteléséhez userspace-ből, anélkül hogy C/C++ programot kellene írnunk/fordítanunk.

Hogyan működik? Az eszközök a háttérben közvetlenül hívják az operációs rendszer ioctl hívásait a megfelelő /dev/i2c-* device file-on, strace-szel követhető, hogy mit csinálnak.

Must-know facts: Ezek a programok pontos funkciói, amiket vizsgán kérdezhetnek:

• i2cdetect: Busz szkennelése. Megmutatja egy adott buszon (pl. /dev/i2c-1), hogy milyen hexadecimális címeken válaszolnak éppen az eszközök (kiépült-e az ACK). Kiderítheted vele, látja-e a Linux a szenzort.
• i2cdump: Adott I2C eszköz (pl. 0x49 címen) összes olvasható regiszterének egyidejű kiolvasása és hexadecimális listázása (dumpolása). Jó áttekintésre.
• i2cget: Egyetlen konkrét, specifikált regiszter adatának kiolvasására (lekérdezésre) szolgál egy adott címen lévő eszközből.
• i2cset: Egyetlen konkrét, specifikált regiszterbe történő adatírásra/beállításra szolgál.

---

A date program funkciói, tulajdonságai

Mi ez? Parancssori eszköz a Linux helyi és globális idejének lekérdezésére, formázására és beállítására. Hasonló a Java java.time.ZonedDateTime osztályához, csak shell szinten.

Hogyan működik? Alapértelmezésként a rendszer CLOCK_REALTIME óráját kérdezi le. Formázó sztringekkel (format string) az idő kiíratható tetszőleges formátumban (pl. UNIX timestamp nanomásodperc pontossággal) és a világ bármely időzónájára vonatkozóan, függetlenül a szerver aktuális lokációjától.

Must-know facts:

• Alapból a lokális időt írja ki UTC-ben.
• Lehet vele jövőbeli és múltbeli időt konvertálni (pl. “hány óra lesz holnap este Hawaii-on”).
• Root jogosultsággal az idő beállítására is használható (akár teljesen rossz értékre is).
• Rendszerszinten a CLOCK_REALTIME órát használja referenciaként.

---

Linux órai és azok tulajdonságai óraszinkronizáció esetén

Mi ez? A Linux kernel többféle logikai órát tart karban különböző mérési feladatokhoz. Míg a Java-ban a System.currentTimeMillis() a faliórát, a System.nanoTime() az eltelt időt méri, a Linux kernel mélyebb felbontást ad (pl. boot óta eltelt idő, szálak processzorideje).

Hogyan működik? Az NTP és PTP kliensek a háttérben futva a magot (kernel) utasítják, hogy gyorsítsa vagy lassítsa a logikai órák ketyegését (frekvencia állítás), vagy végezzen hirtelen értékugrást (step), hogy szinkronba kerüljön a hálózattal.

Must-know facts (kifejezetten ZH-ra):

• CLOCK_REALTIME: A falióra (1970.01.01 UTC óta eltelt idő). Az NTP/PTP programok állítják. Nem garantáltan monoton folytonos (visszafelé is ugorhat időszinkronizációkor).
• CLOCK_MONOTONIC: Boot óta eltelt idő. Dátum beállítás/ugrás nem hat rá. Garantáltan monoton nő, de az NTP/PTP állíthatja a ketyegés frekvenciáját (sebességét).
• CLOCK_MONOTONIC_RAW: Boot óta eltelt idő. Semmi nem állítja, szigorúan a hardveres oszcillátor “névleges” sebességével nő.
• CLOCK_PROCESS_CPUTIME_ID / CLOCK_THREAD_CPUTIME_ID: Az adott processz vagy szál által ténylegesen elfogyasztott CPU idő.

---

A systemd-timesyncd és a timedatectl SNTP kliens tulajdonságai

Mi ez? A systemd-timesyncd a modern Linuxok (pl. Debian/Ubuntu) beépített, pehelysúlyú időszinkronizációs szolgáltatása. Mint egy egyszerű cron-job, ami néha HTTP kérés helyett SNTP-vel (Simple Network Time Protocol) letölti a pontos időt.

Hogyan működik? Kliensként csatlakozik egy beállított NTP szerverhez (pl. /etc/systemd/timesyncd.conf). Lecsekkolja az eltérést, és utasítja a kernelt az óra (frekvencia vagy ugrás) beállítására. A timedatectl show-timesync paranccsal monitorozható a szerver adatai és az offset.

Must-know facts:

• Csak SNTP-vel dolgozik (egyszerűsített NTP, alacsonyabb pontosság).
• Kizárólag kliens, más gépeket nem szolgál ki.
• A konfigurációs fájl módosítása után a sudo systemctl restart systemd-timesyncd parancs kötelező.

---

A chrony NTP szerver tulajdonságai és konfigurációja

Mi ez? Egy robusztus, modern valódi NTP szerver és kliens, amely jelentősen gyorsabban és pontosabban szinkronizál, mint a beépített systemd-timesyncd.

Hogyan működik? Folytonosan méri a helyi oszcillátor pontatlanságát (drift) és rendkívül finoman kompenzálja azt. A konfigurációs fájlokat a /etc/chrony/ (vagy sources.d) mappában tárolja. A chronyc paranccsori eszközzel lehet élőben vezérelni és monitorozni.

Must-know facts:

• Telepítése után (pl. apt install chrony) magától elindul és automatikusan leállítja a systemd-timesyncd-t, hogy a kettő ne “rángassa” az órát egymás ellenében.
• Kulcsparancsok (vizsgán felcserélhetik a funkciójukat): chronyc sources, chronyc sourcestats, chronyc tracking.
• Az NTP protokollt (hálózati idő) használja, NTP szerverként is üzemelhet a hálózatban.

---

PTP támogatás ellenőrzése, az ethtool program szerepe

Mi ez? A PTP (Precision Time Protocol / IEEE 1588) eléréséhez az OS hálózati stacket megkerülő, nano-másodperc pontosságú hardveres időbélyegzésre (HW timestamping) van szükség. Ennek meglétét ellenőrzi az ethtool.

Hogyan működik? Amikor egy keret a hálózati rétegből fizikailag kimegy a kábellel (MAC/PHY szint), a hálókártya csatol rá egy időbélyeget (nem a Linux kernel!). Ezt a képességet az OS felé az ethtool listázza ki.

Must-know facts:

• Parancs az ellenőrzésre: ethtool -T eth0 (ahol eth0 a hálókártya).
• Keresett flag-ek: SOF_TIMESTAMPING_TX_HARDWARE, RX_HARDWARE, RAW_HARDWARE.
• Ha a rendszer támogatja a HW PTP-t, létrejön egy /dev/ptp* eszközfájl a fájlrendszerben.

---

A linuxptp csomag és azon belül az ptp4l szerepe

Mi ez? A linuxptp a PTP (IEEE 1588) hivatalos nyílt forráskódú implementációja Linuxra. Fő daemonja a ptp4l, ami magát a mikroszekundum/nanoszekundum szintű szinkronizációt végzi.

Hogyan működik? A daemon a hardveres órával (a hálókártyán lévő PTP óra) dolgozik. PTP üzeneteket küld és fogad, majd a Best Master Clock (BMCA) algoritmus alapján eldönti, hogy ő lesz-e a master óra, vagy szinkronizál a hálózaton található jobb minőségű órához.

Must-know facts:

• Alapértelmezett kommunikáció: IPv4/UDP felett (de a -2 kapcsolóval tisztán Layer-2 Ethernet MAC szintre állítható).
• Futtatási példa: sudo ptp4l -m -q -i eth0.
• A default óraprioritás 128.
• A prioritás paraméter (--priority2=...) esetében a kisebb szám jelenti a magasabb prioritást (ha beállítjuk 100-ra, jó eséllyel a mi gépünk lesz a Master).

---

A zóna alapú architektúra tulajdonságai és előnyei

Mi ez? Az autós elektronika (E/E architektúra) új paradigmája. A hagyományos, funkcióhoz kötött kábelezés (pl. dedikált kábel minden fék-ECU-nak) helyett egy IT hálózathoz hasonló, topológia/távolság alapú zónákat hoznak létre (mint az edge cloud mikroszerviz architektúra).

Hogyan működik? A perifériák (szenzor, fék, lámpa) egyszerűen a hozzájuk fizikailag legközelebb lévő “Zóna Vezérlőhöz” csatlakoznak. A zóna vezérlők egy közös, nagysebességű központi gerinchálózaton (Ethernet) át kommunikálnak a Központi Számítógéppel.

Must-know facts:

• Virtuális, dedikált hálózatot biztosít minden funkciónak (domain) a közös dróton.
• Jelentősen csökkenti a kábelköteg súlyát és bonyolultságát.
• A klasszikus IP/Ethernet stack nem alkalmas rá, mert nem valós idejű és nem garantálható a determinizmus (késleltetés) -> Ezért kell a TSN (Valós Idejű Ethernet).

---

A TTEthernet szabvány alapvető tulajdonságai

Mi ez? A Valós-idejű Ethernet első generációja (1. iteráció), a TTTech által létrehozott protokoll. Szigorúan Idő-vezérelt (Time-Triggered) hálózat, űr- és repülőgépiparban használják (pl. NASA Orion).

Hogyan működik? Tökéletesen szinkronizált órákra épít. Az ütemezés statikus, előre bele van égetve/konfigurálva a switch-ekbe. Ha egy eszköz küld egy csomagot, amikor nem lett volna szabad, a switch mint egy biztonsági őr kíméletlenül eldobja azt (a hálózat megvédi magát a hibás node-tól).

Must-know facts:

• Szabványa a SAE AS6802.
• Megoldja a “Bumbling idiot” (motyogó idióta) problémát (hibásan folyamatosan adó node blokkolása).
• Három forgalomtípus:
  1. Idővezérlet (Time-Triggered - garantált fix ablak)
  2. Sávszélesség korlátozott (Rate-constrained)
  3. Best Effort (Szabad sávszélesség)

---

Az AVB szabvány alapvető tulajdonságai

Mi ez? Audio-Video Bridging (2. iteráció), az IEEE 802.1 része. Garantált sávszélességű Ethernet multimédiás (stúdió, koncert) és autóipari célokra, TCP/IP mellőzésével.

Hogyan működik? Nem időablakokat definiál fixen előre, hanem sávszélességet foglal (Stream regisztráció). Egy node szól a switchnek, hogy van egy AV streamje. Ha van elég hely a dróton, a switch garantálja az átvitelt és az alacsony késleltetést.

Must-know facts:

• Erőforrást foglal a switchekben az MSRP (Multiple STREAM Registration Protocol) segítségével.
• Szinkronizációhoz az IEEE 802.1AS (PTP) protokollt használja.
• Prezentációs időt (Genlock) garantál: a kamera és a mikrofon adatai ezredmásodpercre egyszerre játszódnak le az elosztott hálózatban.

---

A TSN szabvány és az idő-vezérelt működés

Mi ez? Time-Sensitive Networking (3. iteráció). Egy IEEE szabványcsalád (nem egyetlen szabvány!), amely a normál, gyártófüggetlen Ethernetet determinisztikussá és valós idejűvé (Hard Real-Time) teszi. Lényegében egy Software Defined Network (SDN).

Hogyan működik? A hálózat modelljét YANG nyelven írják le, és NETCONF protokollal, RPC hívásokkal konfigurálják a hálózati elemeket (tranzakciós alapon, konzisztensen). Idővezérelt működése során szigorú határidőkkel és időablakokkal továbbítja a kritikus kereteket a switch-eken keresztül.

Must-know facts:

• Alapja a globális, elosztott óraszinkronizáció.
• A bizonytalanságokat egy ún. Guard band (beérkezési/bizonytalansági időablak) bevezetésével kezeli a switchekben.
• Alapszabványai (ZH-n jó eséllyel felismerősre kérdezik):
  • 802.1AS (Timing)
  • 802.1Q (Bridges/Scheduling)
  • 802.1CB (Reliability / Replication)

---

TSN és az óraszinkronizáció

Mi ez? A determinisztikus ütemezéshez minden switchnek és végpontnak ugyanannyi kell legyen az “idő”. Ez a valós idejű hálózat szívdobogása.

Hogyan működik? A hálózat hardveres támogatású órákat használ, amelyek a PTP (Precision Time Protocol) segítségével folyamatosan szinkronban tartják a lokális rendszereket. Az ütemezést a központi globális idő alapján hajtják végre.

Must-know facts:

• Az IEEE 802.1AS-2020 szabvány (egy IEEE 1588 PTP profil) végzi a TSN alapértelmezett szinkronizálását.
• Elvárás a legrosszabb esetben is maximum 1 µs (100 ns) pontosságú hibahatár.

---

A Filtering and Policing alapötlete és céljai

Mi ez? A hálózat “érték- és időtartományban értelmezett tűzfala”. Védelmi vonal a standard Ethernet hibamodelljének (Fail silent) korlátaival szemben, amikor egy meghibásodott hardver nem egyszerűen elnémul, hanem fals forgalmat generál.

Hogyan működik? A switchekben lévő logika másodpercről másodpercre ellenőrzi a belépő forgalmat. Ha egy végpont nem a saját engedélyezett idejében, nem a dedikált protokolljával, vagy nagyobb sávszélességgel kezd adni (pl. betolakodó támad, vagy meghibásodott), a switch a portjánál eldobja a csomagokat.

Must-know facts:

• Megvédi a hálózatot a “Mumbling idiot” (motyogó idióta) és a Bizánci hiba (Byzantine error) típusú kényszerített téves viselkedésektől.
• Kikényszeríti, hogy egyetlen meghibásodott node ne tudja ártani a hálózat valós idejű működésének (fail-silent viselkedést erőltet ki).

---

A Real-Time Stream Reservation alapötlete és céljai

Mi ez? Dinamikus sávszélesség-lefoglalás a valós idejű adatfolyamok (RT streamek) számára, hasonlóan ahhoz, ahogy egy asztalt foglalsz egy étteremben, mielőtt oda mész.

Hogyan működik? Mielőtt egy alkalmazás kommunikálni kezdene, a System Management megvizsgálja a hálózati útvonalat. Ha van elég szabad erőforrás, a portokon kiosztásra/lefoglalásra kerül a sávszélesség, és a kommunikáció elindul. Ha nincs, a kérést elutasítja.

Must-know facts:

• Garantálja az erőforrás rendelkezésre állását és az alacsony késleltetés-ingadozást.
• Képes arra, hogy egy már kiadott erőforrást menet közben visszavegyen (preempt), ha hirtelen egy kritikus, magasabb prioritású alkalmazás kéri a sávszélességet.

---

Az Enhancements for Scheduled Traffic alapötlete és céljai

Mi ez? Az IEEE 802.1q (alap VLAN prioritások) kiegészítése (EST) Time-Aware shaper bevezetésével, hogy a switch sose blokkoljon véletlenül egy valós idejű csomagot egy hosszan tartó alacsony prioritású csomag kiküldésével.

Hogyan működik? Tudván, hogy mikor érkezik az RT (Time-Triggered) csomag, a switch létrehoz egy bizonytalansági sávot (Guard band). Ebben a sávban, közvetlenül a várt kritikus csomag érkezése előtt a switch blokkolja az összes nagy, Best-Effort (alacsony prioritású) csomag kiküldését.

Must-know facts:

• Tranzakció jelleggel működik: minden hálózati elem betartja a globális határidőt.
• Jelentősen csökkenti a késleltetési ingadozást (jitter).
• Elengedhetetlen feltétele a pontos óraszinkronizáció.

---

Az Frame Replication and Elimination for Reliability alapötlete és céljai

Mi ez? A TSN redundancia mechanizmusa, ami kiküszöböli a normál Spanning Tree Protocol (STP) lassú konvergenciáját. Hardver szintű replikáció a fizikai (kábelszakadás) vagy bithibák azonnali hárítására.

Hogyan működik? Az adót (vagy az első switchet) úgy konfigurálják, hogy a kiinduló Ethernet keretet duplikálja (többszörözze). Ezek a keretek a hálózat különböző fizikai útvonalain (pl. gyűrű vagy párhuzamos ágak) haladnak. A fogadó (vagy utolsó switch) a legelső érvényes beérkező példányt fogadja el, az összes utána befutó duplikátumot azonnal eldobja (elimination).

Must-know facts:

• Az információs útvonalak és maga a hálózati hardver biztosítja a redundanciát, nem a szoftver/alkalmazás.
• Alternatívája (amiből inspirálódott): HSR (gyűrűs) és PRP (párhuzamos) ipari redundancia protokollok.

---

A Frame Preemption alapötlete és céljai

Mi ez? Olyan hardveres képesség a switchekben, ami lehetővé teszi egy már folyamatban lévő nagy, alacsony prioritású keret küldésének “félbeszakítását”, hogy egy fontos, RT keret azonnal kimehessen a dróton (mint az OS thread preemption).

Hogyan működik? Ha az Ethernet port épp egy óriási Best Effort (BE) keretet ad, és beesik a sorba egy magas prioritású keret, a küldés fizikai szinten megáll. Egy speciális jelzésrendszerrel az RT keret átmegy, majd a megszakított BE keret maradéka (maradék byte-ok) továbbadódik.

Must-know facts:

• Célja: Megszünteti/drasztikusan csökkenti a Guard band miatti holtidőt és növeli a csatorna kihasználtságát.
• Hátránya: Komplex hardvert igényel, 1 Gbps felett már gyakran nem éri meg (mert ott eleve olyan gyorsan átmegy a nagy keret, hogy a switch belső procceszálása a szűk keresztmetszet).

---

Az OPC UA tulajdonságai és valós-idejűsége

Mi ez? Platformfüggetlen “európai” Ipar 4.0 szabvány. Nem csak egy protokoll, hanem egy komplex adatleíró nyelv, modell és szolgáltatás (a régi, Microsoft Windows COM-alapú OPC utódja).

Hogyan működik? Alapból Kliens-Szerver modellben működik standard TCP IP-n. Ha valós időben akarunk kommunikálni (RT), a Kliens-Szerver felállás helyett a PubSub (Publish-Subscribe) over UDP kiterjesztést kell használni TSN felett.

Must-know facts:

• Maga az alap OPC UA protokoll NEM valós idejű (mert TCP-t használ).
• Az OPC UA PubSub (UDP felett) az, ami KÉPES a Real-Time (RT) működésre.
• Szigorúan nyílt szabványokra épül, van ingyenes megvalósítása.

---

A DDS tulajdonságai és valós-idejűsége

Mi ez? Data Distribution Service. Az “amerikai” ipari/katonai OMG szabvány, egy teljesen elosztott, központi bróker nélküli Publish-Subscribe middleware.

Hogyan működik? A hálózat elemei egy globális adatmezőbe (Data Space) publikálnak és arra iratkoznak fel. Nincs központi szerver (bróker), ami eleshetne. UDP transzportra épül és extrém módon paraméterezhető Quality of Service (QoS) profilokat támogat a megbízhatóság érdekében.

Must-know facts:

• KÉPES a valódi (Real-time) működésre.
• Publish/Subscribe alapú architektúra.
• Az “OMG” (Object Management Group) környezetéből származik, TCP helyett alapvetően UDP-t használ.

---

Az MQTT tulajdonságai és valós-idejűsége

Mi ez? A legismertebb “könnyűsúlyú” IoT protokoll. Publish-Subscribe alapon működik egy központi üzenetelosztó szerveren (bróker) keresztül.

Hogyan működik? Az IoT kliens (pl. mikrokontroller) nyit egy TCP kapcsolatot a brókerhez. Publikál egy “topic”-ba (pl. sensor/temp), a bróker pedig kiküldi a feliratkozott klienseknek.

Must-know facts:

• NEM valós idejű (alapvetően TCP-t használ).
• A módosított verziója (MQTT-SN - Sensor Networks) ugyan UDP-t használ (pl. vezeték nélküli hálózatokhoz), de annak sem célja a Real-Time (RT) működés.

---

A SOME/IP tulajdonságai

Mi ez? Az autóipar válasza a gRPC-re/REST-re. A “Scalable service-Oriented MiddlewarE over IP” egy AUTOSAR-ba integrált valós idejű middleware (Ethernet hálózatokra optimalizálva).

Hogyan működik? Támogatja a távoli eljáráshívásokat (RPC) és a Publish/Subscribe üzenetküldést is. Rendelkezik Service Discovery-vel (az ECU-k automatikusan megtalálják egymás szolgáltatásait). A platformfüggetlen objektumokat és adattípusokat (uint8, struct, array) a hálózaton küldhető bájtokká alakítja (Serialization), és képes a nagy üzeneteket UDP szegmensekre vágni.

Must-know facts:

• Az autóipari (AUTOSAR) valós-idejű adatok, mérések, szabályozások kommunikációs szabványa.
• Rugalmas: RPC és Pub/Sub alapú tervezést is támogat.
• Kezeli a szerializációt és az UDP szegmentálást.

---

Heterogén rendszerek alapötlete, alapvető architektúrája

Mi ez? Olyan egychipes rendszerek (SoC - System on Chip), amikbe nemcsak egyforma CPU magokat raknak, hanem dedikált, speciális feladatokra szánt célprocesszorokat is (Application CPU + DSP + GPU + RT MCU + FPGA modul). Hasonló elv, mint az Apple M szériás chipjei.

Hogyan működik? A “nagy” teljesítményű Application Processor (AP) magokon Linux fut, ami kiváló a komplex vezérléshez, de a kontextusváltások miatt csapnivaló a valós idejű (RT) feladatokban. Ezért a Linux csak elosztja (orchestrálja) a feladatot. A tényleges valós idejű IO rángatást, vagy a dedikált matekot az elzárt hardveres MCU / DSP magok végzik osztott memórián (Shared Memory) keresztül.

Must-know facts:

• Ok: A Linux 50-70 µs-re teljesen elveheti a CPU-t egy interrupt kezelés miatt, ezért a user-space RT I/O megbízhatatlan.
• A “fő CPU” a vezérlésért (networking, GUI, config), a “heterogén magok” az erőforrás-intenzív / valós idejű végrehajtásért felelnek (Asymmetric Multiprocessing).

---

A Linux remoteproc és RPMsg alrendszere és azok felépítése

Mi ez? A Linux kernel szabványos, gyártófüggetlen keretrendszere, amivel az előző pontban tárgyalt segédprocesszorokat (MCU, DSP) felébreszti, vezérli és kommunikál velük.

Hogyan működik? Két részre oszlik (mint a fájlrendszer vs. network socket):

1. remoteproc (System lifecycle): Felel a firmware (.elf fájl) betöltéséért (tipikusan a /lib/firmware/ útvonalról) a segédmagba a boot során vagy futásidőben. Fájl I/O műveletekkel vezérelhető (Start, Stop).
2. RPMsg (Remote Processor Message): Az alkalmazásszintű kommunikáció. Olyan, mint egy aszinkron IPC pipe; virtuális memóriát (virtio) használ az AP és a segédmagok között. Linux oldalon select(), poll() eseményvezérelt IO hívásokkal várhatunk az MCU-tól jövő adatra.

Must-know facts:

• Az architektúra megköveteli: Mindig ELŐSZÖR a firmware-t kell betölteni a remoteproc-kal, csak ezután indulhat el a Linuxos alkalmazás, ami az RPMsg-en keresztül beszél vele!
• A remoteproc NEM végzi el az I/O pinek lábkiosztását (Pin muxing/Config) – az a Device Tree vagy dinamikus overlay-ek feladata.

---

A SmartNIC koncepció alapötlete és megvalósítási lehetőségei

Mi ez? Intelligens hálózati kártya (Smart Network Interface Controller). Olyan HW modul, ami nemcsak áttolja a hálózati bitfolyamot a fő processzornak, hanem komplex, dedikált programozható egységeket (saját ARM magokat vagy FPGA-t) tartalmaz a hálózati kártyán belül.

Hogyan működik? Mivel a másodpercenkénti 100 Gbit+ forgalom interruptjaitól leolvadna a host CPU (Linux OS), a hálókártyára áthelyezik a hálózati tűzfalazás (firewall), a protokoll értelmezés, sőt az NTP szerver kiszolgálásának logikáját is. A Host OS csak vezényli (orchestrate) a szabályokat, az érdemi munka a NIC-en történik.

Must-know facts:

• Drasztikusan lecsökkenti a hálózati késleltetést (us nagyságrend) és lecsökkenti az AP memória/interconnect terhelését.
• Használják: TCP/UDP offloading, biztonsági szűrés, komplett valós idejű protokollok lekezelése host OS megszakítás nélkül.
• Fizikailag megvalósítható FPGA-val (pl. AMD Alveo) vagy dedikált hálózati CPU magokkal (pl. Intel IPU 16x ARM Neoverse maggal).

---

Vissza a bloghoz