Problem
Radar, her taramada azimut, menzil ve irtifa bilgisi taşıyan blipler üretir. Blip tek bir ölçümdür; track ise aynı hedefe ait ölçümlerin zaman içinde birleştirilmesiyle oluşan takip kaydıdır. Buradaki temel problem, yeni taramadaki bliplerin mevcut track’lerden hangisine ait olduğunu belirlemekti.
Radarın dönüş hızı 36°/s olduğundan bir tarama 10 saniye sürüyor. Platform 450 knot, karşıdan yaklaşan hedef 550 knot hızdayken bu sürede göreli konum yaklaşık 5,1 km değişebiliyor. Yalnızca son konuma göre en yakın track’i seçmek, birbirine yaklaşan hedeflerde hatalı eşleştirmelere yol açabiliyor.
Korelasyon algoritması
Korelasyon gate’i. Arama yarıçapını tarama süresi ve maksimum göreli hızdan hesapladım: 1000 knot = 514,4 m/s; 10 saniyede 5144 m. 1,4 güvenlik katsayısıyla gate yarıçapı 7202 m oluyor. Tahmin edilen track konumuna bu mesafeden uzak blipler aday eşleşmelere alınmıyor. Tarama süresi veya hız sınırı değiştiğinde eşik de aynı hesapla güncellenebiliyor.
Konum tahmini. Her track’in bir sonraki konumu, son iki ölçümden hesaplanan sabit hız modeliyle tahmin ediliyor. Platforma göre kutupsal koordinatlarda gelen blipler enlem-boylama dönüştürülüyor; track-blip mesafesi Haversine formülüyle hesaplanıyor.
Eşleştirme. Gate içindeki aday track-blip çiftleri mesafeye göre sıralanıyor. Greedy matching ile her blip ve track en fazla bir eşleşmede kullanılıyor. Bu yöntem düşük maliyetli ancak tüm eşleşmeler için global optimum garantisi vermiyor.
Track yaşam döngüsü
Eşleşmeyen ilk blipten Tentative track oluşturuluyor. İkinci tutarlı ölçümle Confirmed durumuna geçiyor. Son ölçümden itibaren 30 saniye veri gelmezse Coasting, 50 saniye sonra Dropped oluyor. Yalnızca Confirmed ve Coasting track’ler yayımlanıyor; böylece tek bir gürültü ölçümü operatör ekranında hedef olarak gösterilmiyor.
Servis mimarisi
Servisi hexagonal architecture ile tasarladım. Blip, track, korelasyon motoru, koordinat dönüşümleri, platform sınıflandırma ve alarm mantığı domain katmanında bulunuyor. Bu katmanın gRPC ve Protocol Buffers bağımlılığı yok. Servis akışları application, protokol ve dış sistem bağlantıları infrastructure katmanında yer alıyor. Böylece korelasyon algoritması sunucu başlatmadan test edilebiliyor.
Radar verisindeki derece, deniz mili, feet ve knot birimleri sistem girişinde dönüştürülüyor. Domain katmanındaki hesaplamalar metre ve m/s üzerinden yürütülüyor.
Düzelttiğim tasarım hatası
İlk sürümde blip ID’lerinin taramalar arasında korunduğunu varsaydım; hit/miss sayaçlarını bu ID’lerle tuttum. Ancak ID’ler her taramada yeniden atanıyordu. Aynı hedef farklı ID ile geldiğinde track sürekliliği bozuluyordu.
Çözümde blip ID’sini korelasyon kriterlerinden çıkardım. Her taramayı bağımsız bir ölçüm kümesi olarak işleyip sürekliliği track üzerinde tuttum. Yeni ölçümler konum tahmini ve gate kontrolüyle eşleştiriliyor; ölçüm alamayan track’ler yaşam döngüsü kurallarına göre ilerliyor.
Sonuç
Korelasyon, track durum geçişleri, koordinat dönüşümleri ve multithreaded servis akışları için 108 GoogleTest testi yazdım. Ana işleme döngüsü 500 ms zaman bütçesiyle çalışıyor. Blipler thread-safe bir kuyruk üzerinden işleniyor; spdlog ile JSONL formatında log tutuluyor.
Greedy matching, yoğun trafikte toplam eşleştirme kalitesini düşürebilir. Hungarian algoritması bu sınırlamayı daha yüksek hesaplama maliyetiyle giderebilir. Sabit hız modeli de manevra yapan hedeflerde yetersiz kalabilir; bir sonraki geliştirme adımı track tahmininde bir tracking filter kullanmak.