TR / EN

Maden Sahalarında Personel ve Araç Takip Projesi Nasıl Planlanır?

Yer altı personel ve araç takibi konuşulurken masa üzerindeki ilk çizim genellikle tag, okuyucu ve merkezi sunucudan oluşur. Sahaya inildiğinde tünel geometrisi, enerji noktaları, toz, nem, titreşim, haberleşme kesintileri ve vardiya akışı bu sade çizimi hızla değiştirir. Bir okuyucunun çalışması, ürettiği olayın operasyon açısından doğru ve zamanında olduğu anlamına gelmez.

Nisan-Temmuz 2026 döneminde ele aldığımız anonim bir saha çalışmasında projeyi cihaz kurulumu değil, operasyonel yetenek geliştirme programı olarak yönettik. Tag reader, hat başı bileşenleri, araç/personel tag’leri ve merkezi uygulama yalnızca teknik yapı taşlarıydı. İş güvenliği, saha operasyonu, altyapı, BT, insan kaynakları ve tedarikçi aynı kabul ölçütlerinde buluşmadan canlıya geçiş planlanmadı.

Sorunun ortaya çıkışı

Kurum, vardiya sırasında personel ve araçların belirlenmiş bölgelere giriş-çıkışını merkezi olarak görmek istiyordu. İlk kapsam cihaz adetleri üzerinden hazırlanmış, hangi iş kararının hangi konum hassasiyetine ve gecikme süresine ihtiyaç duyduğu yazılmamıştı. “Yer altında takip” ifadesi gerçek zamanlı koordinattan bölge bazlı geçiş olayına kadar farklı beklentiler yaratıyordu. Önce bu beklentiyi ölçülebilir kullanım senaryolarına çevirdik.

Saha keşfinde plan üzerindeki güzergâh ile fiili operasyonun farklı olduğu görüldü. Geçici çalışma alanları, hareket eden ekipmanlar, enerji kesintisi olasılığı ve bakım erişimi cihaz yerleşimini etkiliyordu. Merkezi sunucuya bağlantı için tek yol varsayılmış, bağlantı kesildiğinde olayların yerelde tutulup tutulmayacağı netleştirilmemişti. Projenin fiziksel, ağ ve uygulama bağımlılıkları tek takvimde görünmüyordu.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım üretici çizimindeki kapsamanın saha kabulü yerine geçeceğiydi. Kaya yapısı, tünel dönüşleri, metal ekipman, montaj yüksekliği ve hareketli araçlar radyo davranışını değiştirebilir. İkinci varsayım tag görülmüyorsa sorunun doğrudan tag arızası olduğuydu. Okuyucu enerjisi, anten, hat bileşeni, ağ yolu, zaman senkronizasyonu veya sunucu işleme kuyruğu aynı belirtiyi yaratabilir.

Bir başka belirti kullanıcıların ekranda gördüğü konumu kesin koordinat olarak yorumlamasıydı. Sistem bölge veya okuyucu geçişi mantığıyla çalışıyorsa gösterim de bu belirsizliği açıkça ifade etmelidir. “Anlık” sözcüğü de ölçülmemişti; olayın sahada oluşması ile ekranda görünmesi arasında kabul edilen gecikme tanımlanmayınca tedarikçi ve operasyon farklı başarı ölçütleri kullandı.

Teknik analiz

Kapsamayı masa başı tasarım, saha ölçümü ve pilot doğrulama olarak üç aşamaya böldük. Kritik geçiş noktaları, kaçış güzergâhları, girişler ve operasyon bölgeleri kullanım senaryosuna göre sınıflandırıldı. Her cihaz için enerji, montaj, çevresel dayanım, bakım erişimi ve iletişim bağımlılığı kaydedildi. Tek bir kapsama yüzdesi yerine kritik nokta tespit oranı, olay gecikmesi ve kesinti sonrası veri bütünlüğü ölçüldü.

Uçtan uca veri akışı tag’den okuyucuya, ara haberleşme bileşenine, saha ağına, merkezi uygulamaya ve API tüketicisine kadar izlendi. Cihaz ile sunucu saatlerinin güvenilir kaynaktan eşlenmesi olay sırasını korumak için kritik bulundu. Bağlantı kesintisinde tampon kapasitesi, tekrar gönderim, yinelenen kayıt ve kayıp olay davranışı test edildi. API alanları veri sahibi ve amaçla eşleştirildi.

Uygulanan çözüm veya önerilen mimari

Önce sınırlı fakat operasyon açısından temsilî bir pilot bölge seçildi. Okuyucu ve hat bileşenleri saha güvenliği kurallarına uygun monte edildi; enerji ve ağ yolları izlenebilir biçimde etiketlendi. Merkezi SmartFlow benzeri uygulama yedekleme, izleme ve zaman senkronizasyonu olan sunucu katmanında çalıştırıldı. Üretim ağına erişimler gerekli akışlarla sınırlandı ve uzaktan bakım ayrı onay sürecine bağlandı.

Pilot kabulü cihazın çevrimiçi görünmesine değil, tanımlı personel ve araç senaryolarının doğru olay üretmesine dayandı. Sonuçlar operasyon, iş güvenliği ve BT tarafından birlikte imzalandı. Yaygınlaştırma lokasyon paketlerine ayrıldı; her pakette saha hazırlığı, kurulum, test, eğitim ve as-built dokümantasyon tamamlanmadan sonraki bölgeye geçilmedi. API entegrasyonu pilot veri kalitesi doğrulandıktan sonra açıldı.

Alternatifler ve karar gerekçesi

Bölge bazlı RFID benzeri yaklaşım daha sade altyapı ve belirli geçiş noktalarında güvenilir olay sağlayabilir; sürekli ve hassas koordinat beklentisini karşılamaz. UWB gibi daha hassas çözümler daha yoğun altyapı, kalibrasyon ve maliyet gerektirebilir. Wi-Fi veya BLE tabanlı seçenekler mevcut altyapıdan yararlanabilir, ancak yer altı ortamında kapsama ve cihaz davranışı mutlaka sahada doğrulanmalıdır.

Tek seferde tüm sahaya yayılım takvimi kısaltıyor gibi görünür; tasarım hatasını çoğaltma ve operasyonu zorlayacak büyük değişiklik riski taşır. Pilot sonrası dalgalı yayılım daha uzun planlama gerektirir, fakat yerleşim standardını gerçek veriye göre geliştirir. Kullanım senaryosu bölge geçişi olduğu için teknoloji kararını pazarlama hassasiyetine değil, kabul edilen doğruluk ve bakım yapılabilirliğine bağladık.

Güvenlik ve operasyonel riskler

Konum olayları çalışan davranışı ve iş güvenliğiyle ilişkili kişisel veri oluşturabilir. Amaç, erişim rolleri, saklama süresi, çalışan bilgilendirmesi ve hukuki dayanak proje başında belirlenmelidir. Yönetim ekranları herkese açılmamalı, rapor dışa aktarımları izlenmeli ve testte gerçek kişi yerine kontrollü kimlikler kullanılmalıdır. API kimlikleri kod veya dokümana yazılmadan güvenli kasada tutulmalıdır.

Sistem tek başına hayat güvenliği sağlayan mekanizma olarak kabul edilmemelidir; kapsama veya bağlantı kesintisi mümkün olduğundan mevcut acil durum prosedürlerini tamamlamalıdır. Yanlış konumun operasyon kararına etkisi ve manuel doğrulama yöntemi yazılmalıdır. Cihaz arızası, enerji kesintisi, sunucu doluluğu ve zaman sapması için alarm ile müdahale sahibi bulunmalı; yedek parça ve saha erişimi planlanmalıdır.

Çıkarılan Dersler

Kontrol Listesi