Wo sehen Sie global, also nicht nur für Bachmann betrachtet, die wesentlichen Trends im Engineering von Automatisierungstechnik?
Scharf: Der primäre Zukunftsmarkt wird ganzheitliches Engineering sein. Das heißt, wir betrachten nicht nur die Elektronik, Soft- oder Hardware, sondern alle Gewerke zusammen, was z.B. im Maschinenbau auch die Hydraulik usw. einschließt. Wir sehen alles als ein System, das man bearbeitet. Ein weiterer Trend ist sicherlich Datenmanagement. Diagnose, mit allem was dazugehört, und die daraus folgenden Schritte, mit mehr Daten über den Prozess, denn der steht jetzt im Vordergrund. Wenn ich mehr Daten über den Prozess habe, dann kann ich diesen besser verstehen, Fehler finden und ihn optimieren.
Hat das auch etwas mit dem Thema Condition Monitoring zu tun, wo Bachmann ja auch zuhause ist?
Scharf: Genau das wäre der nächste Schritt. Condition Monitoring ist im Prinzip genau der Grund, warum wir eine Firma zugekauft haben, dass wir aus dem Umfeld mehr Daten zur Verfügung haben, den Schritt auch aus dem Prozess raus. Der Prozess selbst ist immer im Rahmen des Umfelds zu betrachten. Das Umfeld ist in dem Fall nicht nur das Condition Monitoring, das wir dort speziell betrachten, sondern das Umfeld ist eben auch das weiterführende System. Das Stichwort Industrie 4.0 spielt da z.B. eine Rolle. Sodass es eben die beiden größeren Bereiche gibt: den Prozess, das Umfeld um den Prozess und die Anbindung an weitere Systeme. Bachmann ist ja stark als Kommunikations-Prozessor und das werden wir, denke ich, noch weiter ausbauen.
Sie haben das Stichwort Industrie 4.0 schon genannt. Das ist in etwa das große Bild, die große \’Wolke\‘. Wenn man es auf die tägliche Praxis herunter bricht – wo glauben Sie, dass den Anwendern beim Engineering, speziell dem Maschinenbau der Schuh am meisten drückt?
Scharf: Ich würde da einen Schritt zurückgehen und fragen: \“Wer braucht Industrie 4.0?\“ Das Gefälle zwischen denen, die eine Kleinststeuerung einsetzen, und denen die eine Bachmann-Steuerung, also ein Experten-System, einsetzen, ist sehr stark. Und genau so sehe ich das auch bei den Industrie 4.0-Kunden. Das machen wir teilweise schon, wenn man das einmal ein wenig aus dem Mystischen heraus in die Realität überführt. Auch heute sehen wir, dass relativ viele Kunden Teile davon nutzen, aber nur dann, wenn sie diese komplett und fertig erhalten. Selbst auf die Idee kommen oder selbst einbauen ist sicherlich nicht, einfach weil das Wissen nicht da oder auch die Notwendigkeit teilweise einfach nicht vorhanden ist. Wenn ich eine Verpackungsmaschine als Beispiel nehme, dann ist das durchaus sinnvoll. Bei einer Maschine aber, die für sich ganz alleine auf der Welt steht, und davon gibt es nicht wenige, stellt sich die Frage, ob Industrie 4.0 dort jemals ankommen wird.
Nehmen wir den klassischen Maschinenbauer mit seiner Spritzgieß- oder seiner Verpackungsmaschine. Bezogen auf das Engineering – was ist aktuell sein größtes Problem?
Scharf: Da denke ich mir – deswegen auch die Eingangsfrage \’Wer braucht Industrie 4.0?\‘ -, das größte Problem ist sicherlich der Austausch von Informationen ganz allgemein, also zwischen den Gewerken. In den allermeisten Fällen ist es auch heute noch so, dass der Maschinenbau das führende Gewerke ist – das Projekt startet mit der Erstellung der mechanischen Komponenten. Ich sage das jetzt mal ganz locker: Irgendjemand kommt auf die Idee, \“da brauchen wir ein bisschen Elektromechanik\“, dann werden Sensoren eingebaut, und schon an dem Punkt werden diese mechanisch eingebaut. Logisch schaut dann der Maschinenbauer drüber. Dann, ganz zum Schluss, wenn die Anlage fertig gebaut ist, stellt der \’Softwerker\‘ fest, dass der Sensor an der falschen Stelle sitzt oder nicht verkabelt werden kann. Das hört sich witzig an, ist aber gelebte Praxis.
Ich sehe diese Engineering- übergreifende Thematik auch so. Meine Frage dazu wäre, wie Bachmann solchen Anforderungen begegnet? Welche Philosophie verfolgt Bachmann an der Stelle?
Scharf: Bachmann selbst hat vor langer Zeit auf Eclipse als Basis gesetzt. Eclipse ist ein sehr offenes Tool. Wir haben das Plug-in-Konzept, das Eclipse zur Verfügung stellt, genutzt und stellen unseren Kunden die Möglichkeit, zur Verfügung selbst Plug-ins zu schreiben und damit selbst Schnittstellen für die entsprechenden CAD-Systeme zu schaffen. Wir haben Kunden, die heute noch nicht produktiv damit arbeiten, aber solche Schnittstellen haben wollen oder dabei sind diese selbst zu implementieren. Dann haben wir auch Kunden, die aus dem Market-Place Plug-ins benutzen. Was wir in näherer Zukunft noch tun werden, ist sicherlich entsprechende Tools und Zugänge zu AutoCAD bzw. CAD-Software im Allgemeinen zur Verfügung zu stellen. Was wir auf Programmierebene schon seit 15 Jahren tun, ist, dass wir ein Komponenten-orientiertes System haben. Im Gegensatz zur klassischen SPS haben wir einzelne Komponenten, bei uns heißt es Software-Module, die über eine standardisierte Schnittstelle miteinander kommunizieren. Diese Software-Module können in C/C++, IEC61131 oder Matlab/Simulink programmiert und in einer programmierbaren Konfigurations-Oberfläche konfiguriert werden. Man kann bei uns schon immer, was unsere Kunden auch ganz fleißig tun, mehrere Software-Module miteinander verschalten und daraus die Applikation zusammenstellen. Variantenmanagement, das immer ein wenig mitschwingt, ist so relativ einfach zu behandeln. Es gibt relativ viele Kunden bei uns, die diese Schnittstellen-Problematik so gelöst haben, dass sie über unserem System noch ein eigenes System haben, wo alles zusammenläuft. Da hängen Software-Module dran, die dann automatisch konfiguriert werden und auf Knopfdruck eine Anlage, also nicht nur den Software-Part, sondern auch den Maschinenbau-Part, konfigurieren, können.
Können Sie vielleicht eine kurze Abgrenzung zwischen Komponenten-basiert und Objekt-orientiert machen?
Scharf: Die Diskussion kommt immer wieder auch bei uns im Hause auf. Komponenten-orientiert heißt für uns, dass eine in sich selbst-abgeschlossene Komponente besteht, die testbar, programmierbar und einsetzbar ist. Die ist nicht im Quellcode vorhanden, sondern im Objekt-Code, sprich fix und fertig lauffertig. Objekt-orientiert, dafür benutzen wir überwiegend C++ oder Java als Sprache, ist ein Teil, wie ich etwas aufbaue, weniger die Komponente selbst. Objekt-orientiert wäre, dass man dort alles mitbringt, das kann eine Komponente heute noch nicht.
Sie haben bereits den Punkt angesprochen, wie Kunden von Bachmann programmieren. Ich würde es gerne noch ein wenig allgemeiner fassen: Wohin entwickelt sich die Welt der Steuerungsprogrammierung?
Scharf: Wir denken, dass die Welt professionalisierter wird. Wenn man einen kleinen Abriss nimmt, dann hat man damit angefangen, dass man die Schütze gegen eine Steuerung ausgetauscht hat. Teilweise ist dieser Gedanke auch noch in vielen Unternehmen vorhanden. Wir werden dahin kommen, dass man das Automatisierungssystem nicht mehr als Steuerung sieht, sondern als Programmier-Element, wie es heute schon in der IT-Technik ist. Damit werden dann aber auch alle Möglichkeiten und Techniken, die in der IT-Welt gut und ausgetestet sind, in entsprechender Form zur Verfügung gestellt. Aus diesem Grund stellen wir unseren Kunden den Eclipse-Market-Place zur Verfügung, dort können unsere Kunden heute schon alles nutzen, was die IT-Welt zur Verfügung stellt. Zum Beispiel werden schon aktiv die Tools zum Test-Driven-Development genutzt. Gerade im C/C++ Bereich wird das aktiv genutzt.
Wo sehen Sie, bezogen auf das Engineering, noch weitere Einflüsse der IT-Welt, die im Allgemeinen einen immer größeren Einfluss auf die Automatisierungstechnik hat?
Scharf: Mit meinem Kollegen, dem Engineering-Pendant, habe ich regelmäßig diese Diskussion. Er ist zehn Jahre jünger als ich und diese zehn Jahre machen sich dann doch bemerkbar. Für mich ist Automation in der Cloud immer noch so ein Punkt, bei dem ich mir denke: Ich möchte eigentlich nicht mit etwas in 1.000km Entfernung verbunden sein, was ich weder sehe noch wo ich weiß, was da gerade passiert und ich programmiere darauf. Das ist nicht meine Welt, aber das wird definitiv kommen. Ob es nun in fünf Jahren ist oder in zehn Jahren, da wage ich keine Prognose zu treffen. Ob es auch so umgesetzt wird, wie ich es gerade beschrieben habe, kann ich ebenfalls nicht beurteilen – aber es wird definitiv kommen. Was ich mir eher denke, was jetzt näher in der Programmierwelt ist, sind Domain Spezifische Sprachen DSL. Dass man also anfängt zu vereinfachen, wie man programmiert. Dass es dorthin gehen wird, nicht unbedingt Objekt-orientiert zu arbeiten. Ich denke der Schritt ist zu groß, da es noch zu viele Leute gibt, die mit Objekt-orientiert gar nichts anfangen können. Ich glaube, dass man spezifisch Sprachen entwickelt, um das Programmieren für andere Anwender zu vereinfachen. Dass es zwei Arten von Programmierern geben wird: den Experten, der sich wirklich intensiv mit der Software, und dann auch wirklich nur mit der Software auskennt, und den Anwender, der die Anlage zum Laufen bringt und der dann spezielle Funktionen betreut. Dann verpackt man das in Funktionsbausteine und hinterher wird es speziell für eine Industrie, Firma oder ein Produkt entsprechende Sprachen mit entsprechender Grammatik, die an den Prozess und nicht an die IT-Werker angepasst sind, geben. Da bin ich mir sicher, dass es einen Unterschied geben wird, denn die IT kennt keine Hardware, das ist in der Automatisierung grundlegend anders.
Was sind aus Ihrer Sicht die wesentlichen Treiber dieser Entwicklung, die Sie grade skizziert haben? Sind das gerade die jungen Ingenieure, die frisch von der Hochschule kommen und überwiegend im weitestene Sinn hochsprachen-versiert sind? Oder sind das eher die technischen Notwendigkeiten, die aus der Applikation herauskommen, da die Maschinen einfach zu komplex werden?
Scharf: Ich glaube nicht, dass man das auf das eine oder das andere spezifizieren kann, sondern eher, dass das eine das andere bedingt. Zum Einen steht die technische Anforderung, die wir am Anfang schon erwähnt haben: Um mehr Daten zu strukturieren und Informationen herauszubekommen, muss ich eine andere Art und Weise des Programmierens haben. Da komme ich mit ST einfach nicht mehr weiter, das ist dafür nicht gemacht. Also muss ich in C/C++, C#, Java oder einer anderen IT-Hochsprache programmieren. Dafür brauche ich den jungen Mann, der bringt dann automatisch wieder neue Ideen mit, die die Technik beeinflussen. So ist das sicherlich ein Spiel zwischen beidem. Ich denke mir, dass die Technik der Grund ist, aber nicht der Treiber.
Die Automatisierungswelt spricht schon seit vielen Jahren von Integration. Wenn man sich das genauer betrachtet, dann stellt man fest, dass jeder das für sich anders definiert. Was versteht Bachmann darunter?
Scharf: Die Frage so platt zu beantworten fällt mir schwer. Wenn ich die Integration auf unser primäres Produkt betrachte, dann ist unsere Antwort das SolutionCenter, indem ich sage: Wir betrachten alles zusammen. Steuerung ist also nicht nur Hardware oder Software, sondern eine Kombination aus beidem. Wenn ich Integration so betrachte, dass ich alle Gewerke zusammensetze, dann würde ich sagen, da haben wir, genau wie alle anderen Steuerungshersteller, sicherlich auch noch etwas zu tun. Das wäre für mich so ein Punkt, wo ich sage, AutomationML oder CADex sind da sicherlich der Vorstoß in die richtige Richtung. Ansonsten ist das, was Bachmann unter Integration versteht, sicherlich offen, im Sinne von \’wir sind offen für jede Schnittstelle\‘. Eclipse wäre ein Punkt – sicherlich in dieser Sache auch sehr flexibel. Wir haben festgestellt: Es gibt keinen Workflow, der einheitlich ist, sondern jeder Kunde hat seinen eigenen Workflow. Ich will nicht sagen, dass die nicht ähnlich sind, aber alle haben definitiv ihren Eigenen. Der letzte Punkt: Ein entscheidender Faktor für Integration ist, dass es performant ist. Das mag in den ersten Schritten niemand so sehen, aber ein Tool, auf das ich warten muss, ist nicht nutzbar und macht einfach keinen Spaß. Damit ist es dann auch egal, ob es noch so toll integriert ist, es ist einfach nicht nutzbar.
Wie glauben Sie, macht jemand in fünf Jahren das Engineering für die Steuerung oder sein Automatisierungssystem?
Scharf: Zehn Jahre wären mir da wohler. In zehn Jahren wird es wahrscheinlich die ersten Anwendungen geben, die wirklich verteilt sind. Es wird die ersten 100%ig funktionierenden Tools geben, wo ich mit dem ersten Mausklick im CAD-System und dem letzten Klick bei der Fertigstellung der Anlage in einem Tool bleibe, oder zumindest in einer Workbench. Da werden die Schnittstellen alle funktionieren, da werden auch die Hardware-Elemente eingebunden, die ich heute noch nicht kenne oder bei denen wir heute noch lange nicht so weit sind. In zehn Jahren werden wir auch an dem Punkt sein, dass es Apps gibt, ähnlich wie jetzt im App- oder Google-Store, sodass es die Möglichkeit gibt, Funktionalitäten einfach dazuzukaufen. Ich muss zugeben, auf dem Handy etwas zu installieren ist eine Sache, aber auf einer Anlage ist das etwas anderes. Wenn ich mir einen PID-Algorithmus vorstelle, damit hätte ich jetzt auch kein Problem – wenn der Algorithmus aber Zugriff auf die Hardware hat, dann wäre das etwas anderes.
Herzlichen Dank für die Einblicke in die Welt des Engineering.
