• Verwendung von PC-Technologie für Internet-Geräte

   

• Echtzeit-Erweiterungen für Windows NT
  Die richtige Wahl für Ihr nächstes Echtzeit-Projekt ?

Verwendung von PC-Technologie für Internet-Geräte

Dan Hildebrand
Senior Architect, R&D
QNX Software Systems Ltd.
danh@qnx.com

Zusammenfassung

Der riesige, rasant wachsende PC-Markt produziert eine Vielzahl von Werkzeugen und Plattformen, die Hersteller zur Entwicklung von Internet-Geräten verwenden können - vom Web-Browser bis hin zu hoch integrierten embedded Prozessoren. Nichts desto trotz bleibt ein Problem: Die Betriebssystem-Umgebungen für den Desktop-PC erzwingen typischerweise enormen Overhead bei Platten- und Hauptspeicherkapazitäten und sind daher nicht für das Preissegment eines Konsumproduktes geeignet. Die ideale Lösung? Eine auf Standards basierende Echtzeit-Betriebssystem-Umgebung, die speziell für Runtime-Systeme mit minimalen Prozessor- und Speicherressourcen entwickelt wurde.

Diese Abhandlung untersucht, wie eine solche Lösung es ermöglicht, basierend auf dem QNX^® Echtzeit-Betriebssystem und der grafischen Benutzeroberfläche Photon microGUI preisgünstige, hoch-performante Internet-Geräte zu entwickeln, die der schnellen Entwicklung der Internet-Dienste folgen können. Da sich PC-Hardware genauso schnell weiterentwickelt, befaßt sich diese Abhandlung auch mit Fragen im Zusammenhang mit Produkt-Lebenszyklen (Konfiguration, Skalierbarkeit, Updates und Erneuerung) und untersucht embedded PC-Hardware, die den langfristigen Anforderungen der Hersteller von Internet-Geräten genügt.

Einführung

Mit der weitverbreiteten Verfügbarkeit von kosten-günstigen 32-Bit Mikroprozessoren können Anwendungen, die zuvor nur auf einem Desktop vorhanden waren - inklusive Applikationen für den Zugriff auf das Internet - nun in eine Vielzahl von embedded Systemen und "appliance-class"-Geräten integriert werden. Beispiele hierfür sind z.B. digitale Set-Top-Boxen (STBs) für Fernseher, "Smart Phone"-Telefone für Zuhause oder das Büro sowie Intranet-Geräte für industriespezifische Anwendungsbereiche, wie z.B. Kassensysteme. In dieser Abhandlung bezeichnen wir all diese Geräte mit Internetzugriff als `Internet-Geräte' ("Internet Appliances").

Derzeit werden bereits verschiedene Referenz-Entwürfe für Internet-Geräte entwickelt: beginnend bei selbstgestrickten Betriebssystem-Kernels, die auf kostengünstigen embedded Prozessoren laufen, bis hin zu Desktop-Betriebssystemen, die auf modi-fizierten PC-Workstations laufen, komplett mit MPEG-Hardware für "Live-Video". Während diese Referenzplattformen bereits zeigen, wohin der Trend bei Internet-Geräten letztendlich führen wird, bieten die meisten verfügbaren Internetverbindungen für den Verbraucher (Modem, Kabelanschluß usw.) nicht die entsprechende Infrastruktur und Netzwerk-bandbreite, um Dienste wie z.B. "Video-on-demand" liefern zu können. Trotzdem können Internet-Geräte bereits jetzt auf verschiedene wichtige Informations-dienste zugreifen, inklusive des World Wide Webs.

Internet-Dienste- und Technologien entwickeln sich mit atemberaubender Geschwindigkeit. Daher haben Produkte, die diesen Technologien nicht folgen können, kaum eine Chance, im Markt Fuß zu fassen. Um die Nachfrage der Verbraucher befriedigen zu können, müssen sowohl Software als auch Hardware von Internet-Geräten skalierbar sein im Idealfall durch von Kunden selbst durchgeführte Upgrades. Des weiteren müssend diese Komponenten relativ billig sein, damit das Gerät regelmäßig ersetzt oder ausgetauscht werden kann, sobald es veraltet ist.

Innerhalb dieses turbulenten Marktes haben Produkt-entwickler die Aufgabe, Produkte zu entwerfen, die wenig kosten aber dennoch eine hohe Funktionalität bieten. Sie sind zudem noch einem außergewöhnlichem "Time-to-Market"-Druck ausgesetzt. So betreiben Hersteller z.B. einen erheblichen Aufwand, um bei der Entwicklung von Produkten die "Manufacturability" zu optimieren, also die Kosten des Herstellungsprozesses so gering wie möglich zu halten. Durch den inhärent kurzen Lebenszyklus jeglicher Geräte mit Internetzugriff muß diese Phase für Kostenreduzierungen so kurz wie möglich sein. Des weiteren muß das Design die Möglichkeit bieten, schnelle Updates ohne eine komplette - und teure - Umrüstung des Fertigungs-prozesses durchzuführen.

Glücklicherweise müssen Hersteller die erforder-liche Technologie nicht erst entwickeln, um den sich ständig ändernden Funktionalitätsanforderungen zu folgen. Statt dessen können sie diese Technologie von einer bereits existierenden Quelle ausleihen: dem Desktop-PC.

Warum PC-Technologie?

Mit riesigem Marktanteil und Tausenden Herstellern weltweit ist die PC-Plattform der de facto Standard für ein breites Anwendungsspektrum und bietet einen bewährten Satz von Standard-Werkzeugen. Tatsächlich wird ein Großteil der Technologie, die für Internet-Geräte benötigt wird, mit und für den Desktop-PC entwickelt. Ein vom PC abgeleitetes Design für ein Internet-Gerät profitiert vom vermin-derten Entwicklungsaufwand und -risiko.

So wurde z.B. während der frühen Diskussionen über "Video-on-Demand" für Set-Top-Boxen die Echtzeitdekompression von MPEG-Videodaten als erhebliches Performanceproblem identifiziert und hoch-performante RISC-Prozessoren wurden routinemäßig als Lösung vorgeschlagen. Zur gleichen Zeit begann die Multimedia-Bewegung im Desktop-PC-Bereich eine Reihe von MPEG-fähigen Grafik-Chipsätzen und Erweiterungen von CPU Befehls-sätzen (z.B. MMX) zu generieren. Letztendlich hat die große Nachfrage nach Desktop-Multimedia - zusammen mit den Effekten der Massenproduktion - kostengünstige dedizierte Chips hervorgebracht, die das MPEG-Performanceproblem lösten, sogar wenn diese Chips mit Low-End PC-Prozessoren kombiniert wurden. Der Netto-Effekt: Set-Top-Boxen mit Live-Video, deren Technologien vom PC abgeleitet wurden.

Reichhaltiges Angebot an Werkzeugen

Mit der Verfügbarkeit von verschiedenen PC-Technologien für die Integration in Internet-Geräte werden auch andere Vorteile der PC-Architektur relevant. So bietet z.B. der Desktop-PC unbestritten das reichhaltigste Sortiment an Betriebssystemen, Entwicklungswerkzeugen und Peripheriegeräten für den Entwickler von embedded Systemen. Da ein vom PC abgeleitetes Gerät architektonisch verg-leichbar mit einem Desktop-PC ist, werden der PC und die dafür verfügbare Software zu natürlichen Prototyping-Werkzeugen für den Entwickler von Internet-Geräten. Es gibt einen weiteren, noch wichtigeren Vorteil: Die Anlehnung der Architektur von Internet-Geräten an den Desktop-PC erleichtert die Migration von Hardware- und Software-Technologien auf die Internet-Geräte, weil Internet- und Multimedia-Technologien ursprünglich auf dem Desktop-PC entstehen.

Eine zu direkte Koppelung an die Entwicklung der PC-Technologie birgt allerdings auch Gefahren. Es ist zwar relativ einfach, ein PC-kompatibles embedded System zu entwerfen, indem man ein x86-Prozessor mit einem PC-Motherboard-Chipset kombiniert, jedoch macht das Erscheinen der nächsten Generation die meisten Chipsets sehr schnell überflüssig. So werden die Hersteller von Motherboard-Chipsets durch den Wettbewerb gezwungen, alle sechs Monate neue Versionen zu entwickeln. Offensichtlich benötigen Produkte, die auf diesen Komponenten basieren, regelmäßig eine Überarbeitung des Designs, nur um die Produktion aufrecht erhalten zu können. Der Hersteller muß entweder langfristige Verein-barungen mit den Komponenten-Herstellern treffen oder den Redesign-Zyklus des Geräts beschleunigen, um der Desktop-PC-Hardware folgen zu können (eine praktikable Lösung, da der Markt für Internet-Geräte erfordern könnte, daß die Produkt-Leben-szyklen im Verhältnis zu anderen elektronischen Konsum-produkten beschleunigt werden). Dennoch gibt es andere PC-Hardware-Komponenten, die besser an die Anforderungen der Hersteller von Internet-Geräten angepaßt sind.

Längere Produktlebensdauer

Dank des schnellen Wachstums der embedded x86 Industrie gibt es eine Reihe von hochintegrierten x86-Prozessoren, u.a. den AMD É lan SC310/400 (www.amd.com), den Cyrix MediaGX (www.cyrix.com), den Intel386 EX (www.intel.com) und den National Semiconductor NS486SXF (www.national.com). Da diese Prozessoren genau auf den embedded Markt zielen, sind ihre Hersteller eher bereit, diese auf lange Sicht bereitzustellen - viel länger als Motherboard-Chipsets, die auf den Desktop-PC zielen. Darüber hinaus integrieren diese Prozessoren eine Vielzahl von Peripheriekomponenten in die CPU, wodurch sowohl die Komponent-enanzahl als auch die Kosten von System-Designs verringert werden.

Neben diesen Prozessoren gibt es auch Zusatzchips mit Garantien für langfristige Verfügbarkeit. So bietet z.B. der RadiSys R380EX Chip (www.radisys.com) kombiniert mit dem Intel386 EX einen erheblichen Teil der erforderlichen Funktionalität für einen embedded PC.

Verfügbare Standardhardware

Um Herstellern eine schnelle Entwicklung zu ermöglichen, bieten x86 Chiphersteller auch Evaluations-Boards und Referenz-Entwürfe an. Davon zielen einige direkt auf die Low-Cost Bedürfnisse der Internet-Geräte. Dazu gehören der AMD ÉlanSC310 (www.amd.com), das Intel EXPLR2 Evaluation-Board (www.explr2.com), und der National Semiconductor Odin, ein Referenz-Entwurf speziell für Web-Geräte (www.national.com). Hersteller benutzen diese fertigen Plattformen für Produktevaluierung, schnelles Prototyping, Systement-wicklung und in einigen Fällen begrenzte Produktionsläufe. Sie können Teile der Referenz-Entwürfe kopieren, um ihre eigene spezifische Hardware zu entwickeln. Viele Hersteller von PC-Komponenten haben den Trend erkannt und bieten Set-Top-Box-kompatible Gehäuse, Stromversor-gungen, kabellose Infrarot-Tastaturen und kabellose Mäuse an. Diese Hardware ermöglicht es einem Set-Top-Box-Hersteller, viele Probleme in der frühen Phase des Produktlebenszyklus zu umgehen und ein System basierend auf verfügbarer Standard-hardware zu konfigurieren - ähnlich dem üblichen Vorgehen von PC-Herstellern. Während diese Methode kaum geeignet ist, die Preisklasse eines echten Konsumproduktes zu erreichen, ermöglicht es dem Hersteller in jedem Fall die schnelle Mark-teinführung eines Produktes.

Und die Software?

Bis jetzt haben wir die Anwendbarkeit von PC-Hardware diskutiert, aber der Löwenanteil der Funktionalität eines Internet-Geräts steckt in der Software. Glücklicherweise existiert diese Software bereits auf dem Desktop-PC. Leider benötigen die Betriebssysteme, auf denen diese Software basiert, eine ungeheure Menge an RAM, Plattenplatz und CPU-Zyklen. Das Ausstatten eines Internet-Geräts mit genügend Ressourcen, um ein Desktop-Betriebssystem und eine grafische Benutzerober-fläche zu betreiben, inklusive eines Internet-Browsers, würde die Hardware-Ausstattung des Internet-Geräts in die Region eines Desktop-PC verschieben und somit das Preisniveau eines Konsumproduktes völlig verfehlen.

Da das Internet-Gerät nur eine spezielle Funktion erfüllen soll und kein Allzweck-PC ist, benötigt es nicht den Software-Overhead eines Desktop-Betriebssystems, das entwickelt wurde, um beliebige Desktop-Anwendungen zu unterstützen, wie z.B. eine ressourcenintensive Benutzerober-fläche, binäre Kompatibilität zu Legacy-Anwendungen, usw. Statt dessen kann das Gerät ein wesentlich kleineres, spezialisierteres Betriebssystem verwenden, das entwickelt wurde, um Anwendungen für Internet-Geräte auszuführen. Mit der größeren Effizienz und den geringeren Speicher/Platten-Anforderungen dieses Betriebssystems können die Hardwarekosten reduziert werden, um unter dem kritischen Preisniveau von $300 zu bleiben. Die hieraus resultierenden niedrigen Stückkosten für Set-Top-Box-Geräte können in den monatlichen Kabelgebühren versteckt werden, wodurch der Zwang zum Kauf durch den Verbraucher ganz vermieden wird.

Neben den grundsätzlichen Multitasking-Fähigkeiten, die benötigt werden, um mehrere Prozesse auszuführen, muß ein Internet-Gerät einen Web-Browser zur Verfügung stellen, ein Email-Programm, möglicherweise einen Newsreader und andere Anwendungen, die vom Verbraucher erwartet werden. Zur Unterstützung dieser Anwendungen und für die Benutzerfreundlichkeit benötigt das Internet-Gerät eine grafische Benutzeroberfläche. Zieht man die präzisen Timing-Anforderungen für das Abspielen von Video- und Audiodaten in manchen Anwen-dungen in Betracht, muß das Betriebssystem zusätzlich über Echtzeitfähigkeiten verfügen.

Verfügbare Standardsoftware

Praktischerweise bieten Echtzeit-Betriebssysteme für embedded Anwendungen prozessor- und speichereffiziente Laufzeitumgebungen, die für diese Anwendung geeignet sind. Nichts desto trotz sollte der gleiche Zwang zur Minimierung des Entwicklungsaufwands, der die Hersteller ermuntert, "Anleihen" bei PC-Hardware-Standards zu machen, sie in die Richtung von standardisierten Software APIs bewegen. Wenn das gewählte Betriebssystem eine API unterstützt, die auch von den Anwendungen benutzt wird, die das Internet-Gerät bieten soll, können die Hersteller erheblichen Entwicklungsauf-wand vermeiden, indem sie diese Anwendungen einfach vom PC und anderen Umgebungen portieren. Darüber hinaus ermöglicht eine Standard-API dem Hersteller, den sich schnell weiterentwickelnden Technologien zu folgen, die vom Verbraucher gefordert werden.

Ein Beispiel für die Wirksamkeit einer auf Standards basierendem Betriebssystem-Umgebung ist die Portierung des Spyglass HTML 3.2 Web-Browsers (www.spyglass.com) auf das QNX Echtzeit-Betriebssystem. Nur ein einziger Tag war erforderlich, um die X Windows Version der Spyglass Technologie auf QNX zu portieren. Natürlich ist X zu ressourcenintensiv für die Verwendung in einem Internet-Gerät, so daß der Spyglass-Port seitdem an die Photon microGUI^® angepaßt wurde (ein Windowing-System für QNX, das später beschrieben wird). Die neue Version läuft in ca. 400K ROM oder Flash und 1MB RAM. Dies ist ein exzellentes Beispiel dafür, wie eine auf Standards basierende Umgebung die Portierung einer gängigen Internet-Technologie auf ein Internet-Gerät erleichtern kann (auch Microsofts Web-Browser basiert auf der Technologie von Spyglass). Die komplette Neuent-wicklung eines Web-Browsers für ein proprietäres Betriebssystem mit einer minimalen Grafikbibliothek hätte einen erheblich höheren Entwicklungsaufwand erfordert wobei durch die sich ständig weiterent-wickelnden Web-Browser-Technologien gar kein Ende des Entwicklungsprozesses abzusehen wäre.

Echtzeit POSIX

Da ein Großteil der bereits existierenden Internet-Software auf Unix-Systemen entwickelt wurde, ist eine Unix oder POSIX-API folglich eine gute Wahl. Eine Überprüfung des Quellcodes der Java Laufzeit-umgebung zeigt, daß ein Betriebssystem mit folgenden Eigenschaften bevorzugt wird: POSIX-konform, asynchrone I/O-Vorgänge, generische Threads, Dateisystem, Netzwerk und Windowing-System. Während POSIX-Umgebungen den Ruf haben, ressourcenhungrig zu sein (im Hinblick auf ihre historischen UNIX-Wurzeln), zeigt das Studium der POSIX-Standards eine sorgfältige Definition der Schnittstellen, jedoch nicht der Implementierung. Daher kann durch die Verwendung einer Mikrokernel-Architektur eine POSIX-API zur Verfügung gestellt werden, die ohne den architektonischen "Overhead" eines Unix-Kernels auskommt.

So bietet z.B. der QNX/Neutrino Echtzeit-Mikrokernel fast alle Basisdienste eines POSIX-Betriebssystems in ca. 32K Code. Dies beinhaltet die zentralen Dienste von POSIX 1003.1a, 1003.1b (Echtzeit), 1003.1c (Threads) und 1004.1d (Echtzeit-Erweiterungen). Die einzige Basis-Funktion, die der Microkernel nicht bietet, ist die Fähigkeit, zusätzliche Prozesse zu erzeugen. Diese Funktionalität bietet der Neutrino Prozeßmanager, Proc, der weitere 32K Speicher benötigt. Insgesamt stellt dieser 64K große Betriebssystemkern einen Großteil der Betriebssystem-Funktionalität zur Verfügung, die von einer Java-Laufzeitumgebung benötigt wird (Netzwerk, Dateisystem und Windowing-System sind extern zum Kernel).

Neutrino liefert mehrere Varianten für Memory-Protection, von keinem Schutz bis zum vollen "Prozeß-zu-Prozeß-Schutz". Im Modell ohne Memory-Protection laufen alle Anwendungsprozesse als Threads in einem gemeinsamen Adreßraum. Im Modell mit "Prozess-zu-Prozess-Schutz" läuft jeder Prozeß in einem separaten, MMU-geschützten Adreßraum (die meisten embedded x86-Prozessoren haben integrierte MMUs). Für Java-Applets, die aus dem Web heruntergeladen wurden, ist dieses Maß an Schutz unnötig, da Java selber eine sichere Laufzeitumgebung bietet. Aber für System-komponenten, die nicht in Java implementiert sind, gewährleistet der Speicherschutz die Zuverlässigkeit des Systems, indem er diese Komponenten sicher gegeneinander abschottet. Das Endergebnis? Ein Internet-Gerät, das sowohl Java-Applets, als auch hoch-performante Applikationen im prozessor-spezifischen Binärformat unterstützt und dabei maximale Zuverlässigkeit bietet.

Dank der Möglichkeit, POSIX (und damit auch Unix) Quellcode zu verwenden, können Hersteller von Internet-Geräten der Entwicklung von vielen neu aufkommenden Technologien - vom PC oder anderen Plattformen - mit minimalem Aufwand folgen. Natürlich kommen diese Technologien nicht alle aus der Unix-Welt; viele stammen aus der Windows-Welt. Daher arbeitet QNX Software Systems mit Award Software International (www.phoenix.com) an einer Portierung des API-Access Toolkits, das es Entwicklern ermöglicht, Win32 Quellcode auf das QNX Echtzeit-Betriebssystem zu portieren.

Embedded Windowing-System

Um die Vielzahl von grafischen Anwendungen unterbringen zu können, die vom Verbraucher erwartet werden, benötigt ein Internet-Gerät ein Windowing-System. Eine konventionelle Grafik-bibliothek ist zwar klein genug, bietet aber nicht die Funktionalität, die komplexe Anwendungen wie z.B. Web-Browser benötigen. Andererseits verfügt ein konventionelles Desktop-Windowing-System zwar über die entsprechende Funktionalität, aber es benötigt zu viele Ressourcen, um kosteneffektiv zu sein!

Es gibt einen Weg aus diesem Dilemma. Wir haben bereits gesehen, wie mit der Microkernel-Technologie eine Betriebssystem-Umgebung geschaffen werden kann, die komplette Funktionalität bei einem Minimum an Ressourcen bietet. Das gleiche ist auch für eine Windowing-Umgebung möglich. So ist z.B. die Photon microGUI von QNX ein skalier-bares Windowing-System mit einem "grafischen" Microkernel, das die Funktionalität eines "high-end" Windowing-Systems mit sehr wenig Speicherplatz bietet: etwa 500K in einer Konfiguration für ein Internet-Gerät.

Eine 2+4 Konfiguration

Um die benötigte Funktionalität für die Entwicklung eines Internet-Geräts zu vervollständigen, bietet die QNX/Photon-Laufzeit-Umgebung eine minimale TCP/IP-Implementierung, die nur ca. 50K belegt, sowie ein embedded Dateisystem für Flash-Speicher (oder rotierende Festplatten). Beide Dienste werden in Form von Prozessen hinzugefügt, die vom Betriebssystem-Microkernel verwaltet werden. Die kompletten Speicheranforderungen für diese Umgebung inklusive Betriebssystem, Windowing-System, Netzwerk, Dateisystem, HTML 3.2 Web-Browser, Email, Internet-Newsreader und einem persönlichen Informations-Manager (Termin-verwaltung, Adreßlisten, usw.) betragen weniger als 2MB Flash-Speicher und 4M RAM. Diese "2+4" Speicherkonfiguration ist offensichtlich weniger als das, was ein Desktop-Betriebssystem benötigt, um ähnliche Funktionalität zu liefern. Es ist auch wesentlich kleiner als das, was eine Java-Betriebssystem-Umgebung benötigt.

Eine Demo dieser Software-Umgebung, die mehr Funktionalitäten bietet als die obige Konfiguration (und etwas mehr Speicherplatz benötigt) steht zum Download unter www.qnx.com/iat bereit.

Entwicklungsumgebung

Da das Internet-Gerät eine PC-kompatible Plattform sein kann, können Entwickler einen konventionellen Desktop-PC als Entwicklungs- und Prototyping-Plattform für das Endprodukt nutzen. Die erfor-derlichen Hardwarekomponenten können in einem PC installiert werden (z.B. ein Kabelmodem), und die Software-Entwicklung kann beginnen, während parallel dazu das Hardware-Team arbeitet. Um die Performance-Charakteristika des tatsächlichen Internet-Geräts besser modellieren zu können, haben Entwickler die Auswahl unter mehreren Evaluation-Boards von AMD, Intel oder National Semiconductor.

Fazit

Durch Kombination von Hardware-Technologie aus der Welt des Desktop-PC's mit einer geeigneten embedded Software-Umgebung können Entwickler ohne weiteres einen Entwurf für ein Internet-Gerät realisieren. Bei steigenden Kundenanforderungen können zusätzliche Technologien der ständig wach-senden PC-Welt durch eine minimale Überarbeitung des Designs integriert werden. Diese Kombination von Eigenschaften erlaubt es einem vom PC abgeleiteten Internet-Gerät, die Kennzeichen eines kommerziell erfolgreichen Elektronik-Produktes für den Konsummarkt zu erreichen: kurze "Time-to-Market"-Zeit, niedrige Entwicklungskosten, minimales Risiko und die Fähigkeit, die neuesten Features und Technologien zu bieten, die von Verbrauchern erwartet werden.

© QNX Software Systems Ltd. 1998
QNX, Neutrino, and Photon microGUI are registered trademarks of QNX Software Systems Ltd. All other trademarks and registered trademarks belong to their respective owners.

Echtzeit-Erweiterungen für Windows NT

Die richtige Wahl für Ihr nächstes Echtzeit-Projekt ?

Greg Bergsma
Senior Architect, R&D
QNX Software Systems Ltd.
gbergsma@qnx.com

 

 

Einführung

Seitdem in letzter Zeit vermehrt Echtzeit-Erweiterungen für Windows NT verfügbar werden, beginnen viele Echtzeit-Entwickler, NT für ihr nächstes Projekt in Betracht zu ziehen. Es ist leicht nachvollziehbar warum. Statt Echtzeit- und Desktop-Anwendungen über ein Netzwerk 
zu verbinden, wird scheinbar eine Lösung ermöglicht, in der ein einziges System die gesamte Funktionalität basierend auf einer einzigen API realisieren kann.

Aber ist NT mit Echtzeit-Erweiterungen wirklich eine Lösung für "mission-critical" Echtzeit-Anwendungen? Lassen Sie uns die Fähigkeiten, die wir von Echtzeit-Betriebssystemen inzwischen erwarten, einmal näher betrachten wie z.B. Determinismus, Zuverlässigkeit, geringer Overhead und Portabilität des Quellcodes. Nachfolgend vergleichen wir anhand dieser Kriterien Echtzeit-Betriebssysteme mit "Echtzeit NT".

Echtzeit und Determinismus

Gemäß Definition müssen Echtzeit-Anwendungen auf äußere Ereignisse innerhalb eines vorhersagbaren Zeitraums reagieren. Dies gilt besonders für "harte" Echtzeit-Systeme, wo nicht eingehaltene Dead-Lines schwerwiegende oder sogar katastrophale Konse-quenzen nach sich ziehen würden.

Die Fähigkeit des Echtzeit-Systems, auf äußere Ereignisse innerhalb eines bestimmten Zeitraumes reagieren zu können, wird Determinismus genannt. Um zu zeigen, wie gut ein Echtzeit-Betriebssystem Determinismus unterstützt, geben die meisten Hersteller folgende Performance-Kennwerte an:

• Interrupt Latency (Interrupt-Latenz): die Zeit vom Auftreten des ersten physikalischen Interrupts bis zur Ausführung des ersten Befehls der Interrupt Service Routine (ISR) der Anwendung.
• Scheduling Latency (Scheduling-Latenz): die Zeit von der Ausführung des letzten Befehls des Interrupt Handlers bis zur Ausführung der ersten Instruktion des Prozesses, der durch das Auftreten des Interrupts in den Zustand "Ready" wechselt.
• Context Switch Zeit (Kontextwechselzeit): die Zeit von der Ausführung des letzten Befehls eines User-Level Prozesses bis zur Ausführung der ersten Instruktion des nächsten User-Level Prozesses.

Grafik 1 - Um die Determinismus-Fähigkeiten eines Echtzeit-Betriebssystems zu charakterisieren, verwenden die meisten Betriebssystem-Hersteller folgende Kennwerte: Interrupt Latency (t_il ), Scheduling Latency (t_sl) und Context Switch Zeit (t _cs)

Obwohl diese Kennwerte nur begrenzte Aussagekraft hinsichtlich der Determinismus-Fähigkeiten eines Echtzeit-Betriebssystems haben, können sie doch helfen, zu beurteilen, ob ein Echtzeit-Betriebssystem die Anforderungen einer bestimmten Echtzeit-Anwendung betreffend Determinismus und Perfor-mance erfüllen kann. Ebenso wichtig sind solche Kennwerte beim Vergleich der Performance einer NT Echtzeit-Erweiterung mit spezialisierten Echtzeit-Betriebssystemen.

Betriebssystem-Hersteller geben diese Kennwerte i.d.R. für eine große Anzahl von Prozessortypen an. Betrachten wir z.B. die Daten für QNX, ein Echtzeit-Betriebssystem, das für eine große Bandbreite von Echtzeit-Anwendungen verwendet wird. Die Zeiten sind in Mikrosekunden angegeben:

Prozessor	Interrupt Latency	Scheduling Latency	Context Switch
Pentium 200	1,4	2,9	1,2
Pentium 100	1,8	4,7	2,6
486 DX/33	7,5	12,6	8,2

Wie schneiden NT Echtzeit-Erweiterungen im Vergleich ab? Die Zahlen varieren, aber die veröf-fentlichten Werte für einige Erweiterungen deuten darauf hin, daß sie 10 bis 15 mal langsamer sind als die Zahlen in der obenstehenden Tabelle.

Warum sind diese Erweiterungen so viel langsamer? Ein Grund ist, daß sie regelmäßig einen Hardware-Interrupt pollen, um die Kontrolle an das Echtzeit-Subsystem zu übergeben. Während der Determin-ismus verbessert werden könnte, indem man die Polling-Rate erhöht, würde dies jedoch zusätzliche CPU Zyklen verbrauchen, die die NT-Anwendung vielleicht benötigt, um eine akzeptable Performance zu erreichen. Dieses Problem wird in einer Netzwerk-Anwendung noch gravierender, da Netzwerk-Karten sehr viele CPU-Zyklen beanspruchen und das System durch ihre eigene hohe Interrupt-Rate zusätzlich belasten.

Hohe Verfügbarkeit und Robustheit

Determinismus ist wichtig, aber es gibt weitere Kriterien zur Beurteilung eines Echtzeit-Systems, so z.B. hohe Verfügbarkeit. Kann das Betriebssystem des Systems weiterlaufen, oder sich zumindest schnell wieder fangen, wenn ein Softwarefehler auftritt? Und kann das Betriebssystem weiterhin Dienste zur Verfügung stellen, selbst wenn eine kritische Hardware-Komponente, zum Beispiel die Festplatte, ausfällt?

Das Erreichen einer hohen Verfügbarkeit ist ein komplexes Problem, das eine Reihe von Features im Betriebssystem benötigt. Betrachten wir z.B., wie das Betriebssystem mit Softwarefehlern umgeht.

Egal wie sehr wir uns bemühen, fehlerfreien Code zu schreiben in der Praxis werden unsere Echtzeit-Anwendungen unentdeckte Programmierfehler enthalten, wie z.B. unzulässige Zeigerreferenzen oder überschrittene Array-Grenzen. Die Folge sind Softwarefehler, die potentiell sogar einen System-absturz verursachen können. Um solche Fehler zu entdecken, braucht man ein Betriebssystem mit Unterstützung für die "Memory Management Unit" (MMU), die heutzutage auf den meisten 32-Bit Prozessoren vorhanden ist. Wenn eine Speicher-schutzverletzung auftritt, wird die MMU das Betriebssystem darüber informieren, das seinerseits den fehlerhaften Prozeß abbrechen kann.

Einige NT Echtzeit-Erweiterungen bieten Speicher-schutz für Echtzeit-Prozesse, andere nicht. Aber selbst wenn eine Erweiterung Speicherschutz unter-stützt, bleibt die Frage offen, ob die Möglichkeit besteht, einen Software Watchdog zu implementieren.

Was ist ein Software Watchdog? Es ist ein Prozeß, der vom Betriebssystem informiert wird, sobald eine Speicherschutzverletzung auftritt. Dieser Prozeß trifft dann eine intelligente Entscheidung darüber, wie das System nach dem Auftreten des Fehlers möglichst schnell wieder voll verfügbar gemacht werden kann.

Hardware und Software Watchdogs

Um die Wichtigkeit eines Software Watchdogs zu verstehen, betrachten wir, womit viele existierende Systeme auf Softwarefehler reagieren: mit einem Hardware Watchdog, der an die Reset-Leitung des Prozessors angeschlossen ist. Typischerweise über-prüft eine Komponente der Systemsoftware die Integrität des Systems und signalisiert dann der Timer Hardware, daß das System "gesund" ist. Wenn der Hardware Timer dieses Signal nicht regelmäßig erhält, läuft er ab und erzwingt einen Prozessor-Reset. Die gute Nachricht ist, daß sich das System auf diese Weise bei ernsten Software- oder Hard-wareproblemen wieder erholt. Die schlechte Nachricht ist, daß das System komplett neu gestartet wird, was dem Ziel der hohen Systemverfügbarkeit widerspricht.

Vergleichen Sie dies Verhalten mit dem eines Software Watchdogs, der intelligent zwischen mehreren, weniger drastischen, Reaktionen auf einen Fehler wählen kann. Anstatt jedesmal einen vollen Neustart zu erzwingen, könnte der Software Watchdog:

• einfach nur diesen Prozeß neu starten, ohne das ganze System herunterzufahren, oder
• jeden betroffenen Prozeß beenden, die Hardware in einen `sinnvollen' Zustand versetzen und die betroffenen Prozesse koordiniert neu starten, oder,
• falls das Versagen kritisch ist, einen koor-dinierten Shutdown des ganzen Systems durchführen und einen akustischen Alarm auslösen, um das Wartungspersonal zu alarmieren.

 

Der Software Watchdog erlaubt es, die Kontrolle über das Systems zu behalten, auch wenn mehrere Prozesse innerhalb der Steuerungssoftware versagt haben sollten. Ein Hardware Watchdog Timer kann immer noch dazu dienen, auf Hardwareprobleme zu reagieren, aber Softwareprobleme hat man nun wesentlich besser unter Kontrolle. Des weiteren kann durch die Verwendung eines teilweisen Neustarts das System regelmäßig auftretende Softwareprobleme überstehen, ohne daß die Systemverfügbarkeit beeinträchtigt wird.

 

Die bessere Wahl

Während der Durchführung eines partiellen Neustarts kann das System auch Informationen über die Art des Softwareproblems sammeln. Wenn das System zum Beispiel Zugriff auf Massenspeicher (Flash-Speicher, Festplatte, eine Netzwerk-Verbindung zu einem anderen Computer mit Festplatte) hat, kann der Software Watchdog eine chronologisch archivierte Folge von Prozeß Dump Files anlegen. Diese Dump Files können Informationen liefern, mit denen das Problem behoben werden kann, bevor ähnliche Ausfälle erneut auftreten.

 

Ein Software Watchdog reduziert nicht nur teure (oder sogar gefährliche) Ausfallzeiten, sondern hilft auch, zukünftige Softwarefehler zu vermeiden. Aus diesen Gründen sollte sichergestellt sein, daß eine NT Echtzeit-Erweiterung die Implementierung eines Software Watchdogs ermöglicht.

Reduzierung von Kernel-Fehlern

Natürlich kommen Programmierfehler nicht nur in Anwendungen vor. Um neue Hardware oder System-dienste zu unterstützen, kann es notwendig sein, Gerätetreiber und andere Dienste auf Systemebene zu entwickeln.

In traditionellen Betriebssystem-Architekturen laufen diese Komponenten als Teil des Kernels im Kernel Modus (siehe Grafik 2). Code, der im Kernel-Modus läuft, genießt keinen Schutz durch die MMU. Deshalb können unzulässige Zeigerreferenzen oder Array-Indices in Gerätetreibern Kernel-Fehler verursachen, die nur durch einen Neustart der Hard-ware behoben werden können. Je mehr Code der Kernel enthält, desto größer ist die Wahrscheinlichkeit von Kernel-Fehlern. In Windows NT verursachen diese Fehler einen "Blue Screen-Crash".

In einem Microkernel-Betriebssystem wie QNX, laufen nur der Kernel (32k Code) und die Interrupt Service Routinen (ISRs), im Kernel-Modus, wodurch das Risiko von Kernel-Fehlern drastisch gesenkt wird (siehe Grafik 3).

Grafik 2 - traditionelle Betriebssystem-Architektur

Grafik 3 - QNX Microkernel Architektur

Der "Blue Screen" Crash

Alle Hersteller von Echtzeit-Erweiterungen für NT haben die Notwendigkeit erkannt, mit dem "Blue Screen Crash" umzugehen. Daher können einige dieser Produkte einen Kernel-Fehler abfangen, so daß das Echtzeit-Subsystem die Möglichkeit hat, entweder weiterzulaufen oder das System geordnet zu beenden. Die Vorteile eines Systems, das weiter-laufen kann, sind allerdings fragwürdig, wenn mit den NT Komponenten des Systems nicht mehr kommuniziert werden kann wie zum Beispiel mit der Benutzerschnittstelle!

Und es gibt ein noch größeres Problem: Manche NT Echtzeit-Erweiterungen können potentiell zu Kernel-Fehlern beitragen. Diese Systeme sind direkt im Kernel als Interrupt Service Routine (ISR) imple-mentiert oder laufen im Hardware Abstraction Layer (HAL). Daher läuft das ganze Echtzeit-Subsystem im Kernel-Modus. Was passiert also, wenn es eine unzulässige Zeigerreferenz in einer Echtzeit-Anwendung gibt? Ein Kernel-Fehler ist die Folge - ein "Blue Screen Crash".

Weiterhin benötigen die meisten Echtzeit-Anwendungen spezielle Gerätetreiber. Da alle NT Gerätetreiber im Adreßraum des Kernels liegen, trägt auch dies zur Anfälligkeit des Systems bei.

Technischer Support

Das Stichwort Software-Crash bringt eine weitere Frage auf: Wer ist der Support-Ansprechpartner, falls Probleme auftreten? Microsoft oder der Hersteller der Echtzeit-Erweiterung? Vor der Investition in eine Erweiterung sollte geklärt werden, wer im Falle eines Problemes die Verantwortung für den tech-nischen Support übernimmt.

 

Zugriff auf Systemressourcen

Um schnellen Zugriff auf Systemressourcen zu ermöglichen, (z.B. Dateisysteme, Geräte, Kommunikations-Gateways), bieten traditionelle Echtzeit-Betriebssysteme eine API, die entweder durch Systemprozesse oder im Kernel selber imple-mentiert ist. Ein verteiltes Echtzeit-Betriebs-system, wie zum Beispiel QNX, geht noch einen Schritt weiter und verwandelt ein Netzwerk von Computern in eine einzige logische Maschine. Daher kann ein Prozeß, der auf einem beliebigen Computer läuft, sämtliche Ressourcen im Netzwerk nutzen, wenn er über entsprechende Rechte verfügt. Ressourcen könnten z.B. sein:

• Dateisysteme (Festplatten, CD-ROMs usw.)
• Kommunikations-Schnittstellen (serielle, parallele und Modems)
• CPUs
• Kommunikations-Gateways

Dieser verteilte Ansatz kann die Systemverfügbarkeit wesentlich verbessern. Wenn ein Gerät auf einer Maschine ausfällt, kann ein Prozeß automatisch neu gestartet werden und ein Gerät oder sogar ein Dateisystem einer anderen Maschine benutzen.

Ein wichtiger Punkt bei der Evaluierung einer Echtzeit-Erweiterung ist die Frage, ob der Zugriff auf Ressourcen sowohl von NT Anwendungen als auch von Echtzeit-Anwendungen aus möglich ist. Nehmen wir an, ein Echtzeit-Subsystem benötigt schnellen Zugriff auf das NT Dateisystem. Bietet die NT Erweiterung die dafür erforderliche Funk-tionalität? Wenn ja, wie wird dies bewerkstelligt? Wird der HAL verwendet? Falls ja, werden im Endeffekt dieselben Mechanismen benutzt, durch die NT für Echtzeit ungeeignet ist (d.h. es gibt keine Kontrolle über die Priorität von Systemaufrufen, die in einer ISR initiiert wurden).Was passiert außerdem, wenn Microsoft sich entscheidet, Änderungen am HAL vorzunehmen? Wird die Echtzeit-Erweiterung noch funktionieren?

Alle oben genannten Fragen betreffen auch den Zugriff auf Kommunikations-Gateways.

System-Overhead

Wie bereits oben erwähnt, implementieren einige Echtzeit-Erweiterungen für NT Determinismus durch einen hoch-frequenten Polling-Interrupt. Dieser Interrupt benötigt CPU-Zyklen und verursacht einen Overhead, auch wenn gar keine Echtzeitarbeit erledigt werden muß. Das Ergebnis? Weniger CPU Zyklen für normale NT Anwendungen und erhöhte `Latency'. Im Gegensatz dazu sind die meisten Echtzeit-Betriebssysteme ereignisgesteuert und reagieren auf Interrupts nur, wenn sie auftreten.

Bezüglich des Speicher-Overheads gilt, daß die meisten Erweiterungen einfach nur die an sich schon großen Speicheranforderungen von NT noch weiter erhöhen. Dagegen passen die meisten Echtzeit-Betriebssysteme mit Leichtigkeit in kleine, ROM-basierte embedded Systeme.

Konformität zu Standard-APIs

Um das in Sourcecode investierte Kapital zu schützen, versuchen viele Entwickler, Anwendungen zu erstellen, die über Betriebssystem-Plattformen portabel sind. Industrie-Standards wie z.B. die POSIX API sind geschaffen worden, um Entwicklern zu helfen, dieses Ziel zu erreichen sogar NT bietet eine POSIX-Option an. Nichts desto trotz hat der weitgehende Erfolg von Microsoft Betriebssystemen einen zusätzlichen defacto Standard geschaffen: die Win32 API. Daher unterstützen nun mehrere Hersteller von Echtzeit-Betriebssystemen sowohl POSIX als auch Win32.

Unglücklicherweise unterstützen einige NT Echtzeit-Erweiterungen weder POSIX noch Win32. Statt dessen benutzen sie eine proprietäre API, die jeden Versuch verhindert, sich unabhängig von Plattform oder Hersteller zu machen. Andere Erweiterungen bieten nur eine Untermenge der Win32 API und begrenzen dadurch die Funktionalität, die in einem Echtzeit-System implementiert werden kann.

Fazit

Echtzeit-Erweiterungen unterstützen einen Grad von Echtzeit-Determinismus, den NT alleine nicht bieten kann. Der Grad an Determinismus ist aber nur ein Teil des Gesamtbildes. Eine Echtzeit-Umgebung muß auch extrem zuverlässig sein. Sie muß in der Lage sein, Software-Fehler ohne Ausfallzeit zu überstehen und Kernel-Fehler vermeiden. Für die meisten Anwendungen sollte die Umgebung geringen CPU-Overhead und minimalen Speicherbedarf erfordern. Und sie sollte eine portable API bieten.

Wie wir gesehen haben, können viele NT Echtzeit-Erweiterungen diese Anforderungen nicht erfüllen. Die meisten Echtzeit-Betriebssysteme bieten dagegen etablierte Technologien, die exakt auf die Anforde-rungen des Echtzeit-Markts abgestimmt wurden. Daher ist für die meisten Echtzeit-Anwendungen ein Ansatz mit einer losen Kopplung immer noch am sinnvollsten: NT für den Desktop, ein Echtzeit-Betriebssystem für die Echtzeit-Steuerung und die Integration der zwei Systeme durch die verschiedenen Netzwerk-Optionen, die von den Herstellern von Echtzeit-Betriebssystemen geboten werden.

© QNX Software Systems Ltd. 1998
QNX, Neutrino, and Photon microGUI are registered trademarks of QNX Software Systems Ltd. All other trademarks and registered trademarks belong to their respective owners.