/MES

MES / ERP hakkında

Protokoller ve standartlar:

Endüstriyel:

  • B2MML.Net nerelerde kullanılmalı? MESA repo'sunda tartışma açtım, bekliyorum. Bence uygulamanın ilgili class'ları tarafından kalıtılabilir.
  • M2M iletişimde mevcut UDP tabanlı iletişim sistemi yerine endüstri standartları mı kullanılmalı yoksa genel kavramlar mı? Genel kullanılırsa MQTT uygun. Başlangıç için ve ücretsiz olduğu için makul.
  • Endüstriyel standartlar denenecekse OMG standardı DDS uygulanabilir. Bu konuda Rx4DDS.Net adında bir kütüphane var. RTI ücretli ancak açık kaynaklar için farklı işlem görülebiliyor.
  • DDS yerine SOA mimarili OPC UA da kullanılabilir. Son hali pub-sub'ı da destekliyormuş. Ayrıca ikisi birlikte de kullanılabilir. (Legacy ve .NET Standard için iki ayrı repo var.)
  • OPC UA/DDS Gateway standardı yayımlandı, geçişlilik standart biçimde mümkün
  • Farklı katmanlarda farklı sistemler uygulanabilir (IIRA: machine, unit, site, inter-site vs.). Bu durumda en üst katmanda SOA bir yapı kurulabilir. SOA içinde okunurluk için JSON, performans için protobuf, ZeroFormatter gibi seçenekler de düşünülebilir.
  • Diğer yazılımlarla entegrasyonda, mesajlaşma formatı EDI'dan bahsetmişti. Edifabric ile pek çok standarda göre yazmak mümkün. AS4 gibi bir web servis ayağı da var. Nerelerde kullanılıyor? Gerekirse benzer bir modül ile EDI dokümanlarını .Net objesine ya da JSON'a çevirme işi yapılabilir.
  • Yukarıda saydığım standartlar, diğer uygulamalarla iletişim sağlamak üzere çeşitli adapter'lar ile gerçeklenmeli. Uygulama kendi içinde test edilip en uygun bulunan yollarla iletişimini sağlamalı.
  • KPI-ML diye bir başka MESA standardı var. Otomasyon sistemleri için KPI'ları içeren ISO 22400 standardını gerçekleyen bir XSD şeması. Bunu uygulama için bir benchmark olarak kullanmak mümkün. Yani planlanan ve gerçekleşen arasında bir köprü olarak KPI'ları kontrol mekanizmasının merkezine almak makul olabilir. Bunun da kütüphanesi var.
  • AB destekli BEinCPPS Open Platform kullanılabilir.

Genel:

  • Netmap, FreeBSD için yazılmış, windows portu olan bir servis. Kernel için servis şeklinde yazılmış ancak sonradan port edildiği için doğrudan kullanımı zor. Ağ üzerinde hızlı ve büyük verilerin alışverişi için (örnek) işletim sistemini bypass edip doğrudan ethernet kartı üzerinden işlem yapmayı sağlıyor. C# için interop ile bir wrapper yapılıp dahil edilebilir.
  • Message queue veya bus kullanılabilir yerlerde RabbitMQ (MassTransit ile) ve/veya Kafka (Logstash ile) kullanılabilir mi?
  • OpenStack ya da ServiceFabric gibi bir altyapı sistemi temize çekebilir.
  • Mimari tasarım nasıl olmalı? Örnek 1
  • UI için kullanılan feature toggling sistemin geneli için düşünülebilir. Her müşteri farklı versiyonun farklı modüllerden oluşan bir paketini kullanacaktır.
  • On-premise kurulumlarda yazılımı sanal makineler üzerinde kuracak infrastructure as a code yapısı düşünülebilir (Docker?).

Güvenlik:

  • DDS Security: DDS güvenliği ile ilgili standart var. PKI uygulanıyor.
  • Uygulama güvenliğine yönelik mimarinin ve kodların kontrolünü elden geçirebiliriz.

Veri Analizi:

  • Akan tüm verileri alıp Timescale DB'ye aktaran bir servis yazmak analiz için kullanılacak veriyi sağlayabilir. Event Bus'tan da akış sağlanabilir.
  • Bir noktada Hadoop'a ihtiyaç duyulabilir. Ama nerede?

Endüstri 4.0 Framework'leri:

  • RAMI 4.0 SOA altyapılı bir sistem öneriyor. Daha açık ve uygulamaya yönelik.
  • IIC ürünü olan IIRA birkaç farklı mimariyi öneriyor. Daha çok sürece yönelik.
  • Her birinin ayrı kullanıcısı olacak ve birlikte çalışılabilirlik meselesi ortaya çıkacaktır.
  • OPC UA'dan DDS bus'ına veri gönderen ve alan bir gateway yazma yahut DDS bus'ından OPC UA uygulamasının pub-sub bus'ına veri gönderme denenebilir.

Dotnet:

  • Bütün sistemi reactive olarak değiştirmek zor ancak yeniden yazım durumunda mümkün.Rx kullanımı tüm sistemi Event Driven tasarlamaya sevk ediyor. Ancak B2MML tarafından tanımlanan pek çok şey de zaten event merkezli hazırlanmış. daha kolay olabilir.
  • Rx kullanıldığı için veri yapılarında DynamicData kütüphanesi kullanılması gerekebilir.
  • SOA kısmında Quartz.Net, Hangfire ya da FluentScheduler gibi bir görev zamanlayıcı, Polly veritabanı akış kontrolü, Config.Net gibi bir konfigürasyon kontrolü, Wexflow gibi bir workflow , vs kullanılabilir.

İçerik

  • ITIL ve IT4IT gibi çözümler endüstriyel sorunlara da çözümleri içeriyor olabilir. ITIL pratiklerinin büyük bir kısmını gerçekleyen projeler (1, 2) denenebilir. İlgili metinlerle uygulamayı kıyaslayıp spesifik problemlere önerilen çözümlerin uygulanma biçimlerini görmek faydalı olabilir.
  • ITIL, tüm IT servislerini kapsıyor. Uygulamalar bazen sadece help desk ticketing alanını kapsayabiliyor. Ticari örnekleri incelemek gerekebilir: ServiceNow, BMC Software vs.

İş Modeli:

  • SaaS + On-premise: Jenerik ihtiyaçlar SaaS, spesifik, metale yakın olanlar on-premise vs.
  • Jobs to be Done: Kullanıcı gerçekte ne istiyor. Ne ifade ettiği değil, niyeti önemli. Çözmeye çalıştığı sorun kendi ifade ettiği gereksinimden daha önemli.
  • Bu konuda sektörden birkaç kişiyle uzun uzun mülakat gerekebilir.
  • Rakiplerle benchmark nasıl yapılabilir?