OT DataOps nedir? Veri mühendisliğini fabrika sahasına taşımak

OT veri projeleri neden analitiğe varmadan tıkanır?

Üretimde sık görülen bir senaryo var. Bir veri ya da yapay zekâ girişimi başlar, ama kaynaktan gelen veri yalnızca veri noktası adları, değerler, kalite durumları ve zaman damgalarından oluşur. Bu veri, işletmeye dair ortak bir bağlam neredeyse hiç taşımaz.

Veri bilimciler Jupyter not defterlerini açıp fabrikanın data lake'ine bağlanır ve düzgün yapılandırılmış veri setleri bulmayı bekler. Bunun yerine karşılarına şu çıkar:

• Tag ID: 49021. Value: 43. Timestamp: 12:00:01
• Tag ID: DB4.DBX2.1. Value: TRUE. Timestamp: 12:00:02
• Tag ID: VIB_01A. Value: ERR_COMM. Timestamp: 12:00:03

49021 nedir? 43 Celsius mu, Fahrenheit mı? Zaman damgası hangi saat dilimine göre?

Makine verisi kurumsal analiz için değil, kontrol ve arıza teşhisi için optimize edilmiştir. Veri bir panoyu, bir iş akışını, istatistiksel bir modeli ya da bir yapay zekâ uygulamasını beslemeden önce bu eksik tamamlanmalıdır. Veri ekiplerinin ekipmanın kimliğine, birimlere, kaliteye, üretim durumuna ve verinin kökenine ihtiyacı vardır.

OT DataOps'un konusu tam olarak bu tekrar eden hazırlık sorunudur.

• 4 aşama: Otomatikleştirilmiş OT veri hattı

Gözlenen performans iş yükünün niteliğine, düğüm kapasitesine ve kurulum tasarımına bağlıdır.

OT DataOps nedir?

DataOps (veri operasyonları), ilk olarak IT dünyasında doğmuş bir kavramdır. Analitik ekiplerinin daha hızlı çalışabilmesi için verinin akışını, kalitesini ve aktarımını otomatikleştirmeye odaklanır.

OT DataOps (operasyonel teknoloji için DataOps) ise bu ilkeleri endüstriyel kaynaklara ve işletme kısıtlarına uygular. PLC'ler, SCADA sistemleri, sayaçlar ve makineler gibi varlıkları bağlama; bunların verisini doğrulama ve anlamlandırma; kontrollü canlı ve geçmiş veriyi onaylı kullanıcılara aktarma disiplinidir.

OT DataOps ayrı bir Proxus ürün kategorisi değildir. Bir endüstriyel veri platformu içinde uygulanan bir işletme disiplinidir: kaynak sahipliği, modelleme, kalite, aktarım sözleşmeleri, izleme ve değişiklik kontrolü tek bir yaşam döngüsü olarak yönetilir. (Mevcut sistemlerin üzerinde ayrı bir DataOps katmanı olarak satılan ürünler, örneğin HighByte, bu yaklaşımla Proxus ve HighByte karşılaştırmasında karşılaştırılıyor.)

OT DataOps hattının 4 aşaması

Proxus gibi bir endüstriyel veri platformuna dayanan olgun bir OT DataOps stratejisi, veri mühendisliğinin dört kritik aşamasını otomatikleştirir:

Veri toplama (bağlantı)

Bağlanamadığınız veriyi analiz edemezsiniz. Bir fabrikada yeni bir kontrolörün hemen yanında onlarca yıllık bir seri haberleşme cihazı bulunabilir. OT DataOps, gereken protokollere, sorgulama davranışına, veri noktası hacmine, ağ bölgelerine ve kaynak sistemlerin sınırlarına göre seçilmiş bir uçta veri toplama katmanıyla başlar. Bağlantı kabiliyeti, gerçek ürün sürümüne ve sürücü listesine göre doğrulanmalıdır.

Normalleştirme ve anlamlandırma

En kritik adım budur. Ham veri, fabrikadan çıkmadan önce insanın okuyabileceği bilgiye dönüştürülmelidir. Bir OT DataOps motoru DB4.DBX2.1 = 120 göndermek yerine veri içeriğini şöyle dönüştürür:

{
 "asset": "Extruder_A",
 "location": "Plant_Berlin",
 "metric": "Temperature",
 "value": 120,
 "unit": "Celsius",
 "status": "Warning"
}

Bu veri buluta ulaştığında veri bilimci neye baktığını hemen ve tam olarak bilir.

Akıllı filtreleme ve ölü bant

Bulut sağlayıcıları (AWS ya da Azure gibi) yüklediğiniz (ingress) ve sakladığınız her gigabayt için ücret alır. Bir sıcaklık sensörü her 10 milisaniyede tamamen aynı değeri (22.1°C) gönderiyorsa, bu mükerrer kayıtların hepsini buluta göndermek büyük bir para israfıdır. OT DataOps, ölü bant (yalnızca değer belirli bir yüzde kadar değiştiğinde veri göndermek) ya da zamana göre toplulaştırma (60.000 ham milisaniye verisi yerine 1 dakikalık ortalama göndermek) gibi akıllı filtreleme tekniklerinden yararlanır. Proxus'ta Edge Gateway değerleri kaynakta ölçekler, dönüştürür ve filtreler; ortalamalar ve diğer özetler ise sonraki aşamada, geçmiş veri deposunda ya da veriyi kullanan sistemde hesaplanır.

Unified Namespace (UNS) üzerinden aktarım

Son olarak temiz ve yapılandırılmış veri, içinde arama yapılamayan tek parça bir veritabanına yığılmaz. Merkezi bir Unified Namespace (UNS) içine yayınlanır. UNS, yetkili kullanıcıların yeniden kullanabileceği kurallara bağlı bir işletme modeli sunar. ERP, MES, iş zekâsı araçları, iş akışları, panolar ve onaylı Model Context Protocol (MCP) istemcileri farklı veri sözleşmeleri kullanabilir. Yine de UNS kaynak sahipliği, yetkilendirme, veri kökeni ya da mutabakat gereksinimlerini ortadan kaldırmaz. Proxus'un veri aktardığı veritabanları, mesaj sunucuları, bulut hizmetleri ve API'ler entegrasyonlar sayfasında listeleniyor.

Değerlendirilmesi gereken işletme sonuçları

• Daha az tekrar eden hazırlık: Ortak kimlik, birim, kalite ve durum modelleri, kurallara bağlanıp güncel tutulduklarında mükerrer eşleme işini azaltır.
• Kontrol altındaki veri hacmi: Ölü bant, toplulaştırma ve olay seçimi aktarılan veriyi azaltabilir; ama sonuç sinyalin dinamiğine ve saklama gereksinimlerine göre ölçülmelidir.
• Yeniden kullanılabilir aktarım sözleşmeleri: Yetkili kullanıcılar, her kontrol kaynağına yeniden doğrudan bağlanmadan anlamlandırılmış veriyi tekrar kullanabilir.

Sonuç

Modern ve veriye dayalı bir işletmeyi düzensiz PLC veri noktalarının üzerine kurmak son derece verimsizdir.

OT DataOps, birden fazla işletme uygulamasının tutarlı ve kurallara bağlı veriye ihtiyaç duyduğu ve kaynak kaynak yapılan hazırlığın sürdürülmesinin zorlaştığı durumlarda işe yarar. Bazı işlemler uçta yapılmalıdır; ortak kurallar ve sahiplik, geçmiş verinin saklanması ve veri aktarımı ise uç ve merkez katmanlara yayılabilir. Ürünün sınırlarını eksiksiz değerlendirmek için Proxus endüstriyel veri platformu ile başlayın ve onaylı dışa veri akışlarını IT/OT köprüsü üzerinden planlayın.

Bu yaklaşım ne zaman uygun olmayabilir?

• Düşük frekanslı telemetri, dağıtık bir mimarinin tüm karmaşıklığına değmeyebilir.
• Tek hatlı küçük tesisler önce daha sade mimarileri tercih edebilir.
• Katı eski sistem kısıtları aşamalı bir geçiş gerektirebilir.
• Emniyet açısından kritik kapalı çevrim kontrol, PLC ve emniyet PLC'si katmanlarında kalmalıdır.

Sonuçlar iş yükü profiline, donanım kapasitesine ve kurulum yapısına bağlıdır.

Sık sorulan sorular

OT DataOps'un IT DataOps'tan farkı nedir?

IT DataOps, yazılımların ürettiği veri hatlarını (veritabanları, API'ler, günlükler) iyileştirir. OT DataOps ise fiziksel sensörlerin ve PLC'lerin ürettiği makine verisiyle uğraşır; kapalı protokoller, gerçek zamanlı kısıtlar ve ağ kesintilerinin sık yaşandığı ortamlar onun konusudur. Örneğin depola ve ilet kalıbı, IT'de karşılığı olmayan, OT'ye özgü bir dayanıklılık mekanizmasıdır.

OT verisinin ne kadarı saklanmalı ya da aktarılmalı?

Her duruma uyan bir yüzde yoktur. Karar, prosesin dinamiğine, inceleme ihtiyaçlarına, alarm ve olay gereksinimlerine, örnekleme davranışına, yasal saklama sürelerine ve ayrıntı kaybının maliyetine bağlıdır. Akıllı filtreleme kurallarını geniş çapta uygulamadan önce prosesi temsil eden sinyallerle doğrulayın.

Ayrı bir OT DataOps ekibine ihtiyacım var mı?

Şart değil. Çoğu kuruluşta mevcut otomasyon ve kontrol ekibi, IT'deki veri mühendisleriyle birlikte çalışır. Önemli olan ortak bir veri ağacı tasarımı (UNS) ve sahadan buluta uzanan veri hattının sorumluluğunun net olmasıdır.

Kaynaklar

1. DataOps Manifesto: Çevik veri mühendisliği için topluluk tarafından oluşturulan ilkeler; OT DataOps bunları endüstriyel ortamlara uyarlar. dataopsmanifesto.org
2. ISA-95 / IEC 62264: OT DataOps hattına yapısını veren, kurumsal sistemlerle kontrol sistemleri arasındaki veri modelini tanımlayan standart.
3. Eclipse Sparkplug: MQTT tabanlı OT verisinin normalleştirilmesi için veri içeriği standardı. sparkplug.eclipse.org