Direktbearbetning eller inspelade data: vad behöver egentligen ett VPN?

En robot som slutar vara användbar en rum bort har ett länkproblem eller ett arbetsbelastningsproblem långt innan det har ett VPN-problem. Kryptering skyddar en väg, men den utökar inte radioreckvidden och den gör inte en fjärrberäkning klar tidigare. Beslutet framför dig är vilket arbete som verkligen måste korsa nätet, och det svaret tar oftast bort mer trafik än folk förväntar sig. Tre villkor avgör det, och genomströmning är inte ett av dem.

Tre uppställningar, en beroendefråga

Tabellen skiljer uppställningarna åt efter vad som beror på länken, inte efter vilken programvara som syns i diagrammet.

Ingen rad i den tabellen är ett säkerhetsargument. Styr- och säkerhetsfunktioner behöver fortfarande ett kvalificerat svar för fördröjning, paketförlust och en bruten anslutning, och ingen tunnelindikator ger ett. Tabellen berättar var beroendet bor, och det är den delen en nätverksdesign faktiskt kan ändra.

Villkor ett: måste svaret vara i tid?

Om ett fjärrresultat matar en regulator sitter nätet inne i reglerslingan, och dess fördröjning, jitter och avbrott blir regleregenskaper. Om samma resultat bara matar en skärm, en instrumentpanel eller en person som tittar, är den identiska fördröjningen bara kosmetisk.

Reglerkretsarbete över en trådlös länk är möjligt, och det är också där de flesta "VPN:et är långsamt"-rapporterna uppstår, eftersom tunneln är den synliga komponenten medan radion och routingen är orsaken. Mät runtiden för det faktiska meddelandet i stället för själva tunnelns ping, och fråga sedan om talet passar i slingans budget. Om inte, flytta steget ombord i stället för att förhandla fram en strängare servicenivå för en länk som ingen i rummet kontrollerar. Skriv ned det uppmätta talet tillsammans med villkoren det togs under, för nästa rapport kommer att anlända utan dem.

Villkor två: vilken takt, riktning och avbrott kan du deklarera?

Skriv ned data, takt, riktning och det längsta avbrott som applikationen tolererar. En kameraström uppåt och en kommandokanal nedåt misslyckas på olika sätt, och ett avbrott som en stationär inspektion tolererar avslutar en uppgift i rörelse.

Håll den fysiska anslutningen och tunneln åtskilda när du jämför alternativ, eftersom starkare radio och mindre arbetsbelastning är olika reparationer. En stor överföring som till slut går igenom bevisar ingenting om ett tidskritiskt resultat som kommer jämnt, och en frisk tunnel bevisar ingenting om radion bakom den.

Minska sedan efterfrågan i stället för att försvara den. Sampla ned observationsströmmen, skicka sammanfattningar eller deltan, och låt rå sensordata stanna ombord där lagring är billig och överföring inte är det. En mindre nyttolast försvagar argumentet för en snabbare länk och tar ofta bort behovet av en.

Villkor tre: vem måste se det, och vad stannar lokalt

Observation är vanligtvis ett mycket mindre krav än bearbetning. Om en person måste titta på kameran och en logg måste finnas efteråt är det telemetri plus lagring; om en modell måste köras, fråga först om den kan köras ombord med bara resultatet vidarebefordrat. Att flytta det tunga steget ombord tar bort det synkrona beroendet och lämnar en överföring som kan göras om.

Att två ROS-deltagare finns på samma robot rättfärdigar inte en tunnel i sig. Nåbarhet för noder, applikationsauktorisering och en lokal återställningsplan är separata problem, och ett VPN svarar bara på det första, och bara för den trafik det ombeds routa.

Att spela in en datamängd är en egen design, med egna kommandon

För ett versionbundet exempel, ROS 2 Jazzy-handledningen för inspelning täcker inspelning av valda ämnen, inspektion av den resulterande bagen och uppspelning av den. Spela in de godkända observationsämnena, ge körningen ett namn, och förvara meddelandedefinitionerna och konfigurationen bredvid.

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

Spela inte in varje ämne bara för att verktyget gör det enkelt. Lagringen fylls, kamera- och positionsdata är känsliga, och en bag med omärkta ämnen är ett analysproblem för den som öppnar den nästa gång. Den installerade distributionen avgör också kommandona: verktyg skrivna för ROS 1-bagar flyttas inte över till ROS 2-bagar, så anpassa dokumentationen till versionen som är installerad på roboten.

Spela upp i en isolerad analys- eller simuleringsmiljö. Inspelade kommandoämnen som spelas upp i en levande robots ställdon är en olycka, och förebyggandet är en separat ROS-domän eller ingen hårdvara alls i slingan.

Bestäm var beroendet hör hemma och skriv ned det: ett VPN skyddar ett utbyte som måste ske, bearbetning ombord tar bort ett utbyte som aldrig behövde vara synkront, och en inspelad datamängd ersätter en levande konsument med en senare. Testa sedan det frånkopplade fallet med avsikt, medan det lokala jobbet fortfarande kör, innan någon kallar designen klar.