Yüksek hızlı endüstriyel olay işlemede Actor Model

IIoT'de Actor Model ile dayanıklı eşzamanlı sistemler

Endüstriyel yazılım geliştiren ekipler, er ya da geç aynı mimari duvara çarpar. Fabrikadan saniyede binlerce kez akan veri, sıradan bir IT uygulamasının işlem verisi gibi ele alınır.

Tipik senaryo şöyledir: Bir REST API arka ucu PostgreSQL ya da Microsoft SQL Server gibi klasik bir ilişkisel veritabanına bağlanır ve PLC'ler doğrudan veritabanı tablolarına eşlenir. Sensör sayısının az olduğu, tek noktadaki pilot projelerde bu yaklaşım çoğu zaman yeterlidir.

Sorunlar, tam ölçekli üretime geçildiğinde başlar. Hızlı bir paketleme hattı, tek başına saniyede on binlerce durum değişikliği üretebilir. Sistem bu olayların hepsini aynı anda bir SQL veritabanına yazmaya kalktığında tablo kilitleri, tükenen iş parçacığı havuzları ve ani gecikme artışları ortaya çıkar. Panolar geç güncellenir, kurallar geç çalışır. Klasik IT mimarileri, saha verisinin gerektirdiği eşzamanlılık ve hız karşısında çoğu zaman zorlanır.

Birden fazla tesise yayılan, düşük gecikmeli bir IIoT platformu kurmak istiyorsanız, durumu ve eşzamanlılığı nasıl ele aldığınızı baştan düşünmeniz gerekir. Actor Model tam da burada devreye girer.

• Mikrosaniye düzeyi: Aynı süreç içinde actor'lar arası mesaj iletimi (tek düğüm, ağ trafiği yok)
• Yüksek eşzamanlılık: Bir düğümde aynı anda çalışan çok sayıda actor (donanıma bağlı)
• Yüksek erişilebilirlik: Denetim ağacıyla hatadan otomatik toparlanma imkânı (kurulum yapısına bağlı)

Önemli: Gecikme değerleri, mesajların aynı makinede ve aynı süreç içinde iletildiği varsayımına dayanır. Ağ üzerinden haberleşen uzak actor'larda buna serileştirme ve ağ aktarımı süresi eklenir. Sonuçlar büyük ölçüde iş yüküne, donanım kapasitesine ve kurulum yapısına bağlıdır.

İş parçacıkları fabrika ölçeğinde neden zorlanır?

Actor Model'in neden işe yaradığını anlamak için önce paylaşılan duruma dayanan klasik nesne yönelimli mimarilerin endüstriyel ölçekte nerede tıkandığına bakmak gerekir.

Sıradan bir C# ya da Java uygulamasına 5.000 sensör aynı anda veri gönderdiğinde çalışma ortamı 5.000 ayrı işletim sistemi iş parçacığı açmaz. Bunun yerine iş parçacığı havuzlarını, asenkron G/Ç'yi ve iç kuyrukları kullanır. Ancak endüstriyel ekipmandan gelen yoğun ve kesintisiz yük altında kuyruklar yine de büyür, kilitler için bekleme başlar ve gecikmeler sıçrar.

İki sensör olayı aynı makinenin durumunu aynı anda güncellemeye çalışırsa "yarış durumu" (race condition) oluşur ve makinenin durumu tutarsız hesaplanabilir. Mühendisler bunu önlemek için kilit kullanır.

Kilitler için bekleme, işlem kapasitesini sınırlar. A iş parçacığı bir makinenin durumunu güncellerken B, C ve D sıralarını bekler. Veri hacmi arttıkça bu bekleme katlanarak büyür. Sonunda sunucu, işlemci zamanının önemli bir kısmını asıl operasyon verisini işlemeye değil, iş parçacıklarını birbirine uydurmaya harcar.

Actor Model'de her birim kendi işini yapar

Actor Model, 1973'te ortaya konmuş, eşzamanlı hesaplamaya dair matematiksel bir modeldir. Erlang tabanlı telekomünikasyon altyapısı gibi son derece güvenilir dağıtık sistemlerin temelinde bu model yatar.

Modelde hesaplamanın temel birimi "actor"dür. Actor, dış dünyadan yalıtılmış, çok küçük bir çalışma birimidir. Kendine ait bir durumu, kendine özgü bir davranışı ve yalnızca kendisinin okuduğu bir "posta kutusu" vardır.

Model üç temel ilkeye dayanır:

1. Paylaşılan durum yoktur: Actor'lar belleği paylaşmaz. Yalıtılmış birimler aynı değişkeni değiştirmek için birbiriyle yarışmadığından, uygulama düzeyinde kilide pek ihtiyaç kalmaz.
2. Haberleşme asenkron mesajlarla olur: Actor'lar birbirleriyle yalnızca posta kutularına "gönder ve unut" (fire-and-forget) mesajları bırakarak konuşur.
3. Mesajlar sırayla işlenir: Bir actor posta kutusundaki mesajları her zaman tek tek okur. Mesajı işler, kendi durumunu günceller ve bir sonrakine geçer.

Bu yaklaşım sahada nasıl çalışır?

1.000 motorun bulunduğu bir fabrika düşünün. Unified Namespace yaklaşımıyla kurgulanmış bir mimaride sistem, bellekte 1.000 bağımsız "cihaz actor'ü" oluşturur.

• Her cihaz actor'ü bellekte kendi başına, yalıtılmış bir süreç olarak çalışır.
• Her biri, sahadaki tek bir motorun dijital ikizidir.
• Motor bir saniye içinde 50 titreşim uyarısı ürettiğinde bu mesajların hepsi doğrudan o motorun actor'ünün posta kutusuna düşer.
• Actor mesajları tek tek, sırayla işler, ilgili endüstriyel kural motoru mantığını çalıştırır, durumunu günceller ve sonucu dışarı verir. Aynı süreç içinde mesaj işleme mikrosaniyelerle ölçülür; uçtan uca gecikmeyi ise ağ ve depolama belirler.

Actor'lar belleği paylaşmadığı için çalışma ortamı bu actor'ları mevcut bütün işlemci çekirdeklerine paralel olarak, neredeyse hiç beklemeden dağıtabilir.

Dağıtık motorun temel taşları

Actor tabanlı dayanıklı bir sistem kurmak, dağıtık sistem tasarımında özen ister. Geniş bir alana yayılmış OT ağlarında düşük gecikmeli telemetri elde etmek için modern IIoT mimarileri çoğunlukla Actor Model'in yüksek performanslı ve farklı platformlarda çalışabilen uygulamalarından yararlanır.

Hız bellekte, kalıcılık veritabanında

Fabrikanın anlık durumu yalıtılmış actor'larda, bellekte tutulduğunda OEE gibi metrikler her değişiklikte veritabanına gidip gelmeden, olaylar geldikçe güncellenebilir. Geçmiş veri ihtiyacı için actor'lar veriyi arka planda, asenkron olarak ClickHouse gibi zaman serisi veritabanlarına yazar. Böylece veritabanına yazma süresi canlı veri akışını hiçbir zaman bekletmez. Proxus'ta bu depo, merkez sunucudaki sütun tabanlı geçmiş veri deposudur.

Denetim ağaçlarıyla hataya dayanıklılık

Endüstriyel ağlar zorlu ortamlardır. Sensörlerin enerjisi kesilir, Edge Gateway'lerin bağlantısı kopar, ağ anahtarları arızalanır.

Actor sistemlerinde bileşenler, denetim ağacı (Supervision Tree) denen bir hiyerarşi içinde dizilir. Siemens PLC ile TCP bağlantısını ayakta tutan bir protokol actor'ü ani bir ağ zaman aşımı yüzünden çökerse, onun "üst actor"ü hatayı fark eder, yalnızca o actor'ü yeniden başlatır ve veri toplama kaldığı yerden devam eder. Bu yaklaşım hatayı olduğu yerde sınırlar ve tek bir arızanın bütün sistemi zincirleme olarak çökertmesini önler.

Konumdan bağımsız haberleşme ve yatay ölçekleme

Bazı actor çerçeveleri konumdan bağımsız haberleşme sunar. Bir alarm actor'ü, makine actor'ünün aynı sunucuda mı yoksa başka bir düğümde mi çalıştığını bilmeden ona mesaj gönderebilir; mesajı ağ üzerinden hedefe ulaştırmak çerçevenin işidir. Bu sayede kümeye yeni düğüm ekleyerek ölçeklemek mümkün olur. Bedeli ise küme üyeliğini yönetmek, ağ bölünmelerini ele almak ve uzak düğümlerdeki hatalarla uğraşmaktır.

Pek çok endüstriyel sistem daha sade bir ayrımı tercih eder. Actor'lar her sürecin içinde yerel kalır (her Edge Gateway ya da sunucu için bir süreç). Tesisler ise bağlantı koptuğunda veriyi saklayabilen kalıcı bir mesaj altyapısı üzerinden haberleşir. Böylece her süreç actor'ların eşzamanlılık avantajından yararlanır, WAN tarafını da bu iş için tasarlanmış bir bileşen üstlenir. Bu ayrım, büyük ölçekte çalışan uç bilişim desenleri açısından önemlidir.

İlişkisel veritabanı darboğazından kurtulmak

Yüksek hızlı Endüstri 4.0 verisini zorla klasik ilişkisel veritabanı mimarisinden geçirmek, yoğun yük altında genellikle gecikme artışıyla ve kabaran bulut işlem maliyetleriyle sonuçlanır. Actor tarzı eşzamanlılıktan yararlanan modern IIoT platformları ise çok büyük hacimde endüstriyel olayı işlerken operasyon ekiplerinin ihtiyaç duyduğu düşük gecikmeyi koruyabilir.

Bu yaklaşım ne zaman uygun olmayabilir?

• Seyrek gelen telemetri: Ortam sıcaklığını 15 dakikada bir okuyan bir uygulama, tamamen dağıtık bir actor sisteminin getirdiği mimari karmaşıklığa değmeyebilir.
• Tek hatlık kurulumlar: Küçük ve tek başına çalışan tesisler, daha basit ve tek parça (monolitik) mimarilerle hedeflerine daha hızlı ulaşabilir.
• Güvenlik açısından kritik kontrol: Katı gerçek zamanlı ve güvenlik açısından kritik kapalı çevrim kontrol her zaman PLC ya da Safety PLC katmanında kalmalıdır.

Performans değerleri ve sonuçlar her zaman iş yüküne, fiziksel donanıma ve ağ yapısına göre değişir.

Sık sorulan sorular

Actor Model en basit hâliyle nedir?

Her "actor", kendi verisi ve posta kutusu olan bağımsız, hafif bir hesaplama birimidir. Actor'lar birbirleriyle yalnızca asenkron mesajlarla konuştuğu için paylaşılan belleğe erişim en aza iner. Bu da kilitlenme (deadlock) ve yarış durumu gibi yaygın iş parçacığı sorunlarını büyük ölçüde azaltır. Yine de mühendislerin mesaj sırasını, geri basıncı ve denetim yapısını dikkatle tasarlaması gerekir.

Actor Model diğer yaklaşımlardan nasıl ayrılır?

Kaynaklar

1. Carl Hewitt, Peter Bishop ve Richard Steiger, "A Universal Modular ACTOR Formalism for Artificial Intelligence" (1973) - Actor hesaplama modelini ilk kez tanımlayan ve ACM Digital Library'de dizinlenen temel makale.
2. Microsoft Orleans Documentation - .NET'te sanal actor deseni ve dağıtık sistemlerin ölçeklenmesi üzerine resmi genel bakış.
3. Erlang/OTP Concurrent Programming Guide - Erlang'ın endüstriyel düzeyde kanıtlanmış, actor tarzı eşzamanlılık uygulamasının resmi başvuru kaynağı.