Live-Verarbeitung oder aufgezeichnete Daten: Was braucht wirklich ein VPN?

Ein Roboter, der einen Raum weiter aufhört, nützlich zu sein, hat ein Verbindungs- oder ein Lastproblem lange bevor er ein VPN-Problem hat. Verschlüsselung schützt einen Pfad; sie erweitert nicht die Funkabdeckung und lässt eine entfernte Berechnung nicht früher fertig werden. Die Entscheidung vor Ihnen ist, welche Arbeit wirklich über das Netzwerk gehen muss, und diese Antwort entfernt meist mehr Verkehr, als Menschen erwarten. Drei Bedingungen entscheiden es, und der Durchsatz gehört nicht dazu.

Drei Anordnungen, eine Abhängigkeitsfrage

Die Tabelle trennt die Anordnungen danach, was von der Verbindung abhängt, nicht danach, welche Software im Diagramm erscheint.

Keine Zeile in dieser Tabelle ist ein Sicherheitsargument. Steuer- und Sicherheitsfunktionen brauchen weiterhin eine qualifizierte Antwort auf Verzögerung, Paketverlust und eine abgebrochene Verbindung, und kein Tunnelindikator liefert sie. Die Tabelle sagt, wo die Abhängigkeit lebt, und das ist der Teil, den ein Netzwerkentwurf tatsächlich ändern kann.

Bedingung eins: Muss die Antwort zeitnah sein?

Wenn ein entferntes Ergebnis einen Regler speist, sitzt das Netzwerk in der Regelschleife, und seine Verzögerung, sein Jitter und seine Ausfälle werden zu Regeleigenschaften. Wenn dasselbe Ergebnis nur ein Display, ein Dashboard oder einen zuschauenden Menschen speist, ist dieselbe Verzögerung kosmetisch.

Regelkreisarbeit über eine Funkstrecke ist möglich, und dort entstehen die meisten Meldungen „das VPN ist langsam“, weil der Tunnel die sichtbare Komponente ist, während Funk und Routing die Ursache sind. Messen Sie die Umlaufzeit der tatsächlichen Nachricht statt den Ping des Tunnels selbst und fragen Sie dann, ob die Zahl in das Budget der Schleife passt. Wenn nicht, verlegen Sie den Schritt an Bord, statt eine strengere Dienstgüte für eine Verbindung auszuhandeln, die niemand im Raum kontrolliert. Notieren Sie die gemessene Zahl mit den Bedingungen, unter denen sie erhoben wurde, denn der nächste Bericht kommt ohne sie.

Bedingung zwei: Welche Rate, Richtung und Unterbrechung können Sie erklären?

Schreiben Sie die Daten, die Rate, die Richtung und die längste Unterbrechung auf, die die Anwendung toleriert. Ein Kamera-Upload und ein Kommandokanal abwärts fallen unterschiedlich aus, und eine Unterbrechung, die eine stationäre Inspektion toleriert, beendet eine fahrende Aufgabe.

Halten Sie die physische Anbindung und den Tunnel beim Vergleich von Optionen getrennt, denn ein stärkeres Funkmodul und eine kleinere Last sind verschiedene Reparaturen. Eine große Übertragung, die irgendwann fertig wird, beweist nichts über ein zeitkritisches Ergebnis, das konstant ankommt, und ein gesunder Tunnel beweist nichts über das Funkmodul dahinter.

Dann senken Sie den Bedarf, statt ihn zu verteidigen. Reduzieren Sie die Abtastrate des Beobachtungsstroms, senden Sie Zusammenfassungen oder Deltas und lassen Sie Rohsensordaten an Bord, wo Speicher billig und Übertragung teuer ist. Eine kleinere Nutzlast schwächt das Argument für eine schnellere Verbindung und beseitigt oft die Notwendigkeit dafür.

Bedingung drei: Wer muss es sehen, und was bleibt lokal

Beobachtung ist meist eine viel kleinere Anforderung als Verarbeitung. Wenn ein Mensch die Kamera beobachten muss und anschließend ein Protokoll existieren soll, ist das Telemetrie plus Speicherung; wenn ein Modell laufen muss, fragen Sie zuerst, ob es an Bord laufen kann und nur sein Ergebnis weitergeleitet wird. Den schweren Schritt an Bord zu verlegen, entfernt die synchrone Abhängigkeit und hinterlässt eine Übertragung, die wiederholt werden kann.

Zwei ROS-Teilnehmer auf demselben Roboter rechtfertigen für sich genommen keinen Tunnel. Knotenerreichbarkeit, Anwendungsautorisierung und ein lokaler Wiederherstellungsplan sind getrennte Probleme, und ein VPN beantwortet nur das erste, und nur für den Verkehr, den es weiterleiten soll.

Einen Datensatz aufzuzeichnen ist ein eigenes Design mit eigenen Befehlen

Für ein versionsgebundenes Beispiel deckt das Aufzeichnungs-Tutorial für ROS 2 Jazzy das Aufzeichnen ausgewählter Topics, die Prüfung des entstehenden bag und seine Wiedergabe ab. Zeichnen Sie die freigegebenen Beobachtungs-Topics auf, benennen Sie den Lauf und halten Sie die Nachrichtendefinitionen und die Konfiguration daneben.

ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42

Zeichnen Sie nicht jedes Topic auf, nur weil das Werkzeug es einfach macht. Der Speicher füllt sich, Kamera- und Standortdaten sind sensibel, und ein bag mit unbenannten Topics ist ein Analyseproblem für den Nächsten, der es öffnet. Die eingesetzte Distribution entscheidet auch über die Befehle: Werkzeuge für ROS 1-bags übertragen sich nicht auf ROS 2-bags, also passen Sie die Dokumentation an die auf dem Roboter installierte Version an.

Spielen Sie in einer isolierten Analyse- oder Simulationsumgebung ab. Aufgezeichnete Kommando-Topics in die Aktoren eines laufenden Roboters abzuspielen, ist ein Unfall, und die Vorbeugung ist eine getrennte ROS-Domäne oder gar keine Hardware in der Schleife.

Entscheiden Sie, wohin die Abhängigkeit gehört, und schreiben Sie es auf: Ein VPN schützt einen Austausch, der stattfinden muss, Verarbeitung an Bord entfernt einen Austausch, der nie synchron sein musste, und ein aufgezeichneter Datensatz ersetzt einen Live-Konsumenten durch einen späteren. Testen Sie dann den getrennten Fall absichtlich, während der lokale Job noch läuft, bevor jemand das Design für fertig erklärt.