Ariane 5'in 501 numaralı uçağının tarihsel etkisi neydi?

Ariane 5 roketinin ilk seferinde ( Flight 501 ) fırlatılmasından 37 saniye sonra dağılması genellikle tarih ^1'deki en pahalı yazılım hatalarından biri olarak adlandırılır :

Avrupa Uzay Ajansı'nın, her lansmanda bir çift üç ton uyduyu yörüngeye çekebilecek ve Avrupa'ya ticari alan işinde ezici üstünlük sağlamayı amaçlayan dev bir roket olan Ariane 5'i üretmek 10 yıl 7 milyar dolar aldı.

Fransız Guyanası'nın mangrov bataklıklarına ateşli molozu dağıtarak, bu roketi bir dakikadan az bir süre önce ilk yolculuğuna patlatmak için gereken tek şey, 64 bitlik bir sayıyı 16 bitlik bir alana doldurmaya çalışan küçük bir bilgisayar programıydı.

Bir hata, bir çökme. Bilgisayar biliminin yıllıklarında kaydedilen tüm dikkatsiz kod satırlarından, bu en yıkıcı derecede verimli olabilir. Roket uzmanlarıyla yapılan görüşmelerden ve uzay ajansı için hazırlanan bir analizden aritmetik bir hatadan toplam yıkıma kadar açık bir yol ortaya çıkıyor.

Flight'ın 501 başarısızlığı ve müteakip araştırmalar, güvenlik açısından kritik sistemlerin ve yazılım testlerinin araştırılmasına ne gibi değişiklikler yaptı?

Hatanın kendisinin bir açıklamasını değil, hatanın tarihsel etkisinin, arızanın araştırılmasından / ilhamlarından ilham alan veya doğrudan ilgili olan araştırma açısından bir açıklama arıyorum. Örneğin bu makale şu sonuca varmıştır:

Statik analizi şu amaçlarla kullandık:

• değişkenlerin başlatılmasını kontrol edin,
• paylaşılan değişkenler için potansiyel veri erişimi çakışmalarının kapsamlı listesini sağlamak,
• Ada semantiğinden olası çalışma süresi hatalarını kapsamlı olarak listeler.

Bildiğimiz kadarıyla bu, endüstriyel programları doğrulamak için ilk kez boole tabanlı ve boole tabanlı olmayan statik analiz teknikleri kullanılır.

Benzer şekilde, bu makale ^(pdf) şunları not eder:

Ariane 5 başlatıcısı ve ARD'nin gömülü ADA yazılımının statik analizi için soyut yoruma dayalı statik program analizleri kullanılmıştır. Statik program analizörü, skaler ve dolum noktası üstleri, dizi indeksi hataları, sıfıra bölme ve ilgili aritmetik istisnalar, başlatılmamış değişkenler, analizör Ariane 501 uzunluk hatasını otomatik olarak bulabildi. Gömülü güvenlik açısından kritik yazılımların (aviyonik yazılım gibi) statik analizi çok umut vericidir .

Bu tek olayın yazılım test yaklaşımları ve araçları üzerindeki etkisinin tam bir açıklamasını isterim.

_{¹ 7 milyar dolarlık rakam muhtemelen Ariane 5 projesinin toplam maliyetini ifade ediyor, Wikipedia başarısızlığın 370 milyon dolardan fazla bir kayıpla sonuçlandığını bildirdi. Hala oldukça pahalı bir başarısızlık ama hiçbir yerde 7 milyar dolar rakamı.}

Teknik olarak konuşursak, daha çok bir " yazılım çürümesi " vakasıydı . Uçuş kontrol yazılımı, yazılım geliştirmenin ne kadar pahalı olduğu göz önüne alındığında, özellikle ticari yazılımların çoğunun olması gerekenden çok daha sıkı standartlara göre test edilmesi ve doğrulanması gereken kritik bir yazılım olan Ariane 4 roketinden geri dönüştürüldü.

Ne yazık ki, hiç kimse çalışma ortamındaki değişimin ne gibi bir etkisi olacağını test etmekten rahatsız olmadı ya da yaptılarsa, yeterince kapsamlı bir standarda göre test yapmadılar.

Yazılım, belirli parametrelerin hiçbir zaman belirli değerleri (itme, hızlanma, yakıt tüketim oranları, titreşim seviyeleri, vb.) Aşmamasını sağlamak için oluşturulmuştur. Ariane 4'teki normal uçuşta bu bir problem değildi, çünkü bu parametreler zaten yanlış bir şey olmadan geçersiz değerlere asla ulaşmayacaktı. Bununla birlikte, Ariane 5 çok daha güçlü ve 4'te aptalca görünen aralıklar 5'te oldukça kolay olabilir.

Hangi parametrenin aralık dışında kaldığından emin değilim (hızlanma olabilir, kontrol etmek zorunda kalacağım), ancak yapıldığında, yazılım başa çıkamadı ve aritmetik bir taşma yaşadı. yetersiz hata kontrolü ve kurtarma kodu uygulandı. Yönlendirme bilgisayarı, motor memesi gimballerine çöp göndermeye başladı ve bu da motor memesini hemen hemen rasgele işaret etmeye başladı. Roket devrilmeye ve parçalanmaya başladı ve otomatik kendini imha sistemi roketin artık güvensiz kurtarılamaz bir tavırda olduğunu tespit etti ve işi bitirdi.

Dürüst olmak gerekirse, bu olay muhtemelen yeni dersler vermedi, çünkü daha önce her türlü sistemde bir tür problemler ortaya çıkarıldı ve hataların bulunması ve düzeltilmesi ile ilgili stratejiler zaten var. Olayın yaptığı şey, bu stratejileri takip etmede gevşek olmanın muazzam sonuçları olabileceği noktasını, bu durumda milyonlarca dolar tahrip edilmiş donanımı, bazılarını çok kızdıran müşterileri ve Arianespace'in itibarında çirkin bir göçüğü ortaya çıkarmaktı.

Bu özel durum özellikle göze çarpıyordu, çünkü paradan tasarruf etmek için alınan bir kısayol hem para hem de itibar kaybı açısından büyük bir maliyete neden oldu. Yazılım, Ariane 5 simüle edilmiş bir ortamda, Ariane 4 için geliştirildiği zamanki kadar sağlam bir şekilde test edilmiş olsaydı, yazılım başlatma donanımına yüklenip komutunu vermeden önce hata kesinlikle ortaya çıkacaktı. gerçek bir uçuş. Ayrıca, bir yazılım geliştiricisi kasıtlı olarak yazılıma bazı saçma girdiler atarsa, o zaman hatayı Ariane 4 döneminde bile yakalamış olabilir, çünkü mevcut hata kurtarma işleminin yetersiz olduğunu vurgulayacaktır.

Kısacası, gerçekten yeni dersler vermedi, ancak eskilerini hatırlamamanın tehlikelerini eve getirdi. Ayrıca, bir yazılım sisteminin içinde çalıştığı ortamın, yazılımın kendisi kadar önemli olduğunu göstermiştir. Yazılımın X ortamı için doğrulanabilir olması, benzer ama farklı bir ortamda Y amaca uygun olduğu anlamına gelmez. Son olarak, kritik yazılımların, olmaması gereken koşullarla başa çıkacak kadar sağlam olmasının ne kadar önemli olduğunu vurguladı. olmuş.

Apollo 11 ve bilgisayar sorunları ile kontrast uçuş 501. LGC yazılımı iniş sırasında ciddi bir aksaklıktan muzdarip olsa da, astronotları tehlikeye atmadan ve hala yapabilmek için tetiklenen yazılım alarmlarına rağmen son derece sağlam olacak ve operasyonel bir durumda kalabildi. görevini tamamla.

Çoğunlukla bir yeniden kullanım sorunu ve yönetim sorunuydu, kodlama sorunu değildi. Raporumdan (muhtemelen bazı şeyleri yanlış anlıyorum) raporumdan.

• Ariane IV için bir alt sistem tasarlanmıştı. Ariane IV'ün yörüngeleri taşma ile sonuçlanamadı ve daha sonra meydana gelmesi durumunda bir donanım sorunu olduğuna ve alt sistemi kapatmanın ve yedeklemeye gitmenin doğru şey olduğuna karar verildi.

• Ariane V için, bu alt sistemi yeniden kullanmaya ve varsayımları ve kodu incelememeye değil, teste dayanmaya karar verildi.

• ayrıca tam testin düşürülmesine karar verildi.

Ariane V'in farklı uçuş parametreleri taşma meydana getirdi. Birincil olanı kapatın. Yedek parçayı kapatın. Autodestruction.

Hatırladığım ek şeyler:

• taşma anındaki alt sistem artık işe yaramadı. Başarısızlığının oto-yıkımı tetiklememesi gerektiği söylenebilir. (Öte yandan, eklenen karmaşıklığın kendisi de bir sorun kaynağı olabilir).

• yapılmaması gereken bir veri yoluna gönderilen hata ayıklama verileri vardı. Spesifik olanı hatırlamıyorum.

Diğerlerinin de belirttiği gibi, endüstrinin genel olarak yeniden kullanım kavramını yeniden incelemesine ve bileşenlerin tek başına değil tüm sistem bağlamında değerlendirildiği daha geniş bir referans çerçevesine yerleştirmesine neden oldu. Bu, yeniden kullanımın çekiciliğini önemli ölçüde azaltır, çünkü bir bileşen değişiklik yapılmadan tekrar kullanılabilse bile, yine de yeni bir dizi varsayımla analiz edilmesi gerekir. Başka bir sonuç, aynı yazılımı çalıştıran yedek donanımın neredeyse çekici olmadığıdır, çünkü çoğu modern donanım modern yazılımdan daha güvenilir büyüklük emiridir. Bazı savunma sözleşmelerinin, doğru uygulamayı doğrulamak için aynı şartnameden farklı teknolojileri kullanan farklı ekipler tarafından geliştirilen iki ayrı yazılım sistemi gerektirdiğini duydum.