Traitement en direct ou données enregistrées : de quoi un VPN a-t-il vraiment besoin ?

Un robot qui cesse d’être utile à une pièce de distance a un problème de lien ou de charge de travail bien avant d’avoir un problème de VPN. Le chiffrement protège un chemin ; il n’étend pas la couverture radio et ne fait pas finir plus tôt un calcul distant. La décision devant vous est quel travail doit réellement traverser le réseau, et cette réponse élimine généralement plus de trafic que les gens ne l’imaginent. Trois conditions en décident, et le débit n’en fait pas partie.

Trois dispositions, une seule question de dépendance

Le tableau sépare les dispositions selon ce qui dépend du lien, et non selon le logiciel qui apparaît sur le schéma.

Aucune ligne de ce tableau n’est un argument de sécurité. Les fonctions de contrôle et de sécurité ont toujours besoin d’une réponse qualifiée sur le délai, la perte de paquets et une connexion coupée, et aucun indicateur de tunnel ne la fournit. Le tableau indique où vit la dépendance, et c’est la partie qu’une conception réseau peut réellement changer.

Première condition : la réponse doit-elle être opportune ?

Si un résultat distant alimente un contrôleur, le réseau se trouve dans la boucle de contrôle, et son délai, sa gigue et ses coupures deviennent des propriétés de la commande. Si le même résultat n’alimente qu’un écran, un tableau de bord ou une personne qui regarde, le même délai est cosmétique.

Le travail en boucle fermée sur un lien sans fil est possible, et c’est aussi de là que viennent la plupart des rapports « le VPN est lent », car le tunnel est le composant visible tandis que la radio et le routage sont la cause. Mesurez l’aller-retour du message réel plutôt que le ping du tunnel, puis demandez si le chiffre tient dans le budget de la boucle. Quand ce n’est pas le cas, déplacez l’étape à bord au lieu de négocier un niveau de service plus strict pour un lien que personne dans la salle ne contrôle. Notez le chiffre mesuré avec les conditions dans lesquelles il a été pris, car le prochain rapport arrivera sans elles.

Deuxième condition : quel débit, quelle direction et quelle interruption pouvez-vous déclarer ?

Notez les données, le débit, la direction et l’interruption la plus longue que l’application tolère. Un flux caméra montant et un canal de commandes descendant échouent de manières différentes, et une interruption qu’une inspection fixe tolère mettra fin à une tâche en mouvement.

Gardez l’attachement physique et le tunnel séparés lorsque vous comparez les options, car une radio plus puissante et une charge plus faible sont des réparations différentes. Un gros transfert qui finit par aboutir ne prouve rien sur l’arrivée régulière d’un résultat sensible au temps, et un tunnel sain ne prouve rien sur la radio derrière lui.

Réduisez ensuite la demande au lieu de la défendre. Sous-échantillonnez le flux d’observation, envoyez des résumés ou des deltas, et laissez les données brutes des capteurs à bord, là où le stockage est bon marché et la transmission non. Une charge plus légère affaiblit l’argument en faveur d’un lien plus rapide et supprime souvent le besoin d’en avoir un.

Troisième condition : qui doit le voir, et qu’est-ce qui reste local

L’observation est généralement une exigence bien plus faible que le traitement. Si une personne doit regarder la caméra et qu’un journal doit exister ensuite, c’est de la télémétrie plus du stockage ; si un modèle doit tourner, demandez d’abord s’il peut tourner à bord avec seulement son résultat transmis. Déplacer l’étape lourde à bord supprime la dépendance synchrone et laisse un transfert qui peut être réessayé.

Deux participants ROS sur le même robot ne justifient pas un tunnel à eux seuls. L’accessibilité des nœuds, l’autorisation de l’application et un plan de récupération local sont des problèmes distincts, et un VPN ne répond qu’au premier, et seulement pour le trafic qu’on lui demande d’acheminer.

Enregistrer un jeu de données est une conception à part entière, avec ses propres commandes

Pour un exemple lié à une version, le tutoriel d’enregistrement de ROS 2 Jazzy couvre l’enregistrement de sujets sélectionnés, l’inspection du bag obtenu et sa relecture. Enregistrez les sujets d’observation approuvés, nommez l’exécution et gardez les définitions de messages et la configuration à côté.

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

N’enregistrez pas tous les sujets parce que l’outil rend cela facile. Le stockage se remplit, les données de caméra et de localisation sont sensibles, et un bag de sujets non étiquetés est un problème d’analyse pour la prochaine personne qui l’ouvrira. La distribution déployée décide aussi des commandes : les outils écrits pour les bags ROS 1 ne se transposent pas aux bags ROS 2, alors faites correspondre la documentation à la version installée sur le robot.

Rejouez dans un environnement d’analyse ou de simulation isolé. Rejouer des sujets de commande enregistrés dans les actionneurs d’un robot en fonctionnement est un accident, et la prévention est un domaine ROS séparé ou aucun matériel dans la boucle.

Décidez où appartient la dépendance et écrivez-le : un VPN protège un échange qui doit avoir lieu, le traitement à bord supprime un échange qui n’avait jamais besoin d’être synchrone, et un jeu de données enregistré remplace un consommateur en direct par un consommateur ultérieur. Testez ensuite délibérément le cas déconnecté, avec la tâche locale toujours en cours, avant que quiconque déclare la conception terminée.