- Ay'a yapılacak mürettebatlı görev aracı Orion'un uçuş bilgisayarı, Apollo dönemi sistemlerine kıyasla dayanıklılık ve otomatik kontrol yetenekleri büyük ölçüde geliştirilmiş bir mimariye sahip olup yaşam desteği, güç ve iletişim gibi tüm kritik işlevleri yönetiyor
- Ay yörüngesinde 250 bin mil uzaklıkta bile kesintisiz çalışabilmesi için, fiziksel ve mantıksal yedeklilik yapıları ile çoklu uçuş bilgisayarları sayesinde donanım arızalarına ve radyasyon etkilerine dayanacak şekilde tasarlandı
- Her Flight Control Module (FCM), kendi kendini doğrulayan işlemci çiftinden oluşuyor; toplam 8 CPU paralel çalışıyor ve fail-silent tasarım ile öncelik tabanlı çıktı seçme algoritması sayesinde hataları izole ediyor
- Sistem, time-triggered Ethernet ve deterministik mimari aracılığıyla tam senkronizasyon durumunu koruyor; üçlü yedekli ağ ve bellek sayesinde tek bitlik hatalar bile otomatik düzeltiliyor
- Tüm ana sistemlerin başarısız olması ihtimaline karşı, bağımsız donanım ve işletim sistemi tabanlı Backup Flight Software kontrolü devralıyor; bu yapı gelecekte otonom sistemler için her zaman aktif dayanıklılık modeli olarak değerlendiriliyor
NASA'nın Artemis II hata toleranslı bilgisayar tasarımı
- Artemis II'nin uçuş bilgisayarı, Apollo dönemi seyrüsefer bilgisayarlarına göre dayanıklılık ve otomatik kontrol yetenekleri açısından büyük ölçüde geliştirilmiş bir yapı sunuyor
- Apollo bilgisayarları 1MHz işlemci ve yaklaşık 4KB bellek kullanıyordu; temel kontrol ise manuel anahtarlar veya röle tabanlıydı
- Artemis II'nin Orion kapsülü, yaşam desteği, güç, iletişim gibi tüm kritik işlevleri doğrudan bilgisayar tarafından yönetiliyor
- Ay yörüngesinde 250 bin mil uzaklıktaki bir görevde yaşanacak arıza telafi edilemeyeceği için sistemin uzay radyasyonu, bit flip ve donanım arızaları karşısında bile kesintisiz çalışması gerekiyor
- NASA, fiziksel yedek kablolama, mantıksal olarak yedekli ağ düzlemleri ve çoklu uçuş bilgisayarlarıyla donanım arızalarına karşı önlem aldı
-
Sekizin Gücü
- Orion, klasik üçlü yedekliliğin (triple redundancy) ötesine geçen bir yapı benimsiyor
- İki adet Vehicle Management Computer (VMC) biriminin her birinde ikişer Flight Control Module (FCM) bulunuyor; toplamda 4 FCM var
- Her FCM, kendi kendini denetleyen (self-checking) bir işlemci çiftinden oluşuyor; böylece toplam 8 CPU uçuş yazılımını paralel olarak çalıştırıyor
- Sistem, fail-silent tasarım temeline dayanıyor; hata oluşan CPU yanlış çıktı üretmek yerine hemen sessiz moda geçiyor
- Çoğunluk oylaması yerine, sağlıklı kanalın çıktısını seçmek için öncelik tabanlı kaynak seçme algoritması kullanılıyor
- NASA, Van Allen radyasyon kuşaklarından geçiş sırasında geçici hatalar bekliyor; en fazla 22 saniye boyunca 3 FCM kaybedilse bile görev son kalan FCM ile sürdürülebiliyor
- Sessiz moda geçen FCM, sıfırlandıktan sonra diğer modüllerle yeniden senkronize edilip uçuş sırasında yeniden devreye alınabiliyor
- Orion, klasik üçlü yedekliliğin (triple redundancy) ötesine geçen bir yapı benimsiyor
-
Deterministik çalışmanın korunması
- Birden fazla bağımsız bilgisayarı tam senkronize (lockstep) durumda tutmak için deterministik mimari (deterministic architecture) uygulanıyor
- Orion, sistem geneline zamanı dağıtmak için time-triggered Ethernet ağını kullanıyor
- Uçuş yazılımı, ARINC653 zamanlayıcısının yönettiği major frame ve minor frame içinde çalışıyor
- Zaman ve alan bölümlendirmesi sayesinde giriş ve çıkışların ağ takvimiyle kusursuz biçimde hizalanması garanti ediliyor
- Her FCM aynı girdileri alıyor, aynı kodu çalıştırıyor ve aynı çıktıları üretiyor
- Her saniye FCM saat kayması ölçülüp ağın referans zamanına göre yeniden kalibre ediliyor
- Son teslim süresini (deadline) kaçıran uygulamalar otomatik olarak sessiz moda alınıyor ve ardından yeniden senkronize ediliyor
- Donanım, üçlü modül yedekli bellek (TMR) kullanarak tek bitlik hataları otomatik düzeltiyor; ağ arayüz kartları da çift trafik yolunu karşılaştırıp hata durumunda fail-silent işliyor
- Ağ, üç bağımsız düzlem üzerinden üçlü yedekli yapıda ve tüm anahtarlar kendi kendini doğrulama özelliğine sahip
-
Son yedek sistem
- NASA, tüm ana kanalları aynı anda etkileyebilecek ortak mod arızasına (common mode failure) karşı da hazırlıklı
- Bunun için ayrı bir Backup Flight Software (BFS) sistemi taşınıyor
- BFS, farklı donanım, farklı işletim sistemi ve bağımsız geliştirilmiş sadeleştirilmiş uçuş yazılımından oluşuyor
- Ana sistem başarısız olursa BFS otomatik olarak kontrolü devralıp görevin dinamik aşamalarını tamamlayabiliyor
- Sonrasında mürettebat ana FCM'leri geri getirmeyi deneyebiliyor
- Fail-silent mantığı gerekli olsa da, hataların tespit edilmeden kalmaması için watchdog timer ve çok katmanlı izleme birlikte kullanılmalı
- Tam güç kaybı (dead bus) durumunda bile hayatta kalabilecek şekilde tasarlandı
- Güç geri geldiğinde otomatik olarak safe mode'a geçiyor
- Güneş panelleri Güneş'e çevrilerek enerji geri kazanılıyor, ardından ısıl kararlılık için araç Güneş'e kuyruğu dönük konuma getiriliyor
- Sonrasında Dünya ile iletişim yeniden kurulmaya çalışılıyor; gerekirse mürettebat yaşam destek sistemlerini manuel olarak ayarlayabiliyor
-
Güvenilirliğin geleceği
- Apollo'dan Artemis'e geçiş, yazılım karmaşıklığında sıçrama niteliğinde bir artış anlamına geliyor
- Apollo'da mekanik yedekler vardı, ancak Artemis'te tüm kontrol yazılıma emanet
- NASA, tam ortam simülasyonu, Monte Carlo stres testleri ve büyük ölçekli hata enjeksiyonu (fault injection) içeren modern bir doğrulama iş akışı kullanıyor
- Süper bilgisayarlarla tüm uçuş zaman çizelgesi simüle edilerek, donanım arızalarında bile yazılımın fail-silent biçimde toparlanabildiği doğrulanıyor
- Orion'un sıfır toleranslı mimarisi, gelecekte otonom araçlar ve endüstriyel kontrol ağları gibi alanlarda da uygulanabilecek bir her zaman aktif (always-on) dayanıklılık modeli olarak değerlendiriliyor
- Apollo'dan Artemis'e geçiş, yazılım karmaşıklığında sıçrama niteliğinde bir artış anlamına geliyor
1 yorum
Hacker News yorumları
1989'dan 95'e kadar Stratus'ta VOS ve veritabanı performansı ile ilgili işlerde çalıştım
Stratus, donanım tabanlı hata toleranslı (fault-tolerant) sistemler üreten bir şirketti; rakibi Tandem ise yazılım tabanlı bir yaklaşım kullanıyordu
Stratus'un mimarisi “pair and spare” idi; tüm kartlar yedekliydi ve her pin çıkışı her tikte karşılaştırılıyordu
Motorola 68K'den Intel'e geçerken, bazı komutların kullanılmayan pinlerinin boşa çıkması nedeniyle donanım ekibi büyük zorluk yaşadı
CMU araştırmacısının “Agile ve DevOps mimari disiplini zayıflattı” sözü dikkat çekiciydi
Görünüşe göre bugünlerde deterministik sistemler kurmayı unuttuk
Time-triggered Ethernet'in katı çerçeve zamanlaması, bugünün yazılım geliştirme tarzından tamamen farklı bir dünya gibi geliyor
Modern geliştirme pratiklerinin bazıları (birim testleri, CI vb.) bu ortamlarda da olumlu etki yaratıyor
Şimdi ticari pazar odaklı yapıya geçilince yatırımlar azaldı, ama hâlâ ilginç birçok algoritma var
Frank Mueller ve Johann Blieberger'in çalışmalarına bakılabilir
Uçaklar gibi giriş ve çıkışların sınırlı olduğu ortamlarda deterministik tasarım mükemmel şekilde uyuyor
Pratikte Ethernet'ten çok özel donanım veri yoluna daha yakın
Code Golf'taki ‘radiation hardening’ challenge bana bu yaklaşımın gerçekte işe yarayıp yaramayacağını düşündürdü
Gerçekte çok fazla katmanda iç içe geçmiş sorun var, bu yüzden zor görünüyor; ama yine de ilginç bir fikir
Makalede anlatılan “fail-silent” tasarım ilginçti
Ama iki CPU aynı anda yanlış hesap yapıp sonuçları da eşleşirse bunun nasıl tespit edileceğini merak ettim
İki CPU'nun aynı anda aynı hatayı üretme olasılığı, tek bir CPU'nun FIT değerinden çok daha düşüktür
Yine de uzayda Murphy yasası işler, o yüzden kesin konuşmak zor
“%25 çoğunluk” ile yanlış sonucun seçilmesi de mümkün olabilir
Bu sistemin CPU, RAM, OS ve dil gibi ayrıntılarını merak ediyorum
FCM'nin ne sıklıkla “fail-silent” durumuna geçtiğini de bilmek isterim
Genelde FreeRTOS veya RTEMS üzerinde çalışır
Bana göre proje yapısı fazla karmaşıktı ve kullanması zordu
NASA'nın çekirdek kodlarının çoğu kapalıdır, ancak cFS klasik uçuş yazılımı tasarımını öğrenmek için iyi bir kaynaktır
Makalede gerçek RTOS ve mimari ayrıntıları eksik
Orion'un ana uçuş kontrolü, Green Hills INTEGRITY RTOS ve BAE RAD750 işlemci tabanlı dörtlü yedekli bir yapıdan oluşuyor
BFS ise tamamen farklı bir LEON3 + VxWorks donanımı üzerinde çalışıyor ve NASA'nın cFS framework'ünü kullanıyor
Bu, James Webb teleskobu ve Mars Rover'da da kullanılan modüler yeniden kullanılabilir mimaridir
Bu yapı, basit bir “ana sistem + yedek” modelinden ziyade heterojen yedeklilik (dissimilar redundancy) fikridir
Ayrıntılar için NASA teknik dokümanı 1, doküman 2 incelenebilir
Gerçek üretim işini Lockheed Martin ve alt yükleniciler yaptı
Medyanın bunu NASA doğrudan yapmış gibi sunması yanlış anlamalara yol açıyor
25 yıl önce web geliştiricisi olarak çalışırken, NASA'dan gelen bir arkadaşıma “hataları nasıl ele alıyordunuz?” diye sormuştum
Gülerek “hata yoktu” diye cevap vermişti
Günümüz geliştiricileri, başarısız olunduğunda insan hayatının söz konusu olmadığı ortamlara alışmış durumda
Web hizmetlerinde sonuç gelir kaybı olabilirken, uzay araçlarında mesele insan hayatıdır
Geçmişte radyasyona dayanıklı bilgisayarlar geliştirdim
Sadece basit yedekliliğin ötesinde, yedeksiz hata tespit teknikleri de kullanıyorduk
Bu sistemde böyle bir yaklaşımın görünmemesi biraz hayal kırıklığı yarattı
radyasyon çarpışma kesitinin dağıtılması şeklinde fiziksel sertleştirme de yapılmıştı
Çeşitli yedeklilik yapıları harika olsa da, Manual Override işlevinin hâlâ mümkün olup olmadığını merak ediyorum
Apollo 11 ve 13'te olduğu gibi gerektiğinde doğrudan kontrol edilebiliyor mu, bilmek isterim
Hâlâ test pilotu kökenli astronotlar aracı kullandığı için bunun mümkün olduğunu düşünüyorum