MTConnect Nedir? CNC Verisinin Ortak Dili

Eylül 2008, Chicago. IMTS fuarının açık alanında yirmi beş üretici, farklı marka takım tezgâhlarını aynı ağa bağladı. Amaç tek bir üreticinin dilini dayatmak değil, makinelerin aynı cümleyi konuşabildiği ortak bir sözlük göstermekti. O gün gösterilen şey bir kablo ya da kart değildi; bir veri modeliydi.^[1]

Aynı sorun bugün hâlâ atölyelerin çoğunda duruyor. Bir FANUC kontrol, bir Heidenhain TNC ve bir Mazak MAZATROL yan yana çalışır; üçü de eksen konumu, program adı ve alarm bilgisi taşır. Ama bu bilgiyi aynı ekranda göstermek istediğinizde, her makine için ayrı bir sürücü, ayrı bir eşleme tablosu ve ayrı bir bakım yükü çıkar. MTConnect tam bu noktada devreye girer: makinelerin içini açmadan, veriyi ortak bir sözlükle dışarı verir.

MTConnect, takım tezgâhlarından süreç bilgisi almak için geliştirilen açık, telifsiz ve salt-okunur bir veri standardıdır. Veriyi XML olarak HTTP üzerinden yayınlar; makineye yazmaz, yalnızca okur. Bu tek cümle, hem gücünü hem de sınırını açıklar.^[1][4]

Bir Bakışta MTConnect

MTConnect ne değildir?

Karışıklık genellikle üç kelimede başlıyor: protokol, standart ve sürücü. MTConnect bir saha veri yolu (fieldbus) değildir; servo sürücülerle saat çevrimi düzeyinde konuşmaz. Bir PLC programlama dili de değildir; makinenin mantığını değiştirmez. FOCAS veya LSV2’nin yerine geçmez; onlar kontrolün iç verisine daha derin ve yazma yetkisiyle erişir, MTConnect ise dışarıya okunabilir bir model sunar.^[4]

Bu ayrımı net tutmak, mimari kararların tamamını belirliyor. Bir uygulama takım telafisi yazacaksa MTConnect yanlış adres. Bir uygulama yalnızca “hangi makine çalışıyor, hangi programda, hangi alarmda?” sorusuna cevap arayacaksa MTConnect doğru katman. Üretici tarafında FANUC MT-LINK i gibi araçlar Ethernet ve OPC UA üzerinden benzer bir izleme işlevi sunar; MTConnect bunların yerine değil, yanında konumlanır. Aynı fabrikada iki ihtiyaç birlikte yaşayabilir: yazma için üretici API’si, izleme için MTConnect.^[8]

Üç belge, tek sözlük: Devices, Streams, Assets

MTConnect’in taşıma katmanı sade; asıl iş anlam modelinde yapılır. Agent üç belge ailesi sunar:^[4]

• Devices: Makinenin bileşen ağacı ve veri öğeleri. Eksenler, iş mili, kontrol, program, alarm koşulları burada tanımlanır. Her veri öğesinin bir kimliği (dataItemId), türü (type), kategorisi (SAMPLE, EVENT, CONDITION) ve birimi vardır.
• Streams: Zaman damgalı örnekler ve olaylar. Konum, devir, ilerleme gibi sürekli değerler; program durumu, alarm gibi olaylar burada akar.
• Assets: Takım, palet, fikstür ve parça gibi varlıklar. Takım ömrü veya palet içeriği gibi bilgiler ayrı belgeler olarak taşınır.

Bir istemci önce /probe ile makinenin modelini öğrenir; sonra /current ile anlık görüntüyü, /sample ile sıralı örnek akışını çeker. Model olmadan gelen sayı anlamsızdır: 12.345 değeri, Xabs adlı bir konum öğesine bağlıysa X ekseni konumudur; başka bir modele bağlıysa sıcaklık da olabilir. Standart belgeleri ve cihaz modeli tarayıcısı kamuya açıktır; bir agent’ın modeli yayına almadan önce bu sözlükle karşılaştırılabilir.^[4][2][3]

<!-- Şematik: /probe içindeki bir veri öğesi -->
<DataItem id="Xabs" type="POSITION" subType="ACTUAL"
          category="SAMPLE" units="MILLIMETER" />

<!-- Şematik: /current içindeki bir örnek -->
<Position dataItemId="Xabs" timestamp="2026-11-14T09:15:22Z">
  12.345
</Position>

Bu yapı, MTConnect’i “her makineye özel sürücü” yaklaşımından ayırır. Sürücü, makinenin dilini bilir; MTConnect ise o dilin karşılığını ortak sözlükte arar. Zor kısım da burada başlar.

İlk dönemeç: Sözlük, kablodan daha zor

HTTP üzerinden XML çekmek kolaydır. Birkaç satır kodla /current yanıtını ayrıştırırsınız. Asıl mesai, hangi veri öğesinin hangi iş anlamına geldiğini çözmekle geçer. Çünkü standart ortak bir sözlük tanımlar; ama her agent ve her üretici aynı adları kullanmak zorunda değildir.

Kendi toplayıcılarımızda gördüğümüz tablo bunu net gösteriyor. Mazak makinelerinden gelen MTConnect yanıtlarında program adı pgm, program satırı ln, takım numarası tid, parça sayacı pc, feed override pfo, rapid override pfr adlarıyla gelebiliyor. Aynı fabrikadaki DMG Mori cihazları program1, toolnumber1, part_count1 gibi numaralı adlar kullanıyor; Memex kaynaklı agent’larda ise cn5, cn4, cnt1 gibi kimlikler görülüyor. Bazı agent’lar standart adı dataItemId yerine name alanında taşıyor.^[7]

Bu yüzden sağlam bir istemci yalnızca kimliğe bakmaz; sırasıyla kimlik, name ve tür eşlemesi dener. Bizim uygulamalarımızda execution/exec, program/pgm, Tool_number/tid, PartCountAct/pc gibi eşleşmeler bu yüzden var. Standart, sözlüğü tanımlar; ama sözlüğün lehçelerini konuşmak istemcinin işidir.

Bir de “çevrimdışı” sinyali var: avail veri öğesi UNAVAILABLE döndüğünde makine kapalı veya ağdan kopuk kabul edilir. Bu tek kural bile yanlış yorumlanırsa OEE panosu çalışan makineyi durmuş gösterir. MTConnect’te veri modeli kadar, bu tür durum kurallarını da test etmek gerekir.^[4]

İkinci dönemeç: Salt okunur olması bir eksiklik değil, sınır kararı

MTConnect’in en çok eleştirilen yanı, kontrole yazma yetkisinin olmamasıdır. Oysa bu bir eksiklik değil, bilinçli bir sınır. FOCAS ve LSV2 gibi üretici API’leri parametre, offset, program ve PLC verisi yazabilir; bu güç, aynı zamanda en büyük risk yüzeyidir. Yanlış bir offset veya PLC biti, takımı kırabilir, iş parçasını bozabilir ya da operatörü riske atabilir.^[1][4]

MTConnect bu riski mimari düzeyde keser: veri yalnızca makineden dışarı akar. İzleme, MES, enerji analizi ve duruş sınıflandırması için ihtiyaç duyulan bilgiyi verir; kontrolün içine yazmaz. Bu, “MTConnect güvenlidir” demek değildir; ağ segmentasyonu, TLS, ters vekil ve erişim kontrolü yine gerekir. Söylenebilecek doğru cümle şudur: MTConnect’in yazma yetkisi yoktur, bu yüzden yazma kaynaklı kaza riskini taşımaz.

Üçüncü dönemeç: Standart sürümü ile agent sürümü aynı şey değil

Sahada sık yapılan hata, “agent 2.8 çıktı, standart 2.8 oldu” demek. Agent, standardı uygulayan yazılımdır; standart ise belge kümesidir. Referans cppagent 13 Ekim 2026’da 2.8.0.4 sürümüne ulaştı; README’de desteklenen standart özellikleri 2.5, 2.6 ve 2.7 başlıkları altında anlatılıyor. 2.5 palet/fikstür ve WebSocket tarafını, 2.6 REST hata belgeleri ve AssetAdded olayını, 2.7 ise Part/Process/Task varlık modellerini getiriyor.^[4][5]

Bu ayrım, satın alma ve entegrasyon kararlarını doğrudan etkiler. Bir MES tedarikçisine “hangi MTConnect sürümünü destekliyorsunuz?” diye sorduğunuzda iki cevap almalısınız: hangi standart sürümü ve hangi agent sürümü. Açık kaynak .NET istemcisi MTConnect.NET, 2.7’ye kadar olan standartları destekliyor; bu da eski bir agent ile yeni bir istemci arasında sürüm farkı doğabileceğini gösteriyor. Ayrıca agent’ın buffer davranışı, örnek saklama süresi ve yeniden bağlanma sonrası sequence yönetimi, standart belgede yazandan daha çok saha davranışını belirler.^[4][5][6]

Adapter tarafında da bir seçim var. SHDR, satır tabanlı ve basit bir taşımadır; eski CNC adapter’larının çoğu hâlâ onu kullanır. MQTT ve JSON, daha modern ve ölçeklenebilir bir yol sunar. Agent ile adapter arasındaki bu tercih, standart dışında kalan ama kurulumun kaderini belirleyen bir mühendislik kararıdır.

Kimi için uygun, kimi için değil?

Yaygın dört yanlış

• “MTConnect kurunca her şey görünür.” Hayır. Agent yalnızca kendisine bağlanan veri öğelerini yayınlar; eksik bir adapter veya eşlenmemiş bir sinyal modelde görünmez.
• “Agent’ı makineye kurmak yeterli.” Agent ile adapter ayrı görevlerdir. Adapter kontrolün dilini okur, Agent bu veriyi standart modele çevirip sunar; ikisini aynı kutu sanmak, sahadaki en yaygın mimari hatadır.
• “/current sürekli akıştır.” /current anlık bir fotoğraftır. Kaçırılan olayları yakalamak için /sample ve sequence takibi gerekir; yalnızca /current yoklayan bir istemci, iki yoklama arasındaki alarmı görmeyebilir.
• “Standart adlar her makinede aynıdır.” Sözlük ortaktır, lehçe değildir. exec, pgm, tid gibi kısa adlar yaygın olsa da agent üreticisi ve kontrol ailesi adları değiştirebilir; eşleme tablosu olmadan kör kurulum yapılmamalıdır.

Koşullar (conditions) da ayrı bir dikkat ister. MTConnect’te bir alarm yalnızca “var/yok” değildir; Warning, Fault ve Normal durumları, ilgili veri öğesinin koşul zincirinde taşınır. Bir istemci yalnızca Fault metnini okuyup Normal geçişini yok sayarsa, arıza giderildiğinde panosunda alarm asılı kalır. Bu yüzden koşul yaşam döngüsünü, avail durumuyla birlikte test etmek gerekir.^[4]

Kurulumda yedi kritik adım

1. Ağı ayırın: Makine ağı ile kurumsal ağ arasına bir DMZ veya ters vekil koyun. Agent’ı doğrudan internete açmayın.
2. Agent’ı makineye yakın konumlandırın: Ağ gecikmesi ve kopmalar, örnek buffer’ını doğrudan etkiler.
3. Adapter taşımasını seçin: Eski kontrol için SHDR, yeni altyapı için MQTT/JSON değerlendirin.
4. /probe çıktısını dondurun: Model dosyasını sürüm kontrolüne alın; agent veya kontrol yazılımı güncellendiğinde yeniden karşılaştırın.
5. Eşleme tablosu tutun: dataItemId, name, iş anlamı ve birim sütunları olsun. Mazak/Memex/DMG gibi lehçeleri burada belgeleyin.
6. Zamanı hizalayın: Makine, agent ve toplayıcı saatlerini NTP ile eşleyin; sequence ve timestamp olmadan duruş analizi güvenilir olmaz.
7. Durum kurallarını test edin: avail=UNAVAILABLE, alarm koşulları ve yeniden bağlanma senaryolarını simülatörle doğrulayın.

Sonuç: Ortak cümle, ortak sorumluluk

MTConnect’in değeri, kaç veri noktası taşıdığında değil, kaç farklı makineyi aynı cümlede konuşturabildiğinde saklıdır. Ama ortak cümle, ortak sorumluluk da getirir: sözlüğü kimin tanımladığı, lehçeleri kimin eşlediği ve hangi verinin asla yazılmaması gerektiği açıkça kararlaştırılmalıdır.

Bir sonraki soru şu: Fabrikanızdaki veri modeli kimin elinde? Ve hangi veriyi okumak, hangisini asla yazmamak gerektiğini bugün net olarak söyleyebiliyor musunuz?

Bu yazı, CNC kontrol protokolleri serisinin ilk parçası. Seride FOCAS, Heidenhain DNC/LSV2 ve Mazak entegrasyonunu ayrı ayrı ele alacağız. Endüstriyel seri haberleşmenin fiziksel katmanı için RS-232 rehberimize, gömülü protokol fiziği için I2C/SPI/UART makalemize göz atabilirsiniz.