Dayanıklı bir GNSSAlıcı değerlendirmesi dar bir mühendislik sorusunu yanıtlamalıdır: kontrollü ve tekrarlanabilir koşullar altında alıcı ne raporlar, bağlı platform nasıl tepki verir ve olumsuz bir olaydan sonra kurtarmayı destekleyen kanıt nedir? Tezgah testi bir saha performans garantisi değildir. İncelenen alıcı, anten yolu, donanım yazılımı, yapılandırma, arayüzler ve platform mantığı için belgelenmiş bir karşılaştırma yöntemidir.
NIST’in Temel PNT Profili, konumlandırma, seyir ve zamanlamanın (PNT) sorumlu kullanımını çerçevelemek için Tanımla, Koru, Algıla, Yanıtla ve Kurtar işlevlerini kullanır. ABD İç Güvenlik Bakanlığı Dayanıklı PNT Uygunluk Çerçevesi sonuç odaklıdır ve dayanıklılık seviyelerini uygulama ihtiyacına göre ayırır. DHS en iyi uygulamaları ayrıca iyi tanımlanmış çıktı gözlemlenebilirlerini, olumsuzluk raporlamasını ve kurtarma yeteneklerini gerektirir. Bu referanslar risk tabanlı bir test planını destekler; hiçbir ResiNav ürünü belgelemez veya mevcut ürün dokümantasyonunun yerini almaz.
1. Testi seçmeden önce kararı tanımlayın
Testin desteklemesi gereken platform kararıyla başlayın. Örnekler arasında iki alıcı yapılandırmasını karşılaştırmak, bir denetleyicinin alıcı durum değişikliğini tanıyıp tanımadığını doğrulamak, bir alarmın operatör arayüzüne ulaşıp ulaşmadığını kontrol etmek veya platformun normal seyir moduna dönmesi için gereken koşulları belgelemek yer alır.
Kabul sorusunu gözlemlenebilir terimlerle yazın. “Alıcı dayanıklıdır” tek başına test edilebilir değildir. Yararlı bir ifade, girdi koşulunu, gözlemlenecek alıcı çıktısını veya platform tepkisini, zaman tabanını, izin verilen durum geçişlerini ve saklanacak kanıtı tanımlar.
Arayüz sorumlulukları için GNSS alıcı uyumluluk kılavuzunu ve ResiNav Teknoloji Merkezi’ni inceleyin.
2. Test öğesini ve yapılandırmayı dondurun
Tekrarlanabilir bir sonuç, tam bir yapılandırma kaydı gerektirir. İlk çalıştırmadan önce alıcı modelini, donanım revizyonunu, ürün yazılımını, etkinleştirilmiş takımyıldızları ve frekans bantlarını, mesaj setini, güncelleme hızını, dinamik modeli, yükseklik maskesini, zaman çıkışını, anteni, kabloyu, konektörü, güç kaynağını, kontrolör yazılımını ve kayıt yapılandırmasını tanımlayın.
Çalıştırmalar arasındaki her değişikliği kaydedin. Ürün yazılımı, anten kazancı, kablo kaybı, arayüz hızı veya platform filtrelemesi değişirse, sonucu önceki taban çizgisiyle birleştirmek yerine yeni bir yapılandırma olarak ele alın. Alıcının desteklediği yerlerde yapılandırma dışa aktarımlarını saklayın ve ekran görüntülerini veya komut dökümlerini yalnızca kimlik bilgilerini açığa çıkarmadıklarında saklayın.
3. Temiz bir taban çizgisi oluşturun
Taban çizgisi çalıştırması, olumsuz bir koşul eklenmeden önce tezgahın, kablolamanın, gücün ve kayıt sisteminin kararlı olup olmadığını gösterir. Alıcı durumunu, izlenen takımyıldızları ve sinyalleri, raporlanan çözüm durumunu, zaman durumunu, çıkış mesajı yaşını, arayüz hatalarını, güç olaylarını ve platformun seçili navigasyon kaynağını yakalayın.
Belgelenmiş bir sinyal kaynağı veya tesis için uygun yasal bir alım düzeni kullanın. Test ekipmanı kalibrasyon durumunu, zayıflamayı, dağıtım kayıplarını, saat referansını ve ortam RF koşullarını not edin. Halihazırda sıfırlamalar, düşen mesajlar veya kararsız güç içeren bir taban çizgisi, daha sonraki davranışı amaçlanan test koşuluna atfetmek için kullanılamaz.
4. Alıcı gözlemlenebilirlerini platform sonuçlarından ayırın
DHS en iyi uygulamaları, PNT kullanıcı ekipmanının, ekipmanın bu tür raporlamayı desteklediği durumlarda tespit edilen anormallikler veya tehditler dahil olmak üzere, test ve değerlendirme için yeterli gözlemlenebilirler ve durum bilgisi sunmasını önerir. Belgelenmemiş alanlar için anlam icat etmeden alıcının belgelenmiş çıktılarını yakalayın.
- çözüm türü, geçerlilik ve bütünlükle ilgili durum;
- izlenen sinyaller, ölçümler veya mevcut olduğunda raporlanan RF güç göstergeleri;
- mesaj yaşı, sırası ve güncelleme aralığı;
- zaman durumu ve kullanıldığında 1PPS ilişkisi;
- alıcı alarmları, sıfırlamaları ve yeniden edinme durumları;
- seri, Ethernet veya diğer arayüz hataları;
- platform kaynak seçimi, mod, alarm ve operatör bildirimi.
Bir platform alarmı, bir platform kararının kanıtıdır, RF nedeninin kanıtı değildir. Benzer şekilde, bir alıcı durum alanı, denetleyicinin bunu doğru şekilde tükettiğini veya buna göre hareket ettiğini kanıtlamaz.
5. Zaman uyumlu tek bir olay kaydı oluşturun
Sinyal kaynağı, alıcı, denetleyici ve operatör arayüzü ilişkisiz saatler kullandığında kurtarma güvenilir şekilde ölçülemez. Toplamadan önce test zaman ölçeğini, zaman damgası çözünürlüğünü ve senkronizasyon yöntemini tanımlayın. Orijinal zaman damgalarını koruyun ve sonraki hizalama veya yeniden örneklemeyi belgeleyin.
Her kontrollü koşulun başlangıcına ve sonuna olay işaretleri yerleştirin. Bunları alıcı durumu, mesaj teslimi, denetleyici kararları, tamamlayıcı sensörler ve operatör alarmlarıyla ilişkilendirin. Platform GPS zamanı, UTC, yerel bir saat veya bir ağ zaman kaynağı kullanıyorsa, dönüşümü ve bilinen sapmaları belgeleyin.
6. Kontrollü, yasal olumsuz koşullar kullanın
GPS.gov, karıştırma cihazlarının kasıtlı kullanımının Amerika Birleşik Devletleri’nde yasa dışı olduğunu belirtir ve benzer kısıtlamalar birçok yargı bölgesinde geçerlidir. Açık bir ortamda yetkisiz bir karıştırıcı veya aldatma sinyali yayınlamayın. RF olumsuzluk testlerini yalnızca yetkili, kontrollü bir tesiste uyumlu sinyal üretimi, koruma, iletim enjeksiyonu veya onaylı simülasyon yöntemleri kullanarak gerçekleştirin.
Olumsuz koşullar izlenebilir ve tekrarlanabilir olmalıdır. Örnekler belgelenmiş bir sinyal kesintisi, zayıflama profili, arayüz bağlantısının kesilmesi, güç olayı, geçersiz veya gecikmiş mesaj dizisi veya onaylı bir test vektörüyle tanımlanan simüle edilmiş girdi içerebilir. Seçilen koşul mühendislik sorusuyla eşleşmelidir; her alıcı veya platform her senaryoya maruz bırakılmamalıdır.
7. Algılamayı ve yanıtı ayrı ayrı ölçün
Algılama, tanımlanan olay işareti ile belgelenmiş bir alıcı veya platform göstergesi arasındaki aralıktır. Yanıt, girdiyi reddetme, kaynağı değiştirme, çalışmayı sınırlama, operatörü bilgilendirme veya güvenli bir duruma geçme gibi sonraki eylemdir.
Her iki aralığı da ilişkili yapılandırma ve gözlem yöntemiyle birlikte raporlayın. Tek bir zamanlama sayısını evrensel bir ürün spesifikasyonu olarak yayınlamayın. Değer, sinyal koşuluna, alıcı ayarlarına, mesaj hızına, arayüz gecikmesine, denetleyici mantığına ve platformun kendi kalıcılık filtrelerine bağlı olabilir.
8. Testi çalıştırmadan önce kurtarmayı tanımlayın
Kurtarma, bir olaydan sonraki ilk geçerli koordinattan daha fazlasıdır. DHS rehberliği, kurtarmayı olumsuz bir olaydan sonra nominal çalışmaya ve performansa geri dönüş olarak tanımlar. Bir platform testi için, normal kullanıma devam edilmeden önce karşılanması gereken alıcı ve platform koşullarını tanımlayın.
- alıcı durumu ve zaman durumu;
- belirtilen bir gözlem süresi boyunca kararlı mesaj iletimi;
- arayüz sağlığı ve tekrarlanan sıfırlamaların olmaması;
- sistemin kullandığı yerlerde tamamlayıcı sensörlerle uyum;
- denetleyici kaynak seçimi ve mod durumu;
- alarm onayı ve saklanan olay kanıtı.
Yeniden edinme, stabilizasyon ve platforma yeniden girişi ayrı olaylar olarak kaydedin. Bu, kısa süreli bir çıktının kontrollü bir hizmete dönüşle karıştırılmasını önler.
9. Bir tezgah testi kanıt matrisi oluşturun
| Kanıt grubu | Her çalıştırma için kayıt | Yanıtlanan soru |
|---|---|---|
| Yapılandırma | Alıcı, donanım yazılımı, anten, kablo, bantlar, arayüzler ve platform derlemesi | Kurulum yeniden üretilebilir mi? |
| Temel durum | Sinyal kaynağı, alıcı durumu, zaman durumu, güç ve arayüz sağlığı | Olaydan önce tezgah kararlı mıydı? |
| Olumsuz koşul | Yetkili yöntem, olay işaretleri, seviye veya profil ve süre | Hangi girdi koşulu gerçekte uygulandı? |
| Algılama | Alıcı alanları, platform alarmları ve zaman damgaları | Durum ne zaman fark edildi? |
| Yanıt | Kaynak seçimi, kontrol modu, operatör bildirimi ve güvenlik eylemi | Platform onaylı mantığını izledi mi? |
| Kurtarma | Yeniden edinim, kararlı gözlem, alarm temizleme ve dönüş kriterleri | Hizmete dönüş kontrollü müydü? |
10. Sonucu abartmadan karşılaştırmaları çalıştırın
Tekrarlanan çalıştırmalar için aynı yapılandırmayı, olay profilini, zamanlama referansını ve kabul kurallarını kullanın. Yalnızca en iyi çalıştırmayı değil, gözlemlerin dağılımını raporlayın. Başarısız ve sonuçsuz çalıştırmaları neden kodlarıyla birlikte saklayın. Bir çalıştırma hariç tutulursa, sonucu incelemeden önce hariç tutmayı belgeleyin.
Bir tezgah karşılaştırması, test edilen yapılandırma için bir mühendislik incelemesini destekler. Başka bir anten konumu, kablo, alıcı, donanım yazılımı, platform, RF ortamı veya işletim politikası için performans belirlemez. Hedef kurulum için saha doğrulaması gerekli kalır.
11. Sonuçları entegrasyon ve RFQ girdilerine dönüştürün
Alıcı modelini ve dokümantasyonunu, takımyıldızları ve bantları, anten ve kablo kısıtlamalarını, güç ve arayüzleri, gerekli mesajları, zaman çıktılarını, platform modu mantığını, kabul sorularını ve kanıt formatını sağlayın. İhtiyacın anten, terminal veya sistem seviyesinde bir entegrasyon incelemesi olup olmadığını belirtin.
Ürün kataloğuna göz atınResiNav ürün kataloğuna göz atın formunu kullanınRFQ formunu kullanın ve ardından bir mühendislik incelemesi talep etmek için formu kullanın. Ürün uyumluluğu ve dağıtım uygunluğu, mevcut ürün dokümantasyonu ve hedef platforma karşı doğrulanmalıdır.
Sıkça sorulan sorular
Başarılı bir tezgah testi saha dayanıklılığını kanıtlar mı?
Hayır. Test edilen yapılandırma ve kontrollü koşullar için davranışı belgeler. Kurulum, RF ortamı, donanım yazılımı, alıcı ayarları ve platform mantığı sonucu değiştirebilir, bu nedenle saha doğrulaması gerekli kalır.
Kurtarma süresi, parazitin sonundan ilk konum çıktısına kadar mı ölçülmeli?
Tek başına değil. Alıcının yeniden edinimini, kararlı durumunu, arayüz teslimatını, platform kaynak seçimini ve onaylanmış hizmete dönüş koşulunu ayrı olaylar olarak kaydedin.
Alıcı testi için açık hava karıştırıcı kullanılabilir mi?
Yetkisiz karıştırma veya aldatma sinyali yayılmamalıdır. Yasal, kontrollü bir tesis ve onaylı bir iletim, kalkanlı, simüle veya test vektörü yöntemi kullanın.
Bir OEM alıcı değerlendirmesi için ne sağlamalıdır?
Alıcı ve ürün yazılımını, takımyıldızları ve bantları, anten ve kabloyu, güç ve arayüzleri, gerekli gözlemlenebilirleri, platform mantığını, yetkili test koşullarını, kabul sorularını ve gerekli kanıt formatını sağlayın.
Mühendislik referansları
- NIST: Konumlandırma, Yön Bulma ve Zamanlama Hizmetlerinin Sorumlu Kullanımı
- NISTIR 8323 Rev. 1: Temel PNT Profili
- DHS: Dayanıklı PNT Uyumluluk Çerçevesi
- DHS: Dayanıklı PNT için En İyi Uygulamalar
- GPS.gov: Hakkında Bilgi GPS Sinyal Bozma
Sonraki adım
Kontrollü bir değerlendirme için alıcı, anten, arayüz ve kanıt gereksinimlerini incelemek üzere bir ResiNav mühendislik incelemesi talep edin.
SONRAKİ ADIM
Mevcut platform bilgilerini bir mühendislik incelemesine dönüştürün.
Tartışmayı çerçevelemek için Teknoloji merkezini kullanın, ilgili uygulama senaryolarını inceleyin ve ardından doğrulama için mevcut platform ve alıcı bilgilerini gönderin.