EP0954772A1 - Virtueller roboter - Google Patents

Virtueller roboter

Info

Publication number
EP0954772A1
EP0954772A1 EP98962389A EP98962389A EP0954772A1 EP 0954772 A1 EP0954772 A1 EP 0954772A1 EP 98962389 A EP98962389 A EP 98962389A EP 98962389 A EP98962389 A EP 98962389A EP 0954772 A1 EP0954772 A1 EP 0954772A1
Authority
EP
European Patent Office
Prior art keywords
controller
abstract
translator
virtual robot
model
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP98962389A
Other languages
English (en)
French (fr)
Inventor
Helmut BLÖCKER
Gerhard Kauer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Helmholtz Zentrum fuer Infektionsforschung HZI GmbH
Original Assignee
Helmholtz Zentrum fuer Infektionsforschung HZI GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Helmholtz Zentrum fuer Infektionsforschung HZI GmbH filed Critical Helmholtz Zentrum fuer Infektionsforschung HZI GmbH
Publication of EP0954772A1 publication Critical patent/EP0954772A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
    • B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
    • B25J9/00—Programme-controlled manipulators
    • B25J9/16—Programme controls
    • B25J9/1602—Programme controls characterised by the control system, structure, architecture
    • B25J9/1605—Simulation of manipulator lay-out, design, modelling of manipulator
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/33—Director till display
    • G05B2219/33053—Modular hardware, software, easy modification, expansion, generic, oop
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/39—Robotics, robotics to robotics hand
    • G05B2219/39014—Match virtual world with real world
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/40—Robotics, robotics mapping to robotics vision
    • G05B2219/40131—Virtual reality control, programming of manipulator
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/40—Robotics, robotics mapping to robotics vision
    • G05B2219/40312—OOP object oriented programming for simulation

Definitions

  • the invention relates to a virtual robot, i.e. a method and a device for controlling robots and automatic machines, such as experiments in a laboratory or automated processes in industrial production.
  • the invention is therefore based on the object of developing a virtual robot for controlling robots or automatic machines which can be easily adapted to a wide variety of robots.
  • a virtual robot according to the invention for controlling a real machine preferably comprises a software IC “controller” for controlling the abstract machine, an IC “model” for describing the abstract world of the machine to be actually controlled, an IC “translator” for generating and using the language of the abstract machine, an IC “ro ⁇ bot” for implementing actions of an abstract Robo ⁇ ters that depend on events of the controller, IC “robot Device” to implement actions of a real robot which depend on events of the controller, and an IC “Swatch” for outputting the current internal state of the real machine to a display unit or for simulating real actions.
  • IC “controller” for controlling the abstract machine
  • an IC “model” for describing the abstract world of the machine to be actually controlled
  • an IC “translator” for generating and using the language of the abstract machine
  • an IC “ro ⁇ bot” for implementing actions of an abstract Robo ⁇ ters that depend on events of the controller
  • IC “robot Device” to
  • the software ICs "Swatch” and “Robotdevice” can be derived from an abstract base class “View”, in which the interfaces of the ICs “Swatch” and “Robotdevice” are defined. Furthermore, the software ICs “View” and “Model” can be given a common interface by means of excitation, which enables simplified communication with the "controller”.
  • the IC “Translator” consist of the Mini class “Language”, which comprises the two object classes “Grammar” and “Vocabulary”, the class “Grammar” defining the rules for actions and methods of the abstract machine, while the class “Vocabulary” contains the necessary terms.
  • the "Model” class is such that it inherits its interface to its subclasses, which include an abstract model of the world of a robot that is actually used.
  • the device control includes logging al ⁇ ler "Views”, loading the program parameters in the IC “Mo ⁇ del” and the setting up of the process in the IC world “Model”.
  • the limits of the process world are checked, and if the world limits are not reached, the pending process step is carried out while reaching the World borders of the virtual robot is ended and thus the control of the real robot is finished.
  • This object-oriented design of the software is carried out in four steps:
  • a particular effect when using such software ICs is that when a software IC is improved, all software which contains this software IC is also improved.
  • the easy interchangeability of software ICs is achieved by distinct software units exist that communicate exclusively via exactly defi ⁇ ned interfaces together.
  • the code within an IC is completely encapsulated, ie all internal elements of the ongoing data processing to the product can of au ⁇ , ie by other ICs, inaccessible.
  • FIG. 11 shows a detailed event flow diagram of the virtual robot, the focus of detail being on the IC "translator”.
  • the first step in object-oriented programming is a description of the problem for the control software.
  • an external process pushes the Ansteue- control software, and gives her the required runtime of the Pro ⁇ program parameters, such as information on the actions being performed, so in case of software for controlling a vacuum chamber, the switch-on of the vacuum pump, the numbers of the valves, Time of opening, etc.
  • This information must be translated into program parameters.
  • This is handled by a parser, adds ⁇ ver of a corresponding grammar and a vocabulary ⁇ .
  • the required functions can be understood under the grammar and the necessary data under the vocabulary. that will.
  • the control of the robot to be controlled is carried out by successive commands which have to be given to it at certain times. It is therefore necessary in clock with which the necessary synchronization can take place. Status reports on the current execution status are also required, ie an output unit for a screen is necessary.
  • a communication interface is also required to forward current commands from the control software to the robot.
  • the relevant objects are abstracted into classes of appropriate granularity.
  • the individual machines or robots to be controlled are unsuitable objects for the general design, since they are a direct symbol for the dependency.
  • the IC "controller” contains an interface to the timer of the operating system. The data that define actions for the IC "controller” directly affect its abstract world.
  • the next step is to define the interfaces and inheritance hierarchies between the classes.
  • the "Controller”, "Model” and “View” objects are decoupled, but must be synchronized. Changes of an object may affect other objects without the geän ⁇ -made object to know the other exactly. This is the De ⁇ chorus of "Observer pattern”. Therefore, the design of these three objects is based on the "Observer pattern”.
  • the "Translator” object is only used during the program ⁇ startes. It is not necessary that this object exists as long as the "controller”. A simple association is thus possible in order to establish a connection for the evaluation of the information transmitted.
  • the "Language” object shown in FIG. 1 combines the elements “Grammar” and "Vocabulary".
  • Prinzipi ⁇ ell could formulate the grammar of a language in the form of methods, the vocabulary, however, regarded as their data. This would be the classic definition of a class: summarizing data with the operations directed at it. However, you would be the one ⁇ impose limitation in this design, both elements can not be independent vari ⁇ ming. It would be more cumbersome to apply different grammars to the same vocabulary if both elements were united in one and the same class.
  • Fig. 2 shows the connection between the "Translator” object and its “Language” object.
  • the problem shows that as long as the "Translator” object exists, it needs its “Language” object. Therefore associations are excluded as a connection.
  • 00D aggregations are considered elements of synthesis: "The object consists of ", or "Object A uses object B throughout its existence for task X ".
  • the "translator” class is combined in a singular aggregation with the "Language” class, as shown in FIG. 2.
  • Fig. 3 shows the nesting of the "view” objects.
  • the “controller” implements the algorithms for controlling the various machines (eg cyclical ventilation in a vacuum chamber) and is thus an example of a “strategy pattern”.
  • the class "View” is an abstract base class' in which the interface of the concrete classes derived from it is defined. This design ensures the consistency of the interface for all views.
  • “Swatch” is the class whose copy for the graphical output of the current is responsible internal state on the screen.
  • the "robot Device” class encapsulates the respective interface Subject Author ⁇ fenden hardware to be controlled robot.
  • This class is an adapter class that resolves the hardware dependency via an adapted class.
  • the adapted classes receive the names of the devices to be controlled.
  • the object adapter for the described "view” objects uses the object composition shown in FIG. 4. Here, the Whether ⁇ If ject to "VC-Device" on behalf of all other ⁇ controlled robot.
  • the "controller” object shown in FIG. 5 is the center of the application in the present software design. It registers objects dependent on it in order to inform it in the future of any changes that may occur. Here is unmarried ⁇ Lich the signal that something has changed, sent.
  • the associated class has an interface with which the dependent objects can be synchronized with the new state via queries. In the present case, these are the dependent objects "CSR”, “PCR” and Vacuum Chamber ", which stand for three different robot types in the underlying application.
  • the dependent objects are responsible for obtaining the information relevant to them.
  • the "controller” object utilizes the data that have been available over the Whether ⁇ ject "Translator” and a gegebe ⁇ executes nes protocol.
  • the "controller” has access to the Sy ⁇ stemuhr of the computer and receives from the latter via an interface, a measure of time.
  • the "controller” class is abstract and defines an interface that is inherited from all derived classes. The classes derived from it can be easily exchanged through the common interface. The different methods for each robot are thus solved by this design, which is based on an "observer huster", as shown in FIG. 5.
  • the "model” has the same interface as a “view”. You could now derive the "model” from the abstract base class "View” to inherit this interface, but this would not be a clean representation of reality.
  • PCR is a pipetting robot
  • CRS is a gripping robot
  • Vac or VacuumChamber is an automatic vacuum chamber.
  • FIGS. 9-11 The dynamic, externally visible behavior of the system and its objects is graphically documented in FIGS. 9-11. Internal actions, which are determined by algorithms, are not taken into account unless they manifest themselves externally. All events are first identified and only then assigned to the objects. In this way, the dynamic model provides additional control as to whether the design presented in the object model is sustainable. State diagrams are thus created for each object, as is exemplarily carried out in FIGS. 9-11 with a focus on the "translator".
  • the "controller” receives a line from the “controller” which should contain information for the process to be controlled.
  • the "Translator” checks the grammar and vocabulary of this line and accepts it as a command line.
  • the "Translator” translates the content of the line into program-relevant parameters using the grammar and vocabulary available to it.
  • the translator returns these program parameters to the "controller”.
  • the "controller” receives a line from the “controller” which should contain information for the process to be controlled.
  • the "Translator” checks the grammar and vocabulary of this line and does not accept them as a command line because the grammar is incorrect.
  • the "Translator” informs the "Controller” of an incorrect command line and terminates.
  • the "controller” receives a line from the “controller” which should contain information for the process to be controlled.
  • the "Translator” determines that the transferred line is invalid.
  • the "Translator” informs the controller that it has received an incorrect line of information and aborts.
  • Fig. 11 finally, is a self-explanatory whilflußplan detail with focus "Translator”, that the relationships shown in FIGS. 9 and 10 in the Bacpro ⁇ program embeds.

Abstract

Die Erfindung betrifft einen virtuellen Roboter zum Steuern einer automatischen Maschine, wobei der virtuelle Roboter durch die Interaktion der folgenden Software-ICs gebildet wird: einen IC "Controller" zum Steuern der abstrakten Maschine; ein IC "Model", zum Beschreiben der abstrakten Welt der real zu steuernden Maschine; einen IC "Translator" zum Erzeugen der Sprache der abstrakten Maschine; einen IC "Robot" zum Implementieren von Aktionen eines abstrakten Roboters, die von Ereignissen des IC "Controllers" abhängen, einen IC "Robotdevice" zum Implementieren von Aktionen eines realen Roboters, die von Ereignissen des IC "Controllers" abhängen, und einen IC "Swatch" zum Ausgeben des aktuellen inneren Zustands der realen Maschine auf eine Anzeigeeinheit.

Description

Virtueller Roboter
Die Erfindung betrifft einen virtuellen Roboter, d.h. ein Verfahren und eine Vorrichtung zum Steuern von Robotern und automatischen Maschinen, wie beispielsweise Experimente in einem Labor oder automatisierte Verfahrensabiäufe in der industriellen Fertigung.
Automatisierte Verfahrensabläufe, in denen Vorrichtungen, die im allgemeinen als Roboter bezeichnet werden, mittels spezieller Steuerungsprogramme diverse Tätigkeiten ausführen werden in vielen industriellen Bereichen und Labors verwendet. Beispielsweise ist es bei dem Humane Genome Pro- ject notwendig, eine große Anzahl von DNA-Präparationen zur Isolierung der menschlichen Genome durchzuführen. Um zu dem gewünschten Ziel zu gelangen, ist eine automatisierte Präparation mittels Präpar Yonsroboter notwendig. Die Steuerung bzw. das Steuerungsprogramm derartiger Automaten oder Roboter ist jedoch bislang auf den verwendeten Roboter individuell zugeschnitten und angepaßt. Der Austausch eines Roboters durch einen anderen oder die Erweiterung einer Automatisierung durch Hinzufügen eines weiteren Roboters anderen Typs bedingt daher im Regelfall die Abänderung, Erweiterung oder im Extremfall den gesamten Austausch der bestehenden Steuerungssoftware.
Der Erfindung liegt daher die Aufgabe zugrunde, einen virtuellen Roboter zur Steuerung von Robotern oder Automaten zu entwickeln, der einfach an unterschiedlichste Roboter angepaßt werden kann.
Die Aufgabe wird durch die Merkmale des unabhängigen Anspruchs gelöst. Bevorzugte Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche.
Vorzugsweise umfaßt eine erfindungsgemäßer virtueller Roboter zum Steuern einer realen Maschine einen Software-IC "Controller" zum Steuern der abstrakten Maschine, einen IC "Model", zum Beschreiben der abstrakten Welt der real zu steuernden Maschine, einen IC "Translator" zum Erzeugen und Benutzen der Sprache der abstrakten Maschine, einen IC "Ro¬ bot" zum Implementieren von Aktionen eines abstrakten Robo¬ ters, die von Ereignissen des Controllers abhängen, einen IC "Robotdevice" zum Implementieren von Aktionen eines realen Roboters, die von Ereignissen des Controllers abhängen, und einen IC "Swatch" zum Ausgeben des aktuellen inneren Zu- stands der realen Maschine auf eine Anzeigeeinheit oder zur Simulation von realen Aktionen.
Die Software-ICs "Swatch" und "Robotdevice" können aus einer abstrakten Basisklasse "View" abgeleitet werden, in der die Schnittstellen der ICs "Swatch" und "Robotdevice" definiert sind. Ferner können die Software-ICs "View" und "Model" eine gemeinsame Schnittstelle durch Exzorption erhalten, die eine Vereinfachte Kommunikation mit dem "Controller" ermöglicht. Der IC "Translator" bestehe aus der Mi- xin-Klasse "Language", die die zwei Ob ektklassen "Grammar" und "Vocabulary" umfaßt, wobei die Klasse "Grammar" das Regelwerk für Aktionen bzw. Methoden der abstrakten Maschine definiert, während die Klasse "Vocabulary" die dazu notwendigen Begriffe beinhaltet. Die Klasse "Model" ist so beschaffen, daß sie ihre Schnittstelle auf ihre Unterklassen vererbt, die ein abstraktes Model der Welt eines real verwendeten Roboters umfaßt.
Zur Durchführung der Steuerung erhält der "Translator" vom "Controller" eine Datei, die Informationen über den anzusteuernden Prozeß enthalten soll, der "Translator" überprüft die Grammatik und den Wortschatz dieser Zeile und ak¬ zeptiert sie als Kommandozeile, der "Translator" übersetzt den Inhalt der Zeile mit Hilfe der ihm zur Verfügung stehenden ICs "Grammar" und "Vocabulary" in abstrakte Parameter, der "Translator" gibt dann diese Programmparameter an den "Controller" zurück, und der "Controller" startet: die Gerä¬ testeuerung des virtuellen Roboters mit den Proσrammparame- tern .
Ferner beinhaltet die Gerätesteuerung das Anmelden al¬ ler "Views", das Laden der Programmparameter in den IC "Mo¬ del", und das Aufbauen der Prozeßwelt im IC "Model". Zur Durchführung der Steuerung des realen Roboters wird nach er¬ folgreichem Aufbau der Prozeßwelt ein Taktgeber "Timer" oder ein anderer Beobachter, beispielsweise ein Sensor, gestar¬ tet. Die Grenzen der Prozeßwelt werden geprüft, wobei im Falle des Nichterreichens der Weltgrenzen der anstehende Prozeßschritt ausgeführt wird, während mit dem Erreichen der Weltgrenzen der virtuelle Roboter beendet wird und damit die Steuerung des realen Roboters beendet ist.
Vorteilhafterweise besteht die Software zur Ansteuerung der unterschiedlichen realen Roboter aus leicht modifizier¬ baren Bausteinen, nämlich den genannten Software-ICs . Dieses objektorientierte Design der Software wird in vier Schritten vollzogen :
1. Relevante Objekte erkennen,
2. Abstraktion zu Klassen passender Granularität ,
3. Schnittstellen und Vererbungshierarchie festlegen, sowie
4. Zentrale Beziehungen zwischen den Objekten festlegen.
Ein besonderer Effekt bei der Verwendung derartiger Software-ICs ist, daß bei der Verbesserung eines Software ICs sämtliche Software, die diesen Software-IC enthält, ebenfalls verbessert wird. Die einfache Austauschbarkeit der Software-ICs wird dadurch erreicht, daß abgegrenzte Softwareeinheiten vorliegen, die ausschließlich über genau defi¬ nierte Schnittstellen miteinander kommunizieren. Der Code innerhalb eines ICs ist völlig gekapselt, d.h. alle internen Elemente der stattfindenden Datenverarbeitung sind von au¬ ßen, d.h. von anderen ICs, nicht zugänglich.
Eine bevorzugte Ausführungsform der Erfindung ist nachfolgend anhand der Zeichnungen erläutert.
Fig. 1 zeigt den Aufbau der Klasse "Language",
Fig. 2 zeigt den Zusammenhang zwischen "Translator" und "Language",
Fig. 3 zeigt den Aufbau der Klasse "View", Fig. 4 zeigt die Festlegung des abstrakten "Robot",
Fig. 5 zeigt das "Observer"-Muster für den abstrakten "Controller" ,
Fig. 6 zeigt die Definition der Klasse "Controllerinterface",
Fig. 7 zeigt die Vererbungshierarchie der Klasse "Model",
Fig. 8 zeigt ein Diagramm des gesamten virtuellen Roboters,
Fig. 9 zeigt ein Flußdiagramm der den IC "Translator" betreffenden Ereignisse,
Fig. 10 zeigt ein Ereignisflußdiagramm des ICs "Translator", und
Fig. 11 zeigt ein ausführliches Ereignisflußdiagramm des virtuellen Roboters, wobei der Detailschwerpunkt auf dem IC "Translator" liegt.
In der objektorientierten Programmierung erfolgt als erster Schritt eine Problembeschreibung für die Ansteue- rungssoftware . Hier stößt ein externer Prozeß die Ansteue- rungssoftware an und übergibt ihr die zur Laufzeit des Pro¬ gramms benötigten Parameter, wie beispielsweise Informationen über die auszuführenden Aktionen, also Im Falle einer Software zur Steuerung einer Vakuumkammer die Einschaltzeiten der Vakuumpumpe, die Nummern der Ventile, Zeitangaben zu deren Öffnung etc. Diese Angaben müssen in Programmparameter übersetzt werden. Dies wird von einem Parser übernommen,^ der über eine entsprechende Grammatik und einen Wortschatz ver¬ fügt. Dabei kann unter der Grammatik die benötigten Funktionen und unter dem Wortschatz die notwendigen Daten verstan- den werden. Die Kontrolle über den anzusteuernden Roboter wird durch aufeinanderfolgende Befehle ausgeführt, die zu bestimmten Zeiten an ihn abgegeben werden müssen. Es ist daher in Taktgeber notwendig, mit dem die notwendigen Synchronisationen erfolgen können. Ferner werden Statusreports über den aktuellen Ausführungszustand benötigt, d.h. es ist eine Ausgabeeinheit für einen Bildschirm notwendig. Außerdem wird eine Kommunikationsschnittstelle benötigt, um aktuelle Befehle aus der Steuerungssoftware heraus an den Roboter weiterzuleiten .
Im zweiten Analyseschritt der objektorientierten Programmierung werden die relevanten Objekte zu Klassen passender Granularität abstrahiert. Die einzelnen anzusteuernden Maschinen oder Roboter sind ungeeignete Objekte für das allgemeine Design, da sie ein direktes Symbol für die Abhängigkeit sind. An deren Stelle soll ein abstrakter Roboter, oder allgemeiner eine abstrakte "Maschine" stehen, die in Beziehung zu einer Timer-gesteuerten Ein- und Ausgabefunktion steht. Aus der Sicht der Ansteuerungssoftware ist diese "Maschine" ein Objekt, das über die vorgegebenen Parameter kontrolliert werden muß. Daher wird als das erste Objekt ein Software-IC mit dem Namen "Controller" geschaffen. Der IC "Controller" enthält eine Schnittstelle zu dem Zeitgeber des Betriebsystems. Die Daten, die Aktionen für den IC "Controller" definieren, betreffen direkt dessen abstrakte Welt. Soll nun ein Greifroboter, der Gegenstände von A nach B bewegt, angesteuert werden, so beziehen sich alle Koordinatenangaben auf seinen erfaßbaren Bereich. Seine Welt besteht daher aus Koordinaten und dem Anfahren der entsprechenden Koordinaten. Bei anderen Robotern, wie beispielsweise einem Pipetier-Roboter , sind nur Temperatur und Zeitangaben für dessen Steuerung wichtig. D.h. dessen Welt wird durch Temperatur und Zeitparameter aufgebaut. Folglich muß die abstrakte Maschine "Controller" muß über eine abstrakte Beschrei- bung ihrer Welt verfügen. Entsprechend wird eine Klasse "Model" benötigt.
Der Anwender muß zu Kontrollzwecken über den internen Zustand der abstrakten Maschine "Controller" informiert werden. Dies soll über eine Ausgabe des aktuellen Zustandes auf den Bildschirm erfolgen. Man könnte das Objekt nun einfach "Bildschirm" nennen, wodurch das Design jedoch unnötig festgelegt würde und erhebliches Potential verlöre. Ergeben sich Veränderungen im Modell-Datensatz, so muß sofort die Ausgabe auf dem Bildschirm an die neue Situation angepaßt werden. Dies ist jedoch nicht nur für den Bildschirm so, sondern auch für die eigentliche, anzusteuernde Maschine. Ändert sich das Modell, so sollte sich die Sicht für die Applikation ebenfalls ändern. Die allgemeine Ausdrucksform der dritten Klasse kann daher mit "View" bezeichnet werden. Sie beinhaltet sowohl die Bildschirmausgabe als auch die direkte Kommunikation mit der Maschine, ist also jeweils eine Variante der selben Form:
Verändert der "Controller" das Modell, so werden die abhängigen ICs "View" darüber informiert.
Die abstrakte Maschine "Controller" muß über die neuen Anforderungen informiert werden, die von einer fremden Soft¬ ware beim Aufruf übergeben wurden. Diese Informationen liegen in Form einer Zeile mit Schlüsselworten vor. Diese Schlüsselworte identifizieren die unmittelbar auf sie folgende Information. Diese Information ist ebenso maschinenab¬ hängig, wie das die Klasse "Model". In der Regel sind hier alle Informationen gegeben die den IC "Model" unmittelbar betreffen. Daher wird ein Übersetzer für die jeweilige ab¬ strakte Maschine benötigt, der sowohl über die Grammatik (die Funktionen) , als auch den Wortschatz (die Daten) der jeweiligen Anforderung verfügt. Die vierte Klasse wird daher als "Translator" festgelegt. Grammatik und Wortschatz sind die beiden Elemente, welche in diesem Zusammenhang die breiteste Variation in das Design bringen. Man kann diesen Sachverhalt über ein fünftes Objekt mit dem Namen "Language" widerspiegeln .
Als nächstes müssen die Schnittstellen und Vererbungshierarchien zwischen den Klassen festgelegt werden. Die Objekte "Controller", "Model" und "View" sind entkoppelt, müssen aber synchronisiert werden. Änderungen eines Objektes können sich auf andere Objekte auswirken, ohne daß das geän¬ derte Objekt die anderen genau kennen muß. Dies ist die De¬ finition eines "Observer-Musters" . Daher wird das Design dieser drei Objekte an das "Observer-Muster" angelehnt.
Das "Translator"-Objekt wird nur während des Programm¬ startes gebraucht. Es ist nicht notwendig, daß dieses Objekt genauso lange existiert, wie der "Controller". Somit bietet sich eine einfache Assoziation an, um eine Verbindung für die Auswertung der übergebenen Information herzustellen.
Das in der Fig. 1 dargestellte "Language"-Obj ekt faßt die Elemente "Grammar" und "Vocabulary" zusammen. Prinzipi¬ ell könnte man die Grammatik einer Sprache in Form von Methoden formulieren, die Vokabeln hingegen als deren Daten auffassen. Dies wäre die klassische Definition einer Klasse: Zusammenfassen von Daten mit den auf sie gerichteten Operationen. Allerdings würde man sich bei diesem Design die Ein¬ schränkung auferlegen, beide Elemente nicht unabhängig vari¬ ieren zu können. So wäre es umständlicher, unterschiedliche Grammatiken auf den gleichen Wortschatz anzuwenden, wenn beide Elemente in ein und der selben Klasse vereint wären. Es gibt eine Reihe von Möglichkeiten diese beiden Elemente als eigene Klassen aufzufassen und durch Vererbung in eine "Language"-Klasse zu vereinen. So könnte das "Language"- Objekt wie hier in der Fig. 1 dargestellt als Exemplar einer Mix-In Klasse verstanden werden. Somit ist es möglich das "Grammar" Objekt in künftigen Entwicklungen auszutauschen, ohne daß das "Vocabulary" -Obj ekt betroffen ist.
Fig. 2 zeigt die Verbindung zwischen dem "Translator"- Objekt und seinem "Language"-Obj ekt . Aus der Problemstellung ergibt sich, daß solange das "Translator "-Obj ekt existiert, es sein "Language"-Objekt benötigt. Daher scheiden Assoziationen somit als Verbindung aus. Prinzipiell verbleiben noch die Möglichkeiten der Vererbung oder der Aggregation. Vererbungen sind Elemente des objektorientierten Designs (=00D) um verwandte Objekte, quasi "phylogenetisch" auseinander hervorgehen zu lassen. Aggregationen werden im 00D als Elemente der Synthese angesehen: "Das Objekt besteht aus...", oder "Das Objekt A verwendet während seiner gesamten Existenz Objekt B für Aufgabe X...". Somit wird die "Transla- tor"-Klasse in einer singulären Aggregation mit der "Langua- ge"-Klasse verbunden, wie dies in der Fig. 2 dargestellt ist .
Fig. 3 zeigt die Schachtelung der "View" Objekte. Es leiten sich gemäß eines einfachen "Composite- Musters" zwei Views ab: "Screen" und "Robotdevice". Der "Controller" verwirklicht die Algorithmen zur Ansteuerung der verschiedenen Maschinen (z.B. bei einer Vakuumkammer eine zyklische Entlüftung) und ist somit Beispiel eines "Strategy- Musters". Die Klasse ,,View" ist eine abstrakte Basisklasse' in der die Schnittstelle der von ihr abgeleiteten konkreten Klassen definiert ist. Dieses Design sichert die Konsistenz der Schnittstelle für alle Views. "Swatch" ist die Klasse, deren Exemplar für die graphische Ausgabe des aktuellen inneren Zustandes auf dem Schirm verantwortlich ist. Die Klasse "Robotdevice" kapselt die jeweilige Schnittstelle zur betref¬ fenden Hardware des anzusteuernden Roboters. Diese Klasse ist eine Adapterklasse, welche die Hardwareabhängigkeit über eine adaptierte Klasse auflöst. Die adaptierten Klassen erhalten die Namen der anzusteuernden Geräte.
Um eine maximale Flexibilität zu realisieren wird kein Klassenadapter sondern ein in der Fig. 4 dargestellter Objektadapter verwendet. Somit ist es möglich, während der Laufzeit des Programms durch einfaches Auswechseln der Objekte verschiedene Zielgeräte anzusteuern. Der Objektadapter für die beschriebenen "View"-Obj ekte verwendet die in der Fig. 4 dargestellten Obj ekt komposition . Dabei Steht das Ob¬ jekt "VC-Device" stellvertretend für alle übrigen anzu¬ steuernden Roboter.
Das in der Fig. 5 dargestellte "Controller"-Obj ekt ist im vorliegenden Softwareentwurf das Zentrum der Applikation. Es meldet von ihr abhängige Objekte an, um sie künftig bei auftretenden Veränderungen zu informieren. Dabei wird ledig¬ lich das Signal, daß sich etwas verändert hat, abgesendet. Die zugehörige Klasse verfügt über eine Schnittstelle, mit der sich die abhängigen Objekte über Anfragen mit dem neuen Zustand synchronisieren können. Im vorliegenden Fall handelt es sich um die abhängigen Objekte "CSR", "PCR" und Vacuum- Chamber", die in der zugrundeliegenden Applikation für drei verschiedenen Robotertypen stehen.
Die abhängigen Objekte sind für die Beschaffung der für sie relevanten Informationen selbst verantwortlich. Das "Controller"-Objekt verwertet die Daten, welche über das Ob¬ jekt "Translator" verfügbar wurden, und arbeitet ein gegebe¬ nes Protokoll ab. Der "Controller" hat Zugriff auf die Sy¬ stemuhr des Rechners und erhält von dieser über eine Schnittstelle ein Zeitmaß. Die "Controller"-Klasse ist abstrakt und definiert eine Schnittstelle, die von allen abgeleiteten Klassen geerbt wird. Durch die gemeinsame Schnittstelle können die von ihr abgeleiteten Klassen auf einfache Weise ausgetauscht werden. Die für jeden Roboter unterschiedlichen Methoden sind somit durch diesen Entwurf gelöst, dem ein "Observer-Huster" zugrunde liegt, wie dies in der Fig. 5 dargestellt ist.
Das in der Fig. 6 dargestellte "Model" -Objekt reprä¬ sentiert die Welt der jeweiligen Maschine. Die aus dem "Translator" gewonnenen Daten werden in einem frühen Schritt der Programmlaufzeit über den "Controller" in das "Model" transferiert. Somit ist ", Model" ebenfalls ein Beobachter und wird im "Observer" Muster als solcher angemeldet. Die "Model"-Klasse ist abstrakt und wird durch Vererbung in ihre speziellen, maschinenabhängigen Aufgaben aufgelöst, die hier im Beispiel als "PCR-Model", CSR-Model" und "Vac-Model" ent¬ sprechend dreier verschiedener Roboter bezeichnet sind.
Das "Model" hat für diese Zwecke die gleiche Schnittstelle wie ein "View". Man könnte nun das "Model" von der abstrakten Basisklasse "View" ableiten, um diese Schnittstelle zu vererben, allerdings wäre dies keine saubere Darstellung der Realität.
Würde man diesem Gedanken folgen, so würde das Design auf längere Sicht eine Fehlerquelle beinhalten. So könnte eine Weiterentwicklung der Basisklasse "View", ohne Berücksichtigung der von ihr abhängenden "Model"-Klasse zu ungewollten Effekten führen. Daher wird, wie in der Fig. 7 dargestellt, die reine Schnittstelle aus der "View"-Klasse abstrahiert und eine eigene Klasse "Controllerinterface" definiert, von der dann Ergebnisse sowohl für die Klasse "Model" als auch "View" abgeleitet werden. Das " , Controllerinterface" Objekt garantiert die Konsistenz dieser Schnittstelle für alle Ob¬ jekte, die mit dem "Controller" -Obj ekt interagieren müssen. Eine Weiterentwicklung des Interfaces ist durch diese Abstraktion unproblematisch geworden, weil alle von den Veränderungen betroffenen Klassen diese sogleich erben.
Zusammenfassend ergibt sich daher das in der Fig. 8 dargestellte Objektmodell des virtuellen Roboters. Im vorliegenden Beispiel ist PCR ein Pipettierroboter , CRS ein Greifroboter und Vac beziehungsweise VacuumChamber eine automatischen Vakuumkammer.
In den Figuren 9 - 11 werden die dynamischen, nach außen hin sichtbaren Verhaltensweisen des Systems und seiner Objekte graphisch dokumentiert. Innere Aktionen, die durch Algorithmen festgelegt sind, werden nicht berücksichtigt, sofern sie sich nicht nach außen hin manifestieren. Alle Ereignisse werden zunächst identifiziert und dann erst den Objekten zugewiesen. Auf diese Weise erhält man durch das dynamische Modell eine zusätzliche Kontrolle, ob das im Objektmodell vorgestellte Design tragfähig ist. So v;erden Zu- standsdiagramme für jedes Objekt erstellt, wie dies in den Fig. 9 - 11 beispielhaft mit Schwerpunkt auf den "Translator" durchgeführt ist.
Szenario für den "Translator":
Normalfall
Der "Translator" erhält vom "Controller" eine Zeile, die Informationen für den anzusteuernden Prozeß enthalten soll.
Der "Translator" überprüft die Grammatik und den Wortschatz dieser Zeile und akzeptiert diese als Kommandozeile.
Der "Translator" übersetzt den Inhalt der Zeile mit Hilfe der ihm zur Verfügung stehenden Grammatik und Wortschatz in programmrelevante Parameter. Der Translator gibt diese Programmparameter an den "Controller" zurück.
Extremfälle :
Der "Translator" erhält vom "Controller" eine Zeile, die Informationen für den anzusteuernden Prozeß enthalten soll.
Der "Translator" überprüft die Grammatik und den Wortschatz dieser Zeile und akzeptiert diese nicht als Kommandozeile, weil die Grammatik fehlerhaft ist.
Der "Translator" informiert den "Controller" über eine fehlerhafte Kommandozeile und bricht ab.
Fehleingaben :
Der "Translator" erhält vom "Controller" eine Zeile, die Informationen für den anzusteuernden Prozeß enthalten soll.
Der "Translator" stellt fest, daß die übergebene Zeile ungültig ist.
Der "Translator" informiert den Controller, eine fehlerhafte Informationszeile erhalten zu haben und bricht ab.
Fig. 11 schließlich ist ein selbsterklärender Ereignisflußplan mit Detailschwerpunkt "Translator", das die in den Fig. 9 und 10 dargestellten Zusammenhänge in das Gesamtpro¬ gramm einbettet.
Die in den Figuren verwendete Notation wird üblicherweise bei einem objektorientierten Design verwendet und ist beispielsweise in Arnold Hickersberger : Der Weg zur objektorientierten Software, Hüthig Verlag, Heidelberg 1993, beschrieben .

Claims

Patentansprüche
1. Virtueller Roboter zum Steuern einer automatischen Maschine, dadurch gekennzeichnet, daß der virtuelle Roboter durch die folgenden Software-ICs gebildet wird: einen IC "Controller" zum Steuern der abstrakten Maschine, einen IC "Model", zum Beschreiben der abstrakten Welt der real zu steuernden Maschine, einen IC "Translator" zum Erzeugen und Benutzen der Sprache der abstrakten Maschine, einen IC "Robot" zum Implementieren von Aktionen eines abstrakten Roboters, die von Ereignissen des IC "Controller" abhängen, einen IC "Robotdevice" zum Implementieren von Aktionen eines realen Roboters, die von Ereignissen des IC "Controller" abhängen, und einen IC "Swatch" zum Ausgeben des aktuellen inneren Zustands der realen Maschine auf eine Anzeigeeinheit oder Simulation von realen Aktionen.
2. Virtueller Roboter nach Anspruch 1, dadurch gekennzeichnet, daß die Software-ICs "Swatch" und "Robotdevice" aus einer abstrakten Basisklasse "View" abgeleitet werden, in der die Schnittstellen der ICs "Swatch" und "Robotdevice" definiert sind.
3. Virtueller Roboter nach Anspruch 2, dadurch gekennzeichnet, daß die Software-ICs "View" und "Model" eine gemeinsame Schnittstelle durch Exzerption erhalten, die eine vereinfachte Kommunikation mit dem "Controller" ermöglicht.
4. Virtueller Roboter nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, daß der IC "Translator" aus der Mixin-Klasse "Language" besteht, die die zwei Objektklassen "Grammar" und "Vocabulary" umfaßt, wobei die Klasse "Grammar" das Regelwerk für Aktionen bzw. Methoden der abstrakten Maschine definiert, während die Klasse "Vocabulary" die dazu notwendigen Begriffe beinhaltet.
5. Virtueller Roboter nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, daß die Klasse "Model" ihre Schnittstelle auf ihre Unterklassen vererbt, die ein abstraktes Model der Welt eines real verwendeten Roboters umfaßt.
6. Virtueller Roboter nach einem der vorangegangenen Ansprüche dadurch gekennzeichnet, daß der "Translator" vom "Controller" eine Datei erhält, die Informationen über den anzusteuernden Prozeß enthalten soll, der "Translator" die Grammatik und den Wortschatz dieser Zeile überprüft und sie als Kommandozeile akzeptiert, der "Translator" den Inhalt der Zeile mit Hilfe der ihm zur Verfügung stehenden ICs "Grammar" und "Vocabulary" in abstrakte Parameter übersetzt, der "Translator" dann diese Programmparameter an den "Controller" zurückgibt, und der "Controller" die Gerätesteuerung des virtuellen Ro¬ boters mit den Programmparametern startet.
7. Virtueller Roboter nach Anspruch β, dadurch gekenn¬ zeichnet, daß die Gerätesteuerung das Anmelden aller "Views", das Laden der Programmparameter in das "Model", und das Aufbauen der Prozeßwelt im IC "Model" beinhaltet.
8. Virtueller Roboter nach Anspruch 7, dadurch gekennzeichnet, daß nach erfolgreichem Aufbau der Prozeßwelt ein Taktgeber "Timer" oder ein anderer Beobachter, beispielsweise ein Sensor, gestartet wird.
9. Virtueller Roboter nach Anspruch 8, dadurch gekennzeichnet, daß die Grenzen der Prozeßwelt geprüft werden, wobei im Falle des Nichterreichens der Weltgrenzen der anstehende Prozeßschritt ausgeführt wird, während mit dem Errei¬ chen der Weltgrenzen der virtuelle Roboter beendet wird.
EP98962389A 1997-11-24 1998-11-24 Virtueller roboter Withdrawn EP0954772A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE19751955 1997-11-24
DE1997151955 DE19751955A1 (de) 1997-11-24 1997-11-24 Virtueller Roboter
PCT/EP1998/007567 WO1999027427A1 (de) 1997-11-24 1998-11-24 Virtueller roboter

Publications (1)

Publication Number Publication Date
EP0954772A1 true EP0954772A1 (de) 1999-11-10

Family

ID=7849623

Family Applications (1)

Application Number Title Priority Date Filing Date
EP98962389A Withdrawn EP0954772A1 (de) 1997-11-24 1998-11-24 Virtueller roboter

Country Status (5)

Country Link
EP (1) EP0954772A1 (de)
JP (1) JP2002511969A (de)
CA (1) CA2278582A1 (de)
DE (1) DE19751955A1 (de)
WO (1) WO1999027427A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19949558A1 (de) 1999-10-14 2001-04-19 Heidenhain Gmbh Dr Johannes Steuerungsprogramm für eine numerische Werkzeugmaschine mit einer wiederverwendbaren Softwarestruktur
US7491367B2 (en) 2002-06-04 2009-02-17 Applera Corporation System and method for providing a standardized state interface for instrumentation
DE102004031485B4 (de) * 2004-06-30 2015-07-30 Kuka Roboter Gmbh Verfahren und Vorrichtung zum Steuern des Handhabungsgeräts
DE102008018962B4 (de) * 2008-04-16 2015-08-20 Kuka Roboter Gmbh Verfahren zur Steuerung eines Roboters
DE102010012598A1 (de) * 2010-02-26 2011-09-01 Kuka Laboratories Gmbh Prozessmodulbibliothek und Programmierumgebung zur Programmierung eines Manipulatorprozesses

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4914567A (en) * 1987-11-02 1990-04-03 Savoir Design system using visual language
US5247650A (en) * 1989-08-30 1993-09-21 Industrial Technology Institute System for combining originally software incompatible control, kinematic, and discrete event simulation systems into a single integrated simulation system
US5423023A (en) * 1990-06-25 1995-06-06 Prime Computer, Inc. Method and apparatus for providing a user configurable system which integrates and manages a plurality of different task and software tools
JP3602857B2 (ja) * 1991-04-23 2004-12-15 株式会社日立製作所 多機種対応型情報処理システム、および、方法
EP0596205A3 (en) * 1992-11-03 1996-02-21 Hewlett Packard Co Bench supervisor system.
US5528503A (en) * 1993-04-30 1996-06-18 Texas Instruments Incoporated Integrated automation development system and method

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9927427A1 *

Also Published As

Publication number Publication date
CA2278582A1 (en) 1999-06-03
WO1999027427A1 (de) 1999-06-03
JP2002511969A (ja) 2002-04-16
DE19751955A1 (de) 1999-06-02

Similar Documents

Publication Publication Date Title
DE19781804B4 (de) Vorrichtung zur Simulation einer Echtzeit-Prozesssteuerung
EP1385071B1 (de) Verfahren zum Austausch von Daten zwischen Steuerungen von Maschinen, insbesondere von Robotern
EP1131686B1 (de) Verfahren zur steuerung technischer prozesse
EP1330685B1 (de) Prüfverfahren und prüfvorrichtung zur inbetriebnahme von mittels einer programmlogik gesteuerten systemen
DE102005026040A1 (de) Parametrierung eines Simulations-Arbeitsmodells
DE10206902A1 (de) Engineeringverfahren und Engineeringsystem für industrielle Automatisierungssysteme
EP1638028A2 (de) Rechnergestützte Erzeugung und Änderungsmanagement für Bedienoberflächen
EP1522910B1 (de) Verfahren und Einrichtung zur Konfiguration eines Steuerungssystems
EP3273315B1 (de) Plattform zur weiternutzung bestehender software für die ansteuerung industrieller feldgeräte
EP0954772A1 (de) Virtueller roboter
DE10324594A1 (de) Verfahren zum Bereitstellen einer verbesserten Simulationsfähigkeit eines dynamischen Systems außerhalb der ursprünglichen Modellierungsumgebung
DE19615683A1 (de) Verfahren und Steuereinrichtung für eine graphische Steuerung von Abläufen in einem Netzwerkmanagementsystem
EP1944664B1 (de) Verfahren zur Fehlersuche in einem Automatisierungsgerät
EP1862901A1 (de) Eingabe von Programm-Anweisungen bei imperativen Programmiersprachen
EP2299341A1 (de) Editiergerät und Verfahren zur Konfigurierung von Parametern einer industriellen Automatisierungsanordnung
EP1051671B1 (de) Daten- bzw. informationsübertragungssystem
EP1655663A1 (de) Datenflussmodellierung in Engineering-Systemen
EP1502164B1 (de) Verfahren ZUR UNTERSTÜTZUNG EINER PLANUNG UND REALISIERUNG EINES AUTOMATISIERTEN TECHNISCHEN PROZESSES
EP1936452A1 (de) Verfahren und Vorrichtung zur dynamischen Behandlung von Objekten eines Simulationsmodells
DE102005002362A1 (de) Programmsystem sowie Verfahren und Systemanordnung zu seiner Konfiguration
DE102005009529A1 (de) Datenverarbeitungssystem zur Integration zweier Frameworks
DE10233971A1 (de) Verfahren und Vorrichtung zur Erzeugung von Software
EP2093663A1 (de) Engineering-System für die Entwicklung eines Projektes und Verfahren
DE10125384B4 (de) Vorrichtung und Verfahren zur Inbetriebnahme und Diagnose von Steuerungssystemen
DE102004023634B4 (de) Verfahren zur Vollständigkeits- und Konsistenzprüfung einer Informationsbibliothek

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19990726

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20030531