Üretim sistemlerinde malzemenin doğru zamanda doğru noktaya ulaştırılması; yalnız konveyör, forklift veya AGV gibi fiziksel ekipmanın varlığına değil, farklı taşıma ve elleçleme kaynaklarının ortak bir bilgi yapısı içinde koordine edilebilmesine de bağlıdır. İncelenen çalışma, heterojen Taşıma ve Malzeme Elleçleme Sistemlerini (Transport and Material Handling Systems, TMHS) aynı model altında temsil etmek ve yönetmek için iki katmanlı genel bir yaklaşım önermektedir. İlk katman; taşınan nesneler, iş istasyonları ve taşıma/elleçleme cihazları için standart bir temsil dili sağlar. İkinci katman ise taşıma taleplerinin cihazlara atanması, cihaz hareketlerinin ve elleçleme faaliyetlerinin tetiklenmesi, dış olayların işlenmesi ve güncel sistem durumuna göre kararların yeniden değerlendirilmesi için veri yapıları ve süreçler tanımlar.

Model yalnız otomatik sistemleri hedeflemez. Forklift, kamyon, vinç, konveyör, tugger train, AGV ve farklı elleçleme cihazlarının aynı üretim ortamında bulunabildiği sistemlerin ortak bir yapıyla ifade edilebilmesini amaçlar. Böylece belirli bir ekipman teknolojisine özel yeni bilgi modeli geliştirmek yerine, farklı cihaz davranışları ortak nesne, iş istasyonu, rota, aktivite ve kısıt kavramları üzerinden tanımlanabilir.

Yönetim katmanında sekiz veri yapısı ve beş temel süreç bulunmaktadır. Taşıma talepleri doğrudan bir cihaza kalıcı olarak bağlanmak yerine sistem durumuna göre transport request link'lere dönüştürülür. Bir taşıma birden fazla cihaz gerektiriyorsa sistem yalnız sıradaki cihazı atar; ara aktarım tamamlandığında kalan güzergâh ve cihaz seçeneklerini yeniden değerlendirir. Bu yaklaşım, cihaz kullanılabilirliği veya sistem durumu değiştiğinde sabit bir taşıma zincirine bağlı kalmadan yeniden karar verilmesini sağlar.

Makale modelin uygulanabilirliğini farklı cihaz, transfer noktası, buluşma noktası ve taşınabilir depolama birimleri içeren temsilî endüstriyel senaryolarla göstermektedir. Bununla birlikte değerlendirme kavramsal ve senaryo tabanlıdır; çalışan bir endüstriyel yazılım uygulaması veya gerçek sistemde ölçülmüş performans artışı sunulmamaktadır.

Üretim içi lojistik neden ortak bir modele ihtiyaç duyuyor?

Akıllı üretim ortamlarında üretim planlama, iş emirleri, makine durumu ve malzeme akışının birbirinden bağımsız bilgi adaları olarak yönetilmesi yeterli değildir. Bir üretim işi başlamadan önce gerekli malzemenin ilgili istasyona ulaştırılması, taşıma cihazının uygun olması, yükleme veya boşaltma işleminin fiziksel olarak mümkün olması ve üretim işiyle taşıma faaliyetinin zaman açısından senkronize edilmesi gerekir.

Bu sorun, üretim sisteminde tek bir taşıma teknolojisi bulunduğunda nispeten basittir. Ancak aynı tesiste forklift, AGV, vinç, konveyör, otomatik depolama sistemi, tugger train veya kamyon gibi farklı davranışlara sahip ekipmanlar kullanıldığında her birini ayrı yazılım mantığıyla temsil etmek ölçeklenebilirliği ve yeniden kullanılabilirliği sınırlar.

Kaynak çalışma bu problemi ekipman teknolojisi üzerinden değil, cihazların gerçekleştirebildiği ortak davranışlar üzerinden modellemeye çalışmaktadır.

Taşıma ve Malzeme Elleçleme Sistemi İçin Önerilen Genel Model Nedir?

Önerilen genel model, heterojen üretim içi lojistik sistemlerini iki tamamlayıcı katmanda ele alan bir bilgi ve koordinasyon modelidir. Temsil katmanı nesnelerin, iş istasyonlarının ve taşıma/elleçleme cihazlarının ortak bir sözlükle tanımlanmasını sağlarken; yönetim katmanı taşıma taleplerini, cihaz durumlarını, gerçek cihaz faaliyetlerini ve dış sistem olaylarını kullanarak hangi taşıma veya elleçleme faaliyetinin sırada yürütüleceğini belirler.

Modelin kapsamı

Model ayrık üretim sistemlerine yöneliktir. Sürekli proses üretimi, farklı operasyonel özelliklere sahip olduğu için kapsam dışında bırakılmıştır.

Çalışmanın odağı bir nesnenin taşınması için gereken talebin alınmasından malzemenin hedef istasyona ulaşmasına kadar olan bilgi ve koordinasyon zinciridir. Rota optimizasyonu, fabrika yerleşim tasarımı veya genel kaynak tahsisi optimizasyonu modelin temel kapsamına dahil değildir.

Model Manufacturing Planning and Control System'in bir alt sistemi olarak ele alınmaktadır. Üretim planlama ve kontrol süreçlerinden taşınacak nesneler, taşıma talepleri ve üretim işi durumları alınabilir; karşılığında nesne konumları ve taşıma taleplerinin ilerleme durumu üretim sistemine geri aktarılabilir.

Birinci katman: genel temsil dili

Temsil dili üç temel element sınıfına dayanır:

1. Nesne: Cihaz tarafından taşınabilen malzeme, parça, takım, ekipman veya bunları içeren taşıma/depolama birimleri.
2. İş istasyonu: Bir cihazın ulaşabildiği ve hareket veya elleçleme faaliyeti gerçekleştirebildiği fiziksel nokta.
3. Cihaz: TMHS içinde taşıma veya elleçleme faaliyeti gerçekleştiren fiziksel ekipman veya birlikte yönetilen ekipman grubu.

Nesne: volume ve storage location

Model iki nesne türünü ayırır. Volume, tek parça, parti veya konteyner gibi sayılabilir ve bir noktadan diğerine taşınabilir nesnedir. Storage location ise bir veya birden fazla volume barındırabilen palet, raf veya başka depolama/taşıma birimidir.

Storage location'ın önemli özelliği, yalnız malzemenin bulunduğu fiziksel alan olmak zorunda olmamasıdır; bazı sistemlerde kendisi de cihaz tarafından taşınabilir bir nesne olabilir.

Volume parameter ve storage-location parameter

Kuruluşlar taşınan nesneleri kendi ihtiyaçlarına göre nitelendirebilir. Volume parametreleri ürün türü, şekil veya ağırlık gibi nitelikler içerebilir. Storage-location parametreleri de benzer biçimde depolama birimlerinin kuruluş tarafından tanımlanan özelliklerini ifade eder.

Bu parametreler daha sonra cihaz veya rota kısıtlarının hesaplanmasında kullanılabilir. Örneğin belirli bir cihaz yalnız “Medium” boyuttaki kutuları taşıyabilir veya belirli bir aktivite yalnız 100 kg'ın altındaki hacimler için izinli olabilir.

İş istasyonu türleri

Model üç iş istasyonu davranışı tanımlar:

Bu ayrım özellikle heterojen lojistik sistemleri açısından önemlidir. Bir AGV malzemeyi transfer noktasında bırakabilir ve başka bir cihaz bunu daha sonra alabilir. Buna karşılık bir vinç ile kamyon arasında ağır bir yükün aktarılması için iki cihazın aynı anda buluşma noktasında bulunması gerekebilir.

Storage-location position

Bir storage location içinde birden çok volume bulunabileceğinden model, her volume'un tam olarak hangi pozisyona yerleştirildiğini de takip eder. Her pozisyon yalnız bir volume içerebilir ve hangi volume türünün oraya yerleştirilebileceğini belirleyen kısıt ifadeleri tanımlanabilir.

Cihazların modellenmesi

Bir cihaz, taşıyabildiği nesne türüyle ve üzerinde nesne tutulabilen bir veya birden fazla device position ile tanımlanır. Bunun yanında cihazın ulaşabildiği istasyonlar ve gerçekleştirebildiği faaliyetler iki temel kavramla modellenir: device route link ve device route activity.

Device Route Link ve Device Route Activity Arasındaki Fark Nedir?

Device route link, cihazın iki iş istasyonu arasında gerçekleştirebildiği hareketi tanımlar; başlangıç ve hedef istasyon, taşıma süresi, kısıtlar ve hareket komutunu üretmek için gerekli şablon burada bulunur. Device route activity ise cihaz hedef istasyona ulaştığında gerçekleştirebildiği yükleme, boşaltma, alma veya yerleştirme gibi elleçleme faaliyetini tanımlar.

Device route link

Her rota bağlantısında başlangıç iş istasyonu, hedef iş istasyonu, taşıma süresi, hareketin cihaz tarafından mı yoksa otomatik olarak mı yürütüldüğü ve taşınabilecek nesnelere ilişkin kısıtlar tutulabilir.

Örneğin belirli bir bağlantı yalnız belirli ürün türü veya belirli boyuttaki nesneler için geçerli olabilir. Böylece cihaz fiziksel olarak iki noktayı bağlasa dahi her yük o rotayı kullanmak zorunda değildir.

Go-To template

Model yalnız kavramsal rota bilgisi tutmakla kalmaz; fiziksel ekipmanla iletişimi sağlayabilmek için şablon mekanizması tanımlar. Bir Go-To template, ekipmana “bu cihazı bu başlangıçtan bu hedefe gönder” talimatının hangi veri yapısıyla iletileceğini tanımlar.

Kaynakta SOAP web service örneği verilmekle birlikte yapı belirli bir protokole bağımlı değildir; REST veya JSON temelli haberleşme biçimlerine uyarlanabilir. Buradaki amaç farklı endüstriyel sistemlerle semantik olarak tutarlı bir arayüz sağlamaktır.

Device route activity

Volume için iki ana elleçleme davranışı bulunur: Pick and Load ile Unload and Store. Storage location için ise Load, Unload, Pick ve Store faaliyetleri tanımlanmıştır.

Her aktivitede işlemi cihazın mı, iş istasyonunun mu yoksa otomatik mekanizmanın mı gerçekleştireceği belirtilebilir.

Senkronizasyon davranışı

Bir volume hedef istasyona ulaştığında her zaman hemen boşaltılmayabilir. Model dört senkronizasyon seçeneği sunar:

Böylece taşıma faaliyetinin yalnız fiziksel rota değil, üretim işinin gerçek zamanlı durumu ile de senkronize edilmesi amaçlanmaktadır.

Transfer Point ve Meeting Point nasıl ayrılıyor?

Transfer Point'te bir nesne cihazdan boşaltılarak geçici olarak bekleyebilir ve ikinci cihaz daha sonra bu nesneyi alabilir. Bu nedenle cihazların aynı anda bulunması gerekmez.

Meeting Point'te ise cihazlar arasında doğrudan aktarım yapılır. Örneğin ağır bir coil'i taşıyan vinç ile kamyon veya bir AGV ile robot kol aynı anda ilgili noktada bulunmak zorunda olabilir.

Kaynak çalışmanın Şekil 7'si, üç cihaz rotasını aynı sistem içinde göstererek bir transfer point ile bir meeting point'in tek temsil dilinde nasıl modellenebildiğini örneklemektedir.

Temsil Dilinden Operasyonel Yönetime Nasıl Geçiliyor?

Temsil dili cihazların ve sistem elemanlarının neler yapabileceğini tanımlar. Yönetim katmanı ise sistemin güncel durumunu kullanarak şimdi ne yapılması gerektiğini belirler. Bu nedenle model statik temsil ile dinamik yürütme bilgisini birbirinden ayırmaktadır.

Kaynak çalışma bu yapıyı üç boyutta özetler: Representation Language → Organization TMHS → Application. İlk aşama ortak sözlüğü, ikinci aşama belirli fabrikanın gerçek lojistik ağını, üçüncü aşama ise güncel üretim verisini kullanarak faaliyetlerin koordinasyonunu ifade eder.

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

Model geliştirme yöntemi

Model beş aşamada geliştirilmiştir. Önce literatür ve endüstriyel örneklerden veri toplanmış; ardından farklı TMHS davranışları gözlenmiş ve yorumlanmıştır. Üçüncü aşamada modelin sınırları ve dış sistemlerle arayüzleri tanımlanmıştır. Daha sonra temsil elemanları, özellikler ve yönetim süreçleri geliştirilmiş; son aşamada endüstriyel örnek senaryolar geliştirme süreciyle paralel ve yinelemeli biçimde kullanılarak model üzerinde düzeltmeler yapılmıştır.

Yönetim katmanının sekiz veri yapısı

Transport Request ile Transport Request Link aynı şey değildir

Transport Request, bir volume'un nihai hedefe taşınması ihtiyacıdır. Tek bir transport request'in tamamlanması için birden fazla cihaz gerekebilir.

Transport Request Link ise bu genel talebin belirli bir cihaz tarafından yürütülecek taşıma bölümüdür. Dolayısıyla bir transport request, süreç boyunca birden çok transport request link oluşturabilir.

Bu ayrım modelin heterojen ekipman zincirlerini yönetmesinin temelidir.

Device Activity

Device route, cihazın teorik olarak gerçekleştirebileceği rota ve faaliyetleri tanımlarken Device Activity, modelin o anda cihazdan gerçekten yürütmesini istediği faaliyettir.

Örneğin “WK1'den WK2'ye gidebilir” bir rota kabiliyetidir; “şimdi WK2'ye git” ise Device Activity'dir.

System External Event

Fiziksel üretim ortamındaki değişiklikler modele System External Event üzerinden geri bildirilir. Kaynakta dört temel olay grubu bulunmaktadır: cihaz aktivitesinin tamamlanması, üretim işinin başlaması, üretim işinin bitmesi ve cihaz durumunun değişmesi.

Bu olayların alınması veri yapılarını günceller ve gerektiğinde yeni transport request link veya device activity üretimini tetikler.

Taşıma Talebi Bir Cihaza Nasıl Atanıyor?

Model önce nesnenin mevcut konumu ile hedef workstation arasında geçerli bütün taşıma alternatiflerini belirler. Alternatifler cihaz kabiliyetleri, nesne türü, rota kısıtları, yükleme/boşaltma davranışları ve cihaz kullanılabilirliği açısından doğrulanır. Ardından kaynak çalışmada kullanılan örnek karar mantığı önce en az cihaz gerektiren alternatifi; aynı sayıda cihaz kullanan seçenekler arasında ise toplam taşıma süresi en kısa olan alternatifi seçer.

Tek cihazlı ve çok cihazlı taşıma

Kaynak çalışmanın Şekil 9'unda aynı volume'un üç farklı TMHS yapısında nasıl taşınabileceği gösterilmektedir. İlk yapıda tek bir cihaz başlangıçtan hedefe ulaşabilir. İkinci yapıda taşıma üç cihazın ardışık kullanımını gerektirir. Üçüncü yapıda ise üç cihazlı ve iki cihazlı iki alternatif mevcuttur.

Bu örnek modelin yalnız doğrudan rota bulmadığını, cihazlar arasındaki aktarma zincirlerini de değerlendirdiğini göstermektedir.

Neden bütün taşıma zinciri başlangıçta sabitlenmiyor?

Model çok cihazlı taşımada bütün transport request link'leri başlangıçta kesinleştirmek yerine yalnız bir sonraki cihazı atar.

Örneğin ilk cihaz volume'u transfer noktasına getirdiğinde sistem o anda mevcut alternatifleri tekrar değerlendirir. Bu sırada başka bir cihaz devre dışı kalmış, yeni bir cihaz kullanılabilir hale gelmiş veya daha uygun alternatif ortaya çıkmış olabilir.

Bu mekanizma sabit bir taşıma zinciri yerine güncel sistem durumuna göre yeniden karar verilmesini sağlar.

Alternatif seçimindeki iki örnek kriter

Kaynak çalışmanın önerilen örnek karar mantığında iki kriter vardır:

1. Taşımayı tamamlamak için gereken cihaz sayısını en aza indirmek.
2. Aynı sayıda cihaz gerektiren seçenekler arasında toplam taşıma süresini en aza indirmek.

Az cihaz seçilmesinin gerekçesi yalnız kaynak sayısı değildir. Her ilave aktarma yeni elleçleme faaliyeti, bekleme, senkronizasyon ve cihaz bağımlılığı oluşturabilir.

Bu karar kuralı modelin zorunlu parçası mı?

Hayır. Tartışma bölümünde farklı karar stratejilerinin kullanılabileceği açıkça belirtilmektedir. Model, belirli tek bir optimizasyon kuralı dayatmak yerine karar mekanizmalarının ihtiyaç duyacağı bilgi yapılarını sağlar.

Örneğin FIFO, requirement date önceliği veya kuruluşun tanımladığı başka bir strateji temel temsil dili değiştirilmeden uygulanabilir.

Beş yönetim süreci

Model Fiziksel Cihazların Faaliyetlerini Nasıl Koordine Ediyor?

Cihaz faaliyetleri önceden sabit bir operasyon listesi şeklinde yürütülmez. Model, cihazın tanımlı route link ve route activity yapısını, kendisine atanmış transport request link'leri ve mevcut sistem durumunu birlikte değerlendirerek o anda gerekli olan faaliyeti üretir. Böylece taşınacak nesne bulunmayan bir workstation'da gereksiz duruş veya handling faaliyeti tetiklenmeyebilir.

Pick and Load

Bir cihaz volume yükleyeceği istasyona ulaştığında sistem önce o cihazın taşıması gereken uygun volume'ları belirler. Nesne kısıtları, cihaz kullanılabilirliği ve cihaz üzerindeki uygun pozisyon doğrulandıktan sonra gerçek Device Activity oluşturulur.

Unload and Store

Cihaz üzerindeki volume hedef istasyona geldiğinde kısıtlar ve senkronizasyon kuralları kontrol edilir. Hedef normal workstation ise uygun storage-location position belirlenebilir. Hedef Meeting Point ise doğrudan depolama yerine sonraki cihazla transfer mekanizması çalışabilir.

Load, Unload, Pick ve Store

Taşınabilir storage location'ların yönetiminde cihaz bütün storage unit'i yükleyip boşaltabilir. Bunun yanında ilgili workstation'da storage location içinden tek tek volume alınması veya volume'un storage location içine yerleştirilmesi de modellenebilir.

Dış olaylarla döngünün kapanması

Bir fiziksel aktivitenin gerçekleştirilmiş olması, yalnız komutun cihaza gönderilmesiyle varsayılmaz. Model bu faaliyeti Device Activity olarak izler ve tamamlandığına ilişkin dış olay geldiğinde nesne konumlarını ve cihaz durumunu günceller.

Bu güncelleme sonrasında transport request tamamlanmışsa silinebilir; ara aktarma gerçekleşmişse yeni transport request link oluşturulabilir; cihazın sıradaki aktivitesi yeniden belirlenebilir.

Endüstriyel Vaka Örnekleri Neyi Gösteriyor?

İlk örnek farklı cihazların volume taşıdığı karma bir TMHS'yi, ikinci örnek ise içinde birden fazla volume bulunan taşınabilir storage location'ın cihaz tarafından taşındığı yapıyı göstermektedir. Bu iki senaryo, temel temsil yapısı değiştirilmeden farklı taşıma ve elleçleme davranışlarının aynı yönetim süreçleriyle ifade edilebildiğini göstermeyi amaçlamaktadır.

Örnek 1: volume taşıyan cihazlar

İlk senaryoda DV1–DV5 olmak üzere beş cihaz; WK1–WK4, bir Transfer Point ve bir Meeting Point olmak üzere altı istasyon kullanılmıştır.

Volume parametrelerinden biri kutu boyutunu, diğeri ağırlığı temsil eder. Örneğin DV1 yalnız “Medium” kutuları taşıyabilir ve WK1'de 100 kg'ın altındaki volume'ları Pick and Load edebilir.

Volume V5 için üç taşıma alternatifi

V5'in WK1'den WK2'ye taşınması için üç geçerli alternatif belirlenmiştir:

Örnek karar mantığı daha az cihaz gerektirdiği için Alternatif 1'i seçmektedir. Eğer DV1 uygun değilse Alternatif 2 ve 3 arasında toplam süre dikkate alınır ve Alternatif 2 tercih edilir.

Tek cihazlı senaryo

DV1 önce WK1'de V5'i Pick and Load eder, ardından WK2'ye gider ve V5'i hedef pozisyona Unload and Store eder. Her aktivite tamamlandığında dış olay modelin nesne ve cihaz durumlarını günceller.

Transfer Point senaryosu

İkinci alternatife göre DV2 V5'i TP1'e getirip bırakır. Volume nihai hedefi olan WK2'ye henüz ulaşmadığından taşıma talebi kapatılmaz. Sistem yeni bir transport request link oluşturarak DV3'ün TP1'den WK2'ye taşımayı devam ettirmesini sağlar.

Meeting Point senaryosu

Meeting Point kullanımında DV4 volume'u MP1'e getirir ancak nesneyi normal bir depolama pozisyonuna bırakmaz. DV5'in aynı noktaya gelmesi beklenir ve V5 doğrudan DV4 üzerindeki pozisyondan DV5'e aktarılır.

Bu davranış örneğin vinç-kamyon veya AGV-robot kol gibi eşzamanlı iki cihaz gerektiren transferleri temsil etmek için tasarlanmıştır.

Bir cihazdaki birden fazla taşıma talebinin sıralanması

Makale, taleplerin sisteme oluşturulma sırası ile gerçek ihtiyaç sırasının farklı olabileceğini de ele almaktadır. Bir cihaz birden fazla volume taşıyorsa hedefte boşaltma sırası transport request'in requirement date bilgisine göre değişebilir.

Böylece daha önce yüklenen bir volume, üretimde daha sonra gerekliyse başka bir volume'dan sonra boşaltılabilir.

Örnek 2: storage location taşıyan cihaz

İkinci örnekte DV6 bir storage location'ı bütün olarak taşımaktadır. Aynı storage location içinde birden fazla volume bulunduğunda cihaz her volume için taşıma ünitesini ayrı ayrı yüklemek zorunda değildir.

Model ilgili storage location'ı tek bir transportable unit olarak yükler, farklı workstation'lara gider, gerekli volume'ları storage location içinden alır ve görevler tamamlandığında storage location'ı başlangıç noktasına geri götürebilir.

Bu örnek hiyerarşik nesne ilişkilerinin de ortak veri yapısıyla yönetilebildiğini göstermektedir.

Modelin toplam bilgi yapısı

Tartışma bölümünde yönetim katmanının sekiz veri yapısı ve toplam 38 özellik içerdiği belirtilmektedir. Bu özelliklerin 22'si model tarafından yönetilirken 16'sı üretim sistemi, ekipman veya başka dış süreçlerden gelir.

Bu özelliklerin amacı yalnız veri depolamak değil, üretim sistemi ile taşıma sisteminin senkronizasyonuna temel oluşturmaktır.

Bu Çalışma Modelin Üretim Performansını Artırdığını Kanıtlıyor mu?

Hayır. Çalışmanın değerlendirmesi kavramsal ve senaryo tabanlıdır. Modelin gerçek bir yazılım sistemi olarak uygulanıp mevcut yöntemlerle karşılaştırıldığı deney bulunmamaktadır. Dolayısıyla throughput, çevrim süresi, cihaz kullanım oranı, enerji tüketimi, gecikme veya işletme maliyetinde nicel iyileşme gösterildiği söylenemez.

Çalışmanın desteklediği sonuçlar

• Aynı temsil dili altında farklı taşıma ve elleçleme cihazlarının modellenebildiğini.
• Volume ve taşınabilir storage-location davranışlarının ortak bir yapı içinde ifade edilebildiğini.
• Normal workstation, transfer point ve meeting point davranışlarının ayrıştırılabildiğini.
• Bir taşıma talebinin birden fazla cihaz arasında parçalara bölünebildiğini.
• Taşıma alternatiflerinin cihaz durumu ve rota kısıtlarına göre yeniden değerlendirilebildiğini.
• Dış sistem olaylarının üretim ve taşıma davranışını senkronize etmek için kullanılabildiğini.
• Aynı temsil yapısı değiştirilmeden farklı karar mantıklarının yönetim katmanına uygulanabileceğini.

Çalışmanın desteklemediği sonuçlar

• Önerilen modelin mevcut sistemlerden ölçülmüş olarak daha hızlı olduğunu.
• Üretim throughput'unu belirli bir yüzde artırdığını.
• Taşıma maliyetini, enerji tüketimini veya personel ihtiyacını ölçülmüş biçimde azalttığını.
• Önerilen iki seçim kriterinin bütün üretim sistemleri için optimal olduğunu.
• Modelin gerçek zamanlı üretim ortamında yazılım olarak doğrulandığını.
• Modelin sürekli proses endüstrilerine doğrudan uygulanabileceğini.
• Rota optimizasyonu veya fabrika layout optimizasyonu sorunlarını çözdüğünü.

Sınırlılıklar

Kaynak çalışmanın kendi sonuç bölümünde bazı sınırlılıklar açıkça belirtilmektedir. Bunlardan biri tek device route activity için birden fazla handling instruction tanımlanmasıyla ilişkili modelleme gereksinimleridir. Diğer bir sınır, zaman çizelgesine bağlı operasyonları ifade etmek için gereken bilginin henüz yeterince kapsanmamasıdır.

Daha temel sınırlılık ise modelin henüz çalışan IT support system içinde uygulanıp deneysel olarak değerlendirilmemiş olmasıdır.

Gelecek çalışma

Yazarlar modeli farklı sektörlerden ek endüstriyel vakalarla sınamayı, kalan davranışları kapsamak için yeni özellikler eklemeyi ve yaklaşımı gerçek bir IT support system içinde uygulayarak gerçek zamanlı TMHS koordinasyonu ile esnek konfigürasyon kabiliyetini değerlendirmeyi önermektedir.

Kaynak ve Yöntem Notu

Özgün çalışma: Generic Model to Represent and Manage Transport and Material Handling Systems in Manufacturing Systems

Yazarlar: Micael Gonçalves, Paulo Martins, Guilherme Pereira.

Kurum: ALGORITMI/LASI Research Centre, Department of Production and Systems, School of Engineering, University of Minho, Campus de Azurém, Guimarães, Portugal.

Belge türü: SSRN üzerinde bulunan preprint araştırma makalesi.

SSRN: Abstract No. 7290918.

Hakemlik durumu: Kaynak PDF her sayfada çalışmanın hakem değerlendirmesinden geçmediğini açıkça belirtmektedir.

Makale DOI'si: PDF'de makale için DOI verilmemiştir. Kaynakta bulunan 10.54499/UID/00319/2025 DOI'si finansmanı destekleyen FCT R&D Unit Project Scope kaydına aittir ve makalenin DOI'si değildir.

Finansman: Portuguese Foundation for Science and Technology tarafından PhD grant PD/BD/140854/2018 ve UID/00319/2025 - Centro ALGORITMI kapsamında destek bildirilmiştir.

Çıkar çatışması: Yazarlar çalışmalarını etkileyebilecek bilinen finansal çıkar veya kişisel ilişki bulunmadığını beyan etmektedir.

Ana katkının kökeni: Genel representation language daha önce Gonçalves ve arkadaşlarının 2024 çalışmasında tanıtılmıştır. Bu preprint'in temel yeni katkısı, bu temsil dilini sekiz veri yapısı ve beş yönetim süreciyle genişleten TMHS Management Layer'dır.

Yöntem: Literatür incelemesi, endüstriyel vaka verilerinin gözlenmesi, sistem davranışlarının analizi, model kapsamının belirlenmesi, model geliştirme ve temsilî endüstriyel case study'lerle yinelemeli değerlendirme.

Değerlendirme türü: Kavramsal ve senaryo tabanlı. Çalışan yazılım implementasyonu veya kontrollü performans benchmark'ı bulunmamaktadır.

Model kapsamı: Ayrık üretim ortamları. Sürekli üretim süreçleri, rota optimizasyonu, genel kaynak tahsisi optimizasyonu ve layout design ana kapsamın dışındadır.

Model yapısı: Temsil katmanı + yönetim katmanı. Temsil katmanı objects, workstations ve devices üzerine kuruludur; yönetim katmanı 8 data structure ve 5 process içermektedir.

Veri bağımlılığı: Modelin bazı temel bilgileri dış üretim süreçlerinden, cihazlardan veya kullanıcı arayüzlerinden alması gerektiğinden gerçek uygulamadaki doğruluk dış sistemlerden gelen durum bilgisinin kalitesine bağlıdır.

Lisans: Mevcut PDF içinde açık Creative Commons veya başka bir yeniden kullanım lisansı belirtilmemektedir. Verianla metni bu nedenle kaynak anlatımından ve grafiklerinden bağımsız biçimde oluşturulmuştur.

Telif yöntemi: Kaynak şekiller, rota diyagramları, tablolar veya SOAP şablonu kopyalanmamıştır. Modelde tanımlanan kavramlar ve doğrulanabilir teknik ilişkiler korunmuş; anlatım sırası, tablolar ve pedagojik yapı Verianla için yeniden tasarlanmıştır.