QNX: Echtzeit-OS zum Nulltarif

QNX und die Konkurrenz

Zu den Grundanforderungen für ein hartes RTOS zählen eine Interruptauflösung im Mikrosekundenbereich, ein zuverlässiger Jitter unter 25 µs, eine Reaktionszeit von wenigen 10 bis 100 µs sowie eine garantierte Verarbeitung jedes Interrupts. Solche Fähigkeiten sind einem Betriebssystem nachträglich nur schwer aufzupfropfen. Daran leiden speziell die zwei potenziellen QNX-Rivalen Windows NT/2000/XP und Linux.

Windows NT und seine Nachfolger würden sich schon wegen ihrer Verbreitung im professionellen Bereich zur Verarbeitung von Echtzeitaufgaben anbieten. Im Basiszustand können sie solche jedoch nicht lösen: Die zur Interruptverarbeitung benötigte Zeitspanne lässt sich nicht vorhersagen, auch bei der Speicherzuweisung treten unkalkulierbare Verzögerungen auf. Von der Industrie angebotene Workarounds, wie etwa über NMIs arbeitende Spezial-Hardware oder Systeme mit modifiziertem HAL, realisieren nur "weiche" Echtzeit oder lassen lediglich bestimmte Interruptquellen zu. Lediglich Windows CE bietet ähnliche Fähigkeiten wie QNX RTOS, kann jedoch bedeutend weniger Prozesse verwalten (32 gegenüber 4095) und gibt sich beim Interrupt-Handling weniger flexibel als QNX.

Auch Linux ist nur mit Tricks zu Echtzeitverarbeitung zu bewegen. Die Timer-Auflösung des Kernel liegt auf den meisten Hardware-Plattformen bei 10 ms - für Realtime um zwei Größenordnungen zu langsam. RTLinux, eines der beiden verbreiteten Echtzeit-Linuxe, implementiert einen eigenen Realtime-Microkernel. Er bindet ein Standard-Linux als präemptiv angesteuerten Task niedriger Priorität ein. Applikationen mit Betriebssystem-Aufrufen lassen sich also bestenfalls als "weiche" RT-Tasks realisieren. Die Alternative KURT (Kansas University Real Time Linux) operiert über eine Reprogrammierung des Systemtimers sowie entsprechend angepasste Scheduling-Mechanismen. Bei diesem Ansatz können allerdings einzelne Subsysteme, etwa Massenspeicher, die Interruptverarbeitung für bis zu 450 µs blockieren.