Fakultas Ilmu Komputer
Universitas Brawijaya
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,
& Yanxu, 2013). Penerapan IoT menjadikan aktivitas dalam berbagai bidang dapat saling terhubung melalui Internet, serta menjadi lebih mudah dan efisien. Contohnya seperti, seorang petani dapat mengetahui suhu dan kelembapan lahannya dari tempat yang lain, karena
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 cloud computing 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
Secara umum terlihat bahwa konsep komunikasi yang digunakan merupakan konsep komunikasi arsitektur umum dari publish
subscribe MQTT. Protokol MQTT memiliki broker sebagai pusat pertukaran informasi
antara publisher dan subscriber atau istilah lain
broker dikenal sebagai MQTT server. Publisher yaitu node sensor mengirimkan
informasi data sensor yang telah didapat menuju broker dengan melakukan inisialisasi topik. Dimana topik digunakan sebagai alamat tujuan yang dikirimkan melalui broker dari
publisher sehingga tidak semua dapat menerima
informasi tersebut jika tidak mengetahui topik yang digunakan. Sedangkan subscriber untuk mendapatkan pesan dari publisher, subscriber harus melakukan request atau subscribe topik yang sama dengan topik yang dikirimkan
publisher jika ingin mendapatkan informasi
yang telah dipublish oleh publisher
sebelumnya. Kemudian broker membalas
informasi subscriber dengan menyesuaikan identitas topik yang sama antara publisher dan
subscriber, dan jika topik sama, maka broker
akan meneruskan data yang diperoleh dari
4.2. Alur Kerja Penanganan Publisher
Node sensor membangun koneksi
dengan broker
Broker mendeteksi koneksi baru, meneruskan ke auth server untuk check
authentication
Auth server mendeteksi permintaan check authentication, melakukan proses dan memberikan respon Publisher node sensor
publish data berupa data yang didapat dari sensor menuju broker menggunakan
topik tertentu
Respon diterima, dan diteruskan ke publisher
Broker mendeteksi permintaan publish, 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
authentication
Auth server mendeteksi permintaan check authentication, melakukan proses dan memberikan respon
Subscriber melakukan subscribe topik menuju
broker
Respon diterima, dan diteruskan ke subscriber
Broker mendeteksi permintaan subscribe, 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
Auth server mendeteksi permintaan check authentication, melakukan proses dan memberikan respon
Data sensor diterima subscriber, dan dimasukkan
ke dalam database
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
Pada perancangan skema database ini akan digambarkan skema database yang akan digunakan. Database menggunakan MongoDB, yang merupakan sistem basis data berbasis
document-oriented, dimana data direpresentasikan dalam dokumen-dokumen BSON (Binary JSON).
_id: <ObjectId1> username: <string> password: <string> email: <string> firstname: <string> is_admin: <int> _id: <ObjectId2> user: <ObjectId1> label: <string> secretkeyl: <string> subsperday: <int> subsperdayremain: <int> is_public: <int> _id: <ObjectId3> Label: <string> _id: <ObjectId4> node: <ObjectId2> sensor: <ObjectId3> data: <int> timestamp: <ISODate>
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. Start Menunggu check request dari broker Ada check request dari broker Tidak Check authentication Check superuser Check authorization Ya Tidak Tidak Melakukan check authentication pada database Melakukan check user superuser pada database Melakukan check authorization pada database Ya Ya Ya Aplikasi berhenti Memberikan respond ke broker Tidak End Ya
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.
Start Menunggu permintaan koneksi Koneksi dengan Publisher Koneksi dengan Subscriber Tidak Ya Ya Menerima publish data dari publisher sesuai dengan topik yang digunakan
Meneruskan publish data sesuai dengan topik yang di subscribe Publisher publish
data Koneksi terbangun
Koneksi tetap berjalan Ya
Koneksi terbangun
Ada publish data terbaru
Koneksi tetap berjalan Ya Tidak Ya Tidak Tidak Tidak End Ya A B A B
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
Subscriber bertugas untuk menerima
seluruh publish data yang sudah diperiksa oleh
broker, serta memasukkannya ke database.
Pada Gambar 8, menggambarkan flowchart algoritma dari subscriber. Diawali dengan koneksi dengan broker. Broker akan melakukan pemeriksaan dari setiap koneksi yang akan dibangun. Setelah terkoneksi, maka subscriber akan siap untuk menerima publish data. Jika terdapat publish data yang diterima, maka
subscriber akan memeriksa data payload
apakah sudah memenuhi parameter yang sudah ada pada perancangan publisher.
Start Membangun koneksi dengan broker Berhasil terkoneksi dengan broker Subscribe topic yang digunakan Menerima data terbaru dari topik yang
disubscribe Koneksi terputus Aplikasi berhenti End Tidak Tidak Tidak Ya Ya Ya Ya Tidak Mendapatkan data payload terbaru Memeriksa kesamaan data payload dengan skema database Data payload Sesuai dengan skema
database Data payload dimasukkan ke database Data payload tidak dimasukkan ke database Ya Tidak A A
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 Average Delay (ms) Publisher Average Delay (ms) Publisher Average Delay (ms) 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
100 100 100% 100 100 100 100% 100 100 100 100% 100 100 100 100% 100 250 250 100% 250 250 250 100% 156 250 250 100% 167 250 250 100% 191 500 500 100% 451 500 493 99% 1 500 495 99% 109 500 496 99% 187 Scalability
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
Zhang, Q., Cheng, L., & Boutaba, R. (2010). Cloud computing: state-of-the-art and research challenges. J Internet Serv Appl, I, 7-18.
