RTOS vs. GPOS: Echtzeit- vs. Allzweck-Betriebssysteme im Vergleich

Allzweck-Betriebssysteme (GPOS)

Moderne Geräte (Software/Hardware) benötigen Betriebssysteme. GPOS (General Purpose OS) zielen auf hohen Durchsatz (Throughput) ab: Viele Prozesse pro Zeiteinheit abarbeiten. Beispiel: Windows, Linux, macOS.

GPOS nutzen Fairness-Scheduling: Niedrig-priorisierte Tasks werden oft vor hochpriorisierten ausgeführt, um Gesamt-Durchsatz zu maximieren. Ein hochpriorisierter Thread kann verzögert werden, wenn viele Low-Priority-Tasks in der Queue warten. Geeignet für Multitasking-Desktops/Servers, nicht für zeitkritische Echtzeitanforderungen.

Echtzeit-Betriebssysteme (RTOS)

RTOS (Real-Time OS) sind für zeitkritische Anwendungen mit deterministischem Verhalten konzipiert. Jede kritische Operation hat eine garantierte maximale Ausführungszeit (Time-Bounded).

Drei Kernfunktionen:

1. Scheduler (Task-Planer)
2. RTOS Services (Kernel-Dienste)
3. Synchronisation & Messaging

Der Scheduler

Drei Task-Zustände:

• Ready: Bereit, wartet auf CPU
• Running: Wird gerade ausgeführt
• Blocked: Wartet auf Event/Ressource

Scheduling-Verfahren:

• Präemptiv (Prioritätsbasiert): Höchste Priorität läuft immer. Unterbrechung (Preemption) möglich. Standard bei RTOS.
• Kooperativ: Task gibt CPU freiwillig ab (Time-Slice). Keine Garantie für Reaktionszeit.

Kernel verwaltet: Task-Erstellung, Prioritätsänderung, Zustandswechsel, Task-Löschung.

RTOS Services (Kernel-Dienste)

Kernel managt Ressourcen. Da Tasks nicht immer CPU-Zugriff haben, stellt Kernel Dienste bereit:

• Zeitdienste (Timer, Delays)
• I/O-Dienste
• Interrupt-Handling
• Speicherverwaltung
• Gerätemanagement

Messaging & Synchronisation

Kommunikation zwischen Tasks:

• Mailboxes, Pipes, Message Queues: Datenaustausch
• Event Flags: Synchronisation von Aktivitäten
• Semaphores / Mutexes: Schutz geteilter Ressourcen

RTOS vs. GPOS – Direkter Vergleich

Kernunterschied: Anwendungsart (zeitkritisch vs. durchsatzorientiert).

Beispiel ATM (Geldautomat): Nutzer drückt Bestätigung → Geldausgabe in 4–5 s erwartet. 5 Min. Wartezeit inakzeptabel. → RTOS.

Beispiel PC/Smartphone: Multitasking, keine harten Deadlines. Dokument speichern dauert mal Sekunden, mal Minuten (abhängig von Last). → GPOS (Linux, Windows, Android, iOS).

RTOS-Beispiele: FreeRTOS, Zephyr, VxWorks, QNX, µC/OS, ThreadX.

Vergleichskategorien

Kriterium	GPOS	RTOS
Task Scheduling	Durchsatz-orientiert (Fairness), Priorität nicht garantiert	Prioritätsbasiert, präemptiv, High-Prio immer zuerst
Latenz (Dispatch Latency)	Unbegrenzt (wächst mit Thread-Anzahl)	Begrenzt (bounded), deterministisch
Hardware / Kosten	High-End (PC, Workstation, Server), ressourcenhungrig	Low-End / Standalone (MCU, Vending, ATM), klein, leicht
Kernel Präemptierbarkeit	Nicht präemptiv (Kernel-Calls blockieren High-Prio)	Voll präemptiv (Kernel-Calls unterbrechbar)
Speicherbedarf	Groß (MB–GB)	Klein (KB–wenige MB), < 10 % MCU-Flash/RAM
Ziel	Maximaler Durchsatz, Fairness	Vorhersagbare, fristgerechte Ausführung

RTOS-Auswahl für Embedded-Projekte – Checkliste

Wichtige Features, die ein Embedded-RTOS bieten sollte:

1. Integrierter Scheduler

Präemptiv, prioritätsbasiert, für Echtzeit-Ausführung.

2. Software-Timer

Funktionsausführung in definierten Zeitfenstern. Nicht selbst implementieren – fehleranfällig.

3. Queue-Mechanismus (Nachrichtenwarteschlangen)

Task-übergreifender Datenaustausch (nachrichtenbasiert).

4. Execution Tracing Tools

Laufzeitverhalten analysieren, Fehler finden, Timing prüfen (z. B. Percepio Tracealyzer, SEGGER SystemView).

5. Geringer Memory Footprint

Gesamtgröße < 10 % des MCU-Speichers (Flash + RAM).

Fazit

Beide OS-Typen sind in ihren Domänen richtig. RTOS opfert Durchsatz für Determinismus & Vorhersagbarkeit. GPOS maximiert Durchsatz für allgemeine Workloads. Für Embedded mit harten Deadlines (Motorsteuerung, Medizintechnik, Auto, Industrie) → RTOS. Für UI, Netzwerk, Dateisysteme, Multitasking → GPOS. Manchmal Hybrid: Linux + RTOS-Kernel (PREEMPT_RT) oder Hypervisor.

Fragen? Wir helfen gerne weiter!