Suchen

SPS Zwei Sprachen wetteifern um die Steuerungs-Programmierung

| Autor/ Redakteur: Robert Wilmes / Alexander Strutzke

In der Automatisierungstechnik haben sich zwei Ansätze zur Programmierung etabliert, die kaum unterschiedlicher sein können: Programmierung nach IEC 61131-3 sowie Programmierung in Hochsprache. Zwar wachsen beide Welten immer stärker zusammen, aber für eine vollständige Integration gibt es noch zahlreiche Herausforderungen.

Firmen zum Thema

SPS-Programmierung sollte nach IEC 61131-3 und in einer Hochsprache möglich sein. Bild: Phoenix Contact
SPS-Programmierung sollte nach IEC 61131-3 und in einer Hochsprache möglich sein. Bild: Phoenix Contact
( Archiv: Vogel Business Media )

In der IT-Welt wie auch in der Automatisierungstechnik kam die Hochsprache mit der Rechenmaschine auf den Plan. Schon früh sind aus der hardwarenahen und stackorientierten Assembler-Programmierung zahlreiche Programmiersprachen hervorgegangen. Nicht alle entstandenen Hochsprachen konnten sich dauerhaft etablieren, Fortran oder Pascal zum Beispiel nutzt heute kaum noch jemand. Die neueren Ansätze heißen C++, C#, Visual Basic, Delphi oder Java.

Dabei hat es im Laufe der Zeit unterschiedliche Trends gegeben: Objektorientierung, Client-Server-Technik oder serviceorientierte Technik sind nur einige. Die auf der Basis von IEC 61131-3 definierten Sprachen blicken auf eine andere Geschichte zurück. Erste rechnergestützte Automatisierungs-Systeme hatten die Aufgabe einer einfachen bitorientierten Verknüpfung.

Erste rechnergestützte Automatisierungs-Systeme basierten auf IEC-61131-3-Programmierung

Außer der hardwarenahen Assembler-Programmierung erfolgte bei Systemen amerikanischer Anbieter die Programmierung – wie in der Hochsprache – über einen Kontaktplan, den jeder Elektroniker lesen kann. Damit waren bereits die ersten beiden Sprachen AWL (Anweisungsliste) und KOP (Kontaktplan) definiert.

Für Abläufe mit verschiedenen Zuständen kam die grafische Ablaufsprache (AS) hinzu. Für komplexere Vorgänge, wie Regelungen, gab es noch die grafische Funktionsbausteinsprache (FBS) sowie eine Hochsprache nach dem Muster von Pascal – den Strukturierten Text (ST).

Programmiersprache definiert viele Funktionen der SPS jenseits einfacher Bit-Verknüpfungen

Dabei definiert die Sprache auch viele Funktionen, die über eine einfache Bit-Verknüpfung hinausgehen. Timer-Bausteine gehören ebenso zum Standardumfang wie trigonometrische Funktionen. Auch eine einfache Form der Objektorientierung mit Instanzen sowie globalen und lokalen Variablen ist definiert. Außerdem gibt es Ressourcen, Tasks, Programme und Funktionen. Diese Entwicklung wurde maßgeblich durch den Endanwender geprägt. Oberstes Ziel war die Kompatibilität der Applikationen, Wildwuchs unter den Herstellern der Steuerungen sollte verhindert werden.

Bei der IEC 61131 handelt es sich um eine reine Automatisierungsnorm, die aus vielen Ansätzen das Beste nutzen möchte. Davon sollte auch der Anwender profitieren, der nicht über spezifische Programmierkenntnisse verfügt. Die Hochsprache ist dagegen anspruchsvoller und flexibler. Prinzipiell kann jede Aufgabe mit jedem der beiden Ansätze gelöst werden. Wie praktikabel und effizient die Lösung dann aber wird, hängt vom Programmierer und der zu lösenden Aufgabe ab. Denn beide Ansätze weisen deutliche Vor- und Nachteile auf.

Funktionsbausteine reduzieren Komplexität der SPS-Programmierung

Bei der SPS-Programmierung hat sich die IEC 61131-3 durchgesetzt. Die installierte Basis der Steuerungen ist groß, und geschulte Programmierer sind genügend vorhanden. Diese Methode liegt dem Automatisierer oft näher – gleiches gilt für den Techniker und den Maschinenbediener.

Zum Datenaustausch mit anderen Systemen wie Feldgeräten oder Leitsystemen haben sich fertige Funktionsbausteine etabliert, die die Komplexität erheblich reduzieren. Mit dem Strukturierten Text können auch Arrays und Strukturen auf einfache Weise integriert werden. Ein einfacher EA-Zugriff über EA-Adressen oder in zeitgemäßen Systemen über Signalnamen ist spezifiziert. Der Datenaustausch mit Leit- und Visualisierungssystemen erfolgt meistens über OPC-Server, die auf die SPS abgestimmt sind. Damit kann man eine beliebige Visualisierung einsetzen. Alle Informationen müssen aber über diese Schnittstelle abgebildet werden.

Hochsprachen-Programmierung macht Steuerungen flexibler

Dagegen bietet die Hochsprachen-Programmierung eine hohe Flexibilität – besonders bei der Programmierung von Kommunikationsfunktionen über TCP/IP und bei komplexen Regelungsaufgaben. Allerdings muss sich der Hochsprachen-Programmierer um Treiber, Kommunikation und Betriebssystem-Eigenschaften selbst kümmern. Dazu ist mehr Know-how erforderlich.

Bild 1: IEC 61131-3 und Hochsprache ergänzen sich oft. Eine gegenseitige Integration würde die Vorteile beider Systeme vereinen. (Archiv: Vogel Business Media)

Von Vorteil ist, dass auf ein weites Spektrum an Programm-Quelltexten und Beispielprogrammen zurückgegriffen werden kann. Bei Spezialfunktionen ist man nicht auf den IEC-Funktionsumfang beschränkt. Objektorientierung, Pointer, Strukturen und Arrays gehören zum Standard.

Wie sieht die Zukunft der beiden Ansätzen aus?

Beide Ansätze dienen dem selben Zweck: eine Aufgabe schneller, besser und kostengünstiger zu erledigen. In der Automatisierungstechnik wandert immer mehr Intelligenz ins Feld. Die Steuerungsplattformen werden leistungsfähiger, sodass dort immer mehr Funktionen abgearbeitet werden können. Datenbankzugriffe und andere Kommunikationswege nehmen damit an Bedeutung zu.

Auch künftig wird es Bereiche geben, für die IEC 61131-3 gut ausgerichtet ist – in diese Bereiche wird die Hochsprache nicht so leicht eindringen können. Auf der anderen Seite gibt es Applikationen, die aus systembedingten Gründen besser in Hochsprache gelöst werden: Flexibilität, Leistungsfähigkeit und Schutz von Know-how sind die Hauptgründe.

Automatisierung wird IEC 61131-3 und Hochsprache vereinen

So spricht einiges dafür, dass beide Welten zusammenwachsen können und werden und dass das Beste aus beiden Ansätzen gemeinsam für eine Anwendung genutzt werden kann.Die IEC 61131-3 konzentriert sich auf die feldnahe Maschinenkontrolle während die Hochsprache die Datenaufbereitung, Verdichtung und die Kopplung zu Leitsystemen und Datenbanken übernimmt. Prozesse, die zur Zeit außerhalb der Steuerung – zum Beispiel auf einem Anlagen-PC – realisiert werden, wandern dann in die Steuerung.

Dennoch existieren heute zahlreiche Herausforderungen im Hinblick auf die Integration von Hochsprache oder IEC 61131-3:

  • Die Einbindung von C-Funktionen in die IEC 61131-3 ist heute Stand der Technik – umgekehrt gilt das noch nicht.
  • IEC 61131 nutzt OPC als Lösung zur Datenankopplung – Hochsprachen-Programmierer müssen das selbst lösen. Ein OPC-Server für beide Welten wäre sinnvoll.
  • EA-Zugriffe sind in der IEC 61131-3 festgelegt. Bei der Hochsprache gibt es nur herstellerspezifische Treiber-Schnittstellen. Künftig muss auf EA-Daten über Echtzeit-Ethernet wie Profinet und Feldbussysteme wie Interbus von beiden Seiten gleichzeitig zugegriffen werden können.
  • Die Synchronisation beider Prozesse sowie ein effizienter Datenaustausch ist nicht spezifiziert. Beide Programmteile müssen besser gekoppelt werden.
  • Für die Programmierung in IEC 61131-3 und Hochsprache werden zwei verschiedene Werkzeuge benötigt. Programm-Download und Fehlersuche (Debugger) sollten aus einer Hand kommen.

Gegenseitige Integration bietet Innovationspotenzial für Steuerungen

Der Prozess in Richtung gegenseitige Integration ist in vollem Gange. Die Hardware-Plattformen sind vorhanden, und Betriebssysteme wie Windows CE, für die es IEC-61131-3-Laufzeitsysteme und Hochsprachen-Compiler gibt, drängen in die Steuerungswelt. OPC setzt mit OPC UA (Unified Architecture) eine neue und flexible Spezifikation, die direkt auf der Steuerung laufen kann. In dieser beschriebenen durchgängigen Kombination – Hochsprache und IEC 61131-3 – liegt ein hohes Innovationspotenzial.

Ein Beispiel für eine Hardware-Familie, die entweder mit IEC 61131-3 oder in Hochsprache programmiert werden kann, sind die Control Panels von Phoenix Contact (Bild 3). Der Prozessor aus der Xscale-Familie und das Betriebssystem Windows CE 5.0 sind in allen Control Panels dieser Familie gleich. Die berührungssensitiven 10-Zoll-TFT-Bildschirme sind ebenfalls gleich.

Bild 3: Die Control Panels von Phoenix Contact können sowohl mit IEC 61131-3 als auch in Hochsprache programmiert werden. Bilder: Phoenix Contact (Archiv: Vogel Business Media)

Das CP 310 ETH wird mit der IEC-61131-3-kompatiblen Programmierumgebung PC Worx programmiert und kann EA-Daten über Interbus austauschen. Eine Visualisierung ist bereits vorhanden. Bei dieser Variante sind – wie bei einer handelsüblichen SPS – noch Schlüsselschalter und Fronttasten integriert. Auf dem CP 310T HLC ETH IB können beliebige Hochsprachen-Programme ablaufen, die mit Microsoft Visual Studio Professional 2005 kompiliert wurden. EA-Daten können über Ethernet und Interbus eingebunden werden.

Die IEC-61131-3-Variante dient einem Anwenderkreis, der eine abgestimmte Einheit aus Hardware und Software sucht, um sich möglichst wenig mit der Technik auseinanderzusetzen. Die Hochsprachen-Variante richtet sich an Kunden, die ihr Know-how möglichst flexibel auf eine langfristig verfügbare Steuerungsplattform bringen wollen. Beide Varianten sind Bestandteil des IT-powered-Automation-Konzepts von Phoenix Contact. Durch die einfachere Integration aller Komponenten und Systeme in das Automatisierungs- und Unternehmensnetzwerk lässt sich die Produktivität erheblich steigern.

Dipl.-Ing. Robert Wilmes ist Mitarbeiter der Business Unit Automation Systems bei der Phoenix Contact Electronics GmbH in Bad Pyrmont.

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de (ID: 236874)