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)
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
• Mendapatkan hasil uji rancangan sistem layanan optimalisasi pengaturan APILL
otomatis dan penanganan aduan lalu lintas melalui pendekatan prototipe dan simulasi.
2
1.4 Rancangan Arsitektur
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.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.
8
Gambar 4. Pemasangan Sensor ke Sirkuit 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.
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.
11
ke piezoelektrik dan terjadi reaksi mekanik sehingga bergetar dan memancarkan
gelombang yang sesuai dengan besar frekuensi pada osilator
3. Receiver
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
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() {
13
pinMode (echo, INPUT); //echo sebagai input
}
void loop() {
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.
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.
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
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.
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.
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).
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.
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.
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.
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.
- 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.
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.
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
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
Lampu Lalu -
Lintas,
Persimpangan
31
Cost Structure : Revenue Stream :
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.
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 :
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.
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.
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
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.
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.
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
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.
39
Daftar kebutuhan fungsional dari sistem deteksi banjir dimuat pada tabel
berikut.
40
Layanan Monitoring Lalu Lintas
41
Layanan Penyebaran Data
42
Layanan Monitoring Lalu Lintas
43
Layanan Penyebaran Data
44
Layanan Monitoring Lalu Lintas
45
Layanan Penyebaran Data
46
Layanan Pengaturan APILL
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
48
Penanganan set_aduan_status id_aduan: int none
langsung di
lapangan
49
Penanganan set_aduan_status id_aduan: status: boolean
langsung di int
lapangan
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
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
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
52
Pemodelan pertama adalah dengan service interface diagram. Berikut disajikan
pada gambar service interface diagram yang ada pada sistem layanan yang dibangun.
54
Gambar 38. Penyebaran Data Sequence Diagram
55
5.3.3 Service Participants
56
Gambar 42. Service Contract Notifikasi
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
Gambar 47. Rancangan Desain PCB Traffic Light dengan PCB Express
59
• Hasil Design kemudian dicetak dan dirakit seperti gambar dibawah ini
60
• Pembuatan Script untuk pengiriman data dari Mikrokontroler ke Database
Menggunakan Arduino IDE
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)
63
Gambar 57. Panel Aduan Masyarakat Berisikan Identitas Aduan
64
3. Prototype Sistem Layanan Pengaduan Masyarakat berbasi Android menggunakan
Android Studio
• Potongan Script Koneksi API Server Aplikasi Android
65
• User Interface Sistem Layanan Pengaduan Masyarakat
66
Gambar 65. Contoh Kasus Pemilihan Jenis Aduan
67
• Screenshot notifikasi bentuk SMS Gateway
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
69
• Contoh Script Sistem Layanan Penyebaran Data
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 :
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
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
73
• Uji coba menggunakan browser
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