Anspruchsvolle Software für anspruchsvolle Maschinen

SPS: Wie sieht die allgemeine Geschäftsentwicklung von 3S aus und wie ist das Unternehmen durch die – jetzt schon fast vergessene – Krise gekommen? Hess: Die allgemeine Geschäftsentwicklung ist sehr gut. Die Krise hatte uns natürlich auch Sorgen bereitet, wir sind allerdings relativ glimpflich durchgekommen. Insbesondere im Vergleich zur gesamten Automatisierungsbranche. Konkrete Zahlen dazu: Wir hatten, im Krisenjahr 2009 einen Umsatzrückgang von 6% und 2010 ein Plus von 43% gegenüber 2009. Im ersten Halbjahr 2011 lagen wir bei +36%. Wir können uns jedoch kaum vorstellen, dass es in diesem Tempo weitergehen wird. SPS: Was sind die Branchen außerhalb der klassischen Fabrikautomation die 3S bedient? Hess: Unser Kernbereich ist Factory Automation, der zweite wichtige Bereich ist die Automatisierung von mobilen Arbeitsmaschinen, wie z.B. Baumaschinen oder landwirtschaftliche Maschinen. In dieser Branche beliefern wir fast alle wichtigen Steuerungsanbieter mit etwa einem Drittel der CoDeSys-Laufzeitlizenzen. Gut entwickelt hat sich die Energiebranche: CoDeSys wird in schönen Referenzprojekten eingesetzt, wie z.B. in Windkraftanlagen mit Zentralsteuerung und Pitch Control Rotorblattverstellung. Oder in der Solarbranche, beispielsweise in den thermischen Solarkraftwerken in Spanien sowie im Bereich der Netzleittechnik. Die Prozessautomation ist ein sehr großer Markt, in dem wir allerdings noch nicht so stark vertreten sind, also durchaus ein Wachstumsmarkt. Immer wieder erkennen Hersteller von Embedded Geräten, dass es bei der Projektierung, Inbetriebnahme und Wartung vorteilhaft ist, die Applikationssoftware in IEC61131-3 statt in C zu programmieren. Zumal mit CoDeSys eine ganze Reihe von technologischen Anforderungen, wie z.B. OPC oder Feldbus-Anbindung bereits fertig verfügbar sind. Hinzu kommt, dass das Tool sich so weiter entwickelt hat, eben nicht nur für \’Klapperlogik\‘, sondern für komplexe Applikationen geeignet ist. Beispielsweise schreiben wir unsere Feldbus-Stacks in IEC- also den Ethercat- und den CANopen-Stack, was man früher sonst nur in C gemacht hätte. Von daher deckt CoDeSys auch den Bereich der Systemprogrammierung ab und hat im Gegenzug im applikationsnahen Bereich natürlich alle Vorteile der IEC-Programmierung. SPS: CoDeSys Safety – wie ist da der Stand der Dinge? Hess: CoDeSys Safety ist bei uns ein zent­rales Projekt. Eigentlich sind es sogar drei verschiedene Projekte, wie ich gleich erläutern werde. Was im Blickpunkt der Öffentlichkeit steht und bei uns mit einem Team von gegenwärtig acht Mitarbeitern mit Nachdruck verfolgt wird, ist das SIL3-Projekt für den Maschinenbau – ausgelegt für eine Zusatzsteuerung. Da sind wir mitten in der Hauptprüfung. Die Testphase und -spezifikation werden wir bis Ende März 2012 abschließen, danach erfolgt die Zertifizierung. Aber wie gesagt, es sind eigentlich drei Schienen: Für Mobilsteuerungen bestehen andere Marktanforderungen, weswegen wir parallel an einem zweiten Projekt arbeiten, das eine völlig andere technische Grundlage besitzt. Es zielt auf eine Zertifizierung nach SIL2, sodass man in der Steuerung sowohl Sicherheits- als auch Standardsoftware in einer einzigen Steuerung unterbringt. Das ist in diesem Bereich derzeit Standard. Im Gegensatz zum SIL3-System ist dafür etwas mehr Abnahmeaufwand und Know-how beim Applikations-Programmierer erforderlich. Dafür kommt man mit einer einzigen Steuerung aus, die ohne Einschränkungen im Funktionsumfang programmiert werden kann, während SIL3 einen sehr reduzierten Sprachumfang hat. Und dann haben wir noch eine dritte Schiene: Nicht jeder Steuerungshersteller und schon gar nicht jeder größere Endanwender ist willens, eine Safety-Steuerung zu entwickeln. Deswegen unterstützen wir die dezent­rale Safety-Lösung von Beckhoff: die Safety-Klemme EL6900. Somit können wir eine vollständig integrierte Lösung in CoDeSys anbieten. Erforderlich ist dazu lediglich eine mit CoDeSys programmierbare Steuerung mit Ethercat-Master. SPS: Und wie wird die parametriert? Hess: Direkt mit dem Ethercat-Konfigurator in CoDeSys. Man fügt einen EL6900-Knoten ein und programmiert darunter seine Bausteine im Safety-FUP-Editor. Dabei kann der Anwender natürlich nur den Bausteinvorrat der EL6900 verwenden. Auch für diese Lösung ist eine Zertifizierung in Zusammenarbeit mit Beckhoff vorgesehen. Damit haben wir also drei Schienen: Integrierte SIL3-Safety für den Maschinenbau, SIL2 für mobile Maschinen und die EL6900 – alle drei wollen wir um den Jahreswechsel fertig implementiert haben. Das SIL3-Projekt läuft schon sehr lange, auch für die beiden anderen Projekte haben wir viele Ressourcen investiert. Wir wissen, dass wir damit zwar nicht die Ersten im Markt sind. Dafür sind wir sicher, eine sehr gute und marktgerechte Lösung anbieten zu können. Wir merken, dass Kunden das schätzen und deswegen auf unsere Lösung setzen. Auch wenn wir gegenüber ursprünglichen Zeitvorstellungen hinten dran sind. SPS: Wobei ich es so auch vom Markt her wahrnehme, dass es natürlich bestimmte Bereiche gibt, in denen solch eine Safety-Lösung ein Muss ist. Es gibt aber durchaus auch Maschinen, bei denen es den zeitlichen Druck nicht gibt Safety sofort umzusetzen. Häufig geht es den Maschinen- und Anlagenbauern eher um die langfristigen Perspektiven. Hess: Genau, so ist es tatsächlich und wir merken, dass der Markt schon noch da ist. SPS: Wie viele Ihrer Kunden setzen mittlerweile prozentual etwa auf die Version 3? Hess: Ich habe mal nachgesehen: etwa 150 Firmen – in der Regel Gerätehersteller – haben ein CoDeSys V3 Runtime Toolkit erworben und begonnen, ein V3-Gerät zu implementieren. Das ist der wichtigste Teil unserer etwas mehr als 300 Kunden. Sicherlich sind nicht mehr alle dieser 300 Kunden aktiv – sehr wohl aber die genannten. Auf praktisch allen neuen, mit CoDeSys programmierbaren Geräten, die auf dem Markt gelauncht werden, ist V3 implementiert. SPS: Wie können mit CoDeSys komplexere Antriebsaufgaben vom Anwender umgesetzt werden? Ich denke da an alles was in Richtung 3D geht, Bahnsteuerung, Robotik und CNC-Funktionen. Hess: Wir haben ja ein starkes MotionControl-Paket in CoDeSys integriert, das auf der IEC61131-3 basiert. Es deckt all die genannten Aufgaben ab, bis hin zu 3D-CNC. Dabei sind im Programmiertool natürlich eigene grafische Editoren für die Erstellung von Kurvenscheiben und für CNC-Programme implementiert. Letzterer erzeugt G-Code, der vom Editor in Datenstrukturen abgelegt wird. Das System ist flexibel einsetzbar. So kann der Anwender die Bahn entweder im Programmiersystem rechnen lassen und dadurch die Steuerung entlasten, was natürlich die Flexibilität auf der Steuerung verringert. Oder er belässt die Bahnberechnung der Steuerung, dann kann der G-Code auch dynamisch verändert werden. CoDeSys SoftMotion ist ein sehr umfangreiches Paket, das bei vielen namhaften Steuerungsherstellern zum Einsatz kommt, wie z.B. Schneider Electric oder Lenze. Die Bibliotheksbausteine sind konform nach PLCopen – wir sind schließlich Mitglied der PLCopen Motion Task Force. Unsere Lösung geht allerdings einen ganzen Schritt weiter, als in der PLCopen vorgesehen. Sowohl bei den integrierten Editoren als auch der Anbindung des Antriebs. Der Anwender kann CoDeSys SoftMotion antriebsunabhängig projektieren und damit seine Bewegungen u.a. über Sercos, Ethercat, CANopen oder analog +/-10V realisieren. Man benötigt lediglich einen entsprechenden Treiber dafür. SPS: In welche Richtung aus Ihrer Sicht soll die Steuerungsprogrammierung sich in den nächsten fünf Jahren etwa entwickeln? Hess: Ich sehe da eigentlich zwei Richtungen. Die Steuerungsprogrammierung muss sich einerseits darum kümmern, dass sie nicht abfällt gegenüber den Features und Funktionen, die man in IT-Bereichen gewöhnt ist. Daran arbeiten wir aktiv. So sehen wir z.B. die Objektorientierung als entscheidenden Schritt in diese Richtung. Das bezieht sich aber eben auch auf andere bekannten Methodiken und Tools. Ich spreche von PC-Entwicklungsumgebungen, z.B. den Leistungsumfang von Visual Studio mit den Möglichkeiten für C#. Gerade junge Ingenieure und Informatiker, die von der Uni kommen, wollen nicht den Eindruck haben, die Automatisierungstechnik lebt noch in der Steinzeit. Sie wollen mit einem modernen Tool arbeiten, das angepasst an die Anforderungen der Automation ist. Genauso wie man zwar Ethernet als Feldbus verwenden kann, aber deswegen noch lange nicht so einfach TCP/IP darauf laufen lassen kann. Die technologischen Vorteile der modernen Tools will man in der SPS-Welt sehen, dennoch müssen diese an die speziellen Anforderungen der Automatisierung angepasst sein. Deswegen sehen wir es auch nicht als Lösung, einfach in C oder C++ zu programmieren. Mit der CoDeSys Professional Developer Edition decken wir genau diese Richtung ab. Während in der PC-Welt eine Applikation von vielen Programmierern über einen langen Zeitraum geschrieben wird, ist die Situation im Maschinenbau oft ganz anders. Da schreibt ein Maschinenbauer bzw. Programmierer pro Jahr hunderte von Steuerungsapplikationen. Genauso viele, wie Maschinen gebaut werden. Die Applikationen sind zwar alle ähnlich, aber doch unterschiedlich. Um diese spezielle Entwicklungsanforderung zu erfüllen, könnten die Tools auch noch besser sein. Genau dafür bieten wir den CoDeSys Application Composer an. SPS: Zwei Stichworte: Das eine ist das Thema Team und das Zweite ist das Thema Versionscontrolling. Hess: Ein Versionskontrollen-Management gab es ja bereits in CoDeSys 2.3. Für CoDeSys V3 bieten wir jetzt im Umfang der Professional Developer Edition ebenfalls eine Lösung: wir haben eine Anbindung an Apache Subversion (SVN) integriert. Dabei wurde auch wirklich die Denkweise und Bedienphilosophie von Subversion übernommen. Die Integration geht aber soweit, dass auch grafische Vergleiche z.B. auch in FUP und in SFC erfolgen. Das IEC61131-3 Projekt wird mit dieser Anbindung objektweise in SVN abgelegt – und damit für die Arbeit im Team geöffnet. Das heißt, dass ein Applikationsentwickler z.B. die Auswertung der E/As programmieren kann, während ein anderer im gleichen Projekt einen Berechnungsalgorithmus oder einen Visualisierungsbaustein bearbeitet. SVN sorgt für die Verriegelung bzw. das manuelle Mergen von erstelltem Programmcode in das Projekt. SPS: Welchen Stellenwert hat aus Ihrer Sicht aktuell das Thema Hochsprachenprogrammierung, allerdings nicht im Sinne von C, sondern im Sinne von Strukturierter Text? Hess: ST ist die am häufigsten verwendete Sprache in CoDeSys. Wir haben fast alle Bibliotheken und eine ganze Reihe von systemnahen Funktionen in Strukturiertem Text geschrieben ­ somit hat ST für uns einen sehr hohen Stellenwert. Und so ist es auch für unsere Kunden. Um einmal ein paar Extrembeispiele zu nennen: ein XML Parser im ST, oder eine Art Webbrowser, und wie bereits erwähnt unsere Feldbus-Stacks für Ethercat, CAN-open und J1939. Dadurch sind alle diese Beispiele natürlich portabel und kompilierbar auf jede beliebige Plattform. Viele weitere algorithmische und Datenverarbeitungsfunktionen in Applikationen werden in Strukturiertem Text entwickelt. Oft wird ST erst dann verlassen, wenn die grafischen Sprachen wie FUP oder AS bei Änderungen oder Inbetriebnahme vor Ort ihre Vorteile visuell ausspielen können. SPS: Kann man sagen, dass der Strukturierte Text schon fast – ausgehend von der Nutzung her – den Charakter einer Scriptsprache hat? Hess: Nein, so kann man das nicht sagen. Der Strukturierte Text wird für algorithmische Software verwendet, die im normalen Maschinenzyklus läuft. Scriptsprachen sind für die vergleichsweise langsame Ausführung von Gesamtabläufen gedacht. Diese Aufgabe hat in der IEC eher die Ablaufsprache. Zur Automatisierung des Programmiertools selbst haben wir seit etwa einem halben Jahr die Scriptsprache Python in CoDeSys integriert. Wiederkehrende Funktionen, wie z.B. das Abrufen von Bausteinen aus der Quellcode-Verwaltung oder das Anlegen einer standardisierten Projektstruktur kann der Anwender vom Script erledigen lassen.Aber noch einmal zurück zu ST: gerade jüngere Applikationsentwickler mit Affinität zu Hochsprachen entwickeln überwiegend in dieser Sprache. Diese Gruppe verwendet auch zunehmend die Möglichkeiten der objektorientierten Programmierung in CoDeSys. Zumindest in komplexen Maschinen- oder Anlagenapplikationen. Durch die Modularisierung der Software in Objekte werden solche Projekte besser beherrschbar, auch kann bestehender Code einfacher wiederverwendet werden. Es ist klar, dass die Objektorientierung als Programmierparadigma mehr Einarbeitung erfordert. Viele Programmierer, die heute von der Hochschule kommen, treten allerdings schon mit diesem Hintergrund an. Ihnen muss man nicht erzählen, was eine Methode oder ein Interface ist. Wir sehen uns jedoch nicht als Missionare für Objektorientierung. Denn CoDeSys kann beides. Wenn jemand sagt \“Bleib mir damit weg\“, so kann er wie bisher programmieren. Wie viel Objektorientierung unter der Oberfläche steckt, muss ihn gar nicht interessieren. Der Systemprogrammierer kann seinerseits die Vorteile der OOP nutzen und diese über einen funktionalen Aufruf bereitstellen. Wir wollen einfach beiden Gruppen ein Tool zur Verfügung stellen, mit dem sie sehr gut arbeiten können. Gerade in Deutschland werden sehr hochwertige und anspruchsvolle Maschinen gebaut – dazu gehört natürlich auch anspruchsvolle Applikationssoftware. Wenn Maschinen in HighTech-CAD- und FEM-Tools konstruiert werden, kann der SPS-Programmierer nicht in AWL und möglichst mit einem Zwei-Tages-Kurs das Optimum aus der Maschine holen. Das wäre einfach ein verschenktes Potenzial. Wenn der VDMA heute davon spricht, dass etwa die Hälfte der Wertschöpfung einer Maschine in der Software zu finden ist, müssen die Tools dabei Unterstützung leisten. OOP in CoDeSys ist unser Beitrag dazu. SPS: Welche Chancen einerseits und welche Herausforderungen andererseits sehen Sie für das Unternehmen in den nächsten fünf Jahren? Hess: Da besteht zum einen natürlich die Möglichkeit, die bereits begonnene Internationalisierung weiter voranzutreiben. Zum anderen können wir die oben angesprochenen Branchen, für die CoDeSys sehr gut geeignet ist, weiter ausbauen. In der Embedded Branche und in der Prozessindustrie gibt es sicher noch großes Potenzial. Wir profitieren davon, dass sich CoDeSys als eine Art Standard in Deutschland etabliert hat. Natürlich sehen wir es als Chance, diesen Gedanken auch in andere Branchen und Länder zu tragen. Eine Herausforderung für uns sind auch andere Programmierparadigmen. Aber genau da setzen wir ja an. Wir wollen die Vorteile von alternativen Angeboten, wie z.B. C# aus der PC-Welt, in gleicher Form anbieten und gleichzeitig unsere Vorteile erhalten, die wir z. B. gegenüber Visual Studio haben: Online-Änderungen, Online-Debugging einer laufenden Maschine, integrierte Feldbus-Konfiguration, Visualisierung, Safety und MotionControl. Ganz herzlichen Dank für das interessante Gespräch.