Conventional realtime-subsystems usually work with a synchronized schedulermechanism for realtime subsystem and OS, which usually shows a bad jitter behaviour at high OS load. The X-Realtime Engine works asynchronously with separated clock sources that clearly leads to a better jitter behavior and thereby realizes a complete decoupling of realtime-task to the existing operating system. With the X-Realtime Engine, realtime task cycles are realizable upto 10 µsec (100 KHz) sampling rate. An integrated watchdog-system controls the realtime task and determines the remaining task-time. The SHA X-Failsafe-System offers additionally the possibility to keep a rescue task busy or to proceed a controlled shutdown, even on heavy exception errors (for example Blue-Screen). With the X-Failsafe-System, for example a robot-arm can be driven out from a hazard zone and an alarm signal is caused. The realtime routine has to be equal to a RING0 EXECUTION routine for interrupt control (see Interrupt Access Module), however without a return value and it‘s not depending on the system load. With the X-Realtime routine the same programming methods and restrictions are valid like on each other RING0 EXECUTION routine. With the X-Realtime system several tasks can be programmed within an application or within a device driver and will be automatically mapped to the X-Realtime system layer at runtime. Every task can be setup with its own scheduling cycle which interacts independently to any other task cycles. Additionaly each task can given and changed its own priority dynamically. So several applications with their own realtime tasks can run at once. Together with application task also device drivers can setup their own realtime tasks to run within the X-Realtime system.

Echtzeit-Betriebssysteme werden immer dann benötigt, wenn zeitkritische dynamische Systeme zuverlässig verwaltet werden müssen. Die Verletzung des deterministischen Zeitverhaltens führt bei s.g. sensitiven Systemen i.d.R. zu einem kritischen bis katastrophalen Zustand (z.B. Linearsteuerung, Füllmengenüberwachung), während nicht-sensitive Systeme (z.B. Geschwindigkeitsregelung) bei sporadischer Verletzung temporär in einen kritischen Zustand wechseln oder stabil bleiben. Waren die Anforderungen früherer Echtzeit-Betriebssysteme auf deterministisches Zeitverhalten und Sicherheit begrenzt, so werden heute zusätzlich Visualisierungs- und kommunikative Fähigkeiten mit von solchen Systemen als Standard gefordert. Die Kommunikationsanforderungen an heutige Echtzeit-Betriebssysteme umfassen nahezu den gesamten Schnittstellenbereich.

Man unterscheidet jedoch zwischen echtzeitfähiger und nicht-echtzeitfähiger Kommunikation. Echtzeitfähige Kommunikation wird heute vor allem bei CAN-, Ethernet- und serieller Verbindung gefordert wenn der Datenfluß entweder nicht unterbrochen werden darf, oder Datenpakete in einem festgelegten Zeitraster bearbeitet werden müssen. Vor allem in der industriellen Steuerungstechnik ist die grafische Anzeige der Daten zur Interaktion zwischen Mensch – Maschine eine wichtige Voraussetzung. Moderne Echtzeitbetriebssysteme bieten daher i.d.R eine eigene grafische Schnittstelle zur Daten-Visualisierung. Um den Echtzeitablauf nicht zu beeinflussen, ist die Visualisierung jedoch von der Datenaufnahme zeitlich entkoppelt. Hierbei ist die Programmierbarkeit des Echtzeit-Betriebssystems ein wichtiger Faktor für die Erstellung von Applikationen und deren Wartung und dem damit verbundenen Kostenfaktor. Ein modernes Echtzeitbetriebssystem muß darüberhinaus einen Notbetrieb gewährleisten, um z.B. im Fehlerfall einen Roboter aus einem Gefahrensbereich manövrieren zu können. Besonders bei der Steuerung sensitiver Systeme muß der Notbetrieb die Gesamtsystemstabilität aufrecht erhalten.

Bei Hard-Realtime fähigen Betriebssystemen muß die Latenzzeit der Echtzeit-Task unabhängig von dem Verhalten anderer Tasks sein. Bei Soft-Realtime kann die Latenzzeit der Echtzeit-Task abhängig von dem Verhalten anderer Tasks sein, jedoch nur innerhalb einer vorgegebenen Abweichung. Desweiteren muß bei der begrifflichen Definition zwischen deterministischem Zeitverhalten von AKTIO und REAKTIO unterschieden werden, sofern eine periodische Programmabarbeitung zugrunde liegt. Bei der umlaufenden Echtzeit (AKTIO) wird eine Echtzeit-Task periodisch aufgerufen, welche die Steuerung ausführt. Die Umlauf-Periode bestimmt hierbei das deterministische Zeitraster und somit die Genauigkeit. Bei der ereignisgesteuerten Echtzeit (REAKTIO) wird die Echtzeit-Task immer dann aufgerufen, wenn das Ereignis eintritt (z.B. periodisches Ereignis). Die Latenzzeit muß hierbei kleiner als die Periodendauer des Ereignisses sein (Voraussetzung: Latched Signal). Die Latenzzeit bis zur Abarbeitung des Ereignisses ist hierbei von Software und Hardware abhängig (z.B. Prioritätenverteilung der Interrupts). Die Gesamt-Latenzzeit zwischen Ereignis und Reaktion ergibt sich aus der Summe der Einzel-Latenzzeiten eines Systems. Durch die Kombination eines nicht-echtzeitfähigen Betriebssystems mit einem s.g. echtzeitfähigen Subsystem können die Vorteile beider Systeme vereint werden. So können die Visualisierungs- und Kommunikations- Eigenschaften des nicht-echtzeitfähigen Betriebssystems mit dem deterministischen Zeitverhalten des echtzeitfähigen Subsystems für Steuerungsaufgaben ideal genutzt werden. Ein deterministisches Zeitverhalten ist unter den Betriebssystemen Windows (NT, 2000 oder XP) nur mit Echtzeit-Subsystemen realisierbar. Bei reinen Software-Lösungen muss bei solchen Systemen aufgrund des Betriebsmanagements allerdings meist mit erheblichen Abweichungen (JITTER) gerechnet werden.

SYBERA hat mit SHA (Sybera Hardware Access) eine Realtime-Engine entwickelt, die eine vollständige Abkopplung der Realtime-Task zum bestehenden Betriebssystem umsetzt und somit geringstes JITTER-Verhalten aufweist. Während bei herkömmlichen Echtzeit-Subsystemen die Realtime-Task bei zunehmender CPU-Belastung starken Zeitschwankungen unterliegt, bleibt die Realtime-Task von SHA auch bei extremer CPU-Belastung zeitstabil. Somit kann ein genaues Echtzeit-Verhalten für industrielle Anwendungen unter Windows ohne zusätzliche Hardware umgesetzt werden. Mit der SHA X-Realtime-Engine sind Echtzeit-Task-Zyklen bis zu 10µsec realisierbar (100 KHz Abtastrate). Ein integriertes Watchdog-System überwacht die Echtzeittask und ermittelt die verbleibende Task-Zeit. Das SHA X-Failsafe-System bietet zusätzlich die Möglichkeit, auch bei schweren Ausnahme-Fehlern (z. B. Blue-Screen) das System mit einer Rescue-Task aktiv zu halten oder kontrolliert zu beenden. Mit dem X-Failsafe-System kann beispielsweise ein Roboterarm aus der Gefahrenzone herausgefahren und ein Alarmsignal ausgelöst werden. Der Entwickler arbeitet mit dem SHA System innerhalb seiner gewohnten Entwicklungsumgebung (z. B. Visual C++). Zusätzlich ermöglicht SHA den Zugriff auf alle Hardware-Resourcen direkt von der Applikations-ebene. Ob IO-Portzugriffe, Mapped Memory, Timer- und Interrupt-Steuerung oder Echtzeit, alles kann ohne Zeitverlust und ohne aufwendige Gerätetreiber-Programmierung realisiert werden. Zu den von SHA unterstützten Plattformen zählt ab der Version SHA 7Plus auch Windows CE. Hierbei wurde dasselbe Interface implementiert wie bei der Windows  Version. Ein unter Windows  geschriebenes Programm kann somit leicht nach CE portiert werden. Aktuell werden die Prozessoren x86, ARM und SH4 unterstützt. Weitere Plattform-Unterstützungen sind in Planung. Einsatzgebiete in der Mess-, Steuer- und Regeltechnik mit hohen Datentransferraten und geringsten Reaktionszeiten sind beste Beispiele für die sinnvolle Anwendung von SHA.

Windows XP hat sich im professionellen Workstation-Einsatz weitgehend als Standard-Betriebssystem durchgesetzt. Mit der Entwicklung von XP wurde zudem die Anpassung an die erweiterten Eigenschaften portabler Plattformen und neuer Kartentechnologien bzgl. Energieverwaltung und Plug&Play-Management realisiert. Aufgrund seiner Sicherheitsmechanismen, den Kommunikationseigenschaften, sowie seiner umfangreichen Visualisierungsfähigkeiten bietet es dem Benutzer einen kom-fortablen und sicheren Umgang mit dem Betriebssystem. Um diese Eigenschaften des Betriebssystems auch im industriellen Einsatz nutzen zu können, müssen jedoch Prozesse für Kommunikation und Datenaufbereitung deterministisch abgearbeitet werden können.

Die Multitasking-Struktur von Windows XP widerspricht jedoch dem deterministischen Zeitverhalten einer Taskverarbeitung. Unter XP kommt eine Kombination unterschiedlicher Task-Verteilungsmechanismen zum Einsatz. Tasks welche der niedersten Prioritätsstufe (PASSIVE_IRQL) zugeordnet sind werden typischerweise mit einer 10 msec Unterbrechung nach dem Zeitscheiben-Verfahren (Round Robin) ab-gearbeitet, können jedoch durch höherpriore Tasks asymetrisch unterbrochen werden. Die Tatsache, daß höchstpriore Task (z.B. ISR –> DEVICE_IRQL) nicht-präemtiv abgearbeitet werden, verhindert zudem ein deterministisches Zeitverhalten bei der Task-Abarbeitung. Das XP-Multitasking ist für eine optimale Overall-Performance ausgelegt, jedoch nicht für Prozessbearbeitung in Echtzeit.

Ein Betriebssystem muß in seiner Struktur für eine deterministische Datenverarbeitung bestimmte Kriterien erfüllen. Wichtige systembedingte Voraussetzungen für die Echtzeit-Verarbeitung hierbei sind Preemptives Multitasking, unterbrechbare Interrupt-Verarbeitung, keine Beeinflussung durch andere Prozesse, zeitscheibenbasierter Taskwechsel, mögliche Zuordnung höchster Prioritätsebene für Echtzeit-Task. Mit der Kombination des Betriebssystem XP mit einem echtzeitfähigen SubKernel-System (Echtzeit-Erweiterung) können die Vorteile beider Systeme vereint werden. So können die Visualisierungs- und Kommunikations- Eigenschaften von XP mit dem deterministischen Zeitverhalten des echtzeitfähigen Subsystems z.B. für Steuerungsaufgaben und Protokollverarbeitung ideal genutzt werden. Heute werden unterschiedliche Echtzeit-Erweiterungen für Windows XP angeboten, oft jedoch zugeschnitten für proprietäre Lösungen. Bei reinen Software-Lösungen muss bei solchen Systemen aufgrund des restriktiven Betriebsmanagements von XP allerdings meist mit erheblichen Abweichungen (JITTER) gerechnet werden.

War der Einsatz früherer Echtzeit-Betriebssysteme auf geschlossene Systeme begrenzt, so werden heute solche Betriebssysteme auch in offenen Plattformen einge-setzt und übernehmen zusätzlich Aufgaben für Visualisierung und Kommunikation. Echtzeit wird immer dann benötigt, wenn zeitkritische dynamische Systeme zuverlässig verwaltet werden müssen. Die Verletzung des deterministischen Zeitverhaltens führt bei s.g. sensitiven Systemen i.d.R. zu einem kritischen bis katastrophalen Zustand (z.B. Linearsteuerung, Füllmengenüberwachung), während nicht-sensitive Systeme (z.B. Geschwindigkeitsregelung) bei sporadischer Verletzung temporär in einen kritischen Zustand wechseln oder stabil bleiben. Oftmals wird Determinismus auch Kriterien beurteilt, welche sich nicht nach den physikalischen Voraussetzungen eines Systems richten. Die Forderung nach einem deterministisches Zeitverhalten bei Kommunikation und Datenaufbereitung umfasst nahezu den gesamten Schnittstellenbereich. Determi-nismus wird vor allem bei Feldbussystemen, serieller Kommunikation und Ethernet-Verbindungen gefordert. Hierbei muß jedoch zwischen zwei Ebenen des Determinismus unterschieden werden, Realtime-Level0 - es muß sichergestellt werden, daß bei der Kommunikation keine Daten verloren gehen können, Realtime-Level1 - es muß sichergestellt werden, daß die Datenaufbereitung (Filterung) in einem deterministischen Raster durchgeführt wird.

Um das Echtzeitverhalten nicht zur beeinflussen, muß der Datenaustausch zwischen deterministischen Tasks und nicht-deterministischen Tasks zeitlich entkoppelt (z.B. über RING-Buffer) werden. Ein Echtzeit-Betriebssystem muß zudem einen Notbe-trieb gewährleisten, um im Fehlerfall die Systemstabilität aufrecht zuerhalten. Grundsätzlich muß zwischen zwei Verfahren bei der Echtzeit-Verarbeitung unterschieden werden. Bei der umlaufenden Echtzeit handelt es sich um deterministisches Multitasking, bei dem zwei unterschiedliche Mechanismen zur Anwendung kommen. Beim Non-Preemptive Realtime Multitasking werden Tasks periodisch durch einen Verteiler (Scheduler) in einem deterministischen Zeitraster aufgerufen. Bei dieser Methode richtet sich die Periodendauer des Verteilers nach der Ablaufzeit aller aktiven Tasks. Beim Preemptive Realtime Multitasking werden Tasks periodisch in einem de-terministischen Zeitraster periodisch durch einen Verteiler unterbrochen. Die Periodendauer des Verteilers ist hierbei unabhängig von der Anzahl der aktiven Tasks. Bei der ereignisgesteuerten Echtzeit wird eine Task innerhalb eines deterministischen Zeitfenster aufgerufen, wenn das Ereignis eintritt (z.B. Interrupt). Die Latenzzeit bis zur Abarbeitung des Ereignisses ist hierbei von Software- und Hardware-Verarbeitung abhängig (z.B. Prioritätenverteilung der Interrupts).

SYBERA hat mit SHA (Sybera Hardware Access) eine Realtime-Engine entwickelt, die eine asynchrone Entkopplung (basierend auf 2 getrennten Taktquellen) der Echtzeit-Erweiterung zum bestehenden Betriebssystem ohne zusätzliche Hardware um-setzt und somit geringstes JITTER-Verhalten aufweist. Während bei herkömmlichen Echtzeit-SubSystemen die Latenzzeit bei zunehmender CPU-Belastung starken Schwankungen unterliegt, bleibt die Realtime-Engine von SHA auch bei extremer CPU-Belastung zeitstabil (z.B. Defragmentierung).

Mit der Umsetzung von X-Realtime auf Windows Multiprozessor-Systeme passt SYBERA seine Echtzeiterweiterung konsequent an die neuen Prozessor-Generationen an. Durch die Unterstützung des Symetric-Mode des Advanced Programmable Interrupt Controller (APIC) wird eine höhere Performance mit geringerer Latenzzeit erreicht. Wie bisher arbeitet auch die neue X-Realtime-Engine auf Multi-prozessor-Systemen mit einer asynchronen Entkopplung zum bestehenden Be-triebssystem, wodurch der Scheduler zwischen Echtzeiterweiterung und Betriebssys- tem entfällt. Obwohl heute verschiedene APIC-Konfigurationen auf Multiprozessor-Plattformen zum Einsatz kommen, passt sich die neue X-Realtime-Engine automa-tisch an diese an. SYBERA wird bis Mitte des Jahres die neue X-Realtime-Engine in alle bereits bestehenden Produkte implementieren.