Verschwenden Sie niemals eine gute Krise

Einführung

Die rasanten Fortschritte in der neuen Technologie verändern die Art und Weise, wie Seeleute lernen. Fortgeschrittene Simulationen sind bekanntlich eines der effektivsten angewandten Schulungsinstrumente. Sie werden schon seit vielen Jahren in der Aus- und Weiterbildung von Seeleuten eingesetzt, aber aufgrund der relativ hohen Anschaffungs- und Betriebskosten oft nur begrenzt. Jetzt findet eine Demokratisierung der Simulationsausbildung statt, die es viel mehr Studenten ermöglicht, Zugang zu hochwertigen Simulationswerkzeugen zu einem erschwinglichen Preis zu erhalten. Die Cloud-Technologie und die zunehmende Verfügbarkeit des Internets auf der ganzen Welt ermöglichen diesen Wandel. Die laufende COVID-19-Pandemie beschleunigt ihn noch. Wir können davon ausgehen, dass sich die Qualität der Ausbildung verbessert, aber dies könnte sich auch als ein wesentliches Instrument bei der Digitalisierung erweisen, mit der die maritime Industrie konfrontiert ist.

Seit fast fünf Jahrzehnten ist Kongsberg ein Anbieter von Simulatoren. In Vorwegnahme des digitalen Wandels hat Kongsberg die fortschreitende Technologie aufgegriffen und in Zusammenarbeit mit Xpirit den ersten Simulatordienst auf der Grundlage seiner hochgelobten Plattform für Maschinenraumsimulatoren auf den Weg gebracht. Dieser Dienst wurde im März 2020 der Öffentlichkeit zugänglich gemacht, Monate früher als geplant. Grund dafür war die Schließung der maritimen Akademien im Zuge der Ausbreitung des COVID-19 Virus. Bis zum Ende des Jahres hatten wir unglaubliche dreißigtausend Simulationssitzungen für Studenten weltweit bereitgestellt.

Ein ehrgeiziger Plan

Motiviert durch diesen unbedingten Erfolg hat Kongsberg bereits im Mai 2020 seine Digitalisierungsbemühungen beschleunigt und mit der Cloudifizierung seiner Navigationssimulationsplattform begonnen, mit dem ehrgeizigen Ziel, noch in diesem Jahr den ersten öffentlichen Dienst, einen RADAR-Simulationsdienst, anzubieten. Am letzten Tag des Novembers haben wir ihn gestartet. In dieser Geschichte geht es um Teile der Technologie, die wir entwickelt haben, um den ersten und wahrscheinlich fortschrittlichsten Navigationssimulator in der Cloud bereitzustellen.

Wir hatten viel gelernt, als wir den Engine and Cargo Simulator von Kongsberg in die Cloud brachten, worüber wir in unserem früheren Artikel im XPRT. Magazin #10. Könnten wir auch den Navigationssimulator von Kongsberg in die Cloud bringen und in etwa acht Wochen einen funktionierenden Prototyp haben? Glücklicherweise konnten wir auf all die Arbeit zurückgreifen, die wir in den Jahren zuvor bereits geleistet hatten, aber es war auch keine triviale Aufgabe!

Erste Herausforderung: von (bis zu) 200 Computern auf 1 Docker-Container

Die Simulatorplattform von Kongsberg für Navigation und Offshore heißt Spirit. Es handelt sich um ein hochgradig verteiltes System mit einem Simulator-Server als Herzstück, der "die Welt" und die gesamte Hydrodynamik (die Bewegung des Wassers und die auf Objekte im Wasser wirkenden Kräfte) simuliert. Spirit ermöglicht es Kongsberg, Simulatoren zu bauen, die von einem einzelnen Desktop-Computer bis zu kompletten Schiffsbrücken reichen, die aus Hunderten von Computern bestehen, die zusammenarbeiten, um Instrumente zu steuern und visuelle 3D-Bilder in Echtzeit zu liefern.

Quelle: Maritime Simulation Integriertes Teamtraining/

Spirit hat über Jahre hinweg in seine Plattform investiert. Sie ist vollständig Windows-basiert und die meisten Komponenten verfügen über eine Art grafische Benutzeroberfläche, sogar die Serverkomponenten. In einer Cloud-Umgebung ist eine grafische Benutzeroberfläche jedoch nicht sehr sinnvoll. Ein Cloud-natives System sollte ohne Benutzeroberfläche auf einem Server laufen. Sicher, Sie können sie auf einer VM installieren und die Benutzeroberfläche über Remote Desktop bereitstellen, aber das ist eine altmodische Lösung und eine kostspielige.

Wir hatten bereits eine ganze Plattform und ein Ökosystem für die Ausführung von Simulatoren als Container in einem Kubernetes-Cluster namens K-Sim Connect. Sie übernimmt alles für die Planung von Simulationen, die Verwaltung von Übungen und Studenten im Rahmen eines SaaS-Angebots. Auch Spirit musste in dieser Umgebung landen. Wir wussten, dass es eine Herausforderung sein würde, ein System zu containerisieren, das nicht mit Blick auf die Containerisierung entwickelt worden war.

Hierfür gibt es ungefähr zwei Ansätze:

1. Schreiben Sie das System mit .NET Core/.NET 5 und Docker von Grund auf neu und führen Sie es in Linux-Containern aus, oder:
2. Passen Sie das bestehende System Schritt für Schritt an und lassen Sie es in der Cloud laufen.

Viele Architekten und Entwickler würden aufschreien: "Von Grund auf neu schreiben; dieses System ist nicht Cloud-nativ!". Aus betrieblicher Sicht wäre dies langfristig wahrscheinlich die billigste Lösung, aber die Zeit bis zur Markteinführung wäre sehr lang, die Entwicklungskosten enorm, ganz zu schweigen von der Desinvestition in ein bereits erfolgreiches und bewährtes System. Wir hatten ein sehr kurzes Zeitfenster, um erfolgreich zu sein. Während wir also unsere Maschinenraumsimulatoren in der Produktion ausbauten, begannen wir mit der Arbeit daran, den Radar Navigation Trainer in die Cloud zu bringen.

Unsere bestehende Plattform hatte auch bewiesen, dass wir Windows-Container problemlos in der Cloud ausführen konnten. Natürlich sind Windows-Container groß und der Betrieb von Windows-Knoten ist teurer, aber die Plattform unterstützt vollständig Windows-basierte Software, einschließlich "exotischerer" Dinge wie Win32-Code und Registry-Zugriff. Wir wussten, dass wir dies auch für Spirit benötigten.

Unser Ansatz war zunächst ein wenig Versuch und Irrtum, denn wir mussten die Hindernisse herausfinden, die wir zu überwinden hatten. Wir nahmen das Spirit-Installationsprogramm und erstellten eine Docker-Datei, mit der es installiert werden konnte. Hindernis Nummer eins war, dass wir das Installationsprogramm ohne Kopfhörer laufen lassen mussten. Das war in der InstallShield-Definition leicht zu beheben, indem wir ihm eine Silent-Option gaben.

Gemeinsam mit den Architekten von Spirit haben wir uns überlegt, wie wir alle an der Simulation beteiligten Komponenten ohne Kopfhörer laufen lassen können.

Dieses Diagramm zeigt die wichtigen Komponenten, die an einer Radarsimulation teilnehmen. Alle Serverkomponenten (hellblaue Kästen) verfügten über eine grafische Benutzeroberfläche, die ihren Status anzeigt und manuelle Steuerungsmöglichkeiten wie Anhalten, Starten und Pausieren bietet. Das erste, was das Spirit-Team für uns tat, war, diese Komponenten so zu ändern, dass sie ohne GUI in einem Docker-Container laufen.

Die grünen Komponenten sind vollwertige GUI-Anwendungen (meist WPF). Sie spielen alle eine wichtige Rolle im System. Die Instructor Station dient dazu, Übungen zu erstellen, Schiffe hinzuzufügen, Bedingungen wie das Wetter und das Segelgebiet festzulegen, Studenten zuzuweisen und die Übung zu starten. Auf der Grundlage der Konfiguration in der Übung und im Simulator startet der Ressourcenmanager verschiedene andere Komponenten.

Wir mussten den Prozess des Ladens einer Übung und des Starts der Simulation ohne Benutzerinteraktion automatisieren. Da wir nicht alle Funktionen der Instructor Station in der Cloud benötigen, sondern nur die Möglichkeit, eine Übung zu laden, lieferte das Spirit-Team eine Konsolenanwendung, die genau das tat. Auf diese Weise konnten wir das System über die Befehlszeile booten.

Die Student Station war schwieriger. Sie hat die wichtige Aufgabe, die Instrumente auszuführen, mit denen die Studenten interagieren. Die Instrumente haben eine grafische Benutzeroberfläche, enthalten aber auch Logik, um mit den Serverkomponenten zu interagieren. Insbesondere das Radargerät hat einen Teil, der auf der Grundlage der Eingabedaten Sweeps erzeugt. Ein Radar-Sweep ist eine volle 360-Grad-Drehung des Radarstrahls und erzeugt ein Bild. Bei jedem Schritt in dieser Drehung erzeugt das Radar einen Scan, indem es den Strahl in die entsprechende Richtung schießt.

Ein separates Programm namens Radar Display liest Scans aus dem gemeinsamen Speicher und zeichnet sie auf dem Bildschirm. Hier gab es also mehrere Dinge zu beachten:

• die grafische Benutzeroberfläche der Instrumente entfernen, während die Logik weiterläuft;
• Shared Memory in einem Docker-Container ausführen (könnten wir das?);
• die Anwendung Radar Display durch etwas zu ersetzen, das Bilder ohne eine grafische Benutzeroberfläche erzeugen kann.

Wir hatten bereits gelernt, dass Sie eine ganze Reihe "alter" Windows-Mechaniken in einem Windows-Container ausführen können (vorausgesetzt, Sie führen ein Windows Server Core-Image aus). COM, Registry-Zugriff, Win32, all das funktioniert. Wir haben schnell festgestellt, dass Shared Memory, das ebenfalls ein altes Konstrukt ist, ebenfalls funktioniert. Das bedeutete, dass wir die vorhandenen Komponenten, die Radar-Sweeps erzeugen, wiederverwenden konnten. Wir brauchten nur einen neuen Weg, sie zu hosten, da sie in der Student Station GUI-Anwendung liefen.

Speziell für den Docker-Container haben wir eine Headless Student Station erstellt. Dabei handelt es sich um eine .NET-Konsolenanwendung, die die Komponenten des Spirit-Frameworks lädt, die die Gerätelogik ausführen, aber die Präsentationsschicht überspringt. Eine Schwierigkeit bestand darin, dass die Student Station eine Windows-Anwendung ist, die von der Windows Message Pump gesteuert wird. Einige Komponenten in der Student Station sind darauf angewiesen, dass diese Nachrichtenpumpe verfügbar ist. Außerdem benötigen die COM-Komponenten des Radars einen STA-Thread (Single-Threaded Apartment), um ausgeführt zu werden. Wir haben eine Klasse erstellt, die ein unsichtbares Fenster einrichtet, das die Nachrichtenpumpe ansteuert und einen Dispatcher einrichtet, der das Single-Threaded Apartment garantiert. Das war ein schneller Trick, um die Dinge zum Laufen zu bringen, aber das ist typischerweise etwas, das Sie später wieder aufgreifen sollten, um die Anwendung containerfreundlicher zu machen. Dies erfordert jedoch eine größere Änderung in der Architektur.

Im Container starten wir diese Headless Student Station anstelle der regulären Station.

Sie können mehrere Prozesse in einem Container ausführen. So machen wir es: alle Spirit-Komponenten laufen in diesem einen Container, ein Container pro Schüler.

Die Bootstrapper-Komponente, die die Instructor Station ersetzt, spielt hier eine wichtige Rolle. Sie ist der Hauptprozess, der die Lebensdauer des Containers bestimmt. Außerdem kommuniziert sie mit der K-Sim Connect Plattform, um den Status und den Fortschritt der Simulationssitzung zu verfolgen. Kürzlich haben wir eine automatische Bewertung des Schülers auf der Grundlage von Daten aus dem Simulator hinzugefügt, die unser Webportal in Echtzeit anzeigt.

Zweite Herausforderung: von WPF zu einer webbasierten Benutzeroberfläche

Das bringt uns zu dem nächsten Problem, das im Raum steht: Wie gehen wir mit der Studenten-Benutzeroberfläche um? Unsere Maschinenraumsimulatoren der ersten Generation haben noch eine lokale GUI-Anwendung. Sie funktioniert dank einer relativ einfachen Client-Installation und einer reinen Client/Server-Topologie. Wir konnten das Produkt schnell auf den Markt bringen, auch wenn es ein gewisser Kompromiss ist, einen lokalen Client zu benötigen.

Die Spirit-Plattform ist mit ihrem Echtzeit-Kommunikationsbus etwas komplexer. Wir wussten, dass die Installation der Student Station auf einem Client-PC wegen des großen Platzbedarfs nicht in Frage kam, und wir wollten die Plattform ohnehin web-nativ machen.

In den vergangenen Jahren hatte Kongsberg in ein Erweiterungs-Framework für Spirit investiert. Ein wichtiger Grund dafür war die Möglichkeit, Innovationen auf der Plattform zu entwickeln, ohne jedes Mal die gesamte Plattform selbst ändern, testen und freigeben zu müssen. Diese Multi-Speed-Architektur des Erweiterungs-Frameworks hat auch unsere Bemühungen erheblich beschleunigt.

Einer der Grundgedanken des Erweiterungs-Frameworks war, dass neue Instrumente, die auf diesem Framework basieren, in einer Web-Benutzeroberfläche bereitgestellt und gerendert werden sollten. An dieser Stelle kommt der Spirit Web Server ins Spiel. Er ist ein wesentlicher Bestandteil unserer Lösung. Normalerweise werden diese Webkomponenten von der Student Station GUI-Anwendung als einzelne Panels mit einem eingebetteten Browser gehostet. Das Radar sollte ebenfalls ein webbasiertes Instrument sein, das auf dem Extension Framework basiert. Der Spirit Web Server würde es über einen Kubernetes-Ingress bedienen, den wir im Docker-Container ausgesetzt haben. Jeder Student erhält seine eigene (temporäre) Umgebung mit einer eindeutigen URL:

<Sitzungsnummer>.<cluster-region>.elearning.ksimconnect.com

Die Kubernetes-Ingress-Regeln sorgen dafür, dass der Datenverkehr an den richtigen Container geleitet wird.

Das letzte Teil des Puzzles war der Ersatz des "Chrome" der Student Station, der die Anzeige und Anordnung der Instrumententafeln übernimmt. Diese Anwendung mit dem Namen PanoramaWeb wurde speziell für unseren Umzug ins Web als reine native Webanwendung geschrieben, die Vue.js als Basis verwendet. Der Artikel von Albert Brand in diesem Magazin bietet einen detaillierteren Hintergrund über die Technologie hinter der Web-App. Wir werden PanoramaWeb weiter ausbauen, und wenn es ausgereift ist, wird es die Zukunft der Student Station sein.

Da wir nun eine Möglichkeit hatten, Instrumente über das Internet anzuzeigen, konnten wir die Grundlage für das Radarinstrument schaffen. Schaltflächen, Statusanzeigen und andere Benutzerinteraktionen wie das Zeichnen von Entfernungsmarkierungen oder Peilungslinien werden alle auf der Client-Seite behandelt. Das Erweiterungs-Framework umfasst eine SignalR-Verbindung mit dem Server, die es uns ermöglicht, Status und Aktualisierungen zwischen dem Browser und dem Container zu kommunizieren.

Ersetzen der Radaranzeige Ein wesentlicher Bestandteil eines Radargeräts ist das Radarvideo, die bekannte, oft kreisförmige Ansicht, die die Radarsweeps anzeigt.

Wie das erste Diagramm zeigt, ist auch das bestehende Radar Display eine GUI-Anwendung. Sie verwaltet das Zeichnen des Radarvideos sowie alle Benutzereingaben. Mit den Benutzereingaben hatten wir uns bereits über das Web-Panel befasst. Was übrig blieb, war das Radarvideo.

Der Datenfeed für die Sweeps war bereits im gemeinsamen Speicherblock verfügbar. Die Radargenerator-Komponente schreibt ständig neue Werte für jeden Scan, ähnlich wie ein echtes Radar. Wir haben die Logik aus der bestehenden GUI für die Radaranzeige extrahiert und eine neue Headless-Komponente erstellt, die diese Logik enthält. Sie heißt ScanConverter. Abgesehen von PanoramaWeb ist dies eine der wenigen Komponenten, die wir für unser Cloud-Szenario neu geschrieben haben. ScanConverter übernimmt die Daten aus dem gemeinsamen Speicher und erzeugt ein Bild. Wir tun dies etwa 25 Mal pro Sekunde, was eine akzeptable Bildrate ist.

Dritte Herausforderung: Kommunikation in Echtzeit im Internet

Als nächstes brauchten wir eine Möglichkeit, diese Radar-Videobilder an den Browser zu senden.

Wir haben uns zunächst angesehen, wie Streaming-Dienste wie YouTube oder Netflix das Streaming von Videos an Kunden in einem unglaublichen Ausmaß gelöst haben. Es gibt jedoch einen wichtigen Unterschied zwischen dem Streaming von Inhalten wie Videos und dem Streaming eines Live-Radar-Videomaterials. Wenn es sich um Videos handelt, müssen die Nutzer diese von Anfang bis Ende sehen, ohne Teile des Videos zu überspringen. Selbst beim Live-Streaming auf YouTube beispielsweise muss die Ansicht nicht nahezu in Echtzeit erfolgen. Für uns ist es wichtiger, dass der Benutzer sieht, was gerade auf dem Radar passiert, als dass er das Video von Anfang bis Ende anschaut.

Wir haben uns Streaming-Technologien wie Dynamic Adaptive Streaming over HTTP (DASH oder MPEG-DASH) oder HTTP Live Streaming (HLS) angesehen. Bei jeder dieser Technologien hat jedoch die Bereitstellung eines reibungslosen (Live-)Streams für eine große Anzahl von Benutzern Vorrang vor der Bereitstellung eines Videostreams, der so nah wie möglich an der Echtzeit ist, für einen einzelnen Benutzer. Anschließend haben wir uns eine andere Art von Video-Streaming angesehen, die sich auf Videokonferenzen in nahezu Echtzeit konzentriert: WebRTC. WebRTC ist ein Protokoll für die Sprach- und Videokommunikation in Echtzeit im Internet. Es konzentriert sich auf die Peer-to-Peer-Kommunikation, und ein wichtiges Merkmal ist, dass es heutzutage von Browsern nativ unterstützt wird.

Bei der Verwendung von WebRTC benötigen wir einen sogenannten Signalisierungsserver. Die Clients verwenden diesen zentralen Server, um sich beim ersten Aufbau der WebRTC-Verbindung gegenseitig zu erkennen. Nach dem anfänglichen Bootstrapping wird der Signalisierungsserver nicht mehr benötigt und die WebRTC-Clients kommunizieren direkt peer-to-peer miteinander. WebRTC verfügt über mehrere Mechanismen, die eine solche direkte Kommunikation über verschiedene, durch das Internet getrennte Netzwerke hinweg ermöglichen. Wenn dies nicht gelingt, können die Clients ein TURN-Relay (Traversal Using Relays around NAT) als Ausweichlösung verwenden. Mit einem TURN-Relay kommunizieren die Clients nicht mehr Peer-to-Peer, sondern über dieses zentrale Relay. Das TURN-Relay ist für uns eine wichtige Komponente, da wir es häufig in eingeschränkten Umgebungen wie Unternehmens- oder Schulnetzwerken benötigen. In solchen Netzwerken sind die Mechanismen, die WebRTC zum Aufbau einer Peer-to-Peer-Verbindung verwendet, normalerweise nicht zulässig.

Die Peer-Verbindung in einer WebRTC-Sitzung kann mehrere Video- und Audioströme enthalten, die synchronisiert sind. Das ist bei Videokonferenzen wichtig, denn wenn Sie Menschen sprechen sehen, möchten Sie den Ton hören, der zur Bewegung des Mundes dieser Person passt. In einer Simulation wollen wir auch mehrere Videoströme wie ein Radarvideo, eine 3D-Ansicht und Audioströme synchronisieren, um sicherzustellen, dass das, was der Benutzer sieht und hört, dem aktuellen Zustand der simulierten Welt entspricht.

WebRTC schien perfekt zu unseren Bedürfnissen zu passen, aber unsere größte Herausforderung bestand darin, eine WebRTC-Sitzung zwischen einem Docker-Container und einem Webbrowser einzurichten. Während WebRTC von Haus aus in Browsern unterstützt wird, war die Verwendung auf der Seite des Servers in einer C# .NET-Anwendung komplizierter. Wir mussten die Unterstützung für WebRTC in unsere C#-Anwendung implementieren, genau wie es die Browser-Anbieter für ihre Browser getan haben. Der Quellcode für die WebRTC-Bibliotheken wird von Google veröffentlicht, aber die nativen C- und C++-Versionen müssen in Ihre eigene Anwendung integriert werden. Nach einigem Suchen fanden wir heraus, dass Microsoft bereits ein Projekt auf GitHub hatte, das darauf abzielte, WebRTC in den HoloLens-Anwendungen zu unterstützen, und die von diesem Projekt erstellte Bibliothek ermöglichte es uns, WebRTC mit relativer Leichtigkeit in unsere C#-Anwendung zu integrieren.

Da jeder Simulator-Container eine in sich geschlossene Anwendung mit einem eigenen Endpunkt ist, haben wir uns dafür entschieden, sowohl den Signalisierungsserver als auch den serverseitigen Peer in denselben Prozess im Docker-Container zu integrieren: den Spirit Web Server.

Der Browser verbindet sich mit einem SignalR-Hub (dem Signalisierungsserver), der auf dem Docker-Container offengelegt ist, und tauscht die erforderlichen Nachrichten aus, um eine WebRTC-Verbindung mit dem Simulator aufzubauen, der im selben Container läuft. Sobald die Verbindung hergestellt ist, beginnt der Simulator mit dem Streaming des Radarvideos, das von der Komponente ScanConverter erzeugt wird, über WebRTC an den Browser.

Die Welt nach COVID-19

Das Jahr 2020 begann für uns ruhig, und wir hatten erwartet, dass wir unseren Kundenstamm stetig vergrößern und daran arbeiten würden, den nächsten Simulator in die Cloud zu bringen. COVID-19 hat unsere Pläne und Ambitionen beschleunigt. Unser Produktverantwortlicher fragte uns, "ob wir für eine Herausforderung bereit seien", und das Team nahm mutig an. Und jetzt, ein Jahr später, haben wir Cluster in mehreren Regionen in Betrieb, und Benutzer auf der ganzen Welt nutzen unsere Simulatoren in der Cloud.

Aber wir sind noch lange nicht fertig. Wir haben gerade erst damit begonnen, das Potenzial des Navigationssimulators in der Cloud zu erschließen, und wir arbeiten bereits daran, neben dem Radar noch weitere Funktionen in die Cloud zu bringen.

Wie der Maschinenraumsimulator zeigt auch dieses Projekt, dass Sie Ihr System nicht komplett neu schreiben müssen, um es in der Cloud nutzen zu können. Wir konnten es mit gezielten Änderungen schnell auf den Markt bringen, aber wir wissen, dass wir noch viel Arbeit vor uns haben. Aber dadurch, dass wir es einfach getan haben, haben wir viel mehr darüber gelernt, wo und wie wir unsere Bemühungen zur Optimierung der Spirit-Plattform für die Cloud fokussieren können, als mit einer kompletten Neugestaltung zu beginnen. Hinter den Kulissen arbeiten die Teams bei Kongsberg jetzt hart daran, den Simulator schlanker und containerfreundlicher zu machen. Neue Funktionen werden bereits "cloud-first" entwickelt.

Der Start des RADAR-Dienstes ist ein weiterer wichtiger Schritt in der Demokratisierung der maritimen Simulation. Eine Hürde nach der anderen, wir gestalten die Zukunft der maritimen Simulation und tun dies zum Nutzen der Nutzer und zum Nutzen einer sichereren und grüneren Welt. Und auf dem Weg dorthin erschaffen wir einige epische Scheißtechnologien.

Co-Autor Gullik Jensen (Produktdirektor für digitale Dienste bei Kongsberg)