Sertleşmeyle yer aldınız mı?

Alan sertleşmesi söz konusu olduğunda en iyi uygulamaları incelemek için çok istekliyim. Örneğin, (artık makaleyi bulamıyorum), Mars gezicisinin bazı çekirdek bölümlerinin dinamik bellek tahsisi kullanmadığını, aslında yasak olduğunu okudum. Ayrıca eski moda çekirdekli belleğin uzayda tercih edilebileceğini de okudum.

Google Lunar Challenge ile ilgili projelerden bazılarına bakıyordum ve ayın kodunu almanın, hatta sadece uzaya girmenin nasıl bir his olduğunu merak ediyordum. Uzam sertleştirilmiş tahtaların bu kadar sert bir ortamda bir akıl sağlığı sağladığını biliyorum;

Önümüzdeki birkaç yıl özel alan şirketlerinde daha fazla büyüme gösterebileceğini düşünüyorum, en azından en iyi uygulamalar konusunda biraz bilgili olmak isterdim.

Radyasyon, soğuk veya sıcak, yalıtımına zarar veren bir tahtayı bombalarsa programa ne olur? Amaç, insanları bir uzay gemisinin içinde tutmak (işleri tamir etmek veya değiştirmek kadar) ve işleri düzeltmek için görev yapmaktan kaçınmak olduğunu düşünüyorum.

Ayrıca, eğer kurul bazı kritik bir sistemi koruyorsa, erken uyarılar olağanüstü görünmektedir.

Biri test etme, deneme ve yanılma yoluyla nasıl deneyim kazanır (kendi kişisel uydunuzun başlatılmasını engeller?)

Uzay yazılımı gizli bir sihir değildir. Hala 1'ler ve 1'ler kullanıyorsunuz, 1'ler ve 3'ler değil. Dolayısıyla, muhtemelen gelişen yazılıma neyin girdiğini açıklayan bir wow faktörü yoktur.

Şu anda akla gelen bazı küçük farklılıklar:

• Son derece süreç odaklı.
• Uzay yazılımı her zaman hem yazılım hem de donanım izleme zamanlayıcılarına sahip olacaktır.
• Çalıştığım her uzay sistemi zor ve gerçek zamanlı bir sistemdi.
• Her harici aktörü sisteme benzetin (büyük doğrulukta). Bu genellikle yalnızca test için kullanılan özel donanımların (bazen gerçekten pahalı) oluşturulmasını içerir.
• Resmi testler yapmak için çok çaba harcamak ve masraf harcamak.
• Müşteri (genellikle JPL) test sürecine son derece dahildir.
• Genelde yenileri yerine eski ve bilinen derleyicileri ve geliştirme ortamlarını kullanıyorsunuz.
• Kod incelemeleri, kod incelemeleri ve kod incelemeleri.
• Donanım ve yazılım dünyaları arasında geçiş yapmak çok rahat olsa iyi olur. Donanımı nasıl tasarlayacağınızı bilmek zorunda değilsiniz ama nasıl çalıştığını bilmek zorundasınız.
• Osiloskoplar, mantık analizörleri, sentezleyiciler ve spektrum analizörleri gibi test ekipmanlarının yoğun kullanımı.
• Uygulama programını saklamak için en az 3 yer. Varsayılan ayar ROM'da yazılmıştır. Bu asla değişmeyecek. Diğer 2, geçerli sürüm ve sonraki / son sürüm içindir.
• Hata analizi (MTBF) gerçekten önemlidir.
• Kritik bileşenler için yedek sistemler ve yük devretme planları.

Sadece ilginç soruna rastladım.

Apollo sırasında Instrumentation Lab'deydim ve daha sonra "soğuk savaş" sırasında Draper Lab olarak adlandırıldım.

Apollo rehberlik bilgisayarı için, çekirdek RAM için ve ROM için özel bir örgülü çekirdek kullanılmıştır. Makinenin kendisi tamamen NOR kapılarından üretildi ve güvenilirlik için oldukça yavaş saatlerle beslendi.

Doğrudan Minuteman füzeleri üzerinde çalışmadım, ama bazı sorunların farkındaydım. Bazı elektronik parçaların yakınında bir nükleer savaş başlığı patlarsa, temelde kısa devre yapar. Yönlendirme bilgisayarında Vc'yi anında kapatacak bir radyasyon sensörü vardı, böylece hiçbir şey yanmayacaktı. Daha sonra bilgisayar yeniden başlatılır ve kayıtları silinir.

Bunu yapabilmek için, bilgisayar kayıtlarını düzenli olarak çekirdeğe çeker ve yeniden başlatıldığında bu kontrol noktasından başlar. Bu çalışmayı yapmak için, yazılımın (tümü ASM'de), yanlış cevaplar almadan herhangi bir sıklıkta, bu kadar çok isabet alabileceğini görmek için analiz edilmesi gerekiyordu. Buna "korumanın yeniden başlatılması" denildi. Çok ilginç bir problem, (şükürler olsun) verilen asla kullanılmamıştı.

Özellikle C'de zorlu çevre güvenilirliği elde etmek için işte yaptığım bazı gerçekten somut şeyler var.

MISRA-C: Otomotiv C altkümesi. Ravenscar ADA / Java gibi bir bit.

bekçi köpekleri: programın kilitlenmediğinden emin olun

ecc belleği (bazen)

sağlama toplamları: saygısız bitleri arıyorum. Bunların üçünü de tek bir sistemde gördüm:

1) programı sürekli olarak kontrol eder (EPROM’daydı ancak hala bit sayıldı).

2) belirli veri yapılarını düzenli aralıklarla sağlama toplamı.

3) CPU akıl sağlığı düzenli aralıklarla kontrol eder.

4) IO kayıtlarının içinde olması gerekenleri olup olmadığını kontrol edin.

4b) çıkışları bağımsız girişlere okuyup doğrulayın.

Programlama diline nazaran çok daha önemli olan, temel sistemlerdeki gereksinimlerdir (İşletim Sistemi ve Donanım). Temel olarak, genel sistemin deterministik ve öngörülebilir davranışını sağlamanız (ve kanıtlamanız) gerekir . Gerçek zamanlı toplulukta çok ilgili araştırmalar yapıldı. : Eğer gerçekten bu konuyu incelemek istiyorsanız şiddetle iki kitap okuma tavsiye Gerçek Zamanlı Sistemleri tarafından Jane Liu ve aynı adla bir kitap Hermann Kopetz . Eski, çok teorik bir şekilde programlamayı kapsar, ikincisi ayaklarınızı yere geri getirir ve (gerçek zamanlı) sistem tasarımının ilgili tüm yönlerini, örneğin hata toleransını hemen hemen kapsar.

Ayrıca, aşağıdaki iki olay, yazılım mühendislerinin uzaya bir şey gönderirken karşılaşmaları gereken sorunların kalitesini güzel bir şekilde göstermektedir:

• Ariane 5 (Kanıtlanmış yazılımın farklı sınırlamalar altında tekrar kullanılması)
• Mars Rover Pathfinder Reboot (Öncelikli inversiyon)

Ben (2009 dolaylarında) bu belgeyi buldum C Programlama Dili için Kodlama Standardı JPL Kurumsal üzerinde Jet Propulsion Laboratory at Güvenilir Yazılım (Lars) için Laboratuvarı sitesinde.

Belgelenen kuralların bir özeti:

1. Dil uygunluğu

   • Dil tanımının dışında kalmayın.
   • Etkin olan tüm uyarıları derle; statik kaynak kod analizörleri kullanın.

2. Tahmin edilebilir İcra

   • Sonlandırılması gereken tüm döngüler için doğrulanabilir döngü sınırlarını kullanın.
   • Doğrudan veya dolaylı özyineleme kullanmayın.
   • Görev başlangıcından sonra dinamik bellek ayırma kullanmayın.
   • * Görev iletişimi için IPC mesajları kullanın.
   • Görev senkronizasyonu için görev gecikmelerini kullanmayın.
   • * Açıkça paylaşılan veri nesneleri için yazma izni (sahiplik) aktarın.
   • Semafor ve kilit kullanımına kısıtlamalar getirin.
   • Hafıza koruması, güvenlik sınırları, bariyer düzenleri kullanın.
   • Goto, setjmp veya longjmp kullanmayın.
   • Bir enum listesinin öğelerine seçici değer atamaları kullanmayın.

3. Savunma Kodlaması

   • Veri nesnelerini mümkün olan en küçük kapsam düzeyinde bildirin.
   • Boşluksuz fonksiyonların dönüş değerini kontrol edin veya açıkça (boş) konumuna getirin.
   • İşlevlere iletilen değerlerin geçerliliğini kontrol edin.
   • Akıl sağlığı kontrolü olarak statik ve dinamik iddiaları kullanın.
   • * İnt, short, vb. Önceden tanımlanmış C veri türleri yerine U32, I16, vb. Kullanın.
   • Bileşik ifadelerde değerlendirme sırasını açıkça belirtiniz.
   • Yan etkileri olan ifadeleri kullanmayın.

4. Kod Açıklığı

   • C ön işlemcisini yalnızca çok sınırlı kullanın.
   • Bir işlev veya blok içindeki makroları tanımlamayın.
   • Makroları tanımlamayın veya yeniden tanımlamayın.
   • #Else, #elif ve #endif dosyalarını #if veya #ifdef ile aynı dosyaya yerleştirin.
   • * Metin satırı başına birden fazla ifade veya beyanda bulunmayın.
   • * Sınırlı sayıda parametre ile kısa fonksiyonlar kullanın.
   • * Beyan başına ikiden fazla dolaylı işlem kullanmayın.
   • * Nesne başvurusu başına en fazla iki farklı başvuru düzeyi kullanın.
   • * Makroların içindeki değişkenlik işlemlerini veya typedef'leri gizlemeyin.
   • * Sabit olmayan fonksiyon göstericileri kullanmayın.
   • İşlev işaretleyicilerini başka türlere yerleştirmeyin.
   • Bir #include direktifinden önce kod veya bildirimler yerleştirmeyin.

*) Tüm kurallardır -acak yıldız ile işaretlenmiş olanlar hariç, kurallar.

Uzay geçirmez bilgi işlem sistemlerinin tümü güvenilirlikle ilgilidir. Bu alana derin bir giriş, Algirdas Avižienis, Jean-Claude Laprie ve Brian Randell'ın güvenilirlik temel kavramlarında bulunabilir .

Gerçek zamanlı, uzay hesaplama için de kilit bir kavramdır. Pankrat olarak Hermann Kopetz tarafından Gerçek Zamanlı Sistemleri tavsiye ederim .

Alan hesaplamanın zorluklarına dair pragmatik bir anlayış vermek için, şunları düşünün:

• Uzayda Zor Koşullar: Güneşe yöneldiğinde çok sıcak, diğer tarafında çok soğuk, bellekte bitleri tersine çeviren birçok kozmik ışın, çok büyük hızlanmalar ve dokunulduğunda titreşimler, ... Alan için donanım donanımdan çok daha sağlam olmalı askeri için.

• Uluslararası Uzay İstasyonu veya Hubble Uzay Teleskobu dışında bir arıza meydana geldiğinde, kimse gelip başarısız sistemi değiştiremez. Her şey yerden maksimum gözlemlenebilirlik ve uyumlulukla ve geçmek için yedek sistemler yoluyla sabitlenmelidir. Bu, Dünya uyduları için kolaydır. Bu, iletişim gecikmelerinin bir saat uzun olabileceği uzay problarıyla daha zordur. Aslında, her şeyden önce her şey mümkün olduğunca güvenilir olmalıdır.

Stajyer olarak yer aldığım bir projeden öğrendiklerim:

Donanım özellikleri genellikle daha kötüsü için değişecek!

Örneğin, tasarımda kullanılan alanla sertleştirilmiş CPU'nun 20 MHz'de çalışacağına dair size söz verildi, vaat edildi .

Nihai sonuç 12 MHz'de gerçekleşti. Projenin üst düzey programcısı, kontrol sistemlerinin ve telemetri yazılımının büyük gerçek zamanlı gereksinimlerini karşılamak için birincil CPU'da çalışmak yerine ikinci bir sisteme boşaltılarak, algoritmaları yeniden tasarlamak için çok zaman harcadı.

Bu yüzden, orijinal tasarımda bazı ekstra kaynaklar bırakmaya çalışın ve mevcut tüm CPU ve belleği kullanmamaya çalışın.

Bir yazılım perspektifi için, zaman zaman rastgele, kodunuzdaki bitleri çeviren ayrıcalıklı bir görev yazın ve bununla nasıl başa çıktığını görün. Bu senin simülatörün.

Donanım açısından, parçalar eski olacak, çünkü uzayı değerlendirmek için uzun bir süre gerekiyor. Ayrıca, yeni parçalar sürekli olarak küçülüyor ve bir özellik ne kadar küçükse (bir IC üzerindeki bellek hücresi olduğunu düşünüyorum) radyasyon olayından kaynaklanan bozulmalara o kadar duyarlı oluyor.

Güvenlik açısından kritik bir cihaz üzerinde çalıştım ve benzer çemberlerden geçmemiz gerekti.

Güvenlik kritik değişkenlerimiz vardı. Değişkenin tersinin bir kopyası vardı. Her döngüden sonra, değişken tersine karşı kontrol edildi.

TÜM kayıtların yürüme ve sıfır testlerini yaptık. Program Sayacı dahil!

Mikro talimat setinin tüm kodlarını test ettik. 2 kayıt eklediyseniz, kayıtların eklendiğinden emin olmalıydık.

Bunun bir kısmı muhtemelen uzaydaki programlarla ilgili değildir, ancak size mümkün olan kontrolün büyüklüğü hakkında bir fikir verir.

Bir ortamın daha kötü olmasının daha fazla Hata Düzeltme Kodunun kullanıldığına inanıyorum ve bir dereceye kadar kullanılabilecek ECC hafızaları var.

Bir hata seviyesini tahmin edebiliyorsa, tanıtılan hataları işleyebilecek bir Hata düzelten kod oluşturabilirsiniz.

• Evet, çekirdek bellek araştırma kurullarındadır.
• Dinamik bellek, gömülü sistemler için iyi değil. Güvenilirlik sorunları

Yazılımın ECC veri ve bilgi teorisi ve veriyi bellek arızalarını yönetmek için sistemin etrafına yaymak için özel bir acentası kullanmanın bir başlangıç ​​olacağını tahmin ediyorum. Ancak, rad-hard yazılımı çalışmıyorum bu yüzden aşina değilim, bu sadece bir tahmin.