Im Umfeld der Fernwirktechnik kommen beispielsweise Steuerungen des Wago-I/O-Systems zur Überwachung von mechatronischen Einheiten oder als Gateway zu anderen Feldbussen wie Profibus zum Einsatz. Für die Erweiterung des Portfolios um eine IEC-61850-Lösung wurde die Implementierung eines IEC-61850-Servers in verschiedene Wago- Steuerungen evaluiert, welche dann mit dem in der Leittechnik enthaltenen Client kommunizieren. Nachfolgende Ausführungen beschreiben die Portierung der unter Codesys V2.3 - der IEC-61131- Programmierumgebung des Herstellers 3S Smart Software Solutions - erstellten klassisch prozeduralen Lösung für das Wago-I/O-System Serie 750 hin zu einer unter Codesys V3 erstellten objektorientierten Lösung für das dezentrale Speedway-IO-System.

Modell eines intelligenten elektronischen Gerätes (IED) gemäß IEC 61850: Die Grafik stellt die Projektion von realen Anlagenteilen auf das Software- Objekt und den Datentransport über das Ethernet-Netzwerk dar.

© Bild: Wago

Der Standard 61850 definiert im Wesentlichen ein objektorientiertes Datenmodell sowie Aktionen auf das Datenmodell und das Kommunikationsmodell. Im Datenmodell sind „Logical Name Classes" (92 verschiedene LNCs) definiert, welche ihrerseits wieder „Common Data Classes" enthalten. Diese „Common Data Classes" (29 verschiedene CDCs) enthalten letztendlich Attribute (zehn verschiedene CDA) wie etwa Zeichenketten, ganze Zahlen oder Gleitkommma-Zahlen. Aktionen auf das Datenmodel sind beispielsweise „Gerät identifizieren", „Datenmodel auslesen", „Daten lesen" oder „Daten schreiben". Als mögliche Kommunikationsmodelle für die IEC 61850 sind schließlich MMS, Web-Services oder OPC-UA denkbar. Umgesetzt und verfügbar ist bis dato allerdings erst MMS als Kommunikationsmodell. MMS steht für „Manufacturing Message Specification" und ist als Protokoll im Standard ISO 9506 definiert.

In Codesys V2.3 ist eine Umsetzung sowohl klassisch prozedural als auch „eingeschränkt objektorientiert" möglich. Bei dem klassisch prozeduralen Ansatz kann die Trennung von Daten und Funktion erfolgen, indem für alle LNCs strukturierte Datentypen erstellt werden. Funktionen können dann auf die Datentypen zugreifen und diese manipulieren. Eine eingeschränkt objektorientierte Lösung ist mit dem Ansatz der Funktionsbausteine realisierbar. Dabei sind die strukturierten Daten der Logical Node Classes im Funktionsbaustein gekapselt und lassen sich über den Aufruf des Funktionsbausteins oder den Aufruf einer Aktion auf dem Funktionsbaustein bearbeiten.

Die Schwächen der Codesys-Version 2.3

Eine Schwäche der Codesys-Version 2.3 ist hierbei, dass Aktionen keine IN_OUT-Parameter (call by reference) übergeben werden können und Aktionen auch über keine lokalen Variablen verfügen. Zwar lässt sich die fehlende Möglichkeit, IN_OUT-Parameter zu übergeben, durch die Übergabe eines Pointers umgehen; es gibt jedoch Applikationsingenieure, die Pointer generell vermeiden. Auch gibt es Firmen beziehungsweise Projekte, in deren Codierrichtlinien die Verwendung von Pointern untersagt ist. In der Version 3 von Codesys hat 3S die genannten Schwächen mit der Spracherweiterung „Methode" abgestellt. Methoden erweitern das Konzept von Aktionen dahingehend, dass sie auch lokale Variable enthalten können und es möglich ist, IN_OUT-Parameter zu übergeben.

Ein vom Anwender mit der „Wago-61850-Codesys-Bibliothek" erstelltes SPS-Programm verwendet typischerweise mehrere Objekte verschiedener Logical Node Classes. Dazu ist innerhalb der 61850-Bibliothek eine Iteration über die Instanzen der verschiedenen Logical Node Classes erforderlich. Ein Vorgang, der in Codesys V2.3 ebenfalls aufwendig mit einem Array von Pointern realisiert wurde. Mit dem Interface-Mechanismus der Version 3 gelingt dies wesentlich einfacher. Dabei implementieren mehrere Klassen das gleiche Interface, zum Beispiel alle LNC die Methode Read. Die Methode lässt sich jetzt einfach aufrufen, ohne dass der Programmierer darüber nachdenken beziehungsweise extra Code schreiben muss. Ohne dieses Feature müsste der Funktionsaufruf für jede der Klassen einzeln codiert werden. In einer zukünftigen Erweiterung möchte 3S das derzeit implementierte Kommunikationsmodel MMS durch Web-Services ersetzen. Bei der Version 2.3 bestünde der Lösungsansatz für die Erweiterung um ein neues Kommunikationsmodel darin, zwei Kommunikationsbibliotheken mit gleichem Interface zu erstellen. Zum Übersetzungszeitpunkt würde dann die eine oder andere Bibliothek verwendet. Auch diese Problematik lässt sich mit dem Interface Mechanismus der Version 3 wesentlich einfacher lösen, da der Code dann beide Kommunikationsmodelle beinhalten kann. Eine flexiblere Lösung entsteht dadurch, dass die Entscheidung, ob über MMS oder Web-Services kommuniziert werden soll, zur Laufzeit des SPS-Programms verschoben werden kann.

Noch eine Schwäche von Codesys 2.3: Im Datenmodel der IEC 61850 erben die spezifischen Logical Node Classes von einer Basisklasse eine Anzahl von Common Data Classes. In der Version 2.3 sind diese Daten in jedem spezifischen Typ einer LNC erneut zu definieren und die Funktionalität in den Aktionen erneut zu programmieren. In der Version 3 entfällt dieses durch Nutzung des Vererbungsmechanismus (Spracherweiterung EXTENDS - Stichwort: copy & paste).

Klassich versus objektorientiert

Das Prinzip der objektorientierten Programmierung, welches Codesys V3 zugrunde liegt, ist die Kapselung von Daten (Attribute) und Operationen (Methoden) in einem Objekt. Die Idee rührt daher, dass man „Real World Objects" auf Software- Objekte abbilden möchte - also zum Beispiel ein Objekt Lasttrenner mit dem Attribut Öltemperatur und den Methoden Öffnen/Schließen. Dagegen steht der frühere Ansatz der prozeduralen Programmierung für eine Trennung von Daten und Operationen. Merkmale, die von objektorientierten Sprachen unterstützt werden, sind Klassen, Methoden, Polymorphie, Schnittstellen sowie Speicherverwaltung für Instantiierung und Zerstörung von Objekten zur Laufzeit. Dabei muss eine Sprache nicht notwendigerweise all diese Merkmale unterstützen, damit sie als objektorientiert gilt.

Neben Codesys gibt es weitere objektorientierte Sprachen, die sich jedoch im Automatisierungsumfeld bis dato nicht auf breiter Front durchgesetzt haben.

© Bild: Wago

Die objektorientierten Möglichkeiten bringen aber nicht nur dem Maschinenund Anlagenbauer Vorteile; auch die Hersteller von Automatisierungsgeräten profitieren davon. Diese haben typischerweise sowohl ein Gerät im Programm als auch ein skalierbares Hardware-Portfolio, um dem Anwender eine individuelle Lösung für seine Leistungsanforderungen bieten zu können. Mit den erweiterten Möglichkeiten von Codesys lassen sich jetzt mehr Funktionalitäten aus der Firmware der Geräte in die IEC-61131-Softwarelösungen verlagern, die unmittelbar auf allen Geräten des Herstellers lauffähig sind. Dies verkürzt Entwicklungszeiten und erhöht die Flexibilität.

Im Fall der eingangs erwähnten Telecontrol-Lösung war der Umstieg von der Version 2.3 auf Version 3 der Codesys- Entwicklungsumgebung auf einfache Art über die automatische Konvertierung des Projektes möglich und die Lösung auf der neuen Plattform unmittelbar lauffähig. Für die Aufgabenstellung eigneten sich hier besonders die folgenden objektorientierten Änderungen:

• Das IEC-61850-Klassenmodel spiegelt sich direkt in der objektorientierten Softwarestruktur wieder. Das bedeutet, dass zum Beispiel ein realer Lasttrenner direkt auf die Klasse XCBR abgebildet wird, was für „Circuit Breaker" steht.
• Alle IEC-61850-Logical-Node-Classes beinhalten grundlegende Funktionalitäten einer Basisklasse. Damit sind nur noch die spezifischen Funktionen zu implementieren.
• Codesys stellt mit der speziellen Methode „FB_Init" einen Konstruktor-Mechanismus zur Verfügung. Diese Methode wird automatisch bei der Erzeugung des Objektes genau einmal aufgerufen. In der genannten Anwendung dient dieser Mechanismus zur Initialisierung der typspezifischen Eigenschaften der abgeleiteten 61850-Klassen.
• Wie bereits erwähnt, ist MMS eine erste Umsetzung des IEC-61850-Kommunikationsmodels. Mit Blick auf die weiteren denkbaren Realisierungen hinsichtlich Web-Services oder OPC-UA ist beim Design der Kommunikationsanschaltung als Interface später eine Anschaltung einfach gegen die andere austauschbar.

UML-Editoren treiben die Objektorientierung voran

Die objektorientierten Erweiterungen in Codesys verfolgen letztlich das Ziel, dem SPS-Programmierer die Wahlfreiheit zu bieten, ob er die Aufgabenstellung durchgängig klassisch, durchgängig objektorientiert oder auch „gemischt" umsetzen möchte. Die objektorientierte Lösung bietet jedoch klare Vorteile - zum Beispiel die höhere Wartbarkeit des Codes durch die Kapselung von Daten und Operationen innerhalb von Objekten. Der Mechanismus der Vererbung unterstützt den Entwickler auch hinsichtlich einer einfacheren Erweiterbarkeit der Lösung. Im skizzierten Fallbeispiel lassen sich weitere Logical Node Classes ohne viel „Copy & Paste" ergänzen. Das Merkmal der Interfaces unterstützt den Entwickler zudem bei der Ergänzung um weitere Kommunikations-Mappings.

Mit einer zukünftigen Integration von UML-Editoren in die Entwicklungsumgebung wird die objektorientierte Erweiterung der IEC 61131-3 einen weiteren Schub erfahren. Im Rahmen dieses Schrittes hin zur „ausführbaren UML" wurden innerhalb eines Forschungsprojektes an der Universität Kassel Editoren für Klassen-, Zustands- und Aktivitätsdiagramme erstellt, die sich als Plug-In nahtlos in Codesys einbetten. Die Editoren arbeiten dabei direkt auf dem Datenmodell der Entwicklungsumgebung, so dass keinerlei manueller Abgleich zwischen den UML-Editoren und dem IEC-61131-Code notwendig ist. Dies ermöglicht letztlich einen breiteren Einsatz von Codesys - vom objektorientierten Design, über die Implementierung und Inbetriebnahme bis hin zur Visualisierung.

Autor:

Martin Paulick ist Produktmanager für Engineering-Software und Telecontrol-Lösungen bei Wago Kontakttechnik