Peralatan Laboratorium Simulasi Hibrid. Foto menunjukkan panel kontrol SDS 9300, yang, bersama-sama dengan beberapa komputer analog, bekerja simulasi modul perintah dan modul bulan.Bertahun-tahun sebelum Apollo 11, ketika sistem kontrol sedang dikembangkan, mereka menganggap perangkat lunak yang disematkan sebagai sesuatu yang dapat dilakukan terakhir: "Hal akan melakukannya," kata mereka. Faktanya, lusinan orang, dan ratusan personel pendukung, melakukan hal ini, tetapi Hal Laning pertama-tama harus mencari tahu bagaimana mengatur berbagai fungsi perangkat lunak sehingga mereka dapat dilakukan hampir secara bersamaan dalam waktu nyata di komputer di pesawat ruang angkasa, yang memiliki ukuran dan kecepatan terbatas. .
Arsitektur Hal menghindari perangkap dari sistem operasi di mana perhitungan harus dibagi dengan jelas antara periode waktu. Sistem seperti ini cukup sulit untuk diimplementasikan, karena tugas dapat berubah secara sewenang-wenang. Ketika tugas ditambahkan atau diubah selama proses pengembangan, perubahan dalam perencanaan tugas mungkin diperlukan. Yang terburuk adalah bahwa sistem operasi yang ada pada komputer on-board sangat rapuh, dalam arti bahwa itu benar-benar gagal jika tugasnya memakan waktu lebih banyak daripada yang dialokasikan.
Alih-alih, Leining mengembangkan sistem di mana fungsi-fungsi program didistribusikan dalam bentuk "tugas," yang bisa dalam ukuran berapa pun yang akan diperlukan untuk melakukan fungsi-fungsi ini. Setiap tugas diberi prioritas. Sistem operasi selalu melakukan tugas dengan prioritas tertinggi. Jika tugas dengan prioritas rendah dilakukan, dan tugas dengan prioritas tinggi ditugaskan saat ini, maka tugas dengan prioritas rendah akan ditangguhkan hingga tugas dengan prioritas tinggi selesai. Sistem seperti itu memberi kita ilusi bahwa tugas dilakukan secara bersamaan, meskipun dalam kenyataannya, tentu saja, tugas dilakukan secara bergantian. Sistem semacam itu tidak deterministik, tetapi fungsinya dapat dipahami dan dapat diverifikasi, dan meningkatkan keandalan, keamanan, fleksibilitas dalam penggunaan, dan, khususnya, kemudahan pengembangan.
Eksekutif (
sistem operasi real-time AGC dan LGC. Approx. Transl. ) Mengatur pelaksanaan tugas sedemikian rupa sehingga setiap tugas mempertahankan statusnya dalam bentuk kumpulan register, dan status dipertahankan sementara tugas dilakukan dengan prioritas tinggi. LGC berisi larik delapan set masing-masing 12 register, 15 bit per register. Seperangkat register dengan ukuran ini cukup untuk melakukan banyak tugas, tetapi tugas yang menggunakan penerjemah (
bahasa penafsiran bawaan untuk tugas yang beroperasi dengan angka presisi ganda. Approx. Transl. ) Untuk melakukan perhitungan vektor dan matriks, diperlukan lebih banyak ruang. Untuk tugas-tugas tersebut, array 43 register terpisah dialokasikan. LGC berisi lima array seperti itu (Vector Accumulator, VAC).
Dengan serangkaian array yang terbatas untuk mempertahankan konteks tugas, meluncurkan tugas untuk eksekusi harus dilakukan dengan sangat hati-hati. Fungsi yang dilakukan berurutan satu demi satu digabungkan menjadi satu tugas. Tugas besar SERVICER aktif selama seluruh fase pendaratan dan fase penerbangan lainnya dengan mesin dihidupkan, dan itu termasuk navigasi menggunakan akselerometer, persamaan gerak, kontrol throttle engine, data tentang posisi kapal, data lain pada layar, dan masing-masing fungsi menggunakan output dari yang sebelumnya.
Jumlah array register yang tersedia dan VAC membatasi jumlah tugas yang dapat di-antri untuk dieksekusi hingga delapan, di mana hingga lima dapat menggunakan array VAC. Selama operasi normal, jumlah tugas yang berjalan tetap konstan, meskipun tugas yang diluncurkan untuk satu eksekusi, atau tidak sinkron, dapat menyebabkan fluktuasi pada beban sistem.
Namun, jika jumlah tugas yang dimulai lebih dari selesai, jumlah array register yang digunakan dan VAC meningkat. Jika situasi ini berlanjut untuk waktu yang cukup lama, jumlah mereka habis, dan permintaan untuk memulai tugas selanjutnya tidak dapat dipenuhi.
Kami akan kembali setahun sebelumnya, sebelum peluncuran Apollo 11, ketika kami, para insinyur perangkat lunak, berpikir bahwa kami sudah memiliki cukup barang, dan kami diminta untuk menulis perangkat lunak untuk mendarat di Bulan sedemikian rupa sehingga secara harfiah dapat dimatikan dan dihidupkan kembali. tanpa mengganggu proses pendaratan dan manuver penting lainnya! Ini disebut "restart perlindungan." Selain gangguan daya, faktor-faktor lain dapat menyebabkan sistem restart. Mulai ulang terjadi jika perangkat keras berpikir bahwa program macet dalam loop tak terbatas, atau jika kesalahan paritas terjadi saat membaca ROM, atau karena beberapa alasan lain.
Perlindungan terhadap restart dilaksanakan dengan mendaftarkan "titik arah" di titik yang sesuai dalam program, diatur sedemikian rupa sehingga kembali ke "titik jalan" terakhir tidak menyebabkan kesalahan, seperti yang ditunjukkan dalam contoh berikut:
NEW_X = X + 1
X = NEW_XJelas, tanpa mendaftarkan waypoint, mengeksekusi kode ini untuk kedua kalinya akan menyebabkan X bertambah kembali.
Setelah restart, program seperti itu melanjutkan pekerjaannya. Setiap tugas dimulai dengan titik jalan terdaftar terakhir. jika beberapa salinan dari tugas yang sama berada dalam antrian, hanya yang terakhir dilanjutkan. Beberapa tugas tidak memiliki status vital, dan tidak dilindungi dari restart. Mereka menghilang begitu saja.
Restart proteksi bekerja dengan sangat baik. Pada panel kontrol simulator hybrid kami di Cambridge ada tombol yang menyebabkan restart AGC. Saat menguji perangkat lunak, kami terkadang menekan tombol ini secara acak, hampir berharap bahwa kegagalan akan membawa kami ke bug lain. Selalu, setiap kali perlindungan terhadap restart dipicu, dan pekerjaan berlanjut tanpa henti.
(Simulator hibrida berisi komputer digital SDS 9300 dan komputer analog Beckmann, komputer AGC nyata, dan model realistis dari kokpit modul perintah dan bulan.)
Persiapan awal dari Apollo.Bukan hanya besi yang dapat menyebabkan restart, itu bisa disebut secara programatik jika program mencapai titik di mana komputer tidak tahu bagaimana melanjutkan menjalankan program. Ini terjadi ketika mentransfer kontrol di bawah tag BAILOUT dalam modul Alarm dan Aborsi. Panggilan itu disertai dengan kode kesalahan.
Tindakan ini dilakukan oleh sistem Eksekutif jika sumber daya habis. Jika tugas tidak dapat diatur karena fakta bahwa tidak ada array gratis untuk menyimpan register, Eksekutif disebut BAILOUT dengan kode kesalahan 1202. Jika tidak ada VAC gratis, maka BAILOUT dengan kode 1201 dipanggil.
Tidak semua fungsi yang dilakukan oleh LGC dilakukan sebagai "tugas." Selain itu, ada gangguan perangkat keras yang dapat terjadi kapan saja (jika tidak dilarang secara eksplisit) yang melakukan fungsi prioritas tinggi, interupsi ditugaskan ke perangkat tertentu, termasuk autopilot digital, "uplink" dan "downlink" (
perangkat transmisi dan penerimaan) data pada saluran radio dengan Earth. approx. terjemahan. ) dan keyboard.
Interupsi lain dapat digunakan untuk mengeksekusi potongan kode yang harus dieksekusi pada waktu tertentu. Fungsi seperti itu disebut tugas, dan mereka dijadwalkan dalam subrutin yang disebut WAITLIST. "Tugas" seharusnya memiliki waktu tunggu yang sangat singkat.
Sementara "tugas" direncanakan untuk dieksekusi dengan prioritas tertentu, "tugas" direncanakan untuk diluncurkan pada waktu tertentu. Tugas dan tugas sering dibagikan. Tugas dapat diluncurkan untuk membaca pembacaan sensor, yang harus dibaca pada waktu yang ditentukan secara ketat, dan tugas itu, pada gilirannya, meluncurkan tugas dengan prioritas tertentu untuk memproses pembacaan ini.
Ketika Hal Lane mendesain Executive dan Waitlist pada pertengahan 1960-an, ia melakukan semuanya dari awal, tanpa mengandalkan contoh apa pun. Dan prinsipnya benar hari ini. Distribusi fungsi oleh sejumlah proses asinkron, di bawah kendali lingkungan eksekutif dengan multitasking preemptive berdasarkan interval waktu dan prioritas, semua ini masih mendasari sistem komputer real-time modern untuk aplikasi ruang.
Perakitan giroskop.* * *
Untuk memahami akar penyebab alarm pada Apollo 11 selama penurunan, perlu untuk mempertimbangkan prosedur perkiraan dengan modul perintah, yang mengikuti setelah munculnya modul bulan dari permukaan bulan ke orbit bulan. Sama seperti kita menggunakan radar pendaratan untuk mengukur ketinggian dan kecepatan relatif terhadap permukaan bulan ketika mendarat di bulan, mendekati modul perintah dalam orbit bulan membutuhkan pengukuran jarak, kecepatan dan arah relatif terhadap kapal kedua menggunakan radar pendekatan.
Radar proximity memiliki beberapa mode operasi yang diatur oleh sakelar mode. Mode-mode ini adalah sebagai berikut: SLEW, AUTO, dan LGC. Dalam mode SLEW dan AUTO, radar beroperasi di bawah kendali perintah, terlepas dari LGC. Mode operasi ini dapat digunakan selama lepas landas dan mendekati jika terjadi kegagalan sistem navigasi utama. Dalam mode SLEW, antena radar dipandu secara manual, sisa waktunya stasioner. Ketika antena diarahkan ke target, Anda dapat mengalihkan mode ke AUTO (pelacakan otomatis) dan itu akan melacak target. Radar kedekatan mengukur jarak dan kecepatan, dan sudut rotasi poros di mana antena berputar ditampilkan pada layar kokpit dan pada indikator dalam bentuk skala vertikal. Selain itu, data jarak dan kecepatan memasuki abort guidance system (AGS), sebuah komputer dengan hanya 6144 kata memori yang menduplikasi sistem PGNS utama ketika mendarat di bulan dan lepas landas dari bulan.
(Nama-nama dari tiga mode operasi radar pemulihan hubungan adalah sumber rasa malu bagi beberapa komentator. Atas permintaan kru, penunjukan diubah setelah misi LM-1 dan sebelum misi mendarat di bulan. Mode yang Apollo 11 disebut LGC sebelumnya disebut AUTO. Mode yang itu disebut AUTO pada Apollo 11, sebelumnya disebut MANUAL. Nama mode SLEW tetap tidak berubah. Meskipun ini sama sekali tidak berkontribusi pada masalah pada Apollo 11, dokumentasi LUMINARY internal di bagian yang berkaitan dengan saluran diskrit 33, pada waktu itu masih disebut re Benchmark LGC dengan radar kedekatan diaktifkan oleh RR AUTO-POWER ON.)
Jika sistem PGNS bekerja (sebagaimana adanya), LGC mengendalikan radar, dalam hal ini saklar mode radar kedekatan diatur ke LGC. Elektronik dari antarmuka radar memungkinkan perangkat lunak untuk mendapatkan data tentang jarak dan kecepatan yang diukur oleh radar, serta sudut poros rotasi antena, dari mana arah ke target dapat ditemukan. Program LGC menggunakan informasi ini untuk mendorong LGC lebih dekat ke modul perintah.
Ternyata radar pendekatan juga dapat bekerja selama turun, dan ini dilakukan selama turunnya Apollo 11. Instruksi kru mengharuskan radar dihidupkan segera sebelum dimulainya fase P63 dan tetap dalam mode SLEW atau AUTO untuk seluruh manuver pendaratan.
Banyak penjelasan diberikan mengapa radar disetel dengan cara ini untuk mendarat di bulan. Misalnya, beberapa orang di Houston mungkin mempertimbangkan skema pemantauan pendaratan mewah dengan membandingkan data radar dengan grafik bacaan yang diharapkan. Namun, ada penjelasan yang lebih sederhana: radar dihidupkan sebelum mendarat hanya agar tetap hangat jika terjadi kecelakaan selama interupsi, dan berada dalam mode AUTO (jika modul lunar berada pada posisi yang memungkinkan Anda untuk melacak modul perintah) atau SLEW (pada waktu lain), hanya untuk mencegah pergerakan antena yang tidak berguna.
Gambar 7.
PGNS, ATCA, dan Proximity Radar InterfacesMasalah ini sering dikaitkan (termasuk oleh penulis sebelumnya) hanya sebagai kesalahan dalam daftar periksa. Ini adalah kata-kata yang tidak akurat, seperti halnya tidak tepat untuk memanggil shutdown monitor prematur
mesin delta-V pada modul bulan adalah "kesalahan komputer", sedangkan sebenarnya kesalahan itu ada dalam dokumentasi. Bahkan, posisi saklar radar proximity Apollo 11 seharusnya tidak menyebabkan masalah. Tetapi dari sini Anda dapat melacak kesalahan lain dalam dokumentasi.
Bertahun-tahun sebelumnya, dokumentasi ditulis pada dokumen kontrol antarmuka (ICD), yang mendefinisikan antarmuka listrik antara PGNS dan ATCA (perakitan kontrol terjemahan) elektronik, yang dipasok oleh Grumman Aerospace, perusahaan yang membangun modul pendaratan. ICD menetapkan bahwa rangkaian catu daya 28V dengan frekuensi 800 Hz dalam dua sistem harus diselaraskan dalam frekuensi, tetapi tidak tertulis bahwa mereka harus disinkronkan dalam fase. Faktanya, kedua sistem tersebut selaras frekuensi dengan sinyal “sinkronisasi frekuensi” yang dikirim oleh LGC. Mereka memiliki hubungan fase yang konstan. Namun, fase antara dua tegangan adalah variabel yang benar-benar acak, tergantung pada momen di mana LGC, yang selalu didukung setelah ACTA, mulai mengirim sinyal sinkronisasi. Antarmuka ini ditunjukkan dalam gambar. 7.
Masalah dengan fase 800 Hz terdeteksi ketika menguji modul pendaratan LM-3 dan didokumentasikan, tetapi belum pernah diperbaiki. Akibatnya, ketika sakelar mode radar berada dalam posisi AUTO atau SLEW, mekanisme putar radar bersemangat oleh sinyal 800 Hz dari ATCA, yang dengan probabilitas tinggi tidak bertepatan dalam fase dengan sinyal 800 Hz, yang digunakan sebagai referensi dalam CDU yang mengubah sinyal dari mekanisme untuk berubah menjadi data untuk komputer, dan decrementing (atau decrementing) penghitung di komputer yang memberitahu program bagaimana antena diputar.
Namun pada Apollo 11, CDU bekerja secara berbeda. Karena mereka mengambil tegangan yang dihasilkan secara terpisah sebagai sinyal referensi, sinyal sensor sudut antena yang diterima oleh CDU menunjukkan sudut yang tidak diketahui. Kesalahan terbesar jika perbedaan fasa mendekati 90 atau 270 derajat, dan Apollo 11, jelas, mengenai salah satu poin menarik ini. Sebagai tanggapan, CDU mulai menambah atau mengurangi penghitung LGC pada kecepatan yang hampir konstan, sekitar 6400 pulsa per detik untuk masing-masing sudut. Ini terjadi setiap kali sakelar berada dalam mode SLEW atau AUTO, terlepas dari apakah radar kedekatan dihidupkan.
Penghitung CDU di LGC bertambah atau dikurangi oleh sinyal eksternal yang diproses di komputer. Ini memakan waktu, dalam hal ini satu siklus memori 11,7 μs masing-masing. Jika penghitung bertambah pada kecepatan maksimum, butuh sekitar 15% dari total waktu (waktu nyasar ini disebut TLOSS). Kami saat ini memberikan perkiraan konservatif dari waktu yang dihabiskan sebesar 13%, yang konsisten dengan perilaku yang diamati.
Setelah penerbangan Apollo 11, insinyur Grumman melakukan tes dalam upaya mereproduksi perilaku komputer yang diamati dalam penerbangan. Mereka mengkonfirmasi bahwa bahkan dalam kasus terburuk, CDU tidak dapat mengirim pulsa pada kecepatan maksimum. Mereka sampai pada kesimpulan bahwa beban komputer maksimum dengan meter ini (TLOSS) bisa 13,36%. Selama simulasi, kesalahan serupa dengan yang terjadi dalam penerbangan direproduksi. Dengan demikian, nilai TLOSS yang dikutip adalah perkiraan terbaik didokumentasikan beban komputer Apollo 11. [Clint Tillman, “Mensimulasikan RR-CDU Interface Ketika RR berada dalam Mode SLEW atau AUTO (bukan LGC) di Laboratorium FMES / FCI,” 9 Agustus , 1969]
Saya berhutang budi kepada pakar sistem bimbingan modul bulan George Silver untuk penjelasan pasiennya tentang antarmuka radar pertemuan modul bulan. Dia memainkan peran sentral dalam misi Apollo 11. Pada saat peluncuran, dia berada di Cape Canaveral, kemudian terbang ke Boston, ke Cambridge, untuk bertugas memantau lepas landas dari Bulan. Dia menyaksikan bulan mendarat di rumah di TV pada 20 Juli. Dia mendengar bunyi alarm, menebak bahwa ada sesuatu yang menghabiskan waktu komputer, dan mengingat kasus yang dia lihat saat menguji sistem LM-3, ketika radar kedekatan menyebabkan aktivitas panik counter. Setelah beberapa analisis lebih lanjut oleh tim pemantauan misi Cambridge, Silver akhirnya menghubungi MIT di Houston pada pagi hari 21 Juli, kurang dari satu jam sebelum lepas landas dari bulan.
Fragmen kontrol manual* * *
Mendarat di bulan adalah fase penerbangan paling intens. Sistem kontrol pendaratan harus mencapai tujuan dengan koordinat tertentu, memiliki kecepatan tertentu, akselerasi, derajat menyentak (derajat perubahan / akselerasi). Klumpp disebut tingkat perubahan brengsek "jepret," dan dua turunan berikutnya disebut "crackle" dan "pop." Dalam fase visibilitas (
yaitu, ketika permukaan bulan terlihat di jendela kapal, kira-kira terjemahan. ) program ini memungkinkan kru untuk mengubah situs pendaratan. Throttle dikendalikan terus-menerus. Navigasi termasuk pengukuran menggunakan radar pendaratan. Gambar 8. menunjukkan profil beban khas antara pilihan fase P63 dan menyentuh permukaan bulan.
Fig. 8:
Memuat saat pendaratan (data simulator)Bahkan di bawah kondisi ini, kami mencoba membuat program kami cukup cepat untuk memiliki cukup waktu jika TLOSS besar. Keterbatasan utama adalah periode dua detik, yang dibangun ke dalam program "rata-rata G" yang digunakan selama fase penerbangan.
Ini adalah periode di mana tugas READACCS membaca pembacaan accelerometer dan meluncurkan tugas SERVICER, yang menggunakan nilai-nilai ini sebagai data awal untuk iterasi baru dari perhitungan lintasan, melambatkan mesin, menentukan posisi kapal dan menampilkannya di layar. Selama pendaratan, tingkat beban komputer hanya menunjukkan berapa banyak waktu yang dihabiskan untuk tugas dan gangguan selama setiap periode dua detik.Selama fase pengereman, sampai radar pendaratan melihat permukaan, waktu cadangan setidaknya 15%. Setelah radar dioperasikan, perhitungan tambahan dimulai, terkait dengan transfer koordinat dari sistem referensi radar ke sistem koordinat untuk navigasi, yang mengurangi margin sebesar 13%. Saat tampilan dimulai (kata kerja 16, kata benda 68), margin berkurang hingga 10% atau lebih rendah. Baz Aldrin perseptif ketika dia mengatakan setelah sinyal 1202, "sepertinya dia muncul ketika kita memasuki 1668" [16].Ketika margin 10% dan 13% diambil, LGC tidak memiliki cukup waktu prosesor untuk melakukan semua fungsi yang diperlukan. Karena fleksibilitas desain Eksekutif, dan tidak seperti apa yang akan terjadi dengan arsitektur yang kaku, tidak ada bencana.Tabel 1. Tugas aktif saat mendarat di bulan.
Tabel 1 mencantumkan tugas-tugas yang aktif saat mendarat Apollo 11. SERVICER memiliki prioritas terendah, dan berjalan paling lama. Tugas dengan prioritas tinggi dapat menghentikan SERVICER, tetapi mereka memiliki waktu tunggu yang relatif singkat.Karena SERVICER memiliki prioritas rendah karena ukurannya yang besar, SERVICER mogok karena kurangnya waktu komputasi. Dengan margin negatif dalam waktu, SERVICER tidak berhasil memberikan jawaban ketika READACCS, yang dimulai dengan jadwal, mulai lagi, dan memulai SERVICER lagi. Karena salinan SERVICER sebelumnya tidak menyelesaikan perhitungan, itu tidak membebaskan register dan array VAC, dan READACCS memanggil FINDVAC ke Eksekutif untuk mengalokasikan register baru dan array VAC dan memulai SERVICER. SERVICER ini juga tidak menyelesaikan pekerjaan tepat waktu. Setelah siklus pendek dari operasi tersebut, register dan array VAC berakhir. Ketika permintaan berikut datang ke Eksekutif, BAILOUT dipanggil dengan kode 1201 atau 1202.
Gbr. 9: Operasi SERVICER tanpa dan dengan TLOSSFig.
Gambar 9 menunjukkan bagaimana SERVICER berperilaku dengan TLOSS yang kuat, dan dalam gambar. Gambar 10 menunjukkan perbandingan register dan set VAC selama operasi normal dan dengan TLOSS yang kuat, selama restart terjadi.
Fig.
10. Efek yang dihasilkan oleh TLOSS pada sumber daya Eksekutif dan Daftar Tunggu selama pendaratan di bulan (data simulator dimulai dengan fase P63 sebelum menerima data kecepatan dari radar dan berakhir dengan pendaratan [17].)Efek yang menarik dari urutan peristiwa ini selama fase P63 , adalah bahwa masalahnya dihilangkan sendiri. Restart perangkat lunak hanya mengembalikan salinan terbaru dari tugas SERVICER, dan menghapus semua salinan SERVICER yang tidak lengkap. Selain itu, ia menyelesaikan semua fungsi yang tidak memiliki perlindungan terhadap restart karena mereka tidak kritis, termasuk monitor DELTAH (kata kerja 16, kata benda 68). Ini menyebabkan tampilan beralih dari “kata benda 68” ke “kata benda 63” setelah dua alarm di P63.Sistem proteksi restart awalnya dikembangkan karena kemungkinan kegagalan perangkat keras dan memberikan pengurangan pada beban komputasi dengan TLOSS yang besar. Sistem waktu nyata yang kami kembangkan ternyata tahan terhadap kesalahan dalam kondisi tertentu.Selama fase P64, situasinya berbeda. Selain persamaan gerak yang biasa, pemrosesan tambahan ditambahkan yang mencakup kemampuan untuk menetapkan kembali lokasi pendaratan. Fitur perangkat lunak tambahan meninggalkan margin waktu kurang dari 10%. Alarm terus muncul. Tiga alarm dari 1201 dan 1202 terjadi dalam 40 detik. Setiap kali, perangkat lunak restart, membersihkan antrian tugas, tetapi tidak dapat mengurangi beban.Waktu misi 102: 43: 08, mengantisipasi alarm berikutnya, Armstrong mengalihkan autopilot dari mode AUTO ke ATT HOLD, melemahkan beban komputasi, dan kemudian memasuki mode P66 semi-manual, di mana beban komputer rendah. Setelah 2 menit dan 20 detik bermanuver dalam fase P66, modul bulan duduk.