MQTT dalam Otomasi Industri: Panduan Praktis bagi Produsen

Jika Anda terlibat sama sekali dengan Internet Industri Hal-hal (IIoT), Anda pasti akan melihat akronim baru yang digunakan di mana-mana: MQTT. Sementara MQTT cukup baru dalam otomasi, ia telah ada selama lebih dari 20 tahun. Ini awalnya dikembangkan sebagai protokol untuk mendapatkan data dari lapangan minyak jauh, tetapi sampai akhir-akhir ini, ia tidak pernah mendapatkan penerapan yang banyak di luar aplikasi nich ini. Sekarang ia muncul sebagai salah satu protokol utama untuk proyek transformasi digital untuk manufaktur.

Apa Itu MQTT?

MQTT singkatan dari Message Queuing Telemetry Transport. Ini adalah protokol transportasi pesan client-server publish/subscribe, dianggap sebagai protokol pesan ringan untuk mengirim paket kecil informasi dalam aplikasi bandwidth terbatas. Pada intinya, ia dianggap standar OASIS di jantung konektivitas IoT.

Sejarah

Pada akhir 1990-an, ada kebutuhan akan protokol komunikasi ringan yang dapat mengirim data dari situs minyak jauh dengan kecepatan koneksi yang sangat rendah, mungkin sejauh 300 baud. Strateginya adalah untuk memanfaatkan kemampuan yang sudah ditawarkan di lapis transportasi, yang menggunakan protokol TCP. Protokol aplikasi yang diusulkan akan menghilangkan redundansi apa pun yang menambahi payload transmisi. Ini juga perlu stateful, dan hanya melaporkan berdasarkan pengecualian. Dengan kendala ini dalam pikiran, Phillips 66 bekerja sama dengan Arlen Nipper dari Cirrus Link Solutions dan Andy Stanford-Clark dari IBM untuk mengembangkan apa yang sekarang dikenal sebagai protokol MQTT.

Penggunaan Komersial Awal

Sementara perusahaan otomasi dihubungi dengan protokol MQTT pada awal 2000-an, penggunaannya komersial lainnya adalah dengan aplikasi Facebook Messenger dan Apple Messages. Fitur utama yang menarik adalah protokol memastikan status dan kualitas data. Ketika pengirim sedang mengetik, penerima akan melihat tiga titik yang sekarang sudah sangat familiar di layar. Ini juga digunakan dalam beberapa aplikasi pemantauan rumah dan data cuaca, tetapi pada titik itu, penggunaan MQTT cukup terbatas.

Adopsi Otomatisasi

Pada pertengahan 2010-an, Arlen Nipper sekali lagi mendekati perusahaan otomasi untuk mempromosikan penggunaan MQTT. Ada kebutuhan yang muncul untuk mendapatkan data manufaktur tambahan yang diagregasi tanpa beban jaringan yang signifikan. Namun, ada beberapa kemampuan tambahan yang perlu dikembangkan untuk mendapatkan penerimaan di manufaktur. Cirrus Link Solutions, bersama dengan Inductive Automation, melanjutkan pengembangan apa yang sekarang dikenal sebagai standar Sparkplug, yang mencakup atribut yang diperlukan untuk otomasi, yaitu seperangkat topik yang ditentukan, payload standar, dan kompresi pesan.

Gambaran Umum Struktur

MQTT menggunakan struktur yang mirip dengan struktur folder komputer. Saya akan menggunakan desktop Windows sebagai contoh. Desktop memiliki folder bernama My Documents. Di My Documents, ada folder lain bernama Family, dan di dalam folder tersebut ada folder untuk setiap anggota keluarga. Jalur ke folder saya adalah Desktop/My Documents/Family/David. Saya akan menyimpan (publish) semua dokumen saya di David. Siapa pun yang ingin membaca dokumen saya akan membuka (subscribe) ke David.

Perangkat yang menggunakan protokol MQTT akan publish dan subscribe ke jalur topik yang disebut namespace. Mirip dengan komputer, itu diorganisir dari yang paling umum hingga yang paling spesifik. Semakin tinggi tingkat yang saya subscribe, semakin banyak data yang akan saya terima. Ada juga wildcard yang dapat digunakan untuk membantu mendefinisikan jalur topik. Bintang (*) mencakup semuanya dari tingkat saat ini dan di bawahnya. Plus (+) memindahkan jalur satu tingkat lebih rendah. Saya telah menyertakan beberapa contoh lebih lanjut dalam artikel ini.

Penyesuaian dengan Standar ISA

Standar ISA-95 dipahami dengan baik dalam manufaktur. Ini menjelaskan model standar dan terminologi untuk antarmuka antara sistem perusahaan dan kontrol. Sementara ini umumnya direalisasikan sebagai hierarki, dimulai dengan ERP di atas dan perangkat di bawah, standar terutama menangani data manufaktur dan bagaimana itu harus distruktur. Karena MQTT menggunakan topic namespace, ini dapat dengan mudah diselaraskan dengan hierarki ISA-95. Direkomendasikan bahwa topic namespace harus mengikuti Enterprise, Site, Area, Line, dan Cell saat dikonstruksi. Folder root dari publisher/subscriber juga harus ada di tingkat yang tepat. Misalnya, PLC yang mengontrol cell harus publish data-nya dalam topik Enterprise/Site/Area/Line/Cell. Jika process historian spesifik untuk suatu area, ia harus subscribe semua data di tingkat Enterprise/Site/Area.

Arsitektur

Salah satu pertanyaan umum yang timbul dari penggunaan MQTT adalah apa yang terjadi ketika ada kehilangan konektivitas. Ada beberapa opsi yang dapat digunakan untuk mengurangi situasi ini. Solusi umum adalah menggunakan metode "store-and-forward". Misalnya, sistem SCADA yang berada di lapis kontrol akan terus mengumpulkan data sampai koneksi ke MQTT broker dilanjutkan. Harus diperhatikan bahwa saat koneksi broker dilanjutkan, stempel waktu dari semua data yang disimpan tetap utuh.

MQTT juga mendukung penggunaan backup broker. Sementara ada broker utama, jika koneksi ini terputus, node yang terhubung akan secara otomatis beralih ke broker lain. Hubungan umumnya dikonfigurasi melalui aplikasi (seperti sistem SCADA) yang mendukung fitur ini.

Solusi lain dicapai melalui penggunaan clustering. Ini biasanya untuk aplikasi yang tidak dapat menanggung kehilangan data apa pun. Pengaturan umum adalah memiliki beberapa MQTT broker yang disusun dalam cluster. Semua broker ini sadar satu sama lain dan akan membagi pesan dalam cluster. Ketika konektivitas terputus, publisher dan subscriber data akan secara mulus mengarahkan data ke broker lain tanpa kehilangan apa pun.

Biasanya untuk aplikasi perusahaan untuk menggunakan data dari semua pabrik mereka. Untuk skenario ini, MQTT mendukung penggunaan bridging yang mirip dengan sistem store-and-forward. Dalam arsitektur ini, satu broker akan publish atau bridge sebagian atau semua namespace-nya ke broker lain. Dengan kata lain, broker pabrik akan bridge ke broker perusahaan. Kedua topik yang dipublish dan struktur namespace dapat ditentukan. Ini membatasi jumlah data yang dipublish dan memberikan konteks untuk broker penerima.

Publish semua data apa adanya dengan bintang (*) dan tidak menentukan struktur apa pun adalah cara termudah, tetapi ini dapat menghasilkan banyak data yang tidak perlu dan mungkin membingungkan. Untuk memberikan beberapa konteks data, sebuah topik dapat ditambahkan di awal published topic namespace. Misalnya, Enterprise/Site dapat ditambahkan ke plant Area/+/Cell namespace, yang akan menghasilkan Enterprise/Site/Area/+/Cell yang dikirim ke Enterprise broker. Hasilnya adalah data tingkat Cell dari semua Line akan tersedia dari sistem ini (perhatikan penggunaan wildcard +).

Semua skenario ini dapat diterapkan. Sistem SCADA dapat menggunakan store-and-forward ke MQTT cluster. Ada cluster utama dan backup, tetapi ini mungkin akan menambahkan kompleksitas yang tidak perlu. Terakhir, plant cluster dapat bridge ke enterprise cluster untuk memaksimalkan integritas data. Ini sangat baik untuk analitik perusahaan dan machine learning, karena ini membutuhkan sejumlah besar data berkualitas baik.

Keamanan

Salah satu kekhawatiran utama dalam mengirim dan menerima data manufaktur melalui internet adalah keamanan siber. Sementara satu-satunya cara untuk benar-benar aman adalah dengan menggunakan air gap, ini akan mencegah kemampuan organisasi untuk transformasi digital. Salah satu manfaat utama MQTT adalah keamanannya. Sementara protokol komunikasi lain membuka port jaringan, MQTT hanya memerlukan koneksi keluar ke broker. Pabrik tidak diwajibkan membuka port masuk apa pun, yang sangat menarik bagi organisasi TI.

Pertimbangan Masa Depan

Dalam artikel mendatang, saya akan menjelajahi aplikasi umum dengan MQTT. Sementara protokol dimaksudkan untuk cukup plug-and-play, kemungkinan akan ada minat pada detail teknis tambahan. Pemimpin bisnis mungkin ingin memikirkan bagaimana MQTT akan mempengaruhi upaya transformasi digital mereka saat ini. Dan, tentu saja, pemimpin teknik pasti akan ingin tahu bagaimana MQTT akan mempengaruhi mereka.

Sebagai penutup, MQTT tidak boleh dianggap sebagai pengganti arsitektur yang ada. Selaras dengan persyaratan Industry 4.0, ini memanfaatkan apa yang sudah ada. Akan terus ada kebutuhan akan OPC UA dan protokol lain, karena mereka lebih rinci untuk aplikasi kontrol. Namun, ketika datang ke agregasi jumlah data yang signifikan, MQTT adalah pilihan yang luar biasa.