Diterjemahkan dari bahasa Inggris ke bahasa Indonesia - www.onlinedoctranslator.

com

Metode Siklus Hidup untuk Manajemen Perangkat di IoT Dinamis

Lingkungan

Daniel Del Gaudio, Maximilian Reichel dan Pascal Hirmer

Institut Sistem Paralel dan Terdistribusi, Universitas Stuttgart, Universitätsstraße 38, Stuttgart, Jerman

Kata kunci: Internet of Things, Discovery, Integrasi Perangkat, Desentralisasi.

Abstrak: Di Internet of Things, perangkat yang saling berhubungan berkomunikasi satu sama lain melalui protokol internet standar untuk
mencapai tujuan bersama. Dengan demikian, mereka memungkinkan pembuatan aplikasi yang kompleks dan dapat diatur
sendiri, seperti Kota Cerdas, atau Pabrik Cerdas. Terutama di lingkungan IoT yang besar, perangkat yang baru muncul serta
perangkat IoT yang keluar atau gagal merupakan tantangan besar. Perangkat baru perlu diintegrasikan ke dalam

dkk., 2011).
Lingkungan IoT sangat dinamis, yang berarti perangkat lingkungan, (ii) model meta untuk menggambarkan struktur
masuk dan keluar dari lingkungan ini secara teratur. Namun, ini lingkungan IoT, (iii) metode siklus hidup untuk
mengarah pada tantangan besar untuk beradaptasi dengan mengintegrasikan perangkat baru ke dalam lingkungan
infrastruktur baru. Lebih tepatnya, perangkat yang gagal dapat yang ada mengenai kemampuan mereka dan persyaratan
menyebabkan kesalahan dalam aplikasi IoT atau, misalnya, lingkungan, dan (iv) arsitektur sistem untuk
memantau ketidakakuratan karena penurunan cakupan mengimplementasikan metode tersebut. Pendekatan kami
lingkungan dengan sensor. Sebaliknya, perangkat yang baru dievaluasi melalui implementasi prototipe arsitektur ini.
muncul dapat meningkatkan manfaat aplikasi IoT, misalnya, Dalam pendekatan kami, tujuannya adalah untuk
dengan sensor dan aktuator baru, daya komputasi, atau menjaga segala sesuatunya sedesentralisasi mungkin. Lebih
cakupan lingkungan yang lebih baik. Di Kota Cerdas, misalnya, tepatnya, jumlah komponen sentral harus dijaga serendah
mobil terhubung yang baru masuk perlu dipertimbangkan mungkin karena visi IoT berfokus pada komunikasi langsung
dalam pengaturan lalu lintas, sedangkan mobil yang keluar mesin-ke-mesin. Akibatnya, hanya satu komponen utama
dapat diabaikan. yang diperlukan dalam pendekatan kami, yang berupaya
Tujuan IoT adalah mengelola lingkungan yang mengintegrasikan perangkat baru ke dalam lingkungan IoT.
mungkin otonom dengan interaksi manusia sesedikit Perangkat, bagaimanapun, masih beroperasi dalam
mungkin. Ketika perangkat baru memasuki lingkungan distribusi yang lengkap dan terdesentralisasi

46
Gaudio, D., Reichel, M. dan Hirmer, P.
Metode Siklus Hidup untuk Manajemen Perangkat di Lingkungan IoT Dinamis. DOI:
10.5220/0009340900460056
Di dalam Prosiding Konferensi Internasional ke-5 tentang Internet of Things, Big Data, dan Keamanan (IoTBDS 2020), halaman 46-56 ISBN:
978-989-758-426-8
hak cipta ©c 2020 oleh SCITEPRESS – Publikasi Sains dan Teknologi, Lda. Seluruh hak cipta
 Metode Siklus Hidup untuk Manajemen Perangkat di Lingkungan IoT Dinamis
2
1
3 3
2 MOTIVASI
Dalam bab ini, kami memperkenalkan skenario yang
memotivasi, yang berfungsi sebagai sarana untuk menjelaskan
pendekatan kami dan, lebih jauh lagi, berfungsi sebagai dasar
untuk tujuan evaluasi. Domain dari skenario yang memotivasi ini
adalah Kota Cerdas. Di domain ini, terdapat sejumlah besar
perangkat, seperti Mobil Pintar atau Transportasi Pintar pada
umumnya, Perangkat yang dapat dikenakan yang dikenakan
oleh pejalan kaki, atau server tepi stasioner. Perangkat ini sangat
dinamis dan heterogen. Lebih tepatnya, sejumlah besar
perangkat masuk dan keluar dari lingkungan secara konstan.
Registrasi manual perangkat ini tidak mungkin karena
jumlahnya yang besar.
Perangkat dalam skenario kami saling berkomunikasi
tergantung pada kedekatan geografis, preferensi pengguna,
dipercaya karena data tiba sudah diproses sebelumnya.
Tantangan besar dalam skenario ini adalah mengintegrasikan
mobil yang baru masuk ke dalam aplikasi manajemen lalu lintas
sehingga mobil terdaftar, perangkat lunak yang diperlukan
diterapkan, dan mobil mulai mengirimkan data yang sesuai.
Untuk alasan yang jelas, seluruh proses perlu dilakukan
sepenuhnya secara otomatis.
Dengan kontribusi makalah ini, kami bertujuan untuk
memecahkan tantangan berikut dari skenario ini: (i)
penemuan dan pendaftaran perangkat IoT, dalam skenario
ini Mobil Pintar, (ii) penyebaran otomatis perangkat lunak
dan logika aplikasi pada perangkat IoT yang heterogen, ( iii)
pemrosesan data pada perangkat IoT untuk meningkatkan
privasi dan skalabilitas, dan (iv) komunikasi perangkat yang
lancar sesuai dengan aplikasi tertentu.
Skenario yang diperkenalkan digambarkan pada Gambar 1.
47
IOTBDS 2020 - Konferensi Internasional ke-5 tentang Internet of Things, Big Data, dan Keamanan
Pada gambar ini, pertama, mobil pintar mendaftarkan dirinya di
Unit Pinggir Jalan terdekat, yang digambarkan di bagian tengah
atas. Pada langkah kedua, Unit Sisi Jalan menyebarkan logika
aplikasi dan komponen perangkat lunak yang sesuai pada mobil.
Dalam skenario ini dan dalam ruang lingkup makalah ini, kami
berasumsi bahwa perangkat IoT memungkinkan komunikasi
semacam itu dan bersedia untuk berkolaborasi dengan aplikasi
IoT yang terlibat.
Akhirnya, setelah logika aplikasi yang sesuai
diterapkan, mobil dapat berkomunikasi dengan
mobil lain dan Unit Sisi Jalan di Kota Cerdas sesuai
dengan peraturan khusus, yang merupakan langkah
ketiga pada Gambar 1.
3 PEKERJAAN TERKAIT
kegagalan. Berbeda dengan pekerjaan kami, Seeger et al. secara
khusus fokus pada kegagalan perangkat dan pemulihannya
dalam lingkup koreografi IoT mereka. Perangkat yang baru
muncul, bagaimanapun, tidak ditemukan dan dipertimbangkan
secara otomatis. Selain itu, kami bertujuan untuk menciptakan
pendekatan yang lebih umum, yang tidak hanya berlaku khusus
untuk koreografi tetapi untuk semua jenis model.
Franco da Silva dkk. dan Hirmer dkk. (Hirmer et al., 2016;
Franco da Silva et al., 2020; Franco da Silva et al., 2019)
mengusulkan platform IoT baru MBP serta sarana untuk
memetakan operator ke perangkat IoT terdistribusi dan
menjalankannya. Namun, mereka tidak menyediakan
mekanisme apa pun untuk mengatasi perangkat yang baru
muncul atau kegagalan perangkat.
Kodeswaran dkk. (Kodeswaran et al., 2016) memperkenalkan
Idea – sebuah sistem untuk manajemen kegagalan yang efisien
di lingkungan IoT yang cerdas. Inti dari Ide
48
Pendekatan adalah sistem pusat, yang menyediakan sarana
untuk memantau kegagalan sensor dan, jika terjadi kegagalan,
komponen penjadwalan untuk pemeliharaan. Pekerjaan ini
sebagian besar berfokus pada aplikasi Smart Home. Berbeda
dengan Kodeswaran et al., kami tidak hanya mengatasi
perangkat yang gagal tetapi juga mengintegrasikan perangkat
baru ke dalam aplikasi IoT. Selanjutnya, pendekatan kami lebih
terdesentralisasi, sedangkan kerangka Ide menggambarkan
sistem pusat.
Mirip dengan Kodeswaran et al., Kapitanova et al.
(Kapitanova et al., 2012) memperkenalkan sistem untuk
menangani kegagalan tanpa henti di lingkungan Smart Home.
Deteksi kegagalan dilakukan dengan algoritma pembelajaran
mesin. Sebaliknya, kami bertujuan pada pendekatan
pemantauan yang lebih tradisional dan ringan, dan lebih jauh
lagi, kami juga menyediakan sarana untuk menangani perangkat
yang baru ditambahkan, tidak hanya perangkat yang gagal.
Sangat mirip dengan pendekatan kami adalah area penelitian
keburukan server dapat diambil (Shelby et al., 2014; Shelby
et al., 2013). Cirani dkk. (Cirani et al., 2014) mengusulkan
arsitektur untuk sumber daya otonom dan penemuan
layanan berbasis peer-to-peer di IoT. Arsitekturnya
menggunakan gateway IoT pusat dan antarmuka penemuan
sumber daya CoAP. Dalam makalah kami, kami memutuskan
untuk fokus pada pendekatan yang lebih umum untuk
penemuan dan integrasi perangkat yang tidak secara
khusus disesuaikan dengan CoAP.
Kesimpulannya, tinjauan literatur menyeluruh kami tentang
pekerjaan terkait menunjukkan bahwa meskipun sudah ada
banyak pekerjaan yang berfokus pada kegagalan perangkat atau
pada penemuan dan integrasi perangkat, belum ada pendekatan
gabungan, yang memberikan fleksibilitas, dinamika, dan generik
yang kami tuju dalam makalah ini.
 Metode Siklus Hidup untuk Manajemen Perangkat di Lingkungan IoT Dinamis
4 METAMODELS
Untuk perangkat heterogen yang dapat saling
berkomunikasi, kita memerlukan standar untuk
menggambarkan aplikasi dalam hal komunikasi.
Di bagian ini, kami memperkenalkan dua model
meta, yang membangun fondasi untuk metode siklus
hidup kami: (i) model pemrosesan data, menentukan
logika bisnis aplikasi IoT (Bagian 4.1), dan (ii)
deskripsi struktural lingkungan IoT , termasuk
perangkat, sensor, aktuator, jaringan, dan
komunikasi (Bagian 4.2).
Model-model ini diperlukan karena pemrosesan data harus
dipisahkan dari perangkat aktual yang menjalankan operasi
pemrosesan data, yang mengarah pada pemisahan masalah
yang jelas. Oleh karena itu, perangkat dapat ditambahkan,
dihapus, dan ditukar tanpa harus menyesuaikan model
pemrosesan. Selanjutnya, sebuah aplikasi-
persyaratan, sehingga memungkinkan untuk secara dinamis memilih
perangkat IoT yang tepat untuk operator.
Kami mendefinisikan model pemrosesan sebagai tupel DF =(
O,E,R, permintaan) dengan himpunan operasi HAI, himpunan
tepi berarah E = {e = (HaiSaya,Hai J)|oSaya,Hai J ∈ HAI},
menyatakan bahwa operasi HaiSaya harus dilakukan tepat
sebelum operasi Hai J , kumpulan persyaratan R, dan fungsi
permintaan : HAI → P (R), yang menghubungkan setiap operasi
ke serangkaian persyaratan. Contoh untuk model pemrosesan
dalam representasi JSON terlihat sebagai berikut:
{ Deskripsi struktural perlu diubah oleh perangkat
"flow_id": "TrafficLightFlow",
"flow": {
"1": {
"operasi": "SendPosition", "persyaratan":
["PositionSensor"], "next_oiid": "2"
},
"2": {
"operasi": "SetSignals", "persyaratan":
["TrafficSignals"], "next_oiid": "3"
},
"3": {
"operasi": "StopCar",
"persyaratan":
["AccelerationController"],
"next_oiid": tidak ada
},
}
}
Dalam contoh ini, aliran_id mendefinisikan nama unik untuk
setiap model pemrosesan. Setiap sub-elemen darimengalir
mewakili suatu operasi. berikutnya_oiid menunjukkan operasi
mana yang harus dijalankan setelah KirimPosisi Dan seterusnya.
Model pemrosesan digambarkan pada Gambar-
link L = {l = {DSaya,D J}|DSaya,D J ∈ D}, menyatakan perangkat ituD
Saya dapat berkomunikasi dengan perangkat D J dan sebaliknya,
dan seperangkat kemampuan C. Fungsinyatopi : D →
P (C) menghubungkan setiap perangkat dengan
seperangkat kemampuan untuk mencocokkannya
dengan persyaratan model pemrosesan. Fungsinyaw :→
Q mengaitkan setiap tautan dengan bobot tertentu.
Bobot tautan menunjukkan biaya pengiriman pesan
melalui tautan. Bobot link bisa sangat dinamis dan harus
dipantau selama runtime.
yang ditambahkan dan dihapus, yang merupakan
kontribusi utama dari makalah ini. Model dalam
representasi JSON ini ditunjukkan dalam contoh berikut:
{
"perangkat": {
49
IOTBDS 2020 - Konferensi Internasional ke-5 tentang Internet of Things, Big Data, dan Keamanan

KirimPosisi Atur Sinyal BerhentiMobil

SmartCar1 Lampu Lalu Lintas Cerdas SmartCar2

Operasi: Aliran data:

Gambar 2: Model Pengolahan Lampu Lalu Lintas.

} menjalankan model pemrosesan lingkungan IoT. Runtime

}
5 METODE SIKLUS HIDUP UNTUK
MANAJEMEN PERANGKAT
Kami mengusulkan metode siklus hidup generik dengan enam
langkah untuk mengintegrasikan perangkat IoT baru ke dalam
lingkungan yang ada, yang digambarkan pada Gambar 3. Metode
siklus hidup menjelaskan bagaimana satu perangkat dapat
diintegrasikan ke dalam lingkungan IoT yang ada untuk bekerja
dengan perangkat lain bersama-sama . Ini menjelaskan persyaratan
siklus masuk, keluar, dan masuk kembali ke lingkungan IoT dari satu
perangkat. Selanjutnya, kami mengusulkan arsitektur sistem yang
mengimplementasikan siklus hidup, yaitu
manajemen sekarang hanya bertanggung jawab untuk
memantau perangkat baru dan tidak terlibat dalam
koordinasi mesin-ke-mesin. Oleh karena itu, pemrosesan
data terdesentralisasi masih dapat dipastikan, yang
meningkatkan ketahanan karena tidak ada titik kegagalan
tunggal. Akhirnya, pada langkah terakhir 6 dari metode
siklus hidup kami, perangkat dihapus dari lingkungan, baik
secara sengaja atau karena kegagalan.
Rincian langkah-langkah ini dijelaskan di
bagian berikut.
5.1 Langkah 1: Penemuan Server
Langkah pertama dari metode siklus hidup kami adalah
penemuan server. Agar perangkat dapat terintegrasi dalam

50
 Metode Siklus Hidup untuk Manajemen Perangkat di Lingkungan IoT Dinamis

Langkah 1:

Server
Penemuan

Langkah 6: Langkah 2:

Perangkat Perangkat

Pemindahan Registrasi

Langkah 5:

Langkah kedua dari metode siklus hidup kami terdiri dari

server registrasi menerimanya dan mengirimkan respons, pendaftaran perangkat. Setelah perangkat baru menemukan
atau (iii) penemuan server diimplementasikan ke dalam alamat server pendaftaran (langkah 1), perangkat tersebut
jaringan melalui server DHCP atau DNS. mendaftarkan dirinya sendiri dengan mengirimkanpesan
Kami tidak mempertimbangkan lebih lanjut solusi pendaftaran ke server pendaftaran. Contoh pesan seperti itu
pertama, karena prakonfigurasi perangkat menghilangkan untuk skenario motivasi kami digambarkan sebagai berikut:
dinamika yang kami tuju dalam makalah ini. Misalnya, ketika
perangkat memasuki lingkungan yang berbeda, alamat
{
"perangkat": {
server pendaftaran mungkin berbeda dari yang telah
"nama": "SmartCar2",
dikonfigurasikan sebelumnya. Selanjutnya, alamat server "kemampuan": [
registrasi dapat berubah sewaktu-waktu. "AccelerationController",
Solusi ketiga memerlukan server DNS atau DHCP yang "Sensor Posisi",
"Kekuatan Pemrosesan Tinggi"
dikonfigurasi secara khusus dan, dengan demikian, juga
],
tidak dipertimbangkan lebih lanjut. Akibatnya, kami lebih
"address": "192.168.56.11", "mac":
memilih solusi kedua, karena dapat diimplementasikan oleh "12-43-b5-ae-fd-44-35",
sistem kami sendiri tanpa ketergantungan kritis. Agen "credentialGroup": "group2"
runtime pada perangkat mengirim pesan siaran ke jaringan },

51
IOTBDS 2020 - Konferensi Internasional ke-5 tentang Internet of Things, Big Data, dan Keamanan

Aplikasi
Waktu tayang
Pemodelan
Alat
Model
Pengelolaan Perangkat lunak
Pemetaan
Gudang

Model Pemrosesan

Lingkungan Perangkat
Perangkat Perangkat lunak
Pemodelan Registrasi
Konfigurasi Penyebaran
Alat dan Pemantauan

Model Struktural

Perangkat IoT
Perangkat IoT
2

Perpesanan Waktu tayang Perangkat IoT

Mesin Agen Pengontrol
1

Tepian
Server
Operator dan Adaptor

Lingkungan IoT

formasi tentang perangkat berdasarkan pesan

pendaftaran. Setelah langkah 2, perangkat didaftarkan
dan dapat diproses lebih lanjut.
5.3 Langkah 3: Penentuan Perangkat Lunak
Saat perangkat terdaftar di server pendaftaran, server
sekarang harus menentukan serangkaian operasi yang
sesuai, menerapkan logika bisnis spesifik dari aplikasi
IoT, dan menerapkannya di perangkat. Ini dilakukan
pada langkah 3 metode siklus hidup kami.
Kami menentukan tiga aspek yang perlu
dipertimbangkan untuk memilih operasi yang sesuai:
(i) kemampuan perangkat dalam hal sensor, aktuator,
dan daya pemrosesan, (ii) persyaratan operasi yang
tersedia dalam hal sensor, aktuator, dan pemrosesan
menyatakan bahwa Hai dapat dieksekusi oleh D dalam hal bahwa untuk
setiap kebutuhan D, Hai menawarkan kemampuan yang memuaskan.
Untuk perangkat baru D, sekarang kita dapat mencari
subset dari operasi
HAID = {Hai ∈ O|dapat dieksekusi Oleh(o, d) = 1}, (2)
yang berisi semua operasi yang dapat dieksekusi oleh D dan
dengan demikian memenuhi aspek (i) dan (ii).
Dalam hal aspek (iii), banyak karakteristik yang berbeda
harus dipertimbangkan ketika memilih operasi mana yang
paling "berguna" untuk suatu lingkungan. Kami
menganggap operasi sebagai yang paling berguna untuk
lingkungan jika itu adalah salah satu yang belum digunakan
pada perangkat sama sekali, memperluas cakupan aplikasi
dari lingkungan IoT.

52
 Metode Siklus Hidup untuk Manajemen Perangkat di Lingkungan IoT Dinamis
Selanjutnya, untuk memilih operasi yang sesuai untuk
dijalankan pada perangkat, kami mengevaluasi dua pola
pemrosesan yang perlu ditangani secara terpisah:
• Operasi Paralelisasi:
Operasi yang dapat diparalelkan dapat diskalakan secara
horizontal dengan menerapkan beberapa instance. Oleh
karena itu, saat menerapkan operasi semacam itu, perlu
dipertimbangkan apakah penskalaan diperlukan oleh
aplikasi IoT tertentu. Selanjutnya, jika semua operasi yang
tersedia sudah di-deploy, kami hanya mencari operasi yang
dapat diparalelkan.
• Operasi Unik:
Operasi unik harus unik di dalam lingkungan,
misalnya, karena semua data yang diproses oleh
operasi harus dikonsolidasikan dalam satu
instance. Operasi unik harus dipertimbangkan
secara terpisah saat memilih operasi
komponen harus disimpan dalam penyimpanan perangkat lunak
yang merupakan bagian dari server pendaftaran, seperti yang
ditunjukkan pada arsitektur sistem kami (lih. Gambar 4).
Komponen perangkat lunak ini dapat berkisar dari skrip
sederhana hingga aplikasi perangkat lunak canggih, sedangkan
hanya komponen ringan yang dapat digunakan ke perangkat
keras IoT yang dibatasi sumber daya. Keputusan ini telah dibuat
pada langkah sebelumnya Penentuan Perangkat Lunak.
Komponen Software Deployment dari arsitektur kami
mengekstrak komponen perangkat lunak yang diperlukan dari
repositori perangkat lunak, menghubungkan ke perangkat, dan
mulai menginstal perangkat lunak dan semua dependensi yang
diperlukan. Langkah penyebaran ini dapat diimplementasikan
secara manual menggunakan, misalnya, koneksi SSH, atau
dengan cara yang lebih canggih. Salah satu pendekatan untuk
strategi penyebaran perangkat lunak yang lebih kuat ditawarkan
oleh standar OASIS TOSCA (OA-
SIS, 2013a; OASIS, 2013b). Implementasi open-source
TOSCA, misalnya, disediakan oleh OpenTOSCA (Binz
et al., 2014). Dengan menggunakan pendekatan
berbasis standar, seperti TOSCA, strategi penerapan
lebih tahan masa depan daripada pendekatan
berbasis nonstandar.
Setelah semua aplikasi di-deploy, mesin pesan
pada perangkat (bertanggung jawab atas komunikasi
mesin-ke-mesin) harus dikonfigurasi dengan tepat.
Mesin perpesanan membutuhkan operasi yang dapat
dilakukannya, bagian dari model pemrosesan yang
diikutinya, dan informasi simpul perangkat yang
harus berinteraksi dengannya.
Lebih lanjut, mesin perpesanan pada perangkat lain yang perlu
berinteraksi dengan perangkat baru memerlukan informasi tentang
perangkat yang baru muncul, lebih khusus lagi, operasi apa yang
disediakannya dan bagaimana mereka dapat berinteraksi dengannya.
Yang lebih sederhana tapi kurang skala-
bijak dan mengarah ke solusi yang lebih disesuaikan.
5.5 Langkah 5: Pemrosesan dan
Pemantauan Data
Setelah penyebaran komponen perangkat lunak yang
diperlukan, perangkat yang baru ditambahkan siap untuk
memproses data. Itu dapat menerima, memproses, dan
meneruskan data sesuai dengan model pemrosesan. Sistem
kami sekarang juga dapat memantau perangkat di lingkungan.
Untuk mewujudkan hal ini, setiap agen runtime mengirimkan
pesan kesehatan ke server secara berkala. Frekuensi sangat
tergantung pada kasus penggunaan, yaitu, seberapa kritis
kegagalan perangkat mempengaruhi kesehatan aplikasi.
Ketika server tidak menerima pesan kesehatan dari
perangkat untuk jangka waktu tertentu, itu mengasumsikan
53
IOTBDS 2020 - Konferensi Internasional ke-5 tentang Internet of Things, Big Data, dan Keamanan
bahwa perangkat telah meninggalkan lingkungan secara tidak
sengaja, misalnya karena terjadi kegagalan perangkat. Jika perangkat
meninggalkan lingkungan secara sukarela, perangkat tersebut akan
membatalkan pendaftarannya sendiri. Ini akan dibahas secara lebih
mendalam pada langkah 6. Jangka waktu ditentukan dalamttldi dalam
pilihan dalam pesan pendaftaran seperti yang diperkenalkan di
Bagian 5.2. Periode waktu ini dapat bersifat individual untuk setiap
perangkat, karena lingkungan IoT cenderung sangat heterogen.
Untuk mencegah lalu lintas jaringan yang tidak perlu, memilih
periode waktu yang tepat di mana perangkat mengirim pesan detak
jantung mereka harus dipertimbangkan dengan bijak.
Selanjutnya, untuk pemantauan kesehatan perangkat,
metrik penting adalah bobot tautan (lih. Bagian 4)
dan pemanfaatan sumber daya perangkat. informasi
Pemantauan
dapat
digunakan untuk mendeteksi kemacetan dan bereaksi sesuai,
misalnya, dengan menerapkan perangkat lunak tambahan pada
perangkat untuk menskalakan aplikasi.
melakukan salah satu operasi yang dilakukan perangkat yang
keluar, server pendaftaran dapat menginisialisasi perangkat
baru dengan data cadangan. Dengan begitu, bisa dipastikan
tidak ada data yang tertinggal. Tentu saja, data ini perlu
dilampirkan dengan rentang waktu hingga menjadi basi.
Terutama streaming data di IoT menjadi sangat cepat basi,
sehingga kehilangan kegunaannya setelah beberapa saat.
Saat perangkat meninggalkan lingkungan secara tidak sengaja,
kehilangan data hanya dapat dicegah dengan menyimpan semua
data secara terus-menerus di perangkat dengan harapan data
tersebut masuk kembali. Namun, jika tidak demikian, semua data
yang disimpan di perangkat pada saat kegagalan akan hilang. Salah
satu solusi untuk mengatasi masalah ini adalah backup berkala.
Namun, perlu dipertimbangkan bahwa pencadangan ini
menyebabkan overhead yang signifikan terkait komputasi dan
sumber daya jaringan. Oleh karena itu, tradeoff ini perlu
dipertimbangkan dengan hati-hati untuk setiap aplikasi.
54
tion secara terpisah.
Setelah langkah terakhir dari metode siklus hidup kami,
perangkat meninggalkan lingkungan. Setiap saat, perangkat
dapat masuk kembali dan seluruh metode diinisialisasi ulang.
Perhatikan bahwa jika perangkat sudah berisi komponen
perangkat lunak yang diperlukan saat masuk kembali, metode
ini dapat dipercepat secara signifikan. Dengan demikian, ini juga
mempertimbangkan iterasi sebelumnya.
6 PROTOTIPE DAN PEMBAHASAN
Untuk mengevaluasi konsep kami, kami menerapkan
prototipe manajemen runtime dan agen runtime, yang
berjalan di perangkat itu sendiri (lih. Gambar 4).
Aplikasi agen diimplementasikan dengan Python
untuk menjamin tingkat ringan tertentu karena
Raspberry Pis terpasang ke berbagai sensor dan
aktuator yang menjadi tuan rumah agen. Mesin virtual di
cloud pribadi menghosting komponen manajemen
runtime. Menggunakan infrastruktur yang fleksibel
seperti itu memungkinkan penskalaan komponen
manajemen runtime dengan mudah dan mencegahnya
menjadi satu titik kegagalan.
Untuk menyiapkan komponen manajemen runtime kami,
beberapa langkah sederhana perlu dilakukan, sehingga
memudahkan pengaturan dalam skenario yang berbeda oleh
pemangku kepentingan yang berbeda. Pertama, manajemen
runtime perlu diterapkan pada server aplikasi yang berjalan,
misalnya, pada mesin virtual di cloud atau bahkan di
1https://www.mongodb.com
2https://www.openstack.org
3https://www.raspberrypi.org
 Metode Siklus Hidup untuk Manajemen Perangkat di Lingkungan IoT Dinamis
sebuah perangkat IoT. Kedua, agen runtime harus diinstal pada
setiap perangkat IoT yang terlibat dalam skenario. Selanjutnya,
setiap perangkat memerlukan prakonfigurasi kecil untuk dapat
berbagi kemampuannya dengan manajemen runtime. Untuk
banyak perangkat IoT, kami menyarankan untuk
mengotomatiskan langkah penginstalan dan konfigurasi ini,
misalnya menggunakan TOSCA atau alat penerapan terkenal
lainnya, seperti Ansible4.
Seperti disebutkan sebelumnya, semua perangkat lunak
tambahan yang diperlukan untuk skenario tertentu harus
disimpan dalam repositori perangkat lunak dan diinstal secara
otomatis oleh manajemen runtime sesuai dengan model
pemrosesan untuk skenario dan kemampuan perangkat pada
langkah 4 metode siklus hidup kami.
Prototipe kami menunjukkan bahwa konsep kami dapat
mengatasi tantangan yang tercantum di Bagian 2. Perangkat
secara otomatis terdaftar ketika mereka memasuki area
lingkungan kami dan terhubung ke Wi-Fi (i). Lembut-
Manajemen Perangkat di Lingkungan IoT Dinamis. Dengan
menggunakan metode ini, perangkat yang baru muncul dapat
diintegrasikan dengan mulus ke dalam aplikasi IoT tanpa
memerlukan langkah manual yang memakan waktu. Selain itu,
kami memperkenalkan konsep yang memungkinkan
penanganan perangkat yang gagal atau perangkat yang secara
sukarela ditinggalkan. Metode siklus hidup kami dibangun di
atas model meta, yang menjelaskan pemrosesan data dan
lanskap infrastruktur IoT. Berdasarkan model ini, perangkat
yang baru muncul dapat ditemukan, terdaftar, perangkat lunak
yang diperlukan dapat diinstal dan dapat diintegrasikan untuk
pemrosesan data dalam aplikasi IoT. Akhirnya, perangkat dapat
dihentikan baik secara sukarela atau ketika gagal. Bahkan jika
terjadi kegagalan, kami dapat mendukung aplikasi IoT dalam
menyediakan cara pemrosesan data yang kuat sehingga aplikasi
4https://www.ansible.com/
kation tidak gagal ketika perangkat tunggal melakukannya.
Kami menerapkan prototipe untuk metode siklus hidup
kami untuk memberikan bukti konsep. Di masa depan, kami
bertujuan untuk menerapkan prototipe ini ke skenario yang
lebih kompleks untuk menunjukkan kekuatan pendekatan
kami ke tingkat yang lebih besar.
UCAPAN TERIMA KASIH
Pekerjaan ini sebagian didanai oleh Kementerian
Ekonomi dan Energi Jerman dalam lingkup proyek
IC4F (01MA17008).
REFERENSI
Del Gaudio, D. dan Hirmer, P. (2019). Sebuah mes-
saging engine untuk pemrosesan data terdesentralisasi di
internet of things. Sistem Fisik-Siber Intensif Perangkat
Lunak SICS.
Franco da Silva, AC, Hirmer, P., dan Mitschang, B.
(2019). Penempatan operator berbasis model untuk
pemrosesan data di lingkungan iot. Di dalamKonferensi
Internasional IEEE 2019 tentang Komputasi Cerdas
(SMART-COMP), halaman 439–443. IEEE.
Franco da Silva, AC, Hirmer, P., Schneider, J., Ulusal,
S., dan Tavares Frigo, M. (2020). Mbp: Bukan hanya
platform bodoh. Di dalamProsiding IEEE Intl
Tahunan ke-18. Konferensi Komputasi Pervasif dan
Komunikasi.
Fredj, SB, Boussard, M., Kofman, D., dan Noirie, L.
(2014). Mekanisme penemuan layanan iot berbasis semantik yang
efisien untuk lingkungan yang dinamis. Di dalamSimposium
Internasional Tahunan IEEE 25 Tahun 2014 tentang Pribadi,
55
IOTBDS 2020 - Konferensi Internasional ke-5 tentang Internet of Things, Big Data, dan Keamanan

Komunikasi Radio Dalam Ruangan dan Seluler (PIMRC), Vermesan, O. dan Friess, P. (2013). Internet hal: con-
halaman 2088–2092. IEEE. teknologi ambang untuk lingkungan cerdas dan
Granell, C., Kamilaris, A., Kotsev, A., Ostermann, FO, ekosistem terintegrasi. penerbit sungai.
dan Trilles, S. (2020). Internet untuk segala, halaman 387–
423. Springer Singapura, Singapura.
Harper, R. (2006). Di dalam rumah pintar. Ilmu Musim Semi
& Media Bisnis.
Hirmer, P., Breitenbücher, U., da Silva, ACF, Kepes, K.,
Mitschang, B., dan Wieland, M. (2016).
Mengotomatiskan Penyediaan dan Konfigurasi
Perangkat di Internet of Things.Sistem Informatika dan
Pemodelan Kompleks Triwulanan, 9:28–43.
Kapitanova, K., Hoque, E., Stankovic, JA, Gedung Putih,
K., dan Putra, SH (2012). Menjadi pintar tentang kegagalan:
Menilai perbaikan di rumah pintar. Di dalamProsiding
Konferensi ACM 2012 tentang Komputasi Ubiquitous,
UbiComp '12, halaman 51–60, New York, NY, AS. ACM.

Kodeswaran, PA, Kokku, R., Sen, S., dan Srivatsa, M.

(2016). Ide: Sebuah sistem untuk manajemen kegagalan yang efisien-

OASIS (2013b). Primer TOSCA. On line.

Peltz, C. (2003). Orkestrasi dan koreografi layanan web
rapy. Komputer, (10):46–52.
Seeger, J., A. Deshmukh, R., Sarafov, V., dan Bröring, A.
(2019). Koreografi iot dinamis.Komputasi
Pervasif IEEE, 18:19–27.
Shelby, Z., Bormann, C., dan Krco, S. (2013). inti kembali
direktori sumber.
Shelby, Z., Hartke, K., dan Bormann, C. (2014). Kon-
protokol aplikasi tegang (coap). Laporan teknikal.
Su, K., Li, J., dan Fu, H. (2011). Kota pintar dan aplikasi-
aplikasi. Di dalamKonferensi internasional 2011 tentang
elektronik, komunikasi dan kontrol (ICECC), halaman 1028–
1031. IEEE.
Tanganelli, G., Vallati, C., dan Mingozzi, E. (2015).
Coapthon: Pengembangan aplikasi iot berbasis coap yang
mudah dengan python. Di dalam2015 IEEE 2nd World Forum
on Internet of Things (WF-IoT), halaman 63–68. IEEE.

56