Heterojen Makine Parkından Gerçek Zamanlı Veri Toplama ve ERP Entegrasyonu: Teknik Rehber

Giriş: Hedeflenen problem

Üretim tesislerinde farklı yaşlarda ve farklı üreticilerden gelen makineler, çeşitli protokoller (OPC UA, Modbus, seri, özel TCP) ve farklı zaman damgalarıyla veri üretir. Bu heterojen parkta hedef, IoT endüstriyel otomasyon hizmetimiz kapsamında kullanılan genel yaklaşımlardan bağımsız olarak, güvenilir, düşük gecikmeli ve tutarlı bir veri akışı kurmaktır; böylece ERP sistemine gerçek zamanlı veya yakın-gerçek zamanlı olarak doğru veri iletilebilir.

Sorun tanımı ve başarım kriterleri

• Farklı protokoller ve veri biçimlerinden gelen verileri birleştirip normalleştirme.
• Zaman damgası uyumsuzlukları ve saat sapmalarını yönetme.
• Tekrarlanan veya eksik mesajları algılama ve düzeltme.
• ERP ile veri eşitlemesini idempotent ve izlenebilir hale getirme.
• Operasyonel metrikler ve hatalar için gözlemlenebilirlik sağlama.

Adım 1: Uçta (edge) güvenilir toplama

Her makineden veriyi doğrudan merkezi API'ye göndermek genellikle uygulanamaz. Bunun yerine uçta bir gateway katmanı önerilir:

• Protocol adapter: OPC UA, Modbus, Profinet, seri port gibi arayüzleri okuyan küçük servisler. Bu adaptörler veriyi standart bir iç formatta (ör. JSON: {"deviceId","sensorId","ts","seq","value","unit"}) üretir.
• Geçici saklama: Ağ kopması veya merkezi servis bakımında veriyi lokal olarak persist et (SQLite, küçük dosya tabanlı queue). FIFO kuyruğu ve tombstone kayıtları (idempotency) saklanmalı.
• Sequence ve idempotency: Her mesajda monoton artan bir seqNo ve/veya cihaz tarafı UUID içermek; gateway, duplicate'ları çıkarmak için kısa süreli ID tablosu tutar.
• Zaman damgası: Cihazların ts alanını gönder, ancak gateway kendi alım zamanını da saklasın (recvTs). Bu, sonradan uyuşmazlık tespiti için gerekli.

Adım 2: Mesajlaşma modeli ve güvenlik

Heterojen kaynaklar için ağ ve güvenlik tasarımı kritik:

• Yerel broker (MQTT ya da AMQP) gateway ile merkezi bileşen arasında tampon görevi görür; yüksek hacim için Kafka veya RabbitMQ tercih edin.
• Transport security: TLS, client certificate veya token bazlı kimlik doğrulama. Fabrika ağını VLAN/SDN ile segmentle ve gatewayleri DMZ benzeri bir bölgede konumlandır.
• QoS: MQTT QoS 1 veya 2 seçeneği ile en az bir teslimat sağlanır; kritik mesajlar için ek uygulama katmanı onayı kullanın.

Adım 3: ASP.NET Core tabanlı ingest API tasarımı

Merkezi ingest katmanı için ASP.NET Core ideal bir platformdur. Önerilen mimari unsurlar:

• Bulk endpoint: POST /api/v1/telemetry/bulk – JSON array olarak gelen paketleri validate et, parse et ve asenkron işlem kuyruğuna al.
• Hafif doğrulama: schema validation (JSON Schema veya FluentValidation) ile temel alanların varlığını kontrol et; ağır dönüşümler arkaplana atılmalı.
• Idempotency: Her mesaj için messageId veya deviceId+seq kombinasyonunu kontrol eden bir idempotency tablosu (SQL Server) kullan. Kayıt ömrünü (TTL) ihtiyaca göre temizle.
• Asenkron işleme: Web API hızlı cevap döndükten sonra arkaplanda worker (Hangfire, BackgroundService veya bir message queue consumer) ile normalize ve SQL Server yükünü dengele. Yüksek hacim için batch işlemler (SqlBulkCopy veya TVP + stored procedure) kullanın.

Adım 4: Veri modeli ve SQL Server depolama

Veri tabanı tasarımı performans ve sorgulanabilirlik için önemli:

• Canonical telemetry table: columns = (id PK, deviceId, sensorId, sourceTs, recvTs, seqNo, numericValue, stringValue, unit, rawPayloadHash, processedFlag).
• Partitioning: tarih veya cihaz kümesine göre partition kullan, büyük hacimlerde performansı korur.
• Index stratejisi: deviceId+sourceTs ve processedFlag üzerine uygun indexler; idempotency için unique constraint( deviceId, seqNo ).
• Batch writes: Her dakika veya belirli kayıt sayısına ulaşıldığında toplu insert yap; transaction boyutunu sınırlı tut.

Adım 5: Zaman senkronizasyonu, sıralama ve geç gecikmeler

Zaman uyumsuzluğu üretim verilerinin anlamını bozar. Uygulanabilir öneriler:

• NTP veya PTP ile cihazların saatlerini senkronize etmeye çalış; lojistik açıdan mümkün değilse, cihaz zamanını sourceTs olarak tut ama sunucu tarafından ek recvTs sakla.
• Watermark ve tolerans penceresi: Gerçek zamanlı akışta, olayları işleme sırasında birkaç saniye/dakika pencere tanımla; belirli bir süreden sonra gelen olaylar late-arrival olarak işaretlensin ve ayrı akıştan reconcile edilsin.
• Reordering: SeqNo tabanlı reordering uygulayabilir veya event time processing (örn. stream processor) ile watermark mantığı kullan.

Adım 6: ERP ile entegrasyon stratejileri

ERP tarafına hatasız ve tekrar eden kayıt göndermemek için aşağıdaki yaklaşımları öneririz:

• Canon model mapping: Makine verilerini önce bir canonical iş modeliyle eşleştir (örn. operasyonId, jobId, quantity, timestamp). ERP'ye gönderilen payload bu model üzerinden türetilsin.
• Queue-based sink: ERP'ye doğrudan HTTP post yerine middleware queue (RabbitMQ, Service Bus) ile gönder, retry ve poison message handling ekle.
• Idempotent API çağrıları: ERP'ye gönderirken idempotency-key kullan; ERP tarafı desteklemiyorsa, middleware katmanda durum tablosu tut ve göndermeyi bu tabloda işaretle.
• Reconciliation: Periyodik günlük veya saatlik reconciliation işlevi kur; ERP kayıtları ile sensör/machine kayıtlarını karşılaştır ve farkları raporla.

Veri kalitesi, normalizasyon ve meta-veri yönetimi

Heterojen veriyi anlamlı hale getirmek için:

• Units registry: Ölçü birimlerini normalize eden bir tablo; gelen 'mm', 'cm' gibi birimleri canonical (SI) birime çevir.
• Tag mapping: Her üretici/sürüme özel sensorId dönüşümü için mapping tablosu; versiyonlama ile değişiklikleri izleyin.
• Validation rules: Beklenen aralıklar ve anormallikler için threshold tablosu; threshold aşımları alarmla bildirilir.

Operasyonel izleme ve hata giderme

Sistem sağlık göstergeleri ve hata çözümü için öneriler:

• Metrikler: API latency, queue length, batch insert süreleri, idempotency collision rate gibi metrikleri Prometheus/Grafana ile izleyin.
• Distributed tracing: Bir mesajın cihaztan ERP'ye kadar geçen yolunu izlemek için OpenTelemetry kullanın; örneğin trace id her mesaja eklenir.
• Alerting: Veri akışında uzun süreli duraklama, yüksek duplicate oranı veya reconciliation farkı için otomatik alarm kurun.

Örnek veri akış şeması (adım adım)

1. Makine sensörü -> protocol adapter (gateway) -> local queue (SQLite).
2. Gateway -> MQTT/AMQP broker -> merkezi ASP.NET Core ingest API (POST /api/v1/telemetry/bulk).
3. Ingest API kısa doğrulama yapar, messageId/idempotency kontrolü, ardından mesajları processing queue'ya iter.
4. Background worker batch halinde SQL Server'a yazar (SqlBulkCopy veya TVP + stored procedure).
5. Normalization ve business mapping sonrası middleware queue üzerinden ERP sync işlemi başlar; idempotency key ile gönderim yapılır.
6. Reconciliation job'ları periyodik olarak veri ve ERP kayıtlarını karşılaştırır; sapmalar dashboard'larda gösterilir.

Önerilen teknolojiler ve roller

• Edge protocol adapters: OPC UA SDK, pymodbus veya vendor SDK'ları.
• Broker: Mosquitto (küçük), RabbitMQ/Kafka (yüksek hacim).
• Ingest API: ASP.NET Core 6/7, BackgroundService, Serilog.
• DB: SQL Server (partitioning, TVP/stored proc, SqlBulkCopy).
• Observability: Prometheus, Grafana, OpenTelemetry.

Sonuç ve bir sonraki adım

Heterojen makine parkından güvenilir veri toplamak ve ERP ile tutarlı şekilde entegre etmek, doğru katmanlandırma, idempotency, zaman ve metrik yönetimiyle mümkündür. Önemli olan küçük, doğrulanabilir adımlarla ilerlemek; önce uçtaki güvenilirliğe, sonra merkezi ingest ve son olarak ERP sink stabilitesine odaklanmaktır. Uygulama detayları ve pilot planı için iletişim sayfamız üzerinden bize ulaşabilirsiniz — teknik gereksinimlerinizi inceleyip uygulanabilir bir PoC yol haritası önerebiliriz.

Not: Bu yazı, saha sorunlarına doğrudan uygulanabilir teknik çözümler sunmayı amaçlamaktadır; teknik tercihlerinizi hacim, mevcut altyapı ve kritiklik seviyesine göre uyarlayın.