Pemrosesan langsung atau data terekam: apa yang benar-benar membutuhkan VPN?

Robot yang berhenti berguna begitu berada satu ruangan lebih jauh sudah punya masalah tautan atau masalah beban kerja jauh sebelum punya masalah VPN. Enkripsi melindungi sebuah jalur; ia tidak memperluas jangkauan radio, dan tidak membuat komputasi jarak jauh selesai lebih cepat. Keputusan yang ada di depan Anda adalah pekerjaan mana yang benar-benar harus melewati jaringan, dan jawaban itu biasanya membuang lebih banyak lalu lintas daripada yang orang duga. Tiga syarat menentukan hal ini, dan throughput bukan salah satunya.

Tiga susunan, satu pertanyaan ketergantungan

Tabel itu memisahkan susunan berdasarkan apa yang bergantung pada tautan, bukan berdasarkan perangkat lunak yang muncul di diagram.

Tidak ada satu baris pun dalam tabel itu yang merupakan argumen keselamatan. Fungsi kendali dan keselamatan tetap membutuhkan jawaban yang memadai untuk penundaan, kehilangan paket, dan koneksi yang terputus, dan tidak ada indikator tunnel yang menyediakannya. Tabel itu memberi tahu tempat ketergantungan berada, yaitu bagian yang sebenarnya bisa diubah oleh desain jaringan.

Syarat pertama: apakah jawabannya harus tepat waktu?

Jika hasil jarak jauh memberi masukan ke pengendali, jaringan berada di dalam lingkar kendali, sehingga penundaan, jitter, dan pemutusannya menjadi sifat kendali. Jika hasil yang sama hanya memberi masukan ke layar, dasbor, atau orang yang mengamati, penundaan yang identik itu hanya bersifat kosmetik.

Pekerjaan lingkar tertutup melalui tautan nirkabel memang mungkin, dan di situlah sebagian besar laporan “VPN-nya lambat” berasal, karena tunnel adalah komponen yang terlihat sementara radio dan perutean adalah penyebabnya. Ukur waktu bolak-balik pesan yang sebenarnya, bukan ping tunnel itu sendiri, lalu tanyakan apakah angka itu cocok dengan anggaran lingkar kendali. Jika tidak cocok, pindahkan langkah tersebut ke perangkat alih-alih menegosiasikan tingkat layanan yang lebih ketat untuk tautan yang tidak dikendalikan siapa pun di ruangan itu. Catat angka hasil pengukuran beserta kondisi saat pengukuran, karena laporan berikutnya akan datang tanpa kondisi tersebut.

Syarat kedua: laju, arah, dan gangguan seperti apa yang bisa Anda nyatakan?

Tuliskan datanya, lajunya, arahnya, dan gangguan terpanjang yang masih ditoleransi aplikasi. Aliran kamera ke arah atas dan kanal perintah ke arah bawah gagal dengan cara berbeda, dan gangguan yang masih bisa ditoleransi inspeksi diam akan mengakhiri tugas yang bergerak.

Pisahkan sambungan fisik dan tunnel saat membandingkan pilihan, karena radio yang lebih kuat dan beban kerja yang lebih kecil adalah dua perbaikan yang berbeda. Transfer besar yang akhirnya selesai tidak membuktikan apa pun tentang hasil sensitif waktu yang datang secara konsisten, dan tunnel yang sehat tidak membuktikan apa pun tentang radio di belakangnya.

Lalu kurangi permintaannya, bukan mempertahankannya. Turunkan laju sampel aliran pengamatan, kirim ringkasan atau delta, dan biarkan data sensor mentah tetap di perangkat di tempat penyimpanan murah sedangkan transmisi tidak. Muatan yang lebih kecil melemahkan alasan untuk tautan yang lebih cepat, dan sering menghapus kebutuhan akan tautan itu.

Syarat ketiga: siapa yang harus melihatnya, dan apa yang tetap lokal

Pengamatan biasanya merupakan kebutuhan yang jauh lebih kecil daripada pemrosesan. Jika seseorang harus menonton kamera dan log harus ada sesudahnya, itu telemetri plus penyimpanan; jika sebuah model harus berjalan, tanyakan dulu apakah model itu bisa berjalan di perangkat dengan hanya hasilnya yang diteruskan. Memindahkan langkah berat ke perangkat menghapus ketergantungan sinkron dan menyisakan transfer yang bisa diulang.

Dua peserta ROS yang ada di robot yang sama tidak dengan sendirinya membenarkan sebuah tunnel. Keterjangkauan node, otorisasi aplikasi, dan rencana pemulihan lokal adalah masalah yang terpisah, dan VPN hanya menjawab yang pertama, dan hanya untuk lalu lintas yang diminta untuk dirutekan.

Merekam kumpulan data adalah desain tersendiri, dengan perintahnya sendiri

Untuk contoh yang terikat versi, tutorial perekaman ROS 2 Jazzy mencakup perekaman topik terpilih, pemeriksaan bag yang dihasilkan, dan pemutarannya kembali. Catat topik pengamatan yang disetujui, beri nama pada run, dan simpan definisi pesan serta konfigurasi di sampingnya.

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

Jangan merekam setiap topik hanya karena alatnya memudahkan. Penyimpanan akan penuh, data kamera dan lokasi mengandung sensitivitas, dan bag berisi topik tanpa label menjadi masalah analisis bagi siapa pun yang membukanya berikutnya. Distribusi yang terpasang juga menentukan perintahnya: perkakas yang ditulis untuk bag ROS 1 tidak berlaku untuk bag ROS 2, jadi cocokkan dokumentasi dengan versi yang terpasang di robot.

Putar kembali di lingkungan analisis atau simulasi yang terisolasi. Topik perintah hasil rekaman yang diputar ulang ke aktuator robot yang sedang berjalan adalah kecelakaan, dan pencegahannya adalah domain ROS terpisah atau tanpa perangkat keras sama sekali di dalam lingkar.

Tentukan di mana ketergantungan itu seharusnya berada dan tuliskan: VPN melindungi pertukaran yang memang harus terjadi, pemrosesan di perangkat menghapus pertukaran yang tidak pernah perlu sinkron, dan kumpulan data terekam menggantikan konsumen langsung dengan konsumen yang datang belakangan. Lalu uji kasus terputus dengan sengaja, sementara pekerjaan lokal tetap berjalan, sebelum siapa pun menyebut desainnya selesai.