WO2010136561A1 - Verfahren zur konfiguration einer virtuelle und/oder reale komponenten umfassenden service-orientierten fertigungslinie sowie service-orientierte fertigungslinie - Google Patents

Abstract

Die Erfindung bezieht sich auf ein Verfahren zur Konfiguration einer Service-orientierten Fertigungslinie sowie auf eine Service-orientierte Fertigungslinie, umfassend eine Engineering-Plattform zur Bereitstellung einer virtuellen Umgebung zur Entwicklung und Darstellung von virtuellen Komponenten der Fertigungslinie, wobei die Entwicklungs-Plattform über ein Netzwerk mit einem Netzwerk-Controller sowie mit zumindest einer realen Komponente verbindbar ist, wobei die realen und/oder virtuellen Komponenten als Service-orientierte Komponenten ausgebildet sind, die ihre Komponentenfunktionalität als Web-Service darstellen und wobei die Komponenten physikalische Eingabe- und/oder Ausgabeanschlüsse zum Transfer von Werkstücken aufweisen. Um die Konfiguration der Service-orientierten Fertigungslinie zu vereinfachen, ist vorgesehen, dass ein Komponenten-Controller eine die interne Komponentenfunktionalität ausführende Steuerungslogik aufweist, dass die interne Komponentenfunktionalität eines Eingabe- und/oder Ausgabeanschlusses durch jeweils einen funktionalen Port abstrahiert ist und dass jeder funktionale Port auf einen Web-Service-Endpunkt abgebildet ist, um die durch die Ports abstrahierte Komponentenfunktionalität als Web-Service für den Netzwerk-Controller anzubieten.

Description

Verfahren zur Konfiguration einer virtuelle und/oder reale Komponenten umfassenden Service-orientierten Fertigungslinie sowie Service-orientierte Fertigungslinie

Die Erfindung bezieht sich auf ein Verfahren zur Konfiguration einer virtuelle und/oder reale Komponenten umfassenden Service-orientierten Fertigungslinie, wobei die virtuellen Komponenten in eine virtuellen Umgebung einer Engineering-Plattform implementiert werden und über ein Netzwerk mit den realen Komponenten sowie einem Netzwerk-Controller kommunizieren sowie auf eine Service-orientierte Fertigungslinie, umfassend eine Engineering-Plattform zur Bereitstellung einer virtuellen Umgebung zur Entwicklung und Darstellung von virtuellen Komponenten der Fertigungslinie, wobei die Entwicklungs-Plattform über ein Netzwerk mit einem Netzwerk-Controller sowie mit zumindest einer realen Komponente verbindbar ist, wobei die realen und/oder virtuellen Komponenten als Service-orientierte Komponenten ausgebildet sind, die ihre Komponentenfunktionalität als Web-Service darstellen und wobei die Komponenten physikalische Eingabe- und/oder Ausgabeanschlüsse zum Transfer von Werkstücken aufweisen,

Ein Verfahren und ein System sowie Entwicklung s Werkzeug zur Konfiguration eines virtuellen Service-orientierten Fertigungssystems umfassend virtuelle und reale intelligente Geräte mit implementierten Web-Services, über die Funktionalitäten der Geräte angeboten werden, ist in der WO 2008/090216 Al beschrieben. Das Fertigungssystem wird von einem einzigen, zentralisierten Web-Service gesteuert, der auf einem einzigen Computer abläuft.

Die WO 2008/068333 Al beschreibt ebenfalls ein Steuerungssystem für Serviceorientierte Geräte, ohne allerdings eine Verknüpfung von intelligenten Geräten untereinander anzusprechen.

Die Integration realer und virtueller intelligenter Geräte unter Berücksichtigung der Service-orientierten Architektur in eine virtuelle Umgebung wie beispielsweise DELMIA- Automation ist in dem Aufsatz D. Cachapa u. a. „An approach for integrating real and Virtual production automation devices applying the service-oriented architecture paradigm", ETFA. IEEE Conference, Issue 25. -28. September 2007, Seiten 309-314 beschrieben. Basierend auf der Integration des Paradigmas der Serviceorientierten Architektur (SoA) und existierenden 2D/3D basierenden Entwicklungssystemen wird ein neuer Ansatz und entsprechende Werkzeuge für den Entwurf, die Entwicklung und Anwendung von modularen, virtuellen Web-basierten Produktions-Automations-Geräten beschrieben. Dabei wird die Entwicklungsplattform „DELMIA-Automation" verwendet, um die SoA-Umgebung zu modellieren.

In dem Aufsatz wird eine Entwicklungsumgebung beschrieben, welche die Darstellung von virtuellen Fertigungslinien erlaubt, die Service- orientiert arbeiten. Dies wird erreicht durch die Erstellung einer Rahmenstruktur bzw. eines Programmiergerüstes (Framework) welches die Addition von mehreren autonomen virtuellen Geräten mit unabhängigen Web-Services in die virtuelle Umgebung erlaubt. Dabei folgen die Geräte einer „Plug-and-Play"-Architektur, die diesen erlaubt, mit minimalem oder keinem Konfigurationsaufwand in die Umgebung integriert zu werden.

Zu diesem Zweck wurden virtuelle Geräte als wiederverwendbare Komponenten entwickelt. Diese können als intelligente Geräte bezeichnet werden, welche die Gerätegeometrie, die Bewegung des Geräts beschreibende Kinematik und das Verhalten, welches das Gerät in Form von Services zeigt, aufweisen. Jedes virtuelle Gerät ist mit einer externen Bibliothek verknüpft, sodass dann, wenn die Simulation läuft, jedes Gerät auf seine eigene Bibliothek zugreift und seinen eigenen Web-Service ablaufen lässt.

Obige Ansätze beziehen sich zwar auf die Erstellung, Implementierung und Verwendung von Service-orientierten intelligenten Geräten, wobei der Ansatz allerdings nicht geeignet ist ein Layout einer komplexen Fertigungslinie zu beschreiben. Beispielsweise erfordert die in WO 2008/090216 Al beschriebene Steuerung Serviceorientierter Geräte, dass der Steuerungs-Controller mit jeder Gerätefunktionalität und deren Einschränkungen sowie der Layouts der Fertigungslinie eng vertraut ist.

Daraus folgt die Einschränkung, dass die gesamte Maschinenlogik zum Betrieb des Gerätes in den Controller implementiert werden muss. Dies führt zu einer Vermischung der Maschinenlogik mit der Produktionslogik, welche konzeptionell auf verschiedenen hierarchischen Levels des Produktionssystems angeordnet sind.

In Fig. Ia ist ein Kommunikationsdiagramm zwischen einem Controller CON und einem Lifter LI nach dem Stand der Technik dargestellt. Fig. Ib zeigt rein schematisch die einzelnen Ablaufschritte. Dem Lifter LI wird über ein Förderband COl ein Werkstück WP zugeführt, welches aus einer oberen Position POSl in eine untere Position P0S2 transportiert und sodann auf einen zweiten Förderer CO2 abgelegt wird.

Eine zugehörige Kommunikation zwischen einem Controller CON und dem Lifter LI ist in Fig. Ia dargestellt. Der Controller gibt zunächst den Befehl „Start conveyer: right" um das Förderband COl in Richtung Rechts zu starten, sodass das Werkstück WP in den Lifter LI transportiert wird. Es erfolgt eine Rückmeldung „transfer completed" des Lifters LI, das die Übergabe des Werkstückes WP erfolgt ist. Schließlich wird der Förderer COl durch den Controller CON gestoppt „stop conveyer". Anschließend erhält der Lifter LI den Befehl „Start lifter: down", wodurch das Werkstück WP aus der Position POS 1 in die Position P0S2 transportiert wird. Der Controller CON erhält die Rückmeldung „lifter is down" von dem Lifter LI. Schließlich erhält der Lifter LI den Befehl „Start conveyer: left", wodurch das Werkstück WP auf den Förderer CO2 übergeben wird. Der Vorgang wird durch den Befehl „stop conveyer" beendet.

Das in Fig. 1 dargestellte Beispiel zeigt, dass bereits einfache Funktionen, wie der Transport eines Werkstückes WP innerhalb eines Lifters LI von einer oberen Position POS 1 in eine untere Position P0S2 bereits einen komplexen Controller benötigt. Zudem ignoriert das Beispiel den zugehörigen Steuerungsdatentransfer, die Fehlererkennung und Fehlerbehebung. Fig. 2 zeigt rein schematisch den Lifter LI mit vier physikalischen Eingabe/ Ausgabe- Anschlüssen, welche insgesamt 4² (=16) Betriebs-Modi erlauben. Alle Modi bzw. eine Vielzahl dieser müssen in den Controller codiert werden. Dies zeigt den Anstieg der Komplexität in der Logik des Controllers für jedes Gerät einer Fertigungslinie.

Die EP-A-I 916 600 beschreibt ein Netzwerk-basiertes Robotersystem sowie ein Kommunikationsverfahren. Das Kommunikationsverfahren umfasst eine Kommunikations-Middleware zur Ausführung einer Kommunikation zwischen einer Vielzahl von Sensoren, einem Server sowie einem Roboter. Das Verfahren umfasst die Aufstellung zunächst eines Kommunikations-Frameworks der Middleware zur verteilten Ausführung der Funktion des Roboters durch Verwendung der Vielzahl von Sensoren und des Servers; Ausführung einer Kommunikation zwischen der Vielzahl der Sensoren, des Servers und des Roboters unter Verwendung des zuvor aufgestellten Kommunikations-Frameworks, wobei eine synchrone und asynchrone Operation ausgeführt wird, gemäß einer Größe von Daten für eine Objekt-Fernanfrage von dem Roboter.

In der US-B-7,151,966 ist ein System und ein Verfahren zur Bereitstellung eines offenen Interfaces und verteilter Verarbeitung in einer industriellen Controller- Umgebung beschrieben. Das System und das Verfahren beschreiben virtuelle und entfernte Komponenten-Interaktionen in einem Netzwerk einer industriellen Steuerungsumgebung. Eine oder mehrere Komponenten eines industriellen Steuerungssystems werden als Web-Service definiert, kooperieren, um verteilte Controller-Funktionalität in dem gesamten oder in Teilen eines virtuellen Ausführungs- Frameworks zu unterstützen. Zum Beispiel können die Komponenten Prozess-, Logik-, I/O- und Statuskomponenten eines industriellen Steuerungssystems umfassen. Standardisierte und üblicherweise erhältliche Interfaces beschreiben die Controller- Funktionalität durch Services, wobei Controller-Anwendungen über die Komponenten und assoziierte Interfaces konstruiert werden. Dies kann die Entdeckung (discovery) von anderen verwandten Services einschließen, die Anwendung von üblichen Web- Protokollen zur Kommunikation zwischen den Services. Die WO-A-2009/053472 bezieht sich auf ein Verfahren zur Orchestrierung von Services eines Service-orientierten Automationssystems sowie auf eine Orchestrierungs-Maschine. Dabei bieten Systemkomponenten ihre Funktionalität durch Services an und Services anderer Systemkomponenten werden abgefragt, wobei das Verhalten des Automations Systems durch Orchestrierung der Services der Systemkomponenten mittels einer Orchestrierungs-Maschine gesteuert wird. Um eine Orchestrierung von Services auf Geräte-Level zu erreichen, ist vorgesehen, dass die Orchestrierungs-Maschine auf Service-orientierte Systeme zugeschnittene High-Level- Petri-Netze verwendet und dass die Orchestrierung der Services auf Geräte-Level durch Interpretation und Ausführung von verschiedenen, das Verhalten des Automations Systems und/oder der Systemkomponenten darstellende HLPN-Modelle erfolgt.

Davon ausgehend liegt der vorliegenden Erfindung das Problem zugrunde, ein Verfahren der eingangs genannten Art derart weiterzubilden, dass die Konfigurierung Service-orientierter Fertigungslinien mit virtuellen und/oder realen Geräten bzw. Komponenten vereinfacht wird.

Ein Verfahren zur Konfiguration einer Service-orientierten Fertigungslinie umfasst die Verfahrensschritte:

Erstellen eines Modells für jede der Komponenten, umfassend ein Mechatronik- Interface (Mechl), welches ein physikalisch tatsächlich vorhandenes Komponentendesign einschließlich Eingabe- und/oder Ausgabeanschlüsse zum Transfer von Werkstücken zu anderen Komponenten repräsentiert,

ein Steuerungs-Interface, welches eine in einem Komponenten-Controller implementierte Steuerungslogik zur Ausführung interner

Komponentenfunktionen repräsentiert und

ein Kommunikations-Interface, welches als Web-Service-Interface ausgebildet ist und die Komponentenfunktionen der Komponente darstellt und Service- orientierte Kommunikation mit anderen Komponenten und dem Netzwerk- Controller ermöglicht,

Zuordnung eines funktionalen Ports zu jedem physikalischen Eingabe- und/oder Ausgabeanschluss, wobei die einem physikalischen Eingabe- und/oder Ausgabeanschluss zugeordneten internen Komponentenfunktionen durch die Ports abstrahiert und auf Web-Service-Endpunkte abgebildet werden, um die durch die Ports abstrahierten Komponentenfunktionen als Web-Service anzubieten,

Verknüpfen der Modelle in der virtuellen Umgebung entsprechend eines realen mechanischen Layouts durch Verbindung ihrer funktionalen Ports, wobei die funktionalen Ports in der virtuellen Umgebung auf die Web-Service-Endpunkte der virtuellen Komponenten abgebildet werden.

Vorzugsweise kann durch Zusammensetzen bzw. Verknüpfen von zwei oder mehr virtuellen Geräten bzw. Komponenten eine Komposition von Web-Services gebildet werden, welche den Layout-Spezifikationen in der realen Fertigungslinie folgen.

Die in der virtuellen Umgebung erzeugten Web-Services können für entsprechende reale Geräte bzw. Komponenten der realen Fertigungslinie verwendet werden.

Es ist vorgesehen, dass die Steuerungslogik der Komponenten-Controller in der virtuellen Umgebung validiert wird.

Vorzugsweise können die Ergebnisse der Validierung aus der virtuellen Umgebung in die reale Welt durch Änderung der Adressierung der Web-Services umgesetzt werden.

Gemäß bevorzugter Ausführungsform können die Web-Service beinhaltenden intelligenten Geräte bzw. Komponenten in einer Bibliothek aufgenommen werden, welche unmittelbar in der Service- orientierten virtuellen Umgebung verwendet wird. Eine weitere bevorzugte Verfahrensweise zeichnet sich dadurch aus, dass die physikalische Zusammensetzung von Geräten bzw. Komponenten auf die Zusammensetzung der zugehörigen Web-Service-Interfaces abgebildet wird.

Eine Netzwerkkommunikation der virtuellen Geräte bzw. Komponente kann vorzugsweise ausschließlich über deren Web-Service-Ports erfolgen.

Obiges Verfahren ermöglicht auch die Validierung der physikalischen und logischen Layout- und Komponenten bzw. Geräteinteraktionen.

Das Problem wird unter anderem auch dadurch gelöst, dass die Maschinenlogik bzw. Steuerungslogik derart gekapselt wird, so dass die Komplexität spezifischer interner Gerätefunktionen in den Komponenten-Controller verschoben wird.

Auf diesem Weg „sieht" der Controller die Geräte als „Blackbox", welche klar definierte funktionale Interfaces aufweisen, welche den Aufbau und die Verwaltung der Produktionslogik sehr vereinfachen ohne deren Funktionalität zu beeinträchtigen.

Da das intelligente Gerät bereits Intelligenz zur Unterstützung des Web-Service- Interface bereitstellt, kann der interne Controller mit Maschinenlogik bereichert werden, welche geeignet ist, die internen Geräte- Operationen zu realisieren. Diese werden durch definierte Services an dem externen Web-Service-Interface des Gerätes bzw. der Komponente dargestellt.

Für ein Gerät, welches Bestandteil beispielsweise eines Materialhandhabungssystems ist, sind dessen externe Interfaces vorzugsweise mechanische Übergabepunkte wie Eingabe- und Ausgabe-Anschlüsse, durch die Systempaletten empfangen oder aufgenommen werden können.

Das Verfahren ermöglicht, dass das Layout einer Fertigungslinie und seine Funktionen „hybrid", das heißt in realen / virtuellen Konfigurationen bearbeitet werden können, um diese stufenweise zu testen, zu entwickeln und zu validieren. Das erfindungsgemäße Verfahren betrifft die vorliegenden Hauptaspekte:

Ein Ansatz zur Entwicklung von Komponenten / Geräten einer Fertigungslinie in einer virtuellen Umgebung, wenn solche Komponenten Service- orientiert sind, zum Beispiel ihre Funktionen als Web-Services WS an externen WS -Interfaces darstellen.

Ein Ansatz, um ein Layout einer Fertigungslinie und Verhaltensspezifikationen zu entwickeln und zu validieren.

Ein Verfahren zur Verbindung von Service- orientierten virtuellen und realen Komponenten bzw. Geräten unter Berücksichtigung von Hardware, Software (Kommunikation) und Software (Funktion).

Das beschriebene Verfahren erlaubt einem Entwicklungsingenieur den Aufbau einer Bibliothek von Web-Service beinhaltenden intelligenten Geräten, welche unmittelbar in einer Service-orientierten virtuellen Fertigungslinie verwendet werden können, um diese zu studieren, Prototyp-Untersuchungen oder Überwachung realer Fertigungs statten durchführen zu können, und zwar ohne die Komplexität, welche üblicherweise mit solchen Aktionen verbunden ist.

Da die Bibliothek Web-Service enthaltender intelligenter Geräte wächst, sinkt die Zeit zur Entwicklung oder Durchführung von Änderungen einer Service-orientierten Fertigungslinie drastisch. Dadurch wird es Systemintegratoren ermöglicht, den gesamten Vorteil der von der virtuellen Fertigungslinie dargebotenen Eigenschaften zu nutzen, bevor solche Änderungen in der realen Welt wirksam werden.

Durch das erfindungsgemäße Verfahren wird der Vorteil erreicht, dass die physikalische Zusammensetzung von Komponenten bzw. Geräten wirklich auf die Zusammensetzung der zugehörigen Web-Service-Interfaces abgebildet wird. Dies wird in einer Serviceorientierten virtuellen Umgebung ausgeführt. Da sich der Fabrikbereich in Richtung Service-orientierte Technologien bewegt, um den Anspruch der individualisierten Massenfertigung und Produktionsflexibilität zu erreichen, sind die Werkzeuge, welche das Design und die Validierungsphase des „Lifecycles" unterstützen, Service-erkennend ausgebildet, um deren Integration in den Produktionsprozessen zu vereinfachen.

Da das die Ports spezifizierende Web-Service-Interface in den virtuellen und realen Komponenten identisch ist, besteht keine Beschränkung, virtuelle und reale Komponenten in einer einzige Service-orientierte Architektur zu integrieren, welche ein Hardware-/ Software-In-Loop-Paradigma realisiert.

Durch Zusammensetzung der verschiedenen intelligenten Geräte in einer virtuellen Umgebung und deren Verbindung untereinander kann eine virtuelle Fertigungslinie erstellt werden. Eine solche Service-orientierte Fertigungslinie umfasst eingebettete Komponenten, wie beispielsweise Förderer, Kreuzverschiebetische, welche zu Maschinen, wie Transporteinheiten oder Lifter zusammengesetzt werden können, die wiederum zu eingebetteten Produktionssystemen arrangiert werden können. Die beiden erstgenannten Geräte sind im Wesentlichen intelligente Geräte wie zuvor beschrieben, während das Produktionssystem durch eine virtuelle Fertigungslinie dargestellt ist.

Die in dem Netzwerk bekannten Geräte können miteinander kommunizieren sowie mit den verschiedenen Teilnehmern im Netzwerk. Dies ergibt eine Fertigung sarchitektur, wobei die virtuelle Fertigungslinie viele verschiedene Bereiche oder Produktionsressourcen umfasst.

Da alle Teilnehmer der Fertigungslinie dasselbe Netzwerk und High-Level- Funktionalität teilen, und die Komponenten in der virtuellen Umgebung erscheinen in dem Netzwerk als autonome Geräte, wobei keine klare Trennung zwischen diesen und den realen Geräten existiert. Dies erlaubt den Austausch von einigen der virtuellen Komponenten gegen reale Komponenten zum Zweck des Testens. Folglich wird eine offene Architektur bereitgestellt, wobei sämtliche Teilnehmer frei gemäß ihrer Funktion partizipieren können. Weitere Einzelheiten, Vorteile und Merkmale der Erfindung ergeben sich nicht nur aus den Ansprüchen, den diesen zu entnehmenden Merkmalen - für sich und/oder in Kombination -, sondern auch aus der nachfolgenden Beschreibung von der Zeichnung zu entnehmenden bevorzugten Ausführungsformen.

Es zeigen:

Fig. 1 a, b Ein Kommunikationsdiagramm zwischen einem Controller und einem Lifter sowie einer schematischen Darstellung eines Lifters mit Förderbändern;

Fig. 2 eine schematische Darstellung eines Lifters mit Eingangs-/ Ausgangs-

Ports sowie Darstellung von Betriebs-Modi;

Fig. 3 eine schematische Darstellung des Lifters mit Eingangs-/ Ausgangs-Ports;

Fig. 4 a, b eine schematische Darstellung des Lifters sowie ein Kommunikationsdiagramm einer Kommunikation zwischen einem Controller und dem Lifter;

Fig. 5 eine schematische Darstellung eines Netzwerkes mit Geräten einer Fertigungslinie sowie einem Controller;

Fig. 6 eine schematische Darstellung der Architektur einer Schleife einer Fertigungslinie bestehend aus zwei Liftern, zwei Förderbändern und einer Rückführungslinie;

Fig. 7 eine funktionale Ansicht der Fertigungslinie gemäß Fig. 6 mit Web-

Service-Interfaces ; Fig. 8 eine schematische Darstellung eines intelligenten Gerätes am Beispiel eines Förderbandes, umfassend Mechatronik-Interface, Kommunikations-Interface sowie Steuerungs-Interface;

Fig. 9 eine physische Sicht sowie eine funktionelle Sicht der Verknüpfung einzelner Service-orientierter Geräte zur Bildung eines neuen Services;

Fig. 10 ein Kommunikationsdiagramm des zusammengesetzten Services gemäß

Fig. 9;

Fig. 11 Zusammenfassung einzelner Web-Services zu einem zusammengesetzten

Web-Service höherer Ordnung;

Fig. 12 Darstellung eines Kommunikationsdiagramms zwischen einem Controller und dem zusammengesetzten Web-Service;

Fig. 13 Darstellung virtueller Geräte in einer Entwicklungsumgebung, welche mit einem Controller über ein Netzwerk verbunden sind, und

Fig. 14 Darstellung virtueller Geräte einer Entwicklungsumgebung, welche über ein Netzwerk mit einem realen Gerät und einem Controller verbunden sind.

Fig. 3 zeigt eine schematische Darstellung des Lifters LI mit vier Eingangs-/ Ausgangs- Ports Porti, Port2, Port3, Port4. Beispielsweise ist der Lifter LI in der Lage, Werkstücke WS von der linken und rechten Seite aufzunehmen oder auszugeben und ebenso von einem oberen Level zu einem unteren Level zu fördern. Diese Funktionalität kann durch die Eingangs-/Ausgangs-Ports Porti, Port2, Port3, Port4 abstrahiert werden, wie dies in Fig. 3 dargestellt ist. Den einzelnen Ports können eindeutige Identifikationswertenummern 1 bis 4 zugeordnet werden. Ein Web-Service WS dieses Gerätes agiert als ein Interface zwischen der Maschinenlogik und der äußeren Welt und verbirgt die Komplexität der Gerätefunktionen und zeigt lediglich die Ports Porti, Port2, Port3, Port4 als Service-Interfaces.

Fig. 4a veranschaulicht das erfindungsgemäße Verfahren am Beispiel des Lifters LI. Der Lifter LI als intelligentes Gerät ist erfindungs gemäß mit der internen Maschinenlogik ausgestattet. Die Ports Porti, Port2 können über das Web-Service- Interface aufgerufen werden.

Auf diese Weise wird das intelligente Gerät eine „Blackbox" mit wohl definierten Web- Service-Interfaces.

Das obige Beispiel zeigt, dass die Wirkungsweise des Gerätes vereinfacht wird während die Funktionalität des Gerätes vollständig erhalten bleibt.

Fig. 4b zeigt rein schematisch ein Kommunikationsdiagramm, welches nur noch drei Befehle umfasst, im Vergleich zu den nach dem Stand der Technik notwendigen sieben Befehlen gemäß Figur Ib). Durch den Befehl „transfer in: Porti" wird das Werkstück WP dem Lifter LI übergeben. Der Befehl „transfer completed" zeigt dem Controller an, dass das Werkstück WP in den Lifter LI übertragen wurde. Lediglich durch den einen Befehl „transfer out: Port4" werden intern die Befehle „stop conveyer", „Start lifter: down", „lifter is down", „Start conveyer: left" sowie „stop conveyer" ausgeführt.

Fig. 5 zeigt rein schematisch eine Service- orientierte Automatisierungs struktur einer Fertigungslinie umfassend intelligente Geräte SDl... SDn mit jeweils integriertem programmierbaren Logik-Controller PLC 1...PLCn sowie Web-Service-Interface WS 1...WSn, die über ein Kommunikationsnetzwerk NW wie Ethernet miteinander sowie mit einem Netzwerk-Controller CON verbunden sind.

Die intelligenten Geräte SDl... SDn sind autonom, eigenständig und unabhängig von externen Geräten, um ihre volle Funktionalität zu erreichen und sind in der Lage, mit anderen Geräten zu kooperieren. Die intelligenten Geräte SD 1...SDn enthalten eigenständige (self-contained) Funktionalitäten, welche über Services WS angeboten werden, die im Stande sind, deren Eigenschaften vollständig auszunutzen. Um die Komplexität zu minimieren sind die Geräte SD 1...SDn ihrerseits so einfach wie möglich aufgebaut, wobei sich die wahre Eigenschaft der Fertigungslinie durch Interaktionen zwischen den Geräten SDl ...SDn, der Fertigungslinie PL ergibt.

Das Konzept des intelligenten Gerätes SD wird verwendet um ein Gerät zu beschreiben, welches von Grund auf autonom und kooperativ ist. In dem Gerät SD ist die Kinematik; das Verhalten, welches nach außen durch mindestens einen Service WS dargestellt wird; und die Geometrie, oder im Fall eines virtuellen Gerätes VD, die physikalische Dimension integriert.

Die intelligenten Geräte SD 1...SDn setzen sich daher aus Informationen über deren Geometrie, deren Kinematik sowie deren Web-Services WS 1...WSn zusammen. Geometrie und Kinematik sind Bestandteil des programmierbaren Logik-Controllers PLCl... PLCn. Einzelne intelligente Geräte SDl ... SDn können in die Fertigungslinie PL eingebracht werden, indem diese mit dem Netzwerk NW verbunden werden, wobei ihre volle Funktionalität für den Controller CON sofort verfügbar ist.

In Fig. 3 ist das Konzept der Einführung von Ports Portl...Port4 erläutert. In der Fertigungslinie PL interagieren die verschiedenen intelligenten Geräte SD 1...SDn untereinander, um beispielsweise die Bewegung oder Bearbeitung eines Werkstückes WP auszuführen. Insbesondere zur Durchführung der Streckenführung (routing) können Transportgeräte wie Lifter LI oder Förderband CO derart beschrieben werden, dass diese feststehende Ports aufweisen, von denen die Werkstücke WP in das Gerät hinein und/oder aus diesem heraus übergeben werden können.

Durch Zuordnung einer lokal eindeutigen Identifikationsnummer zu jedem Port Porti ... Port4 kann das Gerät SD, VD erkennen, von wo ein Werkstück WP kommt und wohin es übergeben werden soll. Gemäß der Erfindung können die Ports Portl...Port4 beispielsweise in eine 3D-Umgebung zu Web-Service-Endpunkten eines zugeordneten virtuellen Gerätes VD abgebildet (gemappt) werden. Somit können virtuelle Geräte VD in der 3D-Umgebung an bzw. mit ihren Ports Porti... Portn verbunden werden, um eine kontinuierliche Sequenz von virtuellen Geräten VD zu bilden, welches beispielsweise Werkstücke im Inneren einer Produktionszelle transportieren kann. Durch Zusammensetzen von zwei virtuellen Komponenten erfolgt somit eine Komposition von Web-Services, welche den Layout-Spezifikationen der Fertigungslinie folgt.

Die Zusammenschaltung vieler individueller Geräte SD 1...SDn in dem Netzwerk NW führt zu einer hohen Anzahl von individuellen Services WS, die ihrerseits wenig Funktionalität bieten, jedoch gemeinsam eine hilfreiche und oft komplexe Aufgabe ausführen können.

Um die Geräte SD, VD zusammenzubringen werden Synchronisationsmuster entwickelt, sodass jedes Gerät SD, VD im Stande ist, mit seinen Nachbarn zu kommunizieren und zu verhandeln, wie diese miteinander interagieren wollen. Soll beispielsweise das Werkstück WP von dem Förderer CO zu dem Lifter LI übertragen werden, dann muss zunächst festgestellt werden, dass der Lifter LI:

a) richtig funktioniert, b) nicht belegt ist oder nicht voll ist, c) sich in der korrekten Höhe befindet, um das Werkstück aufzunehmen.

Nachdem die Vorbedingungen erfüllt sind, kann die Übergabe beginnen:

a) Start des Förderers an dem Lifter, b) Start des das Werkstück haltenden Förderers, c) warten auf das Signal des Lifters, dass dieser das Werkstück erhalten hat, d) Stopp des Förderers und des Förderbandes des Lifters.

Sobald die Interaktionsmuster wie oben beschrieben erstellt sind, können diese in einen neuen Service WS auf höherem Level implementiert werden. Diese zusammengesetzten Services WS abstrahieren vier der Interaktionen um die aus dem Pool der existierenden Geräte zugängliche Funktionalität hervorzubringen, während die Komplexität ihrer Nutzung vereinfacht oder reduziert wird.

Da ein zusammengesetztes Gerät zwei oder mehr Geräte verbindet, können seine resultierenden Eigenschaften von der einfachen Summe der Eigenschaften und Begrenzungen jeder Komponente unterschiedlich sein, zum Beispiel wirken zusammengesetzte Geräte so wie ihre Ports diese beschreiben, während die neue Zusammensetzung eine unterschiedliche Anzahl von Ports offerieren kann, welche ihrerseits einzigartig für dieses einzelne Gerät sind. Die Zusammensetzung eines Förderbandes und eines Verschiebetisches resultiert in neuer Funktionalität und Eigenschaften, beispielsweise eines Kreuzverschiebetisches (cross table).

Die zusammengesetzten Geräte können ihrerseits zu anderen zusammengesetzten Geräten höherer Hierarchie hinzugefügt werden, sodass sich schließlich eine Arbeitsstation bzw. Fertigungslinie ergibt.

Dieses „Schicht- Verfahren" entspricht dem Prinzip einer „russischen Puppe", wobei jede obere Schicht die Komplexität der darunter liegenden Schichten verdeckt und deren Interaktionsmuster in Services höherer Level abstrahiert. Diese Services können dann ihrerseits mit anderen Services zusammengesetzt werden, um Services höherer Ordnung zu erreichen. Wenn zwei oder mehrere Komponenten zusammengebracht werden, zeigt die zusammengesetzte Struktur zusammengesetzte Services.

Fig. 6 zeigt schematisch eine physikalische Sicht einer Architektur einer Schleife mit zwei Förderbändern COl, CO2, zwei Liftern LIl, LI2 und einer Rückführlinie RLl. Eine funktionelle Darstellung des Systems aus Sicht des Controllers CON unter Verwendung von Web-Service-Interfaces ist in Fig. 7 dargestellt. Dabei sind Eingangs- /Ausgangs-Anschlüsse bzw. -Ports als Rauten dargestellt. Unter Verwendung dieses Verfahrens werden die physikalische und funktionelle Ansicht analog zueinander, da das Layout und die Verbindungen zwischen den Geräten exakt gleich aussehen. Der physikalische Eingabe/Ausgabe-Anschluss zur Übergabe der physikalischen Palette bzw. des physikalischen Werkstückes und das funktionelle Interface zur Verbindung eines Gerätes mit einem anderen werden durch einen einzigen „Port" repräsentiert.

Der Ausdruck „Port" bezeichnet ein Higher-Level-Interface, welches sich aus den folgenden Komponenten zusammensetzt:

Mechatronik-Interface (Mechl), Kommunikations-Interface (Komi), Steuerungs-Interface (ConI).

Beispielsweise umfasst ein einfaches Förderband CO zwei Ports Porti, Port2, die in Fig. 8 dargestellt sind. Diese können in Komponenten zerlegt werden, nämlich in das Mechatronik-Interface Mechl, Kommunikations-Interface Komi sowie Steuerungs- Interface ConI. Das Mechatronik-Interface Mechl wird repräsentiert durch die tatsächlich physikalisch vorhandenen Eingabe/Ausgabe-Anschlüsse. Diese sind definiert durch das physikalische Gerätedesign, an den Stellen, an denen Paletten aufgenommen oder ausgegeben werden. Dies wird durch das Design der tatsächlichen Hardware beschrieben und eine äquivalente geometrische Repräsentation eines virtuellen Gerätemodells.

Das Kommunikations-Interface ComI wird repräsentiert durch den Web-Service WS. Der Web-Service WS bietet oder stellt ein Interface zu der Außen- Welt bereit, welches das Vorhandensein der physikalischen Eingangs/Ausgangs-Anschlüsse des Gerätes erkennt und im Stande ist, Services für jeden individuellen Eingangs-/ Ausgangs- Anschluss anzubieten, beispielsweise „transfer in from port x and transfer out to port y".

Der Web-Service WS ist zwischen der realen und virtuellen Welt portable, so dass das Port-Kommunikations-Interface sowohl in der virtuellen als auch in der realen Welt gleich funktioniert.

Das Steuerungs-Interface ConI wird repräsentiert durch die funktionale Darstellung des Gerätes SD aus Sicht des Controllers CON. Dieses repräsentiert die Eigenschaften des Gerätes SD gesehen aus der Sicht des Controllers, zum Beispiel die Anschlüsse, an welchen das Gerät seine Funktionalitäten mit der Außenwelt austauscht.

Das Verfahren kann erweitert werden, um die Orchestration von verschiedenen Services WSl, WS2, WS3 zu unterstützen, resultierend in einem neuen Service WS-NEU, welcher mehrere Geräte SD 1...SDn miteinander verbindet, mit neuen Ports PORTl- NEU, PORT2-NEU an den externen Interfaces des neuen zusammengesetzten Gerätes. Ein Beispiel ist in Fig. 9 dargestellt, umfassend die Reihenschaltung von drei Förderbändern COl, CO2 und CO3 einerseits in physikalischer Sicht und andererseits in funktioneller Sicht.

Die Förderbänder COl, CO2, CO3 dienen lediglich als Transportmechanismen, sodass eine Steuerungslogik zur Bewegung einer Palette/ eines Werkstückes von dem Gerät vor dem Förderband COl zu einem Gerät nach dem Förderband C03 das in Fig. 9 dargestellte Kommunikations Schema sehen würde.

Da keine weiteren Funktionalitäten zwischen beiden Schritten notwendig sind, können die in Fig. 9 dargestellten Interaktionen in einen zusammengesetzten Service WS-NEU mit höherem Level abstrahiert werden. Der zusammengesetzte Web-Service eines Lang- Förderbandes LCO ist in Figur 12 dargestellt.

Dies bedeutet, dass das zusammengesetzte Gerät LCO gegenüber dem Controller als ein einziges Gerät erscheint, wie dies in Fig. 12 dargestellt ist. Die entsprechende Kommunikation zwischen dem Controller und dem Lang-Förderband LCO ist ebenfalls in Fig. 12 dargestellt. Das Muster ist gegenüber dem in Fig. 10 dargestellten erheblich vereinfacht, da lediglich drei Befehle auszuführen sind.

Die Steuerungslogik kann durch Abstrahierung der individuellen Gerätefunktionalität und Darstellung dieser an externen Interfaces des zusammengesetzten Gerätes sehr vereinfacht werden. Unter Berücksichtigung der Tatsache, das Web-Service- Technologie zwischen der virtuellen und der realen Welt portable ist, wie dies in der WO 2008/090216 Al beschrieben wurde, kann ein Service-orientiertes Layout einer Fertigungslinie in einer virtuellen Umgebung entwickelt und validiert werden.

Aus funktionaler Sicht besteht kein Unterschied für den Controller zwischen Ports in einem realen Gerät und Ports in einem virtuellen Gerät. Dies bedeutet, dass die Produktionslogik in einer virtuellen Fertigungslinie validiert werden kann. Eine Entwicklungsplattform in einer virtuellen Umgebung ist in Fig. 13a dargestellt. Diese umfasst virtuelle Modelle von intelligenten Geräten VSD1...VSD5, welche über ein Netzwerk NW mit einem realen Controller CON verbunden sind. Eine funktionelle Ansicht ist in Fig. 13b dargestellt. Anschließend kann das Ergebnis stufenweise in die reale Welt umgesetzt werden, durch einfache Änderung der Adressierung der Web- Services WS.

Fig. 14 zeigt ein Beispiel, bei dem der Lifter LI2, der zuvor als virtuelles Gerät VSDS in Fig. 13a dargestellt ist, nunmehr als reales Gerät RSDS mit dem Netzwerk NW verbunden ist.

Claims

PatentansprücheVerfahren zur Konfiguration einer virtuelle und/oder reale Komponenten umfassenden Service-orientierten Fertigungslinie sowie Service-orientierte Fertigungslinie

1. Verfahren zur Konfiguration einer virtuelle und/oder reale Komponenten umfassenden Service-orientierten Fertigungslinie, wobei die virtuellen Komponenten in eine virtuellen Umgebung einer Engineering-Plattform implementiert werden und über ein Netzwerk mit den realen Komponenten sowie einem Netzwerk-Controller kommunizieren, umfassend die Verfahrensschritte:

Erstellen eines Modells für jede der Komponenten, umfassend ein Mechatronik- Interface (Mechl), welches ein physikalisch tatsächlich vorhandenes Komponentendesign einschließlich Eingabe- und/oder Ausgabeanschlüsse zum Transfer von Werkstücken zu anderen Komponenten repräsentiert,

ein Steuerungs-Interface, welches eine in einem Komponenten-Controller implementierte Steuerungslogik zur Ausführung interner

Komponentenfunktionen repräsentiert und

ein Kommunikations-Interface, welches als Web-Service-Interface ausgebildet ist und die Komponentenfunktionen der Komponente darstellt und Sercive- orientierte Kommunikation mit anderen Komponenten und dem Netzwerk- Controller ermöglicht,

Zuordnung eines funktionalen Ports zu jedem physikalischen Eingabe- und/oder Ausgabeanschluss, wobei die einem physikalischen Eingabe- und/oder Ausgabeanschluss zugeordneten internen Komponentenfunktionen durch die Ports abstrahiert und auf Web-Service-Endpunkte abgebildet werden, um die durch die Ports abstrahierten Komponentenfunktionen als Web-Service anzubieten, Verknüpfen der Modelle in der virtuellen Umgebung entsprechend eines realen mechanischen Layouts durch Verbindung ihrer funktionalen Ports, wobei die funktionalen Ports in der virtuellen Umgebung auf die Web-Service-Endpunkte der virtuellen Komponenten abgebildet werden.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass durch Zusammensetzen bzw. Verknüpfen von zwei oder mehr virtuellen Komponenten eine Komposition von Web-Services entsteht, welche den Layout- Spezifikationen in der realen Fertigungslinie folgen.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die in der virtuellen Umgebung erzeugten Web-Services für entsprechende reale Komponenten der realen Fertigungslinie verwendet werden.

4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Steuerungslogik der Komponenten-Controller in der virtuellen Umgebung validiert wird.

5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass Ergebnisse der Validierung aus der virtuellen Umgebung in die reale Welt durch Änderung der Adressierung der Web-Services umgesetzt werden.

6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Web-Services beinhaltendenden intelligenten Komponenten in einer Bibliothek aufgenommen werden, welche unmittelbar in der Service-orientierten virtuellen Umgebung verwendet wird.

7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die physikalische Zusammensetzung von Komponenten auf die Zusammensetzung der zugehörigen Web-Service-Interfaces abgebildet wird.

8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass eine Netzwerkkommunikation der virtuellen Komponente ausschließlich über deren Web-Service-Ports erfolgt.

9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass eine Validierung von physikalischen und logischen Layout- und Komponenteninteraktionen erfolgt.

10. Service- orientierte Fertigungslinie, umfassend eine Engineering-Plattform zur Bereitstellung einer virtuellen Umgebung zur Entwicklung und Darstellung von virtuellen Komponenten der Fertigungslinie, wobei die Entwicklungs-Plattform über ein Netzwerk mit einem Netzwerk-Controller sowie mit zumindest einer realen Komponente verbindbar ist, wobei die realen und/oder virtuellen Komponenten als Service-orientierte Komponenten ausgebildet sind, die ihre Komponentenfunktionalität als Web-Service darstellen und wobei die Komponenten physikalische Eingabe- und/oder Ausgabeanschlüsse zum Transfer von Werkstücken aufweisen, dadurch gekennzeichnet, dass ein Komponenten-Controller eine die interne Komponentenfunktionalität ausführende Steuerungslogik aufweist, dass die interne Komponentenfunktionalität eines Eingabe- und/oder Ausgabeanschlusses durch jeweils einen funktionalen Port abstrahiert ist und dass jeder funktionale Port auf einen Web-Service- Endpunkt abgebildet ist, um die durch die Ports abstrahierte Komponentenfunktionalität als Web-Service für den Netzwerk-Controller anzubieten.

11. Service- Orientierte Fertigungslinie nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass den Ports eindeutige Identifikationswertenummern zugeordnet sind.