Robot industri dan kendaraan otomatis sering mengonsumsi GNSS data sebagai salah satu dari beberapa masukan. Oleh karena itu, uji penerimaan seharusnya tidak hanya menanyakan apakah penerima melaporkan posisi. Uji tersebut harus menunjukkan bagaimana platform lengkap berperilaku sebelum, selama, dan setelah gangguan sinyal yang ditentukan—dan apakah bukti yang dihasilkan cukup untuk kondisi operasi yang dimaksudkan.
NIST menjelaskan penggunaan posisi, navigasi, dan waktu (PNT) yang tangguh sebagai masalah manajemen risiko: organisasi harus mengidentifikasi sistem yang bergantung pada PNT, mendeteksi gangguan atau manipulasi, merespons, dan memulihkan. Panduan akuisisi PNT federal CISA juga menghubungkan persyaratan operasi, tingkat ketahanan, dan bukti kontrak. Kerangka kerja ini tidak mensertifikasi robot atau penerima tertentu. Kerangka kerja ini menyediakan struktur yang berguna untuk memutuskan apa yang harus dimuat dalam catatan penerimaan teknik.
1. Tentukan pertanyaan penerimaan sebelum pengujian
Mulailah dengan keputusan platform yang harus didukung oleh bukti. Contohnya meliputi:
- apakah GNSS waktu tetap selaras dengan pengontrol robot dan log sensor;
- apakah platform mendeteksi masukan navigasi yang tidak valid, menurun, atau tidak tersedia;
- apakah sistem kontrol beralih ke keadaan aman atau navigasi alternatif yang terdokumentasi;
- apakah GNSS data kembali dengan cara yang terkendali dan dapat diamati setelah gangguan berakhir;
- apakah seorang insinyur dapat mereproduksi hasil dari konfigurasi dan log yang direkam.
Catat model robot, GNSS penerima, antena, kabel, konektor, firmware, konstelasi yang diaktifkan dan pita frekuensi, protokol antarmuka, tingkat pembaruan, perangkat lunak pengujian, dan referensi waktu. Hasil tanpa konteks konfigurasi ini tidak boleh dianggap dapat ditransfer ke instalasi lain.
Untuk persiapan antarmuka, lihat GNSS Kompatibilitas Penerima untuk Anti-Jamming Integrasi dan ResiNav katalog produk.
2. Tangkap garis dasar yang bersih
Sebelum memperkenalkan gangguan yang terkendali, kumpulkan garis dasar di bawah lingkungan sinyal yang terdokumentasi. Garis dasar harus mencakup saluran data yang sama yang akan ditinjau selama peristiwa:
- solusi navigasi penerima dan bidang validitas/status;
- pengamatan satelit dan sinyal yang tersedia oleh penerima;
- output waktu, 1PPS atau pengaturan waktu pesan serial yang digunakan oleh platform;
- stempel waktu pengontrol dan stempel waktu log sensor;
- kesalahan antarmuka, pesan yang dijatuhkan, dan peristiwa koneksi ulang;
- mode operasi robot, pemilihan sumber navigasi, dan status keselamatan;
- lokasi antena, rute kabel, kondisi daya, dan pemancar di sekitarnya.
NASCTN NIST GPS pekerjaan penerima menggunakan keluaran penerima yang dapat diukur seperti kepadatan pembawa-ke-noise, kesalahan posisi, kesalahan waktu, satelit yang terlihat, waktu untuk perbaikan pertama, dan waktu untuk akuisisi ulang pertama. Uji robot industri tidak perlu menyalin program penelitian itu, tetapi harus memilih metrik yang dapat diamati sebelum pengujian daripada memilihnya setelah melihat hasilnya.
3. Verifikasi waktu sebagai properti sistem
Jika robot menggunakan GNSS untuk waktu, validasi lebih dari sekadar keberadaan sinyal 1PPS. Dokumentasikan:
- sumber waktu referensi dan ketertelusuran yang sesuai untuk pengujian;
- jalur listrik dan protokol dari penerima ke pengontrol;
- hubungan antara 1PPS, pesan waktu serial, dan stempel waktu aplikasi;
- offset normal dan variasi yang diukur selama garis dasar;
- indikasi alarm atau validitas ketika GNSS waktu menjadi tidak dapat diandalkan;
- perilaku platform saat GNSS waktu tidak tersedia;
- kondisi yang diperlukan sebelum platform menerima waktu yang dipulihkan.
Jangan menyimpulkan akurasi waktu dari label penerima atau deskripsi antarmuka nominal. Ukur perilaku pada titik di mana robot mengonsumsi informasi waktu.
4. Gunakan metode gangguan yang terkendali dan resmi
Uji frekuensi radio harus mematuhi hukum yang berlaku, aturan lokasi, dan kontrol spektrum. Jangan memancarkan sinyal jamming atau spoofing di lingkungan terbuka. Gunakan metode laboratorium resmi seperti penutup berpelindung, injeksi konduktif, GNSS simulator yang disetujui atau fasilitas terkendali lainnya yang dipilih oleh personel yang berkualifikasi.
Rencana pengujian harus menentukan:
- jenis gangguan dan metode pengujian yang diizinkan;
- penanda mulai dan berhenti yang terlihat di log RF dan log platform;
- variabel yang dikendalikan dan urutan langkah;
- pengamatan penerima dan platform pada setiap langkah;
- kriteria penghentian yang melindungi orang, peralatan, dan sistem di sekitarnya;
- metode untuk mengembalikan platform ke kondisi dasar yang telah diverifikasi.
NIST mencatat bahwa sinyal dan data PNT dapat dipengaruhi oleh peristiwa alam, buatan manusia, disengaja, dan tidak disengaja. Oleh karena itu, laporan penerimaan harus menjelaskan kondisi yang diuji secara tepat dan tidak boleh menggeneralisasi satu skenario laboratorium menjadi klaim kinerja lapangan yang universal.
5. Catat deteksi dan respons platform
Untuk setiap langkah pengujian, korelasikan peristiwa penerima dengan respons platform. Bukti yang berguna dapat mencakup:
- indikasi pertama penerima tentang data yang menurun atau tidak valid;
- alarm atau peristiwa diagnostik pertama platform;
- perubahan dalam pemilihan sumber navigasi;
- perubahan dalam mode kontrol atau perilaku keadaan aman;
- kontinuitas dan urutan pesan serial atau jaringan;
- notifikasi operator dan stempel waktu peristiwa;
- data apa pun yang tetap basi setelah bendera validitasnya berubah.
Respons aman robot adalah keputusan rekayasa tingkat aplikasi. GNSS terminal saja tidak dapat menentukan respons kontrol gerakan atau keselamatan fungsional yang benar untuk setiap platform.
Tinjau halaman aplikasi Robotika Industri dan Otomasi untuk pertanyaan integrasi yang harus diselesaikan sebelum memilih antena atau terminal.
6. Tentukan pemulihan sebelum mengukurnya
“Pulih” harus memiliki definisi tertulis. Ini mungkin memerlukan semua hal berikut:
- gangguan telah berakhir dan pengaturan pengujian mengonfirmasi kondisi input normal;
- penerima melaporkan solusi yang valid menggunakan konfigurasi yang diharapkan;
- output waktu dan navigasi tetap dalam batas yang disetujui proyek untuk periode observasi yang ditentukan;
- platform membersihkan atau mengakui alarm sesuai dengan logika yang didokumentasikan;
- pengendali melanjutkan mode navigasi yang diizinkan tanpa lompatan yang tidak dapat dijelaskan, pesan basi, atau diskontinuitas stempel waktu;
- rantai bukti lengkap ada dalam log yang diekspor.
Catat waktu akuisisi ulang dan pemulihan sebagai hasil dari konfigurasi pengujian spesifik. Jangan mengubahnya menjadi jaminan produk umum tanpa spesifikasi terverifikasi yang mencakup kondisi yang sama.
7. Bangun matriks penerimaan
| Fase pengujian | Bukti yang diperlukan | Contoh pertanyaan penerimaan |
|---|---|---|
| Konfigurasi | Penerima, antena, kabel, firmware, antarmuka, pita yang diaktifkan, dan perangkat lunak platform | Dapatkah insinyur lain mereproduksi pengaturan ini? |
| Garis dasar | Posisi/status, waktu, observasi sinyal, integritas pesan, dan status platform | Apakah perilaku normal didokumentasikan sebelum kejadian? |
| Deteksi | Perubahan validitas/alarm penerima dan stempel waktu yang berkorelasi | Apakah sistem mengenali gangguan yang ditentukan? |
| Respons | Mode platform, pemilihan sumber, tindakan keselamatan, dan indikasi operator | Apakah robot mengikuti logika respons yang disetujui? |
| Pemulihan | Akuisisi ulang, periode observasi yang stabil, pembersihan alarm, dan kontinuitas output | Apakah pengembalian ke layanan terkontrol dan dapat diaudit? |
| Laporan | Log mentah, plot, file konfigurasi, penyimpangan, dan persetujuan | Apakah keputusan didukung oleh bukti yang disimpan? |
8. Simpan paket bukti rekayasa
Paket akhir harus mencakup rencana pengujian yang disetujui, manifes konfigurasi, foto atau diagram pengaturan, informasi kalibrasi/referensi jika berlaku, log penerima mentah, log platform, penanda peristiwa, metode analisis, penyimpangan, pengamatan yang belum terselesaikan, dan nama atau peran peninjau.
Simpan data mentah terpisah dari grafik yang diinterpretasikan. Jika suatu nilai telah difilter, di-resample, atau disejajarkan, dokumentasikan transformasinya. Ini mendukung penyelidikan selanjutnya ketika firmware, penempatan antena, rute kabel, atau pengontrol robot berubah.
Pertanyaan yang sering diajukan
Apakah pengujian ini membuktikan bahwa robot industri aman di setiap GNSS lingkungan interferensi?
Tidak. Ini mendokumentasikan perilaku dalam kondisi pengaturan dan pengujian yang ditentukan. Keselamatan fungsional, kepatuhan spektrum, dan kesesuaian penempatan memerlukan insinyur platform yang bertanggung jawab dan otoritas terkait.
Waktu pemulihan mana yang harus ditentukan?
Tentukan peristiwa dan titik akhir terlebih dahulu: akuisisi ulang penerima, keluaran navigasi yang valid, stabilitas waktu, pembersihan alarm platform, atau kembali ke mode kontrol yang disetujui. Ini adalah pengukuran yang berbeda dan tidak boleh digabungkan menjadi satu angka yang tidak ditentukan.
Dapatkah pengacakan udara terbuka digunakan untuk pengujian penerimaan?
Jangan melakukan uji interferensi radiasi tanpa izin. Gunakan metode terkontrol yang sesuai hukum, dipilih oleh personel yang berkualifikasi, seperti pengaturan laboratorium berpelindung atau konduktif.
Apa yang harus dikirim dengan RFQ?
Berikan jenis platform, penerima, konstelasi dan pita, kendala antena dan kabel, antarmuka, daya, lingkungan, gambar instalasi, log yang diperlukan, dan pertanyaan penerimaan yang harus dijawab proyek. Gunakan ResiNav RFQ formulir untuk tinjauan rekayasa.
Referensi rekayasa
- NIST: Penggunaan Layanan Penentuan Posisi, Navigasi, dan Waktu yang Bertanggung Jawab
- NISTIR 8323 Rev. 1: Profil PNT Dasar
- NIST NASCTN: Dampak Sinyal LTE pada GPS Penerima
- CISA: Panduan Akuisisi Layanan PNT Federal
Langkah berikutnya
Untuk membahas rencana penerimaan yang dapat diulang untuk penerima, antena, dan platform industri Anda, minta ResiNav tinjauan teknik.
LANGKAH BERIKUTNYA
Ubah informasi platform yang tersedia menjadi tinjauan rekayasa.
Gunakan pusat Teknologi untuk membingkai pembahasan, tinjau skenario aplikasi yang relevan, lalu kirimkan rincian platform dan penerima yang tersedia untuk dikonfirmasi.