Sudahkah Anda menangani pengerasan ruang?

Saya sangat ingin mempelajari praktik-praktik terbaik dalam hal pengerasan ruang. Sebagai contoh, saya telah membaca (walaupun saya tidak dapat menemukan artikel lagi) bahwa beberapa bagian inti dari penemu Mars tidak menggunakan alokasi memori dinamis, bahkan itu dilarang. Saya juga membaca bahwa memori inti kuno mungkin lebih disukai di ruang angkasa.

Saya sedang melihat beberapa proyek yang terkait dengan Google Lunar Challenge dan bertanya-tanya bagaimana rasanya mendapatkan kode di bulan, atau bahkan hanya ke luar angkasa. Saya tahu bahwa papan yang dikeraskan ruang menawarkan kewarasan dalam lingkungan yang keras, namun saya bertanya-tanya (sebagai seorang programmer C) bagaimana saya perlu menyesuaikan pemikiran dan kode saya jika saya sedang menulis sesuatu yang akan berjalan di ruang angkasa?

Saya pikir beberapa tahun ke depan mungkin menunjukkan lebih banyak pertumbuhan di perusahaan ruang angkasa swasta, saya benar-benar ingin setidaknya memiliki pengetahuan tentang praktik terbaik.

Apa yang terjadi pada suatu program jika radiasi, dingin atau panas membombardir papan yang mengalami kerusakan pada isolasi? Saya pikir tujuannya adalah menjaga manusia di dalam pesawat ruang angkasa (sejauh memperbaiki atau menukar barang) dan menghindari misi untuk memperbaiki keadaan.

Lebih jauh, jika dewan memiliki beberapa sistem kritis, peringatan dini tampaknya sangat penting.

Bagaimana seseorang mendapatkan pengalaman dalam hal ini melalui pengujian dan coba-coba (kecuali peluncuran satelit pribadi Anda?)

Perangkat lunak luar angkasa bukanlah sihir misterius. Anda masih menggunakan 0 dan 1, bukan 1 dan 3. Jadi mungkin tidak ada faktor wow yang terlibat dalam menggambarkan apa yang terjadi dalam pengembangan perangkat lunak.

Beberapa perbedaan kecil yang muncul di pikiran saat ini adalah:

• Berorientasi pada proses.
• Perangkat lunak luar angkasa akan selalu memiliki timer pengawas perangkat lunak dan perangkat keras.
• Setiap sistem ruang yang saya garap adalah sistem real-time yang sulit.
• Anda mensimulasikan (dengan sangat akurat) setiap aktor eksternal ke sistem. Ini biasanya melibatkan pembuatan perangkat keras khusus (terkadang sangat mahal) yang hanya digunakan untuk pengujian.
• Anda menghabiskan banyak upaya dan biaya untuk melakukan pengujian formal.
• Pelanggan (biasanya JPL) sangat terlibat dalam proses pengujian.
• Anda biasanya menggunakan kompiler lama dan dikenal dan lingkungan pengembangan, bukan yang baru.
• Ulasan kode, ulasan kode dan ulasan kode.
• Sebaiknya Anda merasa sangat nyaman untuk beralih antara dunia perangkat keras dan perangkat lunak. Anda tidak harus tahu cara mendesain perangkat keras tetapi Anda harus tahu cara kerjanya.
• Penggunaan alat uji secara ekstensif, seperti osiloskop, penganalisa logika, penganalisis dan penganalisa spektrum.
• Setidaknya 3 lokasi untuk menyimpan program aplikasi. Standarnya dibakar dalam ROM. Ini tidak akan pernah berubah. 2 lainnya untuk versi saat ini dan versi berikutnya / terakhir.
• Analisis kegagalan (MTBF) sangat penting.
• Sistem redundan dan rencana failover untuk komponen-komponen penting.

Saya baru saja menemukan pertanyaan menarik Anda.

Saya berada di Lab Instrumentasi selama Apollo, dan lagi kemudian ketika itu disebut Lab Draper selama "perang dingin".

Untuk komputer panduan Apollo, core digunakan untuk RAM, dan core braided khusus digunakan untuk ROM. Mesin itu sendiri dibuat seluruhnya dari gerbang NOR dan clock cukup lambat, untuk keandalan.

Saya tidak bekerja secara langsung pada rudal Minuteman, tetapi saya menyadari beberapa masalah. Jika hulu ledak nuklir meledak di sekitar beberapa elektronik, itu pada dasarnya lebih pendek. Komputer pemandu memiliki sensor radiasi yang akan langsung mematikan Vc sehingga tidak ada yang terbakar. Kemudian komputer akan restart, setelah registernya dihapus.

Untuk mengatasinya, komputer akan secara berkala memotret registernya ke dalam inti, dan ketika dinyalakan kembali akan dimulai dari pos pemeriksaan itu. Untuk membuat ini berfungsi, perangkat lunak (semua dalam ASM) harus dianalisis untuk melihat bahwa itu dapat mengambil sejumlah hit seperti itu, pada frekuensi berapa pun, tanpa mendapatkan jawaban yang salah. Itu disebut "restart protected". Masalah yang sangat menarik, mengingat (syukurlah) itu tidak pernah harus digunakan.

Untuk mendapatkan keandalan lingkungan yang tangguh khususnya dalam C, berikut adalah beberapa hal nyata yang pernah saya lakukan.

MISRA-C: Subset Otomotif C. Agak seperti Ravenscar ADA / Java.

watchdogs: memastikan program tidak terkunci

memori ecc (kadang-kadang)

checksum: mencari flipping bits. Saya telah melihat ketiganya dalam satu sistem:

1) checksum program terus menerus (itu di EPROM tetapi masih mendapat bit terbalik).

2) checksum struktur data tertentu secara berkala.

3) Pemeriksaan kewarasan CPU secara berkala.

4) periksa register IO memiliki apa yang seharusnya ada di dalamnya.

4b) baca kembali output ke input independen dan verifikasi.

Jauh lebih penting daripada bahasa pemrograman adalah persyaratan pada sistem yang mendasarinya (OS dan Perangkat Keras). Pada dasarnya, Anda perlu memastikan (dan membuktikan) perilaku deterministik dan dapat diprediksi dari keseluruhan sistem. Banyak penelitian terkait telah dilakukan di komunitas real-time. Saya sangat merekomendasikan membaca dua buku jika Anda benar-benar ingin mempelajari subjek ini: Sistem Real-Time oleh Jane Liu dan sebuah buku dengan nama yang sama oleh Hermann Kopetz . Yang pertama mencakup penjadwalan dengan cara yang sangat teoretis sementara yang kedua membuat kaki Anda kembali ke tanah dan cukup banyak mencakup semua aspek terkait dari desain sistem (waktu nyata), misalnya toleransi kesalahan.

Selain itu, dua insiden berikut dengan baik menggambarkan kualitas masalah yang harus dihadapi insinyur perangkat lunak saat mengirim sesuatu ke ruang angkasa:

• Ariane 5 (Penggunaan kembali perangkat lunak yang terbukti dalam berbagai kendala)
• Reboot Pathfinder Mars Rover (Pembalikan prioritas)

Saya menemukan dokumen ini (sekitar 2009) untuk Standar Pengodean Kelembagaan JPL untuk Bahasa Pemrograman C di Laboratorium untuk Perangkat Lunak yang Andal (LaRS) di situs Jet Propulsion Laboratory .

Berikut ringkasan aturan yang didokumentasikan:

1. Kepatuhan Bahasa

   • Jangan menyimpang dari definisi bahasa.
   • Kompilasi dengan semua peringatan diaktifkan; gunakan analisa kode sumber statis.

2. Eksekusi yang Dapat Diprediksi

   • Gunakan batas loop yang dapat diverifikasi untuk semua loop yang dimaksudkan untuk mengakhiri.
   • Jangan gunakan rekursi langsung atau tidak langsung.
   • Jangan gunakan alokasi memori dinamis setelah inisialisasi tugas.
   • * Gunakan pesan IPC untuk komunikasi tugas.
   • Jangan gunakan penundaan tugas untuk sinkronisasi tugas.
   • * Secara eksplisit mentransfer izin menulis (kepemilikan) untuk objek data bersama.
   • Tempatkan pembatasan penggunaan semafor dan kunci.
   • Gunakan perlindungan memori, margin keamanan, pola penghalang.
   • Jangan gunakan goto, setjmp atau longjmp.
   • Jangan gunakan penetapan nilai selektif untuk elemen daftar enum.

3. Pengodean Defensif

   • Deklarasikan objek data pada tingkat ruang lingkup sekecil mungkin.
   • Periksa nilai kembalinya fungsi-fungsi non-void, atau secara eksplisit dilemparkan ke (void).
   • Periksa validitas nilai yang diteruskan ke fungsi.
   • Gunakan pernyataan statis dan dinamis saat memeriksa kewarasan.
   • * Gunakan U32, I16, dll, alih-alih tipe data C yang telah ditentukan seperti int, short, dll.
   • Buat urutan evaluasi dalam ekspresi majemuk menjadi eksplisit.
   • Jangan gunakan ekspresi dengan efek samping.

4. Kode Kejelasan

   • Manfaatkan hanya penggunaan pra-prosesor C yang sangat terbatas.
   • Jangan mendefinisikan makro dalam fungsi atau blok.
   • Jangan undefine atau redefine macro.
   • Tempatkan #else, #elif, dan #endif di file yang sama dengan #if atau #ifdef.
   • * Tempatkan tidak lebih dari satu pernyataan atau pernyataan per baris teks.
   • * Gunakan fungsi pendek dengan sejumlah parameter terbatas.
   • * Gunakan tidak lebih dari dua tingkat tipuan per deklarasi.
   • * Gunakan tidak lebih dari dua level dereferencing per referensi objek.
   • * Jangan sembunyikan operasi dereference di dalam macro atau typedefs.
   • * Jangan gunakan pointer fungsi tidak konstan.
   • Jangan membuang pointer fungsi ke tipe lain.
   • Jangan letakkan kode atau deklarasi di depan arahan #include.

*) Semua aturan harus aturan, kecuali yang ditandai dengan tanda bintang.

Sistem komputasi ruang-bukti adalah soal ketergantungan. Pengantar yang mendalam untuk bidang ini dapat ditemukan dalam konsep-konsep fundamental tentang ketergantungan oleh Algirdas Avižienis, Jean-Claude Laprie & Brian Randell.

Real-time juga merupakan konsep kunci untuk komputasi ruang. Sebagai Pankrat, saya akan merekomendasikan Sistem Real-Time oleh Hermann Kopetz.

Untuk memberikan pemahaman pragmatis tentang tantangan komputasi ruang, pikirkan:

• kondisi ekstrim di ruang angkasa: sangat panas ketika berorientasi ke matahari, sangat dingin di sisi lain, banyak sinar kosmik yang dapat membalikkan bit dalam memori, percepatan besar dan getaran ketika digeber, ... Perangkat keras untuk ruang harus jauh lebih kuat daripada perangkat keras untuk militer.

• Ketika kegagalan terjadi, kecuali di Stasiun Luar Angkasa Internasional atau untuk Teleskop Luar Angkasa Hubble, tidak ada yang datang dan mengganti sistem yang gagal. Semuanya harus diperbaiki dari tanah melalui kemampuan observasi dan perintah yang maksimal dan melalui sistem cadangan untuk beralih. Ini mudah untuk satelit Bumi. Ini lebih sulit dengan probe ruang yang keterlambatan komunikasi mungkin satu jam. Memang, semuanya harus seandal mungkin pada awalnya.

Apa yang saya pelajari dari satu proyek yang saya ikuti sebagai pekerja magang:

Spesifikasi perangkat keras Anda akan berubah, biasanya menjadi lebih buruk!

Sebagai contoh, ruang hardened CPU yang digunakan dalam desain dijanjikan, dijanjikan , ingat, bahwa itu akan berjalan pada 20 MHz.

Hasil akhir berjalan pada 12 MHz. Programmer senior pada proyek menghabiskan banyak waktu mendesain ulang algoritma untuk memenuhi persyaratan real time yang sulit dari sistem kontrol dan banyak perangkat lunak telemetri akhirnya diturunkan ke sistem kedua alih-alih berjalan pada CPU primer.

Jadi, cobalah untuk meninggalkan beberapa sumber daya tambahan yang tersedia dalam desain aslinya dan cobalah untuk tidak menggunakan semua CPU dan memori yang tersedia.

Untuk perspektif perangkat lunak, tuliskan tugas istimewa yang sesekali, secara acak, membalik bit dalam kode Anda, dan lihat bagaimana cara mengatasinya. Itu simulator Anda.

Dari segi perangkat keras, bagian-bagiannya akan menjadi tua, karena butuh waktu lama untuk mendapatkan nilai ruang. Juga, bagian-bagian baru terus menyusut dalam ukuran, dan semakin kecil fitur (pikirkan sel memori pada IC) semakin rentan terhadap korupsi dari peristiwa radiasi.

Saya bekerja pada perangkat yang kritis terhadap keselamatan dan kami harus melalui beberapa lingkaran yang serupa.

Kami memiliki variabel kritis keselamatan. Ada salinan invers dari variabel. Setelah setiap loop, variabel diperiksa terhadap kebalikannya.

Kami memiliki tes berjalan dan nol dari SEMUA register. Itu termasuk Penghitung Program!

Kami memiliki tes semua opcode dari set instruksi mikro. Kami harus memastikan bahwa jika Anda menambahkan 2 register, register ditambahkan.

Beberapa di antaranya mungkin tidak terkait dengan program di luar angkasa, tetapi ini memberi Anda rasa besarnya pemeriksaan yang dimungkinkan.

Saya percaya semakin buruk suatu lingkungan, semakin banyak Kode Koreksi Kesalahan digunakan, dan ada memori ECC yang dapat digunakan sampai batas tertentu.

Jika seseorang dapat memperkirakan tingkat kesalahan seseorang dapat membangun kode koreksi kesalahan yang dapat menangani kesalahan yang diperkenalkan.

• Ya, memori inti ada di papan penelitian.
• Memori dinamis tidak baik untuk sistem tertanam. Masalah keandalan.

Saya akan menebak bahwa ECC perangkat lunak data dan menggunakan teori informasi dan penginapan kustom untuk menyebarkan data di sekitar sistem untuk mengelola kegagalan memori akan menjadi awal. Tapi, saya tidak belajar perangkat lunak rad-keras jadi saya tidak terbiasa dengan itu, itu hanya dugaan.