DE102021131045A1

DE102021131045A1 - Methodenaufrufe in einer speicherprogrammierbaren Steuerung

Info

Publication number: DE102021131045A1
Application number: DE102021131045.8A
Authority: DE
Inventors: Adrian Scholl
Original assignee: Codesys Holding GmbH
Current assignee: Codesys Holding GmbH
Priority date: 2021-11-26
Filing date: 2021-11-26
Publication date: 2023-06-01

Abstract

Die vorliegende Offenbarung bezieht sich auf ein Verfahren zum Aufrufen einer Methode eines industriellen Steuerungsprogramms einer speicherprogrammierbaren Steuerung, wobei die speicherprogrammierbare Steuerung ein Laufzeitsystem mit einem OPC-UA-Server umfasst, der dazu eingerichtet ist, mit einem OPC-UA-Client über eine Kommunikationsverbindung gekoppelt zu werden, und wobei die speicherprogrammierbare Steuerung ferner das industrielle Steuerungsprogramm umfasst. Das Verfahren umfasst ein Empfangen eines auf die Methode gerichteten Methodenaufrufs von dem OPC-UA-Client an dem OPC-UA-Server und ein Aufrufen der Methode in dem industriellen Steuerungsprogramm aus dem Laufzeitsystem heraus in Reaktion auf den empfangenen Methodenaufruf.

Description

Technisches Gebiet
Die Offenbarung bezieht sich auf speicherprogrammierbare Steuerungen (SPS), wie sie zur Steuerung von Maschinen und Anlagen eingesetzt werden können, insbesondere auf Verfahren und Vorrichtungen zum Aufrufen einer Methode eines industriellen Steuerungsprogramms einer speicherprogrammierbaren Steuerung mittels eines OPC-UA-Clients.
Hintergrund und Grundlagen
Industrielle Steuerungsumgebungen sind in der modernen Fertigung allgegenwärtig und umfassen oft mindestens eine speicherprogrammierbare Steuerungseinheit (SPS), die ein Laufzeitsystem bzw. eine Laufzeitumgebung sowie ein industrielles Steuerungsprogramm aufweist. Das Laufzeitsystem kann dabei eine Plattform für das industrielle Steuerungsprogramm bilden und kann weitere Funktionalitäten, wie beispielsweise Laufzeitbibliotheken, Programmier- und Variablenschnittstellen sowie Laufzeitvariablen, für die speicherprogrammierbare Steuerungseinheit bzw. das industrielle Steuerungsprogramm zur Verfügung stellen. Das industrielle Steuerungsprogramm ist dazu eingerichtet, auf der speicherprogrammierbaren Steuerung abzulaufen und dabei eine zugehörigen Maschine oder Anlage anzusteuern, insbesondere mit der zugehörigen Maschine oder Anlage Anweisungen und/oder Daten auszutauschen. Das industrielle Steuerungsprogramm kann dabei die Form von Kontaktplananweisungen (auch als Leiterlogik bezeichnet) oder eines kompilierten Maschinencodes haben. Es wird häufig aus Quellcode generiert, der in einer höheren Programmiersprache, z. B. einer objektorientierten Programmiersprache, geschrieben wurde. Der Quellcode kann vom Benutzer in einer Programmierumgebung geschrieben werden, die sich räumlich entfernt von der speicherprogrammierbaren Steuerungseinheit befindet und über ein Netzwerk, wie z. B. das Internet oder ein dediziertes industrielles Steuerungsnetzwerk, mit der speicherprogrammierbaren Steuerungseinheit verbunden sein kann.
Für viele Anwendungen kann es vorteilhaft sein, von einem externen Rechner auf die industrielle Steuerungseinheit zugreifen zu können, beispielsweise wiederum über das Internet oder das dedizierte industrielle Steuerungsnetzwerk. Solche Anwendungen umfassen beispielsweise die Visualisierung von Parametern der speicherprogrammierbaren Steuerung bzw. der zugehörigen Maschine oder Anlage an dem entfernten Rechner sowie deren Inbetriebnahme, Wartung oder (Um)Konfigurierung von dem entfernten Rechner. Ein industrielles Standardprotokoll für derartige Anwendungen stellt der von der OPC Foundation entwickelte OPC-UA-Standard („Open Platform Communication - Unified Architecture“) bereit. Dieser Standard sieht unterschiedliche Dienste vor, welche zwischen einem OPC-UA-Client auf dem externen Rechner und einem OPC-UA-Server im Laufzeitsystem der speicherprogrammierbaren Steuerungseinheit ausgetauscht werden. Diese Dienste ermöglichen es einem Nutzer, sich von dem OPC-UA-Client in einem Adressraum ähnlich einem Dateisystem auf der speicherprogrammierbaren Steuerungseinheit zu bewegen und einzelne Werte oder Variablen des industriellen Steuerungsprogramms zu selektieren, abzufragen oder zu schreiben.
Darüber hinaus sieht der OPC-UA-Standard vor, dass der OPC-UA-Server dem OPC-UA-Client Methodenaufrufe anbieten kann. Diese Aufrufe bieten dem OPC-UA-Client die Möglichkeit, auf den Ablauf des OPC-UA-Servers bzw. der speicherprogrammierbaren Steuerungseinheit einzuwirken und dort vorbestimmte Aktionen auszulösen. Eine Methode ist dabei einem Objekttyp zugeordnet und kann, wie in objektorientierten Programmiersprachen üblich, auf einer Instanz eines solchen Objekts ausgeführt werden. Eine Methode kann sowohl Eingabeparameter als auch Ausgabeparameter umfassen. Die Werte für die Eingabeparameter können von dem OPC-UA-Client zusammen mit der aufzurufenden Methode an den OPC-UA-Server und von dort an das industrielle Steuerungsprogramm übermittelt werden. Die Werte der Ausgabeparameter werden dann nach dem Aufruf der Methode über den OPC-UA-Server an den OPC-UA-Client zurückgemeldet.
Weiterhin bietet der OPC-UA-Standard umfangreiche Möglichkeiten, Objekte semantisch zu beschreiben. Dadurch ist es beispielsweise möglich, nicht nur einen variablen Wert zu übertragen, sondern beispielsweise auch noch eine Einheit und ein Wertebereich mit anzugeben. Um diese semantischen Beschreibungen zu abstrahieren und allgemein verfügbar zu machen, werden im Rahmen des OPC-UA-Standards verschiedene Typenbeschreibungen für Variablen, Objekte oder auch Datentypen verwendet. In verschiedenen Arbeitsgruppen werden aus diesen verfügbaren Mitteln weitere spezielle Spezifikationen erarbeitet, die einen bestimmten Teilbereich (bspw. einen Barcodescanner oder ein RFID-Lesegerät, aber auch ganze Maschinenschnittstellen) herstellerübergreifend modellieren. Diese sogenannten Companion-Spezifikationen oder Informationsmodelle werden damit zu einer Art Schnittstellenbeschreibung für die modellierten Objekte, und alle interessierten Hersteller können dieselbe Schnittstelle implementieren. In diesen Informationsmodellen werden auch Methoden für bestimmte Aktionen eingesetzt. Alle Typenbeschreibungen und weitere Informationen werden dazu üblicherweise in einer standardisierten XML-Datei zusammengefasst und können von verschiedenen Programmen wieder eingelesen werden. Ein zentrales Element ist dabei der Methodenaufruf durch einen OPC-UA-Client.
In der EP 3 182 235 B1 und der WO 2021/038028 A1 sind Verfahren beschrieben, nach denen in dem industriellen Steuerungsprogramm an einer zuvor definierten Stelle ein Aufruf in eine Systemfunktion erfolgt, die wiederum den Aufruf der Methode steuert. Das in der EP 3 182 235 B1 beschriebene Verfahren sieht dabei vor, dass der Anwender an einer zuvor festgelegten Stelle im industriellen Steuerungsprogramm einen speziellen Aufruf („OPC UA Call)“ in eine Systemfunktion einbaut, wobei diese Systemfunktion prüft, ob ein Methodenaufruf ansteht, und wobei das industrielle Steuerungsprogramm dann ggf. den entsprechenden Funktionsblock aufruft.
In dem in der WO 2021/038028 A1 beschriebenen Verfahren werden OPC-UA-Methodenaufrude auf Funktionsblock-Aufrufe abgebildet. Eingabeparameter bzw. Ausgabeparameter der OPC-UA-Methoden werden dann zu Eingabeparametern bzw. Ausgabeparametern des Funktionsblocks. Die Parameter eines Funktionsblocks bleiben typischerweise statisch erhalten, sodass es möglich ist, die Übergabe der Parameter vom Aufruf des Funktionsblocks zu trennen. Zunächst werden dabei die Eingabeparameter der Methode von dem OPC-UA-Server auf Eingabeparameter des Funktionsbausteins des industriellen Steuerungsprogramms kopiert. Anschließend wird der Funktionsbaustein an einer vorher definierten Stelle des industriellen Steuerungsprogramms aufgerufen, und zwar ohne den speziellen Systemaufruf der EP 3 182 235 B1 . In einem weiteren Schritt werden die Ausgabeparameter von dem Funktionsblock in den OPC-UA-Server kopiert. Dieser Ablauf erfordert eine zusätzliche Synchronisierung, weil die Übergabe der Parameter mit der Anwender-Task synchronisiert werden muss. Die Ausführung des Funktionsbausteins darf nur erfolgen, wenn auch ein Methodenaufruf vom OPC-UA-Client angefordert wurde. Zu diesem Zweck sieht das Verfahren einen weiteren Eingabeparameter vor, um zu signalisieren, dass ein Methodenaufruf anliegt. Ferner wird ein weiterer Ausgabeparameter eingeführt, um einen Abarbeitungsstand und/oder ein Fehlerzustand zu signalisieren.
Zusammenfassung
Die in der EP 3 182 235 B1 und der WO 2021/038028 A1 beschriebenen Verfahren erfordern, dass der Anwender die Stellen im industriellen Steuerungsprogramm vorsieht, an denen der Methodenaufruf erfolgen soll. Wenn der Anwender diese Stellen vergessen hat oder ungeeignet gewählt hat, beispielsweise in einem Pfad, der üblicherweise nicht ausgeführt wird, erfolgt der Methodenaufruf möglicherweise nur verzögert oder überhaupt nicht. Zudem wird die entsprechende Methode nicht ausgeführt, wenn sich das industrielle Steuerungsprogramm in einem Stopp-Zustand befindet. Häufig ist es jedoch gerade gewünscht, während der Inbetriebnahme oder während die Anlage nicht im Regelbetrieb läuft, Methoden über OPC-UA aufzurufen, um bestimmte Diagnoseinformationen zu erhalten. Dafür bietet der vorangehend beschriebene Stand der Technik keine Lösung.
Vor dem Hintergrund des Stands der Technik und der beschriebenen Nachteile liegt die Aufgabe der vorliegenden Offenbarung darin, verbesserte Techniken zum Aufrufen einer Methode eines industriellen Steuerungsprogramms einer speicherprogrammierbaren Steuerung bereitzustellen, die die Handhabung der Aufrufe für den Anwender vereinfachen und die vorgenannten Nachteile reduzieren oder vermeiden.
Diese Aufgabe wird durch ein Verfahren zum Aufrufen einer Methode eines industriellen Steuerungsprogramms einer speicherprogrammierbaren Steuerung gemäß Anspruch 1 und durch eine speicherprogrammierbare Steuerung gemäß Anspruch 10 gelöst. Die abhängigen Ansprüche beziehen sich auf vorteilhafte Weiterbildungen.
In einem ersten Aspekt bezieht sich die Offenbarung auf ein Verfahren zum Aufrufen einer Methode eines industriellen Steuerungsprogramms einer speicherprogrammierbaren Steuerung, wobei die speicherprogrammierbare Steuerung ein Laufzeitsystem mit einem OPC-UA-Server umfasst, der dazu eingerichtet ist, mit einem OPC-UA-Client über eine Kommunikationsverbindung gekoppelt zu werden, und wobei die speicherprogrammierbare Steuerung ferner das industrielle Steuerungsprogramm umfasst. Das Verfahren umfasst ein Empfangen eines auf die Methode gerichteten Methodenaufrufs von dem OPC-UA-Client an dem OPC-UA-Server und ein Aufrufen der Methode in dem industriellen Steuerungsprogramm aus dem Laufzeitsystem heraus in Reaktion auf den empfangenen Methodenaufruf.
Mit der offenbarungsgemäßen Lösung kann ein OPC-UA-Methodenaufruf direkt auf den Aufruf einer Methode einer bestimmten Instanz eines Funktionsblocks abgebildet werden. Insbesondere kann das Aufrufen der Methode in dem industriellen Steuerungsprogramm direkt aus dem Laufzeitsystem heraus erfolgen.
Diese Techniken können den Vorteil aufweisen, dass der Anwender weder im Steuerungsprogramm bestimmte Vorkehrungen für die Methodenaufrufe treffen muss noch einen Funktionsblock mit zusätzlichen Parametern definieren muss. Der Methodenaufruf wird dadurch erheblich vereinfacht und weniger fehleranfällig.
Zudem ermöglicht es die offenbarungsgemäße Lösung, einen Methodenaufruf auch auf ein industrielles Steuerungsprogramm im Stopp-Zustand anzuwenden, um beispielsweise während der Inbetriebnahme oder Wartung der speicherprogrammierbaren Steuerung Diagnose-Informationen zu erhalten. Der Einsatzbereich der Methodenaufrufe wird dadurch erheblich und auf für die Praxis wichtige Anwendungsfelder erweitert.
Im Rahmen der vorliegenden Offenbarung kann ein industrielles Steuerungsprogramm jedes Programm oder Teilprogramm bezeichnen, das dazu eingerichtet ist, auf einer speicherprogrammierbaren Steuerung gespeichert und/oder ausgeführt zu werden und eine mit der speicherprogrammierbaren Steuerung gekoppelte Maschine oder Anlage über Befehle anzusteuern und/oder von der Maschine oder Anlage Parameter, die sich auf den Betrieb der Maschine oder Anlage beziehen, abzufragen.
Das industrielle Steuerungsprogramm kann insbesondere die Form von Kontaktplananweisungen (auch als Leiterlogik bezeichnet) oder eines kompilierten Maschinencodes haben.
Das industrielle Steuerungsprogramm kann ausführbare Programmstücke in Form von Tasks, d. h. in Form von anwendungsbezogenen zusammenhängenden Aufgaben umfassen. Diese Tasks können zyklisch von einem Thread, d. h. von einem Ausführungsstrang oder einer Ausführungsreihenfolge, der speicherprogrammierbaren Steuerung aufgerufen werden.
Bei der von der speicherprogrammierbaren Steuerung gesteuerten Maschine oder Anlage kann es sich um j edwede Form einer ansteuerbaren Maschine oder Anlage handeln, umfassend beispielsweise auch chemische Produktionsanlagen oder Lichtsteuerungen.
Das Laufzeitsystem (manchmal auch synonym als Laufzeitumgebung bezeichnet) kann im Rahmen der vorliegenden Offenbarung eine Plattform bezeichnen, auf der das industrielle Steuerungsprogramm aufsetzen kann. Es kann grundlegende Funktionalitäten für das Lesen und Schreiben von Daten, den Datentransport über Netzwerke und zugeordnete Schnittstellen, die Datenverwaltung und/oder das Ansteuern von Eingabegeräten und Ausgabegeräten bereitstellen. Dazu können auch Laufzeitbibliotheken, Standardbibliotheken, Programmierschnittstellen und Laufzeitvariablen gehören.
Das Laufzeitsystem kann insbesondere funktional von dem industriellen Steuerungsprogramm getrennt sein.
In einer Ausführungsform kann das Laufzeitsystem über eine Schnittstelle mit dem industriellen Steuerungsprogramm kommunizieren. Über diese Schnittstelle können beispielsweise Parameter oder Variablen zwischen dem Laufzeitsystem, insbesondere dem OPC-UA-Server, und dem industriellen Steuerungsprogramm übergeben werden.
Eine Methode kann im Rahmen der vorliegenden Offenbarung eine Subroutine bezeichnen, die eine Folge von Programminstruktionen umfasst. Eine Methode kann dabei einem Objekttyp zugeordnet sein und kann - wie in objektorientierten Programmiersprachen üblich - auf einer Instanz eines solchen Objekts ausgeführt werden. Eine Methode kann insbesondere Prozeduren und/oder Funktionen umfassen. In der Definition einer Methode können eine oder mehrere formale Parameter festgelegt werden, mit denen die Methode aufgerufen werden kann.
Als OPC-UA-Server und OPC-UA-Client können im Rahmen der vorliegenden Offenbarung ein Server-Client-Paar bezeichnet werden, die dazu eingerichtet sind, über die Kommunikationsverbindung mittels des OPC-UA-Kommunikationsprotokolls miteinander zu kommunizieren. Der OPC-UA-Server kann dabei Methoden zur Verfügung stellen, die von dem OPC-UA-Client angefordert werden können.
Die Kommunikationsverbindung kann jedwede drahtgebundene oder drahtlose Verbindung umfassen. Insbesondere kann die Kommunikationsverbindung ein dediziertes industrielles Steuerungsnetzwerk und/oder das Internet umfassen.
Ferner kann der empfangene Methodenaufruf mindestens einen Eingabeparameter und/oder mindestens einen Ausgabeparameter umfassen.
Gemäß einer Ausführungsform umfasst das Laufzeitsystem ein Speicherelement.
Das Speicherelement kann einen dynamischen Speicher, insbesondere einen Heap-Speicher, umfassen oder ein dynamischer Speicher, insbesondere ein Heapspeicher, sein.
Insbesondere kann dem Eingabeparameter und/oder dem Ausgabeparameter eine Speicheradresse in dem Speicherelement zugeordnet sein.
Gemäß einer Ausführungsform werden die Speicheradressen beim Kompilieren des industriellen Steuerungsprogramms vergeben.
Dadurch wird es möglich, die Eingabeparameter und/oder Ausgabeparameter konsistent zwischen dem Laufzeitsystem und dem industriellen Steuerungsprogramm zu übergeben. Insbesondere kann dadurch auf eine Synchronisation der Übergabe der Parameter mit dem Methodenaufruf verzichtet werden.
In einer Ausführungsform umfasst das Verfahren auch ein Kompilieren des industriellen Steuerungsprogramms, wobei die Speicheradressen beim Kompilieren des industriellen Steuerungsprogramms vergeben werden.
Gemäß einer Ausführungsform umfasst das Aufrufen der Methode in dem industriellen Steuerungsprogramm aus dem Laufzeitsystem heraus ein Übergeben des Eingabeparameters und/oder des Ausgabeparameters aus dem Speicherelement bzw. der zugeordneten Speicheradressen an das industrielle Steuerungsprogramm.
Das Übergeben des Eingabeparameters und/oder des Ausgabeparameters an das industrielle Steuerungsprogramm kann mittels eines Stackspeichers, insbesondere eines Stackspeichers des Laufzeitsystems, erfolgen.
Insbesondere können alle benötigten Eingabeparameter und/oder Ausgabeparameter auf dem Stackspeicher übergeben werden. Auf eine Parameterübergabe über Register kann verzichtet werden.
Gemäß einer Ausführungsform läuft das Laufzeitsystem, insbesondere der OPC-UA-Server, in demselben Variablenadressraum wie das industrielle Steuerungsprogramm.
Auf diese Weise kann insbesondere eine konsistente Übergabe der Eingabeparameter und/oder der Ausgabeparameter zwischen dem Laufzeitsystem und dem industriellen Steuerungsprogramm sichergestellt werden. Diese Techniken erleichtern es, den Methodenaufruf direkt aus dem Laufzeitsystem heraus vorzunehmen und eine Datenkonsistenz sicherzustellen, ohne dass die Übergabe der Parameter mit dem Methodenaufruf synchronisiert zu werden braucht.
Gemäß einer Ausführungsform umfasst das Verfahren ein Empfangen eines Wertes des mindestens einen Ausgabeparameters von dem industriellen Steuerungsprogramm an der dem Ausgabeparameter zugeordneten Speicheradresse des Speicherelements.
In einer Weiterbildung umfasst das Verfahren ein Übergeben des empfangenen Werts des mindestens einen Ausgabeparameters von dem Speicherelement mittels des OPC-UA-Servers an den OPC-UA-Client, insbesondere über die Kommunikationsverbindung.
Gemäß einer Ausführungsform erfolgt das Aufrufen der Methode nicht aus dem industriellen Steuerungsprogramm heraus.
Insbesondere kann das Aufrufen der Methode erfolgen, auch wenn das industrielle Steuerungsprogramm zum Zeitpunkt des Aufrufens angehalten ist..
Gemäß einer Ausführungsform wird in Reaktion auf das Aufrufen der Methode ein Wert mindestens eines Ausgabeparameters des industriellen Steuerungsprogramms von dem Laufzeitsystem empfangen, auch wenn das industrielle Steuerungsprogramm zum Zeitpunkt des Aufrufens angehalten ist.
Auf diese Weise können Methodenaufrufe auch in Konstellationen ausgeführt werden, in denen das industrielle Steuerungsprogramm sich in einem Stopp-Zustand befindet, beispielsweise während der Inbetriebnahme oder Wartung der speicherprogrammierbaren Steuerung.
Das Aufrufen der Methode in dem industriellen Steuerungsprogramm aus dem Laufzeitsystem heraus kann in kausaler und/oder zeitlicher Reaktion auf den empfangenen Methodenaufruf erfolgen.
Gemäß einer Ausführungsform erfolgt das Aufrufen der Methode in dem industriellen Steuerungsprogramm aus dem Laufzeitsystem heraus direkt und zeitlich unmittelbar in Reaktion auf den empfangenen Methodenaufruf.
In anderen Ausführungsformen kann das Aufrufen der Methode in dem industriellen Steuerungsprogramm aus dem Laufzeitsystem heraus in kausaler Reaktion auf den empfangenen Methodenaufruf, aber mit einer zeitlichen Verzögerung gegenüber dem empfangenen Methodenaufruf, erfolgen.
Gemäß einer Ausführungsform umfasst das Verfahren ein Bestimmen eines Zeitpunkts für das Aufrufen der Methode in dem industriellen Steuerungsprogramm aus dem Laufzeitsystem.
Dadurch lässt sich der Methodenaufruf gegenüber dem Ablaufen des industriellen Steuerungsprogramms synchronisieren, um beispielsweise den Einfluss des Methodenaufrufs auf die Laufzeit des industriellen Steuerungsprogramms bzw. den Einfluss auf das Echtzeitverhalten der speicherprogrammierbaren Steuerung zu reduzieren.
Gemäß einer Ausführungsform erfolgt das Aufrufen der Methode in dem industriellen Steuerungsprogramm aus dem Laufzeitsystem zu dem bestimmten Zeitpunkt und/oder wird bis zu dem bestimmten Zeitpunkt verzögert.
Der Zeitpunkt kann zumindest teilweise auf Grundlage einer Auslastung, insbesondere einer prognostizierten Auslastung, der speicherprogrammierbaren Steuerung bestimmt werden.
Gemäß einem zweiten Aspekt bezieht sich die Offenbarung auf ein rechnerlesbares Programm oder Programmprodukt mit rechnerlesbaren Instruktionen, wobei die rechnerlesbaren Instruktionen dazu eingerichtet sind, beim Ablaufen auf einem Rechnersystem, insbesondere auf einer speicherprogrammierbaren Steuerung, ein Verfahren mit einem oder allen der vorangehenden Merkmale zu implementieren.
Das rechnerlesbare Programm kann insbesondere auf einem computerlesbaren Medium gespeichert sein.
Gemäß einem dritten Aspekt bezieht sich die Offenbarung auf eine speicherprogrammierbare Steuerung, welche ein Laufzeitsystem mit einem OPC-UA-Server umfasst, wobei der OPC-UA-Server dazu eingerichtet ist, mit einem OPC-UA-Client über eine Kommunikationsverbindung gekoppelt zu werden bzw. zu sein. Die speicherprogrammierbare Steuerung ist ferner dazu eingerichtet, ein industrielles Steuerungsprogramm auszuführen. Der OPC-UA-Server ist dazu eingerichtet, einen auf eine Methode des industriellen Steuerungsprogramms gerichteten Methodenaufruf von dem OPC-UA-Client zu empfangen, insbesondere über die Kommunikationsverbindung zu empfangen. Das Laufzeitsystem ist dazu eingerichtet, die Methode in dem industriellen Steuerungsprogramm aus dem Laufzeitsystem heraus in Reaktion auf den empfangenen Methodenaufruf aufzurufen.
Die speicherprogrammierbare Steuerung gemäß dem dritten Aspekt kann dazu eingerichtet sein, ein Verfahren zum Aufrufen einer Methode des industriellen Steuerungsprogramms mit einem oder allen der Merkmale, wie sie vorangehend unter Bezugnahme auf den ersten Aspekt beschrieben wurden, zu implementieren.
Insbesondere kann der empfangene Methodenaufruf mindestens einen Eingabeparameter und/oder mindestens einen Ausgabeparameter umfassen.
Gemäß einer Ausführungsform umfasst das Laufzeitsystem ein Speicherelement.
Insbesondere kann dem Eingabeparameter und/oder dem Ausgabeparameter eine Speicheradresse in dem Speicherelement zugeordnet sein.
Das Laufzeitsystem kann in einer Ausführungsform dazu eingerichtet sein, den Eingabeparameter und/oder den Ausgabeparameter aus dem Speicherelement bzw. die zugeordneten Speicheradressen in Zusammenhang mit dem Aufrufen der Methode in dem industriellen Steuerungsprogramm aus dem Laufzeitsystem heraus an das industrielle Steuerungsprogramm zu übergeben.
Gemäß einer Ausführungsform ist das Laufzeitsystem dazu eingerichtet, einen Wert des mindestens einen Ausgabeparameters von dem industriellen Steuerungsprogramm an der dem Ausgabeparameter zugeordneten Speicheradresse des Speicherelements zu empfangen.
In einer Weiterbildung ist das Laufzeitsystem, insbesondere der OPC-UA-Server, dazu eingerichtet, den empfangenen Wert des mindestens einen Ausgabeparameters von dem Speicherelement an den OPC-UA-Client zu übergeben, insbesondere über die Kommunikationsverbindung an den OPC-UA-Client zu übergeben.
In einer Ausführungsform umfasst die speicherprogrammierbare Steuerung eine Scheduler-Einheit, welche dazu eingerichtet ist, einen Zeitpunkt für das Aufrufen der Methode in dem industriellen Steuerungsprogramm aus dem Laufzeitsystem zu bestimmen.
Figurenliste
Die Merkmale und zahlreichen Vorteile der offenbarungsgemäßen Lösung lassen sich am besten anhand einer detaillierten Beschreibung bevorzugter Ausführungsformen unter Bezugnahme auf die anliegenden Zeichnungen verstehen, in denen:

1 in schematischer Darstellung eine Steuerungsumgebung zeigt, in der ein Verfahren zum Aufrufen einer Methode eines industriellen Steuerungsprogramms einer speicherprogrammierbaren Steuerung gemäß einer Ausführungsform eingesetzt werden kann;
2 in schematischer Darstellung eine speicherprogrammierbare Steuerung gemäß einer Ausführungsform zeigt;
3 ein Flussdiagramm eines Verfahrens zum Aufrufen einer Methode eines industriellen Steuerungsprogramms einer speicherprogrammierbaren Steuerung gemäß einer Ausführungsform zeigt; und
4 den Datenfluss im Rahmen eines Methodenaufrufs gemäß einer Ausführungsform in einer konzeptionellen Darstellung veranschaulicht.

Detaillierte Beschreibung
Ausführungsformen eines Verfahrens zum Aufrufen einer Methode eines industriellen Steuerungsprogramms einer speicherprogrammierbaren Steuerung werden nachfolgend unter Bezugnahme auf eine beispielhafte und in 1 schematisch veranschaulichte industrielle Steuerungsumgebung 10 beschrieben, bei der es um die Steuerung eines Portalkrans 12 mittels einer speicherprogrammierbaren Steuerungssoftware geht. Dieses Beispiel dient jedoch nur der Veranschaulichung, und im Allgemeinen können die Techniken der vorliegenden Offenbarung für die Steuerung jeder Art von Prozessen oder Anlagen eingesetzt werden, einschließlich, aber nicht beschränkt auf die Steuerung von Industriemaschinen, Robotern, chemischen Herstellungsprozessen oder Lichtsteuerungsanwendungen.
Wie in 1 dargestellt, umfasst die industrielle Steuerungsumgebung 10 des Ausführungsbeispiels einen Portalkran 12, bei dem es sich um einen Kran handeln kann, der in einer Fabrikumgebung eingesetzt wird, um schwere Güter in einer Montagehalle mit Hilfe einer beweglichen Hakenbaugruppe 14 zu bewegen, deren Aktuatoren durch eine Steuerungssoftware gesteuert werden.
Die industrielle Steuerungsumgebung 10 umfasst dazu ferner eine speicherprogrammierbare Steuerungseinheit (SPS) 16, die mit dem Portalkran 12 über eine Steuerleitung 18, z. B. eine drahtgebundene oder drahtlose Verbindung, verbunden ist. In anderen Beispielen kann die speicherprogrammierbare Steuerungseinheit 16 in die gesteuerte Maschine, wie den Portalkran 12, integriert sein.
Die in 1 dargestellte speicherprogrammierbare Steuerungseinheit 16 umfasst ein industrielles Steuerungsprogramm 20 und ein Laufzeitsystem 22. Das industrielle Steuerungsprogramm 20 kann beispielsweise kompilierten Programmcode umfassen, der in einer Speichereinheit (nicht gezeigt) der speicherprogrammierbaren Steuerungseinheit 16 gespeichert sein kann und in einer Verarbeitungseinheit (nicht gezeigt) der speicherprogrammierbaren Steuerungseinheit 16, beispielsweise einer CPU, ausgeführt wird. Der Programmcode kann in Form von Tasks, d. h. in Form von anwendungsbezogenen zusammenhängenden Aufgaben, vorliegen. Diese Tasks können zyklisch von einem Thread, d. h. von einem Ausführungsstrang oder einer Ausführungsreihenfolge, der speicherprogrammierbaren Steuerungseinheit 16 aufgerufen werden. Es kann sich dabei beispielsweise um Programmcode handeln, um die Bewegung der Hakenbaugruppe 14 des Portalkrans 12 zu steuern und/oder um Sensordaten von dem Portalkran 12 auszulesen.
Das Laufzeitsystem 22 stellt eine Plattform dar, auf der das industrielle Steuerungsprogramm 20 aufsetzen kann. Zum Laufzeitsystem 22 können insbesondere Laufzeitbibliotheken, Standardbibliotheken, Programmier- und Kommunikationsschnittstellen sowie Laufzeitvariablen gehören.
Das Laufzeitsystem 22 umfasst insbesondere eine Kommunikationsschnittstelle 24, die dazu eingerichtet ist, mit dem Portalkran 12 über die Steuerleitung 18 zu kommunizieren. Beispielsweise kann die Kommunikationsschnittstelle 24 über die Steuerleitung 18 Anweisungen des industriellen Steuerungsprogramms 20 für den Betrieb der Aktuatoren an den Portalkran 12 geben, um die Hakenbaugruppe 14 entlang eines vorbestimmten Pfades zu bewegen. Die Kommunikationsschnittstelle 24 kann auch Sensorsignale, die sich auf einen Betrieb des Portalkrans 12 beziehen, über die Steuerleitung 18 empfangen und entsprechende Rückmeldungen an das industrielle Steuerungsprogramm 20 liefern. Solche Sensorsignale können sich zum Beispiel auf Sensoren beziehen, die eine Position der Hakenbaugruppe 14 am Portalkran 12 anzeigen.
Wie in 1 weiter dargestellt ist, umfasst das Laufzeitsystem 22 auch einen OPC-UA-Server 26, welcher über die Kommunikationsschnittstelle 24 und eine Kommunikationsverbindung 28 mit einem externen OPC-UA-Client 30 gekoppelt ist. Die Kommunikationsverbindung 28 kann ein dediziertes Steuerungsnetzwerk umfassen, welches beispielsweise auch die Steuerleitung 18 beinhalten kann. Alternativ kann die Kommunikationsverbindung 28 auch ein öffentliches Netzwerk, beispielsweise das Internet, umfassen.
Die in 1 dargestellte Konfiguration erlaubt es einem Anwender, mittels des OPC-UA-Clients 30 über die Kommunikationsverbindung 28 auf den OPC-UA-Server 26 und von dort auf das industrielle Steuerungsprogramm 20 zuzugreifen. Der OPC-UA- Standard stellt dazu insbesondere Dienste bereit, die es dem Anwender möglich machen, sich beim Zugriff auf die speicherprogrammierbare Steuerungseinheit 16 in einem Adressraum ähnlich einem Dateisystem zu bewegen und einzelne Werte zu selektieren. Diese Werte können dann durch den OPC-UA-Client 30 gelesen oder überwacht oder auch beschrieben werden. Auf diese Weise können beispielsweise Parameter des industriellen Steuerungsprogramms 20, die sich auf den Betrieb der Hakenbaugruppe 14 beziehen, über den OPC-UA-Client 30 an einem externen Rechner visualisiert werden. In anderen Anwendungen kann der OPC-UA-Client 30 beispielsweise dazu verwendet werden, die speicherprogrammierbare Steuerungseinheit 16 ausgehend von einem entfernten Rechner, auf dem der OPC-UA-Client 30 implementiert ist, neu zu konfigurieren. Zusätzlich bietet der OPC-UA-Standard die Möglichkeit, dass der OPC-UA-Server 26 dem OPC-UA-Client 30 Methodenaufrufe anbieten kann, die dem OPC-UA-Client 30 die Möglichkeit geben, auf den Ablauf des OPC-UA-Servers 26 einzuwirken und dort bestimmte Aktionen auszulösen. Diese Verfahren zum Aufrufen einer Methode des industriellen Steuerungsprogramms 20 vom OPC-UA-Client 30 aus werden nachfolgend unter Bezugnahme auf die 2 und 3 in weiteren Einzelheiten beschrieben.
Wie in 1 weiter dargestellt ist, kann die industrielle Steuerungsumgebung 10 ferner eine Programmierumgebung 32 umfassen, die mit der Kommunikationsschnittstelle 24 der speicherprogrammierbaren Steuerungseinheit 16 über ein Netzwerk, wie z. B. die Kommunikationsverbindung 28, verbunden ist. Die Programmierumgebung 32 kann beispielsweise einen Desktop-PC oder ein anderes Computergerät umfassen und kann von einem Programmierer verwendet werden, um industrielle Steuerungssoftware zu entwerfen und zu generieren, z.B. in Form eines Steuerungsprogramms in einer Hochsprache wie C, C++ oder C#.
Die Programmierumgebung 32 kann dazu insbesondere eine Programmierschnittstelle 34 umfassen, wie z. B. einen Programmiereditor oder einen grafischen Editor, der es einem Programmierer ermöglicht, ein Steuerungsprojekt für die speicherprogrammierbare Steuerungseinheit 16 zu erzeugen, wobei das Steuerungsprojekt beispielsweise ein Steuerungsprojekt gemäß dem Industriestandard 61131-3 sein kann und insbesondere ein Steuerungsprogramm in einer Programmierhochsprache, globale Variablen, Funktionsblöcke und Funktionen mit lokalen Variablen umfassen kann. Die Programmierumgebung 32 kann ferner eine Programmierspeichereinheit 36 und eine Programmierprozessoreinheit 38 umfassen, die mit der Programmierschnittstelle 34 verbunden sind. Die Programmierspeichereinheit 36 kann Funktionen, Funktionsblöcke oder Variablen speichern, die vom Programmierer bei der Erstellung des Steuerungsprojekts verwendet werden können. Die Programmierprozessoreinheit 38 kann die Verarbeitungsressourcen bereitstellen, um die Programmierschnittstelle 34 zu betreiben und das Steuerungsprojekt zu erzeugen.
In einigen Ausführungsformen kann die Programmierumgebung 32 zusätzlich eine Compiler-Einheit 40 umfassen, die das Steuerungsprojekt einschließlich des Steuerungsprogramms aus der Hochsprache in ein kompiliertes Steuerungsprogramm in Maschinencode umwandeln kann. Das kompilierte Steuerungsprogramm kann dann der speicherprogrammierbaren Steuerungseinheit 16 über die Kommunikationsverbindung 28 und die Kommunikationsschnittstelle 24 zur Verfügung gestellt werden und dort als industrielles Steuerungsprogramm 20 gespeichert und ausgeführt werden.
In anderen Ausführungsformen stellt die Programmierumgebung 32 der speicherprogrammierbaren Steuerungseinheit 16 das Steuerungsprojekt einschließlich des Steuerungsprogramms in der Programmierhochsprache über die Kommunikationsverbindung 28 zur Verfügung, und die speicherprogrammierbare Steuerungseinheit 16 umfasst eine Compiler-Einheit (nicht dargestellt), die das Steuerungsprojekt in Maschinencode kompiliert.
Die Compiler-Einheit 40 kann insbesondere dazu eingerichtet sein, die Speicherpositionen bzw. Speicheradressen der Objekte und Variablen des Steuerungsprojekts bereits beim Kompilieren statisch festzulegen, beispielsweise in Form von Speicher-Offsets bezüglich einer Ursprungsadresse eines Speicherelements der speicherprogrammierbaren Steuerungseinheit 16.
Während in 1 die Programmierumgebung 32 und der OPC-UA-Client 30 als separate Einheiten und räumlich getrennt voneinander dargestellt sind, kann in anderen Ausführungsformen der OPC-UA-Client 30 auch auf der Programmierumgebung 32 implementiert sein.
2 zeigt eine speicherprogrammierbare Steuerungseinheit 16 gemäß einer Ausführungsform, wie sie beispielsweise im Rahmen der in 1 gezeigten industriellen Steuerungsumgebung 10 eingesetzt werden kann. In den 1 und 2 sind einander funktional entsprechende Komponenten mit denselben Bezugszeichen bezeichnet. Optionale Komponenten sind in 2 durch gestrichelte Linien dargestellt.
Die speicherprogrammierbare Steuerungseinheit 16 umfasst ein Laufzeitsystem 22 mit einem OPC-UA-Server, der dazu eingerichtet ist, mit einem OPC-UA-Client 30 über eine Kommunikationsverbindung 28 gekoppelt zu werden, wobei der OPC-UA-Client 30 insbesondere ein externer Client sein kann, der nicht Bestandteil der speicherprogrammierbaren Steuerungseinheit 16 ist. Die speicherprogrammierbare Steuerungseinheit 16 ist ferner dazu eingerichtet, ein industrielles Steuerungsprogramm 20 auszuführen.
Der OPC-UA-Server 26 ist dazu eingerichtet, einen auf eine Methode des industriellen Steuerungsprogramms 20 gerichteten Methodenaufruf von dem OPC-UA-Client 30 zu empfangen. Das Laufzeitsystem 22 ist dazu eingerichtet, die Methode in dem industriellen Steuerungsprogramm 20 aus dem Laufzeitsystem 22 heraus in Reaktion auf den empfangenen Methodenaufruf aufzurufen.
Der empfangene Methodenaufruf kann insbesondere mindestens einen Eingabeparameter und/oder mindestens einen Ausgabeparameter umfassen.
In einer Ausführungsform umfasst das Laufzeitsystem 22 ein Speicherelement, welches beispielsweise als dynamischer Speicher bzw. Heap-Speicher 42 ausgebildet sein kann. Dem Eingabeparameter und/oder dem Ausgabeparameter können jeweils entsprechende Speicheradressen in dem Speicherelement 42 zugeordnet sein.
Wie in 2 angedeutet, ist das industrielle Steuerungsprogramm 20 konzeptionell und funktional von dem Laufzeitsystem 22 verschieden, jedoch über eine Schnittstelle 44 mit dem Laufzeitsystem 22 verbunden. Über die Schnittstelle 44 können die Methodenaufrufe aus dem Laufzeitsystem 22 in das industrielle Steuerungsprogramm 20 erfolgen. Insbesondere können über die Schnittstelle 44 die mit dem Methodenaufruf verbundenen Eingabeparameter und/oder Ausgabeparameter übergeben werden. Das Übergeben des mindestens einen Eingabeparameters und/oder des mindestens einen Ausgabeparameters kann insbesondere mittels eines Stackspeichers (Stapelspeichers) 46 des Laufzeitsystems 22 erfolgen.
3 veranschaulicht anhand eines Flussdiagramms ein beispielhaftes Verfahren zum Aufrufen einer Methode eines industriellen Steuerungsprogramms einer speicherprogrammierbaren Steuerungseinheit, insbesondere der vorangehend mit Bezug auf die 1 und 2 beschriebenen speicherprogrammierbaren Steuerungseinheit 16, wobei die speicherprogrammierbare Steuerungseinheit 16 ein Laufzeitsystem 22 mit einem OPC-UA-Server 26 umfasst, der dazu eingerichtet ist, mit einem externen OPC-UA-Client 30 über eine Kommunikationsverbindung 28 gekoppelt zu werden, und wobei die speicherprogrammierbare Steuerungseinheit 16 ferner das industrielle Steuerungsprogramm 20 umfasst.
In einem ersten Schritt S10 umfasst das Verfahren das Empfangen eines auf eine Methode gerichteten Methodenaufrufs von dem OPC-UA-Client 30 an dem OPC-UA-Server 26, insbesondere über die Kommunikationsverbindung 28.
In einem darauffolgenden zweiten Schritt S12 umfasst das Verfahren ein Aufrufen der Methode in dem industriellen Steuerungsprogramm 20 aus dem Laufzeitsystem 22 heraus in Reaktion auf den empfangenen Methodenaufruf.
Auf diese Weise wird ein Verfahren bereitgestellt, mit dem ein OPC-UA-Methodenaufruf direkt auf den Aufruf einer Methode einer bestimmten Instanz eines Funktionsblocks abgebildet werden kann, sodass der Aufruf direkt aus dem Laufzeitsystem 22 erfolgen kann. Der Anwender muss dazu weder im Anwenderprogramm, d. h. in dem industriellen Steuerungsprogramm 20, bestimmte Vorkehrungen treffen, noch muss er einen Funktionsblock mit zusätzlichen Parameter definieren.
Die vorgestellten Techniken ermöglichen einen Aufruf in die Anwenderapplikation bzw. in das industrielle Steuerungsprogramm 20 aus dem Laufzeitsystem heraus. Da sich das Anwenderprogramm und die Methoden, die darin aufrufbar sind, jederzeit ändern können, das Laufzeitsystem 22 aber regelmäßig nicht entsprechend geändert werden soll, kann mit dem offenbarungsgemäßen Verfahren in vorteilhafter Weise Information für einen Methodenaufruf in das Laufzeitsystem transportiert werden, sodass der Methodenaufruf dort generisch durch das Laufzeitsystem 22 durchgeführt werden kann. Der Aufruf kann dann direkt auf einen Methodenaufruf abgebildet werden, dessen Eingabeparameter und Ausgabeparameter auf dem Stackspeichers 46 übergeben werden können. Dadurch ist es nicht nötig, die Übergabe der Parameter mit dem Aufruf zu synchronisieren. Optional und in Abhängigkeit von den Einsatzerfordernissen kann jedoch ein solcher Aufruf mit den Tasks der Anwenderapplikationen synchronisiert werden, ohne dass in den Anwendertasks dazu spezielle Vorkehrungen getroffen werden müssen.
Im folgenden wird ein beispielhaftes Verfahren zur Veranschaulichung in weiteren Einzelheiten und in seinen aufeinander aufbauenden Teilschritten beschrieben.
In einem ersten Schritt des Beispiels wird in der Programmierumgebung 32 eine XML-Version des der industriellen Steuerungsumgebung 10 zugeordneten Informationsmodells eingelesen. Aus diesem Modell können entsprechend dem Standard IEC 61131-3 passende Funktionsbausteine, Datentypen, Variablen usw. erzeugt werden. In einem nachfolgenden Schritt kann der Anwender mit der Programmierschnittstelle 34 und unter Verwendung dieser Bausteine eine IEC-Applikation erzeugen und mittels der Compiler-Einheit 40 in Maschinencode eines industriellen Steuerungsprogramms 20 übersetzen.
Während des Übersetzungsvorgangs der IEC-Applikation kann eine genaue Beschreibung der Methoden und Funktionen erzeugt werden, welche durch das Laufzeitsystem 22 verarbeitet werden können. Entsprechende Methodenaufrufe von dem OPC-UA-Client 30 können dann durch den OPC-UA-Server 26 entgegengenommen werden. Aufgrund der genauen Beschreibung der Aufrufe kann das Laufzeitsystem 22 die Methodenaufruf direkt in die IEC-Applikation bzw. in das industrielle Steuerungsprogramm 20 durchführen.
Im folgenden werden diese aufeinanderfolgenden Schritte in weiteren Einzelheiten beschrieben.
(a) Einlesen der Informationsmodelle und Erzeugen der IEC-Bausteine
Das Informationsmodell wird in der Programmierumgebung 32 geladen und analysiert. Um bestimmte Anwendungsfälle aus dem Informationsmodell umzusetzen, kann der Programmierer mittels der Programmierschnittstelle 34 bestimmte benötigte Teile auswählen. Aus diesen Elementen können dann anhand einer bestehenden Abbildungsvorschrift die IEC-Elemente generiert werden. Diese Elemente werden dann innerhalb der IEC-Applikation verwendet und können mit der entsprechenden Logik ausprogrammiert werden. Dabei werden auch die Methoden entsprechend generiert.
Das folgende Beispiel zeigt eine Methodenbeschreibung in der OPC-UA-Modellierungssprache, aus der das OPC-UA-Informationsmodell generiert werden kann:

 <opc:ObjectType SymbolicName="TestRootObjectType"
 BaseType="ua:BaseObjectType" IsAbstract="false" SupportsEvents = "false">
 <opc:Description>Entry point for tests</opc:Description>
   <opc:Children>
     <opc:Variable SymbolicName="Var1" DataType="ua:Int32"
     ValueRank="Scalar" ModellingRule="Mandatory" />
     <opc:Object SymbolicName="Var2" TypeDefinition="NestedObjectType"
     ModellingRule="Mandatory" />
     <opc:Object SymbolicName="TestPlaceholder_Nr_"
     TypeDefinition="PlaceholderObjectType"
     ModellingRule="OptionalPlaceholder" />
     <opc:Object SymbolicName="Auxiliaries" TypeDefinition="ua:FolderType"
     ModellingRule="Optional" />
     <opc:Object SymbolicName="Modules" TypeDefinition="ModuleGroupType"
     ModellingRule="Optional" />
     <opc:Method SymbolicName="ExampleMethod"
     TypeDefinition="ExampleMethodType" />
     <opc:Method SymbolicName="ExampleComplexMethod"
     TypeDefinition="ExampleComplexMethodType" />
    <opc:Method SymbolicName="ExampleArrayOutputMethod"
    TypeDefinition="ExampleArrayOutputMethodType" /> 
   </opc:Children>
  </opc:Obj ectType>
  <opc:Method SymbolicName="ExampleComplexMethodType">
    <opc:InputArguments>
      <opc:Argument Name="summand1" DataType="ua:Int32"
      TypeDefinition="ua:PropertyType" />
      <opc:Argument Name="summand2" DataType="ua:Int32"
        TypeDefinition="ua:PropertyType" />
        <opc:Argument Name="dutTest" DataType="DataTypeSimple"
        TypeDefinition="ua:PropertyType" />
        <opc:Argument Name="aryTest" DataType="DataTypeSimple"
        TypeDefinition="ua:PropertyType" ValueRank="Array" />
     </opc:InputArguments>
     <opc:OutputArguments>
        <opc:Argument Name="sum" DataType="ua:Int32" />
        <opc:Argument Name="aryOut" DataType="ua:Int32" ValueRank="Array"/>
      </opc:OutputArguments>
      </opc:Method>

Aus diesem Beispiel ist ersichtlich, dass es einen Objekttypen „TestRootObject“ gibt, der eine Methode „ExampleComplexMethod“ enthält. Aus dem daraus erzeugten Informationsmodell wird dann ein Funktionsbaustein mit einer entsprechenden Methode generiert. Die Methoden werden entsprechend der Definition als Methoden des Funktionsbausteins definiert, hier ersichtlich anhand der Methode „ExampleComplexMethod“:

Diese Methode kann mit dem vorangehend beschriebenen Verfahren dann von dem OPC-UA-Client 30 aufgerufen werden. Der Programmierer füllt die Methode mit der benötigten Programmlogik. Die verwendeten Attribute werden benutzt, um die Methode mit dem Informationsmodell in Verbindung zu setzen. Dabei wird definiert, aus welchem Modell (im Programmcode bezeichnet mit „modeluri“) und aus welcher Version (bezeichnet mit „publicationdate“) dieses Element stammt. Über den Identifikator „NodeID“ wird die Verbindung zur definierten Methode aus dem Informationsmodell hergestellt. Dieser Identifikator kann während des Übersetzens des OPC-UA-Modells in das Informationsmodell fest vergeben und erzeugt werden und ist daher innerhalb des Informationsmodells eindeutig.

(b) Codegenerierung

Nachdem die Programmierung auf der Programmierschnittstelle 34 abgeschlossen wurde, kann die IEC-Applikation mittels der Compiler-Einheit 40 in ausführbaren Maschinencode des industriellen Steuerungsprogramms 20 übersetzt und auf die speicherprogrammierbare Steuerungseinheit 16 übertragen werden. Während dieses Übersetzungsvorgang in der Compiler-Einheit 40 kann auch Code für die Methodenaufrufe generiert werden. Dabei können die Aufrufe einem bestimmten Aufrufschema folgen, das der Aufrufer und der Aufgerufene einhalten müssen. Alle benötigten Eingabeparameter und Ausgabeparameter können auf dem Stackspeicher 46 übergeben werden. Insbesondere kann auf eine Parameterübergabe über Register verzichtet werden. Daraus folgt auch, dass der Aufrufer jeden einzelnen Parameter an die korrekte Position auf dem Stackspeicher 46 kopieren sollte; ansonsten funktioniert die Parameterübergabe ggf. nicht korrekt. Diese korrekte Positionierung kann beispielsweise durch die Compiler-Einheit 40 sichergestellt werden. Freie Methodenaufruf (Funktionen) und instanzbezogene Methodenaufrufe können sich ggf. dabei lediglich durch einen impliziten ersten Parameter unterscheiden, den Pointer auf die Instanz.

Die Strukturierung der einzelnen Parameter für den Methodenaufruf lässt sich auch durch eine Datenstruktur nachbilden. Dabei wird jeder Parameter der Methode zu einem Element einer Datenstruktur. Durch die korrekte Wahl der Datentypen und Offsets in der Struktur ergibt sich ein identisches Layout zwischen der Struktur und der relativen Position der Parameter auf dem Stackspeicher 46.

Um einen allgemeingültigen Methodenaufruf durch das Laufzeitsystem 22 durchführen zu können, ist es sehr vorteilhaft, die Aufrufkonventionen der IEC-Applikation einzuhalten; ansonsten könnten die Parameter möglicherweise falsch übergeben werden. Für den OPC-UA-Server 26 ergibt sich daraus, dass eine solche strukturierte Beschreibung der Parameter vorliegen sollte, anhand derer die Parameter, welche durch den OPC-UA-Client 30 empfangen wurden, auch korrekt an die Methode übergeben werden können. Diese Beschreibung kann bereits während des Übersetzungsvorgangs mittels der Compiler-Einheit 40 erzeugt werden. Sie kann insbesondere alle notwendigen Eigenschaften und Offsets der Parameter enthalten, um das Layout des Aufrufs auf dem Stack in einer Datenstruktur nachbauen zu können. Insbesondere können in dieser Beschreibung Informationen dazu enthalten sein, wie viel Speicherplatz für die Parameterübergabe (Eingabe und Ausgabe) jeweils notwendig ist. Auch können Beschreibungen für jeden einzelnen Parameter umfasst sein, darunter insbesondere die Richtung des Parameters (Input, Output, InOut), der Datentyp und Arraytyp, der Offset innerhalb der Datenstruktur und die Größe des Parameters. Die Beschreibung kann auch Informationen dahingehend umfassen, ob ein Methodenaufruf (mit Instanzzeiger) oder ein Funktionsaufruf (ohne Instanzzeiger) vorliegt.

Im folgenden wird der generierte Code in weiteren Einzelheiten erläutert, um eine genaue Beschreibung für den im obigen Beispiel dargestellten Methodenaufruf zu geben. Es wird daraus ersichtlich, dass für jeden Parameter die entsprechenden Informationen wie Offset, Datentyp, Name, Richtung (in _dwFlags) und Größe (Teil von_ITypeDesc) mit abgelegt werden. Folgender Funktionsbaustein kann verwendet werden, um alle relevanten Informationen für einen Methodenaufruf zu speichern:

Für die Beispielmethode werden dabei im folgenden alle relevanten Informationen durch die Compiler-Einheit 40 erzeugt und dem Funktionsbaustein zugewiesen:

 T_TestRootObjectType_2169_ExampleComplexMethod._pszName :=
 ADR('ExampleComplexMethod') ;
 T_TestRootObjectType_2169_ExampleComplexMethod._dwSize := DWORD#60;
 T_TestRootObjectType_2169_ExampleComplexMethod._dwNativeSize := DWORD#60;
 T_TestRootObjectType_2169_ExampleComplexMethod._typeClass :=
 UINT_TO_INT(284);
 T_TestRootObjectType_2169_ExampleComplexMethod._iComponents := 6;
 T_TestRootObjectType_2169_ExampleComplexMethod._Components :=
   ADR(T_TestRootObjectType_2169_ExampleComplexMethod_ComponentsPtr);
 T_TestRootObjectType_2169_ExampleComplexMethod._SortedComponents :=
   ADR(T_TestRootObjectType_2169_ExampleComplexMethod_SortedComponentsPtr);
 T_TestRootObjectType_2169_ExampleComplexMethod_SortedComponentsPtr[0] :=
   ADR(T_TestRootObjectType_2169_ExampleComplexMethod_Components[5]);
 T_TestRootObjectType_2169_ExampleComplexMethod_SortedComponentsPtr[1] :=
   ADR(T_TestRootObjectType_2169_ExampleComplexMethod_Components[3]);
 T_TestRootObjectType_2169_ExampleComplexMethod_SortedComponentsPtr[2] :=
   ADR(T_TestRootObjectType_2169_ExampleComplexMethod_Components[2]);
 T_TestRootObjectType_2169_ExampleComplexMethod_SortedComponentsPtr[3] :=
   ADR(T_TestRootObjectType_2169_ExampleComplexMethod_Components[4]);
 T_TestRootObjectType_2169_ExampleComplexMethod_SortedComponentsPtr[4] :=
   ADR(T TestRootObjectType 2169 ExampleComplexMethod Components[0]);
 T_TestRootObjectType_2169_ExampleComplexMethod_SortedComponentsPtr[5] :=
   ADR(T_TestRootObjectType_2169_ExampleComplexMethod_Components[1]);
 T_TestRootObjectType_2169_ExampleComplexMethod._methodAdr :=
 ADR(SIGNATURE_2182_FPADDRESS);
 T_TestRootObjectType_2169_ExampleComplexMethod._setInstancePointer := TRUE;
 T_TestRootObjectType_2169_ExampleComplexMethod._definingSignature REF=
 ADR(T_TestRootObjectType_2169);
 T_TestRootObjectType_2169_ExampleComplexMethod._opcuaMetadata REF=
 ADR(_anonVar_12);
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[0]._pstName :=
 ADR('summand1'); 

 T_TestRootObjectType_2169_ExampleComplexMethod_Components[0]._ITypeDesc
 REF= ADR(T_DINT);
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[0]._dwFlags := 2;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[0]._pAddress :=
 DWORD#4;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[0]._clientOffset
 := DWORD#4;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[0]._accessRights
 := INT_TO_BYTE(3);
 T_TestRootObjectType_2169_ExampleComplexMethod_ComponentsPtr[0] :=
 ADR(T_TestRootObjectType_2169_ExampleComplexMethod_Components[0]);
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[1]._pstName :=
 ADR('summand2') ;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[1]._ITypeDesc
 REF= ADR(T_DINT);
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[1]._dwFlags := 2;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[1]._pAddress :=
 DWORD#8;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[1]._clientOffset
 := DWORD#8;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[1]._accessRights
 := INT_TO_BYTE(3);
 T_TestRootObjectType_2169_ExampleComplexMethod_ComponentsPtr[1] :=
 ADR(T_TestRootObjectType_2169_ExampleComplexMethod_Components[1]);
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[2]._pstName :=
 ADR('dutTest');
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[2]._ITypeDesc
 REF=
 ADR(T_DataTypeSimple_2198);
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[2]._dwFlags := 2;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[2]._pAddress :=
 DWORD#12;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[2]._clientOffset
 := DWORD#12;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[2]._accessRights
 := INT_TO_BYTE(3);
 T_TestRootObjectType_2169_ExampleComplexMethod_ComponentsPtr[2] :=
 ADR(T_TestRootObjectType_2169_ExampleComplexMethod_Components[2]);
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[3]._pstName :=
 ADR('aryTest');
 T_TestRootObjectType_2169_ExampleComplexMethod__Components[3]._ITypeDesc 

 REF= ADR(T_VLARY_2182_3);
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[3]._dwFlags := 2;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[3]._pAddress :=
 DWORD#20;
 T_TestRootObjectType_2169_ExampleComplexMethod__Components[3]._clientOffset
 := DWORD#20;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[3]._accessRights
 := INT_TO_BYTE(3);
 T_TestRootObjectType_2169_ExampleComplexMethod_ComponentsPtr[3] :=
 ADR(T_TestRootObjectType_2169_ExampleComplexMethod_Components[3]);
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[4]._pstName :=
 ADR('sum');
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[4]._ITypeDesc
 REF= ADR(T_DINT);
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[4]._dwFlags := 4;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[4]._pAddress :=
 DWORD#32;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[4]._clientOffset
 := DWORD#32;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[4]._accessRights
 := INT_TO_BYTE(3);
 T_TestRootObjectType_2169_ExampleComplexMethod_ComponentsPtr[4] :=
 ADR(T_TestRootObjectType_2169_ExampleComplexMethod_Components[4]);
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[5]._pstName :=
 ADR('aryOut');
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[5]._ITypeDesc
 REF=
 ADR(T_ARPAY_6_OF_T_DINT);
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[5]._dwFlags := 4;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[5]._pAddress :=
 DWORD#36;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[5]._clientOffset
 := DWORD#36;
 T_TestRootObjectType_2169_ExampleComplexMethod_Components[5]._accessRights
 := INT_TO_BYTE(3);
 T_TestRootObjectType_2169_ExampleComplexMethod_ComponentsPtr[5] :=
 ADR(T_TestRootObjectType_2169_ExampleComplexMethod_Components[5]);

Der vorstehend initialisierte Funktionsbaustein kann während der Übertragung der IEC-Applikation auf die speicherprogrammierbare Steuerungseinheit 16 dem Laufzeitsystem 22 bekannt gemacht werden. Über eine Schnittstelle im Laufzeitsystem 22 kann der OPC-UA-Server 26 diese Informationen abfragen und verwenden.

Zusätzlich zu den Informationen über den Aufbau der Parameterübergabe kann die Compiler-Einheit 40 beim Übersetzen eine Liste aus Beschreibungen für die Instanzen generieren, die aus den Typenbeschreibungen des Informationsmodells erzeugt wurden. Diese Liste kann beim Laden der Applikation auf die speicherprogrammierbare Steuerungseinheit 16 übertragen werden. Innerhalb der Liste können die Instanzen über eindeutige Instanzpfade gefunden werden. Die Beschreibung kann für jede Instanz einige weitere relevante Informationen enthalten, beispielsweise die Lage der Instanz innerhalb der IEC-Applikation (Offset), eine Liste aller möglichen Variablen und Methoden, welche zu diesem Objekt gehören, sowie für die unterschiedlichen Variablen und Methoden die passende Typbeschreibung, um die Werte lesen bzw. schreiben zu können oder Methoden aufrufen zu können.

(c) Durchführen des OPC-UA-Aufrufs durch den OPC-UA-Server

Im folgenden wird unter Bezugnahme auf 4 ein beispielhafter Ablauf des Methodenaufrufs durch den integrierten OPC-UA-Server 26 in weiteren Einzelheiten beschrieben.

Wie in 4 dargestellt ist, umfasst das Laufzeitsystem 22 neben dem OPC-UA-Server 26 eine Datenquelle 48 zur Anbindung des industriellen Steuerungsprogramms 20. In dieser Datenquelle 48 werden dem OPC-UA-Server 26 die verschiedenen Variablen und Methoden der IEC-Applikation dem OPC-UA-Server 26 zur Verfügung gestellt. Ein Dienst kann dabei gemäß OPC-UA stets aus einer Liste von gleichartigen Operationen (lesen von Variablen, Schreiben von Variablen usw.) bestehen. Der OPC-UA-Server 26 übernimmt eine vor Verarbeitung solcher Dienste. Dabei können auch weitergehende Prüfungen durchgeführt werden. Nach der Prüfung kann der OPC-UA-Server 26 jede dieser Operationen ausführen für diese unterschiedlichen Operationen wird dann jeweils die Datenquelle 48 aufgerufen. Der Aufruf erfolgt dabei über eine definierte Schnittstelle 50, welches ermöglicht, die Daten aus dem OPC-UA-Protokoll direkt an die Datenquelle 48 weiterzugeben.

Für den Methodenaufruf kann beispielsweise der Dienst Call der Servicegruppe Methode aus dem OPC-UA-Standard verwendet werden. Dieser kann entsprechend der vorangehenden Beschreibung vor verarbeitet werden da die Ausführungszeit von Methoden im allgemeinen nicht bekannt ist, werden die Operationen des Methodendienstes ggf. asynchron durchgeführt, um andere OPC-UA-Dienste in dieser Zeit nicht zu blockieren.

Die vorgenannten Schritte können sämtlich durch den OPC-UA-Server 26 durchgeführt werden. Die Implementierung innerhalb der Datenquelle 48 führt dann über die Schnittstelle 44 den konkreten Aufruf in das industrielle Steuerungsprogramms 20 durch. Dabei kann der vorangehend beschriebene Aufbau der Parameterübergabe verwendet werden.

Gemäß dem OPC-UA-Standard werden alle Elemente durch eindeutige Identifikatoren („NodeIDs“) identifiziert. Die Datenquelle 48 kann aus den Instanzfahrten eindeutige Identifikatoren bilden. Diese Identifikatoren können in Vorbereitung auf den Methodenaufruf über die Kommunikationsverbindung 28 an den OPC-UA-Client 30 übermittelt werden. Hierfür sieht der OPC-UA-Standard eigene Dienste vor. In einem ersten Schritt können die Datenquelle 48 die vom OPC-UA-Client 30 gesendete NodeID der aufgerufenen Methode und die NodeIDs des zugehörigen Objektes überprüfen. Dabei können anhand des Instanzfahrrades überprüft werden, dass diese Identifikatoren ein Element aus dem industriellen Steuerungsprogramms 20 repräsentieren und dass die Methode und das Objekt zusammengehören. Dadurch kann gegebenenfalls verhindert werden, dass eine Methode mit einer falschen Instanz aufgerufen wird.

Nachfolgend kann anhand der NodeID die genaue Methode aus dem industriellen Steuerungsprogramms 20 ermittelt werden und der Aufbau der Parameterübergabe abgefragt werden. In diesem Zusammenhang kann entsprechend der vorangehenden Beschreibung an die Datenquelle 48 eine Datenstruktur übergeben werden, in der alle notwendigen Informationen enthalten sind, um den Aufruf in das industrielle Steuerungsprogramms 20 durchzuführen.

Um den Aufruf vorzubereiten, kann in einem ersten Schritt die Datenstruktur für die Parameterübergabe aufgebaut werden. Dazu kann ein Speicher der entsprechenden Größe vom Heap-Speicher 42 alloziert werden. Auf diesen Speicherbereich können anschließend die Eingabeparameter anhand der Beschreibung übertragen werden. Bei diesem Vorgang kann für jeden einzelnen Parameter eine Konvertierung zwischen der OPC-UA-Repräsentation und der IEC-Repräsentation der Werte stattfinden, wie nachfolgend in Abschnitt (d) in weiteren Einzelheiten beschrieben werden wird. Nach der Konvertierung können die umgewandelten Daten an den passenden Offset des Speicherbereiches beschrieben werden. Zusätzlich kann überprüft werden, ob der Datentyp und der Arraytyp des vom OPC-UA-Client 30 übertragenen Parameters mit der IEC-Deklaration übereinstimmt. Falls sich ein Parameter nicht umwandeln lässt oder nicht korrekt übergeben wurde, kann der Methodenaufruf gegebenenfalls abgebrochen werden. Dabei kann ein entsprechender OPC-UA-Fehlercode für diesen Parameter generiert und in die Antwort an den OPC-UA-Client beschrieben werden.

Zusätzlich kann überprüft werden, dass die Parameter in der korrekten Reihenfolge übergeben werden und dass die Anzahl der Parameter übereinstimmt. Falls dies nicht der Fall ist, kann der Aufruf ebenfalls abgebrochen und ein passender OPC-UA-Fehlercode über die Antwort an den OPC-UA-Client 30 übermittelt werden.

Sobald die vorgenannten Schritte für jeden der Parameter abgearbeitet wurden, liegt in dem Speicherbereich eine Datenstruktur vor, welche genau der Aufrufkonvention innerhalb der IEC-Applikation entspricht.

Über den aus der NodeID ermittelten Pfad kann nun die korrekte Instanzbeschreibung aus der Liste ausgewählt werden. Mit dieser Beschreibung kann über die Schnittstelle 44 in einem ersten Schritt eine Zwischenschicht 52 aufgerufen werden, die Teil der IEC-Applikation ist und Informationen über Instanzen und Methoden enthält. Innerhalb dieser Zwischenschicht 52 können beispielsweise Plausibilitäts- und Rechteprüfungen stattfinden. Der erzeugte Speicherblock mit den Parametern kann hier ebenfalls übergeben werden. Dabei kann auch die Größe der Parameter überprüft, die eigentlich Adresse der Methode ermittelt und auch der Instanzzeiger mithilfe des Offsets aus der Instanzbeschreibung ermittelt werden. Dafür können die Informationen aus der generierten Liste verwendet werden. In einem weiteren Schritt kann der Instanzzeiger an die korrekte Stelle innerhalb der Parameter kopiert werden damit sind alle Informationen in dem Speicherblock vorhanden, die auch ein IEC-Compiler auf den Steck kopieren würde. Das Layout ist insoweit identisch.

In einem nächsten Schritt kann der eigentliche Aufruf der Methode in die Programmlogik 54 der speicherprogrammierbaren Steuerungseinheit 16 über die entsprechende Funktion SysCpuCallecFuncWithParams aus dem Laufzeitsystem 22 heraus erfolgen. Diese Funktion kann den Funktionsaufruf nachbilden, wie ihn auch der vom Compiler erzeugte Code durchführt. Vor dem Kopieren der Parameter auf den Stack kann entsprechend Platz auf dem Stack geschaffen werden. Danach kann der vorbereitete Speicherblock für die Parameterübergabe auf den Stack kopiert und der Sprung an die Codeadresse der Methode ausgeführt werden. Für die aufgerufene Methode macht es dabei keinen Unterschied, ob der Aufruf aus dem generierten Code erfolgt oder aus dem OPC-UA-Server 26.

Nach dem Parameteraufruf kann der gesamte Parameterblock vom Stackspeichers 46 wieder zurück auf den dynamischen Speicher 42 kopiert werden. Auf diese Weise können die Ausgabeparameter an den Aufrufer zurückgegeben werden. Anschließend können die Rücksprünge in alle zuvor aufgerufenen Schichten, beispielsweise die IEC-Zwischenebene 52 und die Datenquelle 48, erfolgen.

In einer Beispielimplementierung kann der Code der Aufruffunktion SysCpuCallecFuncWithParams folgendermaßen ausgebildet sein:

 RTS_RESULT CDECL SysCpuCallIecFuncWithParams(RTS_VOID_FCTPTR pfIECFunc,
 void* pParam, int iSize)
 {
     void *pStack = NULL;
     int iStackSize;
     int iCounter; 

     /* parameter check */
     if (pfIECFunc == NULL)
     {
            return ERR_PARAMETER;
     }
     if (pParam == NULL && iSize != 0)
     {
            return ERR_PARAMETER;
     } 

     /* calculate alligned stack size */
     iStackSize = (iSize + 3) & 0xFFFFFFFC;
     /* move stackpointer by the calculated size to have space for the
     parameters */
     _asm sub esp,iStackSize
     _asm mov pStack, esp 

     if (pStack == NULL)
     {
            return ERR_FAILED;
     } 

     /* copy parameters to the stack */
     /* In almost cases pParam and iSize are alligned, so simply a DWORD
     copy is used. For the remaining cases a BYTE copy is applied.
     On X86 only iSize have to be checked, because the alignment does not
     matter. */ 

     iCounter = 0;
     if (iStackSize == iSize)
     {
            /* DWORD copy */
            int iDwordSize = iSize / 4;
            while (iCounter < iDwordSize)
            {
                   /*lint -e613 */ ((unsigned long*)pStack)[iCounter] =
                    ((unsigned long*)pParam)[iCounter];
                   iCounter++;
            }
     }
     else
     {
            /* BYTE copy */
            while (iCounter < iSize)
            {
                   /*lint -e613 */ ((unsigned char*)pStack)[iCounter] =
                    ((unsigned char*)pParam)[iCounter];
                   iCounter++;
            }
     }
     /* call IecCode */
     _asm call pfIECFunc 

     /* copy returned parameters from the stack to pParam */
     /* In almost cases pParam and iSize are alligned, so simply a DWORD
     copy is used. For the remaining cases a BYTE copy is applied.
     On X86 only iSize have to be checked, because the alignment does not
     matter. */
     iCounter = 0;
     if (iStackSize == iSize)
     {
            /* DWORD copy */
            int iDwordSize = iSize / 4;
            while (iCounter < iDwordSize)
            {
                   /*lint -e613 */ ((unsigned long*)pParam)[iCounter] =
                    ((unsigned long*) pStack)[iCounter]; 
                   iCounter++;
            }
     }
     else
     {
            /* BYTE copy */
            while (iCounter < iSize)
            {
                   /*lint -e613 */ ((unsigned char*)pParam)[iCounter] =
                    ((unsigned char*)pStack)[iCounter];
                   iCounter++;
            }
     }
     /* restore the old stackpointer to remove the parameters from the stack
     */
     _asm add esp,iStackSize
     return ERR_OK;
     }

Nach dem Rücksprung in die Datenquelle 48 können die Ergebnisse ausgewertet werden. War der Aufruf erfolgreich und nicht durch fehlende Zugriffsrechte blockiert, können die Ausgabeparameter von der IEC-Repräsentation in das OPC-UA-Format konvertiert und in die entsprechenden Felder für die Operation des OPC-UA-Call-Dienstes geschrieben werden. Damit ist die Arbeit der Datenquelle 48 beendet. Es erfolgte Rückkehr zum OPC-UA-Server 26, der die Operationen in eine entsprechende Dienst Antwort bündeln und an den OPC-UA-Client 30 zurücksenden kann.

Da der OPC-UA-Server 26 in dem selben Adressraum wie das industrielle Steuerungsprogramm 20 abläuft, sind die vorangehend beschriebenen direkten Sprünge möglich. Ferner lassen sich dadurch Methoden zur Fehleranalyse in gleicher Weise nutzen, wie sie innerhalb der IEC-Applikation zur Verfügung stehen.

(d) Parameterumwandlung zwischen OPC-UA und IEC

Die vorangehend beschriebene Parameterumwandlung zwischen den Standards OPC-UA und IEC kann in wesentlichen Teilen der OPC-UA-Spezifikation „OPC UA for Programmable Logic Controllers based on IEC 61131-3“ folgen. An einigen Stellen können herstellerspezifische Umwandlungen vorteilhaft sein.

Die Umwandlung kann dabei nach folgenden Grundsätzen erfolgen:

1. Umwandlung einfacher Datentypen
1. a. Binärrepräsentation ist identisch. Je nach System findet ein Swap statt.
2. Umwandlung von Zeitdatentypen
1. a. Die Zeitbasis zwischen OPC UA und IEC ist unterschiedlich. Angleichen der Zeitbasis und eventuell Swap.
3. Umwandlung von Zeichenketten (OPC UA UTF-8, IEC ASCII oder UTF-16)
1. a. IEC String: Lesen: Zeichen, die außerhalb des ASCII Bereiches liegen, werden durch ein „?“ ersetzt. Schreiben: Kommen UTF-8 Codepoints vor, die mehr als ein Byte benötigen, wird das Schreiben abgelehnt.
2. b. IEC WSTRING: Konvertierung zwischen UTF-8 und UTF-16 verlustfrei möglich. String wird je nach Richtung (Lesen / Schreiben) passend umgewandelt.
4. OPC UA Datentypen (NodeID, LocalizedText usw.)
1. a. Lesen: Die Daten werden direkt serialisiert.
2. b. Schreiben: Die Empfangen Daten werden als Shallow Copy direkt kopiert. Nur bei Methodenaufruf gültig.
5. Strukturen:
1. a. Es wird elementweise anhand der oben angegebenen Regel konvertiert.
2. b. Die Entsprechenden Werte werden von den gegebenen Offsets gelesen bzw. dorthin geschrieben.
6. Array:
1. a. Einfache Datentypen + Vollzugriff
  1. i. Es wird direkt gelesen + geschrieben.
2. b. OPC-UA-Datentypen:
  1. i. Lesen: Es findet eine elementweise Umwandlung der Elemente statt.
  2. ii. Schreiben: komplettes Array. Es wird eine Shallow Copy des UA-Arrays gemacht.
3. c. alle anderen Fälle
  1. i. Es findet eine elementweise Konvertierung anhand der Parameterumwandlung statt.
7. Arrays und Strukturen können ineinander geschachtelt vorkommen. Das wird über eine entsprechende Beschreibung abgebildet.

(e) Synchronisierung der Methodenaufrufe zur Steuerungsapplikation

Damit den vorangehend beschriebenen Techniken die Parameter des Methodenaufrufs unmittelbar auf dem Stackspeicher 46 übergeben werden können, ist im Unterschied zum Stand der Technik eine Synchronisierung der Methodenaufrufe mit dem Ablauf des industriellen Steuerungsprogramms 20 nicht erforderlich. Darin liegt einer der Vorteile der offenbarungsgemäßen Lösung. Dennoch kann eine Synchronisierung auch im Rahmen der vorliegenden Offenbarung für manche Anwendungen vorteilhaft sein, beispielsweise um den Einfluss des Methodenaufrufs auf das Echtzeitverhalten der speicherprogrammierbaren Steuerungseinheit 16 gering zu halten.

Zu diesem Zweck können beispielsweise für die Methodenaufrufe bewusst ein Zeitpunkt gewählt werden, zudem keine Steuerungs-Task aktiv ist (sogenannte Austastlücke), wie nachfolgend in weiteren Einzelheiten beschrieben ist.

In vielen praktisch relevanten Anwendungen ist der Programmcode des industriellen Steuerungsprogramms 20 durch Vorgaben, die der Programmierer bereits in der Programmierumgebung 32 vornimmt, in Tasks aufgeteilt. Jede solche Task kann die Programme (POUs) umfassen, welche ausgeführt werden sollen. Zusätzlich kann jede Task eine bestimmte Zyklus Zeit umfassen, mit der die entsprechenden Programme aufgerufen werden sollen. Zusätzlich kann für die entsprechenden Tasks auch eine jeweilige Priorität vergeben werden. Während des Programmdownloads auf die speicherprogrammierbaren Steuerungseinheit 16, welche das Laufzeitsystem 22 umfasst, werden die Tasks dann durch das Laufzeitsystem 22 angelegt und entsprechende Ressourcen bereitgestellt.

Wie in den 2 und 4 gezeigt ist, kann das Laufzeitsystem 22 zudem eine Scheduler-Einheit 56 umfassen, welche diese Tasks anhand ihrer zugeordneten Zykluszeit und ggf. Priorität startet oder anhält. Beispielsweise kann die Scheduler-Einheit 56 erkennen, wenn keine der erzeugten Tasks Code ausführt. In einer solchen Situation befindet sich die speicherprogrammierbaren Steuerungseinheit 16 im Leerlauf. In einer solchen Lücke zwischen den Tasks kann die Scheduler-Einheit 56 den Methodenaufruf schieben und dort ausführen.

In einer Weiterbildung kann die Scheduler-Einheit 56 eine solche Lücke und damit einen geeigneten Zeitpunkt für den Methodenaufruf auch bereits im Voraus erkennen, insbesondere in Zusammenhang mit einem deterministischen Scheduling, wie es echtzeitfähige Betriebssysteme (zum Beispiel Linux mit RT Patch, VxWorks) ermöglichen.

Mit diesen Techniken wird es möglich, den OPC-UA-Methodenaufruf zu einem Zeitpunkt auszuführen bzw. auf einen Zeitpunkt zu verschieben, zudem nach Möglichkeit kein anderer IC-Code ausgeführt wird. Damit ist der Methodenaufruf ohne oder nur mit minimalen Nebenwirkungen auf die Laufzeit des industriellen Steuerungsprogramms 20 möglich.

In einer alternativen Ausgestaltung können die Methodenaufrufe in die Slots nach dem eigentlichen IC-Code geschoben werden.

IO-Treiber werden typischerweise verwendet, um die Eingänge und Ausgänge der speicherprogrammierbaren Steuerungseinheit 16 innerhalb der IEC-Applikation zur Verfügung zu stellen. Da eine speicherprogrammierbaren Steuerungseinheit 16 üblicherweise nach der Vorgehensweise Eingabe - Verarbeitung - Ausgabe arbeitet, werden die IO-Treiber üblicherweise vor bzw. nach dem eigentlichen Programmaufruf aufgerufen. Daher ist es möglich, die Eingänge vor der Verarbeitung zu lesen und die Ausgänge nach der Verarbeitung zu schreiben. Die OPC-UA-Methodenaufrufe können auf dieselbe Weise ausgeführt werden. Dazu kann der Programmierer eine Task definieren, in welcher die Aufrufe durchgeführt werden sollen.

Ein Vorteil dieser Variante liegt darin, dass der OPC-UA-Methodenaufruf innerhalb einer Task ausgeführt wird und damit auch in die Lastberechnung der speicherprogrammierbaren Steuerungseinheit 16 eingeht der Programmierer hat den zusätzlichen Vorteil, dass er die Tasks für die Methodenaufrufe selbst definieren kann.

Die vorangehend beschriebenen Ausführungsformen und die Zeichnungen dienen lediglich der Erläuterung der offenbarungsgemäßen Lösung und der mit der offenbarungsgemäßen Lösung erzielbaren Vorteile, sollen die Offenbarung aber nicht beschränken. Der Schutzumfang ergibt sich aus den anliegenden Ansprüchen.

Bezugszeichenliste

10: industrielle Steuerungsumgebung
12: Portalkran
14: Hakenbaugruppe
16: speicherprogrammierbare Steuerungseinheit (SPS)
18: Steuerleitung
20: industrielles Steuerungsprogramm
22: Laufzeitsystem
24: Kommunikationsschnittstelle
26: OPC-UA-Server
28: Kommunikationsverbindung
30: OPC-UA-Client
32: Programmierumgebung
34: Programmierschnittstelle
36: Programmierspeichereinheit
38: Programmierprozessoreinheit
40: Compiler-Einheit
42: Speicherelement; dynamischer Speicher, Heap-Speicher
44: Schnittstelle zum industriellen Steuerungsprogramm 20
46: Stackspeicher
48: Datenquelle
50: Schnittstelle zur Datenquelle 48
52: Zwischenschicht mit Informationen über Instanzen und Methoden
54: Programmlogik der SPS 16 und zugehörige Daten
56: Scheduler-Einheit

ZITATE ENTHALTEN IN DER BESCHREIBUNG

Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.

Zitierte Patentliteratur

EP 3182235 B1 [0006, 0007, 0008]
WO 2021/038028 A1 [0006, 0007, 0008]

Claims

Verfahren zum Aufrufen einer Methode eines industriellen Steuerungsprogramms (20) einer speicherprogrammierbaren Steuerung (16), wobei die speicherprogrammierbare Steuerung (16) ein Laufzeitsystem (22) mit einem OPC-UA-Server (26) umfasst, der dazu eingerichtet ist, mit einem OPC-UA-Client (30) über eine Kommunikationsverbindung (28) gekoppelt zu werden, und wobei die speicherprogrammierbare Steuerung (16) ferner das industrielle Steuerungsprogramm (20) umfasst, wobei das Verfahren umfasst: Empfangen eines auf die Methode gerichteten Methodenaufrufs von dem OPC-UA-Client (30) an dem OPC-UA-Server (26); und Aufrufen der Methode in dem industriellen Steuerungsprogramm (20) aus dem Laufzeitsystem (22) heraus in Reaktion auf den empfangenen Methodenaufruf.
Verfahren nach Anspruch 1, bei dem das Laufzeitsystem (22) ein Speicherelement (42; 46; 48) umfasst und der empfangene Methodenaufruf mindestens einen Eingabeparameter und/oder mindestens einen Ausgabeparameter umfasst, wobei dem Eingabeparameter und/oder dem Ausgabeparameter eine Speicheradresse in dem Speicherelement (42; 46; 48) zugeordnet sind.
Verfahren nach Anspruch 2, bei dem die Speicheradressen beim Kompilieren des industriellen Steuerungsprogramms (20) vergeben werden.
Verfahren nach Anspruch 2 oder 3, bei dem das Aufrufen der Methode in dem industriellen Steuerungsprogramm (20) aus dem Laufzeitsystem (22) heraus ein Übergeben des Eingabeparameters und/oder des Ausgabeparameters aus dem Speicherelement (42; 46; 48) bzw. der zugeordneten Speicheradressen an das industrielle Steuerungsprogramm (20) umfasst.
Verfahren nach einem der Ansprüche 2 bis 4, umfassend ein Empfangen eines Wertes des mindestens einen Ausgabeparameters von dem industriellen Steuerungsprogramm (20) an der dem Ausgabeparameter zugeordneten Speicheradresse des Speicherelements (42; 46; 48).
Verfahren nach Anspruch 5 mit zusätzlich einem Übergeben des empfangenen Werts des mindestens einen Ausgabeparameters von dem Speicherelement (42; 46; 48) mittels des OPC-UA-Servers (26) an den OPC-UA-Client (30).
Verfahren nach einem der vorangehenden Ansprüche, bei dem das Aufrufen der Methode nicht aus dem industriellen Steuerungsprogramm (20) heraus erfolgt.
Verfahren nach einem der vorangehenden Ansprüche, umfassend ein Bestimmen eines Zeitpunkts für das Aufrufen der Methode in dem industriellen Steuerungsprogramm (20) aus dem Laufzeitsystem (22).
Rechnerlesbares Programm mit rechnerlesbaren Instruktionen, wobei die rechnerlesbaren Instruktionen dazu eingerichtet sind, beim Ablaufen auf einem Rechnersystem, insbesondere auf einer speicherprogrammierbaren Steuerung (16), ein Verfahren nach einem der vorangehenden Ansprüche zu implementieren.
Speicherprogrammierbare Steuerung (16), welche ein Laufzeitsystem (22) mit einem OPC-UA-Server (26) umfasst, der dazu eingerichtet ist, mit einem OPC-UA-Client (30) über eine Kommunikationsverbindung (28) gekoppelt zu werden, wobei die speicherprogrammierbare Steuerung (16) ferner dazu eingerichtet ist, ein industrielles Steuerungsprogramm (20) auszuführen, wobei der OPC-UA-Server (26) dazu eingerichtet ist, einen auf eine Methode des industriellen Steuerungsprogramms (20) gerichteten Methodenaufrufs von dem OPC-UA-Client (31) zu empfangen; und wobei das Laufzeitsystem (22) dazu eingerichtet ist, die Methode in dem industriellen Steuerungsprogramm (20) aus dem Laufzeitsystem (22) heraus in Reaktion auf den empfangenen Methodenaufruf aufzurufen.
Speicherprogrammierbare Steuerung (16) nach Anspruch 10, bei der das Laufzeitsystem (22) ein Speicherelement (42; 46; 48) umfasst und der empfangene Methodenaufruf mindestens einen Eingabeparameter und/oder mindestens einen Ausgabeparameter umfasst, wobei dem Eingabeparameter und/oder dem Ausgabeparameter eine Speicheradresse in dem Speicherelement (42; 46; 48) zugeordnet sind.
Speicherprogrammierbare Steuerung (16) nach Anspruch 11, bei der das Laufzeitsystem (22) dazu eingerichtet ist, den Eingabeparameter und/oder den Ausgabeparameter aus dem Speicherelement (42; 46; 48) bzw. die zugeordneten Speicheradressen in Zusammenhang mit dem Aufrufen der Methode in dem industriellen Steuerungsprogramm (20) aus dem Laufzeitsystem (22) heraus an das industrielle Steuerungsprogramm (20) zu übergeben.
Speicherprogrammierbare Steuerung (16) nach Anspruch 11 oder 12, bei der das Laufzeitsystem (22) dazu eingerichtet ist, einen Wert des mindestens einen Ausgabeparameters von dem industriellen Steuerungsprogramm (20) an der dem Ausgabeparameter zugeordneten Speicheradresse des Speicherelements (42; 46; 48) zu empfangen.
Speicherprogrammierbare Steuerung (16) nach Anspruch 13, bei der das Laufzeitsystem (22), insbesondere der OPC-UA-Server (26), dazu eingerichtet ist, den empfangenen Wert des mindestens einen Ausgabeparameter von dem Speicherelement (42; 46; 48) an den OPC-UA-Client (30) zu übergeben.
Speicherprogrammierbare Steuerung (16) nach einem der Ansprüche 10 bis 14, umfassend eine Scheduler-Einheit (56), welche dazu eingerichtet ist, einen Zeitpunkt für das Aufrufen der Methode in dem industriellen Steuerungsprogramm (20) aus dem Laufzeitsystem (22) zu bestimmen.