Ist ein Freigehege genug? PLM-Strategien und Industrie 4.0

Die Computerwoche beschäftigte sich in einem lesenswerten Artikel  mit Industrie 4.0. Darin fand sich ein interessanter Aspekt: Der Trend im Softwarebereich geht weg von großen, monolithischen Alleskönnern und hin zu spezialisierten Teillösungen, die sich eng miteinander verknüpfen lassen. Das bedingt gut dokumentierte, offene Schnittstellen – ein Thema, mit dem sich der Bereich der technischen Software seit Jahrzehnten herumschlägt. Die Anbieter reagieren mit einer Ausweitung ihres Portfolios – aber ein Freigehege ist immer noch ein Gehege mit einem Zaun drum herum.

Fragt man die Softwareanbieter nach Industrie 4.0, hat praktisch jeder eine Lösung im Portfolio. Die Verknüpfung von Daten und Geometrie, der Schwenk zu Mechatronik und, einen Schritt weitergehend, zu softwarezentrierten Produkten und die globale Verknüpfung der Computersysteme sind für CAD– und PLM-Anwender nichts Neues. Doch es fällt schon auf, dass jeder Anbieter sein Produktportfolio als komplette Industrie 4.0-Lösung anpreist, also doch wieder in „sortenreinen“ Strukturen denkt. Alles aus einer Hand – so nachvollziehbar es ist, dass ein Anbieter alle Bedürfnisse des Kunden abdecken möchte, so sehr widerspricht dies der Idee von Internet der Dinge, Industrie 4.0, Web 3.0, Big Data, Social Media und wie die gängigen Hype-Begriffe alle lauten.

Die Idee hinter den neuen Entwicklungen ist ja gerade, dass Informationen Software- oder Genregrenzen überwinden, mit Informationen aus vielen anderen Systemen kombiniert und zu etwas Neuem verknüpft werden. Smartphone-Apps zeigen, wo es hingeht. Ein gutes Beispiel ist Flightradar24, eine App beziehungsweise Website, die die Position und andere Daten von Verkehrsflugzeugen live anzeigt. Die Software arbeitet mit den ADB-S-Daten, die etwa 70 Prozent der Flugzeuge per Funk abstrahlen, und die von Enthusiasten im Internet verfügbar gemacht werden. ADB-S enthält neben Identifikationsdaten wie Flugnummer und Flugzeugkennzeichen Position, Kurs, Flughöhe und weitere Daten – diese werden eigentlich von der Flugsicherung genutzt. Flightradar24 nutzt diese Daten, um die Flugzeuge auf einer Google Maps-Karte darzustellen. Beim Klick auf ein Flugzeug werden die ADB-S-Daten gezeigt, kombiniert mit der Flugroute, die sich Flightradar24 wahrscheinlich anhand der Flugnummer aus den Datenbanken der Fluggesellschaften holt. Zudem wird ein Bild des Flugzeugs angezeigt, das von Planespotters.net kommt. Flightradar24 ist also nichts anderes als eine Kombination von Daten aus verschiedenen Quellen – Google Maps, Fluggesellschaften, Planespotters, ADB-S – zu einem neuen Dienst.

Dieses Beispiel zeigt, wohin die Reise geht. Die Nutzung von Google Maps ist beispielsweise auch bei der Fernüberwachung beziehungsweise -wartung von Bau- oder Landmaschinen und Autos interessant – und schon haben wir eine Verknüpfung von PLM- (oder, wie PTC sagen würde, SLM-)System und einem Webdienst. Google hat die API (Programmschnittstelle), über die das PLM-System an die Kartendaten kommt, implementiert – aber in der anderen Richtung, also der Ausgabe von PLM-Daten an andere Systeme, sieht es eher düster aus.

Die Kopplung an ERP-Systeme ist weit fortgeschritten, aber es kommen proprietäre Schnittstellen CAD-System A zu ERP-System B – oder sogar Übersetzungsprogramme zum Einsatz. Industrie 4.0 erfordert, dass jedes System eine offene, einfach anzubindende und von jedermann zu nutzende API hat. Ich glaube, dass die Zeiten vorbei sind, in denen sich Anwender und Anwendungen in einem virtuellen Gehege – einer Insellösung – einsperren lassen,  so ärgerlich das auch für den Vertriebler sein mag. Man kann die Einkaufsfeldzüge der CAD-Anbieter in den letzten Jahren als Versuch werten, das Gehege auszuweiten, aber diese Strategie wird an Grenzen stoßen. Am Ende wird der Markt die offene Lösung bevorzugen, da bin ich mir sicher.