ISA-95 ile MES–ERP Entegrasyonu: Seviye 3 ve 4 Arasındaki Veri Akışları

Aynı iş emri ERP’de “açık”, MES’te “tamamlandı” görünüyor; depo sayımı tutmuyor; iki ekip de sorunun karşı tarafta olduğunu söylüyor. MES–ERP bağlantısı kötü kurulduğunda tablo budur. Bu bağlantı üretim planını sahaya indirir, sahada olanı stok, maliyet ve sevkiyat sistemlerine geri taşır. Aşağıda ISA-95 (IEC 62264) çerçevesinde seviye 3 ile 4 arasındaki veri nesnelerini, sorumluluk sınırını, entegrasyon yöntemlerini ve sahada çift stok kaydına yol açan hata yönetimi eksiklerini ele alıyoruz.

ISA-95 fonksiyon hiyerarşisi ve seviye 3–4 sınırı

ISA-95 fonksiyon hiyerarşisinde seviye 4 iş planlama ve lojistiktir: üretim planı, malzeme ihtiyaç planlaması, satın alma, stok değerlemesi, maliyet. Zaman ölçeği günler, haftalar, aylardır. Seviye 3 üretim operasyonlarının yönetimidir: iş emirlerinin hatlara dağıtılması, detaylı çizelgeleme, malzeme takibi, kalite kaydı, üretim performansı. Zaman ölçeği vardiya, saat ve dakikadır. Seviye 2 ve altı kontrol sistemleridir.

Entegrasyonun asıl sorusu “bu bilgi kimin?” sorusudur. ISA-95’in sahadaki faydası, her bilginin hangi seviyede üretilip hangi seviyede tüketildiğini netleştirmesidir. Yaygın ayrım:

Bilgi	Sahibi (kaynak)	Tüketen
Malzeme ana verisi, ürün ağacı	ERP (seviye 4)	MES
Rota / operasyonlar, standart süreler	ERP veya PLM	MES
İş emri ve miktar	ERP	MES
Detaylı sıralama, makine ataması	MES (seviye 3)	Saha, operatör
Gerçekleşen üretim, tüketim, hurda	MES	ERP
Lot / seri izlenebilirlik detayı	MES	ERP (özet), kalite

Tablo tesisten tesise değişebilir. Değişmemesi gereken şey, kararın yazılı verilmesi ve her bilgi için tek kaynak tanımlanmasıdır. İki sistemin aynı alanı değiştirebildiği her yer, birkaç ay sonra bir uyumsuzluk kaydı olarak geri döner. Standardın çerçevesi için ISA’nın ISA-95 sayfası başlangıç noktasıdır.

Seviyeler arası temel veri nesneleri

ISA-95 Bölüm 2, seviye 3 ile 4 arasında değiş tokuş edilen bilgiyi nesne modelleriyle tanımlar. Projelerde en sık kullanılanlar:

• Ürün tanımı (product definition): Ürünün nasıl üretileceği; ürün ağacı, operasyonlar, gerekli kaynaklar.
• Üretim çizelgesi (production schedule / operations schedule): ERP’den gelen, ne kadar ve ne zamana kadar üretileceğini söyleyen talepler; pratikte iş emirleri.
• Üretim performansı (production performance / operations performance): Gerçekleşen üretim, tüketilen malzeme, oluşan hurda, harcanan süre.
• Malzeme, personel ve ekipman bilgisi: Lot, stok yeri, yetkinlik, kapasite.
• Üretim kapasitesi (production capability): Hangi kaynağın ne zaman kullanılabilir olduğu.

Proses endüstrilerinde reçete (formül) ayrıca ele alınır. Genel reçete ERP veya PLM’de, sahaya özgü kontrol reçetesi seviye 2–3’te yaşar. ERP’nin PLC parametrelerini doğrudan yönetmesini beklemeyin; bu sınır aşıldığında bir ERP güncellemesi sahada makine ayarını değiştirebilir hale gelir.

Entegrasyon yöntemleri: B2MML, API ve ara tablo

Seviye 3–4 arasında veri taşımanın üç yaygın yolu vardır. Çoğu projede birden fazlası bir arada kullanılır.

Yöntem	Güçlü yanı	Sınırlaması
B2MML (XML mesaj)	ISA-95 nesneleriyle birebir, alan tanımı hazır	Şema geniş; iki tarafın da desteği gerekir
REST / SOAP API	Anlık, doğrulama ve hata dönüşü net	Karşı taraf kapalıyken kuyruk gerekir
Ara tablo (staging)	Basit, izlenebilir, iki tarafı zamansal olarak ayırır	Durum yönetimi ve temizlik disiplini ister
Mesaj kuyruğu / broker	Gevşek bağlılık, yeniden deneme yerleşik	Ek altyapı ve izleme gerektirir

B2MML, MESA’nın yayımladığı ve ISA-95 nesnelerini XML şemalarıyla tanımlayan uygulamadır. Mesajlar fiil ve isimden oluşur; örneğin iş emri listesi aktarılırken Process veya Sync fiiliyle üretim çizelgesi nesnesi, sonuç bildirilirken Acknowledge veya Respond kullanılır. Hazır alan tanımı, iki ekip arasındaki “miktar birimi hangi alanda” tartışmasını baştan keser.

API yaklaşımında ERP ya da MES karşı tarafın web servisini çağırır. Hata dönüşü anlıktır. Ama karşı taraf erişilemezken gönderen tarafta kalıcı bir kuyruk yoksa veri kaybolur. Sahada en sık gördüğümüz eksik budur.

Ara tablo yaklaşımında bir taraf ortak bir veritabanı tablosuna kayıt yazar, diğer taraf okuyup durum alanını günceller. Basittir, hata ayıklaması kolaydır; birçok ERP’nin hazır arayüzü de bu modeldedir. Asgari şema şöyle olabilir (SQL Server sözdizimi; diğer veritabanlarında veri tipleri uyarlanmalıdır):

CREATE TABLE mes_uretim_bildirimi (
  bildirim_id     BIGINT        NOT NULL PRIMARY KEY,
  is_emri_no      VARCHAR(20)   NOT NULL,
  operasyon_no    VARCHAR(10)   NOT NULL,
  malzeme_no      VARCHAR(40)   NOT NULL,
  lot_no          VARCHAR(40)   NULL,
  saglam_miktar   DECIMAL(18,3) NOT NULL,
  hurda_miktar    DECIMAL(18,3) NOT NULL,
  birim           VARCHAR(5)    NOT NULL,
  olusma_zamani   DATETIME2     NOT NULL,  -- UTC
  durum           CHAR(1)       NOT NULL DEFAULT 'N', -- N:yeni P:işleniyor O:tamam H:hata
  hata_mesaji     NVARCHAR(500) NULL,
  deneme_sayisi   INT           NOT NULL DEFAULT 0,
  islenme_zamani  DATETIME2     NULL
);

bildirim_id MES tarafında üretilir ve tekildir; ERP aynı kimlikle ikinci kez gelen kaydı yeni bildirim olarak işlememelidir. Entegrasyonun en önemli kuralı budur. Aşağıda tekrar dönüyoruz.

Örnek iş emri ve üretim bildirimi akışı

1. Serbest bırakma: ERP’de planlama iş emrini serbest bırakır. ERP; iş emri numarası, malzeme, miktar, bitiş tarihi, ürün ağacı ve rota bilgisini MES’e gönderir.
2. Kabul: MES emri doğrular (malzeme ve rota MES’te tanımlı mı, birimler uyumlu mu) ve kabul veya red yanıtı döner. Red gerekçesi ERP’de görünür olmalıdır; görünmezse emir sessizce bekler.
3. Çizelgeleme: MES emri hat ve makinelere atar, sıralar. Bu bilgi genellikle ERP’ye geri gönderilmez; gönderilecekse yalnız planlanan başlangıç ve bitiş zamanı gider.
4. Üretim ve tüketim: Sahada üretim başladığında MES gerçekleşen miktarları, tüketilen malzeme lotlarını ve hurdayı kaydeder.
5. Bildirim: Belirlenen sıklıkta (lot, palet, vardiya veya operasyon sonu) MES üretim ve tüketim bildirimini ERP’ye iletir. ERP stok girişi ve malzeme çıkışı belgelerini oluşturur.
6. Kapanış: Operasyon veya iş emri tamamlandığında MES kapanış bildirimi gönderir; ERP teknik kapanışı ve maliyet hesabını yapar.

Aynı akışı OEE ve duruş verileriyle zenginleştirmek için gereken sinyaller OEE hesaplaması için doğru veri kaynakları yazısında anlatılıyor.

Ana veri sahipliği ve senkronizasyon

Entegrasyon sorunlarının çoğu işlem verisinden değil, ana veriden çıkar. Malzeme kodu MES’te yoksa iş emri reddedilir. Birim dönüşümü farklıysa stok yavaş yavaş kayar ve ancak sayımda fark edilir. Kurallar:

• Malzeme, ürün ağacı ve rota değişiklikleri ERP’den MES’e olay bazlı ya da en azından günlük aktarılır.
• Ürün ağacı ve rota iş emrine sürüm olarak bağlanır. Emir açıldıktan sonra yapılan ana veri değişikliği açık emri sessizce değiştirmemelidir.
• Birimler ve dönüşüm katsayıları tek yerde tanımlanır; MES’te ayrı birim tablosu varsa senkronizasyonu izlenir.
• MES’e özgü veriler (makine parametreleri, operatör yetkinlikleri, kontrol planı detayları) MES’te kalır, ERP’ye taşınmaz.

Saha sinyallerinin ve MES nesnelerinin ortak bir isim uzayında yayımlandığı mimarilerde ISA-95 ekipman hiyerarşisi topic yapısına da yansır; bu tasarım Unified Namespace (UNS) mimarisi yazısında ele alınıyor.

Hata yönetimi ve tekrar deneme

Entegrasyon hatası olacak. Mesele hatanın kaybolmaması ve tekrar denemenin veri çoğaltmamasıdır. Sahada çift stok girişinin tipik nedeni, zaman aşımından sonra körlemesine yapılan tekrar denemedir.

• Tekillik (idempotency): Her mesajın gönderen tarafta üretilmiş tekil bir kimliği olmalı; alıcı bu kimliği daha önce işlediyse sonucu tekrar döndürmeli, yeni belge oluşturmamalıdır. Aksi halde zaman aşımından sonraki tekrar deneme stokta çift giriş üretir.
• Sıra: Aynı iş emrine ait bildirimler sıralı işlenmelidir. Kapanış bildirimi son üretim bildiriminden önce işlenirse ERP geç gelen üretim bildirimini kapalı emir gerekçesiyle reddedebilir.
• Kalıcı kuyruk: API kullanılıyorsa gönderen taraf mesajı önce kendi veritabanına yazmalı, sonra göndermelidir (outbox deseni). Uygulama yeniden başlasa bile mesaj kaybolmaz.
• Kalıcı hata ile geçici hatanın ayrılması: Ağ veya zaman aşımı hataları otomatik tekrar denenir; “malzeme bulunamadı” gibi iş hataları denenmez, bir kişiye bildirilir. Aynı iş hatasını gece boyu binlerce kez deneyen servis, log diskini doldurur.
• Görünürlük: Hatalı ve bekleyen kayıtlar için bir izleme ekranı ve eşik aşıldığında alarm olmalıdır. Hatalı kaydın düzeltilip yeniden gönderilmesi kayıt altına alınmalıdır.

Tasarım kontrol listesi

• Her bilgi nesnesi için sahip sistem ve tüketen sistem yazılı olarak belirlendi.
• İş emri, ürün ağacı ve rota sürümü birlikte aktarılıyor; açık emirler ana veri değişikliğinden etkilenmiyor.
• Her mesajın tekil kimliği var; alıcı taraf tekrar gelen mesajda yeni belge oluşturmuyor.
• Aynı iş emrine ait mesajlar sıralı işleniyor.
• Geçici ve kalıcı hatalar ayrılmış; kalıcı hatalar bir sorumluya bildiriliyor.
• ERP erişilemezken MES’in kaç saat üretim yapabileceği biliniyor ve test edildi.
• Zaman alanları UTC; miktar birimi her mesajda açıkça taşınıyor.
• Entegrasyon trafiği DMZ üzerinden geçiyor, doğrudan IT–OT oturumu yok.

Listedeki “test edildi” ifadesini ciddiye alın: ERP bağlantısını devreye alma sırasında bilinçli olarak kesin, kuyruğun dolup boşaldığını ve stokta çift kayıt oluşmadığını gözünüzle görün. Bu tasarımın uygulanması ve mevcut sistemlerin bağlanması için SCADA, MES ve ERP bağlantıları hizmetimize, kurumsal ağ ile üretim ağı arasındaki mimarinin bütünü için IT/OT entegrasyon danışmanlığı sayfamıza bakabilirsiniz.

Sık sorulan sorular

B2MML kullanmak zorunlu mu?

Zorunlu değil. B2MML, ISA-95 nesnelerinin XML karşılığıdır ve iki taraf da destekliyorsa alan tanımı tartışmasını azaltır. Birçok projede REST API veya ara tablo kullanılır; bu durumda bile alan adlarını ve nesne sınırlarını ISA-95 terimleriyle tanımlamak, ileride sistem değiştiğinde işi kolaylaştırır.

Ürün ağacı ve rota MES’te de değiştirilebilmeli mi?

Ana veri olarak hayır. Ürün ağacı ve rotanın sahibi genellikle ERP’dir; MES’te kalıcı değişiklik yapmak iki sistemi birbirinden koparır. Üretim sırasındaki sapmalar, örneğin alternatif malzeme kullanımı, MES’te işlem verisi olarak kaydedilir ve tüketim bildirimiyle ERP’ye aktarılır.

Üretim bildirimi ne sıklıkla ERP’ye gönderilmeli?

ERP’nin bu veriyle ne yaptığına bağlı. Stok ve maliyet için vardiya veya iş emri sonu bildirimi yetebilir; malzeme ikmali ve sevkiyat planlaması anlık stoka bakıyorsa daha sık, örneğin palet veya lot bazında bildirim gerekir. Çok sık bildirim ERP tarafında belge ve kilit yükü yaratır.

Entegrasyon hatası olduğunda üretim durmalı mı?

Hayır. MES, ERP’ye ulaşamadığında üretimi sürdürebilmeli ve bildirimleri kuyrukta tutmalıdır. Bunun için kesinti süresine yetecek kadar iş emri ve ana veri önceden MES’e alınmış olmalıdır. Üretimin durması gereken tek durum, iş emri veya reçete verisinin hiç olmadığı ya da tutarsız olduğu durumdur.