Trotz unterschiedlichster Aufgabenstellungen und Anforderungen haben die Anwender von Automatisierungstechnik in der Regel dieselben Idealvorstellungen, was die Auswahl der eingesetzten Komponenten betrifft, und zwar:  

• Engineering-Werkzeuge sollen Bibliothekselemente unterschiedlicher Hersteller akzeptieren und verwenden können – Stichwort Portabilität.
• Steuerungsgeräte unterschiedlicher Anbieter sollen sich mit Engineering- Werkzeugen von unterschiedlichen Herstellern konfigurieren beziehungsweise programmieren lassen – Stichwort Konfigurierbarkeit.
• Steuerungsgeräte unterschiedlicher Hersteller sollen an der Ausführung mehrerer, auch verteilter Applikationen zusammenarbeiten können – Stichwort Interoperabilität. 

In der Realität beruhen aktuelle Systeme auf Konzepten, deren Erstellung über 15 Jahre zurückliegt, und zwar auf der 1993 erstmals veröffentlichten IEC 61131-3. Die Grundintention dieser Norm war die Schaffung von gemeinsamen Sprachen in der Automatisierungstechnik. Dies ist – wenn auch mit anfänglichen Schwierigkeiten – nicht zuletzt dank der Interessensgemeinschaft PLCopen gelungen: Die vier Programmiersprachen Anweisungsliste (AWL), Kontaktplan (KOP), Funktionsblockdiagramm (FBD) und Strukturierter Text (ST) sowie die zur Strukturierung vorgesehene Ablaufsprache (AS) sind heute aus der Automatisierungstechnik nicht mehr wegzudenken.

Die IEC 61131-3 erlaubt es den Herstellern von Steuerungsgeräten, beliebige Abwandlungen und Dialekte der genannten Programmiersprachen einzuführen, ohne mit der Norm in Konflikt zu geraten. Das Mittel der „Compliance Statements“ ist letztendlich nicht mehr als eine tabellarische Aufführung jener Elemente, die man gewillt ist, zu unterstützen. Da sich in den letzten Jahren eine weitgehende Unterstützung aller Elemente der IEC 61131-3 durchgesetzt hat, findet sich diese Differenzierung mittlerweile in einer großen Vielfalt an Erweiterungen zu den Programmiersprachen und unterlagerten Konzepten wieder. Angesiedelt sind diese etwa in der Unterstützung von Methoden der Objektorientierung bis hin zur eventbasierten Kommunikation zwischen einzelnen Modulen innerhalb eines Steuerungsgeräts, um nur zwei Beispiele zu nennen. Angesichts dieser Entwicklung und der in der Praxis vorzufindenden, äußerst differenzierten Engineeringtool-Landschaft, kommt man hinsichtlich der Frage, ob die IEC 61131-3 den oben angeführten Auswahlkriterien der Anwender gerecht werden kann, zu einem ernüchternden Resultat:

Portabilität: Was die Portabilität der Engineering-Werkzeuge betrifft, schlägt die PLCopen zwar ein einheitliches Austauschformat auf Basis von XML für Programmierprojekte vor. Aufgrund der größtenteils noch fehlenden Umsetzung, bleibt die IEC 61131-3 in diesem Punkt die Möglichkeiten des neuen Ansatzes allerdings vorerst noch schuldig. Die angesprochenen Differenzierungen scheinen sich diesbezüglich jedoch prinzipiell als hinderlich zu erweisen.

Konfigurierbarkeit: Zwar gibt es auf Feldbus-Ebene derzeit durchaus viel versprechende Ansätze in Richtung einer hersteller-übergreifenden Einbindung von Komponenten in Engineering-Werkzeuge, wie zum Beispiel das Field-Device-Tool-Konzept – kurz FDT; auf Ebene der Programmierung von Steuerungsgeräten allerdings sind diesbezüglich keine vergleichbaren Möglichkeiten in Sicht. Hier lautet die Devise der meisten Anbieter nach wie vor: jedem Steuerungsgerät sein eigenes Engineering- Werkzeug.

Interoperabilität: Die verschiedenen Steuerungsgeräte unterschiedlicher Hersteller arbeiten höchstens auf der Ebene von einfachen Feldbus-Profilen zusammen, was im Engineering zu hohem Aufwand führt und wenig Spielraum für neue Konzepte lässt. Als Beispiel seien hier die immer öfter vorzufindenden frei programmierbaren Steuerungsgeräte in Servoantrieben genannt, die in ihren Möglichkeiten durch die Anbindung über starre Geräteprofile von Feldbussen stark eingeschränkt sind. Kommunikations-Funktionsblöcke, wie sie im Teil 5 der IEC 61131 definiert sind, wurden bisher äußerst selten bis gar nicht umgesetzt!

Was macht die IEC 61499 anders?

Doch auch in der Automatisierungstechnik steht die Zeit nicht still: Und so hat derselbe Personenkreis, der die IEC 61131-3 entwickelte, schon vor Jahren eine Weiterentwicklung angestoßen, die schlussendlich 2005 in einer neuen Norm mündete: in der IEC 61499.

Gegenüberstellung der Merkmale der Normen IEC 61131-3 und IEC 61499

Was sind die Grundideen, die der Entwicklung dieser IEC-61131-3-Nachfolge-Norm zugrunde lagen? Zum einen wurde versucht, aktuelle Technologien der Informatik wie etwa komponenten-basierte beziehungsweise objektorientierte Ansätze einzubauen, ohne die Anforderungen an den Benutzer zu sehr zu erhöhen. Weiterhin kapselt die IEC 61499 die Einbindung der Interaktion mit der „Außenwelt“ – also zum Beispiel die I/Os des Prozesses sowie die Kommunikation an sich – in speziellen Funktionsblöcken, was eine nahtlose Integration in die Steuerungsapplikation ermöglicht. Durch die Event-Steuerung lässt sich zudem eine Verteilung der Applikation ohne besondere Rücksichtnahme auf die Hardware-Konfiguration vornehmen. Nicht zuletzt wurden Mechanismen vorgesehen, um dynamisch Änderungen an ei-ner – auch laufenden –Steuerungsapplikation vorzunehmen.

Hinsichtlich der drei eingangs definierten Eigenschaften bietet die Norm in ihrem Teil 4 die so genannten „Compliance Profiles“ an. Zwar lässt sich auch hierüber ähnlich wie bei der IEC 61131-3 eine beliebige Differenzierung vornehmen; die Grundidee hinter diesen Compliance Profiles ist aber, in diesen Dokumenten genau jene Implementierungsdetails anzugeben, die ein bestimmter Hersteller im Bezug auf Portabilität, Konfigurierbarkeit und Interoperabilität gewählt hat. Durch eine entsprechende Veröffentlichung und eine im besten Fall einheitliche Definition von Compliance Profiles bietet die IEC 61499 somit die Möglichkeit, über Herstellergrenzen hinweg hoch integrierte Lösungen bereitzustellen. Stand heute gibt es am Markt allerdings nur sehr wenige Produkte, die bereits an den Grundsätzen der IEC 61499 ausgerichtet sind. Um einen kurzen Einblick zu gewähren, seien im Folgenden zwei Beispiele herausgegriffen:

Profinet CBA

Ausgangspunkt der von Siemens entwickelten, ethernet-basierten Profinet- Technologie war der Component-Based- Automation-Ansatz – kurz CBA. Dieser stellt auf Basis der IEC 61499 eine Methode bereit, um Automatisierungslösungen mit mehreren Steuerungen projektieren zu können. Dabei werden die Grundelemente der Norm sehr beschnitten, was sich am deutlichsten in der Darstellung von CBAKomponenten ohne Events manifestiert. Die Programmierung einer CBA-Komponente ist nach wie vor Aufgabe des zum Steuerungsgerät gehörenden Engineering- Werkzeugs; allerdings wird das Interface der CBA-Komponente in einem austauschbaren Format bereitgestellt und damit in einem zusätzlichen Engineering- Werkzeug das reine Erstellen der (Daten-) Verbindungen zwischen den Komponenten erledigt. Im Hinblick auf die drei genannten Eigenschaften bedeutet dies:

Portabilität: Portabilität in punkto Engineering- Werkzeuge ist de facto nicht gegeben, weil die Internas der CBA-Komponenten nach wie vor spezifisch bleiben.

Konfigurierbarkeit: Die Frage nach der Konfigurierbarkeit lässt sich bedingt mit „ja“ beantworten, da auf der Ebene der Verbindung der CBA-Komponenten durchaus verschiedene Tools einsetzbar sind. Dies stellt aber nur einen kleinen Teil der Konfigurierbarkeit dar, die im Besonderen auch auf die Programmierung selbst abzielt.

Interoperabilität: Durch die Offenlegung der Spezifikation und Kommunikationsmethoden ist bei Profinet CBA Interoperabilität zwischen Steuerungsgeräten verschiedener Hersteller möglich.   

Isagraf v5.0

Die Firma ICS Triplex hat in der aktuellen Version des Engineering-Werkzeugs Isagraf v5.0 eine interessante Form der Unterstützung der IEC 61499 integriert, indem das Tool eine kombinierte Umgebung von IEC 61131-3 und IEC 61499 bietet. Dies geht sogar so weit, dass Verbindungen zwischen Funktionsblöcken der beiden Normen möglich sind. Die wesentliche Erweiterung für den Benutzer liegt in der Modellierung von verteilten Steuerungsapplikationen an Stellen, bei denen es mit der IEC 61131-3 teilweise sehr schwierig und aufwendig ist, entsprechende Lösungen zu entwickeln. Die Funktionsblöcke selbst werden dabei ohne Änderungen im äußeren Erscheinungsbild der IEC 61499 dargestellt, intern sind aber einige Anpassungen sichtbar wie zum Beispiel die Zustandsmaschine eines so genannten Basic-Funktionsbausteins, die durch die Ablaufsprache ersetzt wurde. Weiterhin wurde die Rekonfiguration, welche die IEC 61499 über ein definiertes Interface vorsieht, durch interne Mechanismen und nicht zuletzt das Austauschformat durch eine proprietäre Repräsentation ersetzt. Auf Basis der Festlegung eines Compliance Profile konnte ICS Triplex die Konformität zur IEC 61499 nachweisen. Was bedeuten diese Implementierungsentscheidungen nun für die drei Eigenschaften, welche die IEC 61499 im Besonderen berücksichtigt?

Portierbarkeit: Aufgrund der Abänderungen der Austauschformate sowie der Internas des Basic-Funktionsblocks ist keine Portierbarkeit gegeben.

Konfigurierbarkeit: Bei Isagraf v5.0 handelt es sich um eine geschlossene Lösung, die keine Konfigurierbarkeit ermöglicht.

Interoperabilität: Verteilung von Applikationen ist explizit berücksichtigt, jedoch auf die Steuerungsgeräte der Isagraf-Lösung eingeschränkt, womit Interoperabilität im eigentlichen Sinn nicht gegeben ist.  

Wege zu einem harmonischen Miteinander

Wie an den beiden Beispielen von ersten IEC-61499- Implementierungen ersichtlich ist, sind die für den Anwender so vorteilhaft klingenden Eigenschaften der Portierbarkeit, Konfigurierbarkeit und Interoperabilität auch mit der IEC 61499 a priori nicht gegeben.

Konzepte zur gemeinsamen Nutzung von IEC 61131-3 und IEC 61499

Doch warum ergibt sich eine solche Situation? Schließlich waren viele der großen Hersteller an der Entwicklung der IEC 61499 beteiligt! Die Antwort hierauf ist in den divergierenden Interessen der Applikationsersteller und der Steuerungsanbieter zu suchen. Der Applikationsersteller möchte gerne, basierend auf den jeweiligen Leistungsmerkmalen, die in Frage kommenden Steuerungshersteller beziehungsweise die für seine Aufgabenstellung am besten geeignete Kombination von Komponenten gezielt und frei wählen können (Skalierbarkeit).

Demgegenüber sind die Steuerungshersteller bemüht, durch Paketbildung in den Leistungsmerkmalen zusätzliche Features mit zu verkaufen (Up-Selling), und naturgemäß daran interessiert, die Kombinationsmöglichkeiten auf das eigene Produktspektrum zu reduzieren (Cross-Selling). Hinzu kommt: Während Applikationsersteller bei einer Erweiterung bestehender Anwendungen keinen Einschränkungen unterworfen sein wollen (freie Erweiterbarkeit), sollen nach dem Wunsch der Steuerungshersteller diese Erweiterung mit dem eigenen Produktportfolio durchgeführt werden (intrinsische Erweiterungen). Ähnliches gilt für die Ersatzteilversorgung. Last but not least sollen vom Applikationsersteller entwickelte Automatisierungslösungen weitgehend unabhängig von der konkreten Hardware in neuen Projekten wieder verwendbar sein (Software-Reuse). Nicht selten ist dies jedoch bei einem Wechsel des Steuerungsherstellers mit hohen Kosten verbunden.

Angesichts dieses Spannungsfeldes divergierender Interessen leuchtet es ein, dass die Bemühungen in Richtung Portabilität, Konfigurierbarkeit und Interoperabilität der gemeinsamen Anstrengung und Spezifikation entsprechender Richtlinien durch möglichst breit aufgestellte Nutzerorganisationen bedürfen. Diese Rolle ist in punkto IEC 61131-3 klar der PLCopen zuzuschreiben. Was die bessere Integration von bestehenden wie zukünftigen Lösungen auf Basis der IEC 61499 betrifft, hat sich in den letzten Jahren die OOOneida-Organisation stark als Diskussions- Plattform engagiert. Mit dem Ziel, beide Ansätze beziehungsweise Normen „unter einen Hut“ zu bringen, bieten sich verschiedene Konzepte an, die durchaus untereinander entsprechende Portabilität, Konfigurierbarkeit und Interoperabilität gewährleisten können:  

• Parallele Nutzung: Die einfachste Lösung eines Nebeneinanders von IEC 61131-3 und IEC 61499 ist die Schaffung einer entsprechenden Schnittstelle zwischen den Plattformen. Hier ließen sich unter anderem die Kommunikations- Funktionsblöcke der IEC 61131-5 als Basis nutzen.
• IEC-61131-3-basierte Lösung: Wie dies etwa die bereits vorgestellte Lösung von Isagraf v5.0 vorsieht, kann auf der Grundlage eines IEC-61131-3-Laufzeitsystems auch die Norm IEC 61499 abgebildet werden.
• IEC-61499-basierte Lösung: Umgekehrt ist es denkbar, die Elemente der IEC 61131-3 innerhalb eines Laufzeitsystems basierend auf der IEC 61499 umzusetzen. Der Vorteil dieser Variante ist, dass dabei das neuere Konzept als Grundlage dient und dementsprechende Optionen für die weitere Entwicklung zu erwarten sind.  

Soweit die Theorie: In der Praxis gestaltet sich die Situation vor allem deshalb als sehr schwierig, da es keiner der Steuerungshersteller alleine vermag, eine neue Norm zu etablieren – siehe zum Beispiel die geringe Verbreitung des von Siemens entwickelten Profinet CBA. Gleichzeitig stellt die Orientierung in Richtung offener Systeme für Steuerungshersteller zunehmend einen entscheidenden Erfolgsfaktor dar. Auf der anderen Seite wird der Druck auf die Applikationsersteller immer größer, aktuelle Konzepte einzuführen, um die Herausforderungen neuer Automatisierungsanlagen meistern zu können. Ergo ist es zwingend notwendig, dass auf herstellerübergreifender Ebene Lösungen diskutiert und ein einheitliches Vorgehen beschrieben wird.  

Autoren:
Josef Fritsche ist Entwicklungsleiter Software bei Bachmann Electronic.

Heinrich Steininger ist Geschäftsführer der Firma Logi.cals (vormals Kirchner Soft).

Christoph Sünder ist Projektassistent im Forschungsfeld „Agile Control“ am Institut für Automatisierungs- und Regelungstechnik (ACIN) der TU Wien.

Alois Zoitl ist ist Gruppenleiter für das Forschungsfeld „Agile Control“ am ACIN der TU Wien.