Dieser Beitrag ist im Juli 2018 erschienen
Am 17.07.2018 bin ich mal wieder nach Lemgo zu einer Veranstaltung "Digital ist nicht gleich Digital - Standards der vernetzten Produktion: Retrofit und OPC UA" gefahren. Es gab mehrere Gründe: Zunächst wollte ich etwas mehr über OPC UA und Retrofitting lernen. Gleichzeitig wollte ich aber auch etwas über die Leute erfahren, die sich mit diesen Themen beschäftigen. Es wurden drei Vorträge gehalten und danach gab es eine Führung durch die smartFactory. Im ersten Vortrag ging es um OPC UA, im zweiten um Retrofitting und im letzten um "Standards und kreative Lösungen".
OPC UA
Den Vortrag über OPC UA hielt Jan Nicolas Weskamp vom Fraunhofer IOSB-INA aus der Forschungsgruppe Big Data Plattformen (www.bigdata-owl.de). Dieses Institut hat auch zusammen mit dem VDMA (Verband Deutscher Maschinen- und Anlagenbau e.V.) einen Leitfaden zur Einführung von OPC UA in den Mittelstand erstellt. Herr Weskamp gab einen kurzen Abriss zu OPC UA ohne zu sehr auf Details einzugehen. OPC UA ist in der IEC Norm 62541 spezifiziert. OPC UA ist ein sehr umfassender Standard, der neben der Kommunikation auch die Informationsmodelle beschreibt, die bei der Kommunikation mit Maschinen anzuwenden sind. Bisher ist es nämlich so, dass weder die Werte, die die Maschinen ausgeben noch deren Format (Felder, Feldlänge, Bezeichnung, etc.) normiert sind.
Die OPC UA Foundation und der VDMA arbeiten zusammen mit den Herstellern offenbar daran, branchenspezifische, standardisierte Informationsmodelle festzulegen. Die sogenannten Companion Specifications. Offenbar sind bisher vom VDMA erst welche zur Robotik und zur Bildverarbeitung veröffentlicht worden. Herr Weskamp nannte auch noch Euromap 77 und PackML. Die Vorteilsargumentation umfasste i. W. folgende Punkte: OPC UA ermöglicht es den Kunden einheitliches Condition Monitoring, Wartung/Konfiguration und "Plug & Work" (hinzufügen von neuen Geräten und deren automatische Konfiguration) durch festgelegte Messwerte (z. B. Energieverbrauch, Umgebungstemperatur, Prozesswerte, Auftragsstatus, etc.).
Zur Einführung von OPC UA muss der Interessent mindestens drei OPC UA Komponenten bei sich implementieren: Transport, Sicherheit und Informationszugriff. Danach würden dann noch die Companion Specifications und ggfs. erweiterte Informationsmodelle hinzukommen. Die Komponenten sind im o. g. Leitfaden z. B. in Abbildung sieben zu sehen.
Interessant finde ich, dass sich hier offenbar die Big Data Spezialisten selbst darum kümmern, dass sie standardisiert an standardisierte Maschinendaten herankommen. Auf meine Nachfrage, was denn die Hersteller dazu bringe, an Companion Specifications mitzuarbeiten, kam als Antwort, das sei Kundenwunsch. Auch die Vorteilsargumentation schien mir noch nicht so schlagkräftig, dass jetzt plötzlich jeder Mittelständler OPC UA einführen würde.
Retrofitting
Den Vortrag über Retrofitting hielt Andre Friesen vom Fraunhofer IOSB-INA aus der Forschungsgruppe Intelligente Datenbasis. Herr Friesen stellte als Gründe für Retrofitting (also das Instrumentieren "alter" Maschinen, um diese vernetzen und auslesen zu können) i. W. optimized, assisted und predictive maintenance, online monitoring sowie quality assurance und Prozessoptimierung. Dazu werden entsprechende Maschinen mit Sensoren und Gateways ausgestattet, um Daten auszuleiten und diese dann z. B. über einen Clouddienst zu visualisieren. Interessant waren die Praxisbeispiele, die bereits umgesetzt worden sind. Vorgestellt wurde die Instrumentierung von Maschinen bei der Firma Heinz Schwarz, mit der man dort ein "Pay per Use" Geschäftsmodell als Zulieferer der Automobilindustrie verwirklichen wollte. Ein weiteres Beispiel kam von der Firma Betron, die Papierpressen nachträglich instrumentiert hat, um diese zu lokalisieren und z. B. deren Füllstand online zu ermitteln. Zum Schluß stellte Herr Friesen noch das System INAsense vor, welches bei Fraunhofer IOSB-INA entwickelt worden ist. Dabei handelt es sich um einen "Demokoffer", mit welchem beim Kunden Daten erhoben werden und diese dann per MQTT, OPC UA und LTE ausgeleitet und einer Verarbeitung zugeführt werden können. Herr Friesen wusste auf Nachfrage nicht, dass auch Maschinenhersteller inzwischen am Retrofitting ihrer alten Anlagen arbeiten (s. z. B. ReadyKit von Krones). Da schien sich der Elfenbeinturm ein wenig zu zeigen.
Standards und kreative Lösungen
Herr Dr. Martin Stein jedoch wusste auch von Herstellern, die im Retrofitting aktiv sind wobei dies tatsächlich branchenspezifisch unterschiedlich sei. Her Dr. Stein stellte ein Praxisbeispiel zur Betriebsdatenerfassung (BDE) vor, welches Dank Standardisierung und OpenSource Technologie umgesetzt und in die Systemlandschaft beim Kunden integriert werden konnte. Er schlug einen etwas größeren Bogen über die Bereiche "Erfassen, Übertragen und Ablegen" wobei er für jeden Bereich proprietäre aber auch offene Standards und Protokolle erwähnte. Denn OPC UA ist natürlich nicht der einzige "Standard", den es im Bereich IoT gibt. Erwähnt wurde schon MQTT, hier kamen noch AMQP, und STOMP und natürlich noch "IT-nähere" Protokolle wie REST und SOAP dazu. Auch bei der Datenablage ging es von SQL-Datenbanken (MariaDB, Postgres, etc.) über NoSQL-Konstrukte (Cassandra, MongoDB, etc.) und Timeseries Datenbanken (InfluxDB, KairosDB, etc.) weiter zu Applikationen wie Solr, Elasticsearch und Kafka, die Herr Dr. Stein als "Engines" bezeichnete. In dem oben genannten Beispiel ging es dann jedoch um die Verbesserung in der Betriebsdatenerfassung durch ein "Spielterminal" im Rahmen der Einführung eines APS (Advanced Planning and Scheduling) Systems. Dabei wurden die verschiedenen Schichten in dem Unternehmen über ein Spiel motiviert, Betriebsdaten zu erfassen. Es entwickelte sich eine Art Wettbewerb zwischen den Schichten und die Qualität der Erfassung stieg deutlich. Erwähnt wurde hier noch das OPC UA SDK von Unified Automation sowie das entsprechende Projekt der Eclipse Foundation.
SmartFactory
Der Rundgang durch die smartFactory OWL hatte dann interessanterweise weniger mit OPC UA und Retrofitting zu tun. Hier ging es mehr darum, was das Fraunhofer Institut hier bereits aufgebaut und in verschiedenen Projekten umgesetzt hat. Interessant für mich war, dass am Anfang darauf hingewiesen wurde, dass die gesamte Umgebung auf einem Doppelboden aufgebaut war, um Maschinen flexibel umgruppieren zu können und sie trotzdem immer einfach mit Strom und Netzwerk versorgen zu können. Weiterhin war die gesamte Halle mit einem System zur Werkstück- resp. Personenlokalisierung ausgeleuchtet.
Die erste Station war ein Demo-Setup zum Thema "Cyber Security", wo ein IDS-System vorgeführt wurde, welches einen Denial of Service via MAC-Spoofing erkannte. Für uns eigentlich ein alter Hut - im Maschinenbau scheint es mit der IP-Sicherheit standardmässig noch nicht so weit her zu sein.
Ein weiterer großer Bereich waren Assistenzarbeitsplätze verschiedener Generationen z. B. mit Video- und Roboterunterstützung, um Fertigung mit hoher Varianz und geringer Fehlerrate zu ermöglichen.
Die letzte Station war ein Logistiksystem, welches mit Hilfe verschiedener Lernalgorithmen auf Geschwindigkeit und geringeren Energieverbrauch optimiert wurde.
Fazit
Es ist immer wieder interessant, wenn man in so eine "neue Welt" eintaucht - schon allein um die Unterschiede und Parallelen zur eigenen "Wirklichkeit" zu entdecken. Es hat mich beeindruckt mit welchem Aufwand der Staat (in Form der bei dem Treffen versammelten, geförderten Kompetenzzentren) das Thema "IoT" und "Industrie 4.0" unterstützt. Noch kommt ein großer Teil (es war die Rede von 75% des Weltmarkts) der Komponenten für "Industrie 4.0" aus der Region OWL. Firmen wie Beckhoff, Weidmüller, Phoenix-Contact u. v. a. m. sind auch in die Standardisierung eingebunden und man trifft fast in jedem Projekt auf entsprechende Firmennamen aus der Region.
Trotzdem habe ich aus meiner Perspektive den Eindruck, als ob das Thema noch nicht richtig abgehoben hätte. Die Anwesenden Firmenvertreter haben nach den Vorträgen z. B. keine Fragen gestellt. Nur im Rundgang durch die Fabrik gab es ein paar angeregte Gespräche. Vielleicht ist das auch eine Mentalitätsfrage - denn für Dienstleister und auch Kunden von Maschinenbauern ergeben sich durch die Vernetzung und die damit einher gehende Datenausleitung durchaus neue Perspektiven: Dienstleister könnten neue Produkte entwickeln, die vielleicht branchenspezifisch aber nicht mehr maschinenspezifisch sein könnten. Kunden könnten sich branchenübergreifend zusammenfinden, um Lösungen zu entwickeln, ohne die eigene Konkurrenz "schlauer" zu machen. So könnten sich Miele, Claas und Benteler zusammentun, einen eigenen "Clouddienstleister" mit der Datenspeicherung zu beauftragen, wenn sie der Datenspeicherung bei Google, AWS und Azure nicht vertrauen. So ein "Clouddienstleister" könnte z. B. Plusserver sein.
Interessant auch, dass die früheren "Trends" im Maschinenbau offenbar bisher nicht "geliefert" haben und deswegen möglicherweise auch heute noch bei potentiellen Anwendern eine gewisse Skepsis vorherrscht. Das kann m. E. aber auch daran liegen, dass die Vorteile, die sich aus der Vernetzung ergeben, offenbar noch nicht bei allen so gut ankommen (obwohl die anwesenden Kompetenzzentren immer wieder auf Fördermöglichkeiten und Projekte hinweisen).
Offenbar hat sich Südkorea bereits auf OPC UA als Standard "geeinigt". Ich persönlich sehe allerdings wesentlich mehr Möglichkeiten in "DIY"-Projekten mit Rasberry-Pi und OpenSource Komponenten, die eine deutlich geringere Einstiegshürde darzustellen scheinen. Probleme bei Standardisierungsbemühungen aus der IT machen es m. E. schwierig, den Erfolg von OPC UA vorhersehen zu wollen.
M. E. gibt es immernoch genug Raum in der Nische neben den großen Hyperscalern - z. B. wenn man sich als Cloudanbieter in Deutschland aufstellt, der sich mit "Industrie 4.0" gut auskennt.
Links
Industrie 4.0 - Kommunikation mit OPC UA - Leitfaden zur Einführung in den Mittelstand
Da das Thema IoT auch gerade wieder bei Lieferanten und Kunden interessant zu werden scheint, hier noch ein paar Links zu MQTT und IoT:
- How to build an IoT Backend using Node.js, Serverless and Docker (leider nur als Video - bisher habe ich die Folien nicht online gefunden).
- How to Leverage a Multi-Cloud Architecture (nur Video - über das Vorgehen, mit dem Samsung durch Rückverlagerung in eine private Cloud Geld sparen konnte.
- NodeConfEU 2013 - MQTT and Node.js (2013!)
- Learn, How to save MQTT messages into a MySQL Database
- EMQ - The Massively Scalable MQTT Broker for IoT and Mobile Applications
- Store messages from Mosquitto MQTT broker into SQL Database
- The missing piece between MQTT and a SQL database in a M2M landscape
- How would I store messages from an MQTT broker like mosquitto so users can see their chat history?
- Temperature Logging Using MQTT and MongoDB
- Node-RED - Flow-based programming for the Internet of Things
- Awesome MQTT
- Connected Cooking powered by MQTT
- MQTT in the Enterprise - How to successfully run an MQTT Message Broker
Sinnvollerweise wird man natürlich IoT-Events nicht direkt in einer SQL-Datenbank speichern sondern am Gateway vorfiltern, in größere Logfiles loggen und diese dann in ein Objectstorage hochladen. Oder Eventstreams bilden und diese dann irgendwie mit Apache Spark oder Apache Beam "near realtime" auswerten.
Interessanterweise engagiert sich Akamai inzwischen auch mit "Akamai IoT Services" im Bereich IoT.
Erhältlich ist "OTA Updates" also "over-the-air" provisioning von IoT-Geräten und "IoT Edge Connect", ein Dienst der die über 2400 Akamai "Datacenter" ins Spiel bringt. Welche Probleme das Produkt genau löst, ist mir noch nicht klar. Es sieht fast so aus als könnten Kunden auf eine verteilte, mandantenfähige MQTT-Plattform zugreifen. Im Vordergrund scheint eine Zustellung der Events mit möglichst geringer Latenz zu stehen, die für manche IoT-Anwendungen von Bedeutung zu sein scheint (z. B. Öffnen des Autos per Smartphone). Ab Slide 43 wird dann auch Datenverarbeitung im Edge-Datacenter gezeigt. Wie genau das funktioniert (und provisioniert wird) ist für mich aber unklar.
Vortrag über MQTT auf der FrOSCon 2018
Vortrag über Node-Red auf der FrOSCon 2018
MES - Manufacturing Execution System
CPS - Cyberphysikalisches System