DE102008023955B4

DE102008023955B4 - Verfahren zur Simulation von Ereignissen und Abläufen von Luft-, Land- oder Wasserfahrzeugen und Simulationssystem

Info

Publication number: DE102008023955B4
Application number: DE102008023955A
Authority: DE
Inventors: Thomas Stumpfegger; Daniel Kos
Original assignee: KUKA Roboter GmbH
Current assignee: KUKA Deutschland GmbH
Priority date: 2008-05-16
Filing date: 2008-05-16
Publication date: 2010-04-01
Anticipated expiration: 2028-05-17
Also published as: DE102008023955A1

Abstract

Verfahren zur Simulation von Ereignissen und Abläufen von Luft-, Land- oder Wasserfahrzeugen, aufweisend folgende Verfahrenschritte:
– Betreiben eines nichtechtzeitfähigen Simulationsprogramms (ESP) auf einem Rechner zur Erzeugung von Simulationssteuerdaten,
– Übertragen der nichtechtzeitfähigen Simulationssteuerdaten in einen Datenmanager (1),
– Auslesen der Daten aus dem Datenmanager (1) in Echtzeit und
– Ansteuern einer Simulationseinrichtung (R) mit den aus dem Datenmanager (1) ausgelesenen Daten in Echtzeit, bei dem
– ein Speicher (RTB) des Datenmanagers (1) mit Simulationssteuerdaten befüllt wird, wenn die Simulationssteuerdaten höchstens mit einer Verzögerung im Datenmanager (1) eintreffen, die kleiner als eine erwartete Verzögerung ist,
– im Datenmanager (1) gespeicherte Simulationssteuerdaten aus dem Speicher (RTB) ausgegeben werden, wenn Simulationssteuerdaten nicht innerhalb der erwarteten Verzögerung eintreffen, und
– der Datenmanager (1) zusätzliche Simulationssteuerdaten erzeugt, wenn weniger als eine vorbestimmte Menge an Simulationssteuerdaten im Speicher (RTB) des Datenmanagers (1) vorhanden sind und die Simulationssteuerdaten nicht innerhalb...

Description

Die Erfindung betrifft ein Verfahren zur Simulation von Ereignissen und Abläufen von Luft-, Land- oder Wasserfahrzeugen und Simulationssystem.
Aus der WO 2005/020184 A2 ist ein Verfahren zum Betreiben eines Echtzeit-Simulationssystems bekannt, das auf einem Nichtechtzeit fähigen Rechner zu betreiben ist. Bei dem dortigen Verfahren wird ein simulierter Zeitzähler während eines ersten Verfahrenschritts eingerichtet. Danach werden alle Prozessorabläufe abgearbeitet, die während einer laufenden Simulation ihren Ablauf abschließen müssen. Der simulierte Zeitzähler wird anschließend zum nächsten simulierten Zeitschritt weitergesetzt. Diese Lösung soll es ermöglichen, ein Echtzeit-Simulationsprogramm auf einem Nichtechtzeit-Rechner betreiben zu können. Die Verwendung von Echtzeit-Rechner wird darin wegen der hohen Kosten als nachteilig erachtet und deshalb vorgeschlagen, das Echtzeit-Simulationsprogramm auf einem Nichtechtzeit-Rechner zu betreiben.
Die WO 2005/109375 A1 beschreibt einen üblichen Flugsimulator zu Trainingszwecken. Die Vorrichtung umfasst eine Kabine, die von einem Hexapoden mit 6 Freiheitsgraden bewegt wird. Der Hexapode wird über ein Bewegungssteuerungsprogramm angetrieben, das auf einem Echtzeit-Rechner abläuft. Der Echtzeit-Rechner ist über eine Ethernet-Busleitung mit dem Simulationsprogramm verbunden, wobei die Daten im TCP/IP oder UDP Protokoll-Standard übertragen werden.
Die DE 103 04 706 A1 beschreibt ein Verfahren zum Steuern einer Anlage, wie einer industriellen Produktionsanlage mit einer Anzahl von Arbeitseinheiten, wie Industrierobotern oder dergleichen, unter Verwendung wenigstens einer speicherprogrammierbaren Steuerung (SPS), bei der historische Prozessdaten in die SPS eingespeist und durch eine Programmlogik der SPS verarbeitet werden.
Die DE 103 51 669 A1 beschreibt ein Verfahren zum Steuern eines Handhabungsgeräts, wie eines Mehrachs-Industrieroboters, wobei zunächst ein erwartetes Bild eines Objekts in einem Arbeitsbereich des Handhabungsgeräts mit einem realen Bild des Objekts verglichen wird, anschließend eine Stellungsabweichung des Handhabungsgerätes bestimmt wird und dann Bewegungen zur Minimierung der Stellungsabweichung durchgeführt werden.
Die WO 2005/020184 A2 beschreibt ein Verfahren zum Betrieb einer Echtzeit-Simulation auf einer Nicht-Echtzeit-fähigen Rechnerplattform.
Die DE 10 2005 058 867 A1 beschreibt ein Verfahren zum Bewegen einer auf einem Schwenk-/Neigekopf angeordneten Kamera entlang einer vorgegebenen Bewegungsbahn insbesondere in einem Set oder Studio, dadurch gekennzeichnet, dass aus der vorgegebenen Bewegungsbahn für die Kamera eine zugeordnete Bewegungsbahn für die räumlichen Positionen und Orientierungen eines Basisbezugs-Systems des Schwenk-/Neigekopfes bestimmt werden und aus der bestimmten Bewegungsbahn für das Basisbezugs-System des Schwenk-/Neigekopfes zugeordnete Stellgrössen für Achsen eines in kartesischen Koordinaten fahrbaren Roboters, an dessen Aufnahmeflansch der Schwenk-/Neigekopf befestigt ist, erzeugt und an die Achsen übertragen werden.
Aufgabe der Erfindung ist es, eine Simulationseinrichtung in Echtzeit anzusteuern, obwohl die zur Ansteuerung erforderlichen Daten lediglich von einem Nichtechtzeit-Simulationsprogramm bereitgestellt werden, wobei eine durch einen Datenmanager verursachte Latenzzeit kompensiert werden soll.
Erfindungsgemäß werden zur Lösung der Aufgabe die folgenden Verfahrenschritte vorgeschlagen:

– Betreiben eines nichtechtzeitfähigen Simulationsprogramms auf einem Rechner zur Erzeugung von Simulationssteuerdaten,
– Übertragen der nichtechtzeitfähigen Simulationssteuerdaten in einen Datenmanager,
– Auslesen der Daten aus dem Datenmanager in Echtzeit und
– Ansteuern einer Simulationseinrichtung mit den aus dem Datenmanager ausgelesenen Daten in Echtzeit, bei dem
– ein Speicher des Datenmanagers mit Simulationssteuerdaten befüllt werden, wenn die Simulationssteuerdaten höchstens mit einer Verzögerung im Datenmanager eintreffen, die kleiner als eine erwartete Verzögerung ist,
– im Datenmanager gespeicherte Simulationssteuerdaten aus dem Speicher ausgegeben werden, wenn Simulationssteuerdaten nicht innerhalb der erwarteten Verzögerung eintreffen, und
– der Datenmanager zusätzliche Simulationssteuerdaten erzeugt, wenn weniger als eine vorbestimmte Menge an Simulationssteuerdaten im Speicher des Datenmanagers vorhanden sind und die Simulationssteuerdaten nicht innerhalb der erwarteten Verzögerung eintreffen.

Als Echtzeit wird im Rahmen der Erfindung diejenige Zeit verstanden, die Abläufe in der realen Welt tatsächlich benötigen. Als Modellzeit wird hingegen eine Zeit bezeichnet, die bspw. eine selbst verwaltete Laufzeit eines Programms sein kann. Die Modellzeit ist zunächst von realen Abläufen, d. h. der Echtzeit unabhängig. Kann nun ein System eine Modellzeit synchron zur Echtzeit ausführen, so wird von einem echtzeitfähigen System gesprochen. Ein Simulationssystem kann prinzipiell zeitliche Abläufe raffen oder strecken. Im Rahmen der erfindungsgemäßen Simulation von Ereignissen und Abläufen von Luft-, Land- oder Wasserfahrzeugen besteht jedoch das Bedürfnis die Ereignisse und Abläufe genau so zu simulieren, wie sie in der realen Welt auch tatsächlich ablaufen würden. Der Begriff Echtzeit meint nicht eine bestimmte Geschwindigkeit oder Verarbeitungsleistung des Programms oder der Steuerung. Vielmehr legt der Begriff Echtzeit nur den Zeitrahmen fest innerhalb dem das System reagieren muss. Im Ergebnis bedeutet dies, dass es bei echtzeitfähigen Systemen darauf ankommt, die Antwortzeit vorzugeben, innerhalb der das System tatsächlich reagiert haben muss. Je nach Anforderung können sich die tatsächlichen Reaktionszeiten und damit die Antwortzeiten deutlich verschieden sein. Bei harten Echtzeit-Systemen wird eine Überschreitung der vorgegebenen Antwortzeit als Fehler gewertet. Bei weichen Echtzeit-Systemen wird eine Überschreitung der vorgegebenen Antwortzeit in einem gewissen Ausmaß und Umfang toleriert, ohne dass dies als Fehler gewertet wird. Die durchschnittliche Abweichung von der erwarteten Antwortzeit liegt in einem tolerierten Rahmen. Diesen Rahmen überschreitende Verspätungen sind selten.
Im Rahmen der Erfindung wird der Begriff Datenmanager nicht lediglich nur als Puffer oder Speicher für die Zwischenlagerung von Daten verstanden, sondern als intelligentes Datenverwaltungssystem, das eingehende und ausgehende Daten organisiert, sowie bearbeitet, extrapoliert oder durch Wissensdaten ersetzt.
Latenzzeit bedeutet ein Zeitraum zwischen einer Aktion und dem Eintreten der zu erwartenden Reaktion, also eine Verzögerungszeit.
Als Jitter wird eine Abweichung von der erwarteten Ankunftszeit einer Reaktion verstanden. Solche Abweichungen können durch Genauigkeitsschwankung in der Übertragungszeit entstehen, bspw. durch eine Varianz in der Laufzeit von Datenpaketen.
Harte Echtzeit-Systeme liefern stets zeitlich vorhersehbare Antworten. Allerdings sind sie generell derart streng ausgebildet, dass sie auch selten auftretenden höchsten Anforderungen gerecht werden können. Dadurch werden während den sonstigen Zeiten mit geringeren Anforderungen unnötig Rechnerkapazitäten gebunden. In der Simulationstechnik und auch in der Automatisierungstechnik, wie die Robotik sind bei harten Echtzeit-Systemen die Echtzeit-Programme auf Echtzeit-Rechnerkomponenten angewiesen. Zu diesen Rechnerkomponenten zählen bspw. auch hochauflösende Grafik-Displays, die – obwohl nicht notwendig – Kapazitäten an Rechenleistung und Speicherplatz beanspruchen, die zur Berechnung von Algorithmen der Echtzeit-Programme benötigt würden. Moderne Microsoft^®-Windows basierte Personal-Computersysteme (PCs) bieten aber eine leistungsfähige Plattform, um mit allerlei Arten von nichtechtzeitfähigen Eingabegeräten, Zusatzhardware und Entwicklungstools zurecht kommen zu können. Die heutigen Multimedia-Anforderungen haben dazu geführt, dass Ereignisse und Abläufe auf Windows basierten PC-Plattformen unter weichen Echtzeitbedingungen stattfinden können. Eine Flexibilität und Variabilität wird durch Programme erreicht, die auf mehren Ebenen ablaufen, die jedoch nicht unmittelbar vom Systementwickler beeinflusst werden können. Dieser Ablauf in mehreren Ebenen bedingt jedoch eine Ungewissheit hinsichtlich der Ausführungszeit. Dies führt zu Jitter und Latenzzeit, d. h. Effekten, mit denen die Hardware unter Umständen nicht zurecht kommen könnte. Die Erfindung setzt hier an und stellt ein Verfahren und ein Simulationssystem vor, wie nicht-echtzeitfähige Simulationsprogramme zur Ansteuerung von echtzeitfähigen Simulationseinrichtungen benutzt werden können.
Die Simulationseinrichtung kann insbesondere einen Industrieroboter als Bewegungsmaschine aufweisen, der mittels einer Antriebssteuerung bewegt wird. Die Antriebssteuerung eines Roboter, auch Robotersteuerung oder Motion-Controller bezeichnet, umfasst alle notwendigen Hardware- und Software-Komponenten, um Ereignisse und Abläufe in Echtzeit ausführen zu können. Als Echtzeitbetriebssystem für die Antriebssteuerung kann VxWorks^® der Firma WindRiver^® eingesetzt werden. Auf diesem Echtzeitbetriebssystem können auch externe Sensoren und Feldbus-Kommunikationseinrichtungen in echtzeitfähig betrieben werden. Auf der Benutzerseite können grafische Benutzerschnittstellengeräte, wie Displays, Ereignisse und Abläufe in Bildern und Grafiken anzeigen, sowie manuelle Eingabegeräte angeschlossen werden. Als benutzerseitiges Betriebssystem hat sich Microsoft^®-Windows auf Personal-Computersystemen etabliert. Neuere Microsoft^®-Windows Versionen ermöglichen zwar aufgrund der fortentwickelten Multimedia-Funktionen bereits eine weiche Echtzeitfähigkeit des Betriebssystems Microsoft^®-Windows, eine harte Echtzeitfähigkeit kann jedoch nicht gewährleistet werden. Trotzdem ist es sinnvoll Microsoft^®-Windows basierte Plattformen zu nutzen, zumal Anwender gerne weitere Anwendungsprogramme nutzen oder eigene Anwendungsprogramme erstellen wollen. Überwiegend sind die für den Betrieb von Peripheriegeräten, wie bspw. Sensoren und Eingabegeräten, notwenigen Treiber einfach, schnell und kostengünstig erhältlich. Gerade im Bereich der Simulation zu Ausbildungs- und Lernzwecken wäre es sinnvoll eine echtzeitfähige Simulation auf der kostengünstigen Microsoft^®-Windows Plattform betreiben zu können. Bisher scheiterte eine Lösung an der fehlenden Echtzeitfähigkeit dieses Betriebssystems. Mit dem erfindungsgemäßen Datenmanager können Echtzeit-Simulationseinrichtungen auf nicht-echtzeitfähigen Betriebssystemen bzw. von nicht-echtzeitfähigen Simulationsprogrammen in Echtzeit angesteuert werden.
Für Bewegungssimulationen kommt der Echtzeitfähigkeit der Antriebssteuerung bspw. des Roboters (Motion-Controller) große Bedeutung zu, da für die Beurteilung der Realitätsnähe der Simulation die dem Benutzer der Simulationseinrichtung erfahrenden Bewegungsbeschleunigungen maßgeblich sind. Art und Weise eines Motion-Controller Aufbaus ist im Ausführungsbeispiel zusammen mit den Figuren näher erläutert.
Der Speicher kann derart organisiert sein, dass diejenigen Daten, die zuerst gespeichert wurden, auch zuerst wieder aus dem Speicher entnommen werden (FIFO-Buffer).
In den meisten Fällen wird die Latenzzeit eine weitaus größere Dauer aufweisen, als die Dauer eines Jitters. Deshalb wird die Größe des Speichers in Abhängigkeit der größten anzunehmenden Dauer der Latenzzeit zu wählen sein. Um den Datenverkehr zwischen den Systemen insgesamt gering zu halten, sollten möglichst viele Daten in einem Datenpaket versendet werden. Der Datenmanager fordert dabei die Datenpakete frühest möglich an, um sie in den Speicher zu schreiben. Die Größe des Speichers sollte jedoch nicht zu groß gewählt werden, da zu Berücksichten ist, dass auch der Speicher des Datenmanagers selbst eine Latenzzeit dadurch hervorruft, dass der Zeitraum des Zwischenspeicherns selbst eine Latenzzeit darstellt. Die Größe des Speichers ist so zu bemessen, dass er einerseits ausreichend groß gewählt wird, um ein Leerlaufen des Speichers zu vermeiden und andererseits so klein gewählt wird, dass die Latenzzeit kein störendes Ausmaß annimmt. So könnte eine Latenzzeit im Datenmanager bzw. im Speicher als eine verzögerte Antwort der Antriebssteuerung des Roboters interpretiert werden. Besonders bei Änderungen in der Bewegungsrichtung oder der Geschwindigkeit der Roboterbewegung tritt eine Verzögerung durch den Datenmanager im Speicher in Erscheinung. Eine Arbeitsweise des Datenmanagers ist im Ausführungsbeispiel zusammen mit den Figuren näher erläutert.
Eine Strategie, insbesondere gegen eine durch den Datenmanager verursachte Latenzzeit kann darin bestehen wesentlich mehr Daten aus dem Simulationsprogramm an den Datenmanager zu schicken, als zur Ansteuerung der Simulationseinrichtung in Echtzeit benötigt werden. Eine obere Grenze bildet die mögliche Speichergröße im Datenmanager insbesondere bezüglich einer Echtzeit-Hardware. Dies setzt jedoch voraus, dass das Simulationsprogramm die Daten schneller erzeugen kann, als zur echtzeitfähigen Verarbeitung in der Simulationseinrichtung benötigt werden. Unabhängig von dem Verarbeitungszustand der Daten im Datenmanager können neue Datenpakete in den Datenmanager gesendet werden, sobald ausreichend Daten von dem Simulationsprogramm zur Verfügung stehen. Jedes Mal, wenn neue Datenpakete im Datenmanager eintreffen können bereits vorhandene Daten aus dem Speicher zumindest in Teilmengen ausgelesen werden. Zur Erzeugung einer kontinuierlichen Bewegungsbahn für die Simulationseinrichtung d. h. die Roboterbewegung sollen die neuen Daten nahtlos an die im Speicher vorhandenen Daten angefügt werden. Durch diese Strategie kann eine Latenzzeit weitgehend verhindert werden, bzw. zu einem seltenen Ereignis reduziert werden, falls durch große Latenzzeiten der Kommunikation eine Verspätung der Ankunft von neuen Daten eintritt und die neuen Daten sich von den bisher gesendeten Daten unterscheiden. Bleiben die neuen Daten gleich den bisher gesendeten Daten, so kann der Datenmanager neben anderen Strategien auch Simulationssteuerdaten erzeugen, die statt der ausbleibenden Daten, als neue Daten verwendet werden.
Um einen Verlust der harten Echtzeitfähigkeit zu vermeiden, ist Sicherzustellen, dass ein Leerlaufen des Speichers nicht eintritt. Eine Strategie, einen internen Abbruch der Datenkommunikation mit dem Echtzeitsystem zu verhindern, ist im Ausführungsbeispiel zusammen mit den Figuren näher erläutert.
Die Erzeugung zusätzlicher Simulationssteuerdaten kann beispielsweise durch Extrapolation auf Grundlage vor zeitlich vorausgegangenen Simulationssteuerdaten erfolgen.
In den oben genannten Fällen kann ein Abbruch der Simulation eingeleitet werden, wenn eine vorbestimmte Dauer, in der eine Extrapolation fortgeführt wird, überschritten wird. Dabei können während eines eingeleiteten Abbruchs Simulationssteuerdaten erzeugt werden, durch welche die Simulationseinrichtung in sanfter Weise in einen Ruhezustand überführt wird.
In allen erfindungsgemäßen Varianten können die Simulationssteuerdaten über einen echtzeitfähigen Bus, insbesondere mittels Ethernet aus dem Datenmanager bzw. dessen Speicher in die Steuerung der Simulationseinrichtung übertragen werden.
In allen erfindungsgemäßen Varianten können die Simulationssteuerdaten in eine Bewegungssteuerung in Echtzeit zugeführt werden.
Eine erfindungsgemäße Bewegungssteuerung kann diejenige einer Antriebssteuerung eines Industrieroboters sein.
Die Erfindung bezieht sich auch auf ein zugehöriges Simulationssystem.
Das erfindungsgemäße Simulationssystem weist die folgenden Komponenten auf:

– einen Rechner mit einem Betriebssystem, auf einem darauf lauffähigen Simulationsprogramm,
– einen Datenmanager mit einem Speicher für Simulationssteuerdaten,
– eine Simulationseinrichtung mit einer Bewegungssteuerung zum Erzeugen von Ereignissen und Abläufen von Luft-, Land- oder Wasserfahrzeugen, wobei

Die Bewegungssteuerung kann eine Antriebssteuerung eines Industrieroboters sein.
Die Simulationseinrichtung kann insbesondere einen Industrieroboter aufweisen, an dessen Handflansch eine Fahrzeugkabine befestigt ist. Vorzugsweise erfolgt die Befestigung bodenseitig der Fahrzeugkabine und in einem Winkel von 45° zwischen Boden und Rückwand der Fahrzeugkabine.
Die Erfindung ist anhand eines Ausführungsbeispiels näher erläutert. Alle Merkmale dieses konkreten Ausführungsbeispiels können weitere vorteilhafte Ausgestaltungen der Erfindung offenbaren.
Es zeigen:
1 eine schematische Darstellung einer Speicher-Strategie;
2 eine grafische Darstellung einer simulierten Geschwindigkeits-Rampe mit einem Speicherleerlauf;
3 eine schematische Darstellung einer Systemarchitektur eines erfindungsgemäßen Simulationssystems;
4 ein Ablaufdiagramm einer erfindungsgemäßen ersten Entscheidungsstrategie;
5 ein Ablaufdiagramm einer erfindungsgemäßen zweiten Entscheidungsstrategie.
Die 1 zeigt einen zeitlichen Ablauf t einer Speicher-Strategie. Die Zeit t läuft auf einer in der 1 in der Mittel dargestellten Zeitachse von oben nach unten. Von der Zeitachse nach rechts ist der Speicherinhalt BC gezeigt. In einem mittleren Bereich des Speichers BC ist ein Schwellenwert N_t aufgezeigt. Zunächst wird vom Datenmanager 1 eine erste Anfrage an Daten NPR1 ausgelöst. Ein ersten Datenpaket NPS1 wird daraufhin in den Speicher BC abgelegt und aufgrund der FIFO-Organisation des Speichers kann ein vorhandenes Datenpaket NPS0 aus dem Speicher BC ausgelesen werden. Nach einer erneuten Anfrage an Daten NPR2 wird ein weiteres Datenpaket NPS2 in den Speicher BC abgelegt und das vorhandene Datenpaket NPS1 kann aus dem Speicher BC ausgelesen werden. Erneut erfolgt eine weitere Anfrage an Daten NPR3 und so weiter. Die Zeit zwischen einer Anfrage an Daten, z. B. NPR2 und einem Auslesen dieser angefragten Daten NPR2 aus dem Speicher BC stellt die Latenzzeit L des Datenmanagers 1 dar.
Für die Kalkulation der Speichergröße und des Schwellenwertes N_t sind zwei Werte maßgeblich, die durch das System selbst vorgegeben sind. Der erste Wert ist die Sampling-Rate, welche bestimmt in welchen Zeitabschnitten der Speicher BC ausgelesen wird. Der zweite Wert ist die größte anzunehmende Latenzzeit, die zu erwarten ist. Die zu erwartende Latenzzeit ist durch umfangreiches Austesten der Kommunikations-Leistung des Systems zu bestimmen. Die zu erwartende Latenzzeit ist ein kritischer Wert hinsichtlich der Gefahr eines Leerlaufens des Speichers BC.
Des weiteren ist die optimale Datenpaketgröße zu bestimmen. Durch die Definition der Datenpaketgröße wird die Menge der zu übermittelnden Daten je Anfrage an Daten festgelegt. Eine Mindestgröße für die Datenpakete ergibt sich aus dem Verhältnis von Latenzzeit der Kommunikation zur Sampling-Rate. Dieses Verhältnis beschreibt die Anzahl von Paketen, die im Speicher BC vorzuhalten sind, um auch bei der maximalen zu erwartenden Latenzzeit ein Leerlaufen des Speichers BC verhindern zu können. Vorzugsweise sollten möglichst große Datenpakte definiert werden, um den Kommunikationsaufwand gering zu halten. Der Schwellenwert N_t zu dem erneut ein Datenpaket angefragt werden soll kann aus dem Verhältnis von Latenzzeit der Kommunikation zur Sampling-Rate bestimmt werden. Darüber hinaus kann ein Sicherheitsfaktor von bspw. 1,1 für eine 10% Sicherheitsmarge angesetzt werden.
Der zeitliche Ablauf t einer Speicher-Strategie nach 1 ist beschrieben für einen Datenmanager 1, der aktiv Daten von dem Simulationsprogramm anfordern kann. In gleicher Weise können erfindungsgemäß aber auch Daten passiv von dem Datenmanager 1 erwartet werden. D. h. der Datenmanager hört einen Datenstrom, der aktiv von dem Simulationsprogramm nach außen geschickt wird ab, um den vollständigen Datenstrom aufnehmen zu können. Sollten unter bestimmten Umständen keine Daten vom Simulationsprogramm geschickt werden, kann auch vorgesehen sein, dass der Datenmanager nur in diesen Ausnahmefällen Daten aktiv vom Simulationsprogramm, wie oben beschrieben anfragt, insbesondere dann, wenn der Speicher RTB droht leer zu laufen.
Die 2 zeigt eine grafische Darstellung einer simulierten Geschwindigkeits-Rampe mit einem Speicherleerlauf. Zwischen 0 und 600 Millisekunden ist ein typischer Geschwindigkeitsrampenverlauf für einen Antrieb dargestellt. Zum Zeitpunkt t = 600 Millisekunden setzt das schlimmste anzunehmende Ereignis ein, der Speicher läuft leer. Soweit die Echtzeit-Simulationssteuerung die Verbindung zum übergeordneten Simulationssystem verloren hat, wird die in der Simulationseinrichtung vorhandene kinetische Energie abgebaut, d. h. es findet ein Abbremsen der Simulationseinrichtung statt. Bei ca. 690 Millisekunden erhält die Echtzeit-Simulationssteuerung wieder Steuerdaten. Die Echtzeit-Simulationssteuerung erkennt nun, dass ein Geschwindigkeitsverlust aufgetreten ist und versucht mit diesem erkannten Geschwindigkeitsverlust zurecht zu kommen. Beispiele erfindungsgemäßer Strategien zur Überwindung bzw. Vermeidung derartiger Ereignis sind in den 4 und 5 als Ablaufdiagramme dargestellt.
3 zeigt zunächst eine schematische Darstellung einer Systemarchitektur eines erfindungsgemäßen Simulationssystems. Ein Nicht-Echtzeitfähiges Simulationsprogramm MS-ESP, das bspw. auch auf einem nicht-echtzeitfähigem Betriebssystem Non-RTOS ablaufen kann, steht über eine Netzwerkkommunikationsschnittstelle EC mit einem echtzeitfähigen Betriebssystem RTOS, wie bspw. Vx-Works^® zum Datenaustausch in Verbindung. Die von der Netzwerkkommunikationsschnittstelle EC seitens des echtzeitfähigen Betriebssystem RTOS eingegangenen Datenpakete werden nun in einem erfindungsgemäßen Datenmanager 1 verarbeitet. Der Datenmanager 1 weist einen Speicher RTB seitens des echtzeitfähigen Betriebssystems RTOS auf. Der Datenmanager 1 versorgt den Steuerungskern CK der Simulationseinrichtung R, die ein Industrieroboter sein kann, mit Datenpaketen in Echtzeit. An einem Handflansch 2 des Industrieroboters kann ein Fahrzeugkabine 3 befestigt sein.
4 zeigt ein Ablaufdiagramm einer erfindungsgemäßen ersten Entscheidungsstrategie. Die Entscheidungsstrategie kann zu jedem Interpolationstakt von bspw. 12 Millisekunden durchgeführt werden. Zunächst wird in einer ersten Entscheidungsfrage Q1 festgestellt, ob ein Steuerungsbefehl an die Simulationseinrichtung R von dem Datenmanager 1 bspw. aus dem Speicher gesendet werden kann. Falls dem so ist (JA) wird in einer zweiten Entscheidungsfrage Q3 festgestellt, ob der zu sendende Steuerungsbefehl von einem vorangegangenen Steuerungsbefehl höchstens um einen tolerierbaren Unterschied abweicht. Falls dieser tolerierbar ist (JA) wird der Steuerungsbefehl im Schritt T3 als neuer Steuerungsbefehl in den Speicher RTB des Datenmanagers 1 eingestellt. Abschließend erfolgt im Schritt T4 ein Senden des nächsten Steuerungsbefehls aus dem Speicher RTB an die Simulationseinrichtung R.
Ist die Abweichung des Steuerbefehlt größer als tolerierbar, so wird anders Entschieden (NEIN) und in einem gesonderten Schritt T2 die Simulation sanft abgebrochen.
Wird in der ersten Entscheidungsfrage Q1 festgestellt, dass kein Steuerungsbefehl an die Simulationseinrichtung R von dem Datenmanager 1 bspw. aus dem Speicher gesendet werden kann, so wird die Entscheidungsfrage Q1 anders Entschieden (NEIN) und in diesem Falle durch eine weitere Entscheidungsfrage Q2 festgestellt, ob der Schwellenwert N_t im Datenmanager 1 unterschritten ist. Falls der Schwellenwert N_t im Datenmanager 1 nicht unterschritten ist (NEIN), so wird erneut ein Steuerungsbefehl, der vom Datenmanager 1 bestimmt, erzeugt bzw. extrapoliert, der sich an früheren vom Simulationsprogramms ESP originär bereitgestellten Steuerungsbefehlen orientiert. Abschließend erfolgt im Schritt T4 ein Senden des Steuerungsbefehls an die Simulationseinrichtung R.
Erfindungsgemäß ist der Datenmanager 1 dazu eingerichtet, im Falle des Ausbleibens von Daten des Nicht-Hartechtzeitfähigen Simulationsprogramms bzw. Nicht-Hartechtzeitfähigen Betriebssystems auf dem das Simulationsprogramm abläuft, eigene Daten, die nicht vom Simulationsprogramm stammen, die entstehenden Datenlücken zu ersetzen und an die Bewegungssteuerung CK der Echtzeit-Simulationseinrichtung R zu senden. Durch das Senden von eigenen Daten des Datenmanagers 1 wird der Bewegungssteuerung CK der Echtzeit-Simulationseinrichtung R sozusagen eine Echtzeitfähigkeit des Simulationsprogramms simuliert d. h. vorgespielt. Die eigenen Daten des Datenmanagers 1 können bspw. aus vorangegangenen Daten des Simulationsprogramms extrapoliert werden. Alternativ können die eigenen Daten des Datenmanagers 1 aus einem Expertensystem bereitgestellt werden, das über eine Wissensbasis verfügt, die in Abhängigkeit der momentane Zustände der Simulation geeignete Daten zur Verfügung stellt, d. h. die Daten können aus Erfahrungswerten bestimmt werden.
Ist der Schwellenwert N_t im Datenmanager 1 unterschritten (JA), so wird in dem Schritt T2 die Simulation sanft abgebrochen.
5 zeigt ein Ablaufdiagramm einer erfindungsgemäßen zweiten Entscheidungsstrategie. In einer ersten Entscheidungsfrage Q4 wird festgestellt, ob ein Datenpaket rechtzeitig eingetroffen ist. Ist das Datenpaket rechtzeitig oder zu früh eingetroffen, so wird das Datenpaket im Schritt T4 in den Speicher RTB des Datenmanagers 1 eingereiht. Ergänzend wird dieses Datenpaket im Schritt T6 in eine Wissensdatenbank eingetragen. Wird bei der Entscheidungsfrage Q4 festgestellt, dass das Datenpaket zu spät eingetroffen ist, so wird es für die Simulation verworfen, jedoch mit dem Schritt T5 in die Wissensdatenbank eingetragen.

Claims

Verfahren zur Simulation von Ereignissen und Abläufen von Luft-, Land- oder Wasserfahrzeugen, aufweisend folgende Verfahrenschritte: – Betreiben eines nichtechtzeitfähigen Simulationsprogramms (ESP) auf einem Rechner zur Erzeugung von Simulationssteuerdaten, – Übertragen der nichtechtzeitfähigen Simulationssteuerdaten in einen Datenmanager (1), – Auslesen der Daten aus dem Datenmanager (1) in Echtzeit und – Ansteuern einer Simulationseinrichtung (R) mit den aus dem Datenmanager (1) ausgelesenen Daten in Echtzeit, bei dem – ein Speicher (RTB) des Datenmanagers (1) mit Simulationssteuerdaten befüllt wird, wenn die Simulationssteuerdaten höchstens mit einer Verzögerung im Datenmanager (1) eintreffen, die kleiner als eine erwartete Verzögerung ist, – im Datenmanager (1) gespeicherte Simulationssteuerdaten aus dem Speicher (RTB) ausgegeben werden, wenn Simulationssteuerdaten nicht innerhalb der erwarteten Verzögerung eintreffen, und – der Datenmanager (1) zusätzliche Simulationssteuerdaten erzeugt, wenn weniger als eine vorbestimmte Menge an Simulationssteuerdaten im Speicher (RTB) des Datenmanagers (1) vorhanden sind und die Simulationssteuerdaten nicht innerhalb der erwarteten Verzögerung eintreffen.
Verfahren nach Anspruch 1, bei dem die Erzeugung zusätzlicher Simulationssteuerdaten durch Extrapolation auf Grundlage vor zeitlich vorausgegangenen Simulationssteuerdaten erfolgt.
Verfahren nach Anspruch 1 oder 2, bei dem ein Abbruch der Simulation eingeleitet wird, wenn eine vorbestimmte Dauer, in der eine Extrapolation fortgeführt wird, überschritten wird.
Verfahren nach Anspruch 3, bei dem während eines eingeleiteten Abbruchs Simulationssteuerdaten erzeugt werden, durch welche die Simulationseinrichtung in sanfter Weise in einen Ruhezustand überführt wird.
Verfahren nach einem der Ansprüche 1 bis 4, bei dem die Simulationssteuerdaten über einen echtzeitfähigen Bus (EC) aus dem Datenmanager (1) in die Bewegungssteuerung (CK) der Simulationseinrichtung (R) übertragen werden.
Verfahren nach einem der Ansprüche 1 bis 5, bei dem die Simulationssteuerdaten in eine Bewegungssteuerung in Echtzeit zugeführt werden.
Verfahren nach Anspruch 6, wobei die Bewegungssteuerung eine Antriebssteuerung eines Industrieroboters ist.
Simulationssystem zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 7, aufweisend: – einen Rechner mit einem Betriebssystem (Non-RTOS), auf einem darauf lauffähigen Simulationsprogramm (ESP), – einen Datenmanager (1) mit einem Speicher (RTB) für Simulationssteuerdaten, – eine Simulationseinrichtung (R) mit einer Bewegungssteuerung (CK) zum Erzeugen von Ereignissen und Abläufen von Luft-, Land- oder Wasserfahrzeugen, wobei die Bewegungssteuerung (CK) der Simulationseinrichtung (R) über eine echtzeitfähige Datenverbindung mit dem Datenmanager (1) verbunden ist und der Datenmanager (1) über eine Datenverbindung mit dem Rechner verbunden ist.
Simulationssystem nach Anspruch 8, wobei die Bewegungssteuerung (CK) eine Antriebssteuerung eines Industrieroboters ist.
Simulationssystem nach Anspruch 9, dadurch gekennzeichnet, dass die Simulationseinrichtung (R) einen Industrieroboter aufweist, an dessen Handflansch (2) eine Fahrzeugkabine (3) bodenseitig befestigt ist.