Pertanyaan Menyusun aplikasi untuk digunakan di lingkungan yang sangat radioaktif


Kami menyusun aplikasi C / C ++ yang disematkan yang ditempatkan di perangkat terlindung di lingkungan yang dibombardir radiasi pengion. Kami menggunakan GCC dan cross-compiling untuk ARM. Ketika disebarkan, aplikasi kami menghasilkan beberapa data yang salah dan crash lebih sering daripada yang kami inginkan. Perangkat keras dirancang untuk lingkungan ini, dan aplikasi kami telah berjalan di platform ini selama beberapa tahun.

Adakah perubahan yang dapat kami lakukan terhadap kode kami, atau peningkatan waktu kompilasi yang dapat dilakukan untuk mengidentifikasi / mengoreksi kesalahan lunak dan memori-korupsi yang disebabkan oleh gangguan acara tunggal? Apakah ada pengembang lain yang berhasil mengurangi efek berbahaya dari kesalahan lunak pada aplikasi yang sudah lama berjalan?


1278
2018-04-24 19:09


asal


Jawaban:


Bekerja selama sekitar 4-5 tahun dengan pengembangan perangkat lunak / firmware dan pengujian lingkungan satelit miniatur*, Saya ingin berbagi pengalaman saya di sini.

* (satelit miniatur lebih rentan terhadap gangguan acara tunggal daripada satelit yang lebih besar karena ukurannya yang relatif kecil, terbatas untuk komponen elektroniknya)

Sangat ringkas dan langsung: tidak ada mekanisme untuk pulih terdeteksi, salah   situasi oleh perangkat lunak / firmware itu sendiri tanpa, setidaknya satu    salinan dari versi kerja minimum perangkat lunak / firmware suatu tempat untuk pemulihan tujuan - dan dengan perangkat keras yang mendukung pemulihan (fungsional).

Sekarang, situasi ini biasanya ditangani baik di tingkat perangkat keras dan perangkat lunak. Di sini, saat Anda meminta, saya akan membagikan apa yang dapat kami lakukan di tingkat perangkat lunak.

  1. ... tujuan pemulihan .... Memberikan kemampuan untuk memperbarui / mengkompilasi ulang / memantulkan perangkat lunak / firmware Anda di lingkungan nyata. Ini adalah sebuah hampir harus dimiliki fitur untuk perangkat lunak / firmware apa pun dalam lingkungan yang terionisasi tinggi. Tanpa ini, kamu bisa memiliki perangkat lunak / perangkat keras berlebihan sebanyak yang Anda inginkan, tetapi pada satu titik, semuanya akan meledak. Jadi, siapkan fitur ini!

  2. ... versi kerja minimum ... Memiliki beberapa salinan yang responsif, versi minimum dari perangkat lunak / firmware dalam kode Anda. Ini seperti Safe mode di Windows. Daripada hanya memiliki satu versi perangkat lunak Anda yang berfungsi penuh, miliki beberapa salinan dari versi minimum perangkat lunak / firmware Anda. Salinan minimum biasanya memiliki ukuran yang jauh lebih kecil daripada salinan lengkap dan hampir selalu ada hanya dua atau tiga fitur berikut:

    1. mampu mendengarkan perintah dari sistem eksternal,
    2. mampu memperbarui perangkat lunak / firmware terkini,
    3. mampu memonitor data housekeeping operasi dasar.
  3. ... menyalin ... di suatu tempat ... Memiliki perangkat lunak / firmware yang berlebihan di suatu tempat.

    1. Anda bisa, dengan atau tanpa perangkat keras yang berlebihan, cobalah untuk memiliki perangkat lunak / firmware redundan di ARM UC Anda. Ini biasanya dilakukan dengan memiliki dua atau lebih perangkat lunak / firmware yang identik di alamat terpisah yang mengirim detak jantung satu sama lain - tetapi hanya satu yang akan aktif dalam satu waktu. Jika satu atau lebih perangkat lunak / firmware diketahui tidak responsif, beralihlah ke perangkat lunak / firmware lain. Manfaat menggunakan pendekatan ini adalah kita dapat memiliki penggantian fungsional segera setelah kesalahan terjadi - tanpa kontak dengan sistem eksternal / pihak manapun yang bertanggung jawab untuk mendeteksi dan memperbaiki kesalahan (dalam kasus satelit, biasanya Pusat Pengontrol Misi) MCC)).

      Sebenarnya, tanpa perangkat keras yang berlebihan, kerugian dari melakukan ini adalah Anda sebenarnya tidak bisa menghapuskan semua satu titik kegagalan. Setidaknya, Anda masih akan memilikinya satu satu titik kegagalan, yaitu sakelar itu sendiri (atau sering kali diawal kode). Namun demikian, untuk perangkat yang dibatasi oleh ukuran dalam lingkungan yang terionisasi tinggi (seperti satelit pico / femto), pengurangan titik tunggal kegagalan ke satu titik tanpa hardware tambahan akan tetap layak dipertimbangkan. Somemore, potongan kode untuk peralihan tentu akan jauh lebih sedikit daripada kode untuk seluruh program - secara signifikan mengurangi risiko mendapatkan Single Event di dalamnya.

    2. Tetapi jika Anda tidak melakukan ini, Anda harus memiliki setidaknya satu salinan dalam sistem eksternal Anda yang dapat bersentuhan dengan perangkat dan memperbarui perangkat lunak / firmware (dalam kasus satelit, itu lagi pusat kendali misi).

    3. Anda juga dapat memiliki salinan di penyimpanan memori permanen di perangkat Anda yang dapat dipicu untuk memulihkan perangkat lunak / firmware sistem yang berjalan
  4. ... situasi yang salah terdeteksi .. Kesalahan itu harus terdeteksi, biasanya oleh perangkat keras koreksi kesalahan / rangkaian deteksi atau dengan sepotong kode kecil untuk koreksi / deteksi kesalahan. Yang terbaik adalah menempatkan kode seperti itu kecil, banyak, dan independen dari perangkat lunak / firmware utama. Tugas utamanya adalah hanya untuk memeriksa / mengoreksi. Jika rangkaian perangkat keras / firmware dapat diandalkan (seperti lebih banyak radiasi yang mengeras daripada yang tersisa - atau memiliki banyak sirkuit / logika), maka Anda mungkin mempertimbangkan untuk melakukan koreksi kesalahan dengannya. Tetapi jika tidak, lebih baik menjadikannya sebagai deteksi kesalahan. Koreksi dapat dilakukan oleh sistem / perangkat eksternal. Untuk koreksi kesalahan, Anda dapat mempertimbangkan untuk menggunakan algoritma koreksi kesalahan dasar seperti Hamming / Golay23, karena mereka dapat diimplementasikan dengan lebih mudah baik di sirkuit / perangkat lunak. Tetapi pada akhirnya tergantung pada kemampuan tim Anda. Untuk deteksi kesalahan, biasanya CRC digunakan.

  5. ... perangkat keras yang mendukung pemulihan Sekarang, sampai pada aspek yang paling sulit dalam masalah ini. Pada akhirnya, pemulihan membutuhkan perangkat keras yang bertanggung jawab untuk pemulihan paling sedikit fungsional. Jika perangkat keras rusak secara permanen (biasanya terjadi setelah itu Total dosis pengion mencapai tingkat tertentu), maka ada (sayangnya) tidak ada cara bagi perangkat lunak untuk membantu pemulihan. Dengan demikian, perangkat keras adalah hal yang paling penting untuk perangkat yang terkena radiasi tinggi (seperti satelit).

Selain saran untuk mengantisipasi kesalahan firmware di atas karena kesengajaan acara tunggal, saya juga ingin menyarankan Anda untuk memiliki:

  1. Deteksi kesalahan dan / atau koreksi kesalahan algoritma dalam protokol komunikasi antar-subsistem. Ini adalah hal lain yang hampir harus dilakukan untuk menghindari sinyal yang tidak lengkap / salah diterima dari sistem lain

  2. Filter dalam pembacaan ADC Anda. Melakukan tidak gunakan pembacaan ADC secara langsung. Filter dengan filter median, filter rata-rata, atau filter lainnya - tak pernah percaya nilai bacaan tunggal. Sampel lebih banyak, tidak kurang - cukup.


729
2018-04-25 02:58



NASA punya sebuah makalah tentang radiasi-mengeras perangkat lunak. Ini menjelaskan tiga tugas utama:

  1. Pemantauan memori secara teratur untuk kesalahan kemudian menghapus kesalahan tersebut,
  2. mekanisme pemulihan kesalahan yang kuat, dan
  3. kemampuan untuk mengkonfigurasi ulang jika sesuatu tidak berfungsi lagi.

Perhatikan bahwa tingkat pemindaian memori harus cukup sering sehingga kesalahan multi-bit jarang terjadi, seperti kebanyakan ECC memori dapat pulih dari kesalahan bit tunggal, bukan kesalahan multi-bit.

Pemulihan kesalahan yang kuat termasuk transfer aliran kontrol (biasanya memulai ulang proses pada suatu titik sebelum kesalahan), rilis sumber daya, dan pemulihan data.

Rekomendasi utama mereka untuk restorasi data adalah untuk menghindari kebutuhan untuk itu, melalui data perantara diperlakukan sebagai sementara, sehingga restart sebelum kesalahan juga menggulung kembali data ke keadaan yang dapat diandalkan. Ini terdengar mirip dengan konsep "transaksi" dalam basis data.

Mereka membahas teknik yang sangat cocok untuk bahasa berorientasi objek seperti C ++. Sebagai contoh

  1. ECC berbasis perangkat lunak untuk objek memori bersebelahan
  2. Pemrograman berdasarkan Kontrak: memverifikasi prakondisi dan postconditions, lalu memeriksa objek untuk memverifikasi itu masih dalam keadaan yang valid.

370
2018-04-24 19:32



Berikut beberapa pemikiran dan gagasan:

Gunakan ROM lebih kreatif.

Simpan apa pun yang Anda bisa di ROM. Daripada menghitung sesuatu, simpan tabel pencarian di ROM. (Pastikan compiler Anda mengeluarkan tabel pencarian Anda ke bagian read-only! Cetak alamat memori pada saat runtime untuk memeriksa!) Simpan tabel vektor interrupt Anda di ROM. Tentu saja, jalankan beberapa tes untuk melihat seberapa andal ROM Anda dibandingkan dengan RAM Anda.

Gunakan RAM terbaik Anda untuk stack.

SEU dalam tumpukan mungkin merupakan sumber crash yang paling mungkin, karena di sinilah hal-hal seperti variabel indeks, variabel status, alamat kembali, dan pointer dari berbagai jenis biasanya hidup.

Mengimplementasikan timer-tick dan rutinitas pengawas waktu pengawas.

Anda dapat menjalankan rutinitas "pemeriksaan kewarasan" setiap klik waktu, serta rutinitas pengawas untuk menangani penguncian sistem. Kode utama Anda juga dapat secara berkala meningkatkan penghitung untuk menunjukkan kemajuan, dan rutinitas pemeriksaan kewarasan dapat memastikan hal ini terjadi.

Melaksanakan kesalahan-mengoreksi-kode dalam perangkat lunak.

Anda dapat menambahkan redundansi ke data Anda untuk dapat mendeteksi dan / atau memperbaiki kesalahan. Ini akan menambah waktu pemrosesan, berpotensi membiarkan prosesor terkena radiasi untuk waktu yang lebih lama, sehingga meningkatkan kemungkinan kesalahan, jadi Anda harus mempertimbangkan trade-off.

Ingat cache.

Periksa ukuran cache CPU Anda. Data yang Anda akses atau modifikasi baru-baru ini mungkin akan berada dalam cache. Saya yakin Anda dapat menonaktifkan setidaknya beberapa cache (dengan biaya kinerja besar); Anda harus mencoba ini untuk melihat seberapa rentan cache untuk SEU. Jika cache lebih keras dari RAM maka Anda dapat secara teratur membaca dan menulis ulang data penting untuk memastikannya tetap dalam cache dan membawa RAM kembali ke jalur.

Gunakan penangan kesalahan-halaman dengan cerdik.

Jika Anda menandai halaman memori sebagai tidak hadir, CPU akan mengeluarkan kesalahan halaman saat Anda mencoba untuk mengaksesnya. Anda dapat membuat penangan kesalahan-halaman yang memeriksa sebelum melayani permintaan baca. (Sistem operasi PC menggunakan ini untuk memuat secara transparan halaman yang telah di-swap ke disk.)

Gunakan bahasa assembly untuk hal-hal penting (yang bisa menjadi segalanya).

Dengan bahasa assembly, Anda tahu apa yang ada di register dan apa yang ada di RAM; kamu tahu apa tabel RAM khusus yang digunakan CPU, dan Anda dapat merancang berbagai hal secara tidak langsung untuk mengurangi risiko Anda.

Menggunakan objdump untuk benar-benar melihat bahasa assembly yang dihasilkan, dan mencari tahu berapa banyak kode yang diperlukan setiap rutinitas Anda.

Jika Anda menggunakan OS besar seperti Linux maka Anda meminta masalah; ada begitu banyak kerumitan dan banyak hal yang salah.

Ingat itu adalah permainan probabilitas.

Seorang komentator berkata

Setiap rutinitas yang Anda tulis untuk menangkap kesalahan akan dapat gagal dari penyebab yang sama.

Meskipun ini benar, kemungkinan kesalahan dalam (katakanlah) 100 byte kode dan data yang diperlukan untuk rutinitas cek berfungsi dengan benar jauh lebih kecil daripada kemungkinan kesalahan di tempat lain. Jika ROM Anda cukup andal dan hampir semua kode / data benar-benar dalam ROM maka peluang Anda lebih baik.

Gunakan perangkat keras redundan.

Gunakan 2 atau lebih pengaturan perangkat keras identik dengan kode yang identik. Jika hasilnya berbeda, reset harus dipicu. Dengan 3 atau lebih perangkat, Anda dapat menggunakan sistem "voting" untuk mencoba mengidentifikasi mana yang telah dikompromikan.


107
2018-04-24 23:11



Anda mungkin juga tertarik dengan literatur yang kaya tentang masalah toleransi kesalahan algoritmik. Ini termasuk penugasan lama: Tulis semacam yang dengan benar mengurutkan inputnya ketika sejumlah perbandingan konstan akan gagal (atau, versi yang sedikit lebih jahat, ketika angka asymptotic dari perbandingan perbandingan gagal sebagai log(n) untuk n perbandingan).

Tempat untuk mulai membaca adalah kertas Huang dan Abraham tahun 1984 "Toleransi Kesalahan Berbasis Algoritma untuk Operasi Matriks". Ide mereka agak mirip dengan komputasi terenkripsi homomorphic (tetapi tidak benar-benar sama, karena mereka mencoba deteksi kesalahan / koreksi pada tingkat operasi).

Keturunan yang lebih baru dari makalah itu adalah Bosilca, Delmas, Dongarra, dan Langou "Toleransi kesalahan berbasis algoritme diterapkan pada komputasi kinerja tinggi".


93
2018-04-24 21:13



Menulis kode untuk lingkungan radioaktif sebenarnya tidak berbeda dengan menulis kode untuk aplikasi mission-critical apa pun.

Selain apa yang telah disebutkan, berikut ini beberapa tips lain:

  • Gunakan langkah-langkah keamanan "roti & mentega" setiap hari yang harus ada pada sistem embedded semi-profesional: pengawas internal, deteksi tegangan rendah internal, monitor jam internal. Hal-hal ini bahkan tidak perlu disebutkan pada tahun 2016 dan mereka standar pada hampir semua mikrokontroler modern.
  • Jika Anda memiliki MCU keselamatan dan / atau otomotif yang berorientasi, itu akan memiliki fitur pengawas tertentu, seperti jendela waktu tertentu, di dalamnya Anda perlu menyegarkan pengawas. Ini lebih disukai jika Anda memiliki sistem real-time mission-critical.
  • Secara umum, gunakan MCU yang cocok untuk sistem semacam ini, dan bukan beberapa fluff mainstream umum yang Anda terima dalam paket serpihan jagung. Hampir setiap MCU produsen saat ini memiliki MCU khusus yang dirancang untuk aplikasi keamanan (TI, Freescale, Renesas, ST, Infineon dll). Ini memiliki banyak fitur keamanan built-in, termasuk core langkah kunci: artinya ada 2 core CPU yang mengeksekusi kode yang sama, dan mereka harus saling menyetujui.
  • PENTING: Anda harus memastikan integritas register MCU internal. Semua daftar kontrol & status periferal perangkat keras yang dapat ditulis dapat ditempatkan dalam memori RAM, dan karenanya rentan.

    Untuk melindungi diri Anda dari korupsi register, sebaiknya pilih mikrokontroler dengan fitur register "write-once" yang sudah terpasang. Selain itu, Anda perlu menyimpan nilai default dari semua register perangkat keras dalam NVM dan menyalin nilai-nilai tersebut ke register Anda secara berkala. Anda dapat memastikan integritas variabel penting dengan cara yang sama.

    Catatan: selalu gunakan pemrograman defensif. Berarti Anda harus mengatur semua mendaftar di MCU dan bukan hanya yang digunakan oleh aplikasi. Anda tidak ingin perangkat perangkat keras acak tiba-tiba bangun.

  • Ada berbagai macam metode untuk memeriksa kesalahan dalam RAM atau NVM: checksum, "pola berjalan", perangkat lunak ECC dll. Solusi terbaik saat ini adalah tidak menggunakan semua ini, tetapi untuk menggunakan MCU dengan ECC internal dan pemeriksaan serupa. Karena melakukan hal ini dalam perangkat lunak itu rumit, dan pemeriksaan kesalahan itu sendiri dapat menyebabkan bug dan masalah tak terduga.

  • Gunakan redundansi. Anda dapat menyimpan memori volatile dan non-volatile dalam dua segmen "mirror" identik, yang harus selalu setara. Setiap segmen bisa memiliki CRC checksum yang terpasang.
  • Hindari menggunakan memori eksternal di luar MCU.
  • Menerapkan operator standar interrupt rutin / pengendali pengecualian default untuk semua kemungkinan interupsi / pengecualian. Bahkan yang tidak Anda gunakan. Rutinitas default seharusnya tidak melakukan apa-apa kecuali mematikan sumber interupsi sendiri.
  • Memahami dan merangkul konsep pemrograman defensif. Ini berarti bahwa program Anda perlu menangani semua kemungkinan kasus, bahkan yang tidak dapat terjadi dalam teori. Contoh.

    Firmware mission-critical berkualitas tinggi mendeteksi sebanyak mungkin kesalahan, dan kemudian mengabaikannya dengan cara yang aman.

  • Jangan pernah menulis program yang bergantung pada perilaku yang tidak ditentukan dengan baik. Sangat mungkin bahwa perilaku tersebut mungkin berubah secara drastis dengan perubahan perangkat keras yang tak terduga yang disebabkan oleh radiasi atau EMI. Cara terbaik untuk memastikan bahwa program Anda bebas dari omong kosong seperti itu adalah dengan menggunakan standar pengkodean seperti MISRA, bersama dengan alat penganalisis statis. Ini juga akan membantu dengan pemrograman defensif dan dengan menyingkirkan bug (mengapa Anda tidak ingin mendeteksi bug dalam segala jenis aplikasi?).
  • PENTING: Jangan menerapkan ketergantungan apa pun dari nilai default dari variabel durasi penyimpanan statis. Artinya, jangan mempercayai isi default dari .data atau .bss. Mungkin ada banyak waktu antara titik inisialisasi ke titik di mana variabel benar-benar digunakan, mungkin ada banyak waktu bagi RAM untuk menjadi rusak. Sebaliknya, tulis program sehingga semua variabel tersebut ditetapkan dari NVM di run-time, tepat sebelum waktu ketika variabel tersebut digunakan untuk pertama kalinya.

    Dalam prakteknya ini berarti bahwa jika suatu variabel dideklarasikan di ruang lingkup file atau sebagai static, Anda tidak boleh menggunakannya = untuk menginisialisasi (atau Anda bisa, tetapi tidak ada gunanya, karena Anda tidak dapat mengandalkan nilai bagaimanapun). Selalu atur dalam waktu berjalan, tepat sebelum digunakan. Jika mungkin untuk berulang kali memperbarui variabel tersebut dari NVM, maka lakukanlah.

    Demikian pula di C ++, jangan bergantung pada konstruktor untuk variabel durasi penyimpanan statis. Mintalah konstruktor (s) memanggil rutin "set-up" publik, yang juga dapat Anda hubungi nanti dalam waktu berjalan, langsung dari aplikasi pemanggil.

    Jika memungkinkan, hapus kode start-up "copy-down" yang menginisialisasi .data dan .bss (dan panggil C ++ constructors) sepenuhnya, sehingga Anda mendapatkan kesalahan linker jika Anda menulis kode yang mengandalkan hal tersebut. Banyak kompiler memiliki opsi untuk melewati ini, biasanya disebut "minimal / cepat start-up" atau serupa.

    Ini berarti bahwa setiap pustaka eksternal harus diperiksa sehingga tidak mengandung ketergantungan seperti itu.

  • Terapkan dan tentukan keadaan aman untuk program, ke tempat Anda akan kembali jika terjadi kesalahan kritis.

  • Menerapkan sistem laporan kesalahan / log kesalahan selalu membantu.

36
2018-04-27 14:11



Dimungkinkan untuk menggunakan C untuk menulis program yang berperilaku kuat dalam lingkungan seperti itu, tetapi hanya jika sebagian besar bentuk optimasi kompilator dinonaktifkan. Mengoptimalkan kompiler dirancang untuk menggantikan banyak pola pengkodean yang tampaknya-redundan dengan yang "lebih efisien", dan mungkin tidak memiliki petunjuk bahwa alasan programmer sedang menguji x==42 ketika kompiler tahu tidak ada cara x mungkin bisa memegang yang lain adalah karena programmer ingin mencegah eksekusi kode tertentu dengan xmemegang beberapa nilai lain - bahkan dalam kasus di mana satu-satunya cara itu bisa memegang nilai itu jika sistem menerima semacam gangguan listrik.

Mendeklarasikan variabel sebagai volatile sering membantu, tetapi mungkin bukan obat mujarab. Yang sangat penting, perhatikan bahwa pengkodean yang aman sering membutuhkan hal yang berbahaya operasi memiliki interlock perangkat keras yang memerlukan beberapa langkah untuk diaktifkan, dan kode itu ditulis menggunakan pola:

... code that checks system state
if (system_state_favors_activation)
{
  prepare_for_activation();
  ... code that checks system state again
  if (system_state_is_valid)
  {
    if (system_state_favors_activation)
      trigger_activation();
  }
  else
    perform_safety_shutdown_and_restart();
}
cancel_preparations();

Jika kompiler menerjemahkan kode dengan cara yang relatif harfiah, dan jika semua pemeriksaan untuk status sistem diulang setelah prepare_for_activation(), sistem ini mungkin kuat terhadap hampir semua peristiwa glitch tunggal yang masuk akal, bahkan mereka yang secara sewenang-wenang merusak meja dan menumpuk program. Jika kesalahan terjadi hanya setelah panggilan ke prepare_for_activation(), itu berarti aktivasi itu akan sesuai (karena tidak ada alasan lain prepare_for_activation() akan dipanggil sebelum kesalahan). Jika itu kesalahan menyebabkan kode untuk dijangkau prepare_for_activation() tidak tepat, tetapi di sana tidak ada peristiwa kesalahan berikutnya, tidak akan ada cara untuk kode untuk selanjutnya mencapai trigger_activation() tanpa melewati pemeriksaan validasi atau memanggil cancel_preparations terlebih dahulu [jika tumpukan gangguan, eksekusi dapat dilanjutkan ke tempat tepat sebelum trigger_activation() setelah konteks yang disebut prepare_for_activation() mengembalikan, tetapi panggilan ke cancel_preparations() akan terjadi antara panggilan ke prepare_for_activation() dan trigger_activation(), sehingga membuat panggilan terakhir tidak berbahaya.

Kode tersebut mungkin aman dalam C tradisional, tetapi tidak dengan kompiler C modern. Kompiler semacam itu dapat sangat berbahaya dalam lingkungan semacam itu karena agresif mereka berusaha untuk hanya memasukkan kode yang akan relevan dalam situasi yang dapat terjadi melalui beberapa mekanisme yang terdefinisi dengan baik dan konsekuensi yang dihasilkannya juga akan terdefinisi dengan baik. Kode yang tujuannya adalah untuk mendeteksi dan membersihkan setelah kegagalan mungkin, dalam beberapa kasus, berakhir dengan memperburuk keadaan. Jika compiler menentukan bahwa upaya pemulihan dalam beberapa kasus akan mengaktifkan perilaku yang tidak terdefinisi, ia dapat menyimpulkan bahwa kondisi yang akan mengharuskan pemulihan seperti itu dalam kasus-kasus seperti itu tidak mungkin terjadi, sehingga menghilangkan kode yang akan diperiksa untuk mereka.


30
2018-04-25 16:14



Ini adalah subjek yang sangat luas. Pada dasarnya, Anda tidak dapat benar-benar pulih dari kerusakan memori, tetapi setidaknya Anda bisa mencobanya gagal dengan segera. Berikut beberapa teknik yang dapat Anda gunakan:

  • data konstan checksum. Jika Anda memiliki data konfigurasi yang tetap konstan untuk waktu yang lama (termasuk register perangkat keras yang telah Anda konfigurasikan), hitung checksumnya pada inisialisasi dan verifikasi secara berkala. Ketika Anda melihat ketidakcocokan, saatnya untuk menginisialisasi ulang atau mengatur ulang.

  • variabel toko dengan redundansi. Jika Anda memiliki variabel penting x, tulis nilainya di x1, x2 dan x3 dan bacalah sebagai (x1 == x2) ? x2 : x3.

  • melaksanakan pemantauan aliran program. XOR bendera global dengan nilai unik dalam fungsi / cabang penting yang dipanggil dari loop utama. Menjalankan program dalam lingkungan bebas radiasi dengan cakupan uji mendekati 100% akan memberi Anda daftar nilai yang dapat diterima dari bendera di akhir siklus. Setel ulang jika Anda melihat penyimpangan.

  • pantau penunjuk tumpukan. Di awal loop utama, bandingkan stack pointer dengan nilai yang diharapkan. Setel ulang pada penyimpangan.


27
2018-04-25 17:05



Apa yang bisa membantu Anda adalah a penjaga. Watchdog digunakan secara luas dalam komputasi industri pada tahun 1980-an. Kegagalan hardware lebih umum saat itu - jawaban lain juga mengacu pada periode itu.

Pengawas adalah gabungan fitur perangkat keras / perangkat lunak. Perangkat keras adalah penghitung sederhana yang menghitung mundur dari angka (katakanlah 1023) ke nol. TTL atau logika lain bisa digunakan.

Perangkat lunak ini dirancang sedemikian rupa sehingga satu rutin memantau operasi yang benar dari semua sistem penting. Jika rutinitas ini selesai dengan benar = menemukan komputer berjalan dengan baik, ia akan mengembalikan counter ke 1023.

Desain keseluruhannya adalah agar dalam keadaan normal, perangkat lunak mencegah penghitung perangkat keras akan mencapai nol. Jika counter mencapai nol, perangkat keras dari counter melakukan tugas satu-satunya dan mengatur ulang seluruh sistem. Dari perspektif counter, nol sama dengan 1024 dan konter terus menghitung mundur lagi.

Pengawas ini memastikan bahwa komputer yang terpasang dihidupkan ulang dalam banyak, banyak kasus kegagalan. Saya harus mengakui bahwa saya tidak akrab dengan perangkat keras yang mampu melakukan fungsi seperti itu pada komputer saat ini. Antarmuka ke perangkat keras eksternal sekarang jauh lebih kompleks daripada dulu.

Kerugian inheren dari pengawas adalah bahwa sistem tidak tersedia dari saat gagal sampai counter pengawas mencapai nol + waktu reboot. Sementara waktu itu umumnya jauh lebih singkat daripada intervensi eksternal atau manusia, peralatan yang didukung harus dapat melanjutkan tanpa kontrol komputer untuk jangka waktu tersebut.


26
2018-04-26 22:41



Jawaban ini mengasumsikan Anda prihatin dengan memiliki sistem yang berfungsi dengan benar, melebihi dan di atas memiliki sistem yang biaya minimum atau cepat; kebanyakan orang bermain dengan hal-hal radioaktif menghargai kebenaran / keamanan atas kecepatan / biaya

Beberapa orang menyarankan perubahan perangkat keras yang dapat Anda buat (baik-baik saja - ada banyak hal bagus di sini di jawaban dan saya tidak berniat mengulanginya semua), dan yang lain menyarankan redundansi (sangat bagus), tetapi saya tidak berpikir siapa pun telah menyarankan bagaimana redundansi itu bisa bekerja dalam praktek. Bagaimana Anda gagal? Bagaimana Anda tahu ketika ada sesuatu yang 'salah'? Banyak teknologi yang bekerja atas dasar segalanya akan berhasil, dan kegagalan adalah hal yang rumit untuk ditangani. Namun, beberapa teknologi komputasi terdistribusi dirancang untuk skala mengharapkan Kegagalan (setelah semua dengan skala yang cukup, kegagalan satu simpul banyak tidak dapat dihindari dengan MTBF untuk satu simpul tunggal); Anda dapat memanfaatkan ini untuk lingkungan Anda.

Berikut beberapa ide:

  • Pastikan bahwa seluruh perangkat keras Anda direplikasi n kali (di mana n lebih besar dari 2, dan sebaiknya aneh), dan bahwa setiap elemen perangkat keras dapat berkomunikasi dengan masing-masing elemen perangkat keras lainnya. Ethernet adalah salah satu cara yang jelas untuk melakukan itu, tetapi ada banyak rute lain yang jauh lebih sederhana yang akan memberikan perlindungan yang lebih baik (mis. BISA). Minimalkan komponen umum (bahkan catu daya). Ini mungkin berarti pengambilan sampel ADC di banyak tempat, misalnya.

  • Pastikan status aplikasi Anda ada di satu tempat, mis. dalam mesin negara yang terbatas. Ini dapat sepenuhnya berbasis RAM, meskipun tidak menghalangi penyimpanan yang stabil. Dengan demikian akan disimpan di beberapa tempat.

  • Mengadopsi protokol kuorum untuk perubahan negara. Lihat RAKIT sebagai contoh. Ketika Anda bekerja di C ++, ada perpustakaan terkenal untuk ini. Perubahan pada FSM hanya akan dilakukan ketika mayoritas node setuju. Gunakan pustaka yang dikenal baik untuk tumpukan protokol dan protokol kuorum daripada menggulirnya sendiri, atau semua pekerjaan baik Anda pada redundansi akan terbuang ketika protokol kuorum macet.

  • Pastikan Anda memeriksa (misalnya CRC / SHA) FSM Anda, dan simpan CRC / SHA di FSM itu sendiri (serta transmisi dalam pesan, dan periksa pesannya sendiri). Dapatkan node untuk memeriksa FSM mereka secara teratur terhadap checksum ini, pesan masuk checksum, dan periksa checksum mereka sesuai dengan checksum kuorum.

  • Buat sebanyak mungkin pemeriksaan internal lainnya ke dalam sistem Anda, buat node yang mendeteksi reboot kegagalannya sendiri (ini lebih baik daripada membawa setengah bekerja asalkan Anda memiliki cukup node). Berusahalah untuk membiarkan mereka membersihkan diri mereka dari kuorum selama reboot jika mereka tidak muncul lagi. Saat reboot, minta mereka memeriksa gambar perangkat lunak (dan apa pun yang mereka muat) dan melakukan tes RAM penuh sebelum memperkenalkan diri kembali ke kuorum.

  • Gunakan perangkat keras untuk mendukung Anda, tetapi lakukan dengan hati-hati. Anda bisa mendapatkan RAM ECC, misalnya, dan secara teratur membaca / menulis melaluinya untuk memperbaiki kesalahan ECC (dan panik jika kesalahan tidak dapat diperbaiki). Namun (dari memori) RAM statis jauh lebih toleran terhadap radiasi pengion daripada DRAM di tempat pertama, jadi itu mungkin lebih baik menggunakan DRAM statis sebagai gantinya. Lihat titik pertama di bawah 'hal-hal yang tidak akan saya lakukan' juga.

Katakanlah Anda memiliki kemungkinan 1% kegagalan dari setiap node yang diberikan dalam satu hari, dan mari berpura-pura Anda dapat membuat kegagalan sepenuhnya independen. Dengan 5 node, Anda perlu tiga kali gagal dalam satu hari, yang merupakan peluang 0,00001%. Dengan lebih banyak, Anda mendapatkan ide itu.

Hal yang akan saya lakukan tidak melakukan:

  • Meremehkan nilai tidak memiliki masalah untuk memulai dengan. Kecuali berat adalah kekhawatiran, blok besar logam di sekitar perangkat Anda akan menjadi solusi yang jauh lebih murah dan lebih andal daripada yang bisa dihasilkan oleh programer. Ditto optical coupling dari input EMI adalah masalah, dll. Apapun, usahakan ketika sumber komponen Anda ke sumber yang dinilai terbaik terhadap radiasi pengion.

  • Gulung algoritme Anda sendiri. Orang telah melakukan hal ini sebelumnya. Gunakan pekerjaan mereka. Toleransi kesalahan dan algoritma terdistribusi sulit. Gunakan pekerjaan orang lain jika memungkinkan.

  • Gunakan pengaturan kompilator yang rumit dengan harapan naif Anda mendeteksi lebih banyak kegagalan. Jika Anda beruntung, Anda dapat mendeteksi lebih banyak kegagalan. Lebih mungkin, Anda akan menggunakan jalur kode di dalam compiler yang telah kurang teruji, terutama jika Anda menggulirnya sendiri.

  • Gunakan teknik yang belum teruji di lingkungan Anda. Kebanyakan orang yang menulis perangkat lunak ketersediaan tinggi harus mensimulasikan mode kegagalan untuk memeriksa pekerjaan HA mereka dengan benar, dan melewatkan banyak mode kegagalan sebagai hasilnya. Anda berada dalam posisi 'beruntung' karena sering mengalami kegagalan permintaan. Jadi, uji setiap teknik, dan pastikan aplikasinya benar-benar meningkatkan MTBF dengan jumlah yang melebihi kerumitan untuk mengenalkannya (dengan kerumitan datang bug). Terutama terapkan ini pada algoritme kuorum referensi saya, dll.


22
2018-04-27 15:41