Kegagalan Perangkat Lunak (Uber Self-Driving Cars)

 

Kegagalan Perangkat Lunak Uber

(Uber Self-Driving Cars)

 

Dalam kehidupan sehari-hari, tentunya kita memerlukan transportasi untuk berpindah dari suatu tempat ke tempat yang lebih jauh. Selain menggunakan kendaraan pribadi, biasanya kita akan menggunakan transportasi umum. Pada era sekarang ketika teknologi informasi berkembang dengan pesat, banyak bisnis transportasi umum berbasis online yang bermunculan. Salah satunya adalah Uber. Uber adalah perusahaan jaringan transportasi asal San Francisco, California yang menciptakan aplikasi penyedia transportasi yang menghubungkan penumpang dengan sopir kendaraan sewaan. Perusahaan ini pernah menjajal pasar Indonesia, namun hal itu tak mampu bertahan lama karena kalah bersaing dengan moda transportasi online lainnya.

Selama Uber beroperasi di berbagai negara, ternyata sering terjadi banyak masalah dan kendala menyangkut dengan software yang mereka buat. Kesalahan atau kegagalan software yang dihadapi misalnya masalah beban tarif yang kacau pada kartu kredit penumpang yang tak hanya terjadi pada satu negara. Pengguna di wilayah luar Indonesia hanya dapat menggunakan moda ini dengan pembayaran menggunakan kartu kredit atau debit (non tunai). Pada saat mereka selesai perjalanan, tagihan tersebut akan masuk ke dalam tagihan kartu kreditnya. Beberapa kasus menyebutkan bahwa tarif yang dibebankan melonjak sangat tinggi sehingga mereka mendapatkan tagihan hingga ratusan juta atas nama akun Ubernya. Uber sempat menyangkal peristiwa tersebut merupakah ulah peretas namun nyatanya software mereka yang bermasalah. Menanggapi hal ini, telah dilakukan perbaikan dan pengembalian tarif ke normal.

Tak hanya itu, dalam melakukan sebuah inovasi baru, Uber sempat mengalami kegagalan. Inovasi tersebut adalah “Uber Self-Driving Cars” dimana layanan ini menggantikan pengemudi manusia dengan program. Mobil yang digunakan mempunyai 20 kamera, 7 laser, GPS, radar, dan LIDAR, sebuah teknologi yang dapat mengukur jarak yang telah didapatkan oleh laser sehingga mobil dapat “melihat” dan menginterpretasikan aksi di sekitar mereka.

Karena merasa yakin dengan apa yang dibuatnya, pengujian pun dilakukan. Pada pengujian tahun 2017, mobil ini mendapatkan banyak pelanggaran lalu lintas dan kecelakaan kecil. Pada Maret 2018, pengujian tersebut akhirnya berujung fatal. Sebuah mobil self-driving milik Uber di Tempe, Arizona menabrak seorang pejalan kaki yang berjalan menyebrang di malam hari. Pejalan kaki itu mengalami luka yang serius sehingga dibawa ke rumah sakit. Namun tak lama, korban tersebut meninggal. Mobil berada dalam mode otonom pada saat kecelakaan. Meskipun ada operator manusia di kursi pengemudi, orang tersebut tidak dapat mengendalikan kendaraan ketika kecelakaan terjadi. Segera setelah kecelakaan fatal itu, Uber telah menangguhkan tes mengemudinya di jalanan umum.

Pada Mei 2018, NTSB (National Transportation Safety Board) dari Amerika menerbitkan laporan tentang kasus tersebut. Laporan itu menjelaskan bahwa perangkat lunak yang ada ditulis dengan buruk. Seperti kebanyakan program self-driving lainnya, software milik Uber mencoba untuk mengklasifikasikan setiap objek yang terdeteksi seperti mobil, sepeda, atau lainnya. Kemudian, berdasarkan klasifikasi ini, perangkat lunak akan menghitung kecepatan dan kemungkinan lintasan untuk objek. Namun sistem ternyata gagal melakukannya. Pada laporan NTSB tertulis timeline detik demi detik yang menunjukkan apa yang “dipikirkan” perangkat lunak tersebut sebelum menabrak korban. Timeline tertulis sebagai berikut.

·      5,2 detik sebelum tumbukan, sistem mengklasifikasikannya sebagai objek “lain” dan memutuskan bahwa ia “statis” atau tidak bergerak sehingga tidak mungkin jika objek melakukan perjalanan ke jalur mobil.

·      4,2 detik sebelum tumbukan, ia direklasifikasi sebagai “kendaraan” dan sistem mengakui bahwa korban bergerak tetapi memperkirakan dia akan tetap berada di jalurnya saat itu.

·      Antara 3,8 sampai 2,7 detik sebelum tumbukan, klasifikasi berganti beberapa kali menjadi “kendaraan” dan “lainnya”.

·      2,6 detik sebelum tumbukan, sistem mengklasifikasikan korban beserta sepedanya menjadi “sepeda” dan sistem kembali meramalkan bahwa dirinya tetap berada di jalurnya.

·      1,5 detik sebelum tumbukan, pernyataan tersebut berubah menjadi “tidak dikenal”.

·      1,2 detik sebelum tumbukan, berubah kembali menjadi “sepeda” ketika objek memasuki jalur SUV dan sistem menyadari kecelakaan sudah dekat

Terdapat dua hal yang patut diperhatikan tentang urutan kejadian tersebut. Pertama, sistem ini tidak mengklasifikan korban sebagai “pejalan kaki”. Menurut NTSB, hal itu terjadi karena desain sistem tidak memiliki pertimbangan untuk pejalan kaki yang sedang berjalan. Kedua, klasifikasi yang berpindah terus menerus mencegah perangkat lunak Uber menghitung secara akurat lintasan objek. Mungkin kita berpikir bahwa sistem mengemudi sendiri saat melihat suatu benda bergerak ke jalurnya, maka mobil akan melakukan pengereman bahkan jika sistem tidak yakin benda apa yang sedang dihadapinya. Namun hal itu bukan merupakan cara kerja perangkat lunak Uber.

Cara kerja sistem ini menggunakan lokasi objek yang diamati sebelumnya untuk membantu menghitung kemacetan dan prediksi jalur yang ada di depannya. Namun jika sistem persepsi mengubah klasifikasi yang terdeteksi, riwayat pelacakan tidak lagi dipertimbangkan saat membuat lintasan baru. Dengan demikian dapat dikatakan bahwa pada kasus ini, sistem tidak dapat menentukan objek apa yang dihadapi dan bertindak seolah-olah objek tersebut tidak bergerak (benda mati). Berdasarkan timeline sebelumnya, disebutkan hanya pada 1,2 detik sebelum kecelakaan, sistem menyadari kecelakaan sudah dekat. Pada titik ini, mungkin sudah terlambat untuk menghindari tabrakan. Menurut NTSB, kendaraan tersebut ternyata tidak mulai melakukan pengereman hingga 0,2 detik sebelum kecelakaan fatal. Hal ini membuat tabrakan jelas tidak dapat dihindari. Untuk menghindari tabrakan, sistem sebenarnya tidak harus mengerem dengan kekuatan penuh tetapi menerapkan gaya pengereman yang memulai perlambatan kendaraan secara bertahap sembari mengingatkan pengemudi untuk mengambil alih.

Tak lama setelah laporan keluar, Uber mengumumkan bahwa ia mematikan kemampuan mobil untuk membuat keputusan darurat sendiri seperti membanting rem atau membelok keras. Sebenarnya kendaraan milik Uber memiliki sistem Volvo XC90 yang dilengkapi dengan sistem pengereman darurat yang canggih namun sayangnya Uber menonaktifkan sistem pencegahan tersebut sesaat teknologi miliknya sendiri aktif. Teknologinya sendiri ternyata menggunakan beberapa frekuensi yang sama dengan radar Volvo sehingga menciptakan gangguan tersendiri. Sejak itu pula, Uber telah mendesain ulang radar mereka untuk bekerja pada frekuensi yang berbeda dari radar Volvo dan memungkinkan sistem pengereman darurat Volvo tetap aktif sementara dirinya menguji tenologinya. Tak hanya itu, ia juga telah mendesain ulang aspek lain dari perangkat lunaknya. Perangkat lunak mereka kini tidak akan lagi membuang data lokasi objek sebelumnya ketika klasifikasi objek berubah.

Berdasarkan kasus kegagalan inovasi di atas, dapat dilakukan analisis dengan menggunakan beberapa software quality attributes. Hasil analisisnya dapat dijabarkan sebagai berikut.

1.    Security

Keamanan mencakup kemampuan sistem perangkat lunak untuk melindungi entitas terhadap serangan dan penyalahgunaan, serta untuk melindungi akses ke sumber daya. Beberapa aspek yang menyangkut keamanan, yaitu:

-          Accountability: menyangkut kewajiban untuk menanggung konsekuensi atas kegagalan.

Berdasarkan kasus tersebut, Uber sudah melakukan kewajiban pertanggungjawaban untuk memperbaiki software nya, mulai dari mematikan kemampuan mobil untuk membuat keputusan sendiri, mendesain ulang radar, dan mendesain ulang aspek lain dari perangkat lunaknya.

-          Auditability/Traceability: kemampuan layanan untuk dipantau dan menghasilkan jejak audit dimana auditnya adalah urutan peristiwa yang dapat direkonstruksi dan diperiksa. Berdarkan kasus tersebut, software milik Uber sudah menghasilkan jejak audit sehingga NTSB dapat memberikan timeline detik-detik sebelum tabrakan terjadi sehingga dapat dianalisis penyebab terjadinya kecelakaan.

-          Integrity: kemampuan untuk memastikan bahwa sistem dan datanya tidak rusak.

Berdasarkan kasus tersebut, Uber dinilai kurang karena sistem ternyata belum sempurna dan masih butuh beberapa perbaikan. Selain itu, sistem tak mampu memberikan peringatan kepada pengemudi untuk mengambil alih kendali ketika sistem bermode otonom sehingga pengemudi tidak mengetahui adanya kegagalan dari sistem.

-          Safety: kemampuan untuk beroperasi tanpa resiko cedera atau bahaya bagi pengguna dan lingkungan di sekitar sistem.

Berdasarkan kasus tersebut, safety dari software ini jelas kurang karena ia tak mampu mengenali sebuah objek hingga terjadi tabrakan yang berakibat fatal.

2.    Performance

Hal ini mencakup kualitas dari kinerja software. Beberapa aspek menyangkut keamanan, yaitu:

-          Throughput: mengacu pada jumlah peristiwa yang ditangani selama suatu interval.

Berdasarkan kasus tersebut, sebenarnya dalam suatu interval (beberapa detik) kemampuan mendeteksi objek dapat beberapa kali berganti yang berarti troughput nya sudah baik, hanya saja kesalahan klasifikasi membuat hal ini menjadi kurang baik.

-          Response Time: waktu yang berlalu ketika layanan menyelesaikan satu transaksi lengkap.

Berdasarkan kasus tersebut, waktu respon berubah-ubah untuk mendeteksi objek. Namun untuk mengklasifikasikannya menjadi yang mendekati, yakni sepeda dan menyakini objek tersebut tidak statis, membutuhkan waktu sekitar 4 detik (5,2 detik – 1,2 detik) sejak pendeteksian awal.

3.    Modifiability

Hal ini menyangkut biaya untuk melakukan perubahan.

Berdasarkan kasus tersebut, terlihat bahwa Uber melakukan beberapa perubahan besar. Setelah perubahan ditentukan, harus dilakukan implementasi, diuji, dan digunakan. Semua tindakan ini membutuhkan waktu dan uang yang sebenarnya dapat terukur. Dilihat dari beberapa perubahan yang dilakukan, dapat dibayangkan bahwa Uber tidak mengeluarkan uang yang sedikit untuk memperbaiki sistem tersebut (mulai dari perbaikan sistem radar, penyewaan radar Volvo, dan pengubahan aspek di software nya).

4.    Availability

Hal ini berkaitan dengan keandalan aplikasi beserta kegagalan sistem dan konsekuensi yang terkait. Kegagalan sistem terjadi ketika sistem tidak lagi memberikan layanan yang konsisten dengan spesifikasinya. Berdasarkan kasus tersebut, software tersebut sebenarnya selalu tersedia untuk digunakan saat dibutuhkan namun dirinya mengalami kegagalan dalam mengklasifikasi objek tertentu selama 4 detik, melalukan penundaan keputusan selama 1 detik, hingga pada waktu 0,2 detik akhirnya mengambil keputusan untuk melakukan pengereman secara kekuatan penuh, namun pada akhirnya kecelakaan tidak dapat dihindari.

Setelah dianalisis dapat diberikan kesimpulan bahwa software milik Uber ini sebenarnya dapat bermanfaat di masa depan karena mempermudah aktivitas manusia, namun terdapat beberapa masalah yang harus segera diperbaiki demi keselamatan pengemudi, pengguna, maupun orang-orang yang berada di sekitarnya. Sebenarnya dalam menghindari resiko kegagalan perangkat lunak, diperlukan perhatian penuh akan analisis software quality attributes secara lengkap. Dengan menganalisisnya, developer dapat melakukan perbaikan sedini mungkin dan membuat strategi penyelesaian yang cepat jika terjadi kesalahan di kemudian hari.

 

REFERENSI

Lee, Timothy B., 2019. How Terrible Software Design Decision Led to Uber’s Deadly 2018 Crash. Dikutip dari https://arstechnica.com/cars/2019/11/how-terrible-software-design-decisions-led-to-ubers-deadly-2018-crash/ pada 29 Februari 2020 pukul 14.17 WIB.

Lenthang, Marlene. 2019. Uber’s self-driving car in Arizona crash that killed a pedestrian last year had the emergency brakes disabled and couldn’t detect jaywalkers, report reveals. Dikutip dari https://www.dailymail.co.uk/news/article-7653911/U-S-agency-finds-flaws-Uber-self-driving-software-tallies-prior-crashes.html pada 29 Februari 2020 pukul 14.42 WIB.