DE102009043425A1

DE102009043425A1 - Simulationssystem und Verfahren für eine technische Anlage

Info

Publication number: DE102009043425A1
Application number: DE102009043425A
Authority: DE
Inventors: Karl-Josef Amthor; Hans-Georg Dr. Köpken; Thilo Stolper
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2009-09-29
Filing date: 2009-09-29
Publication date: 2011-04-07
Also published as: US20110077926A1

Abstract

Ein Simulationssystem weist einen ersten Simulator (3) zur Simulation eines ersten physikalischen Prozesses, einen zweiten Simulator (5) zur Simulation eines zweiten physikalischen Prozesses, einen Seund zur Verarbeitung von Daten aus dem zweiten Simulator (5) auf, wobei im ersten Simulator (3) CAD-Daten gespeichert sind und wobei im zweiten Simulator (5) CAD-Daten gespeichert sind.

Description

In einer digitalen Fabrik können unterschiedliche Aspekte einer Anlage bzw. einer Maschine von unterschiedlichen Simulationstools simuliert werden. Zum Beispiel wird in einem ersten Simulationstool ein Materialfluss in der Anlage und in einem zweiten Simulationstool die Kinematik eines Handhabungsautomaten abgebildet. Die Simulationstools sind voneinander unabhängig.
Eine Aufgabe der vorliegenden Erfindung ist es, die Simulation einer Anlage, Maschine oder auch einer Fabrik zu verbessern.
Die Lösung der Aufgabe gelingt mittels eines Simulationssystems bzw. mittels eines Verfahrens nach einem der Ansprüche 1 bis 15.
Zur Verbesserung einer Simulation können zumindest zwei Simulationstools derart ausgebildet werden, dass diese Simulationstools untereinander Daten austauschen, wobei insbesondere Ergebnisse einzelner Simulationstools auch zusammengefasst werden können. Eine Zielsetzung der Simulation kann es z. B. sein, eine Interaktion eines Handhabungsautomaten mit einem Prozessgut abzuklären. Dies betrifft beispielsweise Verpackungsmaschinen, Druckmaschinen, Farbauftragseinrichtungen bei Druckmaschinen, Pressen, Holzverarbeitungsmaschinen, Glasbearbeitungsmaschinen, Anlagen zur Herstellung von Produkten unterschiedlicher Art und Ausprägung, wie Waschmaschinen, Autos, Elektromotoren, ABS-Gehäuse oder Elektronikartikel.
Ein Simulationssystem weist beispielsweise folgende Komponenten auf:

• einen ersten Simulator zur Simulation eines ersten physikalischen Prozesses;
• einen zweiten Simulator zur Simulation eines zweiten physikalischen Prozesses; und
• einen Server, insbesondere einen Objektserver, zur Verarbeitung von Daten aus dem ersten Simulator und zur Verarbeitung von Daten aus dem zweiten Simulator.

Im ersten Simulator und im zweiten Simulator sind CAD-Daten gespeichert. CAD-Daten stammen von einem CAD-System (Computer-Added-Design-System). CAD-Daten betreffen eine Geometriebeschreibung. Der Server kann in einer Ausgestaltung über Transformationsvorschriften verfügen. Durch eine oder mehrere Transformationsvorschriften können Zustände in Abhängigkeiten von anderen Zuständen ermittelt werden. So kann beispielsweise ein Zustand aus dem ersten Simulator in einen vergleichbaren Zustand des zweiten Simulators transformiert werden. Damit können Simulatoren untereinander angepasst werden.
Gemäß einer Variante des Simulationssystems sind im Objekt-Server CAD-Daten gespeichert. Der Server ist insbesondere ein Rich-Object-Server. Von dem Server können CAD-Daten an einen oder auch an eine Vielzahl von Simulatoren übertragen werden. Für den Fall, dass unterschiedliche Simulatoren unterschiedliche CAD-Daten benötigen werden vom Server CAD-Daten zu einem der Simulatoren übertragen, welche für diesen spezifischen Simulator spezifisch benötigt werden.
Gemäß einer Variante des Simulationssystems ist im Server ein Plug-in gespeichert. Das Plug-in ist ein Software-Erweiterungsmodul für ein Computerprogramm, dessen Funktionalität damit erweitert wird. Das Plug-in ist beispielsweise ein Plug-in eines Simulators oder einer anderen Software. Das Plug-in kann in einem DLL-Format vorhanden sein oder auch als ein proprietärer Dateninformationsblock. In einer Ausführungsform ist im Server ein erstes Plug-in des ersten Simulators gespeichert, und ein zweites Plug-in des zweiten Simulators. Das Plug-in kann verschiedene Informationen beinhalten, wie zumindest eine der folgenden:

• Informationen darüber, welche Daten der Simulator für eine Simulation benötigt;
• Informationen darüber, welche Simulationsdaten auf einem Userinterface dargestellt werden sollen;
• Informationen darüber, welche Simulationsdaten wie auf einem Userinterface dargestellt werden sollen;
• Informationen darüber, welche Attribute von Objekten (Software-Objekten) vom Simulator benötigt werden;
• Informationen darüber, welche CAD-Daten an den Simulator zu übermitteln sind;
• usw.

Gemäß einer Variante des Simulationssystems weist das Simulationssystem einen ersten Signalverarbeitungssimulator und einen zweiten Signalverarbeitungssimulator auf. Ein Signalverarbeitungssimulator simuliert z. B. eine Numerische Steuerung (Numerical Control (NC), eine Computer Numerical Control (CNC)), einen Kern der NC (NCK), eine Speicherprogrammierbare Steuerung (SPS (PLC)), eine Bewegungssteuerung, eine Antriebssteuerung, usw.).
Der erste Signalverarbeitungssimulator ist beispielsweise zur Verarbeitung von Daten des ersten Simulators vorgesehen, wobei der zweite Signalverarbeitungssimulator zur Verarbeitung von Daten des zweiten Simulators vorgesehen ist. Der erste und der zweite Signalverarbeitungssimulator simulieren eine Steuerungsfunktion und/oder eine Regelungsfunktion.
Gemäß einer Variante des Simulationssystems weist zumindest ein Signalverarbeitungssimulator CAD-Daten auf. Diese CAD-Daten können beispielsweise Achsmaße, Baugrößen oder auch Identifikationsdaten von Bauteilen betreffen. Die CAD-Daten der Signalverarbeitungssimulatoren können direkt vom Server (z. B. einem Object-Server) übermittelt worden sein oder auch indirekt über Simulatoren zur Nachbildung von Bewegungen mechanischer Objekte. Der erste und/oder der zweite Simulator sind als derartige Simulatoren ausbildbar. Bei der indirekten Übermittlung von CAD-Daten zu einem Signalverarbeitungssimulator werden die CAD-Daten zunächst z. B. zum ersten Simulator übertragen. Vom ersten Simulator werde die CAD-Daten zum Signalverarbeitungssimulator übertragen.
Gemäß einer Variante des Simulationssystems weist dieses einen Zeitmanager auf. Der Zeitmanager steuert oder regelt Funktionen verschiedener Simulatoren. Auch Signalverarbeitungssimulatoren können im Verhältnis zueinander durch den Zeitmanager zeitbezogen koordiniert und/oder kontrolliert werden. Mit Hilfe des Zeitmanagers ist es beispielsweise möglich verschiedene Funktionen bzw. Simulationsschritte verschiedener Simulatoren (z. B. für mechanische Vorgänge oder auch für Vorgänge einer Signalverarbeitung) aufeinander abzustimmen. So ist der Zeitmanager als ein Synchronisator einer Vielzahl von Simulatoren einsetzbar. In einer Variante ist der Zeitmanager datentechnisch sowohl mit Simulatoren verknüpft, als auch mit einem oder mehreren Objekt-Servern, die ihrerseits mit den Simulatoren datentechnisch verbunden sind. Der Zeitmanager auch in den Server integriert sein.
Gemäß einer Variante des Simulationssystems ist ein physikalisches Objekt durch ein Software-Objekt im Simulationssystem repräsentiert. Beispiele für physikalische Objekte sind Produktionsgüter (z. B. ein Gehäuse, eine Flasche, ein Schlauchbeutel, eine Elektronikbaugruppe, ein Auto, usw.). Das Software-Objekt weist zumindest ein Attribut auf, wobei das Attribut der Beschreibung des physikalischen Objektes dient. Ist das physikalische Objekt beispielsweise eine Flasche, so kann das Software-Objekt ein Attribut für folgende Beschreibungsmerkmale aufweisen: Größe, Form, Material, Farbe, Ort in der Ebene, Ort im Raum, Temperatur, Alter, Abnutzungsgrad, usw.
Gemäß einer Variante des Simulationssystems verwaltet der Objekt-Server Attribute von Software-Objekten. Dies hat den Vorteil einer zentralen Datenhaltung. Ferner ist im Objekt-Server gespeichert welcher der Simulatoren für welches Software-Objekt welche Attribute benötigt. Es gibt Anwendungsfälle bei welchen nicht jeder Simulator alle Informationen über alle Attribute benötigt. Der Objekt-Server kann deshalb derart ausgebildet sein, dass dieser nur die Attriubute eines Software-Objektes an einen Simulator (insbesondere auch einen Signalverarbeitungssimulator) übermittelt, welche der Simulator für die auszuführende Simulation benötigt.
Nach einem Simulationsverfahren zur Simulation physikalischer Prozesse können verschiedene Simulatoren miteinander verknüpft werden. Nachfolgend werden Beispiele für physikalische Prozesse aufgelistet:

– Bewegen einen Körpers
– Erhitzen eines Körpers
– Kühlen eines Körpers
– Bearbeitung eines Körpers (Drehen, Fräsen, Schleifen, Polieren, Biegen, Stanzen, Walzen, Gießen, Spritzen, Beschichten, Dotieren ...)
– ...

Bei dem Simulationsverfahren können z. B. folgende Maßnahmen einzeln oder gemeinsam durchgeführt werden:

– mittels eines ersten Simulator wird ein erster physikalischer Prozess simuliert;
– mittels eines zweiten Simulators wird ein zweiter physikalischer Prozess simuliert;
– mittels eines Servers (insbesondere eines Objekt-Servers) werden Daten aus dem ersten Simulator und Daten aus dem zweiten Simulator verarbeitet;
– Verarbeiten von CAD-Daten im ersten Simulator; und
– Verarbeiten von CAD-Daten im zweiten Simulator.

Vorteilhaft werden Simulationsergebnisse des ersten Simulators an den Server übertragen. Daten des Servers, welche von den Simulationsergebnissen des ersten Simulators abhängen, können dann beispielsweise an den zweiten Simulator übertragen werden. Im zweiten Simulator können diese Daten dann für eine weitere Simulation verwendet werden. Die zeitliche Abfolge der Datenübermittlung kann vorteilhaft mittels eines Zeitmanagers erfolgen.
Die CAD-Daten, welche im ersten und zweiten Simulator verarbeitet werden, sind vorteilhaft vom Server zu den Simulatoren übertragen worden. Der Server hat die CAD-Daten beispielsweise über eine Netzwerkverbindung, über ein Internet von einem CAD-System erhalten. Damit werden die CAD-Daten zentral im Server für verschiedene Simulatoren verwaltet.
Das Simulationsverfahren kann entsprechend der obig erfolgten Beschreibung des Simulationssystems erweitert und ergänzt werden.
Gemäß einer Variante des Simulationsverfahrens werden im Server CAD-Daten gespeichert und/oder verarbeitet, wobei zwischen dem Server und dem ersten Simulator Daten ausgetauscht werden, wobei zwischen dem Server und dem zweiten Simulator Daten ausgetauscht werden. Vorteilhaft werden Attribute zu Software-Objekten, welche im ersten Simulator verwendet werden im Server gespeichert. Des Weiteren können auch Attribute zu Software-Objekten, welche im zweiten Simulator oder in weitern zusätzlichen Simulatoren verwendet werden im Server gespeichert werden. Entsprechen sich Software-Objekte verschiedener Simulatoren, so können diese im Server zusammengefasst werden, wobei der Server die Attribute der sich entsprechenden Software-Objekte speichert und bei Bedarf die jeweiligen spezifisch benötigten Attributinhalte zur Verfügung stellt.
Gemäß einer Variante des Simulationsverfahrens wird ein erster Signalverarbeitungssimulator zur Verarbeitung von Daten des ersten Simulators verwendet wird. Ein zweiter Signalverarbeitungssimulator wird zur Verarbeitung von Daten des zweiten Simulators verwendet, wobei mittels des ersten und des zweiten Signalverarbeitungssimulators eine Steuerungsfunktion simuliert wird, wobei der erste Signalverarbeitungssimulator und/oder der zweite Signalverarbeitungssimulator Funktionen zumindest eines der im Folgenden aufgeführten Geräte simuliert:

• eine Speicher-Programmierbare-Steuerung (SPS);
• eine Numerical-Control (NC, bzw. CNC);
• eine Antriebseinrichtung (z. B. Wechselrichter, Umrichter, Bewegungssteuerung, usw.);
• usw.

Gemäß einer Variante des Simulationsverfahrens werden vom Objekt-Server Software-Objekte verwaltet, wobei die Software-Objekte Attribute aufweisen, wobei ein Software-Objekt eine Vielzahl von Attributen aufweist, wobei abhängig vom Simulator vom Objekt-Server unterschiedliche Attribute eines Software-Objektes an die unterschiedlichen Simulatoren übermittelt werden.
Gemäß einer Variante des Simulationsverfahrens simuliert der erste Simulator einen Transport eines physikalischen Objektes. Der zweite Simulator simuliert eine Bearbeitung oder Verwendung des physikalischen Objektes für etwas. Bei Schlauchbeutelverpackungsmaschinen kann z. B. ein Schlaubeutel mit einem Füllgut befüllt werden, was durch einen Simulator simuliert werden kann.
Gemäß einer Variante des Simulationsverfahrens werden Simulationsergebnisse zeitlich geordnet vom ersten Simulator zum zweiten Simulator übertragen.
Gemäß einer Variante des Simulationsverfahrens werden Simulationsergebnisse der Signalverarbeitungssimulatoren in einem Datenübertragungssimulator verarbeitet. Die im Datenübertragungssimulator verarbeiteten Daten werden im ersten Simulator und/oder im zweiten Simulator weiter verarbeitet. Selbstverständlich ist weder hier in diesem Beispiel noch in den anderen beschriebenen Beispielen die Anzahl der Simulatoren auf einen ersten und einen zweiten Simulator begrenzt. Ein System kann eine Vielzahl von Simulatoren aufweisen, also auch mehr als zwei.
In einer Ausgestaltung des Systems fügt der Rich Objekt Server einem Objekt, welches er aus einer CAD-Anwendung erhält zumindest ein Attribut hinzu. Beispielsweise wird jedem Objekt in der Struktur ein Attribut für einen jeweiligen Zustand hinzugefügt. Simulationssysteme und globale Funktionen können derart ausgebildet sein, dass diese die Attribute abfragen und/oder setzen können.
Ein Simulationssystem kann einen Rich Object Server verwenden, um Daten zwischen den Simulationstools und den globalen Funktionen auszutauschen, der Visualisierung, der Erfassung von Eingangsdaten, dem Ploten von Ergebnissen und dem Logging. Der Rich Object Server kann die Struktur der CAD-Daten der Anlage bzw. Maschine übernehmen. Dabei fügt er z. B. jedem Objekt in der Struktur Attribute für die jeweiligen Zustände hinzu. Simulationssysteme und globale Funktionen können diese Attribute abfragen bzw. setzen. Darüber hinaus verfügt der Rich Object Server beispielsweise auch über Transformationsvorschriften. Durch sie können Zustände in Abhängigkeiten von anderen Zuständen ermittelt werden. Eine zentrale Verwaltung und ein zentraler Austausch von Daten kann über den Rich Object Server erfolgen. Die Datenstruktur im Rich Objekt Server kann auf der Basis der CAD-Datenstruktur basieren. Somit kann ein durchgängiger Datenaustausch zwischen den Simulationstools erfolgen, wobei auch eine Sammlung der Daten für zentrale Funktionen wie Viewer, Logger Scopes und Data Inputs realisierbar ist. Zur Verwaltung der Zustände insbesondere aller Simulationsobjekte mit ihrer CAD-Datenstruktur in dem Rich Objekt Server ist eine entsprechende Speichervorrichtung vorgesehen. Vorteilhaft übergibt jedes Simulationstools regelmäßig die auszutauschenden Zustände ihrer Simulationsobjekte an den Rich Object Server, wobei jedes Simulationstools die Zustände einzelner Objekte in dem Rich Objekt Server abfragen kann. Zudem können globale Programme auf den Rich Object Server zugreifen, um die relevanten Eigenschaften aller Objekte abzufragen.
Nachfolgend wird die Erfindung beispielhaft erklärt. Die dargestellten bzw. beschriebenen Varianten könnten auch teilweise oder vollständig miteinander kombiniert werden. Die nachfolgenden Beispiele beschränken die Erfindung nicht. Auch andere Ausgestaltungen der Erfindung sind möglich, welche von den beschriebenen Beispielen abweichen. Die Darstellung zeigen mit:
1 einen schematischen Aufbau eines Simulationssystems, wobei sich hieraus ein entsprechendes Simulationsverfahren ableiten lässt;
2 ein praktisches Anwendungsbeispiel; und
3 Software-Objekte mit zugehörigen Attributen.
Die Darstellung gemäß 1 zeigt ein Simulationssystem 1. Das Simulationssystem weist einen ersten Simulator 3, einen zweiten Simulator 5, einen dritten Simulator 43, einen vierten Simulator 45 und einen fünften Simulator 47 auf. Einer der Simulatoren simuliert beispielsweise eine Transporteinrichtung zum Transport eines Gutes. Ein weiterer Simulator simuliert z. B. ein Gerät wie einen Sinamic^®. Diese Simulatoren 3, 5, 43, 45 und 47 sind Simulationswerkzeuge zur Simulation verschiedenster Vorgänge, welche zumeist mit einem mechanischen/pysikalischen/chemischen Vorgang in Verbindung gebracht werden können.
Ein Beispiel für Simulatoren sind Physik-Engines. Eine Physik-Engine ist eine Software bzw. eine Kombination aus einer Software und einer Hardware, welche als eine Art Physikmodul eine Simulation eines physikalischen Prozesses sowie der Berechnung objektimmanenter Eigenschaften (z. B. einem Impuls) dient. Ein Ziel kann auch die Simulation von Umweltbedingungen oder dergleichen sein. Vorteilhaft sind Simulatoren, wie Physik-Engines, welche echtzeitfähig sind. Mit der Hilfe einer Physik-Engine lässt sich beispielsweise folgendes simulieren:

• eine physikalische Betrachtungsweise eines starren Körperr (rigid body mechanics)/die Physik starrer Körper bedient sich insbesondere der Gesetze der klassischen Mechanik;
• Stöße zwischen Körpern, mit z. B. plötzliche Richtungs- und Impulsänderungen;
• Masse-Feder Modelle;
• Partikelsysteme u. a. als Grundlage der Simulation von Fluiden (flüssig oder gasförmig);
• elektrische Ladungen und deren Wechselwirkungen;
• usw.

Um Daten zwischen einer Vielzahl von Simulationstools 3, 5, 43, 45 und 47 austauschen zu können, wird ein Rich Object Server 7 verwendet. Ein Rich Object ist ein Software-Objekt. Dieses Software-Objekt dient beispielsweise der Verwaltung generischer Daten. Das Software-Objekt kann hierfür Attribute aufweisen. Mittels des Rich Object Servers können die Software-Objekte verwaltet werden. Die Attribute des Rich Objects sind abhängig von dem Simulationstool 3, 5, 43, 45 und 47, für welches das jeweilige Rich Object vorgesehen ist. Der Rich Object Server 7 ist ein Server, welcher die Rich Objects verwaltet und/oder speichert. Der Rich Object Server kann beispielsweise auch noch zur Ausübung anderer Funktionalitäten vorgesehen sein, wie z. B. einem Datenaustausch für eine Funktion, welche zumindest zwei Simulationstools übergreifend betrifft. Unter einer derartigen übergreifenden, also globalen Funktion ist beispielsweise zu verstehen:

• eine Visualisierung;
• eine Erfassung von Eingangsdaten;
• ein Ploten von Ergebnissen; bzw.
• ein Logging von Daten.

Das Simulationssystem weist hierfür z. B. auch eine Dateneingabeeinrichtung 50, einen Plotter (Scope) 51, einen Logger (Datensammler) 52, und einen Viewer 53 (Man Machine Interface wie z. B. ein Bildschirm) auf.
Der Rich Object Server ist mit zumindest einen Client verbunden. Beispiele für Clients sind:

• der erste Simulator 3, bzw. eine erste Einrichtung, auf welcher das erste Simulationstool ablauffähig ist;
• ein zweiter Simulator 5, bzw. eine zweite Einrichtung, auf welcher das zweite Simulationstool ablauffähig ist;
• eine NC-Steuerung einer Werkzeugmaschine;
• eine Engineeringsoftware zur Erstellung eines Anwenderprogrammes;
• eine Antriebssteuereinrichtung;
• usw.

Der Rich Object Server 7 ist dafür vorgesehen, dass er z. B. CAD-Daten einer Anlage bzw. einer Maschine übernimmt. Diese Übernahme kann Rich Objects involvieren. Die CAD-Daten betreffen beispielsweise, ein Maschinen- oder Anlage-Verhalten, bauliche Maße der Maschine oder Anlage, Maße und Daten des oder der Gegenstände, welche von der Anlage oder Maschine manipuliert, erstellt oder bearbeitet werden, usw.
Vorteilhaft übernimmt der Rich Object Server die Struktur der CAD-Daten ganz oder teilweise. CAD-Daten können z. B. folgender maßen strukturiert werden:

• in Einzelkörperansichten;
• in Funktionsansichten;
• in Assembly-Ansichten (bei Werkzeugmaschinen z. B. Maschinenbett, Bearbeitungsturm, Spindel, ...);
• usw.

Vorteilhaft fügt der Rich Objekt Server einem Software-Objekt, welches er aus einer CAD-Anwendung erhält, zumindest ein Attribut hinzu. Beispielsweise wird jedem Objekt in der Struktur ein Attribut für einen jeweiligen Zustand hinzugefügt. Simulationssysteme und globale Funktionen können derart ausgebildet sein, dass diese die Attribute abfragen und/oder setzen können.
Vorteilhaft können dadurch Möglichkeiten zum Austausch von Daten zwischen Simulationstools erweitert werden. Dieser Austausch kann z. B. über Mechanismen wie OPC, ODE, COM/DCOM oder CORBA realisiert werden. Ein Datenaustausch kann auch für sich projektiert werden, wenn zentrale Objekte verwendet werden, die von sich aus über keine implizite Datenstruktur verfügen. Dann sind alle Variablen und auch die Datenstrukturen separat festzulegen. Dabei ist darauf zu achten, dass diese konsistent und nachvollziehbar bleiben. Bei einer Verwendung des Rich-Objekt-Servers mit den Attributen für die Objekte ist dies vereinfacht und stellt eine effizientere Lösung dar. Dies gilt insbesondere deshalb, weil zwischen vielen Tools die Kopplungsschnittstellen nur rudimentär ausgeprägt sind. So müssen Funktionalitäten z. B. als C-Code durch den Anwender implementiert werden. Zudem sind Einschränkungen bei den einzelnen Mechanismen vorhanden, u. a. hinsichtlich der Zykluszeiten und der Datenflussrichtungen. Dabei ist das Thema der ”virtuellen Zeitachse” ebenfalls nur rudimentär in manchen Anwendungen berücksichtigt. SO bedarf es zum Datenaustausch zwischen den einzelnen Tools einer Zwischeninstanz, um unterschiedliche Zykluszeiten zu überbrücken und Wartezeiten zu vermeiden. Als eines der Austauschformate für CAD-Daten wird das JT-Format verwendet. Dabei besteht die Möglichkeit, auch die Kinematik mit abzubilden und diese für die Visualisierung von Simulationen zu verwenden.
Obig beschriebene Nachteile können mittels einer zentralen Komponente wie dem Rich Object Server 7 überwunden werden. Mit dem Server 7 kommunizieren die einzelnen Simulationstools 3, 41, 43, 45 und 47 wie auch die Tools zur Realisierung globaler Funktionen 50, 51, 52 und 53.
Der Rich Object Server 7 baut seine Datenstruktur durch den Import von CAD-Daten auf. Die Darstellung gemäß 3 zeigt ein Beispiel für ein Objektmodell zu einem Simulationszenario, welches sich im Server 7 befindet. Dabei übernimmt der Server die Objektstrukturen aus CAD-Daten. Wenn ein Simulationstool einen Zustand eines Objektes speichern möchte, so legt der Rich Object Server ein Attribut bei dem entsprechenden Objekt 87 an bzw. aktualisiert das entsprechende Attribut direkt an dem entsprechenden CAD-Objekt. Der Server 7 verwaltet dabei auch die Informationen von dynamisch zur Laufzeit erzeugten Objekten 85, 86 und 87, wie den Prozessgutobjekten, indem er für jedes dieser Objekte eine eigene Instanz des jeweiligen CAD-Satzes lädt.
In einer vorteilhaften Ausgestaltung kann jedes Simulationstool 3, 41, 43, 45, 47, 48, 49, 13, 14, 15, 16 und 18 auf alle Attribute 92 aller Objekte sowohl schreiben als auch lesend zugreifen. Die einzelnen Simulationstools 3, 41, 43, 45, 47, 48, 49, 13, 14, 15, 16 und 18 verfügen z. B. über domänenspezifische Modelle, wie u. a. der Kinematik. Sie übergeben zu Laufzeit ihre Ergebnisse an den Rich Objekt Server 7. Dadurch entstehen über den koordinierten Rich Object Server Multidomänensimulationen.
Auf dem Rich Object Server 7 setzen Tools für globale Funktionen 50, 51, 52 und 53 auf. Dabei können die Funktionen Visualisierung, Erfassung von Eingangsdaten, Ploten von Ergebnissen und Logging realisiert werden. Durch die zentrale Datenhaltung können diese Funktionen durch zeitlich konsistente Daten versorgt werden. Dabei können auch für die Visualisierung die Attribute von den Objekten von dem Rich Objekt Server für die Positionen, Ausrichtungen, Farben und Transparenz der Objekte direkt übernommen werden, da die Objektstrukturen hier identisch sein können.
Wie die Darstellung gemäß 1 zeigt, weist der Rich Object Server 7 Plug-In's 59 auf. Diese Plug-In's 59 stammen beispielsweise von Simulatoren bzw. betreffen diese. Die Simulatoren 3, 5, 43, 45, 47, 16, 18 können von einem Zeitmanager 23 zeitlich gesteuert werden. Hierfür werden Zeitmanagementdaten 24 eingesetzt.
Das System 1 kann auch eine Echtzeit-Einheit 41 aufweisen. Die in der 1 dargestellte Echtzeit-Einheit 41 weist den zweiten Simulator 5 und den zweiten Signalverarbeitungssimulator 15 auf. Diese beiden Simulatoren sind über einen Echtzeit Kommunikationspfad 42 miteinander verbunden. Die verschiedenen Simulatoren des Systems sind darüber hinaus mit weiteren Kommunikationspfaden 40 miteinander verbunden. Dadurch ist ein Kommunikationsnetz 49 ausgebildet, welches auch simuliert werden kann.
In das Kommunikationsnetz sind auch ein OPC-Server 48, eine Numerical Control 19, ein erster Signalverarbeitungssimulator 13 (z. B. für einen virtueller NC-Kern), ein zweiter Signalverarbeitungssimulator 14 (z. B. für eine virtuelle speicherprogrammierbare Steuerung), ein dritter Signalverarbeitungssimulator 15 (z. B. für eine virtuelle Bewegungssteuerung), ein vierter Signalverarbeitungssimulator 16 (z. B. für eine simulierte/emulierte speicherprogrammierbare Steuerung) und ein fünfter Signalverarbeitungssimulator 18 mit eingebunden.
Die Darstellung gemäß 2 zeigt schematisch ein Simulationsszenrio für eine Flaschenbefülleinrichtung 60. Es ist also ein Prozess der Flaschenabfüllung zu simulieren. Gemäß des Simulationsszenarios nach 2 sind die Prozessgutelemente Flaschen 62, 63 und 64, welche durch Objekte repräsentiert werden können, wobei diese Objekte z. B. Attribute wie eine Flaschengröße aufweisen können. Für diese können, wie auch in 3 dargestellt wird, Transformationen zwischen den Objekten eines dynamischen Teilmodells und eines statischen Teilmodell des Datenmodells in dem Rich Object Server erforderlich sein. Ein möglicher Aufbau des Gesamtsimulationssystems ist bereits in der 1 skizziert. Hier werden die Daten zwischen den Simulationssystemen 3, 41, 43, 45 und 47 durch den Rich Object Server ausgetauscht. Die Simulationssysteme können direkt mit den Steuerungen 13, 14, 15, 16 oder 18 kommunizieren, oder auch indirekt über ein simuliertes oder reales Kommunikationsnetz 49. Ein Beispiel für ein Kommunikationsnetz ist das ProfiNet. Für die Kommunikation können Zeitscheiben mittels eines zentralen Zeitmanagers 23 koordiniert werden.
Die Darstellung gemäß 2 zeigt, dass die Flaschen 62, 63, 64 mittels eines Transportbandes 61 zu einem Flaschenbefüller 65 transportier werden können. Derart wird ein Befüllsystem 68 ausgebildet. Diesem System kann beispielsweise eine Funktion zugeordnet werden: m = f(d). Mittels des Transportbandes 61 kann ein Flasche 64 auch zu einem Manipulatorsystem 69 transportiert werden. Das Manipulatorsystem 69 weist einen Manipulator 66 auf. Auch diesem System können Funktionen zugeordnet werden, wie z. B.: (x, y) = f(px, py); (Fx, Fy) = f(m). Neben diesem Manipulatorsystem 69 gibt es auch eine Antriebseinrichtung 21 und eine speicherprogrammierbare Steuerung 17. Ein Materialfluss von Flaschen 62, 63 und 64 kann ein einem Transportsystem 67 simuliert werden.
Die Darstellung gemäß 3 zeigt einen Umgang mit Software-Objekten und mit den zugehörigen Attributen. Der Rich Objekt Server 7 führt die Informationen der Modelle der unterschiedlichen Simulationstools mit unterschiedlichen Abstraktionsebenen zusammen. Dabei bildet er auch die Brücke für die Informationen aus dynamischen und statischen Modellen. Dazu werden in dem Rich Objekt Server 7 Transformationsvorschriften 93, 94 hinterlegt. Die Transformationsvorschriften werden durch mathematische, logische und Übertragungs-Funktionen beschrieben. Mit diesen Transformationsvorschriften 93, 94 können zum einen die Informationen aus einem dynamischen Teilmodell mit Elementen in dem statischen CAD-Modell abgeglichen werden und zum anderen Eigenschaften zwischen einer Baugruppe und ihren Elementen transformiert werden.
Ein Abgleich der Informationen der Elemente aus einem dynamischen Teilmodell 71 und Elementen aus dem statischen Modell 70 (kann sich einer CAD-Struktur bedienen) wird z. B. von dem Rich Objekt Server 7 u. a. für die Prozessgutobjekte vorgenommen. Dabei führt der Rich Objekt Server 7 zum einen logische Transformationsvorschriften 93, 94, als auch einfache Übertragungstransformationen 95, 96 aus. Die logischen Transformationsvorschriften 93, 94 dienen dazu, in einem Attribut 92 von Dummy-Prozessgutobjekten 82 in dem statischen (Teil-)Objektmodell 70 die Existenz eines Prozessgutobjektes 85, 86, 87 aus dem dynamischen Teilmodell 71 an der Position des Dummy-Prozessgutobjektes zu signalisieren. Zudem werden durch die Übertragungstransformationen 95, 96 die Eigenschaften der Prozessgutobjekte aus dem dynamischen Teilmodell an die Prozessgutobjekte aus dem statischen Modell übertragen, wenn die Positionen der beiden Objekte identisch sind. In der 3 ist auch ein übergeordnetes System 75 dargestellt, welches Daten mit Teilmodell 70 austauschen kann.
Des Weiteren ermittelt der Rich Object Server die Zustände von Baugruppen 77 aus Zuständen von den jeweiligen Elementen 78, 79 und 80. Diese Elemente sind bereits aus der 2 bekannt. Es handelt sich dabei um eine X-Achse 78, um eine Y-Achse 79 und einen Greifer 80. Auch die Elemente Abfüllstation 83 und Transportsystem sind aus der 2 bereits bekannt (dort: Flaschenabfüller 65 und Transportband 61). Eine Transformationsvorschrift 93, 94 wird dabei z. B. immer dann ausgeführt, wenn von einem System ein durch sie zu ermittelnder Zustand abgefragt wird. Dabei bildete eine Transformation keine Verhaltensbeschreibung, sondern nur den Übergang zwischen den Modellen der einzelnen Simulationstools 3, 41, 43, 45 und 47 ab.
Die Flexibilität der Simulation ist nun dadurch verbessert, dass durch eine Erweiterung der CAD-Datenstruktur um simulationsspezifische Attribute und dynamische Transformationen zwischen diesen Attributen die Datenhaltung erleichtert wird.
Die Anbindung simulatorspezifischer Attribute an die CAD-Datenstruktur führt die Datenmodelle der unterschiedlichen Simulationen in einem gemeinsamen Datenmodell zusammen, ohne die Struktur in den Einzelsimulatoren unbedingt ändern zu müssen. Die CAD-Struktur ist geeignet als gemeinsame Struktur, da sie früh im Entwurfsprozess entsteht und für alle Beteiligten anschaulich ist. Für die Simulation typischer Anlagen werden z. B. sowohl Simulationstools mit dynamischen Objekten als auch Simulationstools, die nur statische Modelle unterstützen, benötigt. Die dynamischen Transformationen ermöglichen das Zusammenwirken dieser Tools. Eine Erweiterung der Simulatoren mit statischem Objektmodell um ein dynamisches Objektmodell ist nicht unbedingt erforderlich. Der Rich Object Server ermöglicht eine Skalierung des Simulationssystems durch das Einbinden der für die konkrete Simulationsaufgabe benötigten Simulatoren. Das System bleibt dabei durch die gemeinsame Datenstruktur transparent und über zentrale Benutzerschnittstellen bedien- und beobachtbar. Damit kann eine Anlage simuliert werden, die z. B. als eine Baugruppe 77 einen hoch kinematischen Handhabungsautomat und ein Transportsystem 84 für ein Prozessgut wie Flaschen und eine Abfüllstation 83 aufweist. Dabei wird der hoch kinematische Handhabungsautomat 77 von z. B. einer SIMOTION^® und das Transportsystem 84 für das Prozessgut und die Abfüllstation 83 von einer SIMATIC^® gesteuert. Der Handhabungsautomat, das Transportsystem und die Abfüllstation sind dabei auf einem gemeinsamen Träger (Rack) 76 montiert. Ein hierzu passendes Simulationsszenario ist in der 2 abgebildet. Da der Handhabungsautomat 77 ein hoch dynamisches System und die Abfüllstation 83 ein System mit einer festen Anzahl von Objekten mit bekannten Bindungen und das Transportsystem 84 mit dem Prozessgut ein System mit einer dynamischen Anzahl von Objekten mit loser Kopplung ist, werden diese Systeme in spezialisierten Simulationsmodellen mit spezialisierten Simulationssystemen behandelt. Es werden eine Materialflusssimulation, eine Abfüllsimulation und eine Kinematiksimulation eingesetzt. Dabei verwendet die Materialflusssimulation ein dynamisches Objektmodell und die Abfüllsimulation und die Kinematiksimulation jeweils statische Objektmodelle. Wenn auch noch Fragestellungen der Behandlung des Prozessgutes durch den Handhabungsautomaten zu klären sind, so können die Zustände der Objekte der Anlage und des Prozessgutes über den zentralen Rich Object Server übertragen werden. In den Rich Object Server werden zur Verwaltung der Objekte die CAD-Daten der Anlage mit Dummy-Prozessgutobjekten an der Stelle eines möglichen durch den Handhabungsautomaten 77 zu behandelnden Prozessgutobjektes und an der Stelle eines zu befüllenden Prozessgutobjektes importiert. Diese Objekte bilden den statischen Teil des Objektmodells in dem Rich Object Server. Zudem wird von dem Simulationssystem für die Materialflusssimulation für jedes Prozessgutobjekt eine Instanz dynamisch in dem Rich Object Server angelegt. Dabei entsteht der dynamische Teil 71 in dem Objektmodell des Rich Object Servers.
In einer Variation kennt der Rich Object Server keine Verhaltensbeschreibungen der Anlage oder ihrer Objekte. Diese Verhaltensbeschreibungen, wie ein kinematisches Modell 72, ein Abfüllmodell 73 und ein Materialflussmodell 74 sind nur den jeweiligen Simulationssystemen bekannt. Da es zwischen den Simulationsmodellen eine Diskrepanz in der Struktur der auszutauschenden Daten geben kann, dies ja sogar wahrscheinlich ist, sind Transformationsvorschriften 93, 94 notwendig. So wird in einer Transformationsvorschrift 93, 94 das Attribut für das Vorhandensein eines stationären Platzhalterobjektes für ein Prozessgutelement, das gerade manipuliert werden soll, z. B. mit den Werten richtig/true bzw. falsch/false belegt. Dabei nimmt es den Wert true nur dann ein, wenn sich ein tatsächlich vorhandenes, gleichartiges Element des Materialflusses an genau derselben Position befindet. In einer weiteren Transformationsvorschrift bzw. in einer Übertragungstransformation 95, 96 werden die Eigenschaften zwischen den beiden Objekten synchronisiert. Dadurch kann die unterschiedliche Natur des statischen Objektmodells des Handhabungsautomaten 77 bzw. der Abfüllstation 83 und des dynamischen Objektmodells, also der dynamischen Ebene 71 des Materialflusses überwunden werden.
Aufbauend auf dem Rich Object Server können wie auch in 1 dargestellt die Visualisierung, die Erfassung von Eingangsdaten, das Ploten von Ergebnissen und das Logging zentral vorgenommen. Dadurch lassen sich die verschieden Simulationssysteme synchron mit Eingangsdaten versorgen und es lässt sich die Interaktion des Handhabungsautomaten mit dem Prozessgut auswerten. Die verschiedenen Simulationssysteme betreffen dabei z. B. das statische Simulationsmodell und das dynamische Simulationsmodell oder auch ein System die Physik/Kinematik und ein System zur Modellierung einer oder mehrerer Steuerungen/Regelungen.

Claims

Simulationssystem (1), welches – einen ersten Simulator (3) zur Simulation eines ersten physikalischen Prozesses, – einen zweiten Simulator (5) zur Simulation eines zweiten physikalischen Prozesses, – einen Server (7), insbesondere einen Objekt-Server, zur Verarbeitung von Daten aus dem ersten Simulator (3) und zur Verarbeitung von Daten aus dem zweiten Simulator (5), aufweist, wobei – im ersten Simulator (3) CAD-bezogene Daten gespeichert sind, und wobei – im zweiten Simulator (5) CAD-bezogene Daten gespeichert sind.
Simulationssystem (1) nach Anspruch 1, dadurch gekennzeichnet, dass im Server (7) CAD-Daten gespeichert sind.
Simulationssystem (1) nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass im Server (7) ein erstes Plug-in (9) des ersten Simulators (3) gespeichert ist, und dass im Server (7) ein zweites Plug-in (11) des zweiten Simulators (5) gespeichert ist.
Simulationssystem (1) nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass das Simulationssystem (1) einen ersten Signalverarbeitungssimulator (13) und einen zweiten Signalverarbeitungssimulator (15) aufweist, wobei der erste Signalverarbeitungssimulator (13) zur Verarbeitung von Daten des ersten Simulators (3) vorgesehen ist, wobei der zweite Simulator (5) zur Verarbeitung von Daten des zweiten Simulators (5) vorgesehen ist, wobei der erste Signalverarbeitungssimulator (13) eine Steuerungsfunktion und/oder eine Regelungsfunktion simuliert, und wobei der zweite Signalverarbeitungssimulator (15) eine Steuerungsfunktion und/oder eine Regelungsfunktion simuliert.
Simulationssystem (1) nach Anspruch 4, dadurch gekennzeichnet, dass der erste Signalverarbeitungssimulator (13) und/oder der zweite Signalverarbeitungssimulator (15) Funktionen zumindest eines der im folgenden aufgeführten Geräte simuliert: eine Speicher-Programmierbare-Steuerung (17), eine Numerical-Control (19), eine Antriebseinrichtung (21).
Simulationssystem (1) nach einem der Ansprüche 1 bis 5, dadurch gekenneichnet, dass das Simulationssystem (1) einen Zeitmanager (23) aufweist, wobei der Zeitmanager (23) unterschiedliche Simulatoren (3, 5, 13, 15) steuert oder regelt.
Simulationssystem (1) nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass ein physikalisches Objekt (30) durch ein Software-Objekt (32) im Simulationssystem (1) repräsentiert ist, wobei das Software-Objekt (32) zumindest ein Attribut (92) aufweist, wobei das Attribut (62) der Beschreibung des physikalischen Objektes (30) dient.
Simulationssystem (1) nach Anspruch 7, dadurch gekennzeichnet, dass der Server (7) Attribute (92) von Software-Objekten (32) verwaltet.
Simulationsverfahren zur Simulation physikalischer Prozesse, dadurch gekennzeichnet, dass – mittels eines ersten Simulator (3) ein erster physikalischer Prozess simuliert wird, – mittels eines zweiten Simulators (5) ein zweiter physikalischer Prozess simuliert wird, – mittels eines Servers (7), insbesondere eines Objekt-Servers, Daten aus dem ersten Simulator (3) und Daten aus dem zweiten Simulator (5) verarbeitet werden, – CAD-Daten im ersten Simulator (3) verarbeitet werden, und dass – CAD-Daten im zweiten Simulator (5) verarbeitet werden.
Simulationsverfahren nach Anspruch 9, dadurch gekennzeichnet, dass im Server (7) CAD-Daten gespeichert und/oder verarbeitet werden, wobei zwischen dem Server (7) und dem ersten Simulator (3) Daten ausgetauscht werden, wobei zwischen dem Server (7) und dem zweiten Simulator (5) Daten ausgetauscht werden.
Simulationsverfahren (1) nach Anspruch 9 oder 10, dadurch gekennzeichnet, dass ein erster Signalverarbeitungssimulator (13) zur Verarbeitung von Daten des ersten Simulators (3) verwendet wird, dass ein zweiter Signalverarbeitungssimulator (15) zur Verarbeitung von Daten des zweiten Simulators (5) verwendet wird, wobei mittels des ersten Signalverarbeitungssimulators (13) eine Steuerungsfunktion und/oder eine Regelungsfunktion simuliert wird, und wobei mittels des zweiten Signalverarbeitungssimulators (15) eine Steuerungsfunktion und/oder eine Regelungsfunktion simuliert wird, wobei der erste Signalverarbeitungssimulator (13) und/oder der zweite Signalverarbeitungssimulator (15) Funktionen zumindest eines der im folgenden aufgeführten Geräte simuliert: eine Speicher-Programmierbare-Steuerung (17), eine Numerical-Control (19), eine Antriebseinrichtung (21).
Simulationsverfahren nach einem der Ansprüche 9 bis 11, dadurch gekennzeichnet, dass vom Server (7) Software-Objekte (32) verwaltet werden, wobei die Software-Objekte (32) Attribute (92) aufweisen, wobei ein Software-Objekt (32) eine Vielzahl von Attributen (92) aufweist, wobei abhängig vom Simulator (3, 5) vom Server (7) unterschiedliche Attribute (92) eines Software-Objektes (32) an die unterschiedlichen Simulatoren (3, 5) übermittelt werden.
Simulationsverfahren nach einem der Ansprüche 9 bis 12, dadurch gekennzeichnet, dass der erste Simulator (3) einen Transport eines physikalischen Objektes (30) simuliert, und dass der zweite Simulator (5) eine Bearbeitung oder Verwendung des physikalischen Objektes (30) simuliert.
Simulationsverfahren nach einem der Ansprüche 9 bis 13, dadurch gekennzeichnet, dass mittels Simulationsergebnisse zeitlich geordnet vom ersten Simulator (3) zum zweiten Simulator (5) übertragen werden.
Simulationsverfahren nach einem der Ansprüche 11 bis 14, dadurch gekennzeichnet, dass Simulationsergebnisse der Signalverarbeitungssimulatoren (13, 15) in einem Datenübertragungssimulator (40) verarbeitet werden und die die im Datenübertragungssimulator (40) verarbeiteten Daten im ersten Simulator (3) und/oder im zweiten Simulator (5) weiter verarbeitet werden.