doi: 10,3926 / jiem.2009.v2n2.

p337-359 ©© Jiem 2009 - 2 (2): 337-359 - ISSN: 2013-0953

IDEF berdasarkan metode-model simulasi desain dan

pengembangan
Ki-Young Jeong 1, Lei wu2 ,Jae-Dong Hong 3
Program 1Engineering Manajemendi University of Houston-Clear Lake (USA); 2Software
Teknik
di University of Houston-Clear Lake (USA); 3Industrial Rekayasa Teknologi di South Carolina
State
University (USA)
jeongk@uhcl.edu; wuL@uhcl.edu; jdhong@ms.com
Diterima Mei 2009 Diterima Agustus 2009
Abstrak: Tujuan dari penelitian ini adalah untuk memberikan IDEF berdasarkan terpadu
metode-kerangkauntuk model proses bisnis simulasi untuk mengurangi waktu pengembangan
model
dengan meningkatkan komunikasi dan pengetahuan usabilitas selama simulasi proyek. Dalam
kerangka ini, persyaratan simulasi dikumpulkan dengan metode fungsi pemodelan
(IDEF0) dan metode proses pemodelan (IDEF3). Berdasarkan persyaratan ini,
modeldata umum dibangun dengan menggunakan metode IDEF1X. Daridata yang dapat
digunakan kembali
modelini,beberapa model simulasi dihasilkan secara otomatis menggunakandatabase-driven.
model simulasi pendekatan pengembangan Kerangka tersebut diklaim untuk membantu kedua
koleksi kebutuhan dan fase eksperimen selama proyek simulasi dengan
meningkatkan pengetahuan sistem, Model usabilitas, dan pemeliharaan melaluisistematis
penggunaan tiga metode IDEF deskriptif dan fitur daridatabase
teknologirelasional.Sebuah studi kasus fabrikasi semikonduktor kompleks digunakan sebagai
testbed untuk
mengevaluasi dan menggambarkan konsep dan kerangka kerja. Dua yang berbedaperangkat
lunak simulasi
produkyang digunakan untuk mengembangkan dan mengontrol model semikonduktor dariyang
basis pengetahuansama.Studi kasus empiris menunjukkan bahwa kerangka ini bisa
membantumeningkatkan proses proyek simulasi dengan menggunakan model deskriptif berbasis
IDEF dan
teknologi database relasional. Penulis juga menyimpulkan bahwa kerangka ini bisa dengan
mudah
diterapkan pada generasi model analisis lainnya dengan memisahkan logika dariData
desain model simulasi berbasis metodeIDEF dan pengembangan 337
K.-Y. Jeong; L. Wu; J.-D. Hong
doi: 10,3926 / jiem.2009.v2n2.p337-359 ©© Jiem 2009 - 2 (2): 337-359 - ISSN:2013-0953:

Kata kunci IDEF0, IDEF3, IDEF1X, diskrit simulasi kejadian, proses bisnis
1 Pendahuluan
simulasi adalah salah satu alat bantu keputusan yang paling banyak digunakan karena kekuatannya,
fleksibilitas, dan ketahanan. Terutama acara simulasi diskrit (DES) dapat
model dan menganalisis perilaku banyak proses kehidupan nyata sepertibisnis,
proses rantai pasokan, dan proses manufaktur. Namun, seperti Ryan et al.
menunjukkan (2006), pemodelan simulasi sering menjadi pemrogramanberat
tugasdengan esensi dari sistem yang dimodelkan hilang dalamrinci.
kode pemrograman Dengan cara ini, esensi dari sistem ini hanya dapat dilihat
pengembangkode. Hal ini bisa membuat beberapa masalah potensial bagi mereka yang
terlibat dalam proyek simulasi. Sebagai contoh, mungkin membuat informasiserius.
masalahusabilitas Sebuah model simulasi adalah representasi abstrak darinyata
sistemuntuk memecahkan masalah tertentu. Oleh karena itu informasi yang dikumpulkan dan diekstrak
dari sistem nyata harus sistematis diwakili harus dan disimpan untukdi masa depan
digunakan kembalidalam bentuk deskripsi yang sistematis dan format. Hal ini juga dapat menyebabkan
masalahkomunikasi antara pengembang dan pengguna. Biasanya pengguna domain
ahliyang ingin bereksperimen dengan model simulasi untuk memecahkandomain
masalahtertentu.Tugas ini membutuhkan sering perubahan parameter dan modifikasi
model.Namun, kode berat menambah kesulitan untuk pengelolaan yang tepat dariini.
tugas Jika kita mempertimbangkan pengembangan model simulasi sebagai sebuah proyek, dan jika kita memiliki
alat yang sistematis terstruktur untuk mendukung proyek simulasi, kami percaya bahwaini
masalahdapat dikelola. Sheppard (1983) mengusulkan banyak dikutip "40-40-20"
simulasi pengembangan model time aturan yang menyatakan bahwa waktu analis harus
didistribusikan sebagai berikut untuk proyek simulasi yang sukses: (1) 40% untukpersyaratan
tahap pengumpulanseperti perumusan masalah, perencanaan proyek,model
pengembangankonseptual,dan pengumpulan data; (2) 20% untuk model tahap penerjemahan; (3) 40% untuk
fase eksperimentasi seperti verifikasi Model, validasi, implementasi, dan
interpretasi. Oleh karena itu, untuk keberhasilan pelaksanaan setiap proyek simulasi,
sangat penting untuk memiliki pendekatan yang tepat untuk koleksi kebutuhan
dantahapan eksperimen. Oleh karena itu, tulisan ini bermaksud untuk memberikan suatuterpadu
kerangkabagi mereka dua fase dalam proyek simulasi.
Berbasis metode IDEF desain model simulasi dan pengembangan 338
K.-Y. Jeong; L. Wu; J.-D. Hong
doi: 10,3926 / jiem.2009.v2n2.p337-359 ©© Jiem 2009 - 2 (2): 337-359 - ISSN: 2013-0953
Proses metode deskripsi bisa memainkan peran penting dalamsimulasi
fasekoleksi kebutuhan. Meskipun desain banyak proses, analisis dan
pemodelan (DAM) metode yang telah dikembangkan, menggunakan metode ini dalam isolasi -
pendekatan non-metodologis - sering gagal untuk menangkap perilaku sistem kritis
karenakompleksitas dan interaksi komponen dalam sistem.
Pendekatanmetodologis - penggunaan sistematis dari rangkaian metode - memiliki lebih besar
kesempatanuntuk sukses di mewakili perilaku sistem kritis karena dapat menjelaskan
beragam aspek kegiatan DAM seperti informasi, fungsi, danproses
interaksioleh penggunaan sistematis dan terpadu dari metode . IDEF (Integrated
Definition) adalah suite dari metode pemodelan deskriptif di mana beberapa
bahasa pemodelan yang berbeda didefinisikan untuk menggambarkan sistem dariyang
perspektifberbeda.Pertama, karena IDEF adalah suite didefinisikan dengan baik, itu dianggap lebih mudah
untuk menerapkan pendekatan metodologis dengan IDEF Suite bukan dengan yang
sama sekali berbeda dari metode. Kedua karena merupakanpemodelan
metodedeskriptif,itu bisa dengan mudah abstrak dan menangkap esensi dari sistem. Dalamyang
proyek simulasikhas,tim proyek terdiri dari banyak anggota tim sepertisistem,
analis pengembang dan ahli domain. Sistem analis mengumpulkan dan memperbaiki
persyaratan dengan bantuan dari para ahli domain. Ini adalahberulang
proses komunikasidi antara semua anggota. The 'descriptiveness' metode IDEF
bisa membuat proses komunikasi ini lebih mudah dan lebih halus daripadanon
metode deskriptiflainnya.Untuk alasan ini, metode IDEF telah menjadilanjutan.
subjek penelitian
Kategori pertama dari penelitian terkait metode IDEF berusaha untuk membangun sebuahgenerik
model deskriptifdan konseptual menggunakan IDEF suite di domain tertentu (Ang et al,
1994;..Zhang et al, 1996). Kategori lain mengusulkan cara untuk menghasilkan
modelanalisis dari model IDEF tertentu. Sebagai contoh, metode IDEF3
telahdigunakan untuk menghasilkan model simulasi menggunakan software simulasi Saksi (KBSI,
1995) dan menggunakan software Arena (Resenburg et al., 1995). Jeong et al. (2008)
mengembangkan skema untuk mengintegrasikan IDEF3 dengan jaringan antrian terbuka umum di
mana IDEF3 bekerja sebagai repositori pengetahuan. Kategori ketiga digunakan
beberapa metode IDEF dan upaya untuk menggunakan kembali pengetahuan sistem umum di antara
metode IDEF yang berbeda. Misalnya, Lingzhi et al. (1996) mengusulkan skema
untuk mengintegrasikan IDEF1 dengan IDEF0 untuk komputer terpadumanufakturinformasi.
desainsistem Chen et al. (2004) juga mengusulkan skema untuk mengembangkanberdasarkan
ditingkatkan IDEF1 model informasi informasi proses berbasis IDEF0,
IDEF berdasarkan metode-model simulasi desain dan pengembangan 339
K.-Y. Jeong; L. Wu; J.-D. Hong
doi: 10,3926 / jiem.2009.v2n2.p337-359 ©© Jiem 2009 - 2 (2): 337-359 - ISSN: 2013-0953
yang bisa berfungsi sebagai representasi dasar untuk model informasi. Makalah ini
mencakup baik kedua dan kategori ketiga bersama-sama. Ini adalah perpanjangan dari Cho
et al. (1999), KBSI (1995), dan Chen et al. (2004) dalam upaya untuk menyediakan
kerangka kerja terpadu berbasis metode-IDEF desain model simulasi dan
pengembangan untuk membantu proyek simulasi yang sukses.
Gambar 1. "kerangka konseptual pendekatan terpadu berbasis IDEF"
Tahap eksperimen merupakan proses berulang untuk melakukan verifikasi Model,
validasi, pelaksanaan, dan interpretasi yang membutuhkan 40% dari
waktu analis. Proses verifikasi, validasi, dan implementasi
sering memerlukan perubahan kode yang signifikan dan modifikasi model yang. Hal ini juga mungkin
memerlukan beberapa model dengan nilai parameter yang berbeda dan skenario yang beragam.
Oleh karena itu, akan sangat membantu untuk secara otomatis mengembangkan versi beragam simulasi
modeldari basis pengetahuan umum dikembangkan melalui kegiatan DAM.
Meskipunsangat sulit untuk mengembangkan database-driven model simulasi kerja generik
untuk setiap domain, domainmodel simulasi database-driven tertentu
pengembanganlayak dan berguna. Bahkan, Pidd (1992) menunjukkan fakta ini dengan
mengatakan "simulator generik tidak akan sepenuhnya menggantikan program simulasi untuktertentu."
aplikasi Dalam tulisan ini, penulis menyarankan kerangka di mana model simulasi
secara otomatis dihasilkan dari database diperoleh sebagai hasil dari IDEF berbasis
model desain dan pengembangan. Secara khusus, pengetahuan sistem fungsional
ditangkap oleh IDEF0 dan pengetahuan sistem proses ditangkap oleh IDEF3 digunakan
untuk mengembangkan dan memperbaiki pengetahuan model data yang ditangkap oleh IDEF1X. Berdasarkan
berdasarkan metode-IDEF desain model simulasi dan pengembangan 340
K.-Y. Jeong; L. Wu; J.-D. Hong
doi: 10,3926 / jiem.2009.v2n2.p337-359 ©© Jiem 2009 - 2 (2): 337-359 - ISSN: 2013-0953
IDEF1X, model simulasi yang dihasilkan dengansimulasi modeldatabase-driven
pendekatangenerasi(DBSMGA). Dalam kerangka ini, model IDEF1X bekerja sebagai
basis pengetahuan independen perangkat lunak di mana perangkat lunak simulasi yang berbeda bisa
mengakses untuk menghasilkan model menggunakan perpustakaan mereka. Kerangka tersebut dijelaskan dalam
Gambar 1.
Kerangka kerja ini diklaim memiliki beberapa keuntungan atasnon
pendekatanmetodologis:
• Ini memfasilitasi reusability pengetahuan antara metode pemodelan berbeda
yangselama fase pengumpulan persyaratan.
• Hal ini dapat menangkap beragam aspek dari sistem nyata dari perspektif yang berbeda,
yang meningkatkan akurasi representasi.
• Ini meningkatkan model simulasi rawatan sejak logika simulasi
dapatdiubah dalam database sebagai lawan dalam model simulasi.
Namun, perlu dicatat bahwa penulis tidak merasa perlu untuk menggunakanini
kerangka kerjauntuk semua situasi. Sebaliknya, tulisan ini mengklaim bahwa kerangka ini memiliki yang
kesempatanlebih baik untuk memimpin sebuah proyek simulasi yang sukses dengan meningkatkan komunikasi
dan pengetahuan dan model usabilitas. Misalnya, model simulasi dapat
langsung dibangun menggunakan pendekatan drag-and-drop ikon berbasis jika analis memiliki
pengetahuan software simulasi yang cukup. Namun, berdasarkan pengalaman penulis,
ini praktek Model bangunan langsung tanpa pendekatan metodologis sering
menghasilkan model yang salah karena kurangnya komunikasi, tidak tepat Model
abstraksi, dan tidak pantas teknik manajemen Model. Khususnya, dalam
proyek simulasi skala besar, ia cenderung untuk menambahkan lebih banyak kesulitan untuk yang
manajemenproyek simulasitepat.
2 Metode IDEF untuk Pengetahuan Tangkap Proses Bisnis
Menurut Lin et al. (2002), proses bisnis memiliki unsur-unsur berikut:
• Sebuah proses bisnis memiliki pelanggan.
• Sebuah proses bisnis terdiri dari kegiatan yang tujuannya adalah untuk menciptakan
nilai bagi pelanggan.
Berbasis metode IDEF desain model simulasi dan pengembangan 341
K.-Y. Jeong; L. Wu; J.-D. Hong
doi: 10,3926 / jiem.2009.v2n2.p337-359 ©© Jiem 2009 - 2 (2): 337-359 - ISSN: 2013-0953
• Kegiatan yang dilakukan oleh pelaku yang mungkin manusia atau mesin
• Sebuah proses bisnis sering melibatkan unit organisasi yang bertanggung jawab
untuk seluruh proses.
Kami percaya bahwa metode IDEF juga mendukung elemen-elemen. Misalnya, IDEF0
dirancang untuk menangkap 'keputusan' dan 'kegiatan' dari suatu sistem (Mayer et al.,
1995). Keputusan-keputusan dan kegiatan termasuk informasi tentang apa fungsi
sistemmelakukan, kendala apa yang memiliki fungsi, apa yang dibutuhkan untuk
fungsi, dan apa yang input dan output yang bermakna dalam melakukan fungsi-fungsi.
Model IDEF0 diwakili dengan empat persegi panjang dengan empat jenis panah
yang mengelilingi persegi panjang. Sebuah persegi panjang merupakan fungsi atau kegiatan dijelaskan
yangdalam frase verbal, dan panah mewakili (1) "Input" (di sebelah kiri); (2) "Output"
(disebelah kanan); (3) "Control" (di atas); dan (4) "Mekanisme" (di bagian bawah) disebut
(ICOM) dijelaskan dalam frase kata benda untuk menjelaskan perilaku fungsi - lihat
Gambar 2 di bawah ini. Ini juga mendukung dekomposisi hirarkis kegiatan untuk sebuah
abstraksi yang tepat dari sistem. Kami melihat bahwa tigabisnis pertama
elemendapat didukung oleh IDEF0. Misalnya, model yang IDEF0 dapat
dikembangkan dari perspektif pelanggan tertentu dan konteks - elemen pertama.
Kegiatanusaha merupakan bagian dari kegiatan sistem - elemen kedua. Mekanisme
di ICOM termasuk aktor - unsur ketiga.
Control (kata benda)
Fungsi Input
(Frase
Output (kata benda)
yang dimulai dengan
(kata benda) Verb)
Mekanisme (kata benda)
Gambar 2. "fungsi IDEF0 notasi pemodelan".
IDEF3 adalah capture proses dan metode deskripsi dalam konteks tertentu
skenario(Mayer et al., 1995). Proses skema IDEF3 telahsecara luas
diterimasebagai media untuk deskripsi proses di industri (Mo et al., 1998). Seperti yang
terlihat pada Gambar 3, proses skema terdiri dari tiga komponen utama: (1)
"Satuan Of Perilaku" (UOB); (2) "Junction"; (3) "Link".
Berbasis metode IDEF desain model simulasi dan pengembangan 342
K.-Y. Jeong; L. Wu; J.-D. Hong
doi: 10,3926 / jiem.2009.v2n2.p337-359 ©© Jiem 2009 - 2 (2): 337-359 - ISSN: 2013-0953
Nama Keterangan Simbol
Satuan Perilaku (UOB)
IDEF berdasarkan metode-desain model simulasi dan pengembangan 343
K.-Y. Jeong; L. Wu; J.-D. Hong
Menangkap informasi tentang apa yang terjadi di dalam sistem, yang merupakan proses ataukegiatan
namaID
link
Mewakili temporal, logis, kausal, konstruksi alam atau relasional antara UOBs
Persimpangan
Tentukan percabangan logis dari UOBs:
Fan-Out XOR / fan- dalam XOR Fan-Out DAN / Fan-in DAN Fan-Out OR / Fan-in-OR
Gambar 3. "proses IDEF3 skema".
Sebuah UOB menangkap informasi tentang apa yang sedang terjadi dalam sistem untuk mewakili suatu proses
atau kegiatan. Hal ini digambarkan oleh persegi panjang dengan label unik. Persimpangan menyediakan
mekanisme menentukan percabangan logis dari UOBs dan memperkenalkan waktunya -
sementara - dan sequencing dari beberapa proses. Jenis persimpangan termasuk
eksklusifOR dilambangkan dengan "X", sebuah persimpangan penghubung DAN dilambangkan dengan "&", dan
inklusif OR dilambangkan dengan "O". Sejak IDEF3 menggunakan skenario sebagaiorganisasi dasar
strukturuntuk menggambarkan bagaimana sesuatu bekerja, itu bisa dengan mudah masuk dengan tigapertama
elemendari proses bisnis. Ini juga mendukung top-down danbottom-up
pemodelan urutandan dekomposisi hirarkis untuk berbagai tingkat
abstraksi. IDEF1X menghasilkan model data yang mewakili struktur dan
semantik informasi dalam suatu perusahaan atau sistem, yang dikenal sebagaibisnis.
aturan Diagram IDEF1X disempurnakan menjadi tiga tingkatan detail: (1) entity;
tingkathubungan (2) tingkat berdasarkan kunci-; (3) tingkat atribut.bisnis yang beragam
Aturanditentukan sesuai dengan berbagai tingkat detail, danmodel
pengembangandidefinisikan oleh tiga prosedur pemodelan tingkat ini. Gambar 4 menunjukkan
ringkasan dari tiga tingkat ini dengan simbol. Pengguna yang tertarik dianjurkan untuk
membaca (KBSI, 1994) untuk tata bahasa rinci dan simbol grafis untuk
metode IDEF1X.
Lin et al. (2002) juga mengidentifikasi sepuluh konsep penting yang berguna dalam mendefinisikan
proses bisnis,dan kami kreatif digunakan konsep-konsep ini untuk menyelidiki kebugaran
kerangkaterpadu berbasis metode yang diusulkan IDEF untukproses bisnis
desain modelsimulasi dan pengembangan. Hasilnya dirangkum dalam Tabel 1.
Tabel ini menunjukkan semua kecuali satu konsep ditangani dan diwakili olehini.
kerangka
XX
&&
OO
doi: 10,3926 / jiem.2009.v2n2.p337-359 ©© Jiem 2009 - 2 (2): 337-359 - ISSN: 2013-0953
Nama Keterangan Simbol
Satu set hal nyata atau abstrak yang memiliki
1 ) Entitas
atribut umum atau karakteristik. Anggota individu dari set ini disebut sebuah contoh
Identifier- Entitas Independent
IDEF berdasarkan metode-model simulasi desain dan pengembangan 344
K.-Y. Jeong; L. Wu; J.-D. Hong
Sebuah contoh yang dapat diidentifikasi secara unik tanpa menentukan hubungannya dengan entitas lain
Nama Entity
kunci
Atribut
Entitas Identifier- Dependent
Sebuah contoh yang identifikasi tergantung pada nya
hubungan Nama Entity ke entitas lain.
Kunci
Atribut 2) Hubungan Hubungan
antara entitas
Mengidentifikasi Hubungan Connection
Jika sebuah contoh dari seorang anak diidentifikasi oleh hubungannya dengan entitas induk, ini disebut sebagai hubungan
mengidentifikasi. Ini memiliki salah satu kardinalitas berikut (nol, satu atau lebih / satu atau lebih / nol atau satu / persis n / dari n
ke m)

/ //)
Non-Mengidentifikasi Hubungan Connection

(/
PZ n nm
Jika setiap contoh anak entitas dapat diidentifikasi secara unik tanpa mengetahui contoh terkait entitas induk, hal itu disebut
sebagai non-mengidentifikasi hubungan.

/ //)
3) Keys Atribut dari masing-masing entitas Keys Primer Atribut yang unik mengidentifikasi entitas (PK) Alternatif Keys Atribut
yang dapat bekerja sebagai kunci utama (AK) Foreign Keys Atribut bermigrasi dari entitas lain (FK)
Gambar 4. "blok bangunan IDEF1X dan simbol".
Konsep Deskripsi IDEF0 IDEF3 IDEF1X
Kegiatan Tugas, fungsi atau operasi ✓ Perilaku Action, aturan bisnis atau kontrol Mekanisme Sumber Daya ✓ atau lokasi ✓
Relation

(/
PZ n nm
Relation kelas, persimpangan dan link, interaksi, dan dependensi
✓✓
aktor Agen Sosial atau peran Informasi pesan ✓ ✓ obyek Badan diwakili oleh atribut ✓
Kegiatan
diwakili oleh sebagai objek peristiwa atau input / output
✓
Verifikasi dan validasi
model dibangun sebagaimana dimaksud? Model juga merupakan realitas?prosedur Modeling
prosedur khususuntuk membangun sebuah model
✓
Tabel 1. "konsep Bisnis vs . metode IDEF
"padasaat yang sama, ia juga menyarankan intervensi dari pengembang Model dan
pengguna masih diperlukan untuk verifikasi dan validasi Bahkan, penulis tidak mengklaimmanusia.
bahwa proses pengembangan model otomatis sepenuhnya bisa menggantikan
wawasan dan pengetahuan dari - kita bahkan percaya bahwa itu tidak diinginkan.
Sebaliknya, kerangka terpadu ini harus dianggap sebagai bantuan untuk mendukung
manusia dan penilaian mereka.
doi: 10,3926 / jiem.2009.v2n2.p337-359 ©© Jiem 2009 - 2 (2): 337-359 - ISSN: 2013-0953
3 Basis Pengetahuan IDEF1X Data Model untuk Simulasi Model
model data Sebuah IDEF1X harus cukup kuat untuk membuat struktural dan
aspeksemantik dari simulasi dimasukkan dalam model. Salah satu cara untuk mempertimbangkan
aspek semantik dari model simulasi adalah untuk mempelajari ontologi simulasi, dan
mencerminkan hal itu dalam desain model data, karena ontologi memberikan definisi dari
istilah dan hubungan antara mereka. Meskipun beberapaperangkat lunak DES
paketyang tersedia di pasar, mereka memiliki beberapa struktur dasar umum atau
benda, sedangkan struktur yang unik adalah variasi dari struktur umum. Jika
modeldata menggabungkan struktur ini ke dalam desain, bisa digunakan bersama oleh
paket perangkat lunak DES yang berbeda.
Tabel 2 berisi beberapa struktur umum dasar dengan definisi mereka
dalamkonteks simulasi proses bisnis. Perhatikan bahwa terminologi netral,
Generator, Entity, Lokasi, Sumber Daya, Antrian, dan Destroyer digunakan untuk menghindari
mendukung bahasa simulasi tertentu. Misalnya, ED (2001) menggunakan Source,
Produk, Server atau Multiple-Service, Operator, Antrian, dan Sink sementara Flexsim
(2007) menggunakan Sumber, FlowItem, Processor atau Multiprocessor, Operator, dan Sink
bukannya ini terminologi netral.
Nama Definisi
Generator Sebuah struktur yang menciptakan entitas untuk mengisi model
Entity
Sebuah struktur yang mengalir melalui model untuk mewakili pelanggan, pesanan dan item bergerak dalam model.
Lokasi
Struktur yang berinteraksi dengan entitas. Interaksi ini disebut layanan, dan biasanya menunda kemajuan suatu entitas melalui
model.
sumber daya
Berbasis metodeIDEF desain model simulasi dan pengembangan 345
K.-Y. Jeong; L. Wu; J.-D. Hong
Sebuah struktur yang mungkin diperlukan oleh suatu entitas atau lokasi untuk memberikan layanan. Perbedaan antara lokasi dan
sumber daya adalah bahwa lokasi tidak bergerak, dan sumber daya bergerak menuju lokasi ketika diminta.
Antrian
Sebuah struktur yang menyimpan entitas. Antrian menunggu layanan, tidak menerima layanan. Destroyer Sebuah struktur yang
menghancurkan entitas
Tabel 2. "objek simulasi Dasar dan definisi".
Gambar 5 menunjukkan satu pemetaan mungkin antara model data IDEF1X dan
sesuai struktur simulasi netral (benda). Model data memiliki beberapa
- satu atau lebih, dilambangkan dengan P - Order / Produk, Kantor / Toko, Karyawan / Peralatan
atau Operator, dan benda-benda Storage / Queue. Masing-masing yang dipetakan ke Entity,
Lokasi, Sumber Daya dan objek Antrian, masing-masing, dalam model simulasi. Perhatikan
bahwa karena Generator dan Destroyer adalah obyek murni fungsional untukbadan
pembuatandan menghancurkan masing-masing, mereka tidak perlu dimasukkan dalam model data.
doi: 10,3926 / jiem.2009.v2n2.p337-359 ©© Jiem 2009 - 2 (2): 337-359 - ISSN: 2013-0953
Setelah model data dibangun dengan pertimbangan struktur simulasi, database
dapat dengan mudah dibuat dari yang beberapa model simulasi bisa secara otomatis
dikembangkan.
P Generator
P
P
P
IDEF0 & IDEF3 Model
P
Karyawan / Peralatan atau Operator
P
Storage / Antrian
P Destroyer
Gambar 5. "Simulasi dan pemetaan model data".
Dari perspektif simulasi, model data ciriyang diperlukan
fungsionalitassimulasi perpustakaan. Oleh karena itu jika mereka fungsi tidak
didukung oleh perangkat lunak khusus simulasi sasaran, mereka fungsi harus
dikembangkan untuk membuat pengembangan model simulasi database-driven lebih mudah.
4 database-DrivenSimulasi Model Pengembangan
softwareKebanyakan simulasi memberikan script language sendiri denganterstruktur query
bahasa(SQL) dan kemampuan Buka Database Connectivity (ODBC). Oleh karena itu,
antarmukaantara sistem simulasi dan manajemen database (DBMS)
menjadi lebih mudah tetapi masih memerlukan beberapa upaya coding. Dalam penelitian ini, baik Flexsim
dan perpustakaan ED diadopsi untuk melaksanakan DBSMGA karena kedua menyediakan
disesuaikan kemampuan pengembangan perpustakaan Berorientasi Objek di sampingkaya.
perpustakaan standar Pengembangan kemampuan perpustakaan disesuaikan didukung
menggunakan Flexscript (bahasa skrip Flexsim) atau C / C ++ dalam kasus Flexsim dan 4D
Script dalam kasus ED. Setiap objek (perpustakaan) terdiri dari satu set atribut
(karakteristik) dan metode (fungsi) yang dapat diimplementasikan ketika sebuah
event handler yang terkait diaktifkan di perpustakaan. Dalam kasus Flexsim, beberapa
contoh khas dari event yang OnReset - dipicu ketika pengguna mengklik
IDEF berdasarkan metode-desain model simulasi dan pengembangan 346
K.-Y. Jeong; L. Wu; J.-D. Hong
OrderProduk/
Office/Toko
Entity
Sumberdaya
Antrian
P
Lokasi
P
P IDEF1X
Simulasi Data Model
Model
doi: 10,3926 / jiem.2009.v2n2.p337-359 ©© Jiem 2009 - 2 (2): 337-359 - ISSN: 2013 -0953
tombol reset, onmessage - dipicu ketika objek menerima pesan dari
benda-benda lain, OnEntry - dipicu ketika entitas memasuki objek saat, dan
OnExit - dipicu ketika entitas daun dari objek saat. Semua sifat suatu
darikelas mewarisi ke contoh kelas ketika mereka diciptakan dalam model.
Dengan menggabungkan standar perpustakaan dan perpustakaan disesuaikan, pengguna dapat mengembangkan
perangkat lunak mereka sendiri dan / atau domain-spesifik khusus pengguna simulasi, yang membuat
pemetaan dari model data untuk simulasi lebih mudah.
Dalam studi kasus yang akan dibahas kemudian, pertama kami mengembangkan model Flexsim. Sebuah
perpustakaan disesuaikan bernama "simulasi-generator" dikembangkan untuk menghasilkan
model simulasi dari database. Catatan bahwa ini sesuai dengan Simulasi
Model Generator pada Gambar 1. Semua kode ditulis dalam acara Pengguna handler
dantotal baris kode kurang dari 250 termasuk semua user-interface dan layar
perhiasan.
NO Kode Deskripsi
1
IDEF berdasarkan metode-desain model simulasi dan pengembangan 347
K.-Y. Jeong; L. Wu; J.-D. Hong
Terhubung ke Peralatan tabel database melalui DSN pasti pada MyDSN dan melakukan pernyataan SQL.
2
dbopen ( "MyDSN", "* pilih dari Equipment", 0);
Menyimpan jumlah total catatan dalam database di sel (1,1) di InfoTb. "Dbgetnumbrows ()" adalah kata kunci untuk menghitung
jumlah record dalam database saat ini.
3
settablenum ( "InfoTb", 1,1, baris dbgetnum ());
Ulangi fungsi yang didefinisikan di {} dbgetnumrows () kali.
4
for (int i = 1; i <= dbgetnumrows (); i ++)
{Menciptakansebuah instance dari kelas SHOP-Equipment (perpustakaan) dan tempat-tempat itu dalam model. Perhatikan bahwa
toko-peralatan merupakan perpustakaan disesuaikan.
5
CreateInstance (node ( "/ toko-Equipment", perpustakaan ()), model ());
Mengubah nama sebuah contoh menggunakan nama disimpan di database Equipment. dbgettablecell (i, 1) membaca data string
disimpan pada baris ke-i dan 1 kolom
6
setName (terakhir (model ()), dbgettablecel l (i, 1));
CreateInstance (node ( "/
 toko-Menciptakansebuah instance dari kelas SHOP-Buffer Buffer", perpustakaan ()),
model ());
(perpustakaan) dan tempat-tempat itu dalam model. Ini berfungsi sebagai antrian untuk peralatan. setName (terakhir (model ()),
concat (dbget tablecell (i, 1), "Q"));
Tentukan nama antrian di depan peralatan. Concat menghubungkan beberapa string.
7
Hubungkan port output dari antrian ke port input dari peralatan 8 Set_Equipment_Attributes, mengatur peralatan atribut (fungsi
user-defined)
9
contextdragconnection (prev (terakhir (mo del ()), lalu (model ()), "A") ;
Set_Queue_Attributes}; atribut set antrian (pengguna didefinisikan fungsi) dan
akhiruntuk pernyataan 10 Dbclose Tutup perangkat database
();.Tabel 3. "partial pseudo code dalam model simulasi generator"
Tabel 3 menunjukkan parsial pseudo-kode untuk membuat contoh dari perpustakaan objek dari
meja Peralatan untuk menjelaskan cara membaca database melalui ODBC (jalur 1 dan
10) dan membuat objek (contoh perpustakaan) dan menghubungkan mereka dengan menggunakan port
doi: 10,3926 / jiem.2009.v2n2.p337-359 ©© Jiem 2009 - 2 (2): 337-359 - ISSN: 2013-0953
(garis 2-9) satu catatan dalam tabel equipment merupakan salah satu contoh mesin yangMTBF.
bidang terdiri dari (ID peralatan, peralatan Nama, Kapasitas, , MTTR dll).
Garis 8 dan 9 panggil ditetapkan pengguna fungsi untuk mendefinisikan atribut semua
contoh. Hal ini penting untuk mengenali bahwa model adalah seperangkat contoh dari semua
kelas (atau benda) yang terletak di perpustakaan. Kelas-kelas ini dapat diberikan oleh
vendor atau baru dibuat oleh pengguna. Dalam penelitian ini, "TOKO-peralatan" objek
dan "TOKO-Buffer" objek diciptakan di perpustakaan oleh penulis menggunakan Flexscript
untukmemudahkan pemetaan dari model data untuk Flexsim.
5 Pedoman Pengetahuan Reusability antara metode IDEF
Mengembangkan model deskriptif dengan menggunakan metode IDEF membutuhkan umpan balik untuk
memperoleh konsensus dan konfirmasi dari ahli domain. Mengingat fakta
bahwa setiap IDEF menggunakan bahasa pemodelan yang berbeda untuk menangkap perspektif yang berbeda
dari sistem nyata, reuse pengetahuan ditangkap antara metode IDEF yang berbeda
telah terbukti sulit untuk menggeneralisasi. Namun, pentingnya penggunaan kembali pengetahuan
adalah penting - ingat 40-40-20 aturan, dan berapa banyak waktu yang diperlukan untuk
pengumpulan persyaratan dan eksperimen? Berdasarkan pengalaman kami,
panduanberikut tampaknya berguna dalam penggunaan kembali pengetahuan di antara IDEF0, IDEF3
dan IDEF1X. Seperti yang dinyatakan sebelumnya, IDEF0 merupakan perilaku fungsional dari suatu
sistem melalui empat jenis data (ICOM) dan serangkaian kegiatan.
DataICOM bisa informasi, benda atau apapun yang dijelaskan dalam frase kata benda.
Oleh karena itu, beberapa data IDEF0 dapat diwakili sebagai objek atau atribut
dalammodel IDEF1X. Meskipun IDEF0 tidak dirancang untuk menangkap sementara
hubunganantara kegiatan, beberapa aspek fungsional dari sistem mungkin termasuk
hubungan sementara antara kegiatan. Oleh karena itu, jika hal ini terjadi, beberapa kegiatan
di IDEF0 dapat juga diwakili dalam diagram IDEF3. Pedoman direkomendasikan
untuk usabilitas pengetahuan di antara metode IDEF meliputi:
• Sebuah pemodelan IDEF0 dianjurkan pertama karena memberikansistem secara
pengetahuan tingkatkeseluruhan.
• Lalu, suatu pemodelan IDEF3 dianjurkan jika informasi waktu antara
kegiatan yang dibutuhkan. Perhatikan bahwa beberapa deskripsi di UOBs dapat memberikan
petunjukuntuk atribut dan tujuan dalam model IDEF1X.
Berbasis metode IDEF desain model simulasi dan pengembangan 348
K.-Y. Jeong; L. Wu; J.-D. Hong
doi: 10,3926 / jiem.2009.v2n2.p337-359 ©© Jiem 2009 - 2 (2): 337-359 - ISSN: 2013-0953
• Dengan bantuan IDEF0 dan IDEF3, model IDEF1X rinci dapat
dikembangkan.
• A "Mekanisme" di IDEF0 dapat dengan mudah berubah menjadi obyek dalam IDEF1X karena
"Mekanisme" sering kali berisi sumber - benda khas dalam
model IDEF1X.
• The "Kendala" di IDEF0 dapat memberikan objek logis dalam IDEF1X karena ini
"Kendala" sering merupakan aturan bisnis dari suatu sistem.
• Periksa apakah ada benda dalam kalimat verbal (fungsi) dalam model IDEF0
yang perlu diterjemahkan ke dalam atribut atau objek dalam model IFED1X.
Sejak frase verbal yang menjelaskan perilaku fungsi, beberapa kata benda
yang digunakan dalam frase dapat menyampaikan informasi yang berarti untuk model data.
6 Studi Kasus
Makalah ini mempekerjakan studi kasus dari proses fabrikasi semikonduktor
untukmenggambarkan konsep dan kerangka dinyatakan dalam tulisan ini. Model data IDEF1X
dibuat untuk studi kasus ini juga bisa berlaku untuk banyakproses bisnis kehidupan
masalahnyata.Studi kasus ini awalnya berasal dari Deuermeyer et al. (1993), dan
itudiadopsi di sini karena melibatkan proses bisnis kehidupan nyata sangat kompleks.ini
Kasusmenganalisa 172-langkah semikonduktor wafer proses fabrikasi dengan enamkerja--
bidang BERSIH, STRIP, IMPLAN, DEPOSIT, LITHO dan ETCH. Daerah ini melakukan
wafer pembersihan, pengupasan, implantasi ion, deposisi, litografi danetsa,
operasi masing-masing. Setiap karya-daerah terdiri dari mesin dan operator. Seorang
operator diperlukan untuk wafer-bongkar muat operasi di setiap mesin.
Selain itu, ketika berbagai wafer-banyak dimuat, set up diperlukan.
Operasiyang berbeda mungkin memiliki waktu pengolahan yang berbeda meskipun mereka
tampil di mesin yang sama. Setiap jenis produk dapat memiliki routing yang sendiri sebagai
ditoko pekerjaan umum. Namun, sebagian besar urutan operasi serupa seluruhproduk
dijenisdalam proses fabrikasi wafer. Sebagai contoh, semua wafer mulaimereka
operasidari daerah bersih dan selesai pada daerah DEPOSIT setelah beberapamenengah.
operasi Salah satu urutan operasi khas adalah membersihkan, litho, implantasi,
striping, deposisi, etsa, striping dan deposisi lagi. The important shop
information such as the number of machines and operators, MTBF (mean time
between failure), and MTTR (mean time to repair) is summarized in Table 4. Note
IDEF method-based simulation model design and development 349
K.-Y. Jeong; L. Wu; J.-D. Hong
doi:10.3926/jiem.2009.v2n2.p337-359 ©© JIEM, 2009 – 2(2): 337-359 - ISSN: 2013-0953
that both MTBF and MTTR are exponentially distributed, denoted by expo(). Two
virtual areas were added to indicate the starting (START) and ending (END) of the
process. Note that the second column consists of 8-tuples and each of which
denotes the number of visits to each work-area. This 8-tuples are arranged in the
orders of START, CLEAN, STRIP, IMPLANT, DEPOSIT, LITHO, ETCH and END. It is
assumed that this shop is operating for 24 hours with 3 eight-hour shifts due to
high capital equipment. The main performance measure for this shop is the system
cycle time.
Work Area
IDEF method-based simulation model design and development 350
K.-Y. Jeong; L. Wu; J.-D. Hong
MTBF (hrs) MTTR (hrs)
START (0, 1, 0, 0, 0, 0, 0, 0) expo(42.18) expo(2.2) CLEAN (0, 3, 0, 0, 15,1,0, 0) 4 1 ∞ 0 STRIP (0, 2, 0, 0, 1,11,9, 0) 3 1
expo(55.18) expo(12.86) IMPLANT (0, 1, 6, 1, 0, 0, 0, 0) 5 1 expo(75.93) expo(3.88) DEPOSIT (0, 2, 0, 0, 8, 9, 8, 1) 20 3
expo(100) expo(2.78) LITHO (0, 5, 12, 7, 2, 33, 6, 0) 33 4 expo(62.91) expo(9.35)
ETCH (0, 5, 5, 0, 3, 10, 6, 0) 28 3
END (0, 0, 0, 0, 0, 0, 0, 0)
Table 4. “Facility data by work-area”.
Based on the description above, we attempt to build an IDEF0 model according to
the first guideline in the previous section. Each area could be modeled as an
activity in IDEF0, and these activities are connected with each other through
wafers. For example, Figure 6 shows part of the IDEF0 model in the wafer strip
area with its decomposition to show the wafer strip process in detail. For any
machine, when a batch of wafers (job) arrives, the operators are responsible for
selecting the proper job according to the pre-determined dispatching rule that
decides the job processing sequence at the machine. Once a job is selected, it is
loaded onto a machine, and the set up occurs if the job's lot number is different
from that of the previous job. Once it finishes its operation, the wafers are
unloaded and are ready to move to the next destination. The wafer changes its
status over time as seen in the figure. For each area, these wafer processes are
repeated.
# of Visits to Work-
No. of
No. of Area
Machines
Operators
doi:10.3926/jiem.2009.v2n2.p337-359 ©© JIEM, 2009 – 2(2): 337-359 - ISSN: 2013-0953
Dispatching Rule
Available
selected job
Jobs
Select a Job to Operate
Load a Job to a Machine
Set Up a Machine
Unload a Job
Figure 6. “Function model of a fabrication process in strip area”.
Next, according to the second guideline, we tried to consider building an IDEF3
process model. All 172 steps are needed to be represented by IDEF3 model. In this
case, the IDEF3 model is same as the process plan of a wafer fabrication, whose
routing was already depicted in Deuermeyer et al. (1993). Hence, it was not
repeated here. According to the fourth guideline, both an operator and a machine –
mechanism – are considered as important objects, and they are incorporated into
the IDEF1X data model as an object. According to the fifth guideline, the constraint
information, Dispatching Rule, is also captured within the data model since it is
considered as an important factor affecting the cycle time from the shop scheduling
perspective. The same is true for the lot size (Transfer Batch Size) constraint
information. It is also observed that the several functions are controlled by a
IDEF method-based simulation model design and development 351
K.-Y. Jeong; L. Wu; J.-D. Hong
loaded job
finished job
unloaded job
Operator Machine
Machine Operation Recipe
Lot No identity
WIP
Perform an Operation
Transfer Batch Size
doi:10.3926/jiem.2009.v2n2.p337-359 ©© JIEM, 2009 – 2(2): 337-359 - ISSN: 2013-0953
constraint called Machine Operation Recipe, which may contain the operation
sequence information for each product.
With the help of IDEF0 model and the problem descriptions, the IDEF1X model is
defined as in Figure 7. Based on above discussions associated with the IDEF0
model, the Equipment, Product, Operator and DispatchRule are first defined as an
independent object (entity) with keys and attributes. For example, each equipment
needs capacity, MTBF, MTTR, setup time and run time, WorkingShift, Overtime,
BufferSize and Dispatching_ID information. The BufferSize defines the size of
buffer in front of an equipment holding parts awaiting processing, and the
Dispatching_ID is the set of rules defining the sequence of jobs in the queue.
Typically, it follows FIFO – First-In-First Out. In this case study, the queue object
represented in Table 2 is not handled as a separate object since all queues in front
of each piece of equipment are considered as infinite.
Equipment
Product
Operator
Equipment_ID
Product_ID
Operator_ID
Name
Name
Desc Capacity
Demand
Capacity MTBF
LotSize
SkillCode MTTR
Quantity in Parent
WorkingShift SetupTime
Parent ID
OverTime RunTime WorkingShift OverTime
P BufferSize Dispatching_ID (FK)
Product_ID (FK) Equipment_ID (FK) Operator_ID (FK)
EquipSetupTime EquipRunTime
DispatchRule
LaborSetupTime LaborRunTime Dispatching_ID
Operation_Code (AK)
Desc
Desc
Figure 7. “IDEF1X data model for case study”.
The Product object can represent a bill-of-material (BOM) information through
Quantity in Parent and Parent ID attributes. The demand and LotSize are attributes
that affect the cycle time. The Operation object is defined as a dependent object
since it can be uniquely identified only through Equipment, Product and Operator
objects. Hence, the relationship between these three objects and an Operation is
an identifying connection with one-to-many (one or more) cardinality. However,
the relationship between DispatchingRule and Equipment is a non-identifying with
one-to-many (at least one) cardinality since DispatchRule_ID is used as a non-
primary foreign key in the Equipment.
IDEF method-based simulation model design and development 352
K.-Y. Jeong; L. Wu; J.-D. Hong
Operation
P
Routing
P
Routing_ID P
Product_ID (FK) P
Operation_Code_From Operation_Code_To Percentage
doi:10.3926/jiem.2009.v2n2.p337-359 ©© JIEM, 2009 – 2(2): 337-359 - ISSN: 2013-0953
It is important to understand the difference between the Operation and the Routing
object. The Operation contains all operation information that describes “who
(operator) handles what products with what machines for what time”, and the
Operation_Code can be used as an alternative primary key. The Routing object is
created for simulation model generation to describe the sequence of operations for
each product using the information in an Operation object. For each product type
(non-primary FK), the source operation code (OperationCode_From) and the
destination operation code (OperationCode_To) is described with its corresponding
routing probability (Percentage) to support the probabilistic routing view. The
Routing object provides the sequence of operations for each product type while
these operations are characterized by the Operation object. The prototype data
model in Figure 7 was translated into the corresponding MS-ACCESSTM database
using the SmartERTM case tool developed by KBSI (1994). Figure 8 shows a
snapshot of the Flexsim simulation model generated from the data model in Figure
7 using the codes in “simulation-generator” library whose partial pseudo-codes are
represented in Table 3.
Figure 8. “A snapshot of Flexsim model from database”.
In this figure, each of six work-areas is described in bold while the name of an
object is represented in a regular letter. When multiple Operators are involved, all
operators are directly connected to the Dispatcher object which is directly
controlled by a Processor object. Figure 9 shows that of the ED simulation model
from the same data model. The library object in ED is called an atom. The queue
atom is connected to the operation atom, which is connected to the routing atom
that connects the work-areas. The operator control atom (OP CONTROL) is
connected to both the operator atom and the operation atom. The first atom
IDEF method-based simulation model design and development 353
K.-Y. Jeong; L. Wu; J.-D. Hong
doi:10.3926/jiem.2009.v2n2.p337-359 ©© JIEM, 2009 – 2(2): 337-359 - ISSN: 2013-0953
denoted by “1” represents a product atom corresponding to the Product object in
Figure 7. The queue atom denoted by “2” has infinite capacity, which corresponds
to a Buffer object. The operation atom denoted by “3” contains all equipment
information such as MTBF and MTTR as its attributes, and it also includes all sub-
operations such as loading, set up, cleaning operation and unloading operation.
1. PRODUCT 2. QUEUE 3. OPERATION 4. OPERATOR 5. ROUTING 6. OP CONTROL
Figure 9. “A Snapshot of ED model from database”.
When a sub-operation requires an operator, the atom performing the operation
(ie cleaning atom) sends an operator-request-message (ORM) to a corresponding
operator control atom (OP CONTROL). The operator control atom matches an ORM
to an available operator, and it sends available operator(s) to the requesting atom.
If there is no available operator for that ORM, it has to wait at the internal message
queue inside an operator control atom. Once the (sub) operation finishes, the
operator is released from the requesting atom and it becomes available again. All
channels are connected using the information in the Routing object, and sub-
operation information in an operation atom comes from the Operation object in
Figure 7. The operator atom corresponds to the Operator object.
This model was executed with the data in Table 4 for 5 times to filter variation,
considered as the first alternative (ALT1). Each run has 60,000 simulation hours
after 10,000 hours warm up period. Since the sum of the three operators'
utilization in CLEAN, STRIP and IMPLANT was around 80 %, we created two other
alternatives where these three areas have two shared operators (ALT2) and one
shared operator (ALT3). The corresponding models were quickly generated again
IDEF method-based simulation model design and development 354
K.-Y. Jeong; L. Wu; J.-D. Hong
CLEAN
STRIP
IMPLANT
DEPOSIT
LITHO
ETCH
doi:10.3926/jiem.2009.v2n2.p337-359 ©© JIEM, 2009 – 2(2): 337-359 - ISSN: 2013-0953
from the database by changing the “Operator_ID” in the Operation table without
modifying any logic in Flexsim environment for different scenarios. The average
cycle time and throughput (number of units produced per day) were compared and
displayed in Figure 10 where the bar shows the average cycle time and the line
represents the throughput. As seen in the figure, the performance of the second
alternative (ALT2) is almost identical to that of the first alternative (ALT1) even
with less number of operators, and both outperform the third alternative (ALT3).
160
2.45
0
ALT1 ALT2 ALT3
Figure 10. “Alternative comparison”.
Through this case study, we showed that the IDEF method-based integrated
framework could help improve the process of a simulation project by using IDEF-
based descriptive models to capture requirements and to perform the
experimentation. The IDEF1X-based data model supported by IDEF0 and IDEF3
could reduce the time and effort for simulation model development and
maintenance. Before closing this section, it should be recognized again that the
DBSMGA does not depend on any specific simulation software. Any simulation
software supporting the ODBC and SQL capabilities could be used. If the software
has the capability to customize the standard library, it could also reduce the effort
required to map the data model into the simulation model.
7 Discussion and Conclusion
In this paper, the integrated framework of IDEF method-based simulation model
design and development was provided for a business process. In this framework,
the systematic use of IDEF0 and IDEF3 for business processes was proposed to
help the requirement collection phase in a simulation project. From this systematic
use of both descriptive models, the IDEF1X-based data model was created and
became a knowledge base from which multiple simulation models could be
developed, which could save time and effort in the experimentation phase in a
IDEF method-based simulation model design and development 355
K.-Y. Jeong; L. Wu; J.-D. Hong
141.63 140
2.40 2.40
2.40 120
100
2.35
80
avg cycle time (day)
2.30
60
34.21 throughput 40
34.72
2.24
2.25
20
2.20
2.15
doi:10.3926/jiem.2009.v2n2.p337-359 ©© JIEM, 2009 – 2(2): 337-359 - ISSN: 2013-0953
simulation project. A case study in a semiconductor manufacturer was conducted
to show the feasibility of this framework where both Flexsim model and ED model
were generated. This paper also discussed the guidelines to reuse the captured
system knowledge among IDEF0, IDEF3 and IDEF1X.
The advantages of this integrated framework are to improve design knowledge
reusability among IDEF0, IDEF3 and IDEF1X. It could also significantly reduce
simulation model development and maintenance effort. By combining both IDEF
methods and the database technologies together, this research significantly
improved the previous IDEF based researches in that this framework provided a
specific, systematic way to implement and execute the previous IDEF based
modeling and design works. Many practitioners and simulation developers have
been using the icon-based graphic user interface, and they should be familiar with
all icons to develop and use the simulation models – This naturally leads to more
focus on the model development phase without the 'descriptiveness' for better
communication. However, the framework used here could change this game rule.
The use of IDEF methods leads to more focus on the requirement collection phase
of the simulation project. Also by using database as a knowledge base, this
framework eliminated the dependence on the specific simulation software, and
increased the efficiency in the experimentation phase of a simulation project.
Authors believe that the results will significantly contribute to the successful use of
simulation in the business process area where requirement collection is considered
most difficult but important. Another direct advantage of this framework is that this
could be applied to any analytical model as long as that model supports the
database technology by separating the logic from the data.
The result of this study could provide many new ideas and suggestions to both
practitioners and researchers. We summarized these into two categories: IDEF
method-based modeling category and the database-based model generation
category. Regarding the first category, it would be very useful to automate the
knowledge conversion mechanism among IDEF methods to support human
judgment and communication during the large scale simulation project. Also
although we have provided many rules and insights for this conversion, more
research is expected to enrich these lists in a specific domain and/or generic
domain. In addition to the IDEF methods, the unified modeling language (UML)
could also be considered for this DAM activities since it also supports the diverse
modeling approaches from different perspectives. Designing more suitable data
IDEF method-based simulation model design and development 356
K.-Y. Jeong; L. Wu; J.-D. Hong
doi:10.3926/jiem.2009.v2n2.p337-359 ©© JIEM, 2009 – 2(2): 337-359 - ISSN: 2013-0953
model and/or database model could be another direct research area in this
category since there may be an optimal data model in a specific domain. In the
second category, the direct research area includes the development of an
integrated simulation model generator through which the same knowledge in the
database is transformed into software specific simulation models. In this way, the
knowledge reusability will be maximized among simulation software products. Also,
integrating all these – both descriptive modeling methods and the database model
– within single platform could also be considered as another promising future
research area.
References
Ang, CL, Luo, M., & Gay, RKL (1994). Development of a knowledge-based
manufacturing modeling system based on IDEF0 for the metal-cutting industry.
International Journal of Economics, 34(3), 267 – 281.
Chen, P., Caiyun, W., Tiong, R., Seng, KT, & Qizhen, Y. (2004). Augmented
IDEF1-based process-oriented information modeling. Automation in Construction,
13(6), 735 - 750.
Cho, H., & Lee, I. (1999). Integrated framework of IDEF modeling methods for
structured design of shop floor control systems. International Journal of Computer
Integrated Manufacturing, 12(2), 113-128.
Deuermeyer, BL, Curry, GL, & Feldman, RM (1993). An automatic modeling
approach to the strategic analysis of semiconductor fabrication facilities.
Production and Operation Management, 2(3), 195-220.
Enterprise Dynamics. (2001). Reference Guide 4Dscript. Maarssen, The
Netherlands.
Flexsim. (2007). Flexsim Simulation Software User Guide Version 4.0, Flexsim
Software Products, Inc.
Jeong, KY, Cho, HB, & Phillips, DT (2008). Integration of queuing network
and IDEF3 for business process analysis. Business Process Management Journal,
14(4), 471-482.
IDEF method-based simulation model design and development 357
K.-Y. Jeong; L. Wu; J.-D. Hong
doi:10.3926/jiem.2009.v2n2.p337-359 ©© JIEM, 2009 – 2(2): 337-359 - ISSN: 2013-0953
KBSI. (1994). SmartERTM user's manual and reference guide Ver. 2.0, Texas,
College Station, Knowledge Based Systems.
KBSI. (1995). ProSimTM Automatic process modelling for Windows: user's manual
and reference guide ver. 2.1. College Station, TX, Knowledge Based Systems.
Lin, FR, Yang, MC, & Pai, YH (2002). A generic structure for business process
modeling. Business Process Management Journal, 8(1), 19 – 41.
Lingzhi, L., Leong, AC, & Gay, RKL (1996). Integration of information model
(IDEF1) with function model (IDEF0) for CIM information system design. Expert
Systems With Applications, 10(3⁄4), 373 - 380.
Mayer, RJ, Benjamin, PC, Caraway, BE, & Painter, M. (1995). A framework
and a suite of methods for business process reengineering, in Grove, V. and
Kettinger, WJ (Ed.), Business Process Change: Reengineering Concepts,
Methods and Technologies, (pp. 245 - 290). London: Idea Group Publishing.
Mo, JOT, & Menzel, C., P. (1998). An Integrated Process Model Driven
Knowledge Based System for Remote Customer Support. Computers in Industry,
37(3), 171-183.
Pidd, M. (1992). Guidelines for the design of data driven generic simulators for
specific domains. Simulation, 59(4), 237 – 243.
Resenburg, AV, & Zwemstra, N. (1995). Implementing IDEF techniques as
simulation modelling specifications. Computers and industrial engineering, 29(1-4),
467-471.
Ryan, J., & Heavey, C. (2006). Process modeling for simulation. Computers in
Industry, 57(5), 437-450.
Sheppard, S. (1983). Applying software engineering to simulation. Simulation
Practice and Theory, 10(1), 13-19.
Zhang, J., Chuah, B., Cheung, E., & Deng, Z. (1996). Information modeling for
manufacturing systems: A case study. Robotics & Computer-Integrated
Manufacturing, 12(3), 217-225.
IDEF method-based simulation model design and development 358
K.-Y. Jeong; L. Wu; J.-D. Hong
doi:10.3926/jiem.2009.v2n2.p337-359 ©© JIEM, 2009 – 2(2): 337-359 - ISSN: 2013-0953
©© Journal of Industrial Engineering and Management, 2009 (www.jiem.org)
Article's contents are provided on a Attribution-Non Commercial 3.0 Creative commons license. Readers are allowed
to copy, distribute and communicate article's contents, provided the author's and Journal of Industrial Engineering
and Management's names are included. It must not be used for commercial purposes. To see the complete license
contents, please visit http://creativecommons.org/licenses/by-nc/3.0/.
IDEF method-based simulation model design and development 359
K.-Y. Jeong; L. Wu; J.-D. Hong