Kenangan menyakitkan dari simulasi PLC

Pernyataan besar dari disertasi oleh Mr. Roland Schulz dari tahun 2002 merangkumnya dengan cukup baik secara keseluruhan.

Singkatnya:"Mencoba dan menguji membantu menemukan kesalahan".

Sekarang saya tidak menulis di sini tentang simulasi seluruh pabrik produksi, tetapi memecah prinsip lebih jauh ke unit individu (komponen), seperti program otomatisasi atau proyek pengguna.

Di masa lalu, sebagai karyawan muda di Phoenix Contact, saya juga harus belajar pemrograman dan akan senang dengan simulasi pengontrol. Sekedar untuk mengetahui lebih lanjut tentang operasi dan fungsi blok atau program dengan cara "coba-coba". Sayangnya, saat itu tidak ada dan simulasi PLC yang diikuti sangat terbatas. Kode IEC61131-3 dapat disimulasikan dengan baik, tetapi tidak memiliki dukungan perangkat khusus atau hanya perilaku kode yang berbeda antara sistem berbasis Intel dan ARM atau Motorola.

Dengan pemikiran ini dalam pikiran dan kenangan akan rasa sakit yang kami alami dengan simulasi "klasik" dari PLC, kami berangkat untuk benar-benar menemukan sesuatu dengan nilai tambah tanpa menciptakan upaya besar. Upaya di satu sisi dalam pengembangan simulasi dan upaya yang bisa timbul nantinya dalam pemanfaatannya.

Sebagai pengguna, saya ingin dapat mengirim proyek saya ke PLC atau ke simulasi, paling baik dengan klik mouse. Saya tidak ingin memperhatikan arsitektur prosesor, dan tentu saja saya tidak ingin dipaksa untuk menyembunyikan atau, lebih buruk lagi, menghapus fungsi dalam kode saya yang tidak didukung oleh simulasi.

Apa yang bisa lebih jelas daripada menggunakan firmware asli dalam simulasi, yang juga digunakan pada perangkat keras kontrol nyata? Dan itulah yang terjadi.

Saat ini ada emulasi sistem lengkap yang tidak hanya memungkinkan untuk menjalankan berbagai sistem operasi di bawah Windows. Mereka juga memungkinkan emulasi berbagai arsitektur prosesor dan karakteristiknya.

Bukan rahasia lagi bahwa pengontrol kami didasarkan pada Linux. Tetapi penting untuk pengembangan kode bahwa di sini juga digunakan arsitektur prosesor yang berbeda.

Dalam rekayasa, dalam kasus kami Insinyur PLCnext, pelanggan harus dapat memilih antara alamat IP pengontrol atau simulasi - dengan satu klik mouse tanpa khawatir tentang adaptasi kode lebih lanjut atau kompatibilitas kode biner.

Apa yang muncul dari pemikiran itu?

Kami menemukan emulasi sistem QEMU dan menggunakannya untuk mensimulasikan pengontrol kami. QEMU adalah "emulasi mesin sumber terbuka" dan menawarkan apa yang kami cari.

"Hanya" jalankan firmware di dalamnya dan QEMU mengemulasi sistem Linux lengkap Teknologi PLCnext, termasuk arsitektur prosesor ARM dari beberapa pengontrol PLCnext -- dan simulasi PLCnext lahir. Diakui, kami menyertakan beberapa batasan kecil. Komunikasi PROFINET atau protokol komunikasi lainnya dinonaktifkan. Tetapi server OPC UA, misalnya, tidak terpengaruh.

Namun, semua fitur khusus Teknologi PLCnext dapat dipertahankan. Jadi saya juga dapat mengirim program dan komponen C/C++, C# atau Matlab Simulink ke simulasi. Juga APP, yang dapat saya temukan untuk aplikasi tertentu di Store, dapat dibawa ke eksekusi.

Beberapa batasan lebih lanjut jelas - determinisme tidak diharapkan dari sistem yang disimulasikan seperti itu. Dan tergantung pada beban sistem Windows saya, mungkin ada satu atau beberapa pengawas lain pada simulasi PLCnext. Tetapi dalam kasus seperti itu saya selalu dapat memberikan proses simulasi prioritas yang lebih tinggi di sistem Windows dan kemudian kesalahan pengawas dengan cepat diselesaikan.

Dan sekarang saya akhirnya memilikinya, sebuah simulasi, atau bahkan mungkin tergantung pada definisinya, sebuah emulasi dari controller saya. Tapi sayangnya saya harus belajar pemrograman tanpanya, dan sekarang saya tidak memprogram sebanyak itu lagi.