-
Die Erfindung bezieht sich auf ein
Verfahren und ein System zum entfernten Aufruf und zur entfernten Ausführung von
Funktionsbausteinen eines Steuerungssystem in einem verteilten Netzwerk.
-
Ein solches Steuerungssystem mit
seinen speicherprogrammierbaren Steuerungen (SPS) wird insbesondere
in verteilten Automatisierungssystemen eingesetzt.
-
Gegenwärtige Kommunikationsstrukturen
in verteilten Automatisierungssystemen orientieren sich entweder
an von den Herstellern vorgegebenen starren Mustern für die zu
sendenden Telegramme oder die zu sendenden Telegramme setzen sich
aus unstrukturierten Basisdatentypen auf Bit- und Byte- Ebene zusammen,
welche dem Anwender dieser Strukturen wenig Unterstützung bezüglich Typsicherheit
und Datenkonsistenz bieten.
-
Kommunikationsaufgaben zwischen speicherprogrammierbaren
Steuerungen werden so organisiert, dass sich der Ort der Ausführungskontrolle
vom Ort der Speicherung und Ausführung
unterscheidet. Solche Verfahren sind insbesondere in Speicherprogrammierbare
Steuerungen - Teil 5: Kommunikation (IEC 61131-5:2000); EN 61131-5:
Ausgabe 2001 beschrieben.
-
Beispielsweise wird die Kommunikation über Ein/-
Ausgabe- Datenpunkte organisiert. Dabei sind die Daten in den elementaren
Datentypen Wort, Byte bzw. Bit organisiert und werden in dieser
Form übertragen. Ein
Beispiel dafür
ist die Darstellung eines Datums mit einer Anzahl von 8/16/32 Bit-
Daten, die einem Gerät zugeordnet
werden. Wird das Datum beispielsweise im Datenformat „%IX02.03" dargestellt, ist
daraus entnehmbar, dass der Datenpunkt 3 von Gerät 2 adressiert
wird. Diese Adressierungsart existiert in verschiedenen Varianten,
beispielsweise mit und ohne ein Prozessabbild. Das Aktualisieren
der Daten wird automatisch ohne einen Programmierungseingriff durch
den Anwender durchgeführt.
-
Die Nachteile eines solchen Verfahrens
beruhen darin, dass im allgemeinen keine Datenkonsistenz über größere Bereiche
vorhanden ist. Die Daten sind über
die elementaren Datentypen hinaus nicht strukturiert und es wird
ihnen keine Bedeutung zugeordnet, so dass es sich um eine unstrukturierte
Sammlung von Bitmustern handelt.
-
Die Kommunikation in den verteilten
Systemen kann weiterhin über
einzelne Telegramme organisiert werden. Die Bausteine oder Funktionen,
die für
die Projektierung solcher Telegramme zur Verfügung stehen, werden von den
Herstellern der Bussysteme vorgegeben und sind demzufolge für jedes
Bussystem unterschiedlich organisiert. Sie enthalten starke Bezüge auf die
physikalischen Eigenschaften und Protokolle der verwendeten Bussysteme.
Beispielsweise müssen
Baudraten und Timeouts eingestellt werden, unterschiedliche Funktionscodes „gelernt" und oft auch ein
eigenes Netzwerkprotokoll realisiert werden. Die Bits und Bytes der
zu Telegrammen zusammengefassten und gesendeten Nutzdaten müssen auf
der Gegenseite wieder entpackt werden.
-
Bei diesen Verfahren ist für jedes übertragene
Telegramm zwar eine Datenkonsistenz vorhanden und durch die Überlagerung
von normierten Kommunikationsprofilen die Strukturierung und Konsistenz
der Daten im Hinblick auf die Kommunikationsaufgabe gewährleistet,
jedoch ist für
den Anwender die Flexibilität
in Bezug auf die Kommunikationsprofile sehr eingeschränkt und
keine anwendungsorientierte Strukturierung möglich, was beispielsweise aus
den Kommunikationsprofilen für
die Ansteuerung von Antriebsverstärkern zu entnehmen ist.
-
In verteilten Internet- Applikationen
werden zunehmend für
Realisierung einer objektorientierten Kommunikation Standards wie
CORBA (Common Object Request Broker Architecture), MICROSOFT DCOM
(Microsofts Distributed Common Object Model) oder JAVA RMI (Remote
Method Invocation) eingesetzt, mit denen die Objekte, wie Bausteine,
Datentypen, Datenelemente, Visualisierungen und Ressourcen erzeugt
werden, welche unabhängig
von ihrer Implementierungssprache und Plattform miteinander kommunizieren.
Diese Verfahren sind unter anderem in: Horstmann, Core Java 2 -
Band 2 Expertenwissen Professionelle Techniken und Konzepte, Cornell
ISBN: 38272956661 beschrieben.
-
Nachteilig an diesen Konzepten ist,
dass sie nur auf typische PC Betriebssysteme zugeschnitten sind und
zudem nur mit diesen Betriebssystemen zur Anwendung kommen, also
nicht in verteilten Automatisierungssystemen eingesetzt werden.
Auch wird das oft in den Automatisierungssystemen geforderte Echtzeitverhalten
nicht unterstützt.
Ein weiteres Problem ergibt sich im SPS-Umfeld aus dem notwendigen
Schulungsbedarf für
die Anwendung dieser Konzepte.
-
Der Erfindung liegt die Aufgabe zugrunde,
ein Verfahren und ein System zum entfernten Aufruf und zur entfernten
Ausführung
von Funktionsbausteinen eines Steuerungssystems in einem verteilten
Netzwerk, insbesondere zwischen den speicherprogrammierbaren Steuerungen
in einem verteilten Automatisierungssystem anzugeben, mit denen
eine größere Flexibilität, ein geringer
Ressourcenverbrauch und einfache Handhabung der Anwenderprogrammierung
ermöglicht
wird.
-
Diese Aufgabe wird durch ein Verfahren
zum entfernten Aufruf und zur entfernten Ausführung von Funktionsbausteinen
eines Steuerungssystems in einem verteilten Netzwerk mit den im
Anspruch 1 angegebenen Merkmalen gelöst. Vorteilhafte Ausgestaltungen
und ein System zum entfernten Aufruf und zur entfernten Ausführung von
Funktionsbausteinen in einem verteilten Netzwerk sind in weiteren
Ansprüchen
angegeben.
-
Jeder Funktionsbaustein mit seinen
Funktionen, Funktionsblöcken
und Programmen ist dabei vorzugsweise in einer der IEC- Programmiersprachen
geschrieben.
-
Die Funktion als Programm- Organisationseinheit
liefert bei der Ausführung
genau ein Datenelement und wird bei ihrem Aufruf zum Ausführen in
einer Textsprache als ein Operand in einem Ausdruck benutzt.
-
Ein Funktionsblock ist ein Baustein,
der bei der Ausführung
einen oder mehrere Werte liefert. Im Gegensatz zur Funktion liefert
der Funktionsblock keinen Rückgabewert.
-
Die bei der Ausführung der Funktionsbausteine
ausgegebenen Datenelemente und Werte werden im folgenden als Ausgangsdaten
bezeichnet.
-
Von einem Funktionsbaustein können Vervielfältigungen,
sogenannte Instanzen geschaffen werden. Jede Instanz besitzt einen
zugehörigen
Bezeichnen (den Instanznamen), und eine Datenstruktur, die ihre
Eingaben, Ausgaben und internen Variablen beinhaltet. Instanzen
werden wie Variablen lokal oder global deklariert, indem als Typ
eines Bezeichners der Name des Funktionsbausteines angegeben wird.
Die Aufrufe der Funktionsbausteinen werden über die Instanzen realisiert.
-
Die Erfindung geht von einer Programmierungstechnik
der internationalen Norm IEC 1131 aus, bei der dem Anwender
die Funktionalität
einer Funktionsbausteinbibliothek unter der IEC1131 Programmieroberfläche, die
in Speicherprogrammierbare Steuerungen - Teil 3: Programmiersprachen
(IEC 61131-3:1993); Deutsche Fassung EN 61131-3: Ausgabe 1993 beschrieben
ist, zur Verfügung
gestellt wird.
-
Die Modellierung verteilter Automatisierungssysteme über objektorientierte
Kommunikationsprotokolle mittels des entfernten Aufrufes und der
entfernten Ausführung
von Funktionsbausteinen zur Kontrolle einer entfernten Steuerung
ist in Fachkreisen noch unbekannt und zeichnet sich gegenüber den
bisher angewendeten Verfahren zur Realisierung der Kommunikationsaufgaben
in den verteilten Automatisierungssystemen durch einen geringen
Ressourcenverbrauch bezüglich
der Rechenleistung und des Speicherplatzverbrauches, der Echtzeitfähigkeit
sowie durch eine größere Flexibilität und Unterstützung der
Anwenderprogrammierung aus.
-
Zudem ist nicht wie auf der PC- Ebene üblich, die
Unterstützung
durch ein komplexes Betriebssystem und umfangreiche sowie speicherplatzintensive
Bibliotheken nötig.
Die Erfindung trägt
somit auch dem speziellen Einsatzgebiet für kleine verteilte Systeme
Rechnung.
-
Eine weitere Beschreibung der Erfindung
erfolgt nachstehend anhand der folgenden Zeichnungsfiguren.
-
Es zeigen:
-
1 eine
erfindungsgemäße Systemkonfiguration
zum entfernten Aufruf und zur entfernten Ausführung eines Funktionsblockes,
-
2 den
Verfahrensablauf zum entfernten Aufruf und zur entfernten Ausführung eines
Funktionsblockes in der IEC- Programmiersprache AWL entsprechend
dem Stand der Technik, und
-
3 ein
Ausführungsbeispiel
mit dem erfindungsgemäßen Verfahrensablauf
zum Aufruf und zum Ausführen
eines Funktionsblockes mittels des erfindungsgemäßen Systems.
-
1 zeigt
einen möglichen
Aufbau eines Systems zum Aufruf und zur entfernten Ausführung eines Funktionsblockes 3 in
einem verteilten System mittels eines RemoteObjektes 1 unter
Nutzung von verteilten Ressourcen innerhalb einer IEC1131 Programmieroberfläche.
-
Das RemoteObjekt 1 stellt
dazu Methoden bereit, die von den Objekten anderer entfernter Steuerungen
genutzt werden und wird dabei genauso wie ein beliebiger SPS-Baustein verwendet.
-
Gegenüber dem Stand der Technik,
bei dem die zu sendenden Telegramme aus unstrukturierten Basisdatentypen
zusammengestellt sind, werden jetzt Funktionsblöcke 3 definiert.
-
Das RemoteObject 1 überträgt den Ausführungsort
des Funktionsblockes 3 über
ein an eine erste Steuerung angeschlossenes Netzwerk mittels eines
Netzwerkprotokolls N1, beispielsweise über ein ARCNET (Attached Ressource
Computer Network), auf eine zweite entfernte Steuerung, die Remote-
Steuerung 2.
-
Das RemoteObjekt 1 greift
auf eine Instanz des Funktionsblockes 3 zu, welcher die
lokalen Eingangsdaten 4 aus dem SPS- Programm einer ersten
Steuerung aufweist.
-
Die Remote- Steuerung 2 ist
dafür eingerichtet
ist, mit ihrem SPS- Programm das RemoteObjekt 1 mit der
Instanz des Funktionsblockes 3 und einer definierten Remote-Adresse 7 für die Remote-
Steuerung 2 aufzurufen und die Instanz des Funktionsblockes 3 auszuführen bzw.
abzuarbeiten.
-
Die Instanz des Funktionsblockes 3,
welcher in der Remote-Steuerung 2 gespeichert ist und dort
auch abgearbeitet wird, wird dabei in der ersten Steuerung wie ein
lokaler Funktionsblock benutzt. Die Remote- Steuerung 2 wird
so zum integralen Bestandteil des in der ersten Steuerung abgelegten
lokalen Anwenderprogramms.
-
Mittels eines zweiten Netzwerkprotokolls
N2 werden über
das Netzwerk die Ausgangsdaten 5 aus der Instanz des Funktionsbausteines 3 zur
ersten Steuerung zurückgeführt.
-
Das RemoteObjekt 1 basiert
vorzugsweise auf den Funktionsblöcken 3 entsprechend
der IEC1131- Programmieroberfläche.
Es können
jedoch auch beliebige Hersteller- oder
Anwender-Funktionsblöcke
verwendet werden, d.h. es sind keine Bausteine nötig, die speziell für die Kommunikation
entwickelt wurden. Jeder im Rahmen einer Anwendung entwickelte Funktionsblock 3 ist
somit in das RemoteObjekt 1 integrierbar.
-
Während
dem Aufruf und der Ausführung
des Funktionsblockes 3, also wenn der Auftrag einem Laufzeitsystem übergeben
ist, läuft
das SPS- Programm der ersten Steuerung weiter bis der Auftrag vollständig ausgeführt ist.
Ein am RemoteObjekt 1 angeordneter definierter Ausgang
READY 6 wird nach dem Übermitteln der
Ausgangsdaten 5 aus der Instanz des Funktionsblockes 3 zur
ersten Steuerung auf einen definierten Wert OK gesetzt und eine
Meldung zur Remote- Steuerung 2 übermittelt.
-
2 zeigt
den Verfahrensablauf zum Aufruf eines Funktionsblockes 3 in
der IEC-Programmiersprache
AWL (Anweisungsliste) entsprechend dem Stand der Technik anhand
der Verfahrensschritte 20 – 40.
-
In einem ersten Schritt 20 werden
die Eingangsdaten 4 in die Instanz des Funktionsblocks 3 aus
dem SPS- Programm 10 kopiert und der Funktionsblock 3 in
einem zweiten Schritt 30 ausgeführt.
Dabei werden die bei der Ausführung
des Funktionsblockes 3 gelieferten Ausgangsdaten 5 in
einem dritten Schritt 40 aus der Instanz des Funktionsblockes 3 abgeholt
und dem SPS- Programm 10 übergeben.
-
Ein Beispiel für den Aufruf des Funktionsblockes 3 in
der Programmiersprache AWL zeigt der nachfolgende Programmabschnitt,
Als Beispiel für
den Funktionsblock 3 wurde ein Regler gewählt.
-
-
3 zeigt
an einem Ausführungsbeispiel
den erfindungsgemäßen Verfahrensablauf
zum entfernten Aufruf und zur entfernten Ausführung eines Funktionsblockes 3 mittels
des erfindungsgemäßen Systems
anhand der Verfahrensschritte 200 – 410.
-
In einem ersten Schritt 200 wird
vom SPS- Programm 10 der ersten Steuerung eine Instanz
des auszuführenden
Funktionsbausteines 3 gebildet, die Instanz des auszuführenden
Funktionsbausteines 3 wird in das RemoteObjekt 1 übertragen
und die lokalen Eingangsdaten 4 werden in die Instanz des
auszuführenden Funktionsblockes 3 aus
dem aktuellen SPS- Programm 10 kopiert, womit eine Kopie
der Instanz des Funktionsblockes 3 der ersten Steuerung
vorhanden ist. Damit verbraucht der Funktionsblock 3 im
aktuellen SPS- Programm der ersten Steuerung keine Rechenleistung.
Das RemoteObjekt 1 weist nun eine Instanz des Funktionsblockes 3 mit
den lokalen Eingangsdaten 4 aus dem SPS- Programm 10 einer
ersten Steuerung auf.
-
In einem zweiten Schritt 300 wird
das RemoteObjekt 1 mit der Instanz des Funktionsblockes 3 und einer
definierten Remote- Adresse 7 vom SPS- Programm der Remote-
Steuerung 2 aufgerufen und die Daten des RemoteObjektes 1 werden
als Remote- Eingangsdaten über
ein Netzwerkprotokoll N1 zur Remote- Steuerung 2 übertragen.
-
Im Schritt 210 werden die Eingangsdaten 4 des
Funktionsblockes 3 aus dem SPS-Programm 11 der Remote- Steuerung 2 in
die Instanz des auszuführenden
Funktionsblockes 3 kopiert und im Schritt 310 wird die
Instanz des Funktionsblockes 3 ausgeführt.
-
Nachdem im Schritt 410 die Ausgangsdaten 5 aus
der Instanz des Funktionsblockes 3 abgeholt wurden, erfolgt
eine Rückführung der
Instanz des Funktionsbausteines 3 mit seinen Ausgangsdaten 5 über ein zweites
Netzwerkprotokoll N2 zur ersten Steuerung und im Schritt 400 werden
die Ausgangsdaten 5 aus der Instanz des Funktionsblockes 3 in
das SPS- Programm 10 der ersten Steuerung übergeben.
-
In den SPS- Steuerungen ist der Funktionsblock 3 jeweils
in eine Funktionsbausteinbibliothek eingebunden. In der aufrufenden
Steuerung ist es zudem auch ausreichend, wenn der Funktionsbaustein 3 nur
als Schnittstelle, d.h. als Bibliothek ohne Source-Code bekannt
ist.
-
Mittels dem RemoteObjekt 1 werden
nicht nur Daten von der ersten Steuerung auf die Remote- Steuerung 2 übertragen,
sondern es ist auch eine Übertragung
der Funktionalität
eines Funktionsbausteines zwischen den SPS- Steuerungen durchführbar.
-
Ein Beispiel für den Aufruf des Funktionsblockes 3 in
der Programmiersprache AWL mit einem RemoteObjekt 1 zeigt
der nachfolgende Programmabschnitt. Als Beispiel für den Funktionsblock 3 wurde
wiederum ein Regler gewählt.
-
-
Der Regler PIDT1 wird auf der über das
ARCNET angeschlossenen Remote- Steuerung 2 mit der Adresse 2 ausgeführt, und
zwar mit den Eingängen
W:= PIDT_W, X := PIDT X, die ihm im aktuellen SPS- Programm der
ersten Steuerung vorgegeben wurden.
-
Wenn die Remote- Steuerung ARC/2
den Auftrag ausgeführt
hat, schickt sie die ermittelten Ergebnisse zur ersten Steuerung
zurück.
Am RemoteObjekt 1 ist dann der Ausgang „OK" gesetzt und die Ausgänge der
Instanz „myRegler" entsprechen den
Ausgängen
des gerechneten Reglers in der Remote- Steuerung ARC/2.
-
Mit der Ausführung des Auftrages ist gewährleistet,
dass der Aufruf des RemoteObjektes 1 auf eine Anwendung
nicht blockierend wirkt. Ein blockierender Aufruf würde die
für die
Anwendung zur Verfügung
stehende Rechenleistung reduzieren, weil sich beispielsweise zu
den Abarbeitungszeiten die Buslaufzeiten addieren würden. Durch
das erfindungsgemäße System
wird somit die Rechenleistung einer lokalen SPS, welche durch die
ersten Steuerung dargestellt ist, um die entfernte SPS, die der
Remote- Steuerung 2 entspricht, erweitert.
-
Dieses Konzept einer dezentralen
Intelligenz wird so optimal genutzt, weil jede Steuerung in diesem System
sowohl als „remoteSender" als auch „remote
Empfänger" einsetzbar ist.
Jede Steuerung kann über das
RemoteObject 1 Funktionsblöcke 3 einer anderen
Steuerung aufrufen, wenn diese Funktionsblöcke 3 auf der Remote-Steuerung 2 an
dem RemoteObject 1 zum Aufruf bereit gestellt werden. Gleichzeitig
kann die Steuerung selbst Funktionsblöcke 3 für den entfernten
Aufruf zur Verfügung
stellen.
-
Das Verfahren ist nicht nur auf sogenannte „kleine" Funktionsblöcke wie
einen einzelnen Regler beschränkt,
sondern ist zudem für
komplexe Funktionsblöcke
vom Umfang eines kompletten SPS-Programms anwendbar. Dabei ist die
aufrufende SPS in der Lage, die Aufgaben zu delegieren und zu überwachen.
Die entsprechenden Kommunikationsstrukturen ergeben sich aus dem
Ablauf des SPS- Anwenderprogramm und müssen nicht „nachprojektiert" werden.
-
Das Verfahren erlaubt eine typsichere
und konsistente Datenübertragung.
Durch die Übertragung
der Daten in die Remote- Steuerung 2 mittels des Aufrufes
eines Funktionsblocks 3, eröffnet sich dem Anwender die
Möglichkeit,
die Datenübertragung
zu kontrollieren und beispielsweise über Timeouts zudem eine Unterbrechung
der Verbindung zwischen den einzelnen Steuerungen auf einfache Weise
festzustellen.
-
Am Remote-Object 1 wird
zwischen einem blockierenden und einem nichtblockierenden Aufruf
unterschieden. Optional wird auch ein Timeout ausgewertet.
-
Wenn die Ausführungskontrolle über einige
Funktionsblöcke 3 einer
anderen Steuerung übergeben wurde,
kann das SPS-Programm nach dem Timeout wieder selbst die Kontrolle übernehmen.
