Fakultas Ilmu Komputer
479
Rancang Bangun IOT
Cloud
Platform
Berbasis Protokol Komunikasi
MQTT
Moh. Wildan Habibi1, Adhitya Bhawiyuga2, Achmad Basuki3
Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya Email: 1mohwildannhabibi@gmail.com, 2bhawiyuga@ub.ac.id, 3abazh@ub.ac.id
Abstrak
Internet of Things (IoT) merujuk pada suatu jaringan yang menghubungkan berbagai perangkat dalam dunia fisik dengan berbagai protokol berbeda. Namun, terdapat keterbatasan dalam hal komputasi dan penyimpanan karena perangkat IoT hanya menggunakan komponen penyimpanan dan komputasi yang terbatas. Sedangkan cloud adalah lingkungan virtual yang umumnya memiliki kapasitas komputasi dan penyimpanan yang sangat besar. Dengan mengintegrasikan cloud dengan IoT, perangkat IoT diharuskan untuk mengalihkan proses komputasi dan penyimpanan menuju cloud, sehingga cloud dapat menyelesaikan keterbatasan pada perangkat IoT. Terdapat dua masalah utama dari integrasi tersebut, yaitu heterogenitas dan keamanan. Heterogenitas yaitu banyaknya ragam perangkat yang dapat berkomunikasi dengan cloud, sehingga perlu digunakan protokol komunikasi tertentu agar semua perangkat dapat terhubung dengan cloud. Keamanan sendiri merujuk pada validitas perangkat IoT yang mengirimkan data. Dari penjelasan sebelumnya, maka penelitian ini membuat sebuah rancang bangun IoT cloud platform menggunakan protokol komunikasi MQTT untuk menyelesaikan masalah heterogenitas. Sedangkan untuk memastikan validitas dari perangkat IoT yang mengirimkan data, dibangun sebuah mekanisme manajemen perangkat IoT, autentikasi, dan otorisasi. Hasil pengujian performa menunjukkan, sistem yang dibangun mampu menangani publisher hingga 250 publisher dalam tiap detik.
Kata kunci: IoT, cloud, platform, mqtt, authentication, authorization. Abstract
Internet of Things (IoT) referring to a network that linking various device in the physical world with a variety of different protocols. However, there are limitations in terms of computing and storage because IoT device only use minimum computational and storage components. While cloud is a virtual environment that generally has a big capacity of computing and storage. By integrating cloud and IoT, it is necessary to divert IoT device’s computational process and storage towards cloud, so that cloud can resolve the limitations on the IoT device. There are two main issues in the integration, heterogeneity and security. Heterogeneity refers to number range of devices that can communicate with the cloud, so it is necessary to use specific communication protocol so that all devices can be connected to the cloud. Security refers to the validity of the IoT devices that can transmit data to the cloud. From the previous explanation, then this research makes an architecture of IoT cloud platform that use MQTT communication protocol to resolve the problem of heterogeneity. Whereas to ensure the validity of IoT devices that can transmit data, constructed a mechanism to manage IoT device, authentication, and authorization. The performance test results showed, built systems capable of handling the publisher up to 250 publishers in each second.
Keywords: IoT, cloud, platform, mqtt, authentication, authorization.
1. PENDAHULUAN
Internet of Things (IoT), merujuk pada suatu jaringan yang menghubungkan berbagai perangkat dalam dunia fisik dengan berbagai protokol berbeda (Guoqiang, Yanming, Chao,
perangkat IoT yang tersebar pada lahan tersebut saling berbagi informasi dan dapat diakses melalui Internet.
Things atau perangkat dalam IoT, merupakan perangkat fisik yang memiliki identitas, atribut, karakteristik tertentu, dan dapat berkomunikasi antara satu dengan yang lain. Namun, terdapat keterbatasan dalam hal komputasi dan penyimpanan karena hanya menggunakan komponen penyimpanan dan komputasi yang terbatas (Botta, Donato, Persico, & Pescape, 2016). Sebagai contoh, perangkat IoT tidak dapat menyimpan berbagai data yang telah dihimpun hingga bertahun-tahun, atau perangkat IoT tidak dapat melakukan komputasi kompleks. Dengan keterbatasan tersebut, salah satu solusi yang dapat diberikan yaitu mengalihkan proses komputasi dan penyimpanan ke sistem yang lain, contohnya cloudcomputing platform.
Zhang et al (2010) menyebutkan bahwa cloud adalah kumpulan objek computing resources yang dapat dikonfigurasi secara tepat dan diakses dari mana saja, serta resources-nya dapat ditambahkan atau dikurangi dengan cepat dan mudah. Penelitian tersebut juga menyebutkan karakteristik dari sebuah cloud, diantaranya adalah cloud secara virtual memiliki kemampuan yang tidak terbatas dalam hal penyimpanan dan komputasi. Hal itu mengisyaratkan bahwa cloud memiliki teknologi yang mampu menjawab tantangan pada perangkat IoT.
Jika cloud digunakan sebagai solusi terhadap tantangan IoT, maka terdapat beberapa potensi masalah yang perlu diselesaikan (Botta, Donato, Persico, & Pescape, 2016). Secara umum, terdapat dua masalah utama dari integrasi tersebut, yaitu heterogenitas dan keamanan. Heteroginitas yaitu banyaknya ragam perangkat yang dapat berkomunikasi dengan cloud, sehingga diperlukan suatu standar komunikasi sehingga semua perangkat dapat berkomunikasi dengan cloud. Keamanan sendiri merujuk pada validitas perangkat IoT yang mengirimkan data. Oleh karena itu, diperlukan suatu mekanisme kerja yang dapat mengidentifikasi suatu perangkat dan memeriksa valid tidaknya perangkat IoT yang mengirimkan data.
Dari pembahasan sebelumnya, maka penelitian ini membuat sebuah rancang bangun IoT cloud platform, sebagai alternatif yang mampu mendukung komunikasi berbagai perangkat IoT dan menjamin validitas dari
perangkat yang mengirimkan data. Untuk menyelesaikan masalah heteroginitas pada integrasi IoT dan cloud, perangkat IoT cloud platform ini menggunakan protokol komunikasi MQTT. Protokol MQTT digunakan karena keandalan dalam pengiriman paket, dan penggunaan bandwidth yang kecil. Menurut OASIS (2015), MQTT memiliki karakteristik yang mendukung pada kemampuan yang dimiliki oleh perangkat IoT, yaitu dapat bekerja pada low power, dan menggunakan bandwidth yang kecil. Sedangkan untuk memastikan validitas dari perangkat IoT yang mengirimkan data, peneliti akan membangun sebuah mekanisme manajemen perangkat IoT, authentication, dan authorization.
2. ARSITEKTUR KOMUNIKASI PUBLISH/SUBSCRIBE
2.1. Pengertian
Prinsip dari model komunikasi publish / subscribe yaitu beberapa komponen yang menginginkan sejumlah informasi yang sesuai dengan topik mereka inginkan dengan cara mendaftarkan topik apa yang diinginkan. Proses mendaftarkan topik ini disebut dengan subscribe. Sedangkan kumpulan komponen yang menginginkan informasi tersebut disebut sebagai subscriber. Komponen lain membuat atau memberikan informasi terkait dengan yang diinginkan oleh subscriber dengan cara melakukan publish informasi. Komponen itu disebut sebagai publisher. Sedangkan entitas yang bertugas untuk memastikan bahwa suatu paket informasi dapat terkirim dari publisher menuju subscriber disebut sebagai broker. Broker bertugas untuk mengkoordinasi keinginan akan informasi dari para subscriber, dan subscriber biasanya secara eksplisit akan melakukan kontak dengan broker untuk melakukan subscribe (Hunkeler, Truong, & Clark, 2015).
Gambar 1. Model Komunikasi Topic-Based Publish/Subscribe
2.2. MQTT (Message Queue Telemetry Transport)
Queue Telemetry Transport. Ini merupakan protokol komunikasi publish/subscribe topic-based yang sangat sederhana dan ringan, yang didesain untuk alat yang memiliki kemampuan terbatas, bandwidth yang rendah, latency yang tinggi atau jaringan yang kurang dapat diandalkan. Prinsip dari desain ini adalah untuk meminimalkan penggunaan bandwidth jaringan dan kebutuhan sumber daya pada perangkat serta pada waktu yang sama juga berusaha untuk memastikan keandalan dan kepastian dari pengiriman data. Prinsip yang ada ini juga memunculkan beberapa ide protokol mengenai “machine-to-machine” (M2M) atau IoT yang menginginkan perangkat di dunia untuk saling terhubung, dan untuk aplikasi mobile dimana bandwidth dan daya baterai pada keadaan yang cukup (MQTT, 2016).
3. REKAYASA KEBUTUHAN
Rekayasa kebutuhan untuk menganalisis beberapa kebutuhan yang diperlukan pada penelitian ini. Rekayasa kebutuhan pada penelitian ini dijelaskan sebagai berikut:
3.1. Analisis Kebutuhan Pengguna
Kebutuhan pengguna pada penelitian ini yaitu node sensor dapat melakukan pengiriman data sensor menuju broker. Pada sisi web app, akan ditampilkan data - data yang telah diterima dari node sensor dalam bentuk tabel.
3.2. Analisis Kebutuhan Sistem
Kebutuhan sistem IoT cloud platform yang dibangun pada penelitian ini dijelaskan sebagai berikut:
a. Node sensor dapat memperoleh data dari sensor yang dimiliki oleh node sensor tersebut,
b. Node sensor dapat mengirimkan data menuju broker menggunakan protokol MQTT,
c. Broker dapat menerima koneksi yang dibuat oleh publisher (node sensor) dan subscriber, serta dapat menerima data yang dikirim oleh node sensor. Broker melakukan proses authentication terhadap setiap koneksi yang akan dibangun oleh publisher dan subscriber, serta melakukan proses authorization pada setiap data yang akan diterima oleh broker dan data yang akan diteruskan dari broker ke subscriber. Jika lolos tahap tersebut, maka data akan di teruskan ke subscriber,
d. Subscriber dapat menerima data dari broker
dan dapat mengolah data - data yang telah diperoleh sebelumnya untuk dimasukkan ke dalam database atau tidak,
e. Web app dapat menampilkan data - data yang telah dikumpulkan pada database. Web app dapat melakukan Create, Read, Update, dan Delete pada database yang digunakan.
4. PERANCANGAN SISTEM 4.1. Gambaran Umum Sistem
Gambar 2. Alur Komunikasi Data Sistem
4.2. Alur Kerja Penanganan Publisher
Node sensor membangun koneksi
dengan broker
Broker mendeteksi koneksi baru, meneruskan ke auth server untuk check
publish data berupa data yang didapat dari sensor menuju broker menggunakan meneruskan ke auth server untuk check authorization
Auth server mendeteksi permintaan check authorization,
melakukan proses dan memberikan respon
Respon diterima, dan broker menerima publish data sensor sesuai topik dari
publisher
Auth server mendeteksi permintaan check authentication, melakukan proses dan memberikan respon
Gambar 3. Alur Kerja Penanganan Publisher
Pada Gambar 3 ditunjukkan bahwa proses operasi pada sistem dimulai pada dimulai dari node sensor yang akan melakukan publish data maka diharuskan untuk membangun koneksi terlebih dahulu. Broker mendeteksi adanya permintaan koneksi dari publisher tersebut, maka data koneksi yang dikirimkan oleh publisiher akan diambil dan dikirim menuju auth server untuk dilakukan check authentication. Auth server menerima permintaan tersebut, kemudian memproses menggunakan data yang dikirim oleh broker, apakah publisher tersebut dapat melakukan koneksi. Hasil dari check authentication tersebut dijadikan respon oleh auth server, kemudian dikirimkan kembali menuju broker, dan broker mengirim ke publisher. Jika respon yang diterima oleh publisher yaitu mengijinkan untuk melakukan koneksi terhadap broker, maka tahap selanjutnya publisher akan melakukan publish data dengan topik yang telah ditentukan oleh publisher. Permintaan melakukan publish data akan dikirimkan terlebih dahulu oleh publisher menuju broker, dan broker akan mengirim data publish tersebut ke auth server untuk dilakukan check authorization. Pada auth server melakukan check authorization dan hasil dari pemeriksaan tersebut akan bertindak sebagai respon dari auth server kepada broker. Broker menerima respon dari auth server tentang check authorization, jika respon tersebut bernilai positif, maka data publish akan disimpan sementara oleh broker yang nantinya jika ada subscriber dengan topik yang sama melakukan subscribe, maka data tersebut akan diteruskan menuju subscriber tersebut. Jika respon tersebut bernilai negatif, maka broker tidak akan menyimpan data publish tersbut dan tidak akan meneruskannya menuju subscriber meskipun dengan topik yang
sama.
4.3. Alur Kerja Penanganan Subscriber
Subscriber membangun koneksi dengan broker
Broker mendeteksi koneksi baru, meneruskan ke auth server untuk check meneruskan ke auth server
untuk check authorization
Auth server mendeteksi permintaan check authorization,
melakukan proses dan memberikan respon
Respon diterima, dan broker meneruskan publish data
sensor sesuai topik dari publisher kepada subscriber
Gambar 4. Alur Kerja Penanganan Subscriber
Pada Gambar 4 ditunjukkan bahwa proses operasi pada sistem dimulai pada dimulai dari subscriber yang akan melakukan susbscribe pada topik tertentu maka diharuskan untuk membangun koneksi terlebih dahulu. Broker mendeteksi adanya permintaan koneksi dari subscriber tersebut, maka data koneksi yang dikirimkan oleh subscriber akan diambil dan dikirim menuju auth server untuk dilakukan check authentication. Auth server menerima permintaan tersebut, kemudian memproses menggunakan data yang dikirim oleh broker, apakah subscriber tersebut dapat melakukan koneksi. Hasil dari check authentication tersebut dijadikan respon oleh auth server, kemudian dikirimkan kembali menuju broker, dan broker mengirim ke publisher. Jika respon yang diterima oleh subscriber yaitu mengijinkan untuk melakukan koneksi terhadap broker, maka tahap selanjutnya subscriber akan melakukan subscriber pada topik yang telah ditentukan oleh subscriber. Permintaan melakukan subscribe pada topik tertentu akan dikirimkan terlebih dahulu oleh subscriber menuju broker.
4.4. Perancangan Skema Database
_id: <ObjectId1>
Gambar 5. Skema Database MongoDB yang Digunakan
Pada Gambar 5, terdapat 3 koleksi atau dapat dianggap seperti tabel jika pada database relasional. Koleksi tersebut terdiri dari User, Nodes, dan Subscriptions. Setiap koleksi memiliki field yang menjadi acuan dalam mengisi koleksi tersbut. Isi dari sebuah koleksi adalah dokumen atau dapat dianggap seperti record jika pada database relasional. Koleksi User berguna untuk menyimpan data yang berhubungan dengan user atau pengguna yang memiliki hak untuk berkontribusi pada sistem. Koleksi Nodes berguna untuk menyimpan data yang berhubungan dengan mikrokontroler yang digunakan sebagai node sensor. Koleksi Sensors sedikit berbeda dengan koleksi yang lain, karena koleksi ini berada didalam sebuah koleksi, yaitu koleksi Nodes. Koleksi Sensors berguna untuk menyimpan data yang berhubungan dengan sensor yang yang dimiliki atau digunakan oleh mikrokontroler. Koleksi Subscriptions berguna untuk menyimpan data - data yang telah dikirimkan oleh node sensor. Keseluruhan koleksi tersebut akan saling berhubungan antara satu dengan yang lain melalui field _id yang digunakan oleh koleksi yang lain.
4.5. Perancangan Auth Server
Auth Server bertugas untuk melakukan pemeriksaan mengenai koneksi yang akan dilakukan pada broker. Pemeriksaan tersebut meliputi authentication, superuser, dan authorization.
Gambar 6. Alur Kerja Auth Server
Pada Gambar 6, menggambarkan
flowchart algoritma dari Auth Server. Jika Auth Server berjalan, maka akan selalu dalam kondisi siap digunakan jika tidak ada check request dari broker. Jika terdapat request, maka tindak lanjut dari setiap permintaan akan berbeda di dalam prosesnya, namun semua akan berakhir dengan memberikan respon ke broker.
4.6. Perancangan Broker
Broker bertugas untuk menerima publish data dari publisher dengan topik tertentu, kemudian meneruskan publish data ke subscriber yang melakukan subscribe dengan topik yang sama.
Gambar 7. Alur Kerja Broker
Pada Gambar 7, menggambarkan flowchart algoritma dari broker sebagai MQTT Server. Diawali dengan menjalankan fungsi MQTT Broker, kemudian jika ada publish data terbaru dari publisher, maka akan diterima dan disimpan oleh broker. Ketika subscriber melakukan subscribe pada topik yang sama dengan publisher, maka data publish yang telah diterima oleh broker akan diteruskan ke subscriber.
4.7. Perancangan Subscriber
Start terbaru dari topik yang
disubscribe
Gambar 8. Alur Kerja Subscriber
Jika sudah sesuai, maka subscriber akan mencocokkan dengan database yang digunakan. Jika sesuai, maka publish data tersebut akan disimpan pada database.
5. HASIL PENGUJIAN PERFORMA Pengujian performa pertama yaitu pengujian delay yang terjadi saat pengiriman data oleh publisher hingga diterima subscriber tanpa melakukan input pada database. Pengujian dilakukan dengan menggunakan variasi publisher sebanyak 100, 250, dan 500 publisher yang mengakses dalam waktu yang sama. Hasil pengujian dapat dilihat pada Tabel 1 berikut:
Tabel 1. Hasil Pengujian Waktu Delay
Dari hasil pengujian pada Tabel 1, waktu delay yang terjadi juga berbanding lurus dengan jumlah publisher yang melakukan publish data. Waktu delay yang terjadi saat pengiriman data oleh publisher sebanyak 100 dan 250 publisher, memiliki waktu delay di bawah 1000 ms. Sedangkan pada pengujian dengan jumlah publisher sebanyak 500, menunjukkan waktu delay di atas 1000ms, sehingga hasil tersebut dapat dikatakan lebih buruk jika dibandingkan
dengan hasil dengan jumlah publisher di bawah 500 publisher. Dari penjelasan tesebut dapat disimpulkan, sistem dapat menangani jumlah publisher sebanyak < 500 publisher dalam satu waktu.
Berikutnya yaitu pengujian jumlah publisher yang dapat ditangani tiap detik. Pengujian dilakukan dengan menggunakan variasi publisher sebanyak 100, 250, dan 500 publisher yang mengakses dalam waktu yang sama. Hasil pengujian dapat dilihat pada Tabel 2 berikut:
Tabel 2. Hasil Pengujian Tingkat Skalabilitas
Dari Tabel 2, dapat dilihat hasil pengujian yang telah dilakukan, menunjukkan bahwa sistem mampu untuk menangani jumlah publisher hingga sebanyak 500 publisher, dengan tingkat kesuksesan sebesar 99%. Disamping itu, dari hasil pengujian menunjukkan, dengan pengujian sebanyak 500 publisher, rata-rata jumlah publisher yang tertangani di bawah 1 detik berjumlah 187 publisher.
6. KESIMPULAN
Berdasarkan hasil perancangan, implementasi, dan pengujian yang telah dilakukan sebelumnya, maka penulis mendapatkan kesimpulan sebagai berikut: 1. Mekanisme manajemen perangkat IoT,
authentication, dan authorization dapat dilakukan dengan membangun sebuah auth server berbasis protokol HTTP. Auth Server merupakan komponen yang bertugas untuk memeriksa koneksi yang akan dilakukan ke broker dan data yang akan melewatinya. Pemeriksaan tersebut meliputi authentication, superuser, dan authorization. Authentication bertujuan Publisher
100 56,73 250 173,38 500 450,37
100 91,81 250 1021,92 500 5786,104
100 112,7 250 810,332 500 3495,172
100 87,08 250 668,544 500 3243,882
Delay
Publisher Responded Success rate % Responded < 1 s
untuk memastikan validitas dari perangkat IoT yang mengirimkan data. Superuser bertujuan untuk memastikan validitas dari subscriber. Sedangkan authorization bertujuan untuk memastikan validitas dari topik yang digunakan oleh perangkat IoT saat mengirimkan data.
2. IoT cloud platform dibangun menggunakan protokol MQTT yang berpola publish-subscribe dengan arsitektur end-to-cloud. Dalam hal ini, end yang dimaksud merupakan perangkat IoT (node sensor) yang berada pada lapangan, bertindak sebagai publisher yang mengirimkan data yang telah diperoleh. Pada sisi lain, cloud yang dimaksud merupakan sistem IoT cloud platform yang terdiri dari subscriber, database, broker, serta auth server. Cloud bertindak sebagai storage dan juga penerima data yang dikirim oleh node sensor. Script publisher dan subscriber dikembangkan menggunakan Python dengan bantuan modul paho-mqtt.
3. Proses pengolahan data dimulai dari proses pengiriman data yang telah berhasil melalui proses authentication dan authorization. Setelah tahap tersebut, maka data akan diterima pada sisi subscriber. Subscriber memeriksa skema payload data tersebut, dan jika sesuai dengan skema database, maka data akan dimasukkan ke database berbasis MongoDB.
4. Dari hasil pengujian performa, didapatkan beberapa kesimpulan yaitu:
a. Delay yang terjadi saat pengiriman berbanding lurus dengan jumlah publisher yang melakukan koneksi. Sehingga dengan lebih sedikitnya jumlah publisher yang melakukan publish data dalam satu waktu, maka waktu delay akan semakin kecil.
b. Sistem dapat berperforma lebih baik pada tingkat jumlah publisher hingga 250 publisher, karena dengan hasil pengujian delay, menunjukkan rata-rata waktu delay yang terjadi memiliki hasil di bawah 1000 ms dibandingkan dengan tingkat jumlah publisher 500 publisher yang memiliki rata-rata waktu delay di atas 1000ms.
c. Tingkat skalabilitas yang dimiliki oleh sistem untuk menangani jumlah publisher dalam satu detik, rata-rata publisher yang tertangani dalam waktu
satu detik mencapai 191 publisher pada variasi jumlah publisher sebanyak 250 publisher dengan tingkat kesuksesan 100%, dan 187 publisher pada variasi jumlah publisher sebanyak 500 publisher dengan tingkat kesuksesan 99%.
d. Dari kesimpulan poin a dan b, dapat ditarik kesimpulan baru, bahwa sistem dapat menangani publisher dengan rentang jumlah publisher sebanyak 0 hingga 250.
7. DAFTAR PUSTAKA
Botta, A., Donato, W. d., Persico, V., & Pescape, A. (2016). Integration of Cloud Computing and Internet of Things: A Survey. Future Generation Computer Systems, 684-700.
Guoqiang, S., Yanming, C., Chao, Z., & Yanxu, Z. (2013). Design and Implementation of a Smart IoT Gateway. 2013 IEEE International Confrence on Green Computing and Communications and IEEE Cyber, Physical and Social Computing, 720-723.
Hunkeler, U., Truong, H. L., & Clark, A. S. (2015). A Publish/Subscribe Protocol For Wireless Sensor Network. IEEE. MQTT. (2016). Frequently Asked Question.
Diakses 8 Oktober, 2016, dari http://www.mqtt.org/faq
