Interview. Jetzt geht es erst richtig los.

Transkript

1 Jetzt geht es erst richtig los. 46

2 Das industrielle Internet der Dinge hat ein großes Ziel: Maschinen soll das Sprechen beigebracht werden. Damit es in der Machine-to-machine-Kommunikation nicht zu einer babylonischen Kanalverwirrung kommt, braucht es allerdings eine einheitliche, weltweit gültige standardisierte Semantik. OPC UA ist dieser Standard. Für Stefan Hoppe, Global Vice President der OPC Fundation, ist deshalb der zwischenzeitlich national wie international gesetzte Interoperabilitätsstandard so etwas wie der USB-Stecker für Industrie 4.0. Inwieweit braucht jetzt jemand, der mit Spritzgussmaschinen Kunststoffe herstellt, wirklich Industrie 4.0 oder eine vernetzte Produktion à la IIoT? Es ist egal, in welche Industrie Sie gehen, das ist ja gerade das Faszinierende und Erstaunliche, überall wo Maschinen im Einsatz sind, haben Sie derzeit die gleiche Herausforderung: All diese Maschinen müssen verstärkt miteinander gesichert Daten und Informationen austauschen, horizontal und vertikal und am besten standardisiert. Womit wir auch schon direkt bei Ihrem Thema wären: Dieser Standard wird, so sagen Sie voraus, OPC UA werden. Es bedarf keiner Prognosen mehr! Das haben viele noch nicht ganz begriffen, dass die Würfel längst gefallen sind: Nicht OPC UA wird, sondern OPC UA ist bereits dieser Standard: Seit Juli 2015 im RAMI und auch verpflichtend im Kriterienkatalog für Industrie4.0 Produkte. Es ist quasi amtlich. Alle wichtigen Unternehmen, Verbände und Organisationen, sowohl international als auch auf nationaler Ebene hierzulande haben sich einheitlich auf OPC UA für den Bereich Industrial Automation verständigt, OPC UA ist damit gesetzt. Dann ist Ihr Auftrag im Prinzip jetzt eigentlich beendet? Von wegen. Jetzt geht es erst richtig los. Jetzt geht es darum, in welchen Migrationsschritten denn beispielsweise die Maschinenbauer dahin kommen, dass ihre Maschinen OPC UA-fähig werden. Welche Schritte wären das denn? Schritt 1: Zunächst sollte das Gerät, die Maschine IP-fähig sein, also einen Ethernet-Anschluss haben. Schritt 2 wäre dann, die Integration eines OPC UA-Servers in Angriff zu nehmen. Das ist die eigentliche Hausaufgabe, die Hersteller zu erledigen haben: Dazu muss das Datenmodell der Maschine und das kann ja recht komplex sein beschrieben werden und als Daten- und Service-Interface in dem OPC UA-Server umgesetzt werden. Schritt 3 wäre zu schauen, ob es nicht schon ein genormtes Informationsmodell für die Branche gibt, um direkt dieses umzusetzen. Oder eben selbst die Initiative starten, ein solches zu definieren. Wo steht der OPC UA Server eigentlich genau? Ein OPC UA Server ist kein Hardware-Server-Rack sondern ein Software-Framework. Dieses Stück Software sollte idealerweise direkt im Gerät, in der Maschine untergebracht werden. Allerdings sind auch Gateway-Lösungen als kleine Box vor Sensoren oder bestehenden alten Maschinen denkbar. Ich halte das aber immer für eine Übergangslösung. Idealerweise würde ich immer versuchen, den OPC UA-Server in das Gerät hinein zu integrieren genau dann ergeben sich die Vorteile von OPC UA in einer End-to-End-Lösung und man verliert nicht die OPC UA Eigenschaften an der letzten Meile. Warum? Weil ich dann z.b. die Maschine komplett IT-Security-technisch sozusagen gekapselt abschotten kann. und dann kann ich meine Maschine loslassen auf das Internet der Dinge? Im Prinzip ja. Die ganze Datenwelt der Maschine ist ja bislang kaum für die Außenwelt verfügbar gemacht worden, nun stehen die Dienste nach außen standardisiert zur Verfügung. Es gibt beispielsweise bestimmte Sensoren im IO- Link-Bereich, die könnten noch viel mehr Informationen anbieten und nicht nur den eigentlichen Prozesswert. Zum Beispiel ein Barcode-Reader kann nicht nur sagen: Das ist der Barcode, den ich gelesen haben. Er könnte etwa auch zusätzlich Informationen übermitteln zum Beispiel über den Verschmutzungsgrad der Glasplatte des Lesegeräts, das heißt, ob der Reader noch voll funktionsfähig ist oder nicht. Wenn ich diese Zusatzinformation zur Verfügung stelle, dann weiß ich plötzlich, wann ich den Reader vorbeugend säubern muss, ich erhalte also ganz wesentliche Instandhaltungs- und Maintenance-Informationen. Die Geräte werden auf diese Weise immer intelligenter, können mehr. Und OPC UA ist die Plattform, über die dieses Wissen ausgetauscht wird Exakt, aber das darf man an der Stelle nicht verwechseln: 47

3 OPC UA ist kein Protokoll, sondern wie gesagt ein Framework, ein industrieller Interoperabilitätsstandard, um all diese Daten und Informationen von verschiedenen Herstellern in verschiedenen Branchen kompatibel im Netzwerk mit anderen zur Verfügung zu stellen und gesichert auszutauschen. Das ist es de facto. Grade kleine Unternehmen und Mittelständler sehen aber derzeit in der Frage der Standards und Protokolle gerade den Wald vor Bäumen nicht mehr. Jede Woche wird hier eine neue Sau durchs Dorf getrieben. Derzeit heißt es, die Zukunft gehört TSN-Time Sensitive Networking als eigentlichem Datenaustausch-Protokoll. TSN ist kein Datenaustausch-Protokoll und liefert diese auch nicht in die Cloud. TSN ist quasi ein Ethernet-Echtzeit-Transporttunnel der alle möglichen Datenaustauschprotokolle mit deterministischer Echtzeit transportieren kann. TSN kommt: das ist keine Frage. Aber eine signifikant spürbare Adaption von TSN in der Fabrik wird noch Jahre dauern da z.b. die Konfiguration von TSN-Netzwerken mit Komponenten verschiedener Hersteller erst geregelt werden muss. Das hat aber gar nichts mit der Protokoll-Problematik zu tun. und worum geht es im Unterschied dazu bei OPC UA? Bei OPC UA geht es um das Informationsmodell. Wir haben draußen im Feld einen Pool, einen Wust an unterschiedlichsten Geräten und Maschinen und das Problem lautet hier ganz schlicht und ergreifend: wie schaffe ich es, dass sich Wettbewerber an einen Tisch setzen und sagen: Lasst uns doch mal versuchen auf einen gewissen Rahmen eines Informationsmodells zu verständigen, zum Beispiel, verbindlich zu einigen, wie reagiert unsere Maschine nach außen, welche Datenschnittstellen gibt es, etc. Das wäre ein Riesenfortschritt. Das ist im Übrigen genau die Analogie zum USB-Stecker. Es gibt eine riesige Zahl von Druckern unterschiedlichster Firmen, aber jeder Drucker hat einen USB-Stecker. Intern im Gerät können sich Drucker trotzdem weiter differenzieren, zum Beispiel einseitig oder doppelseitiger Druck, oder schwarz-weiß oder bunt. Was bringen mir die neuen vernetzten Maschinendaten? Wer in der Lage ist, mit analytischen mathematischen Verfahren in einem Datenpool gewisse Korrelationen und Auffälligkeiten bei Datenmustern herauszudestillieren, wird einen wachsenden Wettbewerbsvorteil haben. Beim Thema Predicitve Maintenance ist das für alle sofort mit den Händen zu greifen, was ein solche Datenanalyse für ungeahnte Produktivitäts- und Kostenvorteile bringt, nämlich zum Beispiel, die massive Reduzierung von Stillstandzeiten. Das Schöne ist aber ja: Das Vorgehen ist nahezu universell auf alle Geschäftsprozesse übertragbar und da frage ich mich, wird da dann eine ganz neue Software-Spezialisten-Elite heranwachsen, oder wird das wie bei den Mechatronikern eine Verschmelzung mit den Technikern, den Ingenieuren geben? Außer Smart-Data-Vorteilen, was ist eigentlich der direkte Nutzen von OPC UA? Durch OPC UA wird es schlicht einfacher 1. Geräte zu integrieren in einem IT-Umfeld ohne erst alle Details und Hexcodes im Handbuch zu lesen. 2. Mit OPC UA ist man in Punkto Security auf der sicheren Seite. Sicherheit ist sozusagen systemimmanenter Bestandteil von OPC UA. 3. Ich habe eine höhere Durchlässigkeit der Daten. In der klassischen Automatisierungspyramide ist klar festgelegt, wer mit wem kommunizieren kann und darf. In der neuen Welt von Industrie 4.0 kann jetzt plötzlich jeder mit jedem kommunizieren, wenn es erforderlich ist, das ist rein eine Frage wie es das interne Rollenspiel festlegt und die Zugriffsrechte geregelt werden. In der neuen Welt, kann, wenn gewünscht, der RFID-Reader oder die Maschine direkt an der SPS vorbei oder parallel dazu in die Cloud kommunizieren, auch die SPSen können, wenn gewünscht, direkt untereinander kommunizieren. Aus kommunikationstechnischer Sicht ist die Automatisierungspyramide im Grunde aufgehoben und nurmehr eine leere Hülle. Organisatorisch bleibt sie natürlich bestehen, denn eine Fabrik muss weiter wissen, was sie produziert. Ist bei soviel n-zu-n-kommunikation in den Anlagen dann nicht auch kriminellen Kräften Tür und Tor geöffnet? Keineswegs. Ich gebe Ihnen aber insofern recht, dass speziell bei den kleinen und mittleren Betrieben das Wissen um IT-Security doch noch etwas dürftig ausgeprägt ist. Da wird dann gerne stolz behauptet, man arbeite ja über sichere VPN-Tunnels nach draußen. Das ist natürlich Quatsch. VPN-Tunnel sind per se nicht sicher. VPN hat nichts mit Security zu tun. 48

4 Und warum OPC UA schon? OPC UA ist letztlich auch deswegen als verpflichtend für Industrie 4.0 gesetzt, weil OPC UA sozusagen ein integriertes IT-Sicherheitskonzept hat. Es ist der einzige Industrial Automation Standard mit Security integrated by design. Was heißt das in der Praxis genau? Authentifizierung, Signierung und Verschlüsselung wurden beim Design von OPC UA direkt integriert. Sie können damit jeden einzelnen Datenpunkt oder jedes Interface, welches eine Maschine anbietet, nach draußen eigenständig mit Security-Mechanismen belegen und für verschiedene Rollen z.b. dem SCADA-/MES-/-ERP System oder dem Service-Techniker freigeben. Und nach drinnen, von draußen zurück in die Anlage? Hier liegen doch die großen Befürchtungen der Anlagenbetreiber. Wie soll das gehen? Es geht. Und zwar völlig egal, in welche Richtung. OPC UA ist ein Interoperabilitäts-Standard. Das ist ja genau sein Vorteil gegenüber all den anderen Ansätzen, die meist nur in eine Richtung gehen. OPC UA hat zwei Kommunikations- Paradigmen sozusagen unter der Haube. Das eine ist: OPC UA kann Client-Server-basiert arbeiten nach dem Muster des bestätigten Dienstes, also TCP/HTTPS-basiert, aber eben genauso auch nach dem Publisher-Subscriber- Prinzip, wenn es nur um die schnelle Verteilung an viele Zuhörer gehen soll. Für so etwas benutzt man normalerweise UDP, AMQP oder MQTT. Beide Welten hat OPC UA sozusagen on board. Man benötigt also nicht xyz diverse Protokolle für verschiedene Szenarien: mit denen wir 49

5 die Daten hin und herschieben. Das führt am Ende nur zu einer babylonischen Kanalverwirrung und wir haben keine einheitliche Semantik. Lassen Sie uns raten: genau das bietet OPC UA? Ja, exakt: Egal ob Sie nun über Client/Server oder Publisher/Subscriber Mechanismen die Daten per OPC UA kommunizieren, das wirklich wichtige ist die Beschreibung der Daten die Semantik. Brauchen wir denn dann in der OPC UA-Welt überhaupt noch SPSen? Wird die Business Intelligence, also zum Beispiel SAP, über kurz oder lang nicht direkt mit der Maschine oder dem Sensor zu reden versuchen? SAP kann schon heute Maschinen oder Geräte mit OPC UA Schnittstelle innerhalb von 20 Minuten integrieren und die notwendigen Aktionen für den Fluss des Produktes durch eine Produktion orchestrieren. Ein SAP hat aber kein Echtzeitwissen, um eine Roboterachsenregelung selbst zu rechnen und abzufahren. Warum auch. SPSen brauchen wir weiterhin für die Aufgabe, für die sie mal ursprünglich geschaffen wurde: Daten in harter Echtzeit zu verarbeiten und direkt einen Prozess zu steuern auch wenn die gesamte Kommunikation nach oben zum MES oder der Cloud nicht vorhanden ist. Es sollte aber doch anerkennend festgestellt werden, dass die SPS-Hersteller und auch Feldbusorganisationen ganz vorne bei der Standardisierung der Daten in OPC UA dabei waren und sind: Die SPS-Hersteller innerhalb der PLCopen haben bereits 2010 eine sogenannte Companion- Spezifikationen für OPC UA zusammen erstellt also z.b. eine gemeinsame Semantik festgelegt. Auch im IO Bereich passiert das wie z.b. mit IO-Link oder den Feldbuss- Systemen SERCOS, EtherCAT, ProfiNET, Powerlink, CClink und CAN in Automation. Und am Ende wird es heißen, es kann nur noch einen geben. Wie lange wird es dauern, bis sich OPC UA in breiter Front in der Industrie durchgesetzt haben wird? Die Erfahrung bei der Einführung von Standards zeigt: Das geht nicht von heute auf Morgen im Hauruck- Verfahren. Das ist ein Durchdringungsprozess, der viele Jahre dauert, ich rechne grob mit einer Dekade. Aber nicht, dass Sie mich hier falsch verstehen. Der Feldbus innerhalb der Maschine wird nicht durch OPC UA verschwinden, dafür ist OPC UA nicht ausgelegt, auch mit TSN nicht. OPC UA wird aber Maschinen verbinden, nicht über Bit & Byte-Austausch, sondern über Dienste. Das wird derzeit gerne in der Automatisierungs-Branche kolportiert: Das Internet der Dinge via OPC UA zu realisieren ist nur mit TSN wirklich zu schaffen und das wird noch dauern. Das ist Propaganda. OPC UA braucht zum Funktionieren kein TSN. Seit vielen Jahren wird bereits die Maschine-zu- Maschine-Kommunikation über OPC UA realisiert. Das ist die eigentliche Technologie, die Daten und Informationen gesichert austauscht. Und das geht heute auch schon schnell, im Zwei-bis Fünf-Millisekunden-Bereich, diese Performance kann man aber eben nicht garantieren. Dort, wo Sie es garantieren müssen, dort braucht man dann in der Tat TSN. Das ist dann nochmals eine höhere Güte, die dazu kommt. Wieso ist es so komplex, zwei Maschinen miteinander sprechen zu lassen? Der Laie denkt sich: Zwei Maschinen tauschen Daten aus, das kann ja so schwer nicht sein, aber es gibt verschiedene Kategorien von Informationen, zum Beispiel die reinen Livedaten wie ein Stückzahlzähler, oder Alarme und Events, bei denen der Austausch von Daten nur zu gewissen vorher fest definierten Ereignissen erfolgt. Historische Daten werden gar nicht zyklisch kommuniziert, sondern auf Anfrage sollen Daten der Vergangenheit verfügbar gemacht werden. Das alles sind in OPC UA letztlich vom Konzept her bereits vorhandene Dienste, die OPC UA von Haus aus mitbringt. Aber das Internet der Dinge mit vernetzt arbeitenden Maschinen ist das noch lange nicht Ja, das ist nur ein Teilaspekt der Schlüssel ist weiterhin die Beschreibung der sogenannten Dinge. Wo ist also die Bibliothek der Beschreibung der Dinge? Die OPC Foundation hat zumindest die Definition für den Bereich Industrial Automation mit vielen Partnern angefangen. Wo ist OPC UA näher dran, am amerikanischen IoT oder am Deutschen Industrie4.0 -Konzept? IIC und die Plattform Industrie 4.0 haben zwei unterschiedliche Ansätze. Beim IIC geht man eher Einzelfall- und Einzelproblem-lösungsorientiert vor: Verschiedene Firmen definieren in einem Testbed, was sie zusammen lösen und dann auch promoten wollen. Industrie 4.0 hat einen viel spezielleren Ansatz in Richtung Fabrik, was die Amerikaner dann eher unter Smart Factory subsumieren, was ein Teil von IoT ist. Industrie 4.0 ist aber ganz konkret Richtung Produktion aufgestellt. Sicherlich kann man vieles aus diesem Bereich auch im Grunde universell übertragen auf andere Branchen zum Beispiel 50

6 die Energiewirtschaft, die Logistik oder die intelligente Gebäudetechnik. Industrie 4.0 klingt manchmal ein wenig akademisch ist aber eine grandiose Plattform, auf die auch die China2025-Initiative und die Koreanische Manufacturing Initiative 3.0 ganz intensiv und begeistert schaut. Unsere Gründlichkeit, mit der wir Dinge zuerst durchschauen wollen, wird hier im Land manchmal als zu lahm belächelt im Ausland wird das eher als deutsche Tugend, also als strukturiert und gründlich geschätzt. Sehr stark vereinfacht finden wir hier in Europa eher den Zugang über unser Maschinen-Technik-Know-how, nicht zuletzt, weil wir über die Jahre dezidiertes Embedded- Wissen entwickelt haben. Die Amerikaner sind häufig schneller im Thema über die Geschäftsmodelle. Wie gewinnt man das Rennen? Mit tiefem Maschinen-Know-how sollten wir gute aber auch schneller Normen und Standards setzen und Fakten schaffen. Findet jetzt zwischen Amerikanern und uns nicht bereits eine Art Wettrennen um die Macht im Shop-floor statt? Amerikaner beherrschen mit Google weltweit das Internet des Wissens, mit Facebook das Internet der Menschen. Wir sind seit vielen Jahren Exportweltmeister im Sondermaschinenbau und haben exzellentes Ingenieurwissen für Maschinenbau, Elektrotechnik der Informatik und andere Disziplinen. Das Rennen um das Internet der Maschinen halt ich für mindestens offen. ZUR PERSON Stefan Hoppe ist seit Januar 2010 in seiner Funktion als Präsident von OPC Europe innerhalb der OPC Foundation tätig. Am 1. Dezember 2014 wurde er in den OPC Vorstand berufen.1995 stieß Hoppe zu Beckhoff Automation, wo er als Softwareentwickler in der TwinCAT-Software Gruppe tätig war und den OPC-DA Server in TwinCat implementierte. Später arbeitete er als TwinCAT Produktmanager, wobei der Schwerpunkt seiner Arbeit auf TwinCAT 3, Konnektivität und Embedded-Software-Produkten lag.stefan Hoppe hat einen Abschluss in Elektrotechnik der Universität Dortmund. Hierfür forschte er an fahrerlosen Transportsystemen (FTS) am Fraunhofer Institut IML, Dortmund wurde er von Microsoft mit dem MVP (Most Valuable Professional) Award für Embedded Software ausgezeichnet. 51