Apa dampak historis dari Penerbangan 501 Ariane 5?


9

Disintegrasi roket Ariane 5 37 detik setelah diluncurkan pada perjalanan perdananya ( Penerbangan 501 ) biasanya disebut sebagai salah satu bug perangkat lunak paling mahal dalam sejarah 1 :

Butuh Badan Antariksa Eropa 10 tahun dan $ 7 miliar untuk menghasilkan Ariane 5, roket raksasa yang mampu melemparkan sepasang satelit tiga ton ke orbit dengan setiap peluncuran dan dimaksudkan untuk memberi Eropa supremasi luar biasa dalam bisnis luar angkasa komersial.

Yang diperlukan untuk meledakkan roket itu kurang dari satu menit dalam pelayaran perdananya Juni lalu, menyebarkan puing-puing berapi-api di rawa-rawa bakau di Guyana Prancis, adalah sebuah program komputer kecil yang mencoba memasukkan angka 64-bit ke dalam ruang 16-bit.

Satu bug, satu crash. Dari semua baris kode ceroboh yang dicatat dalam catatan sejarah ilmu komputer, yang satu ini mungkin berdiri sebagai yang paling efisien. Dari wawancara dengan para ahli peroketan dan analisis yang disiapkan untuk badan antariksa, jalan yang jelas dari kesalahan aritmatika ke penghancuran total muncul.

Perubahan besar apa yang gagal pada Penerbangan 501 dan investigasi selanjutnya menginspirasi penelitian sistem kritis keselamatan dan pengujian perangkat lunak?

Saya tidak mencari penjelasan tentang bug itu sendiri, tetapi untuk penjelasan tentang dampak historis dari bug tersebut, dalam hal penelitian yang diilhami dari atau yang terkait langsung dengan penyelidikan kegagalan. Sebagai contoh makalah ini menyimpulkan:

Kami telah menggunakan analisis statis untuk:

  • periksa inisialisasi variabel,
  • memberikan daftar lengkap dari konflik akses data potensial untuk variabel bersama,
  • secara lengkap daftar potensi galat run time dari semantik Ada.

Sepengetahuan kami ini adalah pertama kalinya teknik analisis statis berbasis boolean dan non-boolean digunakan untuk memvalidasi program industri.

Demikian pula, makalah ini (pdf) mencatat:

Analisis program statis berbasis interpretasi abstrak telah digunakan untuk analisis statis perangkat lunak ADA tertanam pada peluncur Ariane 5 dan ARD. Penganalisa program statis bertujuan untuk deteksi otomatis dari kekurangan, potensi, ketidakmungkinan atau tidak dapat diaksesnya kesalahan run-time seperti aliran skalar dan titik-mengambang, kesalahan susunan indeks, pembagian dengan nol dan pengecualian aritmatika terkait, variabel tidak diinisialisasi, data balapan aktif struktur data bersama, dll. Alat analisis ini dapat secara otomatis menemukan kesalahan penerbangan Ariane 501. Analisis statis dari perangkat lunak keselamatan penting tertanam (seperti perangkat lunak avionik) sangat menjanjikan .

Saya ingin penjelasan menyeluruh tentang dampak peristiwa tunggal ini terhadap pendekatan dan perangkat pengujian perangkat lunak.

1 Angka $ 7 miliar mungkin merujuk pada total biaya proyek Ariane 5, Wikipedia melaporkan bahwa kegagalan tersebut mengakibatkan kerugian lebih dari $ 370 juta. Masih kegagalan yang cukup mahal tetapi jauh dari angka $ 7 miliar.


5
Tentukan "terburuk" ... Terburuk karena harganya mahal? Saya tidak tahu ... Saya pikir Therac-25 akan menjadi bug yang jauh lebih buruk jika Anda adalah salah satu dari orang-orang yang mengalami overdosis radiasi yang besar selama perawatan kanker. users.csc.calpoly.edu/~jdalbey/SWE/Papers/THERAC25.html ; courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html ; en.wikipedia.org/wiki/Therac-25
FrustratedWithFormsDesigner

2
@FrustratedWithFormsDesigner Menjawab pertanyaan Anda sendiri sangat dapat diterima , kami bahkan mendapat fitur baru - baru ini yang mendorong jawaban sendiri. Saya akan menguji drive untuk pertanyaan ini, namun mengingat ini adalah pertanyaan kontes (bukan karena ada peluang) saya memutuskan untuk membiarkan orang lain menjawabnya.
yannis

3
Apakah kita benar-benar ingin memastikan bahwa pertanyaan didaktik ada dalam ruang lingkup? Jika demikian, saya dapat melihat gelombang pertanyaan yang agak mengganggu yang dimaksudkan untuk membawa kita ke suatu tempat dan mengajarkan kita sesuatu tanpa OP benar-benar membutuhkan jawaban. Terserah Anda, tetapi tampaknya berisiko.
Corbin

4
@gnat Tidak pernah mengatakan itu adalah satu - satunya jawaban, hanya sebuah petunjuk bahwa pertanyaan itu memiliki jawaban untuk menenangkan pemilih yang dekat. Tapi di sini Anda pergi: articles.adsabs.harvard.edu//full/1998ESASP.422..201L/... & dl.acm.org/citation.cfm?id=263750 (ACM paywall)
yannis

3
@FrustratedWithFormsDesigner: Kadang-kadang saya memiliki pertanyaan yang saya pikir saya tahu jawabannya, tetapi saya tidak yakin. Jadi saya ingin bertanya kepada mereka, bukan untuk membuat tesis saya dikonfirmasi, tetapi lebih terbuka untuk semua jenis jawaban yang akan saya dapatkan. Jadi, secara umum, saya pikir masuk akal untuk mengajukan pertanyaan bahkan jika saya sudah memiliki beberapa ide mengenai kemungkinan jawaban.
Giorgio

Jawaban:


5

Secara teknis, ini lebih merupakan " pembusukan perangkat lunak ". Perangkat lunak kontrol penerbangan didaur ulang dari roket Ariane 4 sebelumnya, sebuah langkah yang masuk akal mengingat betapa mahalnya untuk mengembangkan perangkat lunak, terutama ketika itu perangkat lunak misi penting yang harus diuji dan diverifikasi dengan standar yang jauh lebih ketat daripada kebanyakan perangkat lunak komersial.

Sayangnya, tidak ada yang peduli untuk menguji apa dampak perubahan dalam lingkungan operasi, atau jika mereka melakukannya mereka tidak melakukan pengujian dengan standar yang cukup menyeluruh.

Perangkat lunak ini dibangun untuk mengharapkan parameter tertentu tidak pernah melebihi nilai-nilai tertentu (dorong, akselerasi, tingkat konsumsi bahan bakar, tingkat getaran, dll). Dalam penerbangan normal pada Ariane 4 ini bukan masalah karena parameter-parameter itu tidak akan pernah mencapai nilai yang tidak valid tanpa ada sesuatu yang secara spektakuler salah. The Ariane 5, bagaimanapun, jauh lebih kuat dan rentang yang tampaknya konyol pada 4 bisa dengan mudah terjadi pada 5.

Saya tidak yakin parameter apa yang keluar dari jangkauan (mungkin akselerasi, saya harus memeriksa), tetapi ketika itu terjadi, perangkat lunak tidak dapat mengatasi dan mengalami limpahan aritmatika yang telah ada tidak cukup memeriksa kesalahan dan kode pemulihan diimplementasikan. Komputer pemandu mulai mengirim sampah ke gimbal nosel mesin, yang kemudian mulai menunjuk nosel mesin secara acak. Roket mulai runtuh dan hancur, dan sistem penghancuran diri otomatis mendeteksi roket itu sekarang dalam sikap yang tidak dapat diperbaiki dan menyelesaikan pekerjaan.

Sejujurnya, kejadian ini mungkin tidak mengajarkan pelajaran baru, karena jenis masalah telah digali sebelumnya dalam semua jenis sistem, dan sudah ada strategi untuk menangani menemukan dan memperbaiki kesalahan. Apa yang dilakukan oleh insiden itu adalah merampas titik bahwa kelonggaran dalam mengikuti strategi-strategi itu dapat memiliki konsekuensi yang sangat besar, dalam hal ini jutaan dolar perangkat keras yang hancur, beberapa pelanggan sangat kesal dan buruknya reputasi Arianespace.

Kasus khusus ini sangat mencolok karena jalan pintas yang diambil untuk menghemat uang berakhir dengan biaya yang sangat besar, baik dari segi uang dan kehilangan reputasi. Jika perangkat lunak telah diuji sama kuatnya di lingkungan simulasi Ariane 5 seperti ketika pada awalnya dikembangkan untuk Ariane 4, kesalahan pasti akan terungkap jauh sebelum perangkat lunak diinstal pada perangkat keras peluncuran dan dimasukkan ke dalam perintah penerbangan yang sebenarnya. Selain itu, jika seorang pengembang perangkat lunak sengaja melemparkan beberapa masukan yang tidak masuk akal ke dalam perangkat lunak maka kesalahan itu mungkin bahkan tertangkap di era Ariane 4, karena itu akan menyoroti fakta bahwa pemulihan kesalahan yang ada tidak memadai.

Jadi singkatnya, itu tidak benar-benar mengajarkan pelajaran baru, tetapi menabrak bahaya dari tidak mengingat yang lama. Ini juga menunjukkan bahwa lingkungan di mana sistem perangkat lunak beroperasi sama pentingnya dengan perangkat lunak itu sendiri. Hanya karena perangkat lunak ini benar untuk lingkungan X, tidak berarti itu cocok untuk tujuan di lingkungan yang sama tetapi berbeda Y. Akhirnya ia menyoroti betapa pentingnya untuk perangkat lunak misi kritis untuk menjadi cukup kuat untuk menghadapi keadaan yang tidak seharusnya terjadi. terjadi.

Bandingkan penerbangan 501 dengan Apollo 11 dan masalah komputernya. Sementara perangkat lunak LGC menderita kesalahan serius selama pendaratan, itu dirancang untuk menjadi sangat kuat dan mampu tetap dalam keadaan operasional terlepas dari alarm perangkat lunak yang dipicu, tanpa menempatkan astronot dalam bahaya dan masih dapat menyelesaikan misinya.


6
Referensi....?
FrustratedWithFormsDesigner

2
Kenangan saya sendiri tentang kuliah etika teknik ketika belajar ilmu komputer di universitas :)
GordonM

Jika saya ingat dengan benar, masalah itu disebabkan oleh menghilangkan beberapa pernyataan di tempat yang dianggap oke untuk Ariane 4, karena komputernya (navigasi inersia) akan kelebihan beban seandainya pernyataan tersebut ditampilkan. Ariane 5 memiliki komputer yang jauh lebih kuat untuk melakukan pekerjaan yang akan menangani pernyataan dengan mudah, tetapi mereka belum diaktifkan kembali.
Pavel

1

Itu sebagian besar masalah penggunaan kembali dan masalah manajemen dan bukan yang coding. Dari ingatan saya (saya mungkin mendapatkan beberapa hal salah) dari laporan.

  • satu subsistem telah dirancang untuk Ariane IV. Lintasan Ariane IV tidak dapat menghasilkan luapan dan kemudian dengan sengaja memutuskan bahwa jika itu terjadi, itu adalah masalah perangkat keras dan mematikan subsistem dan pergi ke cadangan adalah hal yang tepat untuk dilakukan.

  • untuk Ariane V, diputuskan untuk menggunakan kembali subsistem itu dan tidak meninjau asumsi dan kode tetapi mengandalkan pengujian.

  • selanjutnya diputuskan untuk membatalkan pengujian penuh.

Parameter penerbangan yang berbeda dari Ariane V membuat overflow terjadi. Matikan primer. Matikan cadangannya. Autodestruction.

Hal-hal tambahan yang saya ingat:

  • subsistem pada saat meluap tidak lagi berguna. Orang bisa berpendapat bahwa kegagalannya seharusnya tidak memicu autodestruction. (Di sisi lain, kompleksitas yang ditambahkan itu sendiri bisa menjadi sumber masalah).

  • ada data debug yang dikirim ke bus padahal seharusnya tidak. Saya tidak ingat yang spesifik.


Ah, saya tahu apa bug itu, itu bukan pertanyaan saya. Saya sering mendengar bahwa bug tersebut mengubah pendekatan kami terhadap pengujian perangkat lunak, dan itulah yang saya tanyakan.
yannis


ISTR mekanisme di balik kegagalan itu adalah bahwa kode itu melemparkan pengecualian meluap, yang tidak ditangkap oleh penelepon. Pengecualian diperbanyak hingga ditangkap oleh pengendali pengecualian default, yang membatalkan modul yang menyinggung. Namun, karena pengecualian telah merembes ke banyak tingkatan, "modul menyinggung" pada saat itu adalah seluruh RSI (sistem referensi inersia).
TMN

0

Seperti yang disebutkan orang lain, hal itu menyebabkan industri pada umumnya memeriksa kembali konsep penggunaan kembali, dan menempatkannya dalam kerangka referensi yang lebih besar di mana komponen tidak dievaluasi secara terpisah tetapi dalam konteks keseluruhan sistem. Ini secara signifikan mengurangi daya tarik penggunaan ulang, karena bahkan jika suatu komponen dapat digunakan kembali tanpa perubahan, masih harus dianalisis dengan seperangkat asumsi baru. Akibat lainnya adalah bahwa perangkat keras cadangan yang menjalankan perangkat lunak yang sama hampir tidak menarik, karena sebagian besar perangkat keras modern adalah urutan besarnya lebih dapat diandalkan daripada perangkat lunak modern. Saya telah mendengar bahwa beberapa kontrak pertahanan memerlukan dua sistem perangkat lunak terpisah yang dikembangkan oleh tim yang berbeda menggunakan teknologi berbeda yang bekerja dari spesifikasi yang sama untuk memverifikasi implementasi yang tepat.


2
Referensi silakan ...
yannis

1
Sebagian besar dikenang dari artikel ACM lama, tetapi beberapa informasi lebih lanjut ada di sini .
TMN

Ide-ide komputer yang terpisah, dengan kode yang dikembangkan oleh tim yang berbeda digunakan oleh program pesawat ulang-alik, dan mungkin bahkan lebih awal.
mhoran_psprep

@ mhoran_psprep: Baca tentang kegagalan AT&T Exchange dan hasilnya. Maaf - tidak ada referensi, ketahuilah dari memori.
mattnz
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.