Heterojen Makine Parkında Zaman Damgası Tutarlılığı: PLC, CNC ve IoT Verilerini Tek Bir Zaman Eksenine Oturtma

Problemin özeti ve hedef

Bir üretim hattında PLC, CNC ve çeşitli IoT sensörlerinden gelen olaylar (operasyon başlangıç/bitiş, parça geçti, hata oluştu vb.) kaydedilir. Ancak her cihazın saat kaynağı, ağ gecikmesi ve timestamp formatı farklı olabilir. Bu durum yanlış sıralama, hatalı OEE hesapları ve ERP entegrasyonunda uyuşmazlıklara yol açar. Amaç, heterojen kaynaklardan gelen tüm zaman damgalarını tek, güvenilir bir zaman eksenine (UTC) oturtmak ve veri işleme hattında deterministik, tekrar üretilebilir sonuçlar elde etmektir.

Neden zamana tutarlılık sağlanmalı?

• Sıralama ve nedensellik: Hataların kök neden analizinde olayların doğru sırada olması gerekir. Yanlış sıra, yanlış müdahaleye yol açar.
• Doğru metrikler: Çevrim süreleri, duruş analizi ve OEE gibi metrikler zaman damgasına dayanır; sapma metrikleri yanıltır.
• Entegrasyon güveni: ERP/APS/Fatura kayıtları için zaman uyuşmazlıkları iş süreçlerini bozar.

Genel çözüm mimarisi ve bileşenleri

Çözüm birden fazla katmandan oluşmalıdır: ağ tabanlı saat dağıtımı, saha (edge) düzeltmeleri, güvenilir mesajlaşma, servis katmanı ve kalıcı depolama. Bu katmanların sorumlulukları aşağıdaki gibidir:

• Saat senkronizasyonu: Fabrika ağı içinde merkezi NTP sunucusu; mümkünse PTP ile yüksek hassasiyet dağıtımı.
• Edge Gateway: Cihazdan gelen ham timestamp'i düzeltir, latency/offset ölçer, monoton gateway_sequence ekler ve tamponlama yapar.
• Mesajlaşma: MQTT, Kafka veya RabbitMQ ile per-source partitioning/queue. FIFO gereksinimi olan kaynaklara özel partition/queue.
• API/Servis Katmanı: Idempotency kontrolü, validasyon, geçici hatalara karşı retry, upsert pattern ile veritabanına yazma.
• Kalıcı Depolama: SQL Server üzerinde datetimeoffset ve ek alanlarla saklama, reconciliation tabloları ve indeksler.

Zaman senkronizasyonu: NTP vs PTP ve pratik kurulum notları

NTP çoğu endüstriyel senaryo için yeterlidir; ancak milisaniye-altı hassasiyet gereken CNC, robotik veya eş zamanlı hareket kontrolü uygulamalarında PTP tercih edilir. Uygulama notları:

• Fabrika içinde bir veya birden fazla NTP sunucusu kurun; internet bağımlılığını azaltmak için GPS alıcılı yerel NTP sunucusu düşünün.
• PTP planlanıyorsa switch'lerin boundary clock veya transparent clock desteği olmasına dikkat edin; topoloji tasarımını üreticinin PTP kılavuzuna göre yapın.
• Eski cihazlar doğrudan senkronize edilemiyorsa, edge gateway aracılığıyla düzeltme uygulamayı planlayın.

Edge Gateway: saha düzeltmesi ve pratik algoritmalar

Edge gateway, saat düzeltmesi ve veri standardizasyonunun merkezi noktasıdır. Aşağıda uygulanabilir teknik adımlar yer alıyor:

• Offset ölçümü: İlk bağlantıda cihazla gateway arasında karşılıklı zaman kaydı alarak offset0 hesaplayın. Çift yönlü timestamp alabiliyorsa NTP benzeri formül kullanılabilir. Tek yönlü durumda baseline için bir dizi ölçüm alın.
• Gecikme tahmini: Ağ gecikmesini düzenli olarak ölçün (ping/traceroute veya uygulama seviyesinde request-response). Ortalama ve standart sapma tutun; anormal yüklenmelerde düzeltme değişkenliği artar.
• Düzeltme formülü: correctedUtc = deviceTime + offset(t) + estimatedOneWayLatency. Latency bilinmiyorsa conservative yaklaşım latency/2 ile hesaplanır.
• Drift modelleme: Cihaz saat sapmalarını lineer regresyon veya basit moving average ile modelleyin. Daha sofistike uygulamalarda Kalman filtresi ile sürekli hata tahmini yapılabilir.
• Monoton gateway_sequence: Her eventi gateway tarafında 64-bit monotonik sequence ile işaretleyin. Bu sequence, ağ gecikmeleri ve broker reorder durumlarında kesin sıralama sağlar.
• Buffering ve offline çalışma: Ağ kesildiğinde veriyi disk/DB'ye sırayla tamponlayıp bağlantı geri geldiğinde sırası bozulmadan gönderin. Gönderim sırasında gateway_sequence kullanarak replay yapın.

Pratik offset ölçümü örneği

Basit karşılıklı zaman alışverişi (A = gateway, B = device):

• A zamanında T1 gönderir, B zamanı T2 olarak kaydeder.
• B yanıtı T3 ile gönderir, A bunu T4 olarak alır.

NTP formülünün sade haliyle offset = ((T2 - T1) + (T3 - T4)) / 2. Tek yönlü sınırlamalarda bir dizi ölçüm alıp median offset kullanmak istikrarlı sonuç verir.

Cihaz türlerine özel uygulanabilir ipuçları

PLC

• OPC UA kullanıyorsanız, sunucu tarafı timestamp ve publishing interval ayarlarını kontrol edin. Server timestamp genelde daha güvenilirdir.
• Eski PLC'lerde device_time sadece lokal saat olabilir; bu durumda gateway offset ve drift kayıtlarını tutun.

CNC

• Yüksek hassasiyet gereken hareket kontrolünde PTP tercih edin. Kontrolör üreticisinin PTP/IEEE 1588 destek dökümantasyonunu takip edin.
• Loglar batch halinde geliyorsa, batch içindeki olayların relative zamanlamasını koruyup başlangıç/bitiş zamanlarını gateway'de normalize edin.

IoT sensörleri

• Pil ile çalışan cihazlarda saat drift'i daha hızlıdır; uzun dönem offset kayıtları ve drift eğrisi çıkarın.
• MQTT kullanan sensörlerde broker zaman damgası ile device timestamp karşılaştırması otomatik bir kontrol katmanı sağlayabilir.

Veri modeli ve SQL Server uygulama önerileri

Veritabanı şeması, orijinal ve düzeltilmiş zamanlarla birlikte sequence ve idempotency bilgilerini tutmalıdır. Örnek alanlar:

• utc_timestamp (datetimeoffset) -- gateway düzeltilmiş UTC
• source_timestamp (nvarchar veya datetimeoffset) -- cihazın gönderdiği ham zaman
• source_id (nvarchar) -- cihaz kimliği
• gateway_sequence (bigint) -- gateway tarafından verilen monoton sıra
• device_sequence (bigint) -- cihaz tarafından sağlanıyorsa
• idempotency_key (nvarchar) -- duplicate tespit için

Index önerileri:

• Bileşik index: (source_id, gateway_sequence) -- per-device sorgularda hızlı arama sağlar.
• Zaman bazlı index: (utc_timestamp, source_id) -- zaman aralığı sorgularında faydalıdır.

Güncelleme stratejisi: API katmanında transaction ile MERGE/UPSERT kullanın; idempotency_key ile tekrar gelen payload'ları güvenli şekilde atın veya güncelleyin. Örnek akıl yürütme: aynı idempotency_key ile gelen event ilk işlemde eklenir, tekrar geldiğinde timestamp/gateway_sequence tutarsızsa loglanıp ikinci işlem atlanır.

İşleme hattı: sıra, idempotency ve mesajlaşma

• Idempotency key: source_id + device_sequence veya source_id + eventHash kombinasyonunu kullanın. API, aynı anahtar göründüğünde işlemi ignore etsin.
• Partitioning: Kafka kullanıyorsanız partition by source_id ile tek cihazın kayıtları aynı partitionda kalır ve consumer sırasını korur.
• Consumer mantığı: Consumer son işlenen gateway_sequence'i kontrol etmeli; gap tespit edilirse eksik kayıtlar için retry/alert mekanizması olsun.

Gecikme, anomaliler ve reconciler

Ağ gecikmesi ve saat anomalileri için hem gerçek zamanlı hem batch kontrol mekanizmaları kurun:

• Gerçek zamanlı: cihaz başına rolling offset ortalaması/standart sapma alarmı. Sapma eşik geçerse operatöre uyarı gönderin.
• Batch reconciler: gecelik job ile aynı iş emrindeki çakışan zaman aralıklarını raporlayın; otomatik düzeltme veya operatör onayı akışları oluşturun.
• Operatör dashboard'ı: cihaz bazlı offset, drift grafiği, paket kaybı oranı ve sequence gap metriği gösterin.

Test, pilot ve ölçülebilir başlangıç adımları

Pratik bir pilot planı:

• Öncelikle 5-10 kritik cihaz seçin ve 1 hafta boyunca offset baseline ölçün.
• Edge gateway prototipi kurarak offset hesaplama, latency estimation ve gateway_sequence uygulayın; 2 hafta izlemede sonuçları değerlendirin.
• API tarafında idempotency ve upsert pattern'i hayata geçirin, SQL Server tarafında örnek indeksleri oluşturun ve sorgu performansını ölçün.

Ölçeklendirme ve operasyonel dikkat noktaları

• Gateway sayısını fiziksel/topolojik olarak ayırın; tek gateway tüm tesis için tek hata noktası oluşturmasın.
• Sequence overflow riskine karşı 64-bit kullanın ve rollover durumunu sistem olarak handle edin.
• Her bir cihaz için SLA tanımlayın: maksimum toleranslı offset, paket kaybı eşiği, gecikme eşiği.

Sonuç ve pratik öneriler

Zaman damgası tutarlılığı, tek bir teknolojiyle çözülecek bir sorun değildir; ağ katmanı, saha düzeltmeleri, mesajlaşma ve veri modeli birlikte ele alınmalıdır. İlk adımlar olarak cihazların saat durumunu ölçün, bir edge gateway prototipi kurun ve API/DB tarafında idempotency ile gateway_sequence mekanizmasını devreye alın. Bu yaklaşım, ERP ve raporlama sistemleriyle entegre olurken güvenilir ve tekrarlanabilir veri sağlar.

Detaylı uygulama veya saha testi desteği için iletişim sayfamızdan ulaşabilirsiniz. Daha geniş kapsamlı üretim takip çözümlerimiz için Üretim Takip Hizmetleri sayfasına bakabilirsiniz.

Not: Cihaz üreticisi, ağ topolojisi ve zaman hassasiyeti gereksinimleri çözüme yön verecektir; küçük ölçekli pilot ve saha testi her zaman tavsiye edilir.