Flight Simulation auf einem PC als Soft Realtime Szenario (Screenshot von "Flight Gear")

Einleitung

Über Modellzeit und Echtzeit

In den allermeisten Fällen hat die künstliche Zeit, die in einem simulierten Modell vergeht nicht mit der realen Zeit außerhalb des Computermodells zu tun. Zum Beispiel werden oft bei einer Simulation einer beliebigen biologischen Population Jahre und Jahrzehnte in Sekunden berechnet. Anderseits dauert es bei einer komplexe Strömungssimulation oft Stunden um einige Sekunden zu simulieren. Man kann die künstliche Zeit die innerhalb des Modells vergeht als Modellzeit bezeichnen. Die Echtzeit ist die Zeit, die der Benutzer vor seinem Bildschirm mit dem Warten auf Ergebnisse verbringt. Eine Echtzeitsimulation ist eine Simulation bei der die Modelzeit und die Echtzeit gleich sein sollten. Da die Zeit im Allgemeinen als kontinuierlich verstanden wird und Computersimulationen naturgemäß immer nur in einem gewissen Sinne diskret sein können, kann auch die Modell- und die Echtzeit nur an festgelegten Synchronisationspunkten identisch sein. An den Beispielen kann man sofort sehen, dass Echtzeit nicht gleichbedeutend mit "schnell" sein muss. Eine Echtzeitsimulation einer Population wäre aus Sicht eines Anwenders kaum hilfreich und würde viel zu lange dauern. Kommen wir zurück zu den erwähnten Synchronisationspunkten. Wenn man an HIL (Hardware-In-The-Loop) Simulationen denkt, müssen zum Beispiel in den meisten Anwendungsfällen Echtzeit und Modellzeit jede Millisekunde identisch sein.

Electronic Control Unit1

Soft Real Time Simulation

Dadurch wird bei einer Echtzeitsimulation die Zeit selbst zur kritischen Ressource. Es ist hier nicht genug einfach nur schnell zu sein oder mit wenig Speicher auszukommen. Darüber hinaus muss man vor allem "rechtzeitig" sein. Ein Flugsimulator ist dazu gedacht den Pilotenschüler oder vielleicht auch einfach nur dem Spieler die reale Welt vorzutäuschen. Wenn der Pilot eine Aktion durchführt, z.B. in dem er den Steuerknüppel bewegt, muss der Simulator die gleiche Reaktion in der gleichen Zeit zeigen, wie es das echte Flugzeit tun würde. In der gleichen Zeit meint beides, es gibt eine untere Grenze wie schnell die Reaktion nach dem Ereignis erfolgen darf und eine obere. Die Anforderung für die Software hängt dann noch davon ab, ob man lediglich die Reaktion auf einem Bildschirm darstellen muss oder noch eine großen mechatronischen Flugsimulator bewegen muss. In jedem Fall wäre für einen Flugschüler eine deutlich zu schnelle Reaktion genauso schlecht wie eine deutlich zu späte Reaktion.

Nehmen wir für einen Moment an, dass nur der Mensch hier "in-the-loop" ist und keine mechatronischen Komponenten mitgesteuert werden müssen. In diesem Fall kann man sicherlich von einem Soft Real Time Szenarien sprechen, da es ausreicht wenn die Berechnungen des Simulators in einem hinreichend kleinen Zeitintervall abgeschlossen sind. Ideal wäre hier in der Regel die Mitte des zeitlichen Interfalls. Man kann also zusammenfassen, dass wir in einem Soft Real Time Szenarien der Modellzeit und der Echtzeit nicht erlauben dürfen auseinander zulaufen und gewisse Intervalle einzuhalten, aber es werden keine harten Synchronisationspunkte gefordert.

An Electronic control unit in a Hardware-In-The-Loop scenario

Hard Real Time Simulation: ECU Tests mit Hardware-In-The-Loop Simulatoren

Besonders die Anwendungsmöglichkeiten von Echtzeitsimulation im Bereich der Entwicklung und des Tests von elektronischen Steuergeräten (ECUs) machen sie aktuell interessant. Heutzutage werden große Mengen von ECUs in Autos verbaut und eine Methode diese innerhalb des Entwicklungsprozess für neue ECUs zu testen in Hardware-In-The-Loop-Test. Ein HIL Test wird durchgeführt indem man eine oder mehrere ECUs mit einem Simulator verbindet. Der Simulator repräsentiert für die ECU hierbei den Rest des Autos und der Umgebung, wie zum Beispiel den Fahrer. Somit ist also nun nicht ein Mensch sonder ein Stück Hardware "in-the-Loop" und dadurch ändern sich auch die Anforderungen. Sie sind auf eine gewisse Weise "härter". Wenn eine ECU getestet wird muss man im Allgemeinen sicher sein können das nach eine Reaktion des Simulators exakt nach z.B. einer Millisekunde auch berechnet ist. Ist gibt allerdings auch bei ECU Fälle in denen eine weiche Echtzeit ausreichend ist. Solche Hard-In-The-Loop Tests sind, unabhängig davon ob es um harte oder weiche Echtzeit geht, ein Standard in den V- Entwicklungszyklen für ECU-Software der Automobilindustrie.

Teil eines solchen "Hardware-In-The-Loop" Szenarios ist natürlich der Simulator selbst, er beinhaltet auch eine Echtzeitbetriebssystem (eng. real time operation system - RTOS) und geeignete I/O-Hardware, zum Beispiel angeschlossene FlexRay, CAN oder LIN Bus-Systeme. Ein anderer wichtiger Teil ist natürlich das Computermodel, welches unter Echtzeitbedingen die Umgebung, den Wagen etc. simuliert. Spannende Aufgabenstellungen ergeben sich hier daraus wie ein solches Modell in echtzeitfähigen Code überführt wird. Dieser echtzeitfähige Code benötigt etwas andere Ansätze bzgl. der numerischen Algorithmen oder der Parallelisierung von Code als in einem Nicht-Echtzeit-Kontext.

Für Experimente im Lehrbetrieb oder der Forschung erlauben offene RTOS Betriebssysteme eine wie RTLinux oder sogar einfach der Standard Linux Kernen unter Verwendung des Realtime-Preempt-Patch (s. zum Beispiel einen Artikel in Elektronik Praxis) einen einfachen Zugang mit offen APIs. Daneben liegt der Source Code des Systems offen, was Studierenden bei Interesse die Möglichkeit gibt einmal unter die Haube eines RTOS zu schauen.

last modified by Joerg Frochte on March 1st 2010