BAB 3 ANALISIS DAN PERANCANGAN Analisis Sistem Yang Sedang Berjalan

(1)

BAB 3

ANALIS IS DAN PERANCANGAN

3.1. Analisis Masalah dan Kebutuhan Sistem 3.1.1. Analisis Sistem Yang Sedang Berjalan

Analisis sistem yang sedang berjalan kami lakukan dengan melakukan studi literatur pada penelitian yang dilakukan oleh Aryan Wibowo, Setiadi Wiguna dan Derwin Suhartono yang berjudul “Analisis Dan Perancangan Aplikasi Manajemen Controller-Area Network Berbasis Modbus Pada Multi Genset Controller Melalui Jaringan Lokal Dan Internet” serta wawancara dengan teknisi genset pada perusahaan PT. KitaM aju Niaga, yaitu sebuah perusahaan supplier modul genset controller yang membuka kantornya di komplek pergudangan Arcadia Daan M ogot, Blok G1 no. 10, Batu Ceper – Tanggerang.

Berdasarkan hasil wawancara tersebut, kita memperoleh kenyataan bahwa sistem yang saat sedang berjalan adalah mekanisme pengawasan genset yang dilakukan oleh teknisi dengan menghampiri setiap modul untuk melihat informasi–informasi genset. Selain itu, dengan hanya mengandalkan tampilan layar yang disediakan modul genset controller, teknisi tidak dapat memperoleh informasi secara lengkap. Sehingga dibutuhkan sebuah perangkat komputer atau laptop untuk dikomunikasikan dengan genset controller dengan menggunakan media komunikasi kabel serial RS-485.

(2)

Gambar 3.1. Sistem yang sedang berjalan

Gambar diatas adalah gambaran sistem yang sedang berjalan saat ini. Dengan rangkaian seperti demikian, teknisi perlu mendatangi satu- persatu modul genset controller untuk memperoleh informasi genset.

Sehingga dapat disimpulkan bahwa masalah-masalah yang ada pada sistem yang berjalan saat ini adalah, sebagai berikut :

1. Perolehan informasi genset yang terbatas jika tidak menggunakan perangkat komputer.

2. Dibutuhkan waktu yang sangat banyak untuk untuk melakukan pengawasan terhadap beberapa genset sekaligus.

(3)

3.1.2. Analisis Hasil Pengembangan Sistem Sebelumnya

Pada pengembangan sebelumnya yang telah dilakukan oleh Aryan dan rekan-rekannya yang juga dilakukan pada PT. KitaM aju Niaga, maka permasalahan-permasalahan yang ditemui pada sistem yang berjalan saat ini telah berhasil dipecahkan. Simpulan ini kami peroleh melalui studi literatur pada skripsi Aryan dan rekan-rekannya yang berjudul “Analisis Dan Perancangan Aplikasi M anajemen Controller-Area Network Berbasis M odbus Pada M ulti Genset Controller M elalui Jaringan Lokal Dan Internet”.

Bentuk hasil dari pengembangannya sendiri berupa sebuah sistem baru yang memanfaatkan kemampuan modul genset controller yang dilengkapi dengan protokol modbus yang dapat dihubungkan dengan modul gonset controller lainnya secara serial dengan menggunakan kabel serial RS-485 dan membentuk sebuah Controller Area Network.

Setelah modul-modul terhubung dan membentuk sebuah CAN, maka diperlukan sebuah aplikasi yang dapat berkomunikasi dengan multiple genset. Aplikasi ini yang akan disebut dengan daemon pada pembahasan berikutnya.

(4)

Gambar 3.2. Controller Area Network

CAN yang terbentuk adalah hubungan antara modul-modul secara serial yang dihubungkan dengan remote komputer. Untuk memberikan fokus penulisan, maka penggambaran CAN hanya digambarkan dengan modul-modulnya tanpa genset. Seperti pada gambar sistem hasil pengembangan sebelumnya di bawah ini.

(5)

Gambar 3.3. Topologi Sis tem Pengembangan Sebelumnya

Gambaran sistem hasil pengembangan ini dapat dilihat pada gambar diatas. Pada hasil pengembangan ini, user (dalam hal ini adalah teknisi) telah diberikan sebuah kemudahan dalam mengakses informasi- informasi genset. Teknisi cukup menggunakan komputer yang terhubung dengan internet dan mengakses data server pada sebuah CAN untuk memperoleh informasi-informasi genset yang berada dalam CAN tersebut. Komputer dalam sebuah jaringan yang sama dengan CAN juga dapat digunakan untuk mengakses informasi yang berada pada data server.

(6)

Namun, setelah kami melakukan studi terhadap pengembangan ini, kami menemukan masalah-masalah lainnya, yang akan kami tuliskan pada subbab berikutnya.

3.1.3. Analisis Masalah Pada Pengembangan Sistem Sebelumnya

Pada pengembangan sebelumnya sistem telah mampu untuk melakukan pengawasan multiple genset melalui web. Web yang diakses oleh user memperoleh informasi multiple genset yang disimpan dalam sebuah database yang terletak dalam satu area jaringan lokal, sehingga untuk melihat informasi pada CAN-CAN lainnya, teknisi harus mengakses domain yang berbeda dengan CAN-CAN lainnya.

Permasalahannya dapat dijelaskan bahwa metode monitoring yang berjalan saat ini kurang efektif terutama jika terdapat lebih dari satu CAN yang diinstalasikan.

Aplikasi controller pada remote computer dapat dikembangkan dengan menambahkan sebuah identifikasi lokasi sebuah CAN. Dengan penambahan identifikasi lokasi sebuah CAN, maka informasi CAN yang satu dengan CAN yang lainnya dapat disimpan dalam sebuah database yang sama. Sehingga untuk melakukan pengawasan genset pada beberapa CAN, teknisi genset dapat mengaksesnya pada database dan domain yang sama. Pada sistem yang berjalan saat ini pada setiap CAN harus memiliki satu IP publik. Sedangkan dengan kebutuhan IP, khususnya IPv4 yang semakin banyak, maka semakin sedikit pula sebuah provider jaringan internet memberikan IP publik untuk client mereka. Permasalahannya

(7)

dapat dijelaskan bahwa tanpa IP publik untuk masing-masing CAN, maka aktifitas monitoring tidak dapat dilakukan. Dengan mengembangkan aplikasi kontroler dengan lokasi penyimpanan data yang ditempatkan pada satu tempat saja, maka hanya dibutuhkan satu IP publik untuk dikenali oleh semua CAN dan sebagai webhosting.

Permasalahan lebih lanjut adalah jika akhirnya sudah diciptakan aplikasi yang dapat berkomunikasi dengan multiple CAN, perlu adanya ketersediaan keamanan pemindahan data melalui jalur publik serta kemudahan akses antara satu CAN dengan CAN lainnya dan dengan server data. Infrastruktur berbasiskan jalur Virtual Private Network adalah solusi terbaik dalam memecahkan masalah ini, karena selain memberikan keamanan tambahan dengan enkripsi, VPN juga memberikan kemudahan akses dengan membuat rancangan sebuah jaringan melalui jalur publik, terlihat seolah-olah adalah jaringan lokal, disamping manfaat lain seperti share data antar pengguna. Dengan menggunakan infrastruktur VPN, maka akses database dapat dilakukan tanpa harus melalui jalur public. Ini berarti database dapat berjalan sesuai dengan standar keamanan yang sudah disediakan oleh M ySQL.

M asalah pertama yang paling kritis adalah mengenai protokol agar client dapat berkomunikasi dengan database yang diperoleh dari genset controller dalam satu CAN. Informasi yang dikirimkan genset controller melalui protokol M odbus ke daemon hingga sampai ke client yang menggunakan protokol TCP/IP, tentunya memerlukan protokol sebagai penengah komunikasi tersebut.

(8)

3.2. Perancangan Sistem

Seperti yang telah dijelaskan sebelumnya, sistem yang baru ini adalah bentuk perluasan dari pengembangan sebelumnya, yaitu pemantauan sebuah CAN dalam satu waktu. Dalam perancangan, sistem yang baru ini dihadapkan pada kebutuhan untuk memantau CAN yang jumlahnya lebih dari satu, dan memiliki letak geografis yang berjauhan.

Rancangan sistem yang baru ini terdiri menjadi 3 bagian :

• Subsistem I, koneksi antara remote komputer dan database server dengan VPN server.

• Subsistem II, koneksi antara genset controller dengan daemon hingga proses penyimpanan data ke database server melalui jalur VPN.

• Subsistem III, relasi end user dengan database server untuk memperoleh informasi genset

3.2.1. Subsistem I

Pada Subsistem I, remote komputer pada CAN terhubung dengan VPN server, sehingga jaringan antara CAN dengan CAN lainnya dan juga database server terlihat seperti jaringan lokal. Setiap remote komputer akan memperoleh IP dari VPN server agar dapat berkomunikasi database server.

(9)

Gambar 3.4.Sistem yang dirancang (Topologi Subsistem I)

start

Remote komputer dan database server melakukan koneksi ke

VPN

Setiap remote komputer terhubung dengan database

melalui koneksi VPN

VPN SERVER memberikan IP VPN untuk masing-masing remote komputer dan database server

Autentikasi username dan

password

Berhasil

gagal

Gambar 3.5. Flowchart Subsistem I

(10)

Dalam flowchart dijelaskan bahwa saat sistem dimulai dengan mengawali remote komputer untuk melakukan koneksi dengan multiple genset. Kemudian remote komputer dari masing-masing lokasi memulai koneksi ke VPN server dengan cara autentifikasi username dan password yang telah terdaftar pada VPN server, apabila username dan password yang diinput cocok dengan daftar user yang berada pada VPN server , maka VPN akan memberikan IP baru untuk masing-masing remote komputer, sehingga remote komputer terhubung dengan VPN server.

Dengan ini dapat dikatakan bahwa subsistem I telah berhasil, yaitu remote komputer terhubung dengan VPN server.

Apabila user gagal untuk melakukan koneksi VPN, user akan mengulang inputan username dan password kembali. Ada beberapa kemungkinan alasan mengapa remote komputer tidak dapat terkoneksi dengan VPN server, salah satunya adalah username dan password yang dimasukkan salah atau tidak terdaftar pada daftar user yang boleh melakukan akses ke VPN server, dan penyebab kegagalan lainnya bisa disebabkan oleh kesalahan konfigurasi pada jaringan host maupun servernya sendiri.

3.2.2. Subsistem II

Pada subsistem II, data yang diperoleh dari hasil interaksi daemon dengan modul dikirikanm ke database server melalui jaringan virtual yang dibuat dengan menggunakan VPN. Sebelum subsistem I dijalankan

(11)

data hanya bisa diperoleh daemon, namun tidak dapat disimpan ke dalam database.

simbol deskripsi - - - Koneksi virtual

Koneksi fisik

Gambar 3.6. Topologi Subsistem II

(12)

Gambar 3.7. Flowchart Subsistem II

(13)

Subsistem II merupakan tahap dimana aplikasi daemon diaktifkan. Aplikasi ini berfungsi untuk secara aktif memantau seluruh genset yang terhubung dengan remote komputer secara bergantian. M ula- mula remote komputer user harus memasukkan kota dan lokasi pada aplikasi tersebut. Lalu dilakukan autentikasi data, jika autentikasi gagal berarti ada duplikasi data.

Namun jika autentikasi sukses, data inputan dari remote komputer user akan disimpan ke dalam database. Lalu akan dimulai koneksi antara remote komputer dengan genset controller. Aplikasi daemon akan secara otomatis menyimpan alamat genset yang online ke dalam database.

Remote komputer akan mengambil data dari genset yang online secara berurutan dari awal hingga akhir. Jika pengambilan data gagal dilakukan maka counter genset ini akan bertambah. Lalu remote komputer akan mengambil data pada genset berikutnya.

Apabila gagal, counter genset ini juga akan bertambah. Apabila counter genset setelah bertambah menjadi sama dengan tiga, artinya daemon telah berusaha mengambil data genset namun gagal hingga tiga kali, maka genset tersebut akan dinyatakan offline.

3.2.3. Subsistem III

Pada subsistem III, client memperoleh informasi genset dengan berinteraksi dengan database server melalui web user interface. Web user interface diakses dengan memasukan alamat IP atau nama alamat yang

(14)

telah didaftarkan pada webhosting. Client juga bisa mengaksesnya dari jaringan yang sama dengan database server.

simbol deskripsi - - - Koneksi virtual

Koneksi fisik

Gambar 3.8. Topologi Subsistem III

Subsistem ini menggunakan aplikasi web yang dapat dibuka pada web browser oleh client sebagai interface client untuk dapat melihat data monitoring genset. Agar data aman dari akses sembarang orang, maka user perlu melalui proses autentikasi. Berikut adalah flowchart subsistem ini yaitu

(15)

Gambar 3.9. Flowchart Subsistem III

Pada halaman pertama dari aplikasi web, user akan memasuki halaman login. Tujuannya agar hanya user yang terdaftar yang dapat membuka halaman main pada aplikasi web ini. Jika autentikasi username dan password berhasil maka user akan dibuatkan session.

(16)

Lalu user akan masuk ke halaman main. Jika user langsung masuk ke halaman main tanpa melalui halaman login maka user akan diredirect ke halaman login karena user belum memiliki session. Pada halaman main, user dapat memilih kota dan lokasi dari genset yang ingin dia pilih.

Lalu user dapat memilih pilihan basic instrumentation, extended instrumentation, derived instrumentation, dan accumulated instrumentation. Selain itu user juga dapat melihat halaman detail dari tiap menu yang ada. Jika user ingin keluar dari aplikasi web, user dapat mengklik log out, dan secara otomatis session akan berakhir dan user akan kembali ke halaman login.

(17)

Gambar 3.10. State Transition Diagram Subsistem III

3.3. Perancangan Database

Dibutuhkannya database adalah untuk menampung atau menyimpan berbagai data yang diambil dari genset-genset yang terkonseksi pada sistem.

Pertama-tama dibutuhkan database untuk mencatat daftar genset yang sedang online (dalam kondisi menyala dan terhubung dengan CAN) , kemudian database

(18)

untuk mencatat hasil retrieve (saat aplikasi daemon merequest ke setiap genset) data dari genset.Kemudian database untuk memberikan informasi lokasi (berdasarkan kota dan nama gedung) dimana genset diletakkan.

Untuk itu semua database sistem yang dibuat membutuhkan 4 tabel, yaitu ms_lokasi, ms_page, ms_slave, dan trans.

Nama Tabel : ms_slave

Keterangan : untuk mencatat daftar genset yang (pernah) terkoneksi pada sistem dan status terakhir (online / tidak)

Atribut Keterangan Tipe Null

id_genset Alamat genset (Primary Key)

Varchar(3) Tidak

Status Status genset (1= online, 0=

offline)

Binary(1) Tidak

Time Tanggal dan waktu record disimpan

Timestamp Tidak

M ode M ode kontrol genset (1=

auto, 2= manual)

Char(1) Tidak

Kd_lokasi Kode lokasi dari alamat genset ( yang diambil dari 2 karakter paling awal nama gedung dan diberikan increment angka dibelakangnya apabila terdapat pengambilan 2 karakter paling awal yang sama)

Varchar(3) Ya

Tabel 3.1. Rancangan Entity dari tabel ms_slave

(19)

Nama Tabel : trans

Keterangan : untuk mencatat setiap hasil retrieve data dari genset

Id Nomor record (Primary Key) Integer Tidak id_genset Alamat genset (foreign key) Varchar(3) Tidak id_page Kode page dan offset data Varchar(6) Tidak

Value Nilai dari data Varchar(20) Ya

Slave_addr Untuk melihat pengalamatan dari genset dalam suatu lokasi.

Varchar(9) Tidak

Tabel 3.2. Rancangan Entity dari tabel trans

Nama Tabel : ms_page

Keterangan : untuk memberikan deskripsi dari kode page dan offset (id_detail pada tabel trans). Tabel ini tidak untung digabungkan dengan trans untuk mengurangi redundansi

id_page Kode page dan offset data (Primary Key)

Varchar(6) Tidak

Description Deskripsi dari kode page dan offset yang bersangkutan

Varchar(20) Tidak

Tabel 3.3. Rancangan Entity dari tabel ms_page

(20)

Nama Tabel : ms_lokasi

Keterangan : untuk mengindikasikan dimana lokasi CAN berada. Dengan begitu kita dapat mengetahui letak slave berada.

Kd_lokasi Kode lokasi dari alamat genset ( yang diambil dari 2 karakter paling awal nama gedung dan diberikan increment angka dibelakangnya apabila terdapat pengambilan 2 karakter paling awal yang sama)

Varchar(3) Tidak

Kota Identifikasi kota dimana slave berada

Varchar(30) Ya

Gedung Identifikasi lokasi spesifik dimana slave berada

Varchar(30) Ya

Tabel 3.4. Rancangan Entity dari tabel ms_lokasi

Gambar 3.11. Entity Relationship Diagram Database Sistem

(21)

Berdasarkan Entity Relation Diagram (ERD) diatas, dapat kita lihat hubungan antar tabel, yang kemudian dapat digunakan untuk merancang sistem penyimpanan informasi database.

Di samping database sistem, diperlukan juga database untuk user mengingat user akan mengakses informasi melalui web interface. Database user berguna untuk mendata siapa saja yang berhak mengakses sekaligus menjadi sumber autentikasi bagi web server. Database untuk user hanya akan terdiri dari satu tabel yang berisi field username dan password.

Nama Tabel : ms_user

Keterangan : untuk mendata username dan password untuk autentikasi user

id Penomoran (Primary Key) Integer Tidak

username Nama identifikasi user (unik) Varchar(20) Tidak

password Password Varchar(20) Tidak

Tabel 3.5. Rancangan Entity dari tabel ms_user

3.4. Perancangan Website

Perancangan sitemap untuk aplikasi web tersebut sesuai dengan pengorganisasian data-data monitoring dapat dilihat di bawah ini

(22)

3.4.1. Sitemap Diagram

Halaman login Pilih

Kota - lokasi

Halaman Main Basic instrumentation

Halaman Extended instr umentation

Halaman Der ived instrumentation

Halaman Accumulation instr umentation

Detail basic instrumentation

per genset

Detail accumulation instrumentation

per genset Detail extended instrumentation

per genset

Detail derived instrumentation

per genset

Gambar 3.12. Sitemap Diagram

Berdasarkan sitemap diagram diatas, maka dapat dilihat bahwa :

• Data monitoring ditampilkan berdasarkan halaman

• Pada setiap halaman ditampilkan semua genset yang online berdasarkan kota dan lokasi yang dipilih dan sebagian data dari halaman yang bersangkutan

• Detail data dari setiap halaman ditampilkan untuk setiap genset yang dipilih

3.4.2. Tampilan Halaman

Untuk mempermudah user dalam berinteraksi dengan database dan memperoleh informasi genset, maka diperlukan rancangan halaman web, yang dapat dilihat sebagai berikut :

(23)

• Halaman Login

Gambar 3.13. Rancangan Input Form Login

• Halaman Main

Gambar 3.14. Rancangan Output Halaman M ain

(24)

• Halaman Basic Instrumentation

Gambar 3.15. Rancangan Output Halaman Basic Instrumentation

• Halaman Detail Basic Instrumentation

Gambar 3.16. Rancangan Output Detail Halaman Basic Instrumentation

(25)

• Halaman Extended Instrumentation