BAB IV PERANCANGAN. 4.1 Perancangan Mobile Tracker Simulator (MTS)

(1)

IV-1

BAB IV

PERANCANGAN

Bab ini akan menjelaskan perancangan AntiJam. Pembahasan perancangan pada bab ini akan diorganisasikan menjadi per-modul. Supaya pembahasan dalam Tugas Akhir ini ringkas dan padat, maka pembahasan perancangan:

1. Akan dititikberatkan pada stream programming yang menjadi inti dari Tugas Akhir, dan

2. Untuk hal non stream-programming, pembahasan hanya meliputi hal-hal yang bersifat non-trivial.

4.1 Perancangan Mobile Tracker Simulator (MTS)

Sub-bab ini akan membahasa perancangan modul Mobile Tracker Simulator (MTS). Pembahasan akan didahului tentang definisi simulasi pergerakan telepon seluler, parameter simulasi, rancangan input, output, dan protokol yang digunakan MTS.

4.1.1 Perancangan Input MTS

MTS akan membutuhkan input data berikut ketika dijalankan:

1. Alamat IP dari modul Traffic Pool. Alamat ini diperlukan supaya MTS dapat mengirimkan data simulasi ke Traffic Pool.

2. File map yang sama dengan yang digunakan pada modul Traffic Pool dan

Congestion List. File ini akan berisi graf.

4.1.2 Perancangan Output MTS

Berdasarkan use case pada Gambar III-4, MTS akan mengirimkan paket data ke modul Traffic Pool dengan alamat IP yang diberikan pada input. Paket data tersebut akan berisi field seperti yang dijelaskan pada Tabel IV-1.

(2)

IV-2

Tabel IV-1: Paket data output modul MTS

No. Field Panjang Keterangan

1. Cellphone ID 4 byte No. telepon seluler 2. Xpos 4 byte Posisi latitude 3. Ypos 4 byte Posisi longitude

4. Timestamp 4 byte Timestamp saat data di-generate

4.1.3 Perancangan Protokol MTS

Dalam mengirimkan hasil simulasi, MTS tidak menggunakan protokol khusus. MTS hanya mengirimkan data secara kontinu ke modul Traffic Pool pada sebuah alamat IP tertentu dengan protokol UDP.

4.2 Perancangan Modul Traffic Pool (TP)

Sub-bab ini akan menjelaskan tentang perancangan modul Traffic Pool. TP adalah sebuah modul yang bertugas:

1. Menerima data posisi telepon seluler dari MTS,

2. Menentukan kecepatan telepon seluler dari perbedaan posisi antara dua waktu,

3. Mengirimkan data kecepatan ke modul lain yang membutuhkan.

Traffic Pool dirancang menjadi sebuah server. Server ini akan memiliki thread

yang dijelaskan pada Tabel IV-2.

Tabel IV-2: Thread pada Traffic Pool

No. Fungsi Thread Critical Section

1. Listening update data posisi vehicle dari MTS, menentukan kecepatan.

Saat write vehicle data ke CPU memory.

2. Mengirimkan data ke Traffic Pool Observers. Dalam Tugas Akhir ini, Traffic Pool Observer adalah modul

Congestion Analyzer dan Visual Representation

Saat read vehicle data untuk mengirimkannya.

Thread (1) akan menerima data dari MTS dengan Protocol Data Unit (PDU) yang

dijelaskan pada sub-bab 4.1.2 . Karena thread (1) hanya menerima data posisi (bukan data kecepatan), maka thread (1) harus menentukan data kecepatan sesaat

(3)

IV-3

telepon seluler dengan membandingkan antara lokasi pada satu waktu dengan lokasi waktu sebelumnya.

Baik thread (1) maupun thread (2) akan mengirim dan menerima data melalui protokol UDP sederhana.

4.3 Perancangan Modul Congestion Analyzer (CA)

Berikut ini adalah perancangan dari modul Congestion Analyzer. Pada bagian ini, akan dijelaskan perancangan server, proses pendeteksian kemacetan, perancangan protokol, input, dan output CA.

4.3.1 Perancangan Server

Modul Congestion Analyzer akan diimplementasikan sebagai sebuah server yang melakukan proses listening pada sebuah port UDP untuk menerima update data kendaraan secara terus menerus dari TP. Statechart diagram dari Congestion

Analyzer dapat dilihat pada Gambar IV-1.

Dari Gambar IV-1, dapat dilihat bahwa dalam Congestion Analyzer ada 3 buah

thread, yakni dijelaskan pada Tabel IV-3.

Tabel IV-3: Thread pada Congestion Analyzer

No. Fungsi Thread Critical Section

1. Listening update data vehicle Saat write vehicle data ke CPU memory.

2. Melakukan pengenalan kemacetan dan memberikan hasilnya pada Congestion List

1. Saat membaca data parameter pengenalan kemacetan

2. Saat load data kemacetan dari CPU memory ke GPU memory

3. Listening request perubahan kemacetan Saat write update parameter pengenalan kemacetan

Sedangkan shared object yang digunakan oleh thread di atas dijelaskan pada Tabel IV-4.

(4)

IV-4

Tabel IV-4: Shared object pada Congestion Analyzer

No. Nama Shared Object No. Thread Pengguna

1. Vehicle Data Thread 1

Thread 2

2. Congestion Parameter Thread 2

Thread 3

Request Edge List to Traffic Pool

Listen Vehicle Data to Traffic Pool

Load Edge List from CPU Memory to GPU Memory

Lock-Read Vehicle Data

Load Vehicle Data from CPU Memory to GPU Memory Lock-write Vehicle Data

Perform Congestion Recognition

Load Congestion Data from GPU Memory to CPU Memory

Unlock-Read Vehicle Data Update Vehicle Data

Unlock-write Vehicle Data

Listen to Recognition Option Change request

Lock-Write Recognition Option Change Recognition Option Unlock-Write Recognition Option Lock-Read Recognition Option

Load Recognition Option From CPU Memory to GPU

Memory

Unlock-Read Recognition Option

(5)

IV-5

4.3.2 Proses Pendeteksian Kemacetan dengan Stream Computing pada CUDA

CUDA yang digunakan adalah mesin komputasi paralel. Oleh karena itu, algoritmanya pun harus dimodifikasi agar sesuai dengan arsitektur CUDA. Algoritma paralel tersebut akan dijelaskan berikut.

4.3.2.1 Pendeteksian dengan Algoritma Paralel

Pendeteksian paralel dengan CUDA akan dilakukan dengan cara menghitung rata-rata kecepatan di setiap edge pada setiap stream processor. Pseudocode untuk

kernel yang akan dijalankan dijelaskan pada Algoritma IV-1.

for all k in parallel do

dx := 0 dy := 0

if (k mod 2 = 0) then

// compute x

for i = 1 to vehicles[k / 2].numVehicle dx += vehicles[k / 2][i].x

congestionList[k / 2].dx := vehicles[k / 2].numVehicle

else

// compute y

for i = 1 to vehicles[k / 2].numVehicle dy += vehicles[k / 2][i].y

congestionList[k / 2].dy := vehicles[k / 2].numVehicle syncThreads()

// cari kategori kecepatan if (k < numEdge / 2)

ketemu := false;

congestionCategoryId := 0;

while (not ketemu and numCongestionCategory)

if (resultant >= congestionCategory[congestionCategoryId] resultant < congestionCategory[congestionCategoryId]) ketemu := true else congestionCategoryId += 1 if (ketemu) congestionList[k] = congestionCategoryId else congestionList[k] = "default"

(6)

IV-6

Dalam Algoritma IV-1, setiap stream processor melakukan loop dengan jumlah iterasi yang berbeda, tergantung pada jumlah vehicle yang ada pada edge tersebut. Permasalahan akan timbul pada efisiensi stream processor. Karena sebuah thread di-schedule berdasarkan sistem warp, dimana thread dalam warp yang sama akan menunggu thread lain apabila belum selesai, algoritma ini berpotensi menimbulkan idle-thread. Hal ini mengurangi performa algoritma. Oleh karena itu, sebelum dilakukan pendeteksian, data vehicle harus di-sort terlebih dahulu sesuai dengan perbedaan jumlah vehicle per edge.

Mengenai permasalahan bank-conflict pada CUDA, algoritma ini tidak mendapatkannya, karena setiap thread beroperasi pada memory bank yang berbeda.

4.3.1 Perancangan Protokol CA

Protokol yang digunakan pada modul Congestion Analyzer, yakni untuk menerima data vehicle dari TP, mengirim data congestion ke TP, dan mendengarkan request perubahan parameter pengenalan kemacetan menggunakan protokol UDP biasa.

4.3.2 Perancangan Input CA

Input yang dibutuhkan Congestion Analyzer adalah vektor yang dijelaskan pada Tabel IV-1.

4.3.3 Perancangan Output CA

Output yang dikeluarkan Congestion Analyzer adalah informasi kemacetan yang berbentuk paket data pada Tabel IV-5.

Tabel IV-5: Paket data output modul Congestion Analyzer

1. RecognitionTime 4 byte Waktu saat Congestion Analyzer mendeteksi kemacetan ini. 2. NumEdge 4 byte Jumlah edge yang ada dalam list

of edge.

3. EdgeStatus NumPoints x 4 byte Detail dari setiap titik yang membentuk geometri kemacetan. 4. AverageSpeed NumEdge x 4 byte Kecepatan rata-rata dari setiap

(7)

IV-7

telepon seluler yang terkena kemacetan.

5. List of Edge NumEdge x 4 byte Edge yang terkena kemacetan.

Paket data di atas akan dikirimkan ke modul Congestion List dengan protokol UDP.

4.4 Perancangan Modul Congestion List (CL)

4.4.1 Perancangan Input CL

Input dari modul CL adalah data kemacetan seperti yang dijelaskan pada bagian 4.3.3

4.4.2 Perancangan Server

CL dirancang sebagai sebuah server yang akan memiliki dua thread, yakni:

1. Thread yang bertugas untuk menerima dan menganalisis data kemacetan yang dihasilkan oleh CA.

2. Thread yang bertugas untuk mengirimkan notifikasi kemacetan yang muncul dan hilang serta update data kemacetan pada modul Visual Representation.

4.4.3 Perancangan Output CL

CL memiliki output yang terdiri dari 2 jenis, yakni: 1. Notifikasi kemunculan / update kemacetan. 2. Notifikasi kehilangan kemacetan.

Semua notifikasi tersebut akan dikirimkan melalui protokol UDP kepada setiap subsistem Presentation yang terdaftar. Untuk notifikasi tipe (1), paket data yang akan dikirim dapat dilihat pada Tabel IV-6.

Tabel IV-6: Notifikasi kemunculan / update kemacetan, output modul Congestion List

(8)

IV-8

2. NotificationType 1 byte 1 = Update, 2 = Delete

3. RequestTime 4 byte Waktu saat Congestion Analyzer menerima request.

4. NumPoints 4 byte Jumlah point yang ada dalam list

of point.

5. Points NumPoints x 8 byte Detail dari setiap titik yang membentuk geometri kemacetan.

6. AverageSpeed 4 byte Kecepatan rata-rata dari setiap telepon seluler yang terkena kemacetan.

Sedangkan untuk notifikasi tipe (2), paket data yang akan dikirimkan dapat dilihat pada Tabel IV-7.

Tabel IV-7: Notifikasi delete kemacetan, output modul Congestion List

1. CongestionID 4 byte ID kemacetan.

2. NotificationType 1 byte 1 = Update, 2 = Delete

4.5 Perancangan Modul Visual Representation (VR)

Sub-bab ini akan menjelaskan perancangan modul Visual Representation. 4.5.1 Perancangan User Interface VR

(9)

IV-9

Visual Representation Visual Representation

Insert IP Address of Traffic Pool: 167.205.35.110 OK Welcome to AntiJam!

Gambar IV-2: Tampilan Pembuka AntiJam Visual Representation

Visual Representation Minimap

Posisi Viewport di Minimap 100 m 3 0 m

(10)

IV-10 Exact Range Exact Range Latitude: Longitude: 06:10:88 W 103:40:55 N OK Cancel

Gambar IV-4: Dialog untuk memposisikan viewport dengan tepat Exact Zooming Exact Zooming Width: 2 Height: 0.5 km km OK Cancel

Gambar IV-5: Dialog untuk mengatur ukuran viewport dengan tepat Analyzer Settings

Analyzer Settings

Adjacent cellphone

location threshold: 5.40 meters Analyzer method: N-Body

Specific analyzer settings

OK Cancel

Adjacent cellphone

direction threshold: 5 degrees Minimum

congestion length threshold:

0.5 kms

(11)

IV-11 Congestion List Congestion List 4 3 2 1 Congestion ID Manual Automatic Automatic Automatic Congestion Type 320 m 54 m 2102 m 5434 m Length 07:21:23 06:20:34 06:05:20 06:00:04 Timestamp

Add Manual... Detail Close

Gambar IV-7: Dialog untuk melihat kemacetan yang berhasil dideteksi Add Congestion

Add Congestion

Edge Speed Time Duration

A B C D 4.5 3.5 2.1 3.9 20:41 13:50 06:40 20:43 7:54 2:53 4:45 2:30 OK Cancel

Gambar IV-8: Dialog untuk menambah data kemacetan secara manual

4.5.2 Keterhubungan Rancangan UI dengan Use Case

Keterhubungan antara diagram use case dengan rancangan user interface dapat dilihat pada Tabel IV-8.

Tabel IV-8: Keterhubungan rancangan UI dengan use case pada VR

No. User Interface Use Case yang Diimplementasikan

1. _{Gambar IV-2} UC-VR-07

2. Gambar IV-3 UC-VR-05

(12)

IV-12 4.5.3 Perancangan Input VR

Modul VR akan memiliki input sebagai berikut:

1. Data kendaraan yang dikirimkan oleh modul Traffic Pool. 2. Data kemacetan yang dikirimkan oleh modul Congestion List. 4.5.4 Perancangan Proses VR

Modul VR akan memiliki thread terpisah untuk menerima data kendaraan, data kemacetan, dan mengirim request ke berbagai modul. Thread utama adalah thread GUI.

4.5.5 Perancangan Output VR

Output modul VR dapat dilihat pada Tabel IV-9.

Tabel IV-9: Output pada VR

No. Output Penerima Bentuk

1. Tampilan pergerakan telepon seluler pada layar

System Administrator Gambar

2. Tampilan peta jalan raya. System Administrator Gambar 3. Tampilan kemacetan yang

sedang terjadi.

System Administrator Gambar

4. Request untuk mengontrol berbagai modul