Kode ini didasarkan pada kode MER ( Spirit and Opportunity ), yang didasarkan pada pendarat pertama mereka, MPF ( Sojourner ). Ini 3,5 juta baris C (sebagian besar di-autogenerasi), berjalan pada prosesor RA50 yang diproduksi oleh BAE dan sistem operasi VxWorks . Lebih dari satu juta baris diberi kode tangan.
Kode diimplementasikan sebagai 150 modul terpisah, masing-masing melakukan fungsi yang berbeda. Modul berpasangan tinggi disusun menjadi komponen-komponen yang mengabstraksi modul-modul yang dikandungnya, dan "menentukan fungsi, aktivitas, atau perilaku tertentu." Komponen-komponen ini selanjutnya disusun menjadi lapisan-lapisan, dan "tidak lebih dari 10 komponen tingkat atas".
Sumber: Ceramah utama oleh Benjamin Cichy di 2010 Workshop on Spacecraft Flight Software (FSW-10) , slide, audio, dan video (dimulai dengan ikhtisar misi, diskusi arsitektur di slide 80).
Seseorang di Hacker News bertanya, "Tidak yakin apa artinya sebagian besar kode C dihasilkan secara otomatis. Dari apa?"
Saya tidak 100% yakin, meskipun mungkin ada presentasi terpisah di tahun itu atau tahun yang berbeda yang menggambarkan proses pembuatan otomatis mereka. Saya tahu bahwa itu adalah topik populer pada umumnya di konferensi FSW-11.
Simulink adalah suatu kemungkinan. Ini adalah komponen MATLAB yang populer di kalangan insinyur mesin, dan karenanya sebagian besar insinyur navigasi & kontrol, dan memungkinkan mereka untuk 'kode' dan mensimulasikan hal-hal tanpa berpikir mereka sedang mengkode.
Pemrograman berbasis model jelas merupakan hal yang secara perlahan disadari oleh industri, tetapi saya tidak tahu seberapa bagusnya hal ini di JPL atau apakah mereka akan memilih untuk menggunakannya ketika proyek dimulai.
Kemungkinan ketiga dan kemungkinan besar adalah untuk kode komunikasi. Dengan semua sistem ruang angkasa, Anda perlu mengirim perintah ke perangkat lunak penerbangan dari perangkat lunak darat, dan menerima telemetri dari perangkat lunak penerbangan dan memprosesnya dengan perangkat lunak darat. Setiap paket perintah / telemetri adalah struktur data yang heterogen, dan perlu bahwa kedua belah pihak bekerja dari definisi paket yang sama persis, dan memformat paket sehingga diformat dengan benar di satu sisi, dan diuraikan di sisi lain. Ini melibatkan menyelesaikan banyak hal dengan benar, termasuk tipe data, ukuran, dan endianness (meskipun yang terakhir biasanya merupakan hal global; Anda dapat memiliki banyak prosesor di dalam kapal dengan endianness yang berbeda).
Tapi itu hanya permukaannya saja. Anda memerlukan banyak kode berulang di kedua sisi untuk menangani hal-hal seperti logging, validasi perintah / telemetri, pengecekan batas, dan penanganan kesalahan. Dan kemudian Anda dapat melakukan hal-hal yang lebih canggih. Katakanlah Anda memiliki perintah untuk menetapkan nilai register perangkat keras, dan nilai itu dikirim kembali dalam telemetri dalam paket tertentu. Anda dapat membuat perangkat lunak dasar yang memantau titik telemetri untuk memastikan bahwa ketika nilai register ini ditetapkan, akhirnya telemetri berubah untuk mencerminkan perubahan. Dan tentu saja, beberapa titik telemetri lebih penting daripada yang lain (misalnya arus bus utama) dan ditunjuk untuk turun dalam beberapa paket, yang melibatkan penyalinan tambahan di sisi penerbangan dan de-duplikasi data di sisi darat.
Dengan semua itu, jauh lebih mudah (menurut saya) untuk menulis satu kumpulan file teks statis (dalam XML, CSV, atau DSL / apa pun), jalankan melalui skrip Perl / Python, dan presto! Kode!
Saya tidak bekerja di JPL, jadi saya tidak bisa memberikan detail apa pun yang tidak ada di video, dengan satu pengecualian. Saya pernah mendengar bahwa kode C autogenerated ditulis oleh skrip Python, dan jumlah autocoding dalam suatu proyek sangat bervariasi tergantung pada siapa pemimpin FSW itu.