Kontrol Cerdas dan Desain Perangkat Lunak HMI Membantu Insinyur Membangun Jaringan Baru untuk IIoT
Marissa Tucker dari Parker Hannifin berbicara dengan Editor Senior Patrick Waurzyniak
Marissa, apa peran pengontrol gerakan di Industrial Internet of Things [IIoT], dan perangkat lunak apa yang terlibat?
Saya akan mengambil langkah di luar pengontrol gerakan dan mengatakan bahwa pengontrol otomatisasi yang dapat diprogram [PAC] memainkan peran terbesar di IIoT. Itu karena, selain memiliki logika mesin, PAC menyertakan kontrol gerak sebagai bagian dari rutinitas mereka dan sering kali juga memiliki antarmuka manusia-mesin [HMI] yang disematkan. Keindahan dari pendekatan ini adalah program tidak perlu berbagi tag antar perangkat karena komponen berada pada perangkat yang sama menggunakan logika yang sama. Ini tidak hanya memangkas waktu pemrograman, tetapi juga memfasilitasi kemampuan IIoT.
Berikut contohnya:Kesalahan posisi—yang dulunya sangat spesifik untuk pengontrol gerakan—dapat diakses secara otomatis oleh HMI yang disematkan. Jika HMI yang disematkan itu memiliki kemampuan server web, yang banyak dilakukan, HMI dapat segera mengirimkan peringatan ke operator lokal dan juga ke manajer pabrik melalui email atau SMS [layanan pesan singkat]. Ini jauh lebih baik daripada pendekatan tradisional yang meminta pengontrol gerak mengirim kesalahan ke PLC [pengontrol logika yang dapat diprogram], dengan PLC kemudian harus memproses data hanya untuk mengirimkannya ke HMI — yang mungkin atau mungkin tidak memiliki server web. Transfer data yang rumit antar perangkat ini dihilangkan, karena logika ditulis pada satu perangkat lunak pemrograman yang diunduh pada satu perangkat keras. Ini sangat terintegrasi sehingga Anda dapat dengan mudah mendapatkan informasi di mana saja.
Memastikan bahwa pengembang yang membuat HMI tersemat dapat membuat grup pengguna dan kredensial yang berbeda sangatlah penting. Ini memungkinkan pemrogram untuk membuat instance khusus dari HMI, tergantung pada pengguna.
Kemudahan arus informasi di dalam mesin itu penting, tetapi begitu juga kemudahan arus informasi antar mesin. Standar pemrograman IEC 61131-3 memastikan bahwa mesin yang dikembangkan oleh satu produsen berbicara dalam bahasa yang sama yang digunakan oleh yang lain. Ini sangat menguntungkan integrator karena mereka dapat dengan lebih mudah membuat dua sistem mesin yang berbeda untuk berbicara satu sama lain, sebuah langkah penting menuju IIoT. Organisasi seperti OMAC [Organization for Machine Automation and Control], yang mempromosikan standar PackML, membawa IEC 61131-3 ke tingkat berikutnya dengan tidak hanya merekomendasikan bagaimana sistem harus diprogram, tetapi juga dengan mengembangkan serangkaian tag standar yang digunakan mesin harus tersedia untuk mesin lain dalam jaringan.
Bagaimana dengan perangkat tingkat rendah, seperti katup pneumatik dan sensor posisi? Bukankah semuanya seharusnya menjadi bagian dari IoT?
Tantangannya terletak pada pengambilan data dari perangkat tingkat rendah dan mengubahnya menjadi informasi yang berguna. Salah satu pendekatannya adalah melakukan pemrosesan pada tingkat perangkat ini dan kemudian mengirimkan hasilnya baik melalui bus kontrol berkinerja tinggi atau langsung ke cloud. Ini adalah pendekatan yang sangat mahal dan tidak membantu mengumpulkan atau memusatkan data. Atau, kami melihat pertumbuhan besar dalam popularitas IO-Link, protokol berbasis serial yang dapat mengumpulkan data dasar dari sensor suhu, solenoida, manifold katup pneumatik, dll., tanpa biaya tambahan yang mahal.
Dengan membiarkan bus sederhana, data ini dapat dikumpulkan dan dibuat berguna dengan memproses pada PAC atau PLC yang harus ada di setiap sistem mesin. Dengan menggunakan PAC, yang juga memiliki HMI tertanam untuk penerbitan web, pengguna kemudian dapat mengambil informasi itu dan meletakkannya di jaringan, ke mana pun ia pergi. Bayangkan sebuah sistem pneumatik dengan sensor yang terus menerus memantau suara dalam desibel. Satu-satunya data yang perlu dikirim ke PAC IO-Link adalah dB saat ini. PAC dapat memiliki blok fungsi IEC 61131-3 khusus yang dikembangkan oleh pabrikan yang dapat bekerja pada beberapa pengontrol. Blok fungsi ini dapat memeriksa apakah ada pola aneh dalam kebisingan, untuk mengatakan, 'Ah, mungkin ada kebocoran.' Pemrogram dapat mengambil peringatan itu dan mengirim pesan ke pengguna tingkat pemeliharaan HMI sebelum pneumatik gagal .
Bagaimana cara mendapatkan informasi dari mesin ke cloud, dan bagaimana dengan perangkat lunak yang terlibat?
Masih ada pembagian besar antara lantai pabrik dan TI. Khusus untuk perusahaan manufaktur dengan banyak fasilitas di berbagai negara bagian, atau negara, menyimpan data di server eksternal atau cloud sangat ideal. Dari sisi perangkat lunak, produsen komponen perlu membantu membuat kehidupan pembuat mesin semudah mungkin saat bekerja dengan TI.
Sebagian besar pembuat mesin merasa nyaman memprogram PLC atau PAC dalam IEC atau bahasa serupa, jadi perusahaan harus mencari produsen yang mengambil pendekatan terintegrasi untuk kontrol mesin untuk mempermudah aliran informasi tetapi yang juga memudahkan untuk membagikan informasi tersebut ke server TI. Standar lain yang dikeluarkan dari Eropa adalah OPC-UA [OPC Unified Architecture]. Protokol client-server ini telah berkembang secara signifikan, memungkinkan cara universal untuk mentransfer data baik mesin-ke-mesin, mesin-ke-SCADA, atau mesin-ke-server. Karena fleksibilitasnya, OPC-UA dengan cepat menjadi standar IoT. Cari pemasok yang memiliki perangkat lunak bawaan untuk membuat koneksi OPC-UA dengan mudah hanya dalam beberapa klik dan memungkinkan pengembang untuk berbagi data hanya dengan berbagi beberapa tag dalam program IEC 61131-3. Setelah dapat diakses di server, biarkan TI yang mengurus sisanya.
Apakah informasi berguna di awan? Bagaimana data penting sampai ke tangan operator, di lantai pabrik?
Tergantung kasus penggunaan. Siapa pun yang memikirkan IIoT, apakah mereka operator mesin, pembuat mesin OEM, atau pemilik pabrik, pertama-tama harus mengembangkan kasus penggunaan. Manajer lantai pabrik, misalnya, mungkin menginginkan informasi efektivitas peralatan [OEE] secara keseluruhan. Jenis informasi ini biasanya bukan sesuatu yang dibagikan dengan ruang publik yang lebih luas, jadi yang terbaik adalah menggunakan server internal. Namun, manajer lantai pabrik sering kali berada jauh dari mesin, atau tidak berada di meja mereka, tetapi masih perlu melihat OEE. Kasus penggunaan mendorong solusi:Jika mesin memiliki HMI tertanam dengan server web, pengguna dapat menghubungkannya dari platform iOS atau Android, memasukkan kredensialnya, dan melihat OEE mesin, tidak perlu cloud eksternal . Jaringan dalam pabrik ini sering disebut sebagai komputasi 'kabut'.
Contoh lainnya adalah agen pembelian yang perlu memantau data hasil untuk beberapa lini pabrik di beberapa lokasi. Server eksternal adalah satu-satunya jawaban. Untuk meminimalkan risiko pengungkapan informasi sensitif perusahaan, program mungkin hanya mempublikasikan total output, bukan hasil. Meskipun solusi ini menuntut penggunaan server cloud, solusi ini menggambarkan perlunya menahan diri saat mengirim data apa pun ke server eksternal karena dua alasan:umumnya, ini kurang aman daripada menyimpannya di jaringan internal atau 'kabut', dan sebagian besar rencana membebankan biaya kepada perusahaan untuk mengirim dan menyimpan data ke cloud eksternal.
Pemasar telah melakukan pekerjaan yang baik dalam mempromosikan Industri 4.0, tetapi setiap pengguna perlu mundur dan bertanya, 'Bagaimana saya dapat menggunakan informasinya?' Cloud mungkin tidak diperlukan seperti yang mungkin Anda pikirkan.
Bukankah semua konektivitas ini meningkatkan biaya?
Bisa, tapi tidak harus. Di mana menjadi mahal adalah tiga atau empat tahun ke depan, ketika perusahaan Anda siap untuk IoT, tetapi Anda menentukan perangkat yang membuat sulit atau tidak mungkin untuk berkomunikasi melalui server web atau OPC-UA, atau Anda memilih desain tradisional yang terfragmentasi daripada PAC mesin tunggal yang membuat aliran data menjadi lebih mudah secara signifikan. Untuk mengurangi kesalahan ini, Anda dapat membeli sensor yang sangat mahal yang beralih dari kontrol suhu langsung ke cloud eksternal, melewati semua perangkat lain di mesin. Dari sana, Anda harus memprogram seluruh lapisan atau situs web yang disesuaikan menggunakan perangkat lunak orang lain untuk membuat data bermanfaat. Anda tidak ingin menjadi orang ini.
Sebaliknya, terapkan IIoT dengan cerdas:jadikan itu bagian dari desain mesin pada Hari Pertama. Jika Anda sedang membangun aplikasi baru, Anda berada dalam posisi yang tepat untuk transisi, meskipun itu bukan sesuatu yang sedang dipertimbangkan organisasi Anda saat ini. Pilihan yang Anda buat hari ini dapat menghemat ratusan ribu dolar di kemudian hari.
Selain itu, pilih perangkat tingkat rendah yang mendukung bus seperti IO-Link sehingga Anda bisa mendapatkan data darinya dengan harga terjangkau. Gunakan protokol standar yang hemat biaya dan memungkinkan Anda menggunakan data dari banyak sumber. Gunakan perangkat lunak pemrograman tunggal pada pengontrol tunggal untuk menyederhanakan pemrograman. Pastikan pengontrol mesin memiliki kemampuan untuk hubungan klien-server tanpa harus memerlukan gateway tambahan lainnya. Dengan begitu, jika Anda perlu memulai merutekan informasi ke lokasi yang berbeda, Anda dapat melakukannya dengan benar di program berbasis IEC Anda. Jangan lupa komputasi kabut. Jika PLC Anda memiliki HMI tertanam yang mampu server web, Anda mungkin dapat memenuhi semua kasus penggunaan IIoT Anda tanpa menggunakan cloud sama sekali. Dan jika perlu, pastikan pengontrol yang Anda pilih memiliki perangkat lunak yang memudahkan untuk berbagi ke server OPC-UA, sehingga TI dapat melakukan yang terbaik bagi TI.
Pilihan cerdas membuat konversi ke IIoT sangat terjangkau, tetapi pilihan harus dibuat sekarang.
