Simulasi vs Emulasi dalam Otomasi: Apa Bedanya?

By Mirko Peters · 2026-11-11

Simulasi vs emulasi dalam otomasi: simulasi memodelkan cara sebuah sistem berperilaku, sedangkan emulasi menggantikan komponen nyata dan berjalan secara real time. Lihat kapan masing-masing digunakan.

Automatically translated with AI from the original post. Read the English original

Dalam otomasi, simulasi adalah model yang meniru cara sebuah sistem berperilaku, sering kali lebih cepat dari real time, untuk menjajaki berbagai opsi. Emulasi menggantikan sebagian sistem nyata dengan model, atau meniru sebuah perangkat, sehingga mitra nyatanya bekerja dengannya seolah-olah terhubung ke sistem yang sebenarnya, dan berjalan secara real time. Panduan ini ditujukan bagi manajer excellence operasional yang membaca penawaran dan rencana proyek yang mencampuradukkan kedua istilah tersebut, misalnya dalam virtual commissioning. Anda akan mempelajari definisinya, kegunaan masing-masing, bagaimana software dan hardware in the loop berperan, serta contoh kerja dengan waktu eksekusi.

Poin Penting

• Simulasi memodelkan cara sebuah sistem berperilaku dan dapat berjalan lebih cepat dari real time; emulasi menggantikan sebagian sistem nyata dengan model, atau meniru sebuah perangkat, dan berjalan secara real time.
• Gunakan simulasi untuk menjajaki opsi desain, tata letak, kapasitas, dan strategi kontrol; gunakan emulasi untuk menguji logika kontrol terhadap model plant dan untuk melatih orang.
• Emulasi tidak dapat dipercepat, karena timer kontrol dan komunikasi bergantung pada real time, sehingga emulasi kurang cocok untuk menjalankan banyak skenario.
• Software in the loop dan hardware in the loop adalah konfigurasi emulasi: kode kontrol nyata atau pengontrol nyata bekerja dengan plant yang disimulasikan.
• Kedua istilah ini sering digunakan secara longgar, jadi tanyakan apa yang berjalan secara real time, apa yang nyata, dan apa yang dimodelkan sebelum Anda menerima penawaran atau spesifikasi.

Simulasi vs emulasi: jawaban singkatnya

Kedua istilah ini saling tumpang tindih, dan literatur pun mengakuinya. Emulasi dan simulasi sama-sama menciptakan lingkungan virtual tempat Anda dapat melakukan debug dan pengujian sebelum menyentuh perangkat keras fisik. Laporan lapangan tentang simulasi jaringan industri oleh Duque Anton dan rekan penulis, yang tersedia di arXiv, menyebutkan bahwa simulasi bertujuan meniru keadaan sebuah sistem, sedangkan emulasi bertujuan mereproduksi perilakunya. Para penulis mencatat bahwa kedua kata ini sering dipakai secara bergantian, dan mereka menggunakan "simulasi" secara umum karena banyak alat dapat melakukan keduanya.

Definisi yang lebih praktis datang dari Ian McGregor dalam makalah untuk 2002 Winter Simulation Conference. Ia mendefinisikan model emulasi sebagai model yang sebagian fungsinya dijalankan oleh bagian dari sistem nyata, dan sebaliknya juga berlaku: sebagian sistem nyata digantikan oleh model. McGregor bekerja untuk perusahaan yang menjual alat emulasi, jadi klaimnya perlu dibaca dengan pertimbangan tersebut. Definisinya sendiri mudah diperiksa terhadap proyek mana pun.

Secara sederhana, perbedaan praktis dalam otomasi adalah sebagai berikut:

• Simulasi adalah model dari keseluruhan sistem yang dijalankan secara mandiri. Anda mengubah input dan melihat apa yang terjadi, dan Anda dapat menjalankannya dengan cepat. Anda dapat mensimulasikan permintaan, henti, dan penugasan staf, serta membuat prototipe tata letak dalam model sebelum apa pun dibangun.
• Emulasi menghubungkan sesuatu yang nyata dengan sebuah model. Bagian yang nyata bisa berupa program pengendali, sebuah controller, atau panel operator, dan model memerankan mesin atau pabrik di sekitarnya. Karena ada bagian yang nyata, setiap proses berjalan membutuhkan waktu yang nyata.

Perbedaan yang sama juga tampak pada alatnya, di mana perbedaan antara emulator dan simulator terletak pada apa yang mereka replikasi. Simulator dapat mensimulasikan pabrik atau logika program controller dalam sebuah model. Emulator berupaya meniru fungsi controller yang nyata hingga ke perilaku CPU dan komunikasinya, sehingga kode yang sebenarnya dapat dijalankan di atasnya dan menghasilkan apa yang akan dilakukannya pada perangkat keras target. Dalam praktiknya, vendor sering menyebut emulator dan simulator PLC dengan salah satu nama tersebut, jadi periksalah apa yang ada di balik label itu. Simulator dan emulator untuk controller yang sama dapat berbeda cukup jauh dalam seberapa baik mereka mereproduksi sistem target.

Kasus penggunaan: untuk apa masing-masing digunakan dalam otomasi

McGregor menjelaskan kasus penggunaan yang umum. Model simulasi digunakan untuk menguji dan mengembangkan berbagai solusi guna menemukan yang terbaik. Model ini mengeksplorasi opsi desain, tata letak, batas operasi, dan strategi kendali. Model ini berjalan cepat, sering kali lebih cepat daripada waktu nyata, dan hasilnya dapat diulang selama parameternya tidak berubah. Hal itu membuatnya cocok untuk banyak eksperimen dan optimasi otomatis.

Model emulasi digunakan untuk menguji logika sistem kendali di bawah berbagai kondisi beban, untuk memverifikasi perilaku kendali sebelum commissioning, serta untuk melatih operator dan staf pemeliharaan. Model ini berjalan secara real time dengan sistem kendali yang terhubung dari luar.

McGregor juga mencatat batasannya. Model emulasi kurang cocok untuk eksperimen karena sering kali hanya dapat berjalan secara real time. Menjalankannya lebih cepat daripada waktu nyata menimbulkan kesalahan, karena timer pada sistem kendali tidak dapat menyesuaikan diri. Hasilnya juga kurang dapat diulang, sebab komunikasi antara model dan controller bersifat asinkron dan bergantung pada jaringan serta sistem operasi.

Duque Anton dan rekan-rekan penulisnya menyampaikan poin serupa dari sisi yang berlawanan. Simulasi efisien dari sisi biaya, sumber daya, dan waktu, tetapi setiap karakteristik fisik harus dimodelkan, dan itu terkadang membutuhkan usaha yang besar. Emulasi secara desain seakurat sistem produksi tempat lingkungannya nyata, tetapi membutuhkan lebih banyak perangkat dan ruang, serta biayanya lebih tinggi. Kesimpulan mereka adalah tidak ada solusi umum yang memenuhi semua kebutuhan.

Software in the loop, hardware in the loop, dan digital twin

Dalam proyek otomasi, kedua gagasan ini bertemu dalam pengujian "in the loop". Halaman vendor realvirtual menjelaskannya sebagai berikut:

• Software in the loop: program kendali dijalankan sebagai perangkat lunak di PC, misalnya dalam emulator PLC, dan bekerja dengan model mesin. Tidak diperlukan perangkat keras.
• Hardware in the loop: PLC sungguhan terhubung ke model mesin melalui jaringan. Perangkat keras nyata menggerakkan mesin virtual.

Keduanya termasuk emulasi dalam pengertian McGregor, karena bagian yang nyata, yakni kode kendali atau controller, bekerja bersama model dari bagian lainnya. Keduanya menjadi inti dari virtual commissioning. Halaman ini merupakan sumber dari vendor, dan deskripsinya konsisten dengan definisi akademis di atas.

Model alur produksi merupakan kasus yang berbeda. Simulasi pabrik adalah model terkendali tentang bagaimana pekerjaan bergerak melalui sebagian pabrik, dengan menggunakan aturan operasi terkini, sumber daya, pesanan, dan variasi normal, sehingga perubahan seperti tambahan shift, mesin baru, atau buffer yang lebih kecil dapat diuji sebelum diterapkan. Tidak ada controller yang terlibat dalam loop. Ini adalah simulasi dalam arti murni, dan berjalan jauh lebih cepat daripada waktu nyata.

Digital twin, yaitu representasi digital dari sebuah sumber daya fisik yang dipelihara dan diperbarui berdasarkan hasil pengamatan, dapat berfungsi sebagai model dalam kedua kasus tersebut. Yang menentukan bukan modelnya, melainkan cara penggunaannya: sebagai eksperimen mandiri, yang merupakan simulasi, atau terhubung dengan sesuatu yang nyata secara real time, yang merupakan emulasi.

Emulator atau simulator: mana yang harus digunakan

Gunakan ini sebagai panduan singkat. Ini merupakan ringkasan kami sendiri, bukan standar.

• Seberapa besar kapasitas yang kita butuhkan, dan di mana letak bottleneck-nya? Simulasi. Anda ingin banyak skenario, dengan cepat.
• Apakah program kontrol menangani macet, komponen yang hilang, atau kerusakan sensor? Emulasi, pertama-tama dalam perangkat lunak.
• Apakah pengontrol sungguhan memenuhi persyaratan waktu dan antarmukanya? Hardware in the loop, atau pengujian pada peralatan sungguhan. Duque Anton dan rekan penulisnya menyatakan bahwa perangkat keras sungguhan memberikan hasil yang paling realistis, tetapi paling sulit untuk disiapkan.
• Bisakah kami melatih operator sebelum start-up? Emulasi. Model yang terhubung dengan panel kontrol sungguhan berperilaku seperti mesin sebenarnya.
• Manakah dari dua tata letak yang lebih baik? Simulasi.

Satu proyek sering kali membutuhkan keduanya. Pertama, simulasi menentukan ukuran lini. Kemudian, emulasi menguji program kontrol untuk lini tersebut.

Contoh: satu lini pengemasan, dua pertanyaan

Ini adalah contoh ilustratif, bukan kasus yang diukur. Sebuah lini pengemasan menghasilkan 3.000 karton per jam. Pabrik mengajukan dua pertanyaan.

Pertanyaan 1: apakah penambahan mesin pelabel kedua akan meningkatkan output menjadi 3.600 karton per jam? Ini adalah pertanyaan simulasi. Model produksi menjalankan satu shift 8 jam dalam sekitar 2 menit, yaitu 240 kali lebih cepat dari waktu nyata. Tim menguji 30 skenario, misalnya ukuran batch, ukuran buffer, dan pola henti yang berbeda. Ke-30 run tersebut membutuhkan sekitar 60 menit. Ke-30 skenario yang sama dalam waktu nyata akan memakan 30 × 8 jam = 240 jam, atau 30 hari kerja. Pengujian waktu nyata bukan pilihan untuk pertanyaan ini.

Pertanyaan 2: apakah program kontrol menangani karton macet di mesin pelabel? Ini adalah pertanyaan emulasi. Program kontrol berjalan di emulator PLC, dan model memerankan lini tersebut. Setiap kasus kesalahan membutuhkan sekitar 5 menit dalam waktu nyata, dan waktu ini tidak dapat dipercepat, karena timer program bergantung pada waktu nyata. Dua belas kasus kesalahan membutuhkan sekitar 60 menit. Biaya ini tergolong murah dibandingkan menemukan kesalahan penanganan macet saat start-up pada lini sungguhan.

Kedua pengujian memakan waktu sekitar satu jam, dan keduanya menjawab pertanyaan yang berbeda. Simulasi yang cepat tidak dapat menunjukkan apakah timer kontrol berfungsi, dan emulasi waktu nyata tidak dapat menguji 30 skenario dalam sehari.

Kesalahan umum

• Menggunakan kata-kata tersebut sebagai sinonim dalam spesifikasi. Pemasok yang menawarkan "simulasi" mungkin hanya mengirimkan model murni, padahal Anda membutuhkan pengujian kontrol.
• Menilai waktu kontrol dari simulasi. Model yang berjalan lebih cepat dari waktu nyata tidak menjelaskan apa pun tentang timer dan komunikasi.
• Mempercepat emulasi. Hasilnya salah ketika timer kontrol tidak dapat mengikuti.
• Model yang terlalu rinci. Model yang memuat setiap kabel dan baut membutuhkan usaha yang tidak diperlukan untuk menjawab pertanyaan tersebut.
• Menganggap emulator sebagai pengontrol sungguhan. Emulasi pengontrol bukanlah PLC. Rencanakan pemeriksaan pada perangkat keras sungguhan untuk waktu dan antarmuka.
• Tidak ada uji penerimaan pada lini sungguhan. Uji virtual yang lolos menurunkan risiko. Uji tersebut tidak menghilangkannya.

Bagaimana perangkat lunak dapat membantu

Alat untuk kedua tujuan tersedia. Model aliran produksi berjalan di perangkat lunak simulasi, dan pengujian kontrol menggunakan emulasi PLC serta model mesin. Tanyakan kepada pemasok apa yang berjalan dalam waktu nyata, apa yang nyata, dan apa yang dimodelkan. Untuk pengujian perangkat lunak pada kode kontrol, tanyakan bagaimana pengujian diotomatisasi dan dicatat, sehingga satu kali run pengujian dapat diulang setelah setiap perubahan pada program. Mintalah antarmuka untuk platform PLC Anda serta perkiraan usaha untuk membangun model. Perangkat lunak tidak menentukan pertanyaan mana yang harus diajukan, dan pertanyaan yang jelas adalah cara terbaik untuk memilih di antara keduanya.

Langkah berikutnya

Untuk proyek otomatisasi berikutnya, tuliskan setiap pengujian yang Anda inginkan sebagai sebuah pertanyaan, dan beri tanda pada masing-masing sebagai "banyak skenario, cepat" atau "kontrol nyata, waktu nyata". Kemudian gunakan daftar tersebut untuk memutuskan simulasi atau emulasi sebelum Anda meminta penawaran.