Vernetzte Standards für vernetzte Systeme und Prozesse

Die Entwicklung und Fertigung intelligent vernetzter Produkte für Industrie 4.0 und Internet of Things (IoT) spielt sich in agilen Kompetenz-Netzwerken mit einer Vielzahl neuer Player ab. Für den Informationsaustausch der Partner sind nicht unbedingt neue Standards vonnöten. Vielfach wäre ihnen schon geholfen, wenn man die vielen vorhandenen Standards intelligent miteinander kombinieren und konsequenter anwenden würde.

Offenheit und Standards sind die Voraussetzung für eine reibungslose Kommunikation. Insofern bedeuten Industrie 4.0 und IoT eine große Herausforderung auf dem Gebiet der Standardisierung, denn plötzlich müssen die unterschiedlichsten Elemente miteinander kommunizieren: das Auto mit seiner Umgebung, z. B. mit einem anderen Fahrzeug oder dem Parkhaus, die Systeme eines Autos untereinander und ihre einzelnen Komponenten vielleicht noch mit den Fertigungs- und Montageeinrichtungen. Produkt, Prozess und Ressourcen müssen also IT-gestützt vernetzt werden, was nicht der bisherigen Praxis der Standardisierung entspricht. Bislang gab es, fein säuberlich getrennt, produkt-, prozess- und ressourcenbeschreibende Standards. Deshalb wird gelegentlich der Ruf nach einem übergreifenden Standard laut, der nach Möglichkeit alle diese Anforderungen erfüllt.

So verständlich dieser Ruf ist, er ist auch gefährlich. Die jahrzehntelange Erfahrung auf dem Gebiet der Standardisierung lehrt, dass für die Entwicklung eines solchen Super-Standards Zeit, Geld und letztlich auch die Geduld fehlen. Und selbst wenn alle drei Ingredienzien im Überfluss vorhanden wären, hätte die Standardisierung kaum Aussicht auf Erfolg, weil sich das IoT viel zu dynamisch weiterentwickelt. Außerdem ist ein Standard, der vom Anspruch her alles beschreiben können soll, in einer Zeit, in der alle Welt von föderierten IT-Systemen und intelligent verlinkten Informationen schwärmt, nicht mehr zeitgemäß. Wenn Produkte und Systeme vernetzt werden, warum nicht auch die Standards?

Informationen zu verlinken statt auszutauschen ist en vogue, weshalb OSLC als Standard der Zukunft gefeiert wird, obwohl die Idee der Verknüpfung von Informationen per Tag und Anchor fast so alt ist wie das Internet. So gut diese Verlinkung innerhalb der Unternehmen funktioniert, um Anwendern Informationen systemunabhängig zur Verfügung zu stellen oder alle von einer Änderung betroffenen Instanzen miteinander zu verknüpfen – für die Kommunikation über Unternehmensgrenzen und Firewalls hinweg ist sie nicht nutzbar. Dafür brauchen wir weiterhin den guten alten Datenaustausch, der ohne Standards nicht funktioniert. Sie werden sogar immer wichtiger, weil der Collaboration-Bedarf zunimmt.

Vernetzung von mehreren Standards

Aber welche Standards brauchen wir? Ausgehend von der Annahme, dass sich ein Großteil der Kommunikationsanforderungen mit den heute verfügbaren Standards bewältigen lässt, hat der ProSTEP iViP Verein einmal die Landschaft erforscht. Dabei zeigte sich, dass es allein für die Produktbeschreibung ein riesiges Set an nationalen und internationalen Standards gibt, die sich zum Teil funktional überlappen und deren Protagonisten miteinander rivalisieren. Es ist deshalb an der Zeit, alte Zöpfe abzuschneiden. 

Das heißt nicht nur, sich von älteren Standards wie IGES oder VDA-FS zu verabschieden, deren Pflege Ressourcen bindet, die vielleicht besser in die Implementierung neuer Standards fließen sollten. Es geht auch um ein neues Denken: Statt miteinander zu rivalisieren, sollte man sich darauf verständigen, welche Standards wo ihre Stärken haben und sie miteinander kombinieren. Ein gutes Beispiel für diesen pragmatischen Ansatz ist die Kombination von STEP AP 242 XML und JT.

Ähnlich pragmatisch geht der ProSTEP iViP-Verein beim Projekt "Synced Factory Twin" vor. Ziel ist es, den Informationskreislauf zwischen Entwicklung, Produktionsplanung und Produktion zu schließen, sodass Informationen in beide Richtungen fließen können. Aber nicht auf der Basis eines ultimativen Datenmodells, sondern ausgehend von der Frage, welche Informationen an welcher Stelle im Prozess wirklich gebraucht werden. Und die werden dann von der Entwicklung über die Produktionsplanung bis zur Maschine und wieder zurück über Standards wie STEP AP 242 XML, AutomationML und OPC UA bereitgestellt. Vielleicht lässt sich mit dieser Kombination nicht jeder Anwendungsfall abdecken, aber man schafft mit einem Aufwand von 20 Prozent eine 80prozentige Lösung.

Zeit in eine Standardisierung zu investieren, die nicht genutzt wird, heißt Geld zum Fenster hinauszuwerfen. Das Standardization Strategy Board von ProSTEP iViP und VDA hat die Kombination von STEP AP 242 XML und JT schon 2012 zum verbindlichen Set von Standards für die Geometrie-Beschreibung in der Automobilindustrie erkoren. Trotz offizieller Commitments wird diese Kombination in der Breite noch nicht konsequent angewandt. Ohne sie aber wäre eine Kooperation wie die zwischen Renault, Nissan und Daimler produktdatentechnisch schwer realisierbar. Die drei Partner haben zugleich den Beweis erbracht, dass vernetzte Standards funktionieren.

Standards müssen sich in der Praxis beweisen

Natürlich spielen für cybertronische Produkte mit ihrem hohen Elektronik- und Softwareanteil ganz andere Informationen als Geometriedaten eine Rolle, und richtig ist auch, dass es für ihren Austausch zum Teil noch keine Standards gibt. Aber man kann heute Anforderungen über den ReqIF-Standard statt dokumentenbasiert austauschen und man kann Verhaltensmodelle als Functional Modeling Units (FMU) über FMI-Schnittstellen an Zulieferer übertragen, um sie beispielsweise im Zusammenspiel mit anderern FMUs zu simulieren. Der Einwand, dass das in den FMUs steckende Know-how beim Austausch nicht perfekt geschützt ist, spricht nicht gegen die Anwendung des Standards. Man kann die Basismechanismen schon mal mit vertrauenswürdigen Partnern nutzen, um einen Erfahrungsvorsprung zu gewinnen, und gleichzeitig die Mechanismen für IP-Schutz und Security weiter entwickeln.

Standards müssen sich in der Praxis beweisen. Wir neigen in Deutschland dazu, alles 150-prozentig abzusichern, und testen uns darüber manchmal zu Tode. Ganz anders das Industrial Internet Consortium (IIC) in den USA, das pragmatisch standardisierte Lösungen für bestimmte Use Cases entwickelt und implementiert, um Erfahrungen zu sammeln, die in die Weiterentwicklung der Standards einfließen. Ein bisschen mehr von diesem Pragmatismus könnten wir auch in Deutschland brauchen, um von den Standards zu profitieren, deren Entwicklung wir maßgeblich mitbestimmt haben: selbst zu standardisieren ist immer besser als standardisiert zu werden.