Anda di halaman 1dari 83

SISTEM LAYANAN OPTIMALISASI

PENGATURAN ALAT PEMBERI ISYARAT LALU LINTAS OTOMATIS DAN


PENANGANAN ADUAN LALU LINTAS

Laporan
Disusun Dalam Rangka Memenuhi Tugas Mata Kuliah
Manajemen Layanan
(EL5122)

Oleh:
Kelompok 5
1. Hanavi (23219008)
2. Asmawi Tri Prabowo (23219053)
3. Rizky Andrian (23219031)

Program Studi Magister Teknik Elektro


Sekolah Teknik Elektro dan Informatika
Institut Teknologi Bandung
2019
DAFTAR ISI
DAFTAR ISI.............................................................................................................................. i
DAFTAR TABEL ..................................................................................................................... i
DAFTAR GAMBAR ................................................................................................................. i
BAB I PENDAHULUAN ......................................................................................................... 1
1.1 Latar Belakang ............................................................................................................ 1
1.2 Tujuan Penelitian......................................................................................................... 1
1.3 Ruang Lingkup Penelitian ........................................................................................... 2
1.4 Rancangan Arsitektur .................................................................................................. 3
1.5 Skenario....................................................................................................................... 4
BAB II TINJAUAN PUSTAKA ............................................................................................. 6
2.1 Lalu Lintas................................................................................................................... 6
2.2 Kemacetan ................................................................................................................... 7
2.3 Sensor Infrared (IR) Obstacle ..................................................................................... 8
2.4 Sensor Ultrasonic ...................................................................................................... 10
2.5 Service Oriented Architecture ................................................................................... 14
2.6 Service System .......................................................................................................... 15
2.7 Service System Engineering Framework .................................................................. 16
2.8 Business Process Model and Notation (BPMN) ....................................................... 19
2.9 SOAML ..................................................................................................................... 24
BAB III METODOLOGI ...................................................................................................... 26
3.1 Identifikasi................................................................................................................. 26
3.2 Perancangan .............................................................................................................. 27
3.3 Pengembangan .......................................................................................................... 27
3.4 Deployment ............................................................................................................... 28
BAB IV IDENTIFIKASI ....................................................................................................... 29
4.1 Analisis Kebutuhan ................................................................................................... 29
4.2 Analisis dan Transformasi Model Bisnis .................................................................. 31
4.3 Inovasi Layanan ........................................................................................................ 33
BAB V PERANCANGAN ..................................................................................................... 36
5.1 Pemodelan Layanan .................................................................................................. 36
5.2 Pemodelan Layanan Bisnis ....................................................................................... 40
5.3 Pemodelan Layanan IT.............................................................................................. 52
5.4 Service System Architecture ..................................................................................... 58
BAB VI PENGEMBANGAN ................................................................................................ 59
6.1 Service Prototyping ................................................................................................... 59
6.2 Service Testing .......................................................................................................... 70
i
BAB VI PENUTUP ................................................................................................................ 75
7.1 Kesimpulan................................................................................................................ 75
7.2 Saran .......................................................................................................................... 75
DAFTAR PUSTAKA ............................................................................................................. 76

ii
DAFTAR TABEL
Tabel 1. Komponen Sensor Obstacle ......................................................................................... 8
Tabel 2. Tahapan Service System Engineering (Suhardi dkk., 2017). ..................................... 17
Tabel 3. Identification Stage .................................................................................................... 26
Tabel 4. Design Stage .............................................................................................................. 27
Tabel 5. Development Stage .................................................................................................... 27
Tabel 6. Analisis Permasalahan Kemacetan ............................................................................ 30
Tabel 7. Analisis Fungsional Kemacetan................................................................................. 31
Tabel 8. Goal Service Modelling Sistem Layanan Optimalisasi Pengaturan APILL .............. 34
Tabel 9. Daftar kebutuhan pengguna sistem layanan .............................................................. 39
Tabel 10. Daftar kebutuhan fungsional sistem layanan ........................................................... 40
Tabel 11. Dekomposisi Layanan Pengaturan APILL .............................................................. 44
Tabel 12. Dekomposisi Layanan Monitoring Lalu Lintas ....................................................... 45
Tabel 13. Dekomposisi Layanan Pengaduan Masyarakat ....................................................... 45
Tabel 14. Dekomposisi Layanan Penyebaran Data ................................................................. 46
Tabel 15. Identifikasi Operasi Bisnis Layanan Pengaturan APILL ......................................... 47
Tabel 16. Identifikasi Operasi Bisnis Layanan Monitoring Lalu Lintas ................................. 48
Tabel 17. Identifikasi Operasi Bisnis Layanan Pengaduan Masyarakat .................................. 49
Tabel 18. Identifikasi Proses Bisnis Layanan Penyebaran Data .............................................. 50
Tabel 19. Operasi Sistem Layanan Optimalisasi Pengaturan APILL Otomatis dan
Penanganan Aduan Lalu Lintas ............................................................................................... 51
Tabel 20. Kandidat Layanan Sistem Layanan Optimalisasi Pengaturan APILL Otomatis dan
Penanganan Aduan Lalu Lintas ............................................................................................... 52
Tabel 21. Hasil Pengujian Perangkat Prototype Traffic Light ................................................. 71

i
DAFTAR GAMBAR
Gambar 1. Arsitektur Service Computing System ...................................................................... 3
Gambar 2. Layer Arsitektur Sistem ........................................................................................... 4
Gambar 3. Rangkaian Sensor Obstacle ...................................................................................... 8
Gambar 4. Pemasangan Sensor ke Sirkuit Arduino ................................................................... 9
Gambar 5. Potongan Kode Arduino........................................................................................... 9
Gambar 6. Visualisasi Jarak Aktual Pantulan Gelombang Sensor Ultrasonic......................... 10
Gambar 7. Sensor Ultrasonic HC-SR04 .................................................................................. 12
Gambar 8. Pemasangan Sensor Ultrasonic Pada Sirkuit Arduino ........................................... 13
Gambar 9. Feedback Control-based Services System (Zhang dkk., 2007). ............................. 16
Gambar 10. Events sebagai elemen BPMN ............................................................................. 20
Gambar 11. Activities sebagai elemen dari BPMN ................................................................. 21
Gambar 12. Gateways sebagai elemen dari BPMN ................................................................. 22
Gambar 13. Sequence flow....................................................................................................... 22
Gambar 14. Message flow ........................................................................................................ 22
Gambar 15. Association flow ................................................................................................... 23
Gambar 16. Lane dan pool pada swimlane .............................................................................. 23
Gambar 17. Data, group dan annotation sebagai elemen BPMN ............................................ 24
Gambar 18. Service System Engineering Life Cycle Model ................................................... 26
Gambar 19. Arah Pergerakan Kendaraan Lalu Lintas ............................................................. 29
Gambar 20. Business Model Canvas As-Is.............................................................................. 32
Gambar 21. Business Model Canvas to-be .............................................................................. 33
Gambar 22. Model Sistem Layanan (Zhang dkk., 2007) ......................................................... 37
Gambar 23. Rancangan Sistem Layanan Optimalisasi Pengaturan APILL Otomatis Dan
Penanganan Aduan Lalu Lintas ............................................................................................... 38
Gambar 24. Service Blueprint Layanan Pengaturan APILL .................................................... 40
Gambar 25. Service Blueprint Layanan Monitoring Lalu Lintas ............................................ 41
Gambar 26. Service Blueprint Layanan Pengaduan Masyarakat ............................................. 41
Gambar 27. Service Blueprint Layanan Penyebaran Data ....................................................... 42
Gambar 28. BPMN Pengaturan APILL ................................................................................... 42
Gambar 29. BPMN Layanan Monitoring Lalu Lintas ............................................................. 43
Gambar 30. BPMN Layanan Pengaduan Masyarakat ............................................................. 43
Gambar 31. BPMN Layanan Penyebaran Data ....................................................................... 44

i
Gambar 32. SSO Service Interface Diagram ........................................................................... 53
Gambar 33. Pengaduan Service Interface Diagram ................................................................ 53
Gambar 34. Penyebaran Data Service Interface Diagram ....................................................... 53
Gambar 35. Notifikasi Service Interface Diagram .................................................................. 54
Gambar 36. IoT Service Interface Diagram ............................................................................ 54
Gambar 37. Pengaduan Sequence Diagram............................................................................. 54
Gambar 38. Penyebaran Data Sequence Diagram ................................................................... 55
Gambar 39. IoT Sequence Diagram ........................................................................................ 55
Gambar 40. Service Participant Diagram Sistem Layanan..................................................... 56
Gambar 41. Service Contract SSO .......................................................................................... 56
Gambar 42. Service Contract Notifikasi.................................................................................. 57
Gambar 43. Service Contract Pengaduan ................................................................................ 57
Gambar 44. Service Contract Penyebaran Data ...................................................................... 57
Gambar 45. Service Contract IoT ............................................................................................ 57
Gambar 46. Service Architecture Sistem Layanan Optimalisasi Pengaturan APILL Otomatis
Dan Penanganan Aduan Lalu Lintas........................................................................................ 58
Gambar 47. Rancangan Desain PCB Traffic Light dengan PCB Express ............................... 59
Gambar 48. Rancangann Driver Traffic Light ......................................................................... 59
Gambar 49. Hasil Rakitan Alat Simulasi (dari atas) ................................................................ 60
Gambar 50. Hasil Rakitan Alat Simulasi (dari samping) ........................................................ 60
Gambar 51. Potong Script Pada nodeMCU (1) ....................................................................... 61
Gambar 52. Potongan Script Pada nodeMCU (2) .................................................................... 61
Gambar 53. Potongan Script Pada nodeMCU (3) .................................................................... 62
Gambar 54. Potongan Script untuk Konfigurasi Sensor Obstacle dan Ultrasonic (1) ............. 62
Gambar 55. Potongan Script untuk Konfigurasi Sensor Obstacle dan Ultrasonic (2) ............. 63
Gambar 56. Tampilan Dashboard Aplikasi Desktop ............................................................... 63
Gambar 57. Panel Aduan Masyarakat Berisikan Identitas Aduan ........................................... 64
Gambar 58. Panel Jumlah Kendaraan Pada Setiap Persimpangan .......................................... 64
Gambar 59. Panel History Pengaduan Masyarakat.................................................................. 64
Gambar 60. Potongan Script Untuk Pembuatan Desktop Application .................................... 64
Gambar 61. Script Koneksi API Server ................................................................................... 65
Gambar 62. Script Dashboard .................................................................................................. 65
Gambar 63. Dashboard Aduan E-Complaint ........................................................................... 66
Gambar 64. Contoh Kasus Pemilihan Simpang Yang Macet .................................................. 66

ii
Gambar 65. Contoh Kasus Pemilihan Jenis Aduan ................................................................. 67
Gambar 66. Contoh Kasus Deteksi Lokasi Pemberi Aduan .................................................... 67
Gambar 67. Contoh Notifikasi Dalam Bentuk SMS ................................................................ 68
Gambar 68. User Interface Register dan Gathering Traffic Data Traffic Information API .... 68
Gambar 69. User Interface all_aduan dan aduan_by_date Traffic Information API.............. 69
Gambar 70. User Interface Jumlah Kendaraan Traffic Information API ................................ 69
Gambar 71. Potongan Script Layanan Penyebaran Data ......................................................... 70
Gambar 72. Tampilan LED Prototype Traffic Light ............................................................... 71
Gambar 73. Tampilan Dashboard Terisi Dengan Data dan Status Persimpangan Aktif ......... 72
Gambar 74. Uji Coba Pengaduan Persimpangan Yang Bermasalah ....................................... 72
Gambar 75. Tampilan Notifikasi SMS dari SMS Gateway Tentang Detil Aduan .................. 73
Gambar 76. Uji Coba API Dengan Menggunakan Aplikasi Postman ..................................... 73
Gambar 77. Uji Coba API Dengan Menggunakan Browser .................................................... 74
Gambar 78. Uji Coba Keamanan API...................................................................................... 74

iii
BAB I PENDAHULUAN

1.1 Latar Belakang


Kemacetan lalu lintas dapat dikatakan sebagai sebuah pertanda berkembangnya sebuah
kota metropolitan. Salah satu penyebab kemacetan yang terjadi adalah kapasitas jalan yang
tetap namun jumlah pemakai jalan terus meningkat sehingga menyebabkan waktu tempuh
perjalanan menjadi lebih lama. Lampu Alat Pemberi Isyarat Lalu Lintas (APILL) yang
digunakan sebagai instrumen pengaturan lalu lintas masih menggunakan timer yang tetap,
sehingga tidak dapat menyesuaikan dengan keadaan jalan yang kosong atau padat. Apabila
terjadi kemacetan, maka proses penguraian kemacetan bergantung kepada presensi dari pihak
bewajib yang betugas di lapangan. Dikarenakan peristiwa kemacetan merupakan kejadian yang
bisa terjadi kapan saja, maka hal ini akan menyusahkan apabila pada saat yang bersamaan tidak
ada pihak berwajib yang sedang betugas dilokasi kejadian kemacetan. Kemacetan akan terurai
apabila masyarakat ada yang melaporkan peristiwa kemacetan melalui media sosial, atau ada
masyarakat yang mengambil alih peran sebagai pengurai kemacetan.
Pada penelitian ini, akan dilakukan perancangan sistem layanan optimalisasi pengaturan
APILL otomatis dan penanganan aduan lalu lintas dengan menggunakan alat bantu yakni
Obstacle sensor dan Ultrasonic sensor. Sistem layanan yang dibangun akan menggunakan
sensor untuk mendeteksi keberadaan, jumlah, dan pergerakan kendaraan yang melalui
persimpangan lalu lintas. Selain itu, sistem layanan yang dibangun dapat melayani aduan
masyarakat tentang peristiwa yang berkaitan dengan lalu lintas, seperti kemacetan atau
kecelakaan. Laporan tersebut akan secara otomatis disampaikan kepada stakeholder terkait
untuk menindaklanjuti aduan yang diterima. Server aplikasi berbasis web service akan
menerima data kendaraan lalu lintas dari sensor yang dikirimkan melalui mikroprosessor. Data
tersebut dapat diolah menjadi informasi yang akan dikim kepada para stakeholder yang terlibat
melalui sistem notifikasi dan juga public API.

1.2 Tujuan Penelitian


Berdasarkan uraian latar belakang yang sudah dijelaskan sebelumnya, tujuan penelitian
dalam penelitian ini adalah:
• Menghasilkan rancangan sistem layanan optimalisasi pengaturan APILL otomatis dan
penanganan aduan lalu lintas berbasis IoT menggunakan framework Service System
Engineering (SSE).

1
• Mendapatkan hasil uji rancangan sistem layanan optimalisasi pengaturan APILL
otomatis dan penanganan aduan lalu lintas melalui pendekatan prototipe dan simulasi.

1.3 Ruang Lingkup Penelitian


Penelitian yang dilakukan memiliki batasan masalah sebagai berikut:
1. Penelitian dilakukan pada lingkungan terbatas dengan pengujian melalui alat simulasi, web
application dan android application.
2. Metodologi penelitian dibatasi hanya sampai tahap development (pengembangan).
3. Penelitian tidak membahas keamanan sistem dan transaksi data pada alat simulasi dan
software yang digunakan.

2
1.4 Rancangan Arsitektur

Gambar 1. Arsitektur Service Computing System

3
Gambar 2. Layer Arsitektur Sistem

Penjelasan rancangan:
o End user: masyarakat umum
o Application Services: Web Service
o Application Layer: Aplikasi Web dan Android
o Platform Layer: MySQL (sebagai DBMS), C (untuk Arduino), PHP (sebagai bahasa
pemrograman pembuatan aplikasi website), dan SMS gateway (untuk push SMS)
o Mikrokontroler: Atmega 328
o Sensor Layer:
▪ Sensor Obstacle: untuk mendeteksi ada tidaknya kendaraan
▪ Sensor Ultrasonic: untuk mendeteksi pergerakan dan jumlah kendaraan

1.5 Skenario
Pendeteksian Pergerakan dan Penghitungan Jumlah Kendaraan:
• Sensor dan Mikrokontroler diletakkan pada pinggiran persimpangan lalu lintas.

4
• APILL diberikan inisial timer selama 30 detik untuk setiap warna lampu
• Kasus 1:
o Di persimpangan dengan lampu APILL berwarna hijau, tidak ada kendaraan
yang melintas
o Apabila dalam waktu 5 detik sensor tidak menemukan gerakan kendaraan, maka
lampu hijau hanya akan menyala selama 5 detik saja
• Kasus 2:
o Di persimpangan dengan lampu APILL berwarna hijau, jumlah kendaraan pada
persimpangan tersebut padat
o Apabila dalam waktu 25 detik sensor mendeteksi ada gerakan kendaraan, maka
pada detik ke-26 warna lampu APILL berganti menjadi kuning, dan selanjutnya
pada detik ke-30 warna lampu APILL berganti menjadi merah.
• Kasus 3:
o Di persimpangan dengan lampu APILL berwarna hijau, selama 18 detik
kendaraan melintas normal, namun pada detik ke-19 sudah tidak ada kendaraan
yang melintas
o Apabila sensor tidak menemukan pergerakan kendaraan setelah 18 detik, maka
pada detik ke-19 warna lampu APILL berganti menjadi merah.
Pengaduan Masyarakat:
• Masyarakat menemukan kejadian kemacetan atau kecelakaan di salah satu
persimpangan
• Masyarakat melaporkan menggunakan aplikasi android dengan mengisikan identitas
aduan yang berisikan nama pengirim, lokasi persimpangan, lokasi pengirim aduan,
dan jenis aduan.
• Aduan dikirim menggunakan aplikasi android dan diterima oleh database server
untuk diteruskan kepada desktop application, sehingga muncul notifikasi berupa
aduan masyarakat dan suara/sirine sesuai dengan detil aduan yang dilaporkan.
• Dinas Perhubungan atau Kepolisian melakukan aksi cepat tanggap terhadap
informasi yang diberikan
Akses API :
• Masyarakat melakukan pendaftaran di traffic information web application untuk
dapat mengakses API yang disediakan
• Server melakukan approval akses penggunaan API
• Masyarakat dapat menggunakan API yang tersedia

5
BAB II TINJAUAN PUSTAKA

2.1 Lalu Lintas


Seperti yang tertuang dalam Undang-undang No.22 Tahun 2009, Definisi Lalu lintas yaitu
gerak Kendaraan dan orang di Ruang Lalu Lintas Jalan. Adapun yang dimaksud dengan Ruang
Lalu Lintas Jalan yaitu prasarana yang diperuntukkan bagi gerak pindah kendaraan, orang,
dan/atau barang yang berupa jalan dan fasilitas pendukung.
Mewujudkan lalu lintas dan angkutan jalan yang selamat, aman, cepat, lancar, tertib dan
teratur, nyaman dan efisien melalui manajemen lalu lintas dan rekayasa lalu lintas merupakan
tujuan utama dari pemerintah Indonesia.
Peraturan perundangan yang menyangkut arah lalu lintas, prioritas menggunakan jalan,
lajur lalu lintas, jalur lalu lintas serta pengendalian arus di persimpangan itu semua termasuk
Tata Cara Berlalu Lintas.
Arus lalu lintas adalah jumlah kendaraan yang melewati suatu titik, pendekat satuan waktu
dinyatakan dalam kend/jam. Perhitungan arus lalu lintas dilakukan persatuan jam untuk satu
atau lebih priode, misalnya didasarkan pada kondisi arus puncak yaitu puncak pagi, siang, dan
sore hari.
Persimpangan merupakan suatu tempat dimana terdapat dua atau lebih jalan bertemu atau
berpotongan. Setiap jalan yang memencar dari titik perpotongan atau pertemuan merupakan
bagian dari persimpangan tersebut, disebut juga lengan persimpangan. Pada persimpangan
sering timbul konflik yang berulang seperti tundaan dan antrian. Karakteristik dari transportasi
jalan adalah bahwa setiap pengemudi bebas untuk memilih rutenya sendiri dalam jaringan
transportasi yang ada (terkeculi untuk angkutan umum yang telah memiliki rute atau trayek),
karena itu perlu disediakan persimpangan-persimpangan untuk menjamin keamanan dan
efesiennya arus lalu lintas yang hendak pindah dari satu ruas jalan ke ruas jalan lainnya.
(Irlinawati, 2008).
Ada tiga komponen yang berperan signifikan di jalan raya saat praktek berlalu lintas, yaitu;
manusia, kendaraan dan jalan. Ketiga komponen ini saling berinteraksi dalam pergerakan
kendaraan. Dalam pergerakannya, ketiga komponen di atas harus memenuhi syarat kelaikan
berkendaraan dengan mentaati peraturan berlalu lintas yang sudah ditetapkan dalam
perundang-undangan lalu lintas yang menyangkut angkutan jalan dan jalan yang memenuhi
syarat geometrik.
Manusia sebagai pengguna jalan sangat berperan di ruang lalu lintas sebagai pengemudi
atau pejalan kaki. Sedangkan kendaraan adalah alat transportasi yang digunakan manusia
dengan karakteristik yang berbeda-beda satu sama lainnya; kecepatan, perlambatan,
6
percepatan, dimensi dan muatannya dengan ruang lalu lintas yang cukup untuk bermanuver.
Dan jalan adalah ruang lintasan yang digunakan untuk dilalui oleh kendaraan dan
pengendaranya serta pejalan kaki yang diharapkan bisa dialirkan dengan lancar agar tidak
terjadi kemacetan dan kecelakaan.

2.2 Kemacetan
Kemacetan adalah kondisi dimana arus lalu lintas yang lewat pada ruas jalan yang ditinjau
melebihi kapasitas rencana jalan tersebut yang mengakibatkan kecepatan bebas ruas jalan
tersebut mendekati atau melebihi 0 km/jam sehingga menyebabkan terjadinya antrian. Pada
saat terjadinya kemacetan, nilai derajat kejenuhan pada ruas jalan akan ditinjau dimana
kemacetan akan terjadi bila nilai derajat kejenuhan mencapai lebih dari 0,5 (MKJI, 1997).
Jika arus lalu lintas mendekati kapasitas, kemacetan mulai terjadi. Kemacetan semakin
meningkat apabila arus begitu besarnya sehingga kendaraan sangat berdekatan satu sama lain.
Kemacetan total terjadi apabila kendaraan harus berhenti atau bergerak sangat lambat ( Ofyar
Z Tamin, 2000 ).
Menurut penelitian Administration (2005), terdapat 7 penyebab kemacetan, yaitu:
1. Physical Bottlenecks: Kemacetan yang disebabkan oleh jumlah kendaraan yang melebihi
batas atau berada pada tingkat tertinggi. Kapasitas tersebut ditentukan dari faktor jalan,
persimpangan jalan, dan tata letak jalan.
2. Kecelakaan Lalu Lintas (traffic incident): Kemacetan yang disebabkan oleh adanya
kejadian atau kecelakaan dalam jalur perjalanan. Kecelakaan akan menyebabkan macet,
karena kendaraan yang terlibat kecelakaan tersebut memakan ruas jalan. Hal tersebut
mungkin akan berlangsung lama, karena kendaraan yang terlibat kecelakaan tersebut
perlu waktu untuk disingkirkan dari jalur lalu lintas.
3. Area Pekerjaan (work zone): Kemacetan yang disebabkan oleh adanya aktivitas
kontruksi pada jalan. Aktivitas tersebut akan mengakibatkan perubahaan keadaan
lingkungan jalan. Perubahan tersebut seperti penurunan pada jumlah atau lebar jalan,
pengalihan jalur, dan penutupan jalan.
4. Cuaca yang Buruk (bad weather): Keadaan cuaca dapat meyebabkan perubahan perilaku
pengemudi, sehingga dapat mempengaruhi arus lalu lintas. Contohnya: hujan deras,
akan mengurangi jarak penglihatan pengemudi, sehingga banyak pengemudi
menurunkan kecepatan mereka.
5. Alat Pengatur Lalu Lintas (poor signal timing): Kemacetan yang disebabkan oleh
pengaturan lalu lintas yang bersifat kaku dan tidak mengikuti tinggi rendahnya arus lalu

7
lintas. Selain lampu merah, jalur kereta api juga mempengaruhi tingkat kepadatan jalan,
sehingga jalur kereta api yang memotong jalan harus seoptimal mungkin.
6. Acara Khusus (special event): Merupakan kasus khusus dimana terjadi peningkatan arus
yang disebabkan oleh adanya acara-acara tertentu. Misalnya, akan terdapat banyak
parkir liar yang memakan ruas jalan pada suatu acara tertentu.
7. Fluktuasi pada Arus Normal (fluctuations in normal traffic): Kemacetan yang
disebabkan oleh naiknya arus kendaraan pada jalan dan waktu tertentu. Contohnya,
kepadatan jalan akan meningkat pada jam masuk kantor dan pulang kantor.

2.3 Sensor Infrared (IR) Obstacle


Sensor IR Obstacle merupakan sebuah sensor yang berfungsi sebagai pendeteksi halangan
atau object di depannya menggunakan cahaya inframerah yang dipantulkan. Sensor ini
mempunyai dua bagian utama yaitu IR emitter dan IR receiver. Emitter bertugas memantulkan
inframerah ke rintangan atau objek kemudian akan dipantulkan dan diterima oleh receiver.
Ketika inframerah mengenai sebuah objek, kondisinya akan LOW dan begitu juga sebaliknya.

Gambar 3. Rangkaian Sensor Obstacle

Tabel 1. Komponen Sensor Obstacle

Pin, Control Indicator Deskripsi


Vcc 3.3 to 5 Vdc Supply Input
Gnd Ground Input
Out Output that goes low when obstacle is in range
Power LED Menyala ketika ada power listrik
Obstacle LED Menyala apabila ada objek terdeteksi
Pengatur Jarak Pendeteksian. Diputar searah jarum jam untuk
Distance Adjust
menambah jarak. Dan sebaliknya untuk mengurangi jarak.
IR Emitter Infrared emitter LED
Infrared receiver yang menerima sinyal yang ditransmisikan oleh
IR Receiver
Infrared emitter.

8
Gambar 4. Pemasangan Sensor ke Sirkuit Arduino

Gambar 5. Potongan Kode Arduino

9
2.4 Sensor Ultrasonic
Sensor ultrasonik adalah sebuah sensor yang berfungsi untuk mengubah besaran fisis
(bunyi) menjadi besaran listrik dan sebaliknya. Cara kerja sensor ini didasarkan pada prinsip
dari pantulan suatu gelombang suara sehingga dapat dipakai untuk menafsirkan eksistensi
(jarak) suatu benda dengan frekuensi tertentu. Disebut sebagai sensor ultrasonik karena sensor
ini menggunakan gelombang ultrasonik (bunyi ultrasonik).
Gelombang ultrasonik adalah gelombang bunyi yang mempunyai frekuensi sangat tinggi
yaitu 20.000 Hz. Bunyi ultrasonik tidak dapat di dengar oleh telinga manusia. Bunyi ultrasonik
dapat didengar oleh anjing, kucing, kelelawar, dan lumba-lumba. Bunyi ultrasonik nisa
merambat melalui zat padat, cair dan gas. Reflektivitas bunyi ultrasonik di permukaan zat padat
hampir sama dengan reflektivitas bunyi ultrasonik di permukaan zat cair. Akan tetapi,
gelombang bunyi ultrasonik akan diserap oleh tekstil dan busa.

Cara Kerja Sensor Ultrasonic


Pada sensor ultrasonik, gelombang ultrasonik dibangkitkan melalui sebuah alat yang
disebut dengan piezoelektrik dengan frekuensi tertentu. Piezoelektrik ini akan menghasilkan
gelombang ultrasonik (umumnya berfrekuensi 40kHz) ketika sebuah osilator diterapkan pada
benda tersebut. Secara umum, alat ini akan menembakkan gelombang ultrasonik menuju suatu
area atau suatu target. Setelah gelombang menyentuh permukaan target, maka target akan
memantulkan kembali gelombang tersebut. Gelombang pantulan dari target akan ditangkap
oleh sensor, kemudian sensor menghitung selisih antara waktu pengiriman gelombang dan
waktu gelombang pantul diterima.

Gambar 6. Visualisasi Jarak Aktual Pantulan Gelombang Sensor Ultrasonic

10
Secara detail, cara kerja sensor ultrasonik adalah sebagai berikut:
1. Sinyal dipancarkan oleh pemancar ultrasonik dengan frekuensi tertentu dan dengan
durasi waktu tertentu. Sinyal tersebut berfrekuensi diatas 20kHz. Untuk mengukur jarak
benda (sensor jarak), frekuensi yang umum digunakan adalah 40kHz.
2. Sinyal yang dipancarkan akan merambat sebagai gelombang bunyi dengan kecepatan
sekitar 340 m/s. Ketika menumbuk suatu benda, maka sinyal tersebut akan dipantulkan
oleh benda tersebut.
3. Setelah gelombang pantulan sampai di alat penerima, maka sinyal tersebut akan
diproses untuk menghitung jarak benda tersebut. Jarak benda dihitung berdasarkan
rumus:
S = 340.t/2
dimana S merupakan jarak antara sensor ultrasonik dengan benda (bidang pantul), dan
t adalah selisih antara waktu pemancaran gelombang oleh transmitter dan waktu ketika
gelombang pantul diterima receiver.

Rangkaian Sensor Ultrasonic


1. Piezoelektrik
Piezoelektrik berfungsi untuk mengubah energi listrik menjadi energi mekanik. Bahan
piezoelektrik adalah material yang memproduksi medan listrik ketika dikenai
regangan atau tekanan mekanis. Sebaliknya, jika medan listrik diterapkan, maka
material tersebut akan mengalami regangan atau tekanan mekanis. Jika rangkaian
pengukur beroperasi pada mode pulsa elemen piezoelektrik yang sama, maka dapat
digunakan sebagai transmitter dan reiceiver. Frekuensi yang ditimbulkan tergantung
pada osilatornya yang disesuiakan frekuensi kerja dari masing-masing transduser.
Karena kelebihannya inilah maka tranduser piezoelektrik lebih sesuai digunakan untuk
sensor ultrasonik.
2. Transmitter
Transmitter adalah sebuah alat yang berfungsi sebagai pemancar gelombang ultrasonik
dengan frekuensi tertentu (misal, sebesar 40 kHz) yang dibangkitkan dari sebuah
osilator. Untuk menghasilkan frekuensi 40 KHz, harus di buat sebuah rangkaian
osilator dan keluaran dari osilator dilanjutkan menuju penguat sinyal. Besarnya
frekuensi ditentukan oleh komponen RLC / kristal tergantung dari disain osilator yang
digunakan. Penguat sinyal akan memberikan sebuah sinyal listrik yang diumpankan

11
ke piezoelektrik dan terjadi reaksi mekanik sehingga bergetar dan memancarkan
gelombang yang sesuai dengan besar frekuensi pada osilator

3. Receiver

Receiver terdiri dari transduser ultrasonik menggunakan bahan piezoelektrik, yang


berfungsi sebagai penerima gelombang pantulan yang berasal dari transmitter yang
dikenakan pada permukaan suatu benda atau gelombang langsung LOS (Line of Sight)
dari transmitter. Oleh karena bahan piezoelektrik memiliki reaksi yang reversible,
elemen keramik akan membangkitkan tegangan listrik pada saat gelombang datang
dengan frekuensi yang resonan dan akan menggetarkan bahan piezoelektrik tersebut.

Sensor Ultrasonik HC-SR04


Sensor ini merupakan sensor ultrasonik siap pakai, satu alat yang berfungsi sebagai
pengirim, penerima, dan pengontrol gelombang ultrasonik. Alat ini bisa digunakan untuk
mengukur jarak benda dari 2cm - 4m dengan akurasi 3mm. Alat ini memiliki 4 pin, pin Vcc,
Gnd, Trigger, dan Echo. Pin Vcc untuk listrik positif dan Gnd untuk ground-nya. Pin Trigger
untuk trigger keluarnya sinyal dari sensor dan pin Echo untuk menangkap sinyal pantul dari
benda.

Gambar 7. Sensor Ultrasonic HC-SR04

Spesifikasi Sensor Ultrasonik HC-SR04


• Tegangan sumber operasi 5.0 V
• Konsumsi arus 15 mA
• Frekuensi operasi 40 KHz
• Minimum jarak 0.02 m (2 cm)

12
• Maksimum jarak 4 m
• Sudut pantul gelombang pengukuran 15 derajat
• Minimum waktu penyulutan 10 mikrodetik dengan pulsa berlevel TTL
• Pulsa deteksi berlevel TTL dengan durasi yang bersesuaian dengan jarak deteksi
• Dimensi 45 x 20 x 15 mm

Pemasangan Sensor Ultrasonik ke Arduino


Pertama yang harus dilakukan adalah membuat rangkaian untuk menghubungkan arduino
dengan sensor dengan ultrasonik, dimana pin vcc pada sensor di hubungkan dengan sumber
tegangan 5 volt pada arduino, kemudian pin trigger pada sensor di hubungkan ke pin 4 pada
arduino, pin echo pada sensor di hubungkan ke pin 2 pada arduino, dan pin gnd pada sensor
dihubungkan pada pin gnd pada arduino, atau dapat anda lihat pada gambar dibawah ini

Gambar 8. Pemasangan Sensor Ultrasonic Pada Sirkuit Arduino

Setelah sensor ultrasonik dan arduino terhubug, berikutnya kita dapat menuliskan program
pada arduino IDE seperti di bawah ini.
#define triger 4 //mendefinisikan trigger pada pin 4
#define echo 2 //mendeklarasikan echo pada pin 2
void setup() {

Serial.begin(115200); //memulai serial


pinMode (triger, OUTPUT); //trigger sebagai output

13
pinMode (echo, INPUT); //echo sebagai input
}

void loop() {

digitalWrite (triger, HIGH); //mengirim suara


delayMicroseconds(10); //selama 10 mikro detik
digitalWrite (triger, LOW); //berhenti mengirim suara

float jarak = pulseIn(echo, HIGH); //membaca data dan di masukkan


ke variabel jarak
jarak=jarak/1000000; //konversi mikro detik ke detik
jarak=jarak*330/2; //data mentah di ubah ke dalam meter
jarak=jarak*100; //mengubah data ke dalam centi meter

Serial.println(jarak); //menampilkan nilai jarak pada serial

delay(500); //delay 500ms


}

2.5 Service Oriented Architecture


Terdapat beberapa pengertian dari Service Oriented Architecture (SOA), diantaranya yang
terkenal yaitu:
• Menurut Wu, dkk. 2015, “Arsitektur Berorientasi Layanan (SOA) adalah pendekatan
antara bisnis dan Teknologi Informasi yang selaras di mana aplikasi bergantung pada
layanan yang tersedia untuk memfasilitasi proses bisnis. Layanan adalah komponen
perangkat lunak reusable mandiri yang disediakan oleh penyedia layanan dan
dikonsumsi oleh peminta layanan. SOA menciptakan visi fleksibilitas TI yang
memungkinkan ketangkasan bisnis.”
• Menurut IBM SOA Software, “Arsitektur Berorientasi Layanan (SOA) adalah
pendekatan arsitektural TI sentris bisnis yang mendukung pengintegrasian bisnis Anda
sebagai sebuah keterkaitan, tugas bisnis yang berulang atau layanan. SOA membantu
pengguna membangun aplikasi gabungan, yang merupakan aplikasi yang
memanfaatkan fungsionalitas dari berbagai sumber di dalam dan di luar perusahaan
untuk mendukung proses bisnis horizontal.”
Adapun sifat dari SOA, yaitu:
1. Loosely coupled, yaitu setiap service berdiri sendiri secara independen dan tidak
tergantung service lain untuk berjalan. Ketergantungan diminimalisir sehingga
hanya butuh mekanisme komunikasi satu sama lain.
2. Service contract, yaitu setiap service memiliki kesepakatan mengenai cara untuk
komunikasi.
3. Autonomy, yaitu service memiliki hak penuh terhadap semua lojik yang
dienkapsulasi.

14
4. Abstraction, yaitu service tidak memperlihatkan bagaimana lojik diimplementasi
didalamnya.
5. Reusability, yaitu lojik dibagi menjadi sekumpulan service yang dapat
memudahkan reuse.
6. Statelessness, yaitu service tidak memiliki status tertentu terkait dengan aktivitas
yang dilakukannya.
7. Discoverability, yaitu service didesain untuk deskriptif sehingga bisa ditemukan
dan diakses melalui mekanisme pencarian tertentu.
8. Composability, yaitu service bisa disatukan dengan service lain. Ini memungkinkan
logic dapat diwakili pada level berbeda dari granularity dan mempromosikan
reusability dan pembuatan layer astraction.
SOA digunakan sebagai teknologi layanan yang menyediakan prinsip-prinsip dan konsep
pengelolaan untuk pengembangan dan integrasi sistem. SOA digunakan dalam tahap
menyandingkan sistem yang telah ada dengan identifikasi layanan yang dibutuhkan. Dua
metodologi SOA yang paling terkenal adalah IBM SOMA dan Thomas Erl MSOAM. SOMA
dari IBM sangat direkomendasikan dan dapat disebut sebagai service engineering framework,
karena telah mencangkupi siklus lengkap dari service engineering, dari sisi bisnis ke
implementasi teknis. Namun, SOMA sulit diadopsi karena keterbatasan ketersediaan detail
materi referensi untuk tahapan development dan operation. Sedangkan MSOAM kuat pada
tahapan awal, yaitu identification dan design, namun tidak memberikan petunjuk untuk
aktivitas setelah aktivitas design. Untuk mengatasi keterbatasan kedua metodologi di atas,
Suhardi dkk. (2017) mengusulkan sebuah framework untuk rekayasa sistem layanan.

2.6 Service System


Sistem layanan adalah layanan bisnis yang diwujudkan oleh sistem perangkat lunak
teknologi informasi. Terdapat enam unsur dalam sistem layanan yaitu inputs, outputs, goals,
transformation, components, dan sensor (Zhang dkk., 2007), dapat dilihat pada Gambar 2.1

15
Gambar 9. Feedback Control-based Services System (Zhang dkk., 2007).

1. Inputs
Input dapat berupa informasi yang diberikan oleh pengguna layanan sehingga sistem
layanan dapat menyediakan layanan yang dapat dipersonalisasi.
2. Outputs
Output dari sistem layanan dapat berupa layanan-layanan yang ditawarkan.
3. Goals
Adalah tujuan/sasaran dari sistem sebagai sekelompok kebutuhan sistem yang sudah
didefinisikan sebelumnya.
4. Transformation
Adalah kegiatan kontrol yang diterapkan pada sistem dan hubungannya dengan sistem
layanan yang terhubung dengannya.
5. Components
Adalah elemen utama sistem layanan yang terdiri atas service people, service partners,
service information, service activities, dan service infrastructure resources.
6. Sensor
Adalah elemen sistem yang memantau dan mendeteksi perubahan lingkungan sekitar
sehingga sistem layanan dapat bereaksi secara tepat untuk memberikan layanan yang
lebih baik.

2.7 Service System Engineering Framework


Framework Service System Engineering (Suhardi dkk., 2017) yang merupakan adopsi dari
Service Engineering Based on SOA Methodology (Suhardi dkk., 2015) dan System Engineering
Life Cyle (Kossiakoff dkk., 2011). Adapun tahapannya dapat dilihat pada Tabel 2.1.

16
Tabel 2. Tahapan Service System Engineering (Suhardi dkk., 2017).
Stage Phase Step Artefacts
Identification 1.1 Need Analysis 1.1.1. Operations Operational objectives
Analysis
1.1.2. Functional Business Functions
Analysis
1.1.3. Feasibility Feasible business
Definition functions concept
1.1.4. Needs Validation Operational
Requirements
1.2. Business Model 1.2.1. Operational As-Is Business Model
Analysis and Requirements Analysis
Transformation 1.2.2. Functional To-Be Business Model
Requirements
Formulation
1.2.3. Implementation
Model Exploration
1.2.4. Model Validate To-Be
Requirements Business Model
Validations
1.3. Service Innovation 1.3.1. Model Goal service modelling
requirement analysis
1.3.2. Innovation
analysis and
formulation
1.3.3. Innovation New business service
selection innovation. Business
service catalog (new
business service
innovation and
existing)
1.3.4. Innovation Business Simulation
validation Report
Validated business
service innovation
Design 2.1. Service Modelling 2.1.1. Requirement New service innovation
Analysis components
2.1.2. Functional Service Innovation
Analysis and Design Functional Design,
SCRM
2.1.3. Service Model Service Blueprint
Development and/or Process-Chain-
Network (PCN)
2.1.4. Service Model Validated service
Validation blueprint and/or
Process-Chain-
Network (PCN)
2.2. Process Modelling 2.2.1. Requirements As-Is BPM
Analysis
2.2.2. Functional New Service Processes
Analysis and Design
2.2.3. Service-Process To-Be BPM
Design New and Integrated
Data Design
Validated To-Be BPM
17
2.2.4. Service Process Validated Data Design
Validation
2.3. Architecture Design 2.3.1. Requirements List of business process
Analysis decomposition: atomic,
autonom
2.3.2. Service Analysis IT Service Catalogue
and Design
2.3.3. Service Service composition
Architecture Design diagram, Service
orchestration diagram.
SOA-Reference
Architecture
2.3.4. Service Validated Service
Architecture Validation Orchestration.
Validated SOA-
Reference Architecture
Development 3.1. Service Prototyping 3.1.1. Service New IT service catalog,
Architecture service composition
Requirement Analysis and orchestration
3.1.2. Functional Service platform and
Analysis and Design environment
3.1.3. Prototype Service Prototype (IT
Development Services/modular
prototype, system
prototype)
3.1.4. Prototype Validated Service
Validation Prototype
3.2. Service Testing 3.2.1. Prototype Requirements of IT
Requirement Analysis Service prototype
testing
3.2.2. Design Testing
Validation environment/facilities
3.2.3. System Testing Test scenario document
Development
3.2.4. Operational Test Testing result/report
and Evaluation
Deployment 4.1. Service Rollout 4.1.1. Rollout Requirements of service
Requirement Analysis rollout
4.1.2. Prepare Service System Rollout/
Rollout Implementation Plan
4.1.3. Service Service Rollout
Production and Testing Testing result/report
4.1.4. Service Rollout Testing result/report
4.2. Service Operation & 4.2.1. Operation System Operational
Monitoring Requirement Analysis Requirements
4.2.2. Prepare Service System Operation and
Operation Maintenance Manual,
Standard Operational
Procedures (SOP)
4.2.3. Service Operational services
Operation and
Monitoring
4.2.4. Service Service monitoring
Monitoring Validation result/report and data

18
4.3. Service Improvement 4.3.1. System Service evaluation and
evaluation analysis review report
4.3.2. Functional List of failed service
analysis and design component functions
4.3.3. Service review Service improvement
and improvement proposal
4.3.4. Validate Service Validated service
Improvement improvement proposal

2.8 Business Process Model and Notation (BPMN)


Business Process Model and Notation (BPMN) adalah standar untuk pemodelan proses
bisnis yang menyediakan notasi grafis untuk menentukan proses bisnis dalam Business
Process Diagram (BPD), didasarkan pada teknik flowchart sangat mirip dengan diagram
aktivitas dari Unified Modeling Language (UML). Tujuan dari BPMN adalah untuk
mendukung manajemen proses bisnis, baik untuk pengguna teknis dan pengguna bisnis,
dengan menyediakan notasi yang intuitif untuk pengguna bisnis, namun dapat mewakili
semantik proses yang kompleks. Spesifikasi BPMN juga menyediakan pemetaan antara
grafis dari notasi dan konstruksi yang mendasari bahasa eksekusi, khususnya Business
Process Execution Language (BPEL).
Tujuan utama dari BPMN adalah untuk memberikan notasi standar mudah dipahami
oleh semua pemangku kepentingan bisnis, termasuk analisis bisnis yang dapat
menyempurnakan proses. Para pengembang teknis bertanggung jawab untuk menerapkannya,
dan manajer bisnis yang memantau dan mengelola mereka. BPMN berfungsi sebagai bahasa
umum, menjembatani kesenjangan komunikasi yang sering terjadi antara desain proses bisnis
dan implementasi. Sejak 2014, BPMN telah dilengkapi dengan standar baru untuk membangun
Model Keputusan (Decision Model) dan Standar Notasi.
BPMN terdiri dari diagram sederhana dibangun dari seperangkat elemen grafis. Untuk
pengguna bisnis dan pengembang, mereka menyederhanakan pemahaman terhadap alur (flow)
dan aktivitas (activities) dari proses bisnis. Empat kategori elemen dasar BPMN adalah:
1. Flows Object 2. Connecting objects 3. Swim lanes dan 4. Artifacts.

2.8.1 Flows Object


Flow objects adalah elemen utama dalam BPMN, dan terdiri dari tiga elemen inti,
yaitu: Events, Activities, dan Gateways.
1. Events
Events diwakili dengan lingkaran dan menunjukkan sesuatu yang terjadi
(dibandingkan dengan aktivitas, yang merupakan sesuatu yang dilakukan). Ikon
dalam lingkaran menunjukkan jenis events (misalnya, sebuah amplop yang

19
mewakili pesan, atau jam mewakili waktu). events juga diklasifikasikan sebagai
penangkapan (misalnya, jika penangkapan pesan masuk mulai proses) atau
melempar (seperti melemparkan pesan selesai ketika proses berakhir).
• Start events
Bertindak sebagai pemicu proses; ditunjukkan dengan lingkaran bergaris tipis,
dan hanya dapat menangkap, sehingga ditunjukkan dengan ikon terbuka.
• Intermediate events
Merupakan sesuatu yang terjadi antara awal dan akhir events; ditunjukkan
dengan lingkaran bergaris ganda, dan dapat melemparkan atau menangkap.
Misalnya, tugas bisa mengalir ke suatu events yang melempar pesan
menyeberang ke pool lain, di mana events berikutnya menunggu untuk
menangkap respon sebelum melanjutkan.
• End events
Merupakan hasil dari sebuah proses; ditunjukkan dengan lingkaran bergaris
tebal, dan hanya bisa melempar, sehingga ditampilkan dengan ikon yang solid.
Berikut ini adalah gambar ikon dari ketiga events.

Gambar 10. Events sebagai elemen BPMN


2. Activities
Suatu activity diwakili dengan persegi panjang dengan sudut-bulat dan
menggambarkan jenis pekerjaan yang harus dilakukan. Activity atau
aktivitas/kegiatan adalah istilah umum untuk pekerjaan yang dilakukan
perusahaan. Aktivitas dapat bersifat atom (tidak dapat dipecah lagi) atau senyawa
(dapat dipecah lagi kedalam beberapa aktivitas).
• Task
Task merupakan satu kesatuan kerja yang tidak atau tidak dapat dipecah ke
tingkat lebih lanjut dari proses bisnis rinci. Hal ini disebut sebagai kegiatan
atom. Task adalah aktivitas level terendah digambarkan pada diagram proses.
Satu set task mungkin merupakan prosedur tingkat tinggi.
• Sub-process
Digunakan untuk menyembunyikan atau mengungkapkan tingkat tambahan
proses bisnis lebih rinci. Ketika diturunkan, subproses ditunjukkan dengan

20
tanda plus diposisi bawah didalam persegi panjang; ketika diperluas, persegi
panjang bulat mengembang untuk menampilkan semua aliran object,
menghubungkan obyek, dan artefak. Sebuah subproses disebut sebagai
kegiatan senyawa. Subproses memiliki events awal dan akhir sendiri; Urutan
mengalir dari proses induk dan tidak boleh keluar batas.
• Transaction
Suatu bentuk subproses di mana semua kegiatan yang ada harus diperlakukan
secara keseluruhan; yaitu, Transaksi harus diselesaikan untuk memenuhi
tujuan, dan jika salah satu gagal, maka harus dibatalkan. Transaction berbeda
dengan subproses yang dapat diperluas, dinotasikan dengan persegipanjang
dengan garis ganda.
• Call Activity
Sebuah titik dalam proses dimana proses global atau task global digunakan
kembali. Call Activity dibedakan dengan lainnya oleh perbatasan tebal sekitar
area kegiatan.

Gambar 11. Activities sebagai elemen dari BPMN


3. Gateways
Sebuah gateway diwakili dalam bentuk berlian dan menentukan pencabangan dan
penggabungan jalur, tergantung pada kondisi yang diungkapkan. Ada beberapa
jenis gateway, yaitu:
• Exclusive
Digunakan untuk membuat arus alternatif dalam proses. Karena hanya salah
satu jalur dapat diambil, hal itu disebut eksklusif.
• Event Based
Jalur proses ditentukan pada kondisi yang didasarkan pada sebuah events yang
telah dievaluasi.
• Parallel
Digunakan untuk membuat jalur paralel tanpa mengevaluasi kondisi apapun.
• Inclusive
Digunakan untuk membuat arus alternatif di mana semua jalur dievaluasi.
• Exclusive Event Based
21
Sebuah event dievaluasi untuk menentukan jalur yang saling eksklusif akan
diambil.
• Complex
Digunakan untuk memodelkan perilaku sinkronisasi yang kompleks.
• Parallel Event Based
Dua proses paralel dimulai berdasarkan suatu peristiwa, tetapi tidak ada
evaluasi dari events.

Gambar 12. Gateways sebagai elemen dari BPMN

2.8.2 Connecting Object


Flow objects dihubungkan satu sama lain menggunakan connecting objects, yang
terdiri dari tiga jenis, yaitu: sequences, messages, dan associations.
1. Sequences
Sequences diwakili dengan garis yang solid berpanah, dan menunjukkan di mana
memesan kegiatan yang dilakukan. Sequences flow juga memiliki simbol di awal,
sebuah berlian kecil menunjukkan salah satu dari sejumlah arus bersyarat dari
suatu event, sedangkan garis miring diagonal menunjukkan aliran bawaan dari
keputusan atau kegiatan dengan arus bersyarat.

Gambar 13. Sequence flow


2. Messages
Messages flow diwakili dengan garis putus-putus, lingkaran terbuka di awal
dengan panah terbuka di akhir. Digunakan untuk menunjukkan aliran pesan antara
dua partisipan dalam sebuah proses. Message flow tidak boleh dipergunakan
sebagai penghubung antar objek dalam satu pool.

Gambar 14. Message flow

22
3. Associations
Association diwakili dengan garis putus-putus. Hal ini digunakan untuk
mengaitkan artefak atau teks ke object flow, dan dapat menunjukkan beberapa
arahan menggunakan panah terbuka (menuju artefak yang mewakili hasil, dari
artefak yang mewakili input, dan keduanya untuk menunjukkan telah dibaca dan
diperbarui) . Tidak ada directionality yang digunakan ketika artefak atau teks
dikaitkan dengan aliran urutan atau pesan (sebagai aliran yang sudah
menunjukkan arah).

Gambar 15. Association flow

2.8.3 Swimlanes
Swimlanes adalah mekanisme visual dalam mengorganisasikan dan mengkategorikan
activities, dalam BPMN terdiri dari 2 (dua) jenis, yaitu: Pool dan Lane. Elemen ini dipat
digambarkan secara vertikal maupun horisontal. Swimlane bukan hanya sebagai pembatas
kategori pada aktivitas akan tetapi juga menggambarkan tanggung jawab dari setiap proses
yang ada.

Gambar 16. Lane dan pool pada swimlane

2.8.4 Artifacts
Artifacts mempresentasikan informasi yang saling berhubungan dalam sebuah model
namun bukan merupakan elemen individu dalam proses. Artifacts memungkinkan
pengembang untuk membawa beberapa informasi lebih lanjut ke dalam model/diagram.
Dengan cara ini model/diagram menjadi lebih mudah dibaca. Terdapat tiga jenis artifact,
yaitu: data objects, group dan annotation.
1. Data object: mekanisme untuk menunjukkan bagaimana data dibutuhkan atau
diproduksi oleh aktivitas. Data object dihubungkan dengan aktivitas melalui
Associations.

23
2. Group: diwakili dengan persegi panjang dengan ujung bulat yang digambarkan
dengan garis putus-putus. Group dapat digunakan untuk tujuan dokumentasi atau
analisis, tetapi tidak mempengaruhi sequence flow.
3. Annotation: mekanisme untuk pemodel memberikan informasi teks tambahan
untuk pembaca dari diagram BPMN.

Gambar 17. Data, group dan annotation sebagai elemen BPMN

Keempat kategori memungkinkan penciptaan diagram proses bisnis sederhana


(BPD). BPD juga mengizinkan membuat jenis baru dari objek aliran atau artefak, untuk
membuat diagram lebih dimengerti.

2.9 SOAML
SOAML adalah seperangkat ekstensi kecil UML untuk mendukung pemodelan SOA.
Terdapat beberapa keunggulan dari SOAML, yaitu dengan ekstensi UML2 yang mendukung
konsep layanan, focus pada konsep pemodelan layanan, serta terintegrasi dengan BPMN,
BMM, dan metamodel lainnya. SOAML menyediakan metamodel dan profil UML untuk
spesifikasi dan desain layanan dalam arsitektur berbasis layanan, yang meliputi identifying
services, specifying services, defining service consumers and providers, serta the policies.
Dalam SOAML terdapat beberapa konsep atau istilah yang digunakan, yaitu :
• Participant. Participant adalah entitas atau jenis entitas tertentu yang menyediakan atau
menggunakan layanan. Participant dapat mewakili komponen orang, organissai, atau
komponen sistem informasi.
• Port. Participant menyediakan atau mengkonsumsi layanan melalui port. Port adalah
bagian atau fitur dari participant yang merupakan titik interaksi untuk layanan, dimana
layanan disediakan dan dikonsumsi.
• Service Description. Mendeskripsikan bagaiman participant berinteraksi untuk
menyediakan atau menggunakan layanan yang dienkapsulasi dalam spesifikasi untuk
layanan ini. Service description meliputi UML interface, service interface, dan service
contract.
• Service Capabilities. Participant harus menyediakan layanan harus memiliki
kemampuan untuk menyediakan layanan tersebut. Service capability meliputi :

24
kemampuan yang miliki participant yang dapat dimanfaatkan untuk memberikan
layanan, dan kemampuan yang dibutuhkan untuk mengidentifikasi kandidat layanan.
• Service Architecture merupakan deskripsi tingkat tinggi tentang bagaimana participant
berinteraksi untuk suatu tujuan dalam menyediakan dan menggunakan layanan yang
dinyatakan dalam service contract.
Berikut ini adalah tahapan-tahapan dalam Service Modeling dengan SOAML:
1. Service identification. Mengidentifikasi kemampuan yang dibutuhkan berdasarkan
kebutuhan bisnis dan kemampuan ini dapat diakses melalui service interface.
2. Service specification, merupakan model rincian service interface. Service interface ini
mencakup antarmuka yang disediakan dan dibutuhkan, roles (peran) yang dimainkan
oleh antarmuka tersebut dalam spesifikasi layanan, dan aturan (rules) atau protocol
tentang bagaiman peran tersebut berinterkasi.
3. Service realization, merupakan model realisasi service interface, participant, operasi
dan metode layanan.
4. Service composition, merupakan bagaimana participant bergabung untuk
menghubungkan permintaan dan layanan melalui service channels. Gabungan ini
menggambarkan bagaimana participant disusun bersama untuk memberikan solusi,
termasuk implementasi layanan lainnya.
5. Service implementation, merupakan UML untuk fitur transformasi SOA yang
digunakan untuk membuat implementasi web services.

25
BAB III METODOLOGI

Metodologi yang digunakan dalam penelitian ini adalah menggunakan framework service
system engineering berbasis SOA (Suhardi dkk., 2017) yang terdiri dari tahapan identifikasi,
design, development dan deployment. Tahapan pada penelitian ini dibatasi sampai dengan
tahapan development.

Gambar 18. Service System Engineering Life Cycle Model

3.1 Identifikasi
Tahapan pertama yang dilakukan dalam penelitian ini adalah tahap identifikasi. Tahapan
ini terdiri dari tiga fase yaitu analisis kebutuhan, transformasi dan analisis model bisnis dan
inovasi layanan.

Tabel 3. Identification Stage


No Input Metode/Teknik Tools Output

Permasalahan terkait Analisa, studi True Observation


1
kemacetan lalu lintas literatur Requirement Analysis

- As-Is BMC
- Service
2 Rancangan model bisnis Analisa BMC
Innovation
- To-Be BMC

26
- Business
Service
Catalog

3.2 Perancangan
Tahap kedua dalam penelitian ini adalah tahap perancangan. Tahapan ini terdiri dari tiga
fase yaitu service modeling, process modeling dan architecture design.

Tabel 4. Design Stage


No Input Metode/Teknik Tools Output
Service
Service
Proses bisnis dan skenario Blueprint &
1 Analisa Blueprinting,
bisnis BPMN
BPMN
Koreografi

Daftar Layanan, Interaksi Tabel, Service


2 Analisa
antar layanan Draw.IO blueprint

Proses bisnis dan Tabel, Service


3 Analisa
rancangan data Draw.IO Catalog

IT Service
4 Katalog Layanan TI Analisa SOAML
Catalog

3.3 Pengembangan
Tahap selanjutnya dalam penelitian ini adalah tahap development. Tahapan ini terdiri dari
dua fase yaitu service prototyping dan service testing.

Tabel 5. Development Stage


No Input Metode/Teknik Tools Output
Notepad++,
PHP, Arduino Prototype
1 Daftar layanan Pemrograman
IDE, layanan
nodeMCU

Analisa dan Prototype


2 Prototype layanan Postman
Validasi layanan yang

27
telah
divalidasi

3.4 Deployment
Tahap selanjutnya dalam penelitian ini adalah tahap deployment.
No Input Metode/Teknik Tools Output
Gitlab, Web
Instalasi dan
1 Source Code Prototype Server, dan Aplikasi
Konfigurasi
Database

28
BAB IV IDENTIFIKASI

4.1 Analisis Kebutuhan


Terdiri dari beberapa langkah yaitu analisis operasional, analisis fungsional, analisis
kelayakan, dan validasi kebutuhan

4.1.1 Analisis Operasional


Berdasarkan studi literatur ditemukan informasi mengenai kemacetan yaitu
kemacetan adalah kondisi dimana arus lalu lintas yang lewat pada ruas jalan yang
ditinjau melebihi kapasitas rencana jalan tersebut yang mengakibatkan kecepatan
mendekati 0 Km/Jam sehingga menyebabkan terjadinya antrian (MKJI, 1997).
Kemacetan lalu lintas terjadi apabila kapasitas jalan tetap sedangkan jumlah pemakai
jalan terus meningkat yang menyebabkan waktu tempuh perjalanan menjadi lebih lama
(Wohl et al dalam sugiyanto, 2011). Saat ini sudah banyak teknologi yang
menghasilkan informasi kemacetan yang berguna bagi masyarakat untuk mengetahui
keadaaan suatu jalan seperti google maps.

Gambar 19. Arah Pergerakan Kendaraan Lalu Lintas

Berdasarkan hasil wawancara dan observasi lapangan, masyarakat


membutuhkan pengaturan APILL yang adil untuk semua persimpangan. Pengaturan
APILL untuk suatu persimpangan dianggap tidak memperhatikan kondisi jalanan,
apakah kendaraan pada persimpangan tersebut ada atau tidak. Hal ini relevan dengan
observasi yang telah dilakukan, dimana pada suatu persimpangan tertentu dengan
jumlah kendaraan padat memiliki jumlah waktu tunggu yang sama dengan
29
persimpangan lainnya tanpa memperhatikan jumlah kendaraan yang ada pada
persimpangan tersebut.

Tabel 6. Analisis Permasalahan Kemacetan


No Permasalahan/Kondisi Saat Ini Yang Perlu Dilakukan
1. Pengaturan APILL menggunakan Pemasangan sensor di setiap
timer yang tetap setiap keadaan persimpangan yang dapat mendeteksi
yang terjadi di lalu lintas keberadaan dan pergerakan kendaraan
kendaraan, sehingga waktu yang melintasi suatu persimpangan
tunggu persimpangan tidak
efisien dan dapat menyebabkan
kemacetan di salah satu
persimpangan
2. Kepolisian dan Dinas Pihak berwajib mendapat informasi status
perhubungan selaku pihak yang lalu lintas kendaraan dari sistem layanan
berwenang mengatur lalu lintas monitoring lalu lintas agar dapat diketahui
kendaraan tidak dapat bergerak persimpangan mana yang mengalami
secara cepat tanggap apabila ada suatu kejadian, sehingga personel dari
suatu persimpangan yang salah satu pihak berwajib dapat
dideteksi terjadi kemacetan melakukan tindakan secara cepat
3. Masyarakat mengalami kendala Masyarakat mendapat akses komunikasi
dalam memberikan aduan secara kepada pihak berwajib dengan
cepat kepada pihak berwajib menggunakan aplikasi mobile berbasis
apabila terjadi suatu android untuk menyampaikan aduan
permasalahan di persimpangan tentang permasalahan yang terjadi pada
yang mereka jalani suatu persimpangan

4.1.2 Analisis Fungsional


Setelah melakukan analisis operasional, selanjutnya adalah melakukan analisis
fungsional. Hasil observasi lapangan dapat diturunkan menjadi fungsi-fungsi bisnis
(business function) sebagaimana disajikan pada berikut ini.

30
Tabel 7. Analisis Fungsional Kemacetan
No. Fungsi Bisnis Deskripsi
Fungsi pembacaan data keberadaan dan
1. Pendeteksian informasi kendaraan pergerakan kendaraan secara otomatis
dengan menggunakan sensor
Fungsi ini dapat memenuhi kebutuhan
Penyebaran data informasi data dan informasi kendaraan melalui
2.
kendaraan public API dari sistem layanan yang
dibangun
Fungsi ini dapat memenuhi kebutuhan
masyarakat dalam menyampaikan
3. Pengaduan masyarakat
permasalahan yang berkaitan dengan
lalu lintas di suatu persimpangan

4.2 Analisis dan Transformasi Model Bisnis

4.2.1 Analisis Kebutuhan Operasional Model Bisnis


Berdasarkan kebutuhan operasional pada tahap sebelumnya, kemudian
dilakukan analisis model bisnis terhadap layanan pengaturan lampu lalu lintas yang
dilakukan oleh Kepolisian maupun Dinas Perhubungan. Model bisnis ini kemudian
dituangkan dalam bentuk Business Model Canvas (BMC) yang dapat dilihat pada
gambar berikut.

Value Customer Customer


Key Partner Key Activities
Proposition Relationship Segment
- Dinas - Pengaturan - Pengaturan - Penanganan - Masyarakat
Perhubungan Lampu Lalu lalu lintas kemacetan Pengguna
- Kepolisian Lintas otomatis langsung oleh Jalan
petugas

Key Resource : Channel :

Lampu Lalu -
Lintas,
Persimpangan

31
Cost Structure : Revenue Stream :

- Biaya Pengadaan Infrastruktur - APBN


- Biaya Pemeliharaan
- Biaya Operasional

Gambar 20. Business Model Canvas As-Is

Berdasarkan BMC ‘As-Is’ dapat diketahui bahwa pada blok Key Activities
pengaturan lampu lalu lintas dilakukan dengan cara mengatur timer tetap pada APILL
yang dipasang di setiap persimpangan. Kegiatan ini mengharuskan petugas, baik dari
pihak Kepolisian maupun Dinas Perhubungan, selalu siap siaga menjaga kelancaran
lalu lintas dikarenakan waktu timer pada APILL tidak dapat menyesuaikan dengan
jumlah kendaraan pada suatu persimpangan.
Value Proportion pada model bisnis ‘as-is’ yakni penyediaan layanan
pengaturan APILL secara otomatis untuk mempermudah petugas dalam menghitung
durasi waktu tunggu untuk laju kendaraan pada setiap persimpangan. Pada Blok
Customer Relationship, Pengguna yang dalam hal ini adalah warga pengguna jalan
dapat berinteraksi langsung dengan pihak berwajib yang sedang bertugas untuk
mengatur keadaan lalu lintas. Tidak adanya channel langsung yang dapat digunakan
oleh masyarakat akan mempersulit mereka dalam menghubungi pihak yang berwajib,
apabila tidak pihak berwajib yang bertugas tidak berada di lokasi yang ditemukan
permasalahan lalu lintas.

4.2.2 Formulasi Kebutuhan Fungsional, Implementasi dan Validasi Model


Bisnis
Model bisnis saat ini masih memiliki beberapa kelemahan seperti yang telah
dijelaskan sebelumnya. Kekurangan tersebut kemudian akan diperbaaiki melalui
peningkatan model bisnis sistem usulan. Model bisnis usulan disajikan pada gambar
berikut.

32
Customer Customer
Key Partner Key Activities Value Proposition
Relationship Segment
- Dinas - Optimalisasi - Pengaturan - Pengaduan -
Perhubungan pengaturan lampu lalu permasalahan Masyarakat
- Kepolisian lampu lalu lintas yang lalu lintas ke Pengguna
- Masyarakat lintas dapat pihak Jalan
- Pendeteksian menyesuaikan berwajib
pergerakan dan dengan jumlah secara cepat
jumlah kendaraan pada
kendaraan setiap
- Pelayanan persimpangan
cepat tanggap - Kemudahan
lalu lintas oleh Akses dan
pihak berwajib Kontrol
terhadap
Key Resource Keadaan Lalu Channel
Lintas
- Lampu Lalu - SMS
Lintas - Mobile
- Persimpangan Application
- Perangkat IOT - Web
Service
Cost Structure: Revenue Stream :

- Biaya Pengadaan Infrastruktur - APBN


- Biaya Pemeliharaan - Penyewaan Provider
- Biaya Operasional Jaringan
- Pemberian Akses API
Gambar 21. Business Model Canvas to-be

Perubahan terjadi hampir pada semua blok. Key Aktivities akan berfokus pada perangkat
dan transformasi TI seperti pemasangan perangkat, pemantauan sensor, dan pengiriman
notifikasi. Pada blok Customer Relationship, masyarakat akan dapat menggunakan perangkat
smartphone untuk mengirimkan aduan tentang permasalahan lalu lintas yang terjadi.
Perubahan di blok Key Resources yaitu sudah melibatkan internet, sensor obstacle dan sensor
ultrasonic, dan arsitektur sistem. Pada blok Channel, adanya penambahan webservice, mobile
application dan sms sebagai media menyampaikan informasi.

4.3 Inovasi Layanan


Penentuan inovasi terhadap layanan bisnis deteksi dini bencana banjir berbasis IoT
dilakukan dengan terlebih dahulu melakukan analisis terhadap kebutuhan model bisnis pada
fase sebelumnya

33
4.3.1 Analisis Kebutuhan Model, Analisis dan Formulasi Layanan
Penentuan inovasi terhadap layanan bisnis dilakukan dengan terlebih dahulu
melakukan analisis terhadap kebutuhan model bisnis pada fase sebelumnya. Analisis
terhadap model bisnis to-be dilakukan untuk mendapatkan kebutuhan akan inovasi
layanan. Inovasi tersebut disesuaikan dengan kebutuhan dan tujuan yang sudah
diidentifikasi. Analisis dilakukan dengan menggunakan Goal Service Modeling (GSM)
yang hasilnya dapat dilihat pada tabel berikut.

Tabel 8. Goal Service Modelling Sistem Layanan Optimalisasi Pengaturan APILL


Goal / Sub Goal KPI Metric
Peningkatan jumlah sensor
Tersedianya sistem
yang digunakan untuk
layanan pengaturan Jumlah sensor
mendeteksi keberadaan dan
APILL yang optimal
pergerakan kendaraan
Tersedianya sistem
layanan yang dapat Peningkatan jumlah
menyampaikan penanganan aduan
Jumlah tindakan aduan
informasi aduan masyarakat yang diterima
masyarakat secara oleh petugas
cepat dan tepat
Tersedianya sistem
layanan yang dapat
Peningkatan jumlah akses
menyediakan data Jumlah akses
data kendaraan lalu lintas
dan informasi
kendaraan lalu lintas

4.3.2 Pemilihan Inovasi Layanan


Katalog layanan bisnis yang akan dikembangkan dapat dilihat pada tabel dibawah ini.
Layanan Bisnis Deskripsi
Layanan yang digunakan untuk mengatur
Layanan Pengaturan APILL
APILL secara optimal
Layanan Monitoring Lalu Lintas Layanan yang digunakan untuk mengawasi
keadaan lalu lintas dan aduan masyarakat

34
Layanan Pengaduan Masyarakat Layanan yang digunakan untuk memberikan
aduan permasalahan lalu lintas
Layanan Penyebaran Data Layanan yang digunakan untuk memberikan
akses kepada masyarakat dalam
menggunakan API yang disediakan sesuai
dengan kebutuhan

4.3.3 Validasi Inovasi Layanan


Validasi inovasi dilakukan dengan melakukan pengecekan kembali antara
inovasi layanan dengan kebutuhan yang sudah diidentifikasi di langkah sebelumnya.
Hasil pengecekan menunjukkan bahwa usulan inovasi layanan sudah sesuai dengan
layanan deteksi banjir yang diharapkan.

35
BAB V PERANCANGAN
Tahap perancangan merupakan tahap kedua setelah identifikasi yang terdiri atas beberapa
fase yaitu pemodelan layanan, pemodelan proses, dan perancangan arsitektur. Tahap ini
melakukan analisis dan perancangan terhadap inovasi layanan yang telah dipilih pada fase
inovasi layanan sebelumnya. Perancangan dilakukan dengan memperhatikan interaksi berbagai
pihak yang terlibat dalam layanan, proses bisnis yang terjadi, serta hubungan antara satu
layanan dengan layanan lainnya.

5.1 Pemodelan Layanan


Pemodelan layanan terdiri atas beberapa langkah yang dilakukan yaitu analisis kebutuhan
pemodelan layanan, analisis dan perancangan fungsional model layanan, dan mengembangkan
model layanan.

5.1.1 Analisis Kebutuhan Pemodelan Layanan


Pada tahap ini dilakukan analisis terhadap inovasi yang telah dihasilkan pada
fase inovasi layanan sebelumnya. Selanjutnya dilakukan identifikasi terhadap
komponen-komponen yang terdapat pada inovasi layanan tersebut. Terdapat 6-tuple
yang digunakan sebagai pendekatan untuk mengidentifikasi unsur sistem layanan
(Zhang dkk., 2007). Keenam tuple dalam sistem layanan optimalisasi pengaturan
APILL otomatis dan penanganan aduan lalu lintas adalah sebagai berikut.
a. Inputs, data mengenai keberadaan dan pergerakan kendaraan yang berasal dari
sensor. Data inilah yang akan dikirim ke database server melalui
mikrokontroler untuk dilakukan proses lebih lanjut.
b. Outputs, berupa layanan pengaturan APILL, layanan pengaduan lalu lintas oleh
masyarakat, dan public API.
c. Tujuan, tersampaikannya informasi keadaan lalu lintas.
d. Transformasi, berupa kegiatan kontrol terhadap perangkat pengaturan APILL
beserta element pendukungnya agar tercapai tujuan bisnis.
e. Komponen, terdiri atas:
• People, yakni masyarakat pengguna jalan.
• Partners, yakni tim atau unit pengawas lalu lintas dari Kepolisian dan Dinas
Perhubungan, penyedia layanan internet, penyedia perangkat keras dan
penyedia perangkat lunak.

36
• Informasi, yakni informasi keadaan lalu lintas dari data sensor dan
pengaduan masyarakat.
• Aktivitas, meliputi pemasangan sensor, pengiriman data dari sensor ke
database server melalui mikrokontroler, pengaturan APILL, pengaduan
permasalahan lalu lintas, dan monitoring keadaan lalu lintas.
• Sumber daya, berupa infrastruktur TI (perangkat keras dan perangkat lunak)
serta fasilitas sarana dan prasarana seperti bangunan, ruang kerja, ruang
server.
f. Sensor, berupa sensor obstacle dan sensor ultrasonic.

Gambar 22. Model Sistem Layanan (Zhang dkk., 2007)

5.1.2 Analisis dan Perancangan Fungsional


Sistem layanan optimalisasi pengaturan APILL otomatis dan penanganan aduan
lalu lintas merupakan sistem yang berfungsi untuk memantau keadaan lalu lintas dan
mengatur APILL secara optimal. Hal ini berguna bagi pihak berwajib untuk
menghindari kemacetan pada salah satu persimpangan sekaligus dapat bertindak secara
cepat apabila ada aduan dari masyarakat tentang permasalahan mengenai lalu lintas.
Notifikasi yang diterima melalui pengaduan masyarakat akan berisikan detil aduan
yang dapat memberikan informasi kepada pihak berwajib untuk dapat melakukan

37
penanganan permasalahan lalu lintas secara cepat dan tepat. Selain itu, pengaturan
APILL dengan menggunakan sensor obstacle dan sensor ultrasonic dapat membuat
waktu tunggu setiap persimpangan menjadi optimal karena dapat menyesuaikan dengan
keberadaan dan jumlah kendaraan pada suatu persimpangan. Sensor ini dipasang pada
jarak tertentu di setiap persimpangan, dimana posisi kedua sensor saling berseberangan.
Data yang diterima dari kedua sensor tersebut dikirimkan ke database server dengan
menggunakan bantuan mikrokontroler yang terhubung dengan koneksi internet.

Gambar 23. Rancangan Sistem Layanan Optimalisasi Pengaturan APILL Otomatis Dan
Penanganan Aduan Lalu Lintas

Rancangan sistem tersebut dapat dipecah menjadi beberapa subsistem dengan


fokus masing-masing sebagai berikut:
a. IoT (Internet of Thing)
Subsistem ini bertanggung jawab dalam arsitektur alur komunikasi antar
komponen, yaitu komponen fisik yang ditangkap oleh sensor dan komponen
perangkat lunak sehingga dapat berkomunikasi melalui jaringan internet.
b. Detektor/sensor

38
Sistem ini menggunakan sensor obstacle dan ultrasonic. Detektor/sensor
merupakan subsistem yang bertanggung jawab menangkap nilai-nilai
variabel kendaraan yaitu keberadaan, pergerakan dan jumlah kendaraan.
c. Mobile application
Aplikasi berbasis mobile berfungsi sebagai jembatan IoT dengan sistem
sosial. Hal ini diperlukan untuk memudahkan masyarakat dalam
memberikan aduan permasalahan lalu lintas secara langsung kepada pihak
berwajib sehingga dapat diatasi dengan cepat.
Kebutuhan pengguna (user) dari sistem ini dideskripsikan pada table berikut.

Tabel 9. Daftar kebutuhan pengguna sistem layanan


No. Nama Kebutuhan Deskripsi
1. Sistem dapat menggunakan Data keberadaan dan pergerakan
sensor untuk menangkap data kendaraan dapat dibaca oleh sensor
untuk dikirim ke mikrokontroler
2. Sistem dapat menyimpan data Data yang diperoleh dari sensor
yang dideteksi oleh sensor disimpan di database server melalui
pengiriman oleh mikrokontroler
3. Sistem dapat membaca History data keberadaan dan
keberadaan dan pergerakan pergerakan kendaraan dapat dibaca
kendaraan setiap pergantian lalu sampai pada keadaan yang paling
lintas di persimpangan terakhir dengan menggunakan
dashboard pada desktop application
4. Sistem dapat memberikan Detil aduan yang disampaikan oleh
informasi dan notifikasi aduan masyarakat melalui mobile
masyarakat application akan disampaikan
dalam bentuk notifikasi dan sirine
sesuai dengan jenis aduan yang
diterima
5. Sistem dapat mengatur APILL Pengaturan APILL dapat
secara otomatis dan optimal disesuaikan dengan kondisi
kendaraan yang melintas di suatu
persimpangan

39
Daftar kebutuhan fungsional dari sistem deteksi banjir dimuat pada tabel
berikut.

Tabel 10. Daftar kebutuhan fungsional sistem layanan


No. Deskripsi
1. Sistem dapat menggunakan sensor obstacle dan sensor ultrasonic
2. Sistem dapat mengirimkan data keberadaan, pergerakan, dan jumlah
kendaraan ke sistem penyimpanan data
3. Sistem dapat membaca keberadaan dan pergerakan kendaraan setiap
pergantian lalu lintas di persimpangan
4. Sistem dapat memberikan informasi dan notifikasi aduan masyarakat
5. Sistem dapat mengatur APILL secara otomatis dan optimal
6. Sistem dapat membagi informasi dalam bentuk public API

5.2 Pemodelan Layanan Bisnis


Pemodelan Layanan Bisnis digunakan untuk melihat gambaran besar dari berbagai
layanan yang diusulkan. Pemodelan ini diperlukan sebelum menerjemahkan usulan Layanan
ke dalam fase Deployment

5.2.1 Service Blueprint


Layanan Pengaturan APILL

Gambar 24. Service Blueprint Layanan Pengaturan APILL

40
Layanan Monitoring Lalu Lintas

Gambar 25. Service Blueprint Layanan Monitoring Lalu Lintas

Layanan Pengaduan Masyarakat

Gambar 26. Service Blueprint Layanan Pengaduan Masyarakat

41
Layanan Penyebaran Data

Gambar 27. Service Blueprint Layanan Penyebaran Data

5.2.2 Business Process Modelling Notation


Layanan Pengaturan APILL

Gambar 28. BPMN Pengaturan APILL

42
Layanan Monitoring Lalu Lintas

Gambar 29. BPMN Layanan Monitoring Lalu Lintas

Layanan Pengaduan Masyarakat

Gambar 30. BPMN Layanan Pengaduan Masyarakat

43
Layanan Penyebaran Data

Gambar 31. BPMN Layanan Penyebaran Data

5.2.3 Business Service Capabilities


Layanan Pengaturan APILL

Tabel 11. Dekomposisi Layanan Pengaturan APILL


No. Proses Bisnis Capabilities
1. Start Timer Memulai waktu timer pada salah satu
warna lampu APILL
2. Deteksi Pergerakan Kendaraan Menerima data dari sensor-sensor
3. Kirim Data Mengirimkan data dari sensor ke
mikrokontroler untuk diproses
Mengirimkan data mikrokontroler ke
Database
4. Proses Data Hitung Jumlah Kendaraan
Validasi Data Pergerakan Kendaraan
Validasi Warna Lampu
5. Konfigurasi APILL Start Delay Timer
Trigger Immediate Validation
Habiskan Durasi
Ganti Warna Lampu APILL

44
Layanan Monitoring Lalu Lintas

Tabel 12. Dekomposisi Layanan Monitoring Lalu Lintas


No. Proses Bisnis Capabilities
1. Proses Data Cari data sesuai request
Mengurutkan data berdasarkan waktu
terkini
Mengembalikan data pada requester
2. Monitoring Lalu Lintas Membuka desktop application
Melihat history aduan
Cek status penanganan aduan
3. Penanganan Aduan Periksa detil aduan
Hubungi personel lapangan
Penanganan langsung di lapangan

Layanan Pengaduan Masyarakat

Tabel 13. Dekomposisi Layanan Pengaduan Masyarakat


No. Proses Bisnis Capabilities
1. Pengaduan Masyarakat Mengisi detil aduan sesuai dengan
permasalahan yang ditemukan
Mengirim laporan aduan
2. Pengelolaan Aduan Masyarakat Penerimaan laporan
Validasi detil aduan yang diterima
Menyalakan sirine sesuai dengan jenis
aduan
Menampilkan detil aduan
Menyimpan detil aduan ke dalam
database
3. Penanganan Aduan Periksa detil aduan
Hubungi personel lapangan
Penanganan langsung di lapangan

45
Layanan Penyebaran Data

Tabel 14. Dekomposisi Layanan Penyebaran Data


No. Proses Bisnis Capabilities
1. Penggunaan API Request API
Get Data
2. Notifikasi Pengiriman dan penerimaan notifikasi
apakah request API diterima atau
ditolak
3. Pengelolaan API Penerimaan request data
Validasi request data
Approve request
Deny request
Grant request access
Return data API
Validasi Warna Lampu
4. Registrasi Pendaftaran identitas untuk akses API
Pengisian form
Submit form
Ganti Warna Lampu APILL

5.2.4 Business Service Candidates


Proses selanjutnya adalah mendapatkan kandidat operasi dari setiap
dekomposisi proses bisnis yang telah di identifikasi sebelumnya. Kandidat Operasi di
dapat dari dekomposisi proses bisnis yang dapat di otomatisasi. Berikut adalah proses
identifikasi operasi dari setiap proses bisnis yang ada.

46
Layanan Pengaturan APILL

Tabel 15. Identifikasi Operasi Bisnis Layanan Pengaturan APILL


Proses
No. Capabilities Operasi Parameter Return
Bisnis
1. Start Timer Memulai waktu start_timer warna_lampu none
timer pada salah : int,
satu warna timer: int
lampu APILL
2. Deteksi Mengatur status set_sensor_state none sensor_state:
Pergerakan dari sensor- boolean
Kendaraan sensor
Menerima data get_sensor_state id_sensor: int sensor_state:
status dari boolean
sensor-sensor
3. Kirim Data Mengirimkan get_data request: array serial_data_si
data dari sensor mpang: string
ke
mikrokontroler
untuk diproses
Mengirimkan send_data serial_data_si sending_statu
data mpang: string s: boolean
mikrokontroler
ke Database
4. Proses Hitung Jumlah count_vehicle id_simpang: vehicle_num
Data Kendaraan int ber: int
get_count_vehicl request: response: int
e string
Validasi Data sensor_correction id_simpang: sensor_correc
Pergerakan int tion: boolean
Kendaraan
Validasi Warna apill_correction id_apill: int apill_correcti
Lampu on: boolean
5. Konfiguras Start Delay start_delay_timer none none
i APILL Timer

47
Trigger trigger_validation none none
Immediate
Validation
Habiskan Durasi set_default_timer none none
Ganti Warna switch_apill id_simpang: none
Lampu APILL int

Layanan Monitoring Lalu Lintas

Tabel 16. Identifikasi Operasi Bisnis Layanan Monitoring Lalu Lintas


Proses
No. Capabilities Operasi Parameter Return
Bisnis
1. Proses Cari data search_data request: data: array
Data sesuai request string
Mengurutkan sort_by_time data: array sorted_data:
data array
berdasarkan
waktu terkini
Mengembalik get_data none data: array
an data pada
requester
2. Monitorin Membuka init_desktop_moni none none
g Lalu desktop toring
Lintas application
Melihat view_history_adu none none
history aduan an
Cek status get_aduan_status id_aduan: int aduan_status:
penanganan boolean
aduan
3. Penangana Periksa detil detail_aduan id_aduan: int detail_aduan:
n Aduan aduan array
Hubungi send_sms id_aduan: sending_status:
personel int, boolean
lapangan detil_aduan:
array

48
Penanganan set_aduan_status id_aduan: int none
langsung di
lapangan

Layanan Pengaduan Masyarakat

Tabel 17. Identifikasi Operasi Bisnis Layanan Pengaduan Masyarakat


Proses
No. Capabilities Operasi Parameter Return
Bisnis
1. Pengadua Mengisi detil create_aduan request: data_aduan:
n aduan sesuai array array
Masyarak dengan
at permasalahan
yang
ditemukan
Mengirim send_aduan data_aduan: sending_status:
laporan aduan array boolean
2. Pengelola Penerimaan get_aduan id_aduan: data_aduan:
an Aduan laporan int array
Masyarak Validasi detil validation_aduan id_aduan: validation_status
at aduan yang int : boolean
diterima
Menyalakan activate_sirine id_aduan: none
sirine sesuai int,
dengan jenis category_ad
aduan uan: int
Menampilkan view_aduan request: response: array
detil aduan array
Menyimpan save_aduan data_aduan: save_status:
detil aduan ke array boolean
dalam
database
3. Penangana Periksa detil detail_aduan id_aduan: detail_aduan:
n Aduan aduan int array
Hubungi send_sms id_aduan: sending_status:
personel int boolean
lapangan

49
Penanganan set_aduan_status id_aduan: status: boolean
langsung di int
lapangan

Layanan Penyebaran Data

Tabel 18. Identifikasi Proses Bisnis Layanan Penyebaran Data


Proses
No. Capabilities Operasi Parameter Return
Bisnis
1. Pengguna Request API request_api url: string response: int
an API Get Data get_data url: string data: json
2. Notifikasi Pengiriman get_notif none data: json
dan
penerimaan
notifikasi
apakah request
API diterima
atau ditolak
3. Pengelola Penerimaan get_request url: string response: int
an API request data
Validasi validation_token token: string response: int
request data
Approve approve_request token: string response: int
request
Deny request deny_request token: string response: int
Grant request grant_request token: string response: int
access
Return data return_data token: Data: json
API string, url:
string
Validasi validate_apill id_apill: int validation_status:
Warna Lampu boolean
4. Registrasi Pendaftaran sign_up Request: registration_status:
identitas untuk array boolean
akses API
Pembuatan Create_user request: response: string
user array

50
Submit form submit_form form_data: submit_status: boolean
string
Ganti Warna change_apill id_apill, : int none
Lampu APILL id_simpang:
int
5. Login Memasukkan login username: response: string
credential string,
yang sudah password:
terdaftar string
Melakukan validate_token token: string response: string
validasi token
Keluar dari logout id_user: int response: string
sistem

5.2.5 Business Service Architecture


Berikut ini adalah ringkasan seluruh operasi yang telah diidentifikasi diatas:

Tabel 19. Operasi Sistem Layanan Optimalisasi Pengaturan APILL Otomatis dan Penanganan Aduan
Lalu Lintas
No. Operasi No. Operasi
1 start_timer 26 view_aduan
2 set_sensor_state 27 save_aduan
3 get_data 28 detail_aduan
4 send_data 29 send_sms
5 count_vehicle 30 get_count_vehicle
6 sensor_correction 31 request_api
7 apill_correction 32 get_data
8 start_delay_timer 33 get_notif
9 trigger_validation 34 get_sensor_state
10 set_default_timer 35 validation_token
11 switch_apill 36 approve_request
12 search_data 37 deny_request
13 sort_by_time 38 grant_request
14 get_data 39 return_data
15 init_desktop_monitoring 40 validate_apill

51
16 view_history_aduan 41 sign_up
17 get_aduan_status 42 create_form
18 detail_aduan 43 submit_form
19 send_sms 44 change_apill
20 set_aduan_status 45 Login
21 create_aduan 46 Validate_token
22 send_aduan 47 logout
23 get_aduan
24 validation_aduan
25 activate_sirine

Kandidat operasi yang telah diidentifikasi di atas kemudian dikelompokan


sehingga menjadi sebuah kandidat layanan. Setelah mendapatkan kandidat layanan dan
operasi melalui tahapan sebelumnya diatas, kemudian dilakukan revisi agar layanan
dan operasi yang terindikasi duplikat digabungkan.

Tabel 20. Kandidat Layanan Sistem Layanan Optimalisasi Pengaturan APILL Otomatis dan
Penanganan Aduan Lalu Lintas
Kandidat Kandidat Operasi
No.
Layanan
1 SSO Login, validate_token, logout, sign_up
2 Pengaduan view_aduan, get_aduan_status, set_aduan_status,
create_aduan, send_aduan, get_aduan,
validation_aduan
3 Penyebaran Send_data, get_data, search_data, count_vehicle,
Data get_count_vehicle
4 Notifikasi Send_sms, activate_sirine, get_notif
5 IoT set_default_timer, start_timer, start_delay_timer,
set_sensor_state, get_sensor_state, sensor_correction,
apill_correction, trigger_validation, switch_apill

5.3 Pemodelan Layanan IT

5.3.1 Service Interface

52
Pemodelan pertama adalah dengan service interface diagram. Berikut disajikan
pada gambar service interface diagram yang ada pada sistem layanan yang dibangun.

Gambar 32. SSO Service Interface Diagram

Gambar 33. Pengaduan Service Interface Diagram

Gambar 34. Penyebaran Data Service Interface Diagram


53
Gambar 35. Notifikasi Service Interface Diagram

Gambar 36. IoT Service Interface Diagram

5.3.2 Service Rule dan Protocols

Gambar 37. Pengaduan Sequence Diagram

54
Gambar 38. Penyebaran Data Sequence Diagram

Gambar 39. IoT Sequence Diagram

55
5.3.3 Service Participants

Gambar 40. Service Participant Diagram Sistem Layanan

5.3.4 Service Contract


Tahap berikutnya adalah service contract diagram. Sama seperti Service
Interface, Service Contract Diagram adalah diagram untuk menentukan peran,
antarmuka, data pesan layanan. Service Contract mendefinisikan kontrak yang
menentukan bagaimana penyedia (provider) dan konsumen (Requester / Consumer)
bekerja bersama untuk mencapai tujuan, melalui penggunaan layanan. Service Contract
menggambarkan perjanjian antara provider dan requester tentang bagaimana layanan
harus disediakan dan dikonsumsi. Perjanjian tersebut mencakup antarmuka, koreografi,
serta syarat dan ketentuan lainnya sehingga Service Contract Diagram dirancang untuk
spesifikasi Service Contract. Berikut service interface diagram yang ada pada sistem
layanan yang dibangun.

Gambar 41. Service Contract SSO

56
Gambar 42. Service Contract Notifikasi

Gambar 43. Service Contract Pengaduan

Gambar 44. Service Contract Penyebaran Data

Gambar 45. Service Contract IoT

57
5.4 Service System Architecture

Gambar 46. Service Architecture Sistem Layanan Optimalisasi Pengaturan APILL Otomatis Dan
Penanganan Aduan Lalu Lintas

58
BAB VI PENGEMBANGAN
6

6.1 Service Prototyping


Pada fase ini, sistem layanan yang telah didesain akan dibuat menjadi beberapa prototype
sistem layanan yang memiliki fungsi-fungsi sesuai dengan model yang telah didesain.
Beberapa prototype yang telah dibuat antara lain:
1. Prototype Sistem Layanan Optimalisasi Pengaturan APILL
• Mendesign PCB Traffic Light dengan PCB Express

Gambar 47. Rancangan Desain PCB Traffic Light dengan PCB Express

• Driver Traffic Light Design

Gambar 48. Rancangann Driver Traffic Light

59
• Hasil Design kemudian dicetak dan dirakit seperti gambar dibawah ini

Gambar 49. Hasil Rakitan Alat Simulasi (dari atas)

Gambar 50. Hasil Rakitan Alat Simulasi (dari samping)

60
• Pembuatan Script untuk pengiriman data dari Mikrokontroler ke Database
Menggunakan Arduino IDE

Gambar 51. Potong Script Pada nodeMCU (1)

Gambar 52. Potongan Script Pada nodeMCU (2)

61
Gambar 53. Potongan Script Pada nodeMCU (3)

• Pembuatan Script Pada Sensor Obstacle dan Ultrasonic Menggunakan Arduino IDE

Gambar 54. Potongan Script untuk Konfigurasi Sensor Obstacle dan Ultrasonic (1)

62
Gambar 55. Potongan Script untuk Konfigurasi Sensor Obstacle dan Ultrasonic (2)

2. Prototype Sistem Layanan Monitoring Lalu Lintas Menggunakan Visual Basic


• User Interface Sistem Layanan Monitoring Lalu Lintas

Gambar 56. Tampilan Dashboard Aplikasi Desktop

63
Gambar 57. Panel Aduan Masyarakat Berisikan Identitas Aduan

Gambar 58. Panel Jumlah Kendaraan Pada Setiap Persimpangan

Gambar 59. Panel History Pengaduan Masyarakat

• Contoh Script Sistem Layanan Monitoring Lalu Lintas

Gambar 60. Potongan Script Untuk Pembuatan Desktop Application

64
3. Prototype Sistem Layanan Pengaduan Masyarakat berbasi Android menggunakan
Android Studio
• Potongan Script Koneksi API Server Aplikasi Android

Gambar 61. Script Koneksi API Server

• Potongan Script Dashboard Aplikasi Android

Gambar 62. Script Dashboard

65
• User Interface Sistem Layanan Pengaduan Masyarakat

Gambar 63. Dashboard Aduan E-Complaint

Gambar 64. Contoh Kasus Pemilihan Simpang Yang Macet

66
Gambar 65. Contoh Kasus Pemilihan Jenis Aduan

Gambar 66. Contoh Kasus Deteksi Lokasi Pemberi Aduan

67
• Screenshot notifikasi bentuk SMS Gateway

Gambar 67. Contoh Notifikasi Dalam Bentuk SMS

4. Prototype Sistem Layanan Penyebaran Data, berupa Traffic Information API yang
buat dengan bahasa pemrograman PHP
• User Interface Sistem Layanan Penyebaran Data

Gambar 68. User Interface Register dan Gathering Traffic Data Traffic Information API

68
Gambar 69. User Interface all_aduan dan aduan_by_date Traffic Information API

Gambar 70. User Interface Jumlah Kendaraan Traffic Information API

69
• Contoh Script Sistem Layanan Penyebaran Data

Gambar 71. Potongan Script Layanan Penyebaran Data

6.2 Service Testing


Pada fase ini dilakukan uji coba fungsi-fungsi dari prototype sistem layanan yang telah
dibangun. Uji coba dilakukan antara lain:
1. Uji coba Sistem Layanan Optimalisasi APILL
Pengujian pertama dilakukan dengan menjalankan traffic light tanpa ada kendaraan
yang melintas. Pengujian kedua dilakukan dengan melakukan pergerakan mobil-
mobilan sebagai simulasi adanya kendaraan yang melintas pada persimpangan
tersebut. Setelah 10 detik maka hentian pergerakan lalu lintas, seolah olah tidak ada

70
lagi kendaraan yang melintas. Kemudian perhatikan apa yang terjadi pada
persimpangan tersebut setelah selama 3 detik tidak ada pergerakan lalu lintas.
Pengujian ketiga dilakukan dengan melakukan pergerakan mobil-mobilan selama 35
detik yang menandakan bahwa volume kendaraan yang melintas cukup tinggi.
Perhatikan apa yang terjadi dipersimpangan pada detik ke 30.
Berdasarkan simulasi pengujian yang dilakukan pada perangkat prototype traffic light
menggunakan tiga kondisi maka diperoleh hasil pengujian sebagai berikut :

Tabel 21. Hasil Pengujian Perangkat Prototype Traffic Light


Kasus dan Hasil Uji
Data Masukan Yang Diharapkan Pengamatan Kesimpulan
Traffic light tanpa Lampu hijau Setelah 3 detik Sesuai
kendaraan menyala selama 3 lampu hijau tidak
melintas detik menyala
Traffic light Lampu hijau Setelah 10 detik Sesuai
dengan menyala selama 10 tidak ada
kendaraan detik, 3 detik pergerakan, maka
melintas 10 detik kemudian lampu 3 detik kemudian
hijau tidak lampu hijau tidak
menyala. menyala.
Traffic light Lampu hijau Setelah sampai ke Sesuai
dengan menyala hanya detik 30, maka
kendaraan sampai pada detik lampu hijau tidak
melintas selama ke 30 menyala
35 detik

2. Uji Coba Sistem Layanan Monitoring Lalu Lintas


Pengujian diawali dengan uji coba sensor menghitung jumlah kendaraan yang
melintas disuatu simpang. Terlihat pada layar LED jumlah Kendaraan (K) terus
bertambah apabila ada pergerakan mobil-mobilan yang melewati sensor.

Gambar 72. Tampilan LED Prototype Traffic Light

71
Setelah keempat simpang didapatkan datanya maka akan ditampilkan dalam aplikasi
desktop monitoring. Begitu juga bila ada pengaduan dari masyarakat, aplikasi akan
membunyikan sirine sesuai dengan tipe kejadiannya dan memberikan warna yang
berbeda untuk tiap tipe kejadian. Keadaan tersebut ditunjukkan pada gambar berikut
ini.

Gambar 73. Tampilan Dashboard Terisi Dengan Data dan Status Persimpangan Aktif

3. Uji Coba Sistem Layanan Pengaduan Masyarakat


Uji coba dilakukan dengan membuat laporan aduan menggunakan aplikasi Android
E-Complaint.

Gambar 74. Uji Coba Pengaduan Persimpangan Yang Bermasalah

72
Sesaat setelah laporan dikirim, dalam hitungan detik petugas dishub atau kepolisian
langsung menerima sms notifikasi

Gambar 75. Tampilan Notifikasi SMS dari SMS Gateway Tentang Detil Aduan

4. Uji Coba Sistem Layanan Penyebaran Data


Uji coba dilakukan dengan menguji API yang telah dibangun apakah dapat
memberikan http response (200) dan menghasilkan data JSON.
• Uji coba menggunakan aplikasi postman

Gambar 76. Uji Coba API Dengan Menggunakan Aplikasi Postman

73
• Uji coba menggunakan browser

Gambar 77. Uji Coba API Dengan Menggunakan Browser


• Uji coba keamanan, disimulasikan mencoba mengakses api tanpa menggunakan
token, terlihat hasilnya akses ditolak.

Gambar 78. Uji Coba Keamanan API

Untuk video simulasi pengujian, dapat dilihat pada tautan berikut


https://www.youtube.com/watch?v=I1EvtCFP0Wk

74
BAB VI PENUTUP
7

7.1 Kesimpulan
Dari serangkaian kegiatan penelitian yang dilakukan dari mulai tahapan identifikasi hingga
pengujicobaan service, diperoleh beberapa kesimpulan sebagai berikut:
1. Penggunaan service system engineering (SSE) framework terbukti dapat
menghasilkan rancangan sistem dan simulasi produk pengaturan APILL yang
terstruktur dan sistematis
2. Hasil pengujian simulasi produk pengaturan APILL berjalan sesuai skenario yang
telah dirancang.
3. Kombinasi penerapan ilmu elektronika dan ilmu rekayasa perangkat lunak dengan
konsep layanan terbukti menghasilkan produk tepat guna yang tidak bergantung pada
bahasa pemrograman tertentu
4. Pemilihan sensor obstacle dan ultrasonic terbukti dapat mendeteksi pergerakan
kendaraan yang menjadi parameter utama dalam pengaturan apill
5. Penerapan layanan aduan, notifikasi dan monitoring dalam ruang lingkup simulasi
terbukti dapat menjadi masukan bagi stakeholder dalam meningkatkan pelayanan lalu
lintas.

7.2 Saran
Saran yang dapat diberikan untuk pengembangan sistem layanan di masa depan adalah:
1. Untuk peneliti selanjutnya yang akan melakukan kajian yang sama, dapat
menambahkan fitur lainnya atau penggunaan sensor yang berbeda demi mendapatkan
sistem layanan yang lebih baik.
2. Untuk stakeholder agar dapat mempertimbangkan penggunaan sistem layanan di
dalam kebutuhan pengaturan lalu lintas agar manfaat penelitian dapat dirasakan oleh
masyarakat

75
DAFTAR PUSTAKA

Bang, K. L. (1997). Manual Kapasitas Jalan Indonesia. Indonesia: Direktorat Jenderal Bina
Marga.
Irlinawati. (2008). Pengkajian Kinerja Persimpangan Pada Simpang Empat Jalan Pangeran
Antasari, Jalan Gajah Mada, Dan Jalan Hayam Wuruk. Fakultas Teknik. Universitas
Lampung.
Suhardi, Kurniawan, N. B., Sembiring, J., & Yustianto, P. (2017). Service Systems Engineering
Framework Based on Combining Service Engineering and Systems Engineering
Methodologies.
Tamin, O. Z. (2000). Perencanaan dan Permodelan Transportasi. Bandung: Penerbit ITB.
Undang-Undang Republik Indonesia Tentang Lalu Lintas dan Angkutan Jalan, No.22 (2009).

76

Anda mungkin juga menyukai