Maschinen- und Anlagenbauer müssen bei Fehlerfällen schnell reagieren. Denn der Kunde möchte keinen Stillstand der Maschine und seine Auslastung möglichst hoch halten. Hierbei schafft die Datenbrille eine Abhilfe.
Der Betreiber einer größeren Maschine möchte die Stillstandszeiten möglich gering halten. Schließlich wurde die Investition für die Anlage ja auch mit einer bestimmten Auslastung motiviert. Und das heißt, dass Stillstände die ROI-Rechnung verderben.
Hinzu kommt, dass die Maschinenhersteller oder Wartungsdienstleister häufig nicht direkt beim Anlagenbetreiber sitzen. Das kann die Wartung verzögern und damit auch die Stillstandszeit erhöhen.
Folglich könnte der Anlagenbetreiber seinen ROI-Druck an den Hersteller weitergeben. Es werden bestimmte Reaktionszeiten und Zeiten bis zur Behebung von Fehlern vereinbart. Je nachdem, wie weit der Hersteller entfernt sitzt, empfindet er sich dann als mehr oder weniger geknebelt.
Aber mit den neuen Streaming-Techniken gibt es Abhilfe. Damit kann der Hersteller oder Wartungstechniker nämlich viel schneller vor Ort sein. Wenngleich er auch nicht direkt anreist. Vielmehr steht er mit seinem Fachwissen dem Anwender bei.
Unmittelbar auf Stillstand reagieren
Beispielsweise könnte in der Produktion ein einfacher Defekt zum Stillstand führen. Dann ruft der Betreiber der Anlage sofort den Herstellerservice an. Gleichzeitig setzt der Mitarbeiter an der Anlage eine Datenbrille auf. Anschließend loggt sich der Servicespezialist des Herstellers in das Webportal ein.
Die Kommunikation läuft nun in zwei Richtungen. Einerseits nimmt die Kamera des Mitarbeiters das Bild der Anlage direkt vor seiner Nase auf. Andererseits sieht der Servicespezialist des Herstellers dieses Live-Bild. Genauso als ob er mit an der Anlage steht und dem Mitarbeiter über die Schulter schaut.
Schließlich kann der entfernte Servicespezialist dann gemeinsam mit dem Mitarbeiter einen ersten Blick auf den Defekt werfen. Je nachdem, was aufgetreten ist, reagiert er dann. Entweder leitet er für eine kleine Reparatur an oder er weiß dann gleich mehr, was ihn vor Ort erwartet.
Wenngleich nicht alle Fehler aus der Ferne zu beheben sind, so kann doch bei kleinen Defekten die Maschine wieder schnell in Betrieb gehen. Übrigens sind der Erfahrung nach viele Defekte wirklich nur kleinerer Art. Wenn dann ein Mitarbeiter vor Ort schnell das Problem beseitigt, ist allen geholfen. Der Servicetechniker kann sich um mehr Defekte kümmern und der Anlagenbetreiber reduziert seinen Stillstand.
Streaming
Als Beispiel für die technische Umsetzung schauen wir uns dies nun einmal genauer an. Im Folgenden konzentrieren wir uns dazu auf eine Recon Jet. Deren Kamera soll Bilder direkt an ein MacOS-Notebook streamen. Das heißt, das unsere Lösung in zwei Teile zerfällt. Einerseits das Capturing und Streaming. Andererseits das Empfangen der Bilder auf dem Notebook.
Auch wenn das den Fall unseres Servicetechnikers noch nicht vollständig löst, so deutet es zumindest technisch die Lösung an. Schließlich muss für das vollständige Produkt natürlich noch einiges an Infrastruktur aufgebaut werden.
Von der Datenbrille weg …
Für die Recon Jet stehen mehrere Werkzeuge zur Verfügung. Hierzu hat sich natürlich das freie Android Studio bewährt. Dabei ist eine wichtige Entscheidung, ob man die Komponenten des Recon Jet-SDKs einsetzen will oder nicht. Einerseits taugen Apps mit dem SDK für die Recon Jet und sind dafür optimiert. Andererseits laufen die Apps ohne das SDK auch auf beliebigen anderen Android-Geräten.
Die Bibliothek libstreaming bietet eine Unterstützung für ein RTP-basiertes Streaming von beliebigen Android-Geräten ausgehend. Mit dem Start der Streaming-Session legen wir lediglich die Ziel-IP (eventuell auch in Form einer Multicast-Adresse) fest. Dementsprechend vereinfacht die Bibliothek das Abgreifen des Kamerabildes deutlich.
Nachdem die Session vorhanden ist, steht deren Beschreibung im SDP-Format zur Verfügung. Damit kann die Beschreibung auch per RTSP verteilt werden.
Im Folgenden komprimiert die Datenbrille fleißig die Bilder mit H.264. Während der Komprimierung des Video-Streams läuft der Prozessor auf hoher Last. Dadurch produziert er einiges an Wärme. Demzufolge spürt das der Benutzer auch an seinen Wangenknochen. Außerdem leidet auch die Laufzeit der Brille bei laufendem Streaming.
… auf das Notebook
Wenn wir mit dem Streaming beginnen, dann testen wir erst einmal den Stream. Dafür eignet sich das Kommandozeilentool ffplay aus dem ffmpeg-Paket. Das ist auch als MacPort verfügbar. Sobald die SDP-Datei vorliegt, reicht ein einfaches
ffplay -protocol_whitelist file,rtp,udp -i <name>.sdp -probesize 1000
Damit erzeugt ffplay die entsprechenden Endpunkte für das Streaming. Ebenfalls öffnet es ein Fenster zur Anzeige des Streams. Ferner erlaubt die Option „-protocol_whitelist” dem ffplay die Verwendung der aufgelisteten Protokolle. Genauso bestimmt „-probesize“, wieviel Daten zur Analyse des erhaltenen Streams gepuffert werden sollen. Dies beeinflusst die Anzeigeverzögerung des Streams, weshalb eine Reduzierung sinnvoll sein kann.
Anzeige im Browser
Des Weiteren möchte der Nutzer den Stream vielleicht auch im Browser ansehen. Dafür empfiehlt sich ein HTTP-basiertes Verfahrens zur Streamwiedergabe. Beispielsweise sind das Tools wie HLS oder MPEG Dash. NGINX unterstützt in Kombination mit dem nginx-rtmp-module diese beiden Protokolle. Falls erste Versuche nötig sind, ist ein entsprechender Docker-Container eine gute Wahl.
Allerdings sind zwei Fallstricke zu vermeiden. Erstens muss der Stream auf eine erreichbare IP des Docker-Hosts zielen. Nur eine auf dem Host erreichbare IP reicht nicht. Zweitens gilt es zu beachten, dass RTP ein UDP-basiertes Protokoll ist. Eventuelle Portangaben in Docker versehen wir also mit dem Suffix /upd. Schließlich vermeiden wir damit die Fallstricke und schauen uns den von der Recon Jet gelieferten Stream im Browser an.
Weil beide Protokolle (HLS und MPEG Dash) auf der Basis von Playlists arbeiten (in Form einer m3u/m3u8- oder mpd-Datei), verzögert sich die Anzeige zusätzlich um die Chunk-Größe für die Streaming-Dateien. Ob diese Anzeigeverzögerung zum Problem wird, hängt vom konkreten Einsatzfall ab. Immerhin versprechen Protokolle wie WebRTC hier Abhilfe. Jedoch sprengen sie den Rahmen dieser Beschreibung.