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

com

Lihat diskusi, statistik, dan profil penulis untuk publikasi ini di:https://www.researchgate.net/publication/282307190

Arsitektur referensi berbasis iot untuk proses pengelolaan air pintar

Artikel· Januari 2015

KUTIPAN BACA
109 12.839

7 penulis, termasuk:

Tomas Robles Ramon Alcarria

Universidad Politécnica de Madrid Universidad Politécnica de Madrid

50PUBLIKASI456KUTIPAN 180PUBLIKASI1,227KUTIPAN

LIHAT PROFIL LIHAT PROFIL

Mariano Navarro Rodrigo Calero

Grupo Tragsa Grupo Tragsa

13PUBLIKASI211KUTIPAN 45PUBLIKASI 222KUTIPAN

LIHAT PROFIL LIHAT PROFIL

Beberapa penulis publikasi ini juga mengerjakan proyek terkait ini:

Infraestructura para presentación de información visual de bajo consumo y mantenimiento basada en pantallas de tinta electrónica.Lihat proyek

Karto-IoTLihat proyek

Semua konten yang mengikuti halaman ini diunggah olehRamon Alcarriapada 19 Mei 2016.

Pengguna telah meminta peningkatan file yang diunduh.

Arsitektur referensi berbasis IoT untuk pengelolaan air pintar
proses

Tomas Robles1, Ramon Alcarria2Keahlian, Diego Martn1,

Mariano Navarro3, Rodrigo Calero3, Sofia Iglesias3, dan Manuel López3
1Dep. de Ingenierı́a de Sistemas Telemáticos
2Dep. de Ingenierı́a Topográfica y Cartografı́a
Universidad Politécnica de Madrid, Spanyol {
tomas.robles, ramon.alcarria, diego.martin}@upm.es
3Unit inovasi dan R&D
Grup Tragsa, Spanyol
{mnc, rcalero, siglesias, mlopez}@tragsa.es

Abstrak
Air merupakan sumber daya vital bagi kehidupan, dan pengelolaannya merupakan isu
kunci saat ini. Sistem teknologi informasi dan komunikasi untuk pengendalian air saat ini
menghadapi masalah interoperabilitas karena kurangnya dukungan standarisasi pada
peralatan pemantauan dan pengendalian. Masalah ini mempengaruhi berbagai proses
dalam pengelolaan air, seperti konsumsi air, distribusi, identifikasi sistem dan
pemeliharaan peralatan. OPC UA (Object Linking and Embedding for Process Control
Unified Architecture) adalah arsitektur berorientasi layanan platform independen untuk
kontrol proses di sektor logistik dan manufaktur. Berdasarkan standar ini, kami
mengusulkan model pengelolaan air pintar yang menggabungkan teknologi Internet of
Things dengan koordinasi proses bisnis dan sistem pendukung keputusan.

Kata kunci:Pengelolaan Air, Irigasi, OPC UA, Internet of Things

1. Perkenalan
Pengelolaan air didefinisikan sebagai kegiatan merencanakan, mengembangkan, mendistribusikan, dan mengelola
penggunaan sumber daya air secara optimal. Hal ini berdampak pada beberapa hal [1] kehidupan manusia, seperti
produksi pangan, konsumsi air, pengolahan limbah, irigasi, pemurnian, pembangkitan dan pemanfaatan energi, dll.

Kurangnya standar TIK (Teknologi Informasi dan Komunikasi) air mencegah interoperabilitas yang
efektif, dan meningkatkan biaya dan pemeliharaan produk baru. Saat ini ada banyak produsen kecil dan
lokal dari solusi spesifik di pasar yang lemah dan terfragmentasi. Hampir tidak ada adopsi sistem yang
kompleks dan interoperable yang membahayakan kontrol dan pemantauan jaringan distribusi air, juga
mencegah evolusinya dan peningkatan yang diperlukan, sebagai adopsi paradigma IoT (Internet of Things).

Selain itu, sistem TIK saat ini untuk pengelolaan air adalah hak milik dan dikemas sebagai produk independen,
mendukung semua tingkat manajemen mulai dari pengembangan produk hingga komunikasi dengan sistem
manajemen. Pemeliharaan dan keberlanjutan sistem tergantung pada perusahaan yang menyediakannya. Ini

Jurnal Jaringan Seluler Nirkabel, Komputasi Ubiquitous, dan Aplikasi yang Dapat Diandalkan, volume: 6, nomor: 1, hlm. 4-23
KeahlianPenulis korespondensi: Departamento de Ingenierı́a Topográfica y Cartografı́a, Universidad Politécnica de Madrid, Avenida del
Mediterráneo km 7,0, 28031 Madrid, Spanyol, Telp: +34-91-336-6487

4
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

mensyaratkan UKM (Usaha Kecil dan Menengah) yang mengembangkan sistem dan perangkat TIK pengelolaan air tidak
boleh memasuki pasar air bahkan dengan solusi yang kuat tanpa mempertimbangkan sistem lengkap yang
membahayakan kekuatan mereka.
OPC (Object Linking and Embedding for Process Control) dikembangkan oleh industri otomasi dan logistik
sebagai spesifikasi standar terbuka yang memungkinkan komunikasi data pabrik waktu nyata antara perangkat
kontrol yang diproduksi oleh produsen yang berbeda. Versi terbaru OPC (OPC UA), didasarkan pada teknologi
layanan web, sehingga OPC UA menjadi platform-independen dan dengan demikian dapat diterapkan dalam
skenario di mana OPC klasik tidak digunakan.
Dalam pekerjaan ini kami menyelesaikan model pengelolaan air pintar yang kami usulkan [2]. Dalam pekerjaan kami
sebelumnya, kami mendefinisikan model berbasis Internet of Things untuk pengelolaan air pintar menggunakan OPC UA.
Pekerjaan sebelumnya ini telah diperluas dengan penyediaan arsitektur terperinci di mana kami mempertimbangkan teknologi
IoT untuk memisahkan sistem pendukung keputusan dan pemantauan dari koordinasi proses bisnis dan implementasi
subsistem. Arsitektur fungsional ini mempertimbangkan beberapa lapisan dan antarmuka untuk memungkinkan interaksi
lapisan. Kami juga memperluas model referensi kami yang menjelaskan kasus penggunaan praktis yang mendefinisikan
bagaimana arsitektur MEGA digunakan untuk mengembangkan kontrol proses pengelolaan air sederhana dengan
menggunakan resep, dan menjelaskan aspek yang lebih praktis dari skenario validasi kami, yang diadakan di stasiun percobaan
pengelolaan air di Zaragoza, Spanyol.
Bagian selanjutnya dari makalah ini adalah sebagai berikut: Bagian 2 mengusulkan arsitektur tingkat tinggi
berdasarkan tantangan industri, persyaratan pengelolaan air, dan fungsionalitas OPC UA; Bagian 3 menjelaskan
integrasi IoT ke dalam sistem pengelolaan air; Bagian 4 mengembangkan model referensi untuk pengelolaan air pintar,
muncul dengan kasus penggunaan sederhana, dan akhirnya menganalisis skenario pengelolaan air saat ini dan
implementasi di masa depan.

2 Arsitektur Tingkat Tinggi untuk pengelolaan air yang efektif

Konsumen di sektor air menyediakan massa kritis yang lemah untuk mempengaruhi keputusan
yang menghasilkan perubahan yang tepat. Sektor air beroperasi dalam interaksi yang kompleks
antara sumber daya air dan sistem sosial-ekonomi dan lingkungan. Jangkauan pemangku
kepentingan sangat besar, publik dan swasta, dari perusahaan global hingga lokal, didukung
oleh otoritas nasional, regional, dan sekali lagi lokal. Sifat yang berbeda dalam pemangku
kepentingan dan juga berbagai skema tata kelola air, yang terus berkembang di setiap negara,
adalah alasan utama fragmentasi pasar saat ini dalam solusi pengelolaan air. Fragmentasi pasar
yang berlebihan merupakan penghalang besar bagi inovasi di bawah paradigma yang
diinginkan dari Manajemen Sumber Daya Air Terpadu (IWRM), dengan memperlambat adopsi
arsitektur dan standar referensi terbuka.

2.1 Tantangan untuk menentukan Standar Industri untuk Pengelolaan Air

Untuk menentukan standar industri yang layak dan lebih luas untuk proses pengelolaan air, dua
tantangan utama harus dipecahkan: 1) Kurangnya integrasi solusi saat ini dan 2) model referensi TIK
umum yang tidak ada untuk proses pengelolaan air.
Ada kurangnya integrasi solusi saat ini. Meskipun ada banyak vendor global yang mengintegrasikan solusi
pengelolaan air, solusi lokal juga dapat dikembangkan dan dipelihara. Sifat kecil dan lokal dari perusahaan-perusahaan
ini membuat mereka mengantisipasi perubahan yang tidak terduga dan memungkinkan mereka untuk memberikan
berbagai solusi untuk masalah intra-regional. Namun, sebagai konsumen, usaha kecil tidak memiliki massa kritis untuk
mempengaruhi keputusan dan mengembangkan sistem referensi sendiri. Definisi kerangka bersama untuk
menyalurkan upaya ini diperlukan, tidak hanya untuk memperkuat sinergi di antara berbagai

5
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

pemain, tetapi juga untuk memungkinkan integrasi dan adopsi solusi spesifik secara luas.
Vendor global dan lokal menggunakan standar, metode, model data, dan saluran komunikasi yang berbeda untuk
solusi mereka. Solusi ini seringkali sangat kompleks dan terkadang tidak berkelanjutan secara ekonomi bagi pelanggan
mereka. Hambatan ini mengarah pada masalah pemantauan yang mencegah proses pengambilan keputusan yang
diperlukan. Ini menyatakan perlunya pemahaman bersama dan metodologi yang konsisten untuk pengelolaan air yang
efektif.
Tidak ada model referensi TIK untuk proses pengelolaan air. Saat ini banyak perusahaan yang terlibat dalam
kegiatan pengelolaan air, seperti pengumpulan, distribusi, konduksi dan pengolahan. Selain itu, perusahaan yang
terlibat dalam bidang yang terkait dengan pengelolaan tanah atau kimia juga menuntut teknologi yang sesuai
untuk dukungan dan penyediaan air.
Ini menyiratkan heterogenitas besar yang membutuhkan berbagai keterampilan yang bekerja bersama.
Ribuan perusahaan secara langsung aktif dalam proses semacam ini. Misalnya, 1.500 perusahaan terlibat dalam
teknologi air di Belanda [3]. Di Eropa, EUWMA (European Union of Water Management Association) mewakili lebih
dari 8.600 organisasi di delapan negara. Juga, di AS, perusahaan yang mengkhususkan diri dalam pengolahan air
adalah anggota asosiasi perdagangan internasional yang mewakili lebih dari 500 perusahaan [4].

Kedatangan baru teknologi TIK di bidang pengelolaan air harus berurusan dengan berbagai macam proses
dan fungsi yang diperlukan untuk memahami siklus pengelolaan air (konsumsi perkotaan dan pedesaan, cuaca
dan perubahan iklim, sumber daya air, pertanian, air tanah, hutan, daerah aliran sungai, kawasan lingkungan
dengan minat khusus, dll). Siklus yang kompleks ini mengakibatkan kurangnya model referensi untuk
penggunaan TIK dan tidak adanya pemimpin yang jelas tentang teknologi TIK yang mencakup seluruh proses
pengelolaan air. Ada beberapa inisiatif Eropa [5] untuk mendefinisikan kerangka kerja umum untuk kebijakan air,
tetapitidak ada organisasi internasional yang mempromosikan definisi standar TIK untuk mendorong kerja sama
yang efektif antara infrastruktur dan komponen pengelolaan air. Ini terutama karena dua alasan:

Sedikit apresiasi untuk interoperabilitas: proses pengelolaan air dilakukan oleh teknologi spesifik yang
berasal dari sektor lain, seperti otomatisasi, energi, dll. Kontrol teknologi tersebut disediakan oleh solusi
eksklusif. Salah satu alasan kurangnya kerja sama yang efektif antara infrastruktur dan komponen
pengelolaan air adalah karena tidak adanya persyaratan, tuntutan atau peraturan hukum yang
memaksakan interkoneksi sistem tersebut.
Perusahaan pengelolaan air berorientasi lokal: sebagian besar solusi pengelolaan air yang saat ini digunakan disediakan
oleh UKM. Perusahaan-perusahaan tersebut memberikan solusi sederhana untuk masalah yang sangat spesifik dengan pasar
lokal yang membutuhkan hubungan dekat, tetapi mereka biasanya menemukan masalah untuk memperluas bisnis mereka ke
wilayah atau negara lain karena peraturan yang berbeda, dan interworking peralatan yang rendah. Masalah bagi pengguna
akhir adalah bahwa mereka terlibat dengan penyedia lokal yang bahkan dapat menghilang dan infrastruktur yang ada tidak
dapat dipertahankan dan diperbarui oleh yang lain. Oleh karena itu mereka terpaksa memulai dari awal dengan reinvestasi yang
besar.
Untuk mengatasi masalah tersebut, Tragsa [6] mempromosikan model MEGA [7] sebagai inisiatif khusus di
Spanyol yang dapat diterjemahkan ke tingkat Eropa dan Internasional. Tragsa adalah perusahaan publik milik
Kementerian Pertanian, Pangan & Lingkungan Spanyol yang menangani semua aspek pengelolaan air. Di negara-
negara Mediterania konsumsi air untuk pertanian mewakili 70% dari total dan konsumsi energi lebih tinggi
daripada kota besar seperti Madrid, Roma, Paris, atau Athena. Model MEGA mempertimbangkan arsitektur
decoupled fungsional untuk memungkinkan interoperabilitas antara peralatan vendor tertentu.

2.2 Persyaratan untuk Arsitektur referensi

Kami mendefinisikan persyaratan berikut yang harus dipenuhi untuk mengembangkan model pengelolaan air standar:

6
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

PERTANYAAN #1:Sistem harus mencakup fungsi pengelolaan air ini: pengelolaan jarak jauh
elemen fisik dan pengoperasian unit dasar; identifikasi sumber daya dalam jaringan air, definisi
operasi dan kondisi melalui jaringan.
PERTANYAAN #2:Ini harus mendukung interoperabilitas dengan aplikasi lain seperti sistem informasi
geografis dan juga database yang berisi informasi mengenai tanah, ramalan cuaca, lingkungan, pertanian,
dll.
PERTANYAAN #3:Ini harus menyediakan arsitektur yang fleksibel dan dapat diperluas untuk integrasi berbagai sistem.
Untuk melakukan itu, ia harus mendefinisikan antarmuka terbuka di antara lapisan komunikasi dan kontrol proses, dan juga
mengintegrasikan sistem IoT untuk akses langsung ke perangkat pengelolaan air individu.
PERTANYAAN #4:Ini harus mendukung integrasi dengan sistem warisan, mengendalikan peralatan saat ini.
Prasarana pengelolaan air yang saat ini tersebar di pedesaan terdiri dari banyak perangkat yang saling berhubungan
dan sederhana yang harus dikelola dengan menggunakan sistem warisan. Mereka mengintegrasikan fungsi komunikasi,
model data, dan protokol yang bergantung pada teknologi spesifik pabrikan. Mengganti sistem ini dengan yang baru
tidak selalu merupakan solusi yang layak.

2.3 Persyaratan untuk Arsitektur referensi

OLE untuk Kontrol Proses (OPC), yang merupakan singkatan dari Object Linking and Embedding (OLE) untuk
Kontrol Proses, adalah nama asli untuk spesifikasi standar yang dikembangkan pada tahun 1996 oleh satuan
tugas industri otomasi industri. Standar menentukan komunikasi data pabrik waktu nyata antara perangkat
kontrol dari pabrikan yang berbeda[8] .
Sejak November 2011, OPC Foundation secara resmi mengganti akronimnya menjadi ”Open
Platform Communications”. Perubahan nama mencerminkan penerapan teknologi OPC untuk aplikasi
dalam kontrol proses, manufaktur diskrit, otomatisasi bangunan, dan banyak lainnya. Awalnya,
standar OPC terbatas pada sistem operasi Windows. Spesifikasi ini, yang saat ini dikenal sebagai OPC
Classic, telah diadopsi secara luas di berbagai industri, termasuk manufaktur, otomatisasi gedung,
minyak dan gas, energi terbarukan, dan utilitas.
Dengan diperkenalkannya arsitektur berorientasi layanan dalam sistem manufaktur, tantangan baru dalam
keamanan dan pemodelan data tiba. OPC Foundation mengembangkan spesifikasi OPC UA (OPC Unified Architecture)
untuk memenuhi kebutuhan ini dan pada saat yang sama menyediakan arsitektur platform terbuka yang kaya fitur agar
tahan terhadap masa depan, skalabel, dan dapat diperluas.
OPC UA, dirilis pada tahun 2008, terdiri dari bagian-bagian berikut: Konsep, Model Keamanan, Model Ruang
Alamat, Layanan, Model Informasi, Pemetaan, Profil, Akses Data, Alarm dan Kondisi, Program, Akses Historis,
Penemuan, dan Agregat. Ini juga mendefinisikan arsitektur berorientasi layanan platform independen yang
mengintegrasikan semua fungsionalitas spesifikasi OPC Classic individu ke dalam satu kerangka kerja yang dapat
diperluas. Pendekatan berlapis-lapis dari OPC UA mencapai tujuan desain awal berikut:

• Kesetaraan fungsional:semua spesifikasi COM OPC Classic dipetakan ke UA

• Independensi platform:dari mikrokontroler tertanam ke infrastruktur berbasis cloud

• Aman:enkripsi, otentikasi, dan audit

• Dapat diperluas:kemampuan untuk menambahkan fitur baru tanpa memengaruhi aplikasi yang ada

• Pemodelan informasi yang komprehensif:untuk mendefinisikan informasi yang kompleks

7
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

Kerangka kerja pemodelan informasi OPC UA mengubah data menjadi informasi. Dengan kemampuan
berorientasi objek yang lengkap, bahkan struktur multi-level yang paling kompleks pun dapat dimodelkan dan
diperluas. Tipe data dan struktur didefinisikan dalam profil. Misalnya, spesifikasi OPC Classic yang ada
dimodelkan ke dalam profil UA, yang juga dapat diperluas oleh organisasi lain.

Gambar 1: Pemodelan informasi UA OPC

OPC UA menawarkan satu set Layanan Basis, yang dilengkapi dengan layanan opsional (Akses Data, ASE,
Akses Data Historis, Perintah, Alarm dan Peristiwa, Pertukaran dan Keamanan Data), seperti yang ditunjukkan
pada Gambar 1. Layanan Over Base dan menggunakan beberapa layanan opsional, standar OPC UA dapat
diterapkan ke domain spesifik apa pun dengan definisi Spesifikasi Model Informasi. Di vendor tingkat atas dapat
menentukan Model Informasi spesifik mereka sendiri.
Fungsionalitas baru yang disediakan oleh spesifikasi OPC-UA (dukungan untuk aplikasi Web untuk
mengakses server OPC-UA, layanan komputasi awan OPC-UA) selaras dengan persyaratan arsitektur pengelolaan
air yang diusulkan. Jadi, kami memutuskan untuk menggunakan standar ini untuk komunikasi antara antarmuka
MEGA.

2.4 Arsitektur tingkat tinggi untuk pengelolaan air yang efektif

Arsitektur MEGA dijelaskan pada Gambar 2. Model tingkat tinggi yang diusulkan mengidentifikasi tiga
lapisan (dari bawah ke atas):Lapisan subsistem, ituLapisan koordinasidanManajemen - Lapisan eksploitasi.
Lapisan-lapisan ini berurusan dengan yang umumModel Pengelolaan Airyang mempertimbangkan definisi
dariEntitas,resep,Prosedur,Proses yang direncanakan, danAlarm. Model pengelolaan air adalah elemen
kunci untuk memungkinkan MEGA menyediakan kerangka perilaku umum. Antara lapisan Subsistem dan
lapisan Koordinasi adaKoordinasi - Antarmuka subsistemdan di antara lapisan Koordinasi dan Manajemen -
Eksploitasi adaKomunikasi Umumantarmuka. Ini juga dianggap sebagai lapisan Administrasi yang
mengelola informasi yang diberikan oleh lapisan Koordinasi melaluiAntarmuka Administrasi.

Kami menjelaskan elemen utama arsitektur MEGA:

Lapisan Manajemen dan Eksploitasi:lapisan ini menampung aplikasi dan layanan utama yang
bertanggung jawab atas pengelolaan infrastruktur air yang efisien, dan mendukung definisi dan
manajemen untuk proses yang diterapkan pada infrastruktur tersebut. Pada lapisan ini Operator
(perusahaan jasa besar, dan asosiasi pengguna akhir antara lain) mendorong proses manajemen abstrak
dari sistem akhir tertentu yang digunakan di lingkungan nyata. Layanan dapat dijalankan pada host lokal,
layanan cloud, atau lingkungan layanan lain apa pun yang disediakan oleh teknologi mutakhir saat ini.
Lapisan koordinasi:lapisan ini mendukung interoperabilitas antara sistem manajemen dan eksploitasi
yang berbeda dan subsistem perangkat keras dan perangkat lunak yang mendasarinya. Berdasarkan
definisi model pengelolaan air, lapisan Koordinasi melakukan fungsi-fungsi berikut:

• Manajemen entitas:Lapisan koordinasi mendefinisikan dan menghubungkan entitas dengan objek fisik. Entitas
bisa menjadiEntitas Nyataketika mereka secara langsung sesuai dengan perangkat fisik atauEntitas Virtual,

8
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

Lapisan Eksploitasi Manajemen

Komunikasi Umum
antarmuka
Lapisan koordinasi
Administrasi
antarmuka

Prosedur
Manajer entitas Perencana proses
Pengelola

Entitas
Berencana
lapisan administrasi

resep Prosedur
proses DB

Entitas Nyata Entitas Virtual

Pengelola Pengelola
Alarm
pesan DB

Subsistem Alarm dan

Pelaku proses
pengontrol pengelola pesan

Koordinasi-
Antarmuka subsistem

Subsistem

Gambar 2: Struktur Fungsional Tingkat Tinggi MEGA

ketika mereka sesuai dengan fungsionalitas yang dapat dicakup oleh beberapa perangkat atau bagian dari satu
perangkat.

• Manajemen prosedur:SEBUAHproseduradalah kasus penggunaan pengelolaan air tingkat tinggi yang

dilakukan dalam satu atau banyak subsistem. Prosedur yang ditentukan oleh Manajemen dan Eksploitasi
dikumpulkan dan dikirimkan ke lapisan Subsistem. Lapisan koordinasi berinteraksi dengan subsistem
dengan mempertimbangkan topologi sistem air, dan antarmuka setiap subsistem.

• Manajemen resep:resepmenentukan urutan kegiatan yang akan dieksekusi dalam subsistem. Mereka
terkait dengan prosedur. ItuManajer prosedurmengikat resep dengan prosedur yang ditentukan.

• Perencanaan proses:Proses adalah aktivitas atom yang dieksekusi di dalam subsistem. Resep
disusun oleh proses. ItuPerencana prosesmendefinisikan proses dan mengirimkannya kePelaku
proses, yang sedang dalam perubahan eksekusinya.

Lapisan subsistem:lapisan subsistem berisi berbagai subsistem yang terintegrasi ke dalam Sistem
Pengelolaan Air. Setiap subsistem independen dari yang lain dan mengelola siklus hidup operasi yang
dijalankan. Subsistem dapat menjadi heterogen dan bergantung dari teknologi eksklusif. Untuk mencapai
interoperabilitas, mereka harus mengimplementasikan metode yang didefinisikan dalam antarmuka
Koordinasi-Subsistem.

9
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

Lapisan administrasi:lapisan administrasi memungkinkan konfigurasi entitas yang berbeda didefinisikan

dalam lapisan Koordinasi. Ini menyediakan antarmuka pengguna yang dapat digunakan oleh administrator
platform untuk melakukan fungsi administrasi dan pemantauan.
Tiga antarmuka utama didefinisikan dalam arsitektur tingkat tinggi ini, Antarmuka Administrasi,
Antarmuka Komunikasi Umum, dan Antarmuka Subsistem Koordinasi:
Antarmuka Administrasi:Antarmuka Administrasi memungkinkan pemantauan entitas yang ditentukan
dan disimpan di lapisan koordinasi. Secara khusus memonitor entitas, prosedur, dan proses, dan
bagaimana proses ini dieksekusi menjadi subsistem.
Antarmuka Komunikasi Umum:Antarmuka dua arah ini memberikan solusi umum untuk menangani
pesan dari proses bisnis di lapisan manajemen dan eksploitasi dan memprosesnya di lapisan koordinasi
dengan menggunakan standar berbasis industri seperti ISA-95/88 dan OPC UA, seperti yang dijelaskan di
Bagian 2.3.
Antarmuka Koordinasi-Subsistem:antarmuka ini memungkinkan pelaksanaan proses pengelolaan air di
subsistem. Lapisan Koordinasi tidak tahu persis struktur internal setiap subsistem (yang dilaksanakan oleh
masing-masing perusahaan), tetapi dapat mendelegasikan proses dan memantau pelaksanaannya dan
status sistem fisik yang meminta informasi yang relevan. Informasi ini dikumpulkan, diproses, dan
selanjutnya diterjemahkan ke lapisan Manajemen dan Eksploitasi.
Lapisan dan antarmuka ini bergantung pada bagaimana elemen dan proses pengelolaan air didefinisikan.
Analisis data, pengumpulan, distribusi proses dan perilaku sistem didefinisikan ke dalam model fisik dan model
proses.
Model Fisik:Model fisik memungkinkan definisi peralatan yang terintegrasi dalam sistem pengelolaan air secara
hierarkis. Model ini mengidentifikasi secara unik entitas yang berpartisipasi dalam subsistem, bagaimana entitas terkait
dan dikelompokkan. Karena subsistem dapat menjadi heterogen dan bergantung pada teknologi eksklusif, hal ini
memungkinkan UKM, yang tidak memiliki sumber daya untuk mengimplementasikan seluruh sistem referensi sendiri,
untuk mengembangkan atau menggunakan kembali satu subsistem.
Model Proses:berdasarkan model fisik dan mengetahui proses yang dapat dilakukan setiap subsistem, proses
sederhana atau kompleks didefinisikan dan (i) dimuat ke dalam sistem; (ii) divalidasi menurut informasi internal;
(iii) didistribusikan ke subsistem yang sesuai; (iv) dilaksanakan dan dipantau; dan akhirnya (v) dihentikan dan
dilaporkan.
OPC UA didefinisikan untuk mengendalikan proses yang ditugaskan ke entitas fisik. Karena sifat khusus dari
sistem pengelolaan air, MEGA mengidentifikasi "entitas virtual" sebagai konsep yang didefinisikan untuk
memfasilitasi pengelolaan air melalui satu sistem air tertentu. Entitas virtual dapat didefinisikan sebagai
"perangkat logika yang dihasilkan oleh operasi logika entitas hidrolik". Penggunaan entitas virtual
memungkinkan definisi proses untuk elemen tersebut yang tidak sesuai dengan perangkat nyata, melainkan
sesuai dengan fungsi yang dapat dicakup oleh beberapa perangkat atau bagian dari satu perangkat.
Karena sifat virtual entitas tersebut, perilaku dan status fungsionalnya akan ditentukan di Lapisan
Koordinasi, bukan di Subsistem. Kemudian, resep kontrol termasuk prosedur untuk entitas virtual
tersebut akan dieksekusi oleh Lapisan Kontrol, karena resep tersebut tidak akan ditransfer ke
subsistem mana pun.
MEGA menyediakan Arsitektur referensi untuk proses pengelolaan air menggunakan OPC UA. Gambar 3
menunjukkan bagaimana arsitektur referensi MEGA cocok dengan piramida otomatisasi, dan menggunakan OPC
UA untuk komunikasi antara Lapisan Koordinasi dan Lapisan Subsistem.
Versi pertama MEGA mendefinisikan dua antarmuka berdasarkan OPC UA: Antarmuka Komunikasi
Umum dan Antarmuka Subsistem Koordinasi. Namun antarmuka antara Level Kontrol Proses dan Level
Kontrol & bidang tidak ditentukan sama sekali di MEGA. Hal ini karena sifat sistem pengelolaan air untuk
irigasi di lapangan. Arsitektur referensi MEGA mengidentifikasi subsistem untuk mencakup Level Kontrol
Proses dan Level Kontrol & lapangan, sehingga setiap perusahaan pabrikan dapat memberikan solusi
langsung menggunakan proses dan teknologi komunikasi yang paling sesuai.

10
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

Gambar 3: OPC UA dalam piramida otomatisasi untuk MEGA

nologies sesuai dengan keadaan seni dan persyaratan yang diberlakukan oleh sistem semacam itu. Dalam proses pengelolaan
air, peralatan harus ditempatkan di lingkungan yang tidak bersahabat (udara terbuka, kondisi cuaca buruk, peralatan tanpa
pengawasan atau akses yang sulit, dll.) Oleh karena itu, merupakan masalah utama bagi setiap penyedia bahwa sistem mereka
mampu mengatasi kesulitan tersebut. bahkan dengan antarmuka tertentu.

3 Mengintegrasikan IoT dalam pengelolaan air

Berkontribusi pada solusi yang mengintegrasikan paradigma Internet of Things ke dalam proses pengelolaan air dapat
bermanfaat untuk mengatasi solusi yang diharapkan. Sisa dari Bagian ini menjelaskan manfaat utama dari mengadopsi
IoT dan karakteristik IoT yang dipertimbangkan dalam model MEGA yang diusulkan, dengan mempertimbangkan
kemajuan baru pada teknologi TIK untuk menciptakan sistem yang layak dan komersial [9].
Mark Weiser mendefinisikan ”Lingkungan Cerdas” [10] sebagai - dunia fisik yang kaya dan tak terlihat terjalin
dengan sensor, aktuator, tampilan, dan elemen komputasi, tertanam mulus dalam objek sehari-hari kehidupan
kita, dan terhubung melalui jaringan berkelanjutan. Ada banyak karya penelitian yang berkontribusi untuk
memecahkan berbagai masalah diLingkungan Cerdas, seperti akses tanpa batas ke sumber daya dan perangkat
[11], eksekusi layanan terdistribusi [12], teknik pilihan sosial [13], dll. Karya lain menjelaskan bagaimana IoT
didasarkan pada tiga paradigma - berorientasi internet (middleware), berorientasi pada hal-hal ( sensor) dan
berorientasi pada pengetahuan (semantik) [14]. Meskipun jenis penggambaran ini diperlukan karena sifat subjek
interdisipliner, kegunaan IoT hanya dapat dilepaskan dalam domain aplikasi di mana tiga paradigma
berpotongan.

3.1 IoT untuk Pengelolaan Air

Penyediaan kemampuan Internet of Things dalam skenario pengelolaan air dapat dicapai jika kita
mempertimbangkan beberapa pertimbangan dari sudut pandang bisnis, sosial dan teknis. Di sini kami
mencantumkan manfaat utama menyediakan IoT dalam skenario pengelolaan air:
Peningkatan efisiensi:perusahaan dan asosiasi pengelolaan air dapat menggunakan kontrol operasional waktu nyata untuk
membuat keputusan bisnis yang lebih cerdas dan mengurangi biaya operasi. Mereka menggunakan data waktu nyata dari

11
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

sensor dan aktuator untuk memantau dan meningkatkan infrastruktur pengelolaan air, menjadikannya lebih efisien,
mengurangi biaya energi, dan meminimalkan campur tangan manusia.
Penghematan biaya:biaya pengelolaan air dapat dikurangi melalui peningkatan pemanfaatan aset, efisiensi proses
dan produktivitas. Pelanggan dan organisasi dapat memperoleh manfaat dari peningkatan pemanfaatan aset (misalnya,
unit irigasi air pintar yang menghilangkan operasi manual) dan peningkatan layanan (misalnya, pemantauan kondisi
irigasi dari jarak jauh)
Pemanfaatan aset:dengan pelacakan aset yang lebih baik (mesin, peralatan, peralatan, dll.) menggunakan sensor dan
konektivitas, perusahaan dapat memperoleh manfaat dari transparansi dan visibilitas ke dalam aset dan rantai pasokan mereka.
Mereka dapat dengan mudah menemukan aset dan menjalankan pemeliharaan preventif pada bagian penting dari infrastruktur
dan mesin.
Peningkatan produktivitas:Produktivitas adalah parameter penting yang mempengaruhi profitabilitas organisasi mana pun. IoT
memungkinkan kontrol waktu nyata, model bisnis baru, pengoptimalan proses, konservasi sumber daya, pengurangan waktu layanan,
dan kemampuan untuk melakukan semua ini secara global, mengurangi ketidaksesuaian keterampilan yang diperlukan vs. tersedia, dan
meningkatkan efisiensi tenaga kerja.
Perluasan model bisnis baru dan yang sudah ada:IoT bermanfaat di salah satu dari tiga lapisan yang
ditentukan. Dalamlapisan subsistem, subsistem IoT dapat menjalankan proses dan berkomunikasi menggunakan
antarmuka komunikasi standar; dalamlapisan koordinasi, dapat berguna untuk memungkinkan UKM merancang
aplikasi koordinasi baru, dengan tujuan untuk mengatur lapisan manajemen dan eksploitasi dengan lapisan
subsistem; dan akhirnya, dilapisan manajemen dan eksploitasi, kemampuan identifikasi IoT berkontribusi untuk
menyediakan layanan informasi yang disesuaikan untuk komunitas jaringan distribusi air tertentu.

Seperti yang kami jelaskan sebelumnya, IoT dibangun di atas tiga pilar [14]:Orientasi internet, orientasi benda, dan orientasi
pengetahuan. Kami menghubungkan pilar-pilar ini dengan kemampuan objek untuk (i) dapat diidentifikasi (apa saja
mengidentifikasi dirinya sendiri), (ii) berkomunikasi (apa saja berkomunikasi) dan (iii) berinteraksi (apa pun berinteraksi), baik di
antara mereka sendiri, membangun jaringan objek yang saling berhubungan, atau dengan pengguna akhir atau entitas lain
dalam jaringan. Model MEGA yang diusulkan mempertimbangkan properti ini:
berorientasi internet:model MEGA yang diusulkan mengidentifikasi tiga lapisan (lihat Gambar. ??). Lapisan-
lapisan ini dikomunikasikan dengan dua antarmuka web yang memungkinkan definisi sistem komunikasi yang
fleksibel dan terukur untuk mengendalikan sejumlah besar subsistem yang diperlukan untuk sistem pengelolaan
air yang lengkap.
ItuKoordinasidanManajemen - Eksploitasilapisan didefinisikan sebagai layanan Cloud.IoT, sebagai visi
yang lebih luas dari konsep komunikasi mesin-ke-mesin (M2M) sebelumnya, mendapatkan dukungan oleh
infrastruktur komputasi Cloud saat ini, yang mulai menyediakan apa yang disebut solusi IoT berbasis cloud.

Selanjutnya, kemampuan subsistem (yaitu teknologi penginderaan, penggerak, komputasi dan

komunikasi) bergantung pada kondisi spesifik dari skenario di mana mereka ditempatkan. Akses tanpa
batas ke subsistem akan mengharuskan:Lapisan subsistem mencakup homogenisasi melalui keragaman
besar paradigma komunikasi dan granularitas yang lebih tinggi,untuk menangani banyak teknologi
komunikasi.
berorientasi pada hal:Karena pengalaman pengembangan sistem pengelolaan air sebelumnya, elemen
paling granular yang dapat diakses adalah subsistem. Diharapkan granularitas yang lebih tinggi di tahun-tahun
mendatang, karena subsistem disusun oleh banyak perangkat dan keterkaitan, seperti yang kami jelaskan dalam
model fisik dan proses Bagian 4. Elemen-elemen ini dapat didefinisikan ulang sebagaiObjek Pintar, menjadi objek
yang mampu menggambarkan kemungkinan interaksinya sendiri. Smart Object dapat memberikan informasi
berikut: Properti objek (properti fisik dan deskripsi teks), perilaku (perilaku berbeda berdasarkan variabel
keadaan) dan, juga, informasi interaksi (keadaan dial, pengukur, sakelar, dll.) saat ini.
Penting untuk mendefinisikan bagaimana subsistem sebagai wadah objek pintar memenuhi fitur yang diidentifikasi oleh
[14] dan [15]. Subsistem mendefinisikan dan menyediakan identifikasi objek, untuk melakukan itu mereka harus menggabungkan

12
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

Identifikasi sistem yang unikfitur. Juga, mereka mempublikasikan kemampuan subsistem, sebagai daftar fungsi yang didukung
oleh mereka, dengan mempertimbangkan kemampuan mengintegrasikan objek.

Berorientasi pada pengetahuan:karena keragaman subsistem yang besar untuk pengelolaan air, penting
untuk memodelkan karakteristik yang dimiliki oleh subsistem ini, dan perilakunya. Dalam karya ini kami
menyediakan model fisik, mendefinisikan elemen fisik yang menjalankan proses pengelolaan air secara hierarkis,
dan juga model proses, mengatur pelaksanaan proses tertentu dalam subsistem pengelolaan air. Berdasarkan
model ini, eksekusi cerdas proses pengelolaan air didukung melalui kolaborasi antara subsistem dan lapisan
Koordinasi, berdasarkan pertukaran informasi di antara mereka (lihat Gambar. 3). Berkat sistem penyediaan
pengetahuan dapat dipantau untuk memfasilitasi entitas publik melacak pemenuhan peraturan.Informasi yang
akan dipantau secara mandiri disediakan oleh subsistemberdasarkan kemampuan sensor. Model-model ini dapat
diperkaya dengan semantik untuk menggambarkan, berbagi, dan mengintegrasikan informasi, menyimpulkan
pengetahuan baru terkait dengan pengelolaan air dan proses irigasi. Semantik juga membantu membuat data
yang dapat diinterpretasikan oleh mesin dan dapat dideskripsikan sendiri dalam domain IoT. Deskripsi semantik
dapat mendukung integrasi data dengan mengaktifkan interoperabilitas antara berbagai sumber data (sensor,
perangkat); namun, analisis dan pemetaan antara model deskripsi semantik yang berbeda masih diperlukan
untuk memfasilitasi integrasi data IoT dengan pengetahuan domain lain yang ada.

4 Model referensi untuk pengelolaan air pintar

Bagian ini menjelaskan model pengelolaan air yang sedang dikembangkan. Model ini terdiri dari tiga
elemen utama, Model Pengelolaan Air, Antarmuka Komunikasi Umum dan Antarmuka Koordinasi-
Subsistem (CS).

4.1 Model Pengelolaan Air

Model pengelolaan air meliputi model fisik dan model proses.

Model fisik mengikuti standar EN 61512 [16] dan EN 62264 [17]. Seperti yang diusulkan oleh EN 61512,
struktur berlapis didefinisikan dan diwakili pada Gambar 4. Tiga lapisan atas (Perusahaan, Lokasi dan Area)
dimodelkan seperti pada EN62264, mewakili organisasi perusahaan. Sel Proses dan Unit mewakili entitas di
mana proses dijalankan. Contoh sel dan unit proses adalah Sektor Irigasi dan Stasiun Manajemen Pompa
(PMS). Terakhir, Equipment Module dan Control Module adalah elemen-elemen yang dimiliki oleh
subsistem dan tidak dapat diakses secara langsung oleh lapisan Koordinasi. Karena kemajuan saat ini
dalam keadaan seni di IoT, elemen-elemen ini akan menjadiElemen Cerdas di masa depan dan mereka
akan langsung diidentifikasi dan diakses. Hidran, stasiun penyaringan, dan saluran pemompaan adalah
contoh modul peralatan. Mesin katup dan meter adalah contoh modul kontrol.
Model proses mengatur pelaksanaan proses tertentu dalam subsistem pengelolaan air, mengikuti
strategi yang telah ditentukan. Contoh proses adalah irigasi, pengisian tangki, atau pengukuran konsumsi
air. Model proses mengidentifikasiProsedur, sebagai elemen dasar yang akan dieksekusi oleh Process Cell.
Prosedur disusun olehProsedur Unit, sebagai elemen dasar yang akan dieksekusi oleh satu unit, dan
akhirnya,Operasi, sebagai instruksi atom dieksekusi di dalam unit. Misalnya, instruksi atom yang akan
dieksekusi di stasiun manajemen pompa dapat berupa menjalankan proses pembersihan berkala untuk
mengoptimalkan kinerja stasiun. Definisi elemen dan operasi dalam model fisik dan model proses masing-
masing memungkinkan operasi dan manajemen jarak jauh elemen pengelolaan air, seperti yang dituntut
REQ #1

13
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

4.2 Antarmuka Komunikasi Umum

Antarmuka Komunikasi Umum terdiri dari satu set layanan web yang digunakan oleh aplikasi milik
lapisan Manajemen - Eksploitasi, untuk beroperasi pada entitas yang ditentukan oleh model fisik,
mengidentifikasi keadaan sistem saat ini dan juga mengirim operasi pengelolaan air untuk
mengontrol konsumsi air.

Proses
Memuat memeriksa Memvalidasi Pemantauan
Desain

Perusahaan Lokasi Daerah

Fisik
Model Kontrol Peralatan Proses
Satuan
Modul Modul Sel

Proses Satuan
Operasi Prosedur
Eksekusi Prosedur

Gambar 4: Lapisan model fisik dan proses

Antarmuka Komunikasi Umum menangani pesan dari proses bisnis (aplikasi berbasis GIS, layanan yang
menyediakan informasi tentang tanah, meteorologi, sesuai permintaan REQ #2), dalam format XML, dan
mengubahnya menjadi model informasi OPC UA yang sesuai dengan ISA-95/88 . OPC UA (IEC 62541) adalah
standar berbasis industri yang menyediakan sarana komunikasi dan interaksi terpadu untuk Arsitektur
Berorientasi Layanan dan Layanan Web. Ini sering digunakan untuk mengimplementasikan profil yang berbeda
untuk sistem otomasi [18] seperti otomasi rumah dan industri dan juga sistem pengelolaan air. OPC UA
berkontribusi untuk memenuhi REQ #3, karena memungkinkan integrasi berbagai sistem berdasarkan teknologi
tertentu.
OPC UA mendefinisikan model informasi yang memungkinkan pembuatan instans perangkat dan jenis
perangkat. Kami menerapkan model fisik di OPC UA yang mendefinisikan pesan kontrol di lapisan
Manajemen - Eksploitasi, dan memungkinkan eksekusi pesan-pesan ini di lapisan Koordinasi. Agar sesuai
dengan ISA-9588, kami mendefinisikan resep, yang menentukan urutan kegiatan dalam bentuk langkah-
langkah prosedural. Jadi, pesan kontrol berisi resep yang akan dieksekusi di subsistem, oleh komponen
fisik yang terletak di dalamnya. Menggunakan resep menjadi solusi untuk mengelola elemen subsistem,
yang tidak dapat diakses secara langsung oleh lapisan Koordinasi, karena urutan aktivitas yang akan
dilakukan harus dipisahkan dari teknologi spesifik dalam subsistem, sesuai tuntutan REQ #4.
Mungkin ada beberapa masalah jika lebih dari satu resep dieksekusi pada entitas yang sama pada waktu yang
sama. Untuk mengatasinya, kami mendefinisikan resep dengan batasan eksekusi, yang mencegah beberapa eksekusi
resep pada elemen fisik yang sama. Untuk memeriksa elemen mana yang digunakan oleh resep, lapisan Koordinasi
mengambil daftar operasi yang harus dilakukan oleh resep dan mendapatkan pengidentifikasi sel dan unit proses yang
melakukan operasi ini. Jika salah satu dari sel dan unit proses ini digunakan oleh resep lain yang harus dijalankan pada
saat yang sama, lapisan koordinasi menemukan ketidakcocokan, yang harus diselesaikan di lapisan Manajemen -
Eksploitasi dengan intervensi pengguna.
Gambar 5 menjelaskan model yang ditentukan untuk resep. Resep kontrol memilikiID Resepyang
secara unik mengidentifikasinya. Juga, itutajukmengidentifikasi prosedur di mana resep disertakan dengan
ID prosedural, dan jenis resep yang akan dieksekusi (Jenis Resep). ItuRumusmencakup serangkaian
tindakan yang harus dilakukan atas entitasID Entitas. Bergantung pada jenis resep, formula berlaku untuk
elemen aktif (resep pemantauan), elemen irigasi (resep irigasi), hidran entitas (hidran

14
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

KontrolResep

ID Resep tajuk Rumus

ID prosedural Mulai tanggal

ID Entitas

Jenis Resep
Pemantauan
Irigasi
hidran

Gambar 5: Model resep kontrol

resep), dll.

4.3 Antarmuka Koordinasi-Subsistem

Antarmuka Koordinasi-Subsistem (CS) bertukar pesan OPC-UA antaraLapisan koordinasidan
Subsistem.

Koordinasi- Subsistem 1
OPC-UA
Koordinasi Subsistem Subsistem OPC-UA
Server antarmuka
Klien pengontrol

penemuan: getEndpoints
memohon

KontrolResep Deskripsi Titik Akhir[]

Setel S1.valve1 BuatSecureChannel()

membuka
Dapatkan Atribut Node
Setel katup #1
Tulis (jalur simpul, nilai)
membuka

dataChange (jalur simpul, nilai, status)

SELESAI hasil

Gambar 6: Menerapkan resep kontrol sederhana

Antarmuka ini menganggap elemen pengelolaan air (Unit, Sel Proses, dll) sebagai satu set node,
yang dapat dipantau dan diakses oleh klien OPC-UA. Modifikasi node ini, karena eksekusi formula
resep, menghasilkan perubahan perilaku elemen fisik. Rumus resep ditransfer dari lapisan koordinasi
ke subsistem yang dapat mengeksekusinya. Untuk melakukan itu, lapisan koordinasi harus
mengetahui kemampuan subsistem. OPC-UA mendukung definisi dariProfil, yang menjelaskan fitur
yang didukung oleh produk yang sesuai dengan OPC-UA. Fitur wajib yang harus didukung oleh klien
dan server ditentukan dalam profil, bersama dengan fungsi lain yang tidak diperlukan yang
dinegosiasikan antar entitas. Saat ini, OPC Foundation telah menerbitkan lebih dari 60 profil OPC-UA
[19].
Gambar 6 menjelaskan diagram interaksi dari use case'Menerapkan resep kontrol sederhana'. Diagram
mencerminkan interaksi antara lapisan Koordinasi dan Subsistem, yang masing-masing mencakup server OPC-UA
dan klien OPC-UA. Subsistem harus menemukan profil yang didukung dengan mendapatkan
titik akhir server. Kemudian, saluran komunikasi yang aman dibuat dengan server. Sebuah modifikasi
dari properti di sebuah subsistem perangkat mereka (seperti membuka katup) ditransmisikan melalui antarmuka CS
menggunakan perintah OPC Get Node Attributes, untuk mengambil nama, jenis, deskripsi dan izin (membaca
dan/atau menulis) dari node, dan terakhir, menggunakan perintah OPC write untuk mengubah nilai node.

15
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

Ketika perubahan dilakukan dalam sistem fisik (misalnya katup dibuka), elemen merespons dengan a
perubahan dataperistiwa yang dikirimkan ke lapisan Koordinasi, dengan hasil tindakan.

4.4 Kasus Penggunaan sederhana

Dalam Bagian ini kami mengilustrasikan dengan menggunakan contoh sederhana bagaimana MEGA dapat digunakan. Kami menjelaskan
skenario sederhana namun realistis, kami menunjukkan bagaimana data didefinisikan untuk dimuat ke MEGA, dan akhirnya kami
menguraikan bagaimana MEGA melakukan kontrol proses.

1.Deskripsi skenario
Skenario yang diusulkan berisi "satu subsistem dengan hidran dan deposit air yang
menyediakan air ke sistem". Gambar 7.A menunjukkan skema skenario.

Gambar 7: Model Fisik

Untuk Jaringan Hidraulik tersebut kami ingin mendefinisikan proses selanjutnya, yang langsung diungkapkan oleh
petani: “mengirigasi tanggal 27 September pukul 12.00 selesai pukul 12:30 dan menggunakan volume maksimum 800
liter”.

2.Definisi Model Fisik

Berdasarkan peralatan nyata yang dijelaskan pada Gambar 7.A langkah selanjutnya adalah definisi
Model Fisik menurut spesifikasi MEGA. Gambar 7.B menggambarkan identifikasi komponen, dan
Gambar 7.C menggambarkan model fisik untuk use case ini. MEGA tidak mendefinisikan prosedur
standar apa pun untuk memuat model fisik ke dalam Sistem MEGA. Tabel Gambar 8 dijabarkan dari
Gambar 7.C dan dimuat ke dalam Lapisan Koordinasi.

Gambar 8: Model Fisik dimuat ke dalam Lapisan Koordinasi

16
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

4.5 Definisi resep utama

Seperti yang dijelaskan dalam Bagian 4.2 MEGA membutuhkan definisi dari resep Master. Penjabaran dari proses
informal menjadi resep semi formal adalah sebagai berikut:

• Diperlukan untuk menjalankan prosesresep irigasi 1di atas hidran sederhanaHYS01

• Waktu mulai pelaksanaan resep: 27 Oktober 2013, pukul 12:00

• Akhir pelaksanaan resep: 27 Oktober 2013, pukul 12:30
• Maksimum air yang digunakan untuk irigasi: 800 liter

MEGA tidak menentukan bagaimana mendefinisikan resep. Dalam kasus kami, elemen-elemen berikut berlaku:

• Entitas target untuk resepnya adalah: WMD01.IRS01.DNT01.NBU01.HYS02

• Ketentuan yang berlaku untuk resep ini adalah:

– Tanggal Mulai (201312011200) menurut ISO8601

– Dua kondisi untuk menyelesaikan:
KeahlianVolume Maks>0.8(M3)
KeahlianDurasi Maks>1800(bagian)

Untuk mengilustrasikan bagaimana resep prosedur pengelolaan air terlihat seperti Gambar 9 menyajikan deskripsi
XML dari contoh resep Master yang diberikan di atas.

Gambar 9: Proses Operasi pada Entitas tunggal

Elemen terakhir yang akan dimuat ke dalam sistem MEGA adalah Master Recipe, yang merangkum proses yang
didefinisikan pada Gambar 9 ke dalam beberapa amplop “administratif”, yang deskripsi detailnya berada di luar cakupan
makalah ini.
Resep Master ditransfer ke Tingkat Koordinasi, di mana fungsi-fungsi berikut dilakukan:

17
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

1.Pemetaan Pengidentifikasi:Pengidentifikasi dari resep Master dipetakan ke dalam pengenal

subsistem. Algoritme pemetaan pengenal tidak ditentukan oleh MEGA, begitu pula versi OPC
UA saat ini. Di MEGA fungsi ini dibiarkan untuk implementasi manual atau semiotomatis sesuai
dengan preferensi pengembang. Saat ini ada inisiatif standardisasi OPC UA agar dapat
mendukung identifikasi otomatis entitas dengan OPC UA, kami berharap versi MEGA berikutnya
dapat memasukkan peningkatan ini.

2.Validasi resep:Validasi resep yang dikirim oleh Lapisan Manajemen dan Eksploitasi memerlukan
pemeriksaan bahwa subsistem terkait dapat menjalankan proses yang terdapat dalam Resep ini. MEGA
mendefinisikan prosedur untuk memutuskan kapan tidak akan menjadi masalah konkurensi terkait
dengan penugasan lebih dari satu proses ke entitas yang sama pada periode waktu yang sama. Dalam
skenario sederhana kami, HYSO1 tidak memiliki proses lain yang ditugaskan untuk dieksekusi, jadi tidak
ada masalah penjadwalan.

3.Proses transfer ke subsistem yang sesuai:Proses yang akan dijalankan untuk setiap entitas akan
ditransfer ke subsistem tempat entitas berada, dan alarm serta nilai dapat dipantau dari
Aplikasi Kontrol menggunakan mekanisme standar OPC UA. Dalam hal ini tidak ada alarm atau
nilai yang akan dipantau.

4.Kontrol dan pemantauan eksekusi proses:Proses yang ditransfer dipantau dari aplikasi
Kontrol, sedangkan proses dijalankan secara otonom di tingkat subsistem. Lapisan
Koordinasi memberikan informasi kepada Lapisan Manajemen dan Eksploitasi tentang
pelaksanaan setiap Resep.

4.6 Deskripsi skenario pengelolaan air

Skenario untuk pengelolaan air mempertimbangkan lingkungan alam, kota dan daerah pedesaan. Sistem
yang digunakan dalam skenario ini dikendalikan oleh aplikasi yang mengakses subsistem. Perlu
mempertimbangkan berbagai kondisi, mulai dari jumlah subsistem yang akan di-deploy hingga model
bisnis yang harus diperhatikan untuk kontrol subsistem, layanan eksploitasi, dan pertukaran informasi.
Bagian ini menjelaskan skenario penerapan yang telah kami tetapkan untuk memvalidasi model MEGA,
yang dikembangkan diAula Dei, sebuah stasiun percobaan di Zaragoza, Spanyol. Kami juga menghitung
daftar fungsi yang akan kami uji di stasiun ini.
Stasiun percobaan Aula Dei difokuskan pada siklus pengelolaan air, khususnya irigasi. Sebuah sistem
irigasi lengkap dimodelkan, dari asupan air hingga distribusi ke elemen terbaru (yaitu hidran). Satu sistem
irigasi bekerja dengan gravitasi dan yang lainnya bekerja dengan tekanan buatan, untuk mencakup semua
situasi yang dapat disajikan dalam pengaturan nyata. Dari sudut pandang elemen otomatisasi dan kontrol,
pelaksanaan berbagai prosedur diperbolehkan dalam elemen hidrolik yang sama. Secara khusus, instalasi
dibagi menjadi:

1. Jaringan atas dengan dua tangki air pada level yang berbeda dan stasiun pengangkat dengan dua pompa secara
paralel dan fungsi kontrol level.

2. Jaringan tekanan dengan stasiun pompa otomatis, tiga pompa secara paralel. Dua di antaranya dengan penggerak
kecepatan variabel. Jaringan terdiri dari 20 hidran, dikelompokkan menjadi 4 jalur yang mengembalikan air ke
tangki, menutup siklus.

3. Pusat kendali dengan peralatan komputer yang diperlukan untuk pengendalian dan pemasangan yang tepat, serta
untuk melakukan beberapa pengujian atas aplikasi manajemen.

18
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

4. Saluran dengan elemen pengatur untuk air hilir, pintu pengatur untuk air hulu, pintu
pengatur campuran dan pintu pengatur aliran.

Gambar 10: Deposito dan tiga stasiun pompa di Aula Dei

Gambar 11: Sistem irigasi di Aula Dei

Gambar 10 menunjukkan deposit dan tiga stasiun pompa yang dipasang di Aula Dei. Gambar 11
menunjukkan sistem irigasi yang terdiri dari 20 hidran dan elemen regulasi terkait.
Pengujian berikut dilakukan untuk memverifikasi pengoperasian yang benar dari peralatan yang dipasang:

• Pengujian pada sistem jarak jauh, memeriksa pengoperasian yang benar dari peralatan yang dipasang
berdasarkan pengaturan yang diperlukan. Juga memeriksa interoperabilitas antara peralatan dan pusat kendali.

19
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

• Tes aliran pengaturan air, memeriksa fungsi optimal berbagai algoritma kontrol, baik di stasiun
pompa yang beroperasi bersama dengan tangki dan di titik kontrol regulasi untuk hidran.

• Pengujian pada aplikasi manajemen, memeriksa operasi yang benar dan interoperabilitas dengan sistem
yang diinstal. Beberapa komputer dipasang untuk melakukan pengujian paralel guna memeriksa
koordinasi peralatan dan mendeteksi gangguan.

Kami menghitung daftar fungsi yang akan kami uji dalam skenario yang dijelaskan:

• Memuat dan konfigurasi elemen model fisik. Pemetaan entitas hidrolik dan asosiasi ke
pengontrol subsistem. Pemantauan dan daftar elemen model fisik yang terdaftar di
lapisan Koordinasi.

• Pengumpulan dan konsolidasi data dari subsistem. Koordinasi subsistem dan integrasi data,
yaitu integrasi data agregat hidran untuk pengawasan cabang.

• Eksekusi resep kontrol di entitas virtual, menetapkan tindakan yang sesuai ke subsistem terkait.
Pembuatan pendaftar riwayat yang dinormalisasi untuk entitas virtual.

• Penerimaan, interpretasi, alokasi dan pengiriman elemen dari model proses. Pemantauan dan
daftar elemen-elemen ini.

• Penyimpanan, publikasi, dan distribusi topologi hidrolik ke aplikasi yang membutuhkannya.

Penyimpanan dan publikasi data sensor (kondisi cuaca, kelembaban, suhu) yang dikumpulkan oleh
subsistem lama, disesuaikan dengan model MEGA.

5 Kesimpulan dan Pekerjaan Masa Depan

Pengelolaan air berdampak pada beberapa hal penting dalam kehidupan manusia dan beberapa skenario, seperti kota, kawasan
alami, pertanian, dll. Beberapa pekerjaan berfokus pada kurangnya layanan TIK dan alat untuk pengelolaan air, yang
memungkinkan penggunaan kembali informasi (tujuan PSI Directive [20]), memudahkan pemenuhan regulasi kebijakan dan
pemantauan sumber daya.
Dalam makalah ini kami mempresentasikan inisiatif MEGA untuk mendefinisikan arsitektur referensi untuk
pengelolaan air berdasarkan mengintegrasikan kemampuan IoT untuk mencapai sistem industri yang skalabel
dan layak. Kami mendefinisikan lapisan eksploitasi manajemen, lapisan koordinasi, lapisan subsistem dan lapisan
administrasi dan antarmuka yang memungkinkan interaksi lapisan. Kami juga mempertimbangkan model fisik,
yang mendefinisikan elemen fisik yang melaksanakan proses pengelolaan air secara hierarkis, dan juga, model
proses, yang mengatur pelaksanaan proses tertentu dalam subsistem pengelolaan air.
Proses ditentukan berdasarkan prinsip otomatisasi dan menggunakan standar OPC UA yang banyak digunakan. Kami
mengilustrasikan bagaimana arsitektur tersebut dapat digunakan untuk mengontrol sistem pengelolaan air yang sebenarnya,
tetapi kami masih perlu mendefinisikan dengan jelas prosedur operasi untuk menangani banyak masalah nyata seperti definisi
jaringan fisik atau pemetaan pengenal.
Terakhir, kami menjelaskan skenario penerapan yang telah kami tetapkan untuk validasi model MEGA,
yang dikembangkan di Aula Dei, stasiun eksperimental di Zaragoza, menyebutkan daftar fungsi yang akan
kami uji di stasiun ini.
Kita dapat menyimpulkan bahwa adopsi IoT dan OPC UA memfasilitasi perusahaan pengelola air untuk mengakses
pasar global yang lebih luas dan menggabungkan manfaat baru untuk sistem pendukung keputusan, pemantauan, tata
kelola air, dan juga hubungan energi air. Pekerjaan di masa depan akan menjelaskan pengujian yang dilakukan dan akan
fokus pada kontribusi untuk memecahkan masalah koordinasi saat menjalankan beberapa resep pada sumber daya fisik
yang sama, dengan mempertimbangkan prioritas dan eksekusi bersyarat serta optimalisasi proses.

20
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

ucapan terima kasih

Pekerjaan ini sebagian didukung oleh MEGA, upaya penelitian bersama Tragsa dan UPM. Hal ini juga didukung
oleh proyek CALISTA, TEC2012-32457, yang diberikan oleh Kementerian Ekonomi dan Daya Saing di Spanyol.

Referensi
[1] Perserikatan Bangsa-Bangsa. Laporan Pembangunan Berkelanjutan Global – Ringkasan Eksekutif: Membangun Masa Depan Bersama
yang Kita Inginkan. New York: Departemen Urusan Ekonomi dan Sosial Perserikatan Bangsa-Bangsa, Divisi Pembangunan
Berkelanjutan. 2013. http://sustainabledevelopment.un.org/globalsdreport/, terakhir dilihat November 2014.
[2] T. Robles, R. Alcarria, D. Martn, dan A. Morales, "Model berbasis Internet of Things untuk pengelolaan air
pintar," diProk. dari Konferensi Internasional ke-8 tentang Jaringan Informasi Tingkat Lanjut dan Lokakarya
Aplikasi (WAINA'14), Victoria, Kanada. IEEE, Mei 2014, hlm. 821–826.
[3] HollandTrade, beranda: http://www.hollandtrade.com/, terakhir dilihat November 2014, 2014.
[4] Asosiasi Teknologi Air, beranda: http://www.awt.org/, terakhir dilihat November 2014, 2014.
[5] Petunjuk Kerangka Air UE (Petunjuk 2000/60/EC), 2000.
[6] Beranda grup TRAGSA: http://www.tragsa.es/en/, terakhir dilihat November 2014.
[7] Beranda proyek MEGA: http://www.gestiondelagua.es/en/, terakhir dilihat November 2014.
[8] Beranda OPC: https://opcfoundation.org, terakhir dilihat November 2014.
[9] J. Gubbi, R. Buyya, S. Marusic, dan M. Palaniswami, “Membangun masa depan bersama yang kita inginkan,” United Nations
Department of Economic and Social Affairs, 2013.
[10] M. Weiser, R. Gold, dan JS Brown, "Asal Ubiquitous Computing Research di PARC pada Akhir 1980-an,"
Jurnal Sistem IBM, vol. 38, tidak. 4, hlm. 693–696, Desember 1999.
[11] R. Alcarria, T. Robles, A. Morales, DL de Ipiña, dan U. Aguilera, "Mengaktifkan pemanggilan kemampuan yang
fleksibel dan berkelanjutan di lingkungan prosumer bergerak,"Sensor, vol. 12, tidak. 7, hlm. 8930–8954, Juni 2012.
[12] R. Alcarria, T. Robles, A. Morales, dan E. Cedeño, “Menyelesaikan tantangan koordinasi dalam eksekusi layanan
seluler terdistribusi,”Jurnal Internasional Layanan Web dan Grid, vol. 10, tidak. 2, hlm. 168–191, Januari 2014.

[13] E. Serrano, P. Moncada, M. Garijo, dan C. Iglesias, "Mengevaluasi teknik pilihan sosial ke dalam lingkungan
cerdas dengan simulasi sosial berbasis agen,"Ilmu Informasi, vol. 286, hlm. 102–124, Desember 2014.

[14] L. Atzori, A. Iera, dan G. Morabito, “The Internet of Things: A survey,”Jaringan komputer, vol. 54, tidak. 15, hlm.
2787–2805, Oktober 2010.
[15] D. Miorandi, S. Sicari, FD Pellegrini, dan I. Chlamtac, “Internet of things: Visi, aplikasi, dan tantangan
penelitian,”Jaringan Ad Hoc, vol. 10, tidak. 7, hlm. 1497–1516, September 2012.
[16] AENOR EN 61512: Kontrol batch – Bagian 2: Struktur data dan pedoman untuk bahasa, 2002.
[17] AENOR EN 62264: Integrasi sistem kontrol perusahaan - Bagian 1: Model dan terminologi, 2013.
[18] M. Melik-Merkumians, T. Baier, M. Steinegger, W. Lepuschitz, I. Hegny, dan A. Zoitl, “Menuju OPC UA sebagai
middleware SOA portabel antara perangkat lunak kontrol dan aplikasi nilai tambah eksternal,” dalamProk.
Konferensi IEEE ke-17 tentang Teknologi Berkembang dan Otomasi Pabrik (ETFA'12), Kraków, Polandia. IEEE,
September 2012, hlm. 1–8.
[19] J. Imtiaz dan J. Jasperneite, “Skalabilitas OPC-UA hingga ke level chip memungkinkan Internet of Things,” di
Prok. dari Konferensi Internasional IEEE ke-11 tentang Informatika Industri (INDIN'13), Bochum, Jerman.
IEEE, Juli 2013, hlm. 500–505.
[20] Arahan PSI (2003/98/EC). Arahan tentang penggunaan kembali informasi sektor publik mulai berlaku pada tanggal
31 Desember 2003, Komisi Eropa.

————————————————————————————————————————————————————

21
Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

Biografi Penulis

Tomas Roblesmenerima gelar MS dan Ph.D. gelar di bidang Teknik Telekomunikasi dari
Universitas Teknik Madrid pada tahun 1987 dan 1991 masing-masing. Sejak tahun 1991
ia adalah profesor di bidang Teknik Telematika di ETSI Telekomunikasi Universitas
Teknik Madrid. Minat penelitiannya difokuskan pada Aplikasi dan layanan Tingkat Lanjut
untuk jaringan Broadband, baik jaringan kabel maupun nirkabel.

Ramon Alcarriamenerima gelar MS dan Ph.D. gelar di bidang Teknik

Telekomunikasi dari Universitas Teknik Madrid pada tahun 2008 dan 2013.
Saat ini, ia adalah asisten profesor di Topografi ETSI Universitas Teknik
Madrid. Minat penelitiannya adalah Arsitektur Layanan, Jaringan Sensor,
Komposisi Layanan, dan Lingkungan Prosumer.

Diego Martnmeraih gelar doktor pada tahun 2012, meraih gelar B.Sc di bidang Teknik
Komputer dan gelar MS di bidang Ilmu Komputer dari Departemen Informatika di Carlos III
University of Madrid, Spanyol. Bidang penelitian utamanya adalah Peningkatan Proses
Perangkat Lunak, Manajemen Pengetahuan dan Pemanfaatan Kembali, dan Lingkungan
Prosumer.

Mariano Navarrolulus sebagai Insinyur Telekomunikasi dari Technical University of

Madrid pada tahun 1990. Saat ini bekerja sebagai Kepala Unit ICT sejak tahun 2005. Ia
telah bekerja di TRAGSA Group, (Tragsa & Tragsatec) selama 18 tahun. Pakar Inovasi
Terbuka dan Ruang Sosial untuk Penelitian dan Inovasi, juga berpartisipasi dan
mengoordinasikan beberapa proyek UE. Anggota ENoLL, pemimpin lab TRAGSA Living,
dan anggota jaringan SSRI.

Rodrigo Calerolulus di Teknik Pertanian, spesialisasi di Teknik Pedesaan, dari University of

Cordoba. Sejak 1999, ia bekerja di Grup Tragsa di Unit Litbang di bidang-bidang yang terkait
dengan pengolahan air, pengelolaan air, irigasi, infrastruktur pedesaan, biomassa, dan
penggunaan energi. Saat ini menjabat sebagai Kepala Departemen di Unit Litbang. Dalam
hal ini, dia telah mengoordinasikan beberapa proyek nasional R&D dan dia adalah penulis
beberapa paten dan makalah.

22
 Arsitektur referensi berbasis IoT Robles, Alcarria, Martn, Navarro, Calero, Iglesias dan López

Sofa Iglesiaslulus dalam Teknik Pertanian dari Universitas Teknik Madrid (2001).
Magister Perdagangan Internasional (CESMA). Setelah satu tahun bekerja di area
komersial sebagai manajer produk internasional, ia mulai bekerja di Tragsa 10 tahun
yang lalu. Dia berpartisipasi dalam proyek-proyek nasional dan internasional yang
berhubungan dengan air, mengimplementasikan manajemen air dan proyek-proyek
teknik sipil dan mengajar manajemen air dan proyek di Sekolah Teknik dan Arsitektur.

Manuel Lópezmenerima gelar Ph.D. gelar dari Universitas Cordoba. Ahli dalam Fisika
Terapan, Analisis, Simulasi dan Kontrol Program Teknik Lanjutan (2007). Dia juga adalah
Insinyur Pertanian yang berspesialisasi dalam teknik pedesaan. Dia telah bekerja di Tragsa
Group selama 25 tahun. Dia menjabat sebagai kepala unit Inovasi dan R&D selama 15 tahun.
Dia telah mengoordinasikan beberapa proyek R&D nasional dan internasional dan dia adalah
penulis beberapa makalah, bab buku, dan paten. Saat ini menjabat sebagai Deputi Direktur
Dukungan Teknis di Tragsa.

23

Lihat statistik publikasi