Echtzeit

Das QNX Neutrino RTOS gewährleistet vorhersagbare Reaktionszeiten sowohl auf Applikationsebene als auch in allen Subsystemen. Eines der kritischsten Probleme in Echtzeitsystemen, die Prioritätsinversion, wird durch konsequente Prioritätsvererbung auf Thread-Ebene unter QNX eliminiert.

Selbstheilungsfähigkeit

Systemausfälle sind Vergangenheit, Blue Screens gibt es nicht - dank der QNX Microkernel-Architektur. Programmabstürze werden abgefangen, keine Softwarekomponente kann den Kernel oder andere Komponenten beschädigen. Bei Fehlersituationen kann sich das System innerhalb von Sekundenbruchteilen wieder in einen definierten Zustand versetzen, in dem einzelne Komponenten kontrolliert neu initialisiert werden.

Zeitpartitionierung

Freie CPU-Zeit steht unter QNX allen Prozessen zur Verfügung, doch wenn das System stark ausgelastet wird, können vom Systemdesigner zugewiesene CPU-Zeitbudgets zur Anwendung kommen. Damit können für kritische Prozesse CPU-Zeit-Garantien eingerichtet werden, damit diese ihre Aufgaben in jedem Fall erfüllen.

Hochverfügbarkeit

Zum QNX-Betriebssystem gehören der Hochverfügbarkeitsmanager (separater Prozess) sowie eine Hochverfügbarkeits-API, über die Verbindungen zwischen Prozessen abgesichert werden können. Fällt ein Treiber, Protokoll-Stack oder eine Applikation aus, reißt sie keine anderen Komponenten mit. Stattdessen erkennt der Hochverfügbarkeitsmanager die Situation – während andere einen Reboot ausführen müssen, ist das QNX-basierte System sehr schnell wieder verfügbar.

Netzwerke

QNX unterstützt Standard-Netzwerktechnologie wie IPv4, IPv6, IPSec, FTP, HTTP, SSH, Telnet, etc. Darüber hinaus gibt es auch ein „natives“ Netzwerkprotokoll, mit dem eine transparente Verteilung von Ressourcen über das Netzwerk möglich ist.

Dateisysteme

Unter QNX Neutrino laufen auch Dateisysteme nicht als Teil des Kernels, sondern in einem separaten Bereich mit Speicherschutz. Das bedeutet nicht nur höhere Sicherheit, sondern auch, dass ein Dateisystem dynamisch gestartet oder wieder gestoppt werden kann. Mehrere Dateisysteme können je nach Bedarf parallel betrieben werden.

Portabilität

QNX Neutrino wurde als POSIX-konformes Echtzeit-OS entworfen. Dadurch ist es möglich, existierende Applikationen und Funktionsbibliotheken aus der Linux/Unix/Open Source Welt schnell zu portieren. Und da das QNX-Betriebssystem auf verschiedenen Embedded-CPUs läuft (ARM, Power Architecture, MIPS, x86, SH4) hält sich bei einem Wechsel der Hardware-Plattform der Portierungsaufwand sehr in Grenzen.

Der QNX Microkernel ist präemptierbar, das heißt durch externe Anforderungen unterbrechbar, und er verwaltet alle Threads mit prioritätsbasiertem, präemptivem Scheduling. Das Zeitverhalten des QNX Neutrino RTOS ist deshalb vorhersagbar, die Reaktionszeiten sehr kurz – beides Schlüsselbedingungen zur Erfüllung von Echtzeitanforderungen. Hochpriore Threads können auch bei hoher Systemauslastung zuverlässig ihre Deadlines einhalten.

Folgende Eigenschaften des QNX Neutrino RTOS tragen zu der exzellenten Echtzeit-Performance bei:

• Kurze Interruptlatenz- und Context Switch Zeiten helfen, die schnellstmögliche Reaktionszeit aus der entsprechenden Embedded-Hardware herauszuholen
• Prioritätsvererbungsmechanismen verhindern Prioritätsumkehr
• Das synchrone Message Passing von QNX hilft bei der Implementierung echtzeitfähiger Interprozess-Kommunikation
• Unterstützung von Interrupt-Nesting sowie eine Obergrenze für die Interruptlatenzzeit stellen sicher, dass hochpriore Interrupts Vorrang haben und in einem vorhersagbaren Zeitrahmen bearbeitet werden

Das QNX Neutrino RTOS ist ein echtes Microkernel-Betriebssystem – das bedeutet, dass im Kernel selbst tatsächlich nur die absolut notwendigen Betriebssystem-Grundfunktionen abgewickelt werden, also z.B. Signale, Timer und Scheduling. Alle anderen Komponenten – vor allem Treiber, Protokoll-Stacks, Dateisysteme – laufen, genau wie die Applikationen, in der sicheren Umgebung eines speichergeschützten Bereichs mit geringeren Privilegien. Das bedeutet enorme Robustheit nicht nur für OS-Subsysteme, sondern für alle Softwarekomponenten, die der Nutzer entwickelt oder integriert.

Die Kommunikation zwischen Applikationen und OS-Komponenten erfolgt über einen einheitlichen, klar definierten Messaging-Mechanismus. Dieser stellt eine Art virtuelles "Software-Bussystem" dar; jederzeit können neue Komponenten eingehängt oder auch entfernt werden. Das Message Passing funktioniert auch transparent über CPU-Grenzen hinweg, womit nahtloser Zugriff auf beliebige Ressourcen innerhalb eines Netzwerks von QNX-Systemen möglich wird.

QNX Neutrino RTOS microkernel

The QNX Neutrino RTOS microkernel isolates processes in memory-protected user space.

Fehlertoleranz und Recovery-Fähigkeiten

Seit über drei Jahrzehnten arbeitet QNX mit dem Konzept der Microkernel-Architektur, welche sich vielfach in anspruchsvollsten Umgebungen bewährt hat:

• Kommt es in irgendeiner Systemkomponente zu einer Störung – selbst in einem Low-Level-Treiber – kann dies nicht den Kernel oder andere Komponenten beschädigen
• Bei Ausfall einer Komponente kann das Betriebssystem diese kontrolliert beenden und alle Ressourcen sauber wieder freigeben – ein Reboot des Systems ist nicht nötig
• Stürzt eine Softwarekomponente ab, kann sie mittels eines definierbaren Recovery-Mechanismus wieder neu gestartet werden; der Hochverfügbarkeitsmanager ermöglicht auch das Auflösen von Abhängigkeiten

Elegantes Design mit Message Passing

Die QNX Microkernel-Architektur fördert durch die in ihrer Natur liegende Modularität einfaches und elegantes Systemdesign. Das QNX Message Passing:

• stellt einen einheitlichen Mechanismus zur Interprozess-Kommunikation (IPC) zur Verfügung
• ermöglicht den Aufbau verteilter, fehlertoleranter Systeme, in denen Ressourcen transparent über ein Netzwerk oder eine andere Verbindung verfügbar sind
• synchronisiert automatisch Interaktionen von kooperierenden Softwarekomponenten
• verwaltet das Queuing komplett automatisch
• ermöglicht es, komplexe Applikationen in sauber getrennte Blöcke aufzuteilen, welche unabhängig voneinander entwickelt und getestet werden können
• erlaubt es, Systemdienste mittels einfacher Standard-POSIX-Aufrufe zu nutzen – kein Kopfzerbrechen wegen komplizierter Interface-Layer

In Systemen mit hoher CPU-Auslastung muss verhindert werden, dass bestimmte Prozesse zu lange keine CPU-Zeit bekommen und somit quasi „verhungern”. Mit der QNX-Zeitpartitionierung kann auf einfache Weise sichergestellt werden, dass kritische Systemteile immer genügend Rechenzeit haben - nicht nur bei Echtzeitanforderungen ein großer Vorteil.

Die QNX-Zeitpartitionierung ist adaptiv – im Gegensatz zu statischen Lösungen geht hier keine CPU-Zeit verloren und man muss die Sicherheit der Partitionierung nicht mit einer größeren CPU oder mehr Entwicklungsaufwand bezahlen. Die Zeitpartitionierung ist außerdem unschätzbar hilfreich, wenn ein Projekt in die Software-Integrierungsphase geht und plötzlich sehr viele Softwarekomponenten um CPU-Zeit konkurrieren.

QNX Neutrino RTOS adaptive partitioning

QNX adaptive partitioning offers applications unused CPU capacity while guaranteeing required CPU cycles to critical processes.

Ein völlig neuer Ansatz

Die QNX-Zeitpartitionierung geht einen speziellen Weg: Sie garantiert den einzelnen Partitionen (Gruppen von Prozessen bzw. Threads) ein Mindestbudget an CPU-Zeit. Das bedeutet, dass Partitionen durchaus auch – wenn vorhanden – mehr CPU-Zeit verbrauchen können.

Der Systementwickler teilt das System in Partitionen auf und weist jeder einen Prozentsatz an CPU-Zeit zu. Unter normalen Umständen können die Partitionen so viel CPU-Zeit verwenden wie vorhanden ist. Ist die CPU jedoch unter Volllast, bedeutet das in der Regel, dass das System an seine Grenzen stößt und eigentlich mehr CPU-Zeit nötig wäre. Hier tritt dann die QNX-Zeitpartitionierung in Aktion und teilt die CPU-Zeit entsprechend der Mindestgarantien den Partitionen zu. Damit erhält man ein mächtiges Werkzeug an die Hand, mit dem sichergestellt werden kann, dass die entsprechenden Softwarekomponenten immer die für ihre einwandfreie Funktion minimal notwendige CPU-Power zur Verfügung haben.

Mehr Effizienz

Die QNX-Zeitpartitionierung ist adaptiv und darum effizienter als statische Ansätze:

• Ansätze mit statischen Partitionen wie z.B. ARINC 653 verschwenden Rechenleistung: CPU-Zeit, die in einer Partition nicht genutzt wird, geht einfach verloren und kann nicht an andere Partitionen verteilt werden. Statt einer Mindestgarantie an CPU-Zeit muss man für die entsprechende Partition also deren Maximalbedarf vorsehen.
• Bei der QNX-Zeitpartitionierung können Prozesse auch mehr Zeit verbrauchen als zugewiesen, wenn ansonsten CPU-Zyklen ungenutzt blieben. Bei Vollauslastung wird sichergestellt, dass jede Partition ihr entsprechendes Zeitbudget erhält.

Mehr Sicherheit

Mit der QNX-Zeitpartitionierung werden Ihre Systeme sicherer:

• Denial-of-Service (DoS) Angriffe basieren auf Überlastung bestimmter Systemkomponenten. Mit Zeitpartitionierung können diese in einer Partition gekapselt werden, so dass ein DoS-Angriff keine systemweiten Folgen hat.
• Mit Zeitpartitionierung können zugekaufte oder nicht validierte Softwarekomponenten anderen, wichtigen Systemteilen nicht unbegrenzt CPU-Zeit entziehen.

Sich selbst überwachende Systeme

Die Zeitpartitionierung hilft, sich selbst überwachende Systeme aufzubauen:

• Mittels CPU-Zeit-Garantien ist sichergestellt, dass Fehlerabfang- und Recovery-Mechanismen immer aktiv sind.
• Selbst bei einem völlig überlasteten System hat ein Administrator über ein mittels Zeitpartitionierung abgesichertes Interface (lokal oder remote) noch Zugriff und kann den Gesamtzustand analysieren.

Echtzeitverhalten sicherstellen

Die QNX-Zeitpartitionierung kann auch helfen, den für Echtzeitanforderungen wichtigen Determinismus sicherzustellen:

• CPU-Zeit von Partitionen, die gerade nicht beschäftigt sind, wird dynamisch an andere Partitionen vergeben, die von mehr CPU-Zeit profitieren können.
• Verfügbare CPU-Zeit wird dem ausführbereiten Thread mit der höchsten Priorität zugewiesen.
• Entwickler können Threads als “critical” definieren – diese Threads laufen unabhängig von Zeitbudget und CPU-Auslastung.

Garantierte Reaktionszeiten

Die Zeitpartitionierung ermöglicht garantierte Reaktionszeiten auf Events, ohne dass man ständig mit verschiedenen Thread-Prioritäten jonglieren muss:

• Dem User-Interface eines Geräts kann ein Mindestbudget an CPU-Zeit zugewiesen werden, so dass es garantiert und immer gleich schnell auf Benutzereingaben reagiert – egal ob Knopfdruck oder Sprachbefehl.
• Bei der Medienwiedergabe hilft eine garantierte Mindest-CPU-Zeit, Aussetzer zu vermeiden.

Effizientere Produktentwicklung

Die QNX-Zeitpartitionierung kann helfen, signifikante Einsparungen beim Integrations- und Debugging-Aufwand von komplexen Embedded-Systemen zu erzielen:

• Für jede wichtige Systemkomponente kann ein CPU-Budget festgelegt werden. Damit wird die zeitintensive und fehleranfällige nachträgliche Anpassung von Prioritäten einzelner Threads vermieden.
• Die für die Integration der Softwarekomponenten zuständigen Entwickler können die Zeitbudgets variieren und je nach Projektanforderung ändern – ohne den Code anpassen oder neu kompilieren zu müssen.

Einfache Anwendung

Die QNX-Zeitpartitionierung ist einfach anzuwenden:

• Die Zeitpartitionierung kann auch nachträglich in ein QNX-System eingebaut werden, Anpassungen an existierenden Applikationen oder anderen Prozessen sind nicht notwendig.
• Die Partitionsparameter werden konfiguriert, nicht programmiert. Um eine CPU-Zeit-Garantie zu gewährleisten, sind keine Eingriffe in den Source Code von Programmen erforderlich.

Um eine sehr hohe Systemverfügbarkeit zu ermöglichen, stellt das QNX Neutrino RTOS zwei grundlegende Mechanismen bereit:

• Kapselung – Jede Softwarekomponente wird von jeder anderen isoliert, dadurch werden bei Ausfall einer Komponente die Auswirkungen auf das Gesamtsystem minimiert.
• Recovery-Mechanismen – Programmierbare Recovery-Mechanismen setzen das System ohne Reboot wieder in Funktion, das ermöglicht eine sehr niedrige Mean Time to Repair (MTTR).

Diese Möglichkeiten ergeben sich durch das Zusammenspiel des Speicherschutzes für alle Komponenten und den Einsatz unseres Hochverfügbarkeits-Frameworks.

Zusätzlich kann die Verfügbarkeit eines Systems gesichert werden durch:

• Redundante Systemdienste – Das QNX “Transparent Distributed Processing” (verteilte Netzwerk-Architektur) ermöglicht den einfachen Aufbau redundanter Systemdienste und -ressourcen.
• CPU-Zeit-Garantien – Die QNX Zeitpartitionierung stellt garantierte Mindest-CPU-Zeitbudgets bereit, so dass wichtige Softwarekomponenten in jedem Fall ans Laufen kommen.

So funktioniert die Kapselung

Die QNX Microkernel-Architektur sorgt dafür, dass ein Fehler in einer Softwarekomponente auf diese beschränkt bleibt:

• Mithilfe der MMU wird für alle Komponenten – ohne Ausnahme – ein jeweils separater Speicherbereich bereitgestellt. Was auch immer innerhalb dieses Bereiches passiert, andere Komponenten oder gar der OS-Kernel können nicht beschädigt oder überschrieben werden.
• Hardware-Treiber oder Systemdienste (z.B. Netzwerk-Stack oder Dateisystem) werden ebenso behandelt und können deshalb bei Problemen automatisch neu gestartet werden, ohne andere Systemteile zu beeinflussen.
• Das dem POSIX-Standard entsprechende Prozessmodell stellt sicher, dass jeder Ressource ein Besitzer zugeordnet werden kann. Wird ein Prozess unerwartet beendet, kann das Betriebssystem alle Ressourcen sauber wieder freigeben.

So funktioniert der Recovery-Vorgang

Das QNX Hochverfügbarkeits-Framework stellt eine Infrastruktur bereit, um hochverfügbare Systeme aufzubauen. Damit wird nicht nur die softwareseitige Implementierung von Hardware-orientierten Lösungen vereinfacht, sondern auch Werkzeuge bereitgestellt, mit denen auf Software-Fehler reagiert werden kann, bevor sie einen Domino-Effekt im System verursachen. Entwickler können projektspezifische Recovery-Szenarios programmieren und damit Systeme aufbauen, die sich im Fehlerfall selbst und ggf. vom Nutzer unbemerkt wieder herstellen.

System mit Selbstheilungskräften

Das Hochverfügbarkeits-Framework ermöglicht:

• Automatischen Neustart beliebiger Softwarekomponenten – ohne System-Reboot
• Automatische Wiederherstellung der Interprozess-Kommunikationsverbindungen von reinitialisierten Komponenten
• Programmierbare Recovery-Aktionen, mit denen Applikationen auf Fehlersituationen reagieren können, um die Konsequenzen zu minimieren und schnell wieder in einen definierten Zustand zu gelangen

Der Hochverfügbarkeitsmanager

Der Hochverfügbarkeitsmanager (High Availability Manager, HAM) ist ein „Software-Watchdog” – ein Hintergrundprozess, der das System überwacht und mehrstufige Recovery-Aktionen durchführen kann, wenn ein Applikationsprozess, Treiber oder Systemdienst abstürzt oder nicht mehr reagiert.

Außerdem wird er durch eine zweite Instanz seiner selbst überwacht, so dass selbst in dem unwahrscheinlichen Fall, dass der HAM selbst unerwartet beendet wird, sofort der zweite HAM übernimmt.

Das Hochverfügbarkeits-Framework enthält eine Library mit einer API zum HAM. Damit ist eine einfache Kommunikation mit dem HAM möglich, die außerdem thread-safe ist. Ferner ist eine Client Recovery Library enthalten, welche spezielle Recovery-fähige Varianten vieler Standard-I/O-Funktionen aus der libc bereitstellt.

Das QNX Neutrino RTOS unterstützt diverse Netzwerkprotokolle, unter anderem:

• IPv4/IPv6(basierend auf NetBSD 4.0)
• SNMP v1/v2/v3
• L2 VLAN, QoS, STP
• 802.11a/b/g, WPA, WPA2, WEP

Sicherheitsrelevante Protokolle:

• IPSec, IKE, SSL, SSH, NAT, IP filtering
• Open Cryptography API
• Hardwarebeschleunigung für Paketbearbeitung

QNX networking protocols

QNX Software Systems offers one of the most comprehensive networking solutions for connected and distributed systems.

TCP/IP Stack RFC Support

QNX Software Systems erweitert ständig die Unterstützung diverser Netzwerkprotokolle. Sollten Sie in der folgenden Liste ein von Ihnen benötigtes Protokoll nicht finden, kontaktieren Sie uns bitte.

Das QNX Transparent Distributed Processing (TDP) ist eine Softwaretechnologie für die Nutzung von in einem Netzwerk verteilten Ressourcen. Mehrere Rechner können damit wie ein einziger betrachtet werden. Das bedeutet:

• In einem Gerät “vernetzte” Rechner, die über eine Backplane oder andere Verbindungstechnik gekoppelt sind, können damit auf einfache Weise zusammengeschaltet werden
• In einem auf mehreren verteilten Rechnerknoten basierenden System können standortunabhängig Daten gelesen, Prozesse verwaltet oder Steuerungsaufgaben durchgeführt werden

Abstraktion der Verteilung von Ressourcen

Das TDP ermöglicht die Nutzung des QNX Message Passing über beliebige Netzwerktechnologien. Hard- und Software-Ressourcen auf Netzwerkknoten lassen sich damit so nutzen als wären es lokale Ressourcen – über Standard Message Passing. Eine Ressource kann dabei quasi alles sein: Systemdienst, Datenbank, Hardware-Interface, Message Queue, Dateisystem ...

Die Nutzung einer Ressource ist unabhängig von deren Standort im Netz: Jeder Knoten kann jede Ressource nutzen.

Transparent distributed processing

QNX transparent distributed processing allows an application to access resources on any node in the network, across virtually any network interconnection technology.

So funktioniert die Standortunabhängigkeit

Die Standortunabhängigkeit von Ressourcen im Netz wird über einen globalen Namensauflösungsdienst realisiert, dabei können:

• sich mehrere gleiche Hardware-Komponenten im Netz für den selben Service registrieren
• die registrierten Ressourcen automatisch im Netz bekannt gemacht werden
• die Applikationen ebenso wie die zu nutzenden Software-Ressourcen flexibel zur Laufzeit auf die Netzwerkknoten aufgeteilt werden

Redundanz und Load Balancing

Mit TDP lassen sich redundante Ressourcen mit Load Balancing realisieren:

• Unterstützung für mehrere Verbindungen zwischen Rechnern – bricht eine ab, wird automatisch eine andere, noch funktionierende Verbindung verwendet, die Ressource bleibt verfügbar
• Netzwerkverkehr kann per Load Balancing über mehrere Verbindungen geleitet werden, um höheren Durchsatz zu erreichen
• Applikationen können bei Verbindungsaufnahme einen präferierten Knoten angeben, doch fällt dieser aus, wird transparent auf einen anderen umgeschaltet

Datenaustausch über beliebige Verbindungen

Transparent Distributed Processing arbeitet eine Ebene über dem Transport Layer, ist also nicht von einer bestimmten Hardware-Infrastruktur abhängig. Es kann genutzt werden über LANs, Backplanes, proprietäre Verbindungssysteme, Automotive-Busse wie CAN oder MOST bis hin zum Internet.

Effizientere Produktentwicklung

TDP kann helfen, Zeit und Kosten zu sparen. Mit TDP entfallen die herkömmlichen, oft schwerfälligen Netzwerk-Interprozess-Kommunikationsmechanismen. Ohne irgendwelche speziellen APIs oder Bibliotheken können Applikationen und Systemdienste im Netzwerk verteilt werden – die Kommunikation über Message Passing ist gleich, ob lokal oder übers Netzwerk:

• Sowohl für Applikationen (Clients) als auch Ressourcen (Server) ist die Arbeit über das Netzwerk transparent – es ist keine explizite Netzwerkprogrammierung erforderlich
• Prozesse, die auf einem Rechner miteinander kommunizieren, können auf mehrere Rechner verteilt werden und genauso weiter kommunizieren. Bei verteilten Systemen können Entwickler somit die vorhandenen Kapazitäten (CPU-Power, Speicher, angeschlossene Hardware) aller Knoten von überall nutzen und somit enorm effiziente Systeme aufbauen.
• Die Entwicklung von fehlertoleranten Systemen wird vereinfacht – wenn ein Rechner nicht verfügbar ist, kann ein anderer dessen Aufgaben transparent übernehmen.
• Beim Debuggen können Multi-Link-Verbindungen helfen, Daten abrufbar zu halten, auch wenn eine Verbindung temporär unterbrochen ist.

QNX bietet verschiedene Dateisysteme an, die Vorteile sind:

• Ein Dateisystem wird außerhalb des Kernels ausgeführt – als Prozess mit vollem Speicherschutz im User-Mode der CPU. Damit können Dateisystem-Module auch im laufenden Betrieb gestoppt, gestartet und aktualisiert werden ohne einen Reboot erforderlich zu machen.
• Der Zugriff erfolgt grundsätzlich über Standard-POSIX-Aufrufe wie open(), read(), write(), close(), etc.
• Selbstverständlich können auf einem System mehrere Dateisysteme parallel genutzt werden. Kompressionsmöglichkeiten können helfen, den Bedarf an Flash-Speicher zu reduzieren.

Der QNX Pathname-Space

Die QNX-Dateisysteme arbeiten innerhalb des QNX Pathname-Space. Dieser Pathname-Space ermöglicht es, an beliebiger Stelle lokale und remote Dateisysteme einzuhängen. Der Pathname-Space ist immer vorhanden, auch wenn keine Festplatte oder Flash-Dateisystem gemountet ist. QNX-Systeme können von diversen Speichermedien oder über das Netzwerk booten.

Überblick Dateisysteme

Embedded-Dateisysteme – NOR- und NAND-Flash

QNX Flash-Filesysteme bieten Zuverlässigkeit auf Filesystem-Ebene:

• Verschiedene Mechansimen stellen sicher, dass ein unerwarteter Stromausfall nicht zu einem korrupten Dateisystem führt
• Wear-Leveling hilft, die Lebensdauer der Flash-Bausteine zu erhöhen

ETFS transaction structure

ETFS is a power-safe filesystem composed entirely of transactions.

Dateisystem-Eigenschaften

QNX NOR- und NAND-Dateisysteme...:

• führen im Hintergrund Reclaim-Operationen durch, um nicht mehr benutzten Flash-Speicher freizugeben und Verzögerungen beim Schreiben/Löschen von Blöcken bei Applikationsanforderungen zu reduzieren
• arbeiten mit RAM-Cache, um Zugriffe zu beschleunigen
• können mit Datenkompression genutzt werden, um Flash-Speicherbedarf zu reduzieren

POSIX/ISO-C Dateizugriffe

QNX NOR- und NAND-Dateisysteme unterstützen:

• Standard Datei-Stream-Operationen
• Dynamisches Erzeugen und Verändern von Dateien und Verzeichnissen
• Symbolische Links, lange Dateinamen, Zugriffsrechte
• Auf das Flash kann auch direkt über ein Raw-Interface zugegriffen werden, um mit Standard POSIX-Tools wie cp oder dd neue Boot-Images zu schreiben

NOR-Flash-Dateisystem

NOR-Flash-Chips werden mit dem QNX Flash Filesystem Version 3 (FFSv3) angesprochen.

Konsistenzüberprüfung

Dateisystem-Metadaten werden in sauber sequenzierten Vorgängen aktualisiert, um eine höchstmögliche Integrität selbst nach einem Stromausfall zu erreichen. Beim Systemstart wird das Dateisystem auf Konsistenz überprüft und Probleme mit der Datenintegrität so weit wie möglich behoben.

Bad Block Management

Fehlerhafte Blöcke werden gekennzeichnet und transparent für Applikationen nicht genutzt.

NAND-Flash-Dateisystem

NAND-Flash wird durch das QNX Embedded Transaction Filesystem (ETFS) unterstützt.

Durch Stromausfall verursachte Dateisystem-Probleme vermeiden

Durch atomare Transaktionen bei Datei- und Verzeichnisoperationen wird sichergestellt, dass die Dateisystem-Integrität selbst bei Stromausfällen gewahrt bleibt.

Block-Integrität

Das QNX-NAND-Dateisystem überwacht den Zustand der Blöcke:

• Vom Hersteller als Bad Blocks gekennzeichnete Blöcke werden automatisch von der Nutzung ausgeklammert
• Viel gelesene Blöcke werden umkopiert, bevor sie ihre normale Obergrenze an Lesezyklen erreichen, so dass der ECC-Recovery-Mechanismus nur selten aktiv werden muss

Defragmentierung

Das QNX NAND-Dateisystem ist transaktionsbasiert und versucht darum, Fragmentierung vorzubeugen, um die Anzahl der Transaktionen niedriger zu halten:

• Schreibzugriffe können gepuffert werden, so dass zahlreiche kleinere Schreibtransaktionen zusammengefasst werden, bevor sie ins NAND geschrieben werden.
• Im Hintergrund wird automatisch defragmentiert, wobei Applikationsaktivität stets Vorrang hat.

Komplettkopie möglich

Die Filesystem-Daten sind nicht fix blockgebunden, d.h. das gesamte Dateisystem kann komplett von einem NAND-Flash-Baustein auf einen anderen kopiert werden.

Mit dem QNX Neutrino RTOS sind besonders schnelle Bootvorgänge möglich:

• Booten ohne BIOS – auf x86-Systemen kann QNX auch ohne BIOS gebootet werden
• Volle Kontrolle des Bootvorgangs – Dank Microkernel können wichtige Applikationen noch vor bestimmten Treibern gestartet werden
• Instant Device Activation (IDA) – Mittels eines “Mini-Treiber”-Konzepts können schon Hardwarezugriffe erfolgen, während der Kernel noch initialisiert wird; später wird die Kontrolle an einen Standard-Treiber übergeben

Booten ohne BIOS

QNX ermöglicht auf x86-Systemen das Booten ohne BIOS, indem die Systeminitialisierung durch eigenen Code erfolgt. Diese speziell auf die entsprechende Hardware angepasste Initialisierungsfunktionalität erspart langwierige Wartezeiten durch BIOS-Funktionen (z.B. Suchen von Tastatur oder USB-Geräten).

Auf x86-Systemen übernimmt das BIOS in der Regel eine Menge an Grundinitialisierung des Systems und integrierter Peripherie. Bei QNX kann dies auf Treiberebene unabhängig vom BIOS geschehen. Dadurch kann der Systemdesigner festlegen, wann welche Hardwareteile initialisiert werden sollen. Das heißt: Für später benötigte Funktionen des Systems kann die entsprechende Hardware auch erst später initialisiert werden, so dass schnelleres Booten möglich wird.

Bei der Entwicklung einer Bootsequenz ohne BIOS können bestimmte Teile, z.B. Interruptzuweisungen, für die tatsächlich vorliegende Embedded-Hardware programmiert werden, man hat also viel mehr Einfluss, als wenn man alles dem BIOS überlassen muss. Die Hardware kann so aufgebaut werden, dass in einem linear eingemappten Chip (Flash oder EEPROM) schon Teile des Betriebssystems liegen, welche dann besonders schnell starten. Von da aus können dann z.B. Massenspeichermedien-Treiber (HD, NAND-Flash oder USB) gestartet werden, um weitere Systemteile nachzuladen.

Volle Kontrolle über den Bootvorgang

Da für den QNX Microkernel alle Softwarekomponenten einfach Prozesse sind, ist es sehr einfach, deren Startreihenfolge frei vorzugeben. Gibt es während des Bootvorgangs freie CPU-Zeit, kann der Entwickler diese mit parallelem Start weiterer Module füllen. Einfaches Beispiel: Ein System könnte beim Booten als erstes den Audiotreiber starten und ein kurzes Jingle abspielen, währenddessen werden dann schon weitere Treiber und Applikationsteile geladen.

Instant Device Activation

Die QNX Instant Device Activation (IDA) ermöglicht es, extrem kurze Zeitvorgaben bezgl. Verfügbarkeit zu erreichen, z.B. den Empfang und die Bestätigung von CAN-Bus-Nachrichten bei einem Cold Boot.

IDA boot process

Instant device activation brings a minidriver up before the kernel initialization to meet early boot requirements, then hands control over to the OS.

Kritische Funktionalität sofort verfügbar

IDA basiert auf einem Konzept mit “Mini-Treibern”, welche schon starten, bevor der OS-Kernel initialisiert wird. Diese Mini-Treiber können:

• auf externe Events reagieren (um die Anforderungen an die Antwortzeiten einzuhalten), auf Hardware zugreifen und Daten puffern, um sie später an den eigentlichen Treiber zu übergeben
• wenn der eigentliche Treiber läuft, entweder parallel weiterlaufen oder im Hintergrund terminieren – ohne Blackout-Momente oder Datenverlust

IDA kann Hardware-Kosten senken

Die IDA-Technik kann Hardware-Kosten sparen, weil sie:

• Daten von Bussystemen wie MOST oder CAN direkt bearbeiten kann, so dass komplexe Power-up-Szenarien entfallen
• die Verwendung von separaten Microcontrollern unnötig macht, die ansonsten eingesetzt werden, um zeitliche Anforderungen einhalten zu können

Anpassbarkeit

Der Source Code der IDA-Mini-Treiber erlaubt die Anpassung an verschiedene projektspezifische Anforderungen, z.B.:

• Anpassung von Polling-Intervallen, um zeitlichen Anforderungen gerecht zu werden
• Puffergrößen verändern
• Zeitpunkt und Mechanismen des Übergangs vom Mini-Treiber zum eigentlichen Treiber anpassen

Persistent Publish/Subscribe (PPS) ist ein praktischer Mechanismus zum Datenaustausch in Embedded-Systemen. PPS erlaubt den Aufbau lose gekoppelter Prozesse, die Daten asynchron verfügbar machen bzw. lesen. Die Kommunikation zwischen Softwarekomponenten ist damit nur noch von den Daten selbst abhängig, Programmiersprache oder Datenursprung spielen für die Gegenseite keine Rolle. Die Möglichkeiten im Einzelnen:

• Publisher- und Subscriber-Beziehungen können eins zu eins, eins zu viele und viele zu eins sein.
• Das Interface basiert auf Objektnamen, wodurch Softwarekomponenten einfacher ausgetauscht und integriert werden können.
• Nutzbar mit allen Programmiersprachen wie z.B. C, C++, Java, Python, Perl oder Shellscripten.
• Objekteigenschaften können auf persistenten Speichermedien abgelegt werden, so dass sie ohne zusätzlichen Programmieraufwand nach einem Neustart sofort wieder zur Verfügung stehen.
• Auch On-Demand-Publishing (statt Push) wird unterstützt.

Die Microkernel-Architektur von QNX bedeutet nicht nur höhere Zuverlässigkeit aller Softwarekomponenten, sondern bringt im Vergleich zu herkömmlichen monolithischen Betriebssystemen auch beim Thema Multicore einige interessante Vorteile.

Das Problem beim monolithischen Kernel

Monolithische Betriebssystem-Kernel wie z.B. bei Microsoft Windows oder auch Linux haben im Multicore-Betrieb ein Problem: Beim Zugriff auf Kernel-Funktionen benötigt man entweder einen globalen Kernel-Lock-Mechanismus oder viele kleine Struktur- und Code-Locks. Die Nachteile:

• Die Verwendung eines globalen Kernel-Locks kann zu gravierenden Verzögerungen führen, wenn ein Programm Kernel-Funktionalität benötigt, der Kernel jedoch gerade auf einem anderen Core läuft.
• Nutzt man viele kleine, funktionsabhängige Locks, führt dies zu komplexerem Code und verschachtelten, schwer nachvollziehbaren Abhängigkeiten, ohne das eigentliche Problem zu lösen – Zugriffe auf bestimmte Funktionalität können immer noch stark verzögert werden, je nachdem welche Subsysteme gerade von anderen Programmen in Anspruch genommen werden

Wie der Microkernel das Locking-Problem löst

Beim QNX Microkernel-Konzept sind nur genau die Funktionen Teil des Kernels, für die unbedingt Kernel-Privilegien erforderlich sind. Diese Operationen sind zahlenmäßig begrenzt und sehr schnell durchgeführt. Ein Kernel-Lock ist deshalb viel seltener überhaupt erforderlich und wenn, wird er schnell wieder freigegeben.

Länger dauernde Systemaktivitäten – inklusive Prozessverwaltung – laufen als Threads und werden deshalb ganz normal geschedulet, wie andere Threads auch (Applikationen, Treiber, Protokoll-Stacks usw.). Für den Multicore-Betrieb bedeutet das: Diese Threads können vom Microkernel über die verfügbaren CPU-Cores verteilt werden.

Effiziente Nutzung von Multicore

QNX ermöglicht schnelle Entwicklung von Applikationen, die Multicore-Power richtig ausnutzen:

• Existierende Applikationen weiterverwenden, Threads werden automatisch auf die Cores verteilt
• Analysetools zeigen grafisch, wie sich Ihr Multicore-Systeme verhält
• Unterstützung von Multicore-Debugging und -Optimierung
• SMP und BMP erlauben jeder Applikation Zugriff auf alle Systemressourcen (im Gegensatz zu AMP oder Virtualisierungsansätzen)

Bound Multi-Processing (BMP) ist eine von QNX entwickelte Erweiterung des SMP-Konzepts der “Prozessor-Affinität”. Es hilft Entwicklern oder auch dem Systemintegrator, Prozesse sauber an einen bestimmten Prozessor zu binden, ohne Änderungen im Code vornehmen zu müssen. BMP ist in einigen Szenarien von großem Vorteil:

• Erhebliche Erleichterung bei der Migration von Legacy Code, der (anstatt die vorgesehenen Synchronisationsmethoden zu nutzen) sich darauf verlässt, auf einer einzelnen CPU zu laufen
• Sehr viel einfacher zu implementieren als asymmetrisches Multi-Processing (AMP), z.B. wenn man einen oder mehrere Cores für die Datenverarbeitung, andere wiederum für die Steuerung reservieren möchte
• BMP kann unnötige Core-to-Core Migration verhindern, so dass der CPU-Cache optimal genutzt werden kann (Vermeidung von wiederholtem Cache Flushing)

Bound multi-processing use case

QNX Software System's unique BMP technology enables developers to bind processes and threads to a specified processor without code changes.

Wie QNX den Multicore-Betrieb optimiert

Das QNX Neutrino RTOS nutzt primär zwei Ansätze, um im BMP-Betrieb die Performance zu optimieren: Soft Affinity und Runmasks.

Soft Affinity

Wenn möglich, versucht das QNX OS, einen Thread auf genau den CPU-Kern zu schedulen, auf dem dieser das letzte Mal gelaufen ist, damit der entsprechende CPU-Cache wiederverwendet werden kann.

Runmasks

Jeder Thread hat eine sog. Runmask, das ist ein Feld mit Bits, die angeben, auf welchem CPU-Kern der Thread laufen oder nicht laufen darf. Normalerweise erbt ein Thread seine Runmask von seinem Parent, damit sichergestellt ist, dass alle Threads des Prozesses an denselben Prozessor gebunden sind. Die Runmasks können aber für jeden Thread jederzeit dynamisch geändert werden. Der Systemdesigner hat damit die Möglichkeit, Fine-Tuning zu betreiben, in dem er bestimmte Threads bestimmten CPU-Kernen zuweist oder für ausgewählte Systemfunktionen eine oder mehrere CPUs reserviert.

Die QNX® Momentics® Tool Suite unterstützt Sie auf vielfältige Weise bei der Entwicklung von Multicore-basierten Systemen. Debugger, Profiler und weitere Analyse-Werkzeuge berücksichtigen Multicore-Aspekte. Auch existierende Software, die eigentlich nie für Multicore-Betrieb gedacht war, lässt sich mit diesen Tools auf Multicore migrieren.

• Application Profiler – zeigt Bottlenecks auf, wo besonders viel CPU-Zeit verbraucht wird und hilft, Programmteile zu finden, bei denen eine Parallelisierung mittels Multithreading lohnenswert wäre
• System Profiler – visualisiert die Auslastung jedes CPU-Kerns mit sehr hoher zeitlicher Auflösung, zeigt Inter-Core-Kommunikation an und hilft, Verzögerungen durch Resource Contention aufzudecken
• Source Level Debugger – erlaubt das parallele Debuggen mehrerer Prozesse und Threads auf mehreren Cores
• Blocking-Analyse – hilft z.B. bei der Nutzungsverfolgung geteilter Ressourcen

Siehe auch: QNX Momentics Tool Suite