Rancang Bangun IOT Cloud Platform Berbasis Protokol Komunikasi MQTT

  Vol. 2, No. 2, Februari 2018, hlm. 479-485 http://j-ptiik.ub.ac.id

  

Rancang Bangun IOT Cloud Platform Berbasis Protokol Komunikasi

₁ MQTT _{2 3} Moh. Wildan Habibi , Adhitya Bhawiyuga , Achmad Basuki

  Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya _{1 2 3} Email: mohwildannhabibi@gmail.com, bhawiyuga@ub.ac.id, abazh@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.

  IoT, cloud, platform, mqtt, authentication, authorization.

  Kata kunci:

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.

  & Yanxu, 2013). Penerapan IoT menjadikan 1.

   PENDAHULUAN aktivitas dalam berbagai bidang dapat saling

  terhubung melalui Internet, serta menjadi lebih

  Internet of Things (IoT), merujuk pada

  mudah dan efisien. Contohnya seperti, seorang suatu jaringan yang menghubungkan berbagai petani dapat mengetahui suhu dan kelembapan perangkat dalam dunia fisik dengan berbagai lahannya dari tempat yang lain, karena protokol berbeda (Guoqiang, Yanming, Chao,

  Fakultas Ilmu Komputer Universitas Brawijaya

479 perangkat IoT yang tersebar pada lahan tersebut saling berbagi informasi dan dapat diakses melalui Internet.

  Things

  Prinsip dari model komunikasi publish /

  2.2. MQTT (Message Queue Telemetry Transport)

  Gambar 1. Model Komunikasi Topic-Based Publish/Subscribe

  keinginan akan informasi dari para subscriber, dan subscriber biasanya secara eksplisit akan melakukan kontak dengan broker untuk melakukan subscribe (Hunkeler, Truong, & Clark, 2015).

  Broker bertugas untuk mengkoordinasi

  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.

  subscribe . Sedangkan kumpulan komponen

  menginginkan sejumlah informasi yang sesuai dengan topik mereka inginkan dengan cara mendaftarkan topik apa yang diinginkan. Proses mendaftarkan topik ini disebut dengan

  subscribe yaitu beberapa komponen yang

  2.1. Pengertian

  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.

  2. ARSITEKTUR KOMUNIKASI PUBLISH/SUBSCRIBE

  authentication , dan authorization.

  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,

  platform

  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

  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.

  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.

  cloud adalah kumpulan objek computing resources yang dapat dikonfigurasi secara tepat

  Zhang et al (2010) menyebutkan bahwa

  MQTT merupakan singkatan dari Message Queue Telemetry Transport. Ini merupakan protokol komunikasi publish/subscribe topic-

  based yang sangat sederhana dan ringan, yang

  , dan Delete pada database yang digunakan.

  akan meneruskan data yang diperoleh dari publisher .

  subscriber , dan jika topik sama, maka broker

  yang telah dipublish oleh publisher sebelumnya. Kemudian broker membalas informasi subscriber dengan menyesuaikan identitas topik yang sama antara publisher dan

  publisher jika ingin mendapatkan informasi

  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 sehingga tidak semua dapat menerima

  informasi data sensor yang telah didapat menuju broker dengan melakukan inisialisasi topik. Dimana topik digunakan sebagai alamat tujuan yang dikirimkan melalui broker dari

  Publisher yaitu node sensor mengirimkan

  antara publisher dan subscriber atau istilah lain broker dikenal sebagai MQTT server .

  subscribe MQTT. Protokol MQTT memiliki broker sebagai pusat pertukaran informasi

  Secara umum terlihat bahwa konsep komunikasi yang digunakan merupakan konsep komunikasi arsitektur umum dari publish

  4.1. Gambaran Umum Sistem Gambar 2. Alur Komunikasi Data Sistem

  4. PERANCANGAN SISTEM

  Web app dapat melakukan Create, Read, Update

  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

  Web app dapat menampilkan data - data yang telah dikumpulkan pada database.

  Subscriber dapat menerima data dari broker dan dapat mengolah data - data yang telah diperoleh sebelumnya untuk dimasukkan ke dalam database atau tidak, e.

  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.

  publisher dan subscriber, serta melakukan

  dikirim oleh node sensor. Broker melakukan proses authentication terhadap setiap koneksi yang akan dibangun oleh

  subscriber , serta dapat menerima data yang

  MQTT, c. Broker dapat menerima koneksi yang dibuat oleh publisher (node sensor) dan

  Node sensor dapat memperoleh data dari sensor yang dimiliki oleh node sensor tersebut, b. Node sensor dapat mengirimkan data menuju broker menggunakan protokol

  Kebutuhan sistem IoT cloud platform yang dibangun pada penelitian ini dijelaskan sebagai berikut: a.

  3.2. Analisis Kebutuhan Sistem

  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.1. Analisis Kebutuhan Pengguna

  Rekayasa kebutuhan untuk menganalisis beberapa kebutuhan yang diperlukan pada penelitian ini. Rekayasa kebutuhan pada penelitian ini dijelaskan sebagai berikut:

  bandwidth dan daya baterai pada keadaan yang cukup (MQTT, 2016).

3. REKAYASA KEBUTUHAN

4.2. Alur Kerja Penanganan Publisher

  Gambar 4. Alur Kerja Penanganan Subscriber

  direpresentasikan dalam dokumen-dokumen BSON (Binary JSON).

  document-oriented , dimana data

  Pada perancangan skema database ini akan digambarkan skema database yang akan digunakan. Database menggunakan MongoDB, yang merupakan sistem basis data berbasis

  4.4. Perancangan Skema Database

  melakukan subscriber pada topik yang telah ditentukan oleh subscriber . Permintaan melakukan subscribe pada topik tertentu akan dikirimkan terlebih dahulu oleh subscriber menuju broker.

  broker , maka tahap selanjutnya subscriber akan

  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

  check authentication . Auth server menerima

  dikirimkan oleh subscriber akan diambil dan dikirim menuju auth server untuk dilakukan

  subscriber tersebut, maka data koneksi yang

  pada topik tertentu maka diharuskan untuk membangun koneksi terlebih dahulu. Broker mendeteksi adanya permintaan koneksi dari

  subscriber yang akan melakukan susbscribe

  Pada Gambar 4 ditunjukkan bahwa proses operasi pada sistem dimulai pada dimulai dari

  _{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

  menuju subscriber meskipun dengan topik yang sama.

  publish tersbut dan tidak akan meneruskannya

  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 akan disimpan sementara oleh broker

  dari auth server tentang check authorization, jika respon tersebut bernilai positif, maka data

  server kepada broker. Broker menerima respon

  tersebut akan bertindak sebagai respon dari auth

  authorization . Pada auth server melakukan check authorization dan hasil dari pemeriksaan

  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

  publisiher akan diambil dan dikirim menuju auth server untuk dilakukan check authentication . Auth server menerima

  maka diharuskan untuk membangun koneksi terlebih dahulu. Broker mendeteksi adanya permintaan koneksi dari publisher tersebut, maka data koneksi yang dikirimkan oleh

  node sensor yang akan melakukan publish data

  Pada Gambar 3 ditunjukkan bahwa proses operasi pada sistem dimulai pada dimulai dari

  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 _{Data sensor diterima meneruskan publish data sensor sesuai topik dari publisher kepada subscriber} ^{Auth server mendeteksi permintaan check authentication, melakukan proses dan memberikan respon} _{subscriber, dan dimasukkan ke dalam database}

  _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

  data dari publisher dengan topik tertentu, kemudian meneruskan publish data ke

  apakah sudah memenuhi parameter yang sudah ada pada perancangan publisher.

  subscriber akan memeriksa data payload

  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

  4.7. Perancangan Subscriber Subscriber bertugas untuk menerima

  subscriber .

  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

  Server . Diawali dengan menjalankan fungsi

  Pada Gambar 7, menggambarkan flowchart algoritma dari broker sebagai MQTT

  Gambar 7. Alur Kerja Broker

  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}

  4.6. Perancangan Broker Broker bertugas untuk menerima publish

  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

  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.

  request

  kondisi siap digunakan jika tidak ada check

  Server berjalan, maka akan selalu dalam

  Pada Gambar 6, menggambarkan flowchart algoritma dari Auth Server. Jika Auth

  ^Tidak broker ^{Check authen tication} _{Check superuser} Check ^Ya _{authorization} ^{Tidak Tidak Melakukan check authen tication pada database Melakukan check user superuser pada database Melakukan check} _{authorization pada database} ^{Ya Ya} _Ya ^{Aplikasi berhenti Memberikan resp ond ke broker Tidak End Ya} Gambar 6. Alur Kerja Auth Server

  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}

  Auth Server bertugas untuk melakukan

  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.

  record jika pada database relasional. Koleksi

4.5. Perancangan Auth Server

  Start _{Membangun koneksi dengan broker} Berhasil terkoneksi _{dengan broker Subscribe top ic 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 paylo ad 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

  publisher

  1 500 495 99% 109 500 496 99% 187 Scalability

  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%

  Jika sudah sesuai, maka subscriber akan mencocokkan dengan database yang digunakan. Jika sesuai, maka publish data tersebut akan disimpan pada database.

  Tabel 2. Hasil Pengujian Tingkat Skalabilitas

  sama. Hasil pengujian dapat dilihat pada Tabel 2 berikut:

  publisher yang mengakses dalam waktu yang

  Pengujian dilakukan dengan menggunakan variasi publisher sebanyak 100, 250, dan 500

  publisher yang dapat ditangani tiap detik.

  sebanyak < 500 publisher dalam satu waktu. Berikutnya yaitu pengujian jumlah

5. HASIL PENGUJIAN PERFORMA

  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

  authentication, dan authorization dapat

  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

  publish er yang mengakses dalam waktu yang

  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

  Delay (ms) Publisher Average Delay (ms) Publisher Average

  authentication , superuser , dan authorization. Authentication bertujuan Publisher Average

  Pemeriksaan tersebut meliputi

  broker dan data yang akan melewatinya.

  merupakan komponen yang bertugas untuk memeriksa koneksi yang akan dilakukan ke

  server berbasis protokol HTTP. Auth Server

  dilakukan dengan membangun sebuah auth

  1. Mekanisme manajemen perangkat IoT,

  publisher sebanyak 500, menunjukkan waktu

  Berdasarkan hasil perancangan, implementasi, dan pengujian yang telah dilakukan sebelumnya, maka penulis mendapatkan kesimpulan sebagai berikut:

  6. KESIMPULAN

  tertangani di bawah 1 detik berjumlah 187 publisher.

  publisher , rata-rata jumlah publisher yang

  Disamping itu, dari hasil pengujian menunjukkan, dengan pengujian sebanyak 500

  sama. Hasil pengujian dapat dilihat pada Tabel 1 berikut:

  Dari Tabel 2, dapat dilihat hasil pengujian yang telah dilakukan, menunjukkan bahwa sistem mampu untuk menangani jumlah

  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 hingga sebanyak 500 publisher, dengan tingkat kesuksesan sebesar 99%. untuk memastikan validitas dari perangkat IoT yang mengirimkan data. Superuser bertujuan untuk memastikan validitas dari

  subscriber.

  Dari kesimpulan poin a dan b, dapat ditarik kesimpulan baru, bahwa sistem dapat menangani publisher dengan rentang jumlah publisher sebanyak 0 hingga 250.

  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.

  7. DAFTAR PUSTAKA

  c.

  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).

  Tingkat skalabilitas yang dimiliki oleh sistem untuk menangani jumlah

  publisher yang memiliki rata-rata waktu delay di atas 1000ms.

  Sedangkan

  bertindak sebagai storage dan juga penerima data yang dikirim oleh node sensor. Script publisher dan subscriber dikembangkan menggunakan Python dengan bantuan modul paho-mqtt.

  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

  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.

  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

  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.

  Cloud computing: state-of-the-art and research challenges. J Internet Serv Appl, I, 7-18.