Akıllı bir katmanlı imalat sistemi yalnızca robot, kaynak makinesi veya 3D yazıcıdan oluşmaz. Termal kamera, termokupl, makine konumu, kaynak akımı, voltaj, tel besleme hızı ve daha birçok veri kaynağının aynı üretim sürecini eş zamanlı olarak izlemesi gerekir. Sorun, bu cihazların çoğunun farklı üreticiler tarafından geliştirilmesi ve TCP, UDP, OPC-UA veya üreticiye özgü yazılımlar gibi birbirinden farklı iletişim yöntemleri kullanmasıdır. Georgia Institute of Technology araştırmacılarının bu çalışması, farklı cihazları tek bir sabit protokole zorlamak yerine her cihaz bağlantısını bağımsız bir Python modülü hâline getiren ve bu modülleri merkezi bir çoklu iş parçacığı mimarisinde birleştiren alternatif bir yaklaşım öneriyor.

Önerilen yapı wire-arc additive manufacturing (WAAM) sistemi üzerinde gösterildi. Deney düzeneğinde Fanuc LR Mate 200iD/7L robotundan TCP ile 10 Hz konum verisi, Fronius TPS 400i kaynak sisteminden OPC-UA ile 20 Hz kaynak verisi, FLIR kızılötesi kameradan 30 Hz termal görüntü ve Raspberry Pi'ye bağlı dört termokupldan UDP ile 10 Hz sıcaklık verisi toplandı. Her veri örneğine merkezi bilgisayardaki ortak NTP zaman referansına göre zaman damgası eklenerek farklı frekans ve protokollerdeki ölçümlerin ortak bir üretim zaman çizgisinde karşılaştırılabilmesi hedeflendi.

Çalışmanın ana fikri, bütün üretim ekipmanlarının aynı iletişim protokolünü konuşmasını sağlamak değil, her cihazın kendi doğal iletişim biçimini korurken merkezi mimariye standart bir veri çıktısıyla bağlanmasını sağlamaktır. Böylece yeni bir sensör eklendiğinde bütün mimarinin yeniden yazılması yerine yalnız o cihaz için yeni bir iletişim modülü geliştirilebilir. Bununla birlikte çalışma yalnız belirli bir WAAM laboratuvar sistemi üzerinde demonstrasyon sunmaktadır; mimarinin bütün katmanlı imalat makinelerinde otomatik uyumluluğunu, endüstriyel ölçekte gecikme performansını veya kapalı çevrim kalite kontrolündeki üretim kazancını henüz göstermemektedir.

Katmanlı imalatta neden bir “dijital mimari” gerekiyor?

Katmanlı imalat sürecinde fiziksel parçanın katman katman oluşturulması yalnız sürecin görünen kısmıdır. Modern bir sistemde aynı anda çok sayıda dijital bilgi oluşur:

• robot veya CNC konumu,
• kaynak akımı ve voltajı,
• tel besleme hızı,
• ısı girdisi ve güç,
• termal kamera görüntüleri,
• termokupl sıcaklıkları,
• optik görüntüler,
• akustik sinyaller,
• makine durumu ve hata mesajları.

Bu veriler parçada neden gözenek, çatlak, geometrik sapma veya termal bozulma oluştuğunu anlamak için önemli olabilir. Aynı veriler daha ileri aşamada makine öğrenmesi modellerinin girdisi veya gerçek zamanlı kontrol döngülerinin geri beslemesi olarak da kullanılabilir.

Ancak fiziksel olarak aynı üretim hücresinde bulunan cihazlar dijital olarak aynı dili konuşmak zorunda değildir.

Asıl sorun farklı üreticilerin farklı haberleşme yöntemleri

Bir robot üreticisi TCP soket mesajlaşması ve kendine özgü programlama dili kullanabilir. Kaynak güç kaynağı OPC-UA sunucusu sağlayabilir. Bir kamera üreticisi kendi SDK'sını kullanırken başka bir sensör UDP paketi gönderebilir.

Araştırmacıların problemi şu şekilde özetlenebilir:

Farklı protokoller + farklı örnekleme frekansları + farklı üretici yazılımları → parçalanmış üretim verisi.

Oysa proses analizi yapılırken araştırmacının bilmek istediği şey örneğin şöyledir:

Robot tam bu koordinattayken kaynak akımı neydi, termal kamerada maksimum sıcaklık kaçtı ve aynı anda plakadaki dört termokupl ne ölçtü?

Bunu cevaplamak için verilerin ortak zaman bağlamına yerleştirilmesi gerekir.

ROS neden doğrudan çözüm olarak seçilmedi?

Çalışma Robot Operating System'i (ROS) çok bileşenli sistemlerin iletişim ve kontrolü için önemli bir yaklaşım olarak değerlendiriyor. Ancak yazarlar kendi kullanım amaçları açısından ROS'un işletim sistemi, implementasyon ve ön bilgi gereksinimlerini sınırlayıcı bulmaktadır.

MTConnect ve OPC-UA gibi çözümler de endüstriyel makine verisine erişim için kullanılabilmektedir. Buna karşılık araştırmacıların hedefi, tek bir protokolü bütün cihazlara uygulamak yerine üreticiye özgü mevcut iletişim yöntemlerini birbirinden bağımsız Python modülleri üzerinden merkezi yapıya bağlamaktır.

Bu çalışma ROS, MTConnect veya OPC-UA'nın yetersiz olduğunu genel olarak kanıtlayan karşılaştırmalı benchmark değildir. Bunların çalışma bağlamındaki uygunluk sınırlılıkları mimari tasarım gerekçesi olarak tartışılmaktadır.

Önerilen mimarinin temel prensibi nedir?

Mimari üç kavram üzerine kuruludur:

1. Her donanım için bağımsız iletişim modülü.
2. Modüllerin merkezi Python “main” sistemi tarafından paralel çalıştırılması.
3. Bütün verilerin zaman damgasıyla ortak veri yapısında birleştirilmesi.

Bu nedenle sistem monolitik değil, modülerdir.

Bir termokupl sisteminin eklenmesi gerektiğinde Fanuc veya Fronius kodunun yeniden tasarlanması yerine yalnız termokupldan veri alan yeni bir Python betiği yazılır ve ana iş parçacığı yöneticisine eklenir.

Şekil 2: Merkezi mimari nasıl çalışıyor?

Makalenin 3. sayfasındaki Şekil 2, bütün sistemin mimari haritasını göstermektedir.

Merkezde Main Multi-thread Handler bulunur. Bu ana yapı farklı donanımlarla iletişim kuran alt programları aynı anda çalıştırmaktadır.

Örneğin:

• Fronius Handler → OPC-UA verilerini toplar,
• Fanuc Handler (Read) → robot pozisyonunu ve register değerlerini alır,
• Fanuc Handler (Write) → robota başlatma veya benzeri sinyaller gönderebilir,
• FLIR IR Handler → termal kamera görüntülerini işler.

Ana yapı ayrıca IP adreslerini, sistem parametrelerini ve deney bilgilerini ayrı sözlüklerde tutmaktadır. Toplanan veri daha sonra dönüştürülerek DataFrame/yerel dosya yapısına kaydedilebilmektedir.

Python multi-threading burada ne işe yarıyor?

Sensörlerin birbirini beklememesi gerekir. Termal kamera saniyede 30 görüntü üretirken robot yalnız saniyede 10 konum örneği gönderiyorsa, bütün sistemin en yavaş cihaza göre çalıştırılması veri kaybına yol açabilir.

Bu nedenle her iletişim süreci bağımsız iş parçacığında çalıştırılır.

Bir cihazdan gelen veri bir queue yapısına bırakılır. Başka bir iş parçacığı bu kuyruktaki kayıtları merkezi log sistemine yazar.

Bu yaklaşım farklı cihazların kendi doğal veri hızlarında çalışabilmesine imkân vermeyi amaçlamaktadır.

Zaman damgası neden sistemin kritik bileşeni?

Farklı frekanslarda kayıt alınması tek başına sorun değildir; hangi ölçümün hangi proses anına ait olduğunun bilinmemesi asıl sorundur.

Her alt program veri noktasına bilgisayarın ortak NTP zaman referansını kullanarak zaman damgası eklemektedir.

Bir veri kaydı kavramsal olarak:

[sensör kimliği + ölçülen değer + zaman damgası]

şeklinde düşünülebilir.

Böylece 30 Hz kameradaki bir görüntünün yaklaşık olarak hangi 20 Hz kaynak örneğine veya 10 Hz robot konumuna denk geldiği sonradan belirlenebilir.

Bununla birlikte çalışma NTP tabanlı eşleştirmenin mutlak zaman doğruluğunu veya cihazlar arasındaki senkronizasyon hatasını ölçmemiştir.

Fanuc robotla iletişim nasıl kuruluyor?

Deney düzeneğinin robotu Fanuc LR Mate 200iD/7L'dir.

Ana iletişim:

• TCP socket messaging,
• Fanuc R648 ve R636 socket paketleri,
• Fanuc'un KAREL programlama dili

üzerinden gerçekleştirilmektedir.

Python'un yerleşik socket paketleri robotla bağlantıyı başlatır; robot KAREL programıyla bağlantıyı kabul eder ve kaynak programı boyunca verileri gönderebilir.

KAREL'in yürütme yapısı nedeniyle veri gönderme ve alma durumları kaynak betiğindeki register değerleriyle değiştirilir. Katmanlar arasında robot bilgisayardan devam sinyali gelene kadar bekleyebilmektedir.

Bu yapı yalnız veri okumaya değil belirli koşullarda bilgisayardan robota bilgi gönderilmesine de olanak sağlamaktadır.

Fronius kaynak sistemi nasıl bağlanıyor?

İkinci ana bileşen Fronius TPS 400i kaynak güç sistemidir.

Sistem kendi OPC Unified Architecture — OPC-UA sunucusunu barındırmaktadır.

Bilgisayar bu sunucu üzerinden:

• kaynak modu,
• prosesin aktif olup olmadığı,
• hata bilgileri,
• seam numarası,
• kaynak enerjisi,
• akım,
• voltaj,
• güç,
• tel besleme hızı

gibi bilgileri okuyabilmektedir.

Python tarafında asenkron programlama kullanılarak OPC-UA sunucusu deneyde 20 Hz aralıkla sorgulanmıştır.

FLIR termal kamera neden ayrı bir thread gerektiriyor?

Termal kamera bağlantısı FLIR'in Spinnaker SDK'sı ve PySpin uygulaması üzerinden gerçekleştirilmektedir.

Kamera ham radyometrik veriyi okuyup verilen emissivity değerine bağlı olarak sıcaklığa dönüştürebilmektedir.

Çalışma önemli bir pratik sorun bildiriyor: görüntünün aynı handler içinde diske kaydedilmesi kamera hızını yaklaşık 30 fps'den 10 fps'ye kadar düşürebilmektedir.

Araştırmacılar bu nedenle görüntü kaydetmeyi ayrı bir thread'e ayırmıştır. Kamera veri akışı ile disk yazma işleminin birbirinden ayrılması, kameranın daha yüksek doğal örnekleme hızını korumayı amaçlamaktadır.

Termokupl eklemek modülerliği nasıl gösteriyor?

Makalenin 4. sayfasındaki Şekil 3(b), çalışmanın “modüler” iddiasını doğrudan görselleştiriyor.

İlk mimaride bulunmayan termokupllar daha sonra Raspberry Pi üzerinden sisteme eklenmiştir.

Akış:

Termokupllar → Raspberry Pi Thermocouple Reader → UDP → Thermocouple Handler → Main Multi-thread Handler

şeklindedir.

Yeni cihaz için gereken temel işlemler kaynakta üç adım olarak açıklanmaktadır:

1. iletişim betiğini başlat,
2. verilerin aktarılacağı queue'yu oluştur,
3. proses bitince bağlantıyı düzgün biçimde kapat.

Bu, modülerliğin yeni sensörün otomatik keşfi anlamına gelmediğini de göstermektedir. Sensöre özgü iletişim kodunun yine geliştirilmesi gerekir.

Deneyde ne üretildi?

Mimarinin çalışmasını göstermek için wire-arc additive manufacturing ile beş katmanlı, tek dikişli Aluminum 5183 duvar üretilmiştir.

Duvar uzunluğu:

152,4 mm

olarak verilmiştir.

Altlık ise Aluminum 6061'den:

50,8 × 203,2 mm

boyutlarında hazırlanmıştır.

Bu deney sırasında dört bağımsız veri akışı aynı anda kaydedilmiştir.

Şekil 4 neden çalışmanın en önemli görsellerinden biri?

Dördüncü sayfadaki Şekil 4 yalnız mimari şemasını değil, gerçek deney verilerinin nasıl aynı süreçte birleştiğini göstermektedir.

Görselde:

• IR kameranın termal ölçümü,
• Fanuc robotun üç boyutlu konumu,
• Fronius kaynak sistemi verileri,
• dört termokupl sıcaklık eğrisi

aynı WAAM prosesi bağlamında gösterilmektedir.

Termal kamera örneğinde maksimum sıcaklık 509,36 °C olarak görünmektedir.

Bu değer çalışmanın ana performans sonucu değildir; Şekil 4'te gösterilen belirli proses anına ait termal ölçüm örneğidir.

Farklı frekanslı veriler nasıl işleniyor?

Kaynakta her veri akışı kendi özgün frekansında kaydedilmekte ve zaman damgalarıyla kaynak başlangıcına hizalanmaktadır.

Deney sırasında Python logging mekanizması veriyi sensör tipinden bağımsız olarak mümkün olduğunca hızlı biçimde kaydeder. Ana program sonlandırıldığında CSV tekrar ayrıştırılarak sensörlere göre organize edilir.

Bu yaklaşımın önemli avantajlarından biri ham verinin doğal frekansının korunabilmesidir.

Araştırmacı daha sonra ihtiyacına göre veriyi:

• aynı frekansta bırakabilir,
• downsample edebilir,
• ara değer tahminiyle çözünürlüğünü yükseltebilir,
• farklı sensörlerle nokta-nokta karşılaştırabilir.

Termokupl ve IR kamera neden birlikte değerli?

IR kamera yüzey sıcaklığı hakkında yüksek uzamsal ve zamansal çözünürlük sağlayabilir fakat doğru sıcaklık hesaplaması emissivity değerine bağlıdır.

Termokupl ise belirli fiziksel noktalarda doğrudan sıcaklık referansı sağlayabilir.

Yazarlar özellikle alüminyum sisteminde termokuplların IR kamera emissivity ayarlarını doğrulamak için bir tür ground truth olarak kullanılabileceğini belirtmektedir.

Bu, veri füzyonunun yalnız daha fazla veri toplamak için değil, bir sensörün başka sensör tarafından doğrulanması için de kullanılabileceğini göstermektedir.

Gerçek zamanlı kontrol mümkün mü?

Mimari yalnız veriyi kaydetmek üzere tek yönlü tasarlanmamıştır. Merkezi bilgisayar hesaplama yaptıktan sonra bazı makinelere geri bilgi gönderebilmektedir.

Kaynakta verilen örnek, termal veride belirli bir değişiklik tespit edildiğinde robot pozisyonunun daha soğuk bölgelere yönlendirilerek parça boyunca daha düzgün sıcaklık gradyanı elde edilmeye çalışılmasıdır.

Bu güçlü bir kullanım senaryosudur ancak önemli bilimsel sınır şudur:

Çalışma bu özel adaptif termal kontrol algoritmasını uygulayıp parça kalitesindeki iyileşmeyi ölçmemiştir.

Yani mimari böyle bir geri besleme döngüsüne teknik temel sağlayabilir; kapalı çevrim performansı gelecekte ayrıca doğrulanmalıdır.

Makine öğrenmesi için ne avantajı olabilir?

Farklı sensör verilerinin zaman açısından eşlenmesi, makine öğrenmesi için özellikle önemlidir.

Örneğin çalışma 30 Hz termal kamera verisinin iki adet 15 Hz alt kümeye bölünebileceğini tartışmaktadır.

Bir 15 Hz veri kümesi:

• kaynak parametreleri,
• robot pozisyonu,
• termal bilgiler

ile birlikte bir modelin eğitiminde kullanılabilir; diğer 15 Hz noktalar tahmin performansını sınamakta kullanılabilir.

Bu senaryo çalışmada öneri olarak verilmiştir. Makalenin kendi deneylerinde bu tasarımla eğitilip doğruluğu raporlanan yeni bir ML modeli yoktur.

Çalışma neyi destekliyor?

• Farklı üretici ve protokollere sahip WAAM bileşenleri Python tabanlı modüler bir merkezi mimariye bağlanabilir.
• TCP, OPC-UA, Ethernet ve UDP tabanlı veri akışları aynı deney sırasında birlikte kaydedilebilir.
• Her sensör kendi veri toplama frekansında çalıştırılabilir.
• Zaman damgaları farklı frekanstaki veri akışlarını aynı üretim süreci boyunca ilişkilendirmek için kullanılabilir.
• Yeni bir sensör modülü mevcut ana yapıyı bütünüyle yeniden tasarlamadan eklenebilir.
• Merkezi bilgisayar yalnız veri almakla sınırlı değildir; bazı makine bağlantılarında geri bilgi gönderme altyapısı kurulabilir.
• Toplanan birleşik veri, proses sonrası analiz, sensör doğrulama, makine öğrenmesi ve gelecekteki geri beslemeli kontrol sistemleri için temel oluşturabilir.

Çalışma neyi kanıtlamıyor?

• Mimarinin dünyadaki bütün katmanlı imalat sistemleriyle doğrudan uyumlu olduğunu kanıtlamıyor.
• Yeni bir cihazın iletişim betiği yazılmadan otomatik olarak sisteme bağlanacağını göstermiyor.
• Zaman senkronizasyonunun mutlak hassasiyetini ölçmüyor.
• Ağ gecikmesi, paket kaybı ve jitter için nicel benchmark sunmuyor.
• Çok yüksek sensör sayısında ölçeklenebilirlik sınırını ölçmüyor.
• ROS, MTConnect veya başka mimarilere karşı nicel performans üstünlüğü göstermiyor.
• Kapalı çevrim proses kontrolünün parça kalitesini artırdığını deneysel olarak göstermiyor.
• Toplanan verilerle yeni bir makine öğrenmesi algoritmasının doğruluğunu ölçmüyor.
• Üretilen Aluminum 5183 numunenin mekanik özelliklerinde mimariye bağlı iyileşme kanıtlamıyor.

Çalışmanın Yöntemi ve Bulguları

Deney sisteminin fiziksel bileşenleri

İletişim protokolleri

Veri işleme zinciri

Çalışmanın yazılım akışı sadeleştirildiğinde:

Cihaz → cihaz-özel Python iletişim betiği → queue → merkezi multi-thread handler → timestamp + veri kaydı → logging → CSV → sensöre göre yeniden düzenleme

biçimindedir.

Bu tasarımın önemli yönü sensör verisinin merkezi uygulamaya gelmeden önce kendi cihaz-özel iletişim katmanında çözülmesidir.

Merkezi sistem böylece her cihazın ayrıntılı protokolünü aynı kod bloğunda yönetmek zorunda kalmaz.

NTP zaman referansı

Alt modüller ortak bilgisayar üzerindeki NTP zaman referansıyla veri noktalarına zaman damgası eklemektedir.

Bu yaklaşım farklı veri akışlarının kaynak başlangıcı çevresinde hizalanabilmesine olanak verir.

Ancak kaynakta:

• NTP offset,
• clock drift,
• paket gecikmesi,
• timestamp belirsizliği,
• senkronizasyon hatası

için nicel ölçüm verilmemektedir.

Beş katmanlı demonstrasyon

Şekil 3'ün gösterdiği modüler ekleme

Termokuplların ilk mimariye sonradan eklenmesi çalışmanın modüler tasarımının en doğrudan demonstrasyonudur.

Raspberry Pi'deki termokupl okuyucu sıcaklık dizisini üretir. Thermocouple Handler bu veriyi merkezi yapının beklediği formata dönüştürür ve ana multi-thread handler'a aktarır.

Diğer cihazların iletişim kodları bu ekleme sırasında yeniden yazılmamıştır.

Şekil 4'ün gösterdiği veri füzyonu

Şekil 4'te dört fiziksel veri kaynağı tek üretim olayı etrafında görselleştirilmektedir.

Böylece araştırmacı aynı zaman aralığında:

• ısı kaynağının konumunu,
• IR maksimum sıcaklığını,
• kaynak güç sistemi davranışını,
• plakadaki dört sıcaklık ölçümünü

birlikte inceleyebilmektedir.

Bu çalışma açısından “tek veri akışı” ifadesi bütün sensörlerin aynı frekansta tek tip ölçüm üretmesi değil, farklı veri akışlarının ortak zaman ve kayıt yapısı üzerinden birlikte analiz edilebilir olması anlamına gelmektedir.

Veri çözünürlüğü sonradan değiştirilebilir

Makale iki farklı veri işleme senaryosunu tartışmaktadır.

Çözünürlüğü artırma: 10 Hz termokupl ölçümleri arasında 30 Hz IR kamera veya Kalman filtresi gibi yöntemlerden yararlanılarak ara değerler tahmin edilebilir.

Çözünürlüğü azaltma: IR kameranın 30 Hz verisi, daha düşük frekanslı ve güvenilen başka bir sensörle nokta-nokta kıyas için downsample edilebilir.

Ayrıca buluta gönderilen veri miktarının sınırlandırılması gereken sistemlerde daha düşük frekansta veri akışı oluşturulabilir.

Bunlar mimarinin sunduğu veri işleme olanaklarıdır; makalede bütün bu filtreleme yöntemlerinin performansı karşılaştırmalı olarak test edilmemiştir.

Çalışmanın güçlü yönleri

• Gerçek WAAM donanımı üzerinde uygulamalı demonstrasyon yapılması.
• Dört farklı veri kaynağının aynı anda kullanılması.
• TCP, UDP ve OPC-UA gibi farklı iletişim yöntemlerinin aynı mimaride bulunması.
• Farklı doğal örnekleme frekanslarının korunması.
• Yeni termokupl modülünün sonradan eklenerek modülerliğin gösterilmesi.
• Zaman damgalı veri yapısının proses analizi için merkezi hâle getirilmesi.
• Robot bağlantısında yalnız okuma değil geri yazma imkânının bulunması.
• Yazılım yapısının Python gibi yaygın bir araştırma diliyle geliştirilmesi.

Çalışmanın temel sınırlılıkları

Çalışma kısa-format bir Manufacturing Letters makalesi olduğu için mimarinin çok geniş ölçekli performans değerlendirmesi yapılmamıştır.

Özellikle şu ölçümler eksiktir:

• uçtan uca veri gecikmesi,
• timestamp senkronizasyon hatası,
• paket kayıp oranı,
• uzun süreli sistem kararlılığı,
• maksimum eş zamanlı sensör sayısı,
• CPU ve RAM yükü,
• ağ bant genişliği gereksinimi,
• kontrol döngüsü tepki süresi,
• diğer dijital mimarilerle nicel benchmark.

Ayrıca test tek bir araştırma WAAM hücresinde gerçekleştirilmiştir. Farklı marka robotların, CNC sistemlerinin, lazer tabanlı AM makinelerinin veya endüstriyel fabrika ağlarının aynı kolaylıkta entegre edilebileceği ayrıca doğrulanmalıdır.

Endüstride uygulanırken başka ne gerekir?

Bir araştırma laboratuvarında modüler veri toplama mimarisi kurulması ile sürekli çalışan endüstriyel üretim altyapısı aynı güvenilirlik gereksinimlerine sahip değildir.

Gerçek fabrika uygulamasında ayrıca:

• kullanıcı yetkilendirme,
• ağ güvenliği,
• endüstriyel cihaz sertifikasyonu,
• bağlantı kesilmesinde güvenli davranış,
• veri bütünlüğü,
• yedekleme,
• versiyon yönetimi,
• protokol değişikliklerinde bakım,
• gerçek zamanlı kontrolün güvenlik sınırları

gibi konuların ayrıca ele alınması gerekir. Kaynak çalışma bunların tümünü çözülmüş kabul etmemektedir.

Türkiye'deki üretim sistemleri açısından anlamı

Çalışmada Türkiye'deki bir fabrika, robot veya AM sistemi üzerinde test bulunmamaktadır. Bu nedenle sistemin belirli bir Türk sanayi tesisinde doğrudan çalışacağı sonucu çıkarılamaz.

Bununla birlikte araştırmanın temel mimari fikri marka ve protokol çeşitliliğinin yüksek olduğu üretim tesisleri açısından genel bir araştırma yaklaşımı sunmaktadır. Örneğin farklı üreticilerden robot, kaynak sistemi, CNC, termal kamera ve proses sensörleri bulunan bir hücrede her cihaz için ayrı bağlantı modülü geliştirilip ortak zaman damgalı veri katmanına aktarılabilir.

Yerel endüstriyel uygulamada özellikle kullanılan PLC/CNC/robot protokolleri, siber güvenlik kuralları, gerçek zaman gereksinimleri ve fabrika ağ altyapısı için ayrı doğrulama yapılması gerekir.

Kaynak ve Yöntem Notu

Tam özgün çalışma adı: A proposal of a modular and customizable digital architecture for additive manufacturing

Yazarlar: Kathryn Kelly, Christopher Saldana, Kyle Saleeby.

Yazar sırası: Kaynak çalışmadaki sıra aynen korunmuştur.

Sorumlu yazar: Kathryn Kelly.

Eş katkı/eş birinci yazar: Kaynakta eş katkı beyanı bulunmamaktadır.

Kurum 1: Georgia Institute of Technology, George W. Woodruff School of Mechanical Engineering, Atlanta, Georgia, USA.

Kurum 2: Georgia Institute of Technology, Georgia Tech Manufacturing Institute, Atlanta, Georgia, USA.

Kaynak türü: Hakemli kısa-format araştırma/uygulama makalesi; Manufacturing Letters içinde “Letters” olarak yayımlanmıştır.

Dergi: Manufacturing Letters.

Yayımlayan: Elsevier Ltd. on behalf of Society of Manufacturing Engineers (SME).

Cilt: 49.

Sayfalar: 13–18.

DOI: 10.1016/j.mfglet.2026.06.008

Gönderim tarihi: 2 Nisan 2026.

Revizyon tarihi: 2 Haziran 2026.

Kabul tarihi: 9 Haziran 2026.

Çevrim içi yayın: 22 Haziran 2026.

Resmî DOI bağlantısı: https://doi.org/10.1016/j.mfglet.2026.06.008

Hakemlik durumu: Manufacturing Letters'ın yayımlanmış hakemli kısa araştırma formatıdır. Derginin resmî yazar kılavuzu makalelerin hakem değerlendirmesine tabi olduğunu belirtmektedir.

Lisans: Creative Commons Attribution-NonCommercial 4.0 — CC BY-NC 4.0.

Preprint durumu: İncelenen dosya nihai yayımlanmış Manufacturing Letters makalesidir.

Deney sistemi: Fanuc LR Mate 200iD/7L robotik manipülatör, Fronius TPS 400i CMT kaynak sistemi, FLIR IR kamera, dört termokupl ve Raspberry Pi.

Demonstrasyon: Aluminum 5183 kullanılarak Aluminum 6061 altlık üzerinde 152,4 mm uzunlukta, beş katmanlı tek dikişli WAAM duvar.

Ana yazılım mimarisi: Python multi-threading, queue, logging, cihaz-özel handler betikleri ve zaman damgalı merkezi veri toplama.

İletişim yöntemleri: Fanuc için TCP/KAREL; Fronius için OPC-UA; FLIR için Ethernet/Spinnaker/PySpin; Raspberry Pi termokupl sistemi için UDP.

Veri frekansları: Fanuc 10 Hz; Fronius 20 Hz; FLIR 30 Hz; termokupllar 10 Hz.

Zaman senkronizasyonu: Modüller merkezi bilgisayardaki ortak NTP zaman referansına göre zaman damgası atamaktadır. Makalede senkronizasyon hatasının nicel benchmark'ı verilmemiştir.

Finansman: Makalede ayrı bir finansman beyanı bulunmamaktadır. CRediT katkılarında Kyle Saleeby için Funding acquisition rolü belirtilmiştir.

Çıkar çatışması: Yazarlar, çalışmayı etkileyebilecek bilinen mali çıkar veya kişisel ilişki bulunmadığını beyan etmiştir.

CRediT katkıları: Kathryn Kelly: Writing – review & editing, Writing – original draft, Validation, Software, Methodology, Investigation, Formal analysis, Conceptualization. Christopher Saldana: Writing – review & editing, Supervision. Kyle Saleeby: Writing – review & editing, Resources, Funding acquisition, Formal analysis, Data curation.

Kod erişilebilirliği: Kaynak makale, kullanılan test kodunun Georgia Tech Manufacturing Institute'dan talep üzerine sağlanabildiğini ve çalışmanın tamamlanmasının ardından GTMI GitHub hesabında bütünüyle yayımlanmasının planlandığını belirtmektedir. Bu ifade kaynak makalenin yayın sırasındaki durumunu yansıtır.

Veri erişilebilirliği: Makalede ayrıca bağımsız bir Data Availability Statement bulunmamaktadır. Çalışmanın ana odağı mimarinin ve örnek veri akışlarının gösterimidir.

Temel yöntemsel sınır: Mimari tek bir WAAM araştırma sistemi üzerinde test edilmiştir. Makalede uçtan uca latency, jitter, packet loss, NTP senkronizasyon hatası, kaynak kullanımı veya büyük ölçekli sensör sayısında ölçeklenebilirlik benchmark'ı bulunmamaktadır.

Modülerlik sınırı: Mimariye yeni cihaz eklemek için ilgili sensör/makineyle haberleşebilen cihaz-özel Python betiğinin geliştirilmesi gerekir. Çalışma plug-and-play donanım keşfi önermemektedir.

Kontrol sınırı: Merkezi bilgisayardan makineye veri yazılabilmesi mimarinin geri beslemeli kontrol için kullanılmasını mümkün kılmaktadır; ancak çalışmada termal geri besleme ile otomatik robot düzeltmesinin parça kalitesine etkisi deneysel olarak ölçülmemiştir.

Makine öğrenmesi sınırı: Veri mimarisinin ML modelleri için kullanılabileceği tartışılmıştır; makale kendi topladığı veri üzerinde yeni bir makine öğrenmesi modelinin performansını raporlamamaktadır.

Bilimsel içerik sınırı: Bu Verianla yazısındaki mimari, donanım, iletişim protokolleri, sensör frekansları, deney geometrisi ve uygulama senaryoları özgün çalışmaya dayanmaktadır. Dış kaynak yalnız bibliyografik kayıt ve derginin hakemlik durumunun doğrulanması amacıyla kullanılmıştır.