Yüksək radioaktiv mühitlərdə istifadə üçün ərizə kompilyasiyası.

İyonlaşdırıcı şüalanma ilə nurlanmış bir mühitdə ekranlı bir cihazda yerləşdirilən quraşdırılmış C / C ++ tətbiqini yığırıq. Biz ARM-dən GCC və cross-tərtibatdan istifadə edirik. Dağıtıldığında tətbiqimiz bəzi səhv məlumatlar yaradır və ən çox istədiyimiz kimi düşür. Avadanlıq bu mühit üçün nəzərdə tutulmuşdur və tətbiqimiz bu platformada bir neçə ildir fəaliyyət göstərir.

Bir hadisəni ifşa etməklə yaranan yumşaq səhvləri və yaddaş korrupsiyasını müəyyən etmək / düzəltmək üçün edilə bilən kodumuzu və ya kompilyasiya müddətini təkmilləşdirmək olarmı? Hər hansı digər developers yumşaq yumruların uzun müddətli tətbiqlərdə zərərli təsirlərinin azaldılmasına nail ola bildimi?

1210
24 апр. çay üzərində qurulmuşdur 24 apr. 2016-04-24 22:09 '16 saat 10:09 'da 2016-04-24 22:09
@ 22 cavab

Proqramın / proqram təminatının inkişafı və minyatür peyklərin ətraf mühitinin sınaqdan keçirilməsi ilə təxminən 4-5 ildir işləyərkən burada təcrübəmizi bölüşmək istərdim.

* (miniatür peyklər, elektronik komponentləri üçün nisbətən kiçik, məhdud ölçüləri səbəbindən daha böyük peyklərdən daha birdəfəlik hadisələrə daha çox meylli olurlar).

Çox qısa və birbaşa olmaq üçün: proqramın / proqram təminatının özünün proqram təminatının / proqram təminatının ən azı bir iş versiyasının ən azı bir surətini bərpa etmək məqsədi ilə və ya dəstəkləyən qurğulardan istifadə edərək, aşkar və səhv hallardan xilas etmək üçün heç bir mexanizm yoxdur bərpa (funksional).

İndi bu vəziyyət adətən həm hardware, həm də proqram səviyyəsində işlənir. Burada sorğunuza əsasən proqram səviyyəsində nə edə biləcəyimizi sizə xəbər verəcəyəm.

  • ... bərpa hədəfi .... Real mühitdə proqram / proqram təminatını yeniləmək / yenidən tərtib etmək / bərpa etmək bacarığını təmin edin. Bu yüksək səviyyədə ionlaşmış mühitdə hər hansı bir proqram / firmware üçün demək olar ki, məcburi bir xüsusiyyətdir. Bu olmadan, istədiyiniz qədər lazımsız proqram və ya donanma ola bilər, ancaq bir anda hamısı patlayır. Beləliklə, bu xüsusiyyəti hazırlayın!

  • ... minimum iş versiyası ... Kodunuzda həssas, bir neçə nüsxədə, minimum proqram təminatı / firmware versiyası var. Bu, Windows-da təhlükəsiz rejimə bənzəyir. Proqramınızın yalnız bir tam funksional versiyasına malik olmaq yerinə, proqram / firmware proqramının minimum versiyasının bir neçə nüsxəsi var. Minimum nüsxədə adətən tam surətdən daha kiçik bir ölçüsü var və demək olar ki, həmişə yalnız aşağıdakı iki və ya üç funksiyaya malikdir:

    • bir xarici sistemdən bir əmri dinləyə bilərik
    • mövcud proqram / firmware yeniləmə edə,
    • əməliyyatlar üzrə əsas əməliyyat məlumatlarını izləyə bilir.
  • ... surəti ... bir yerdə ... Sənədsiz proqram təminatı / firmware var.

    • Zərərsiz avadanlıqla və ya olmadan, ARM uC-də lazımsız proqram / proqram təminatına malik ola bilərsiniz. Bu, adətən, bir-birlərinə birbaşa ürək çatışmazlığını göndərən ayrı-ayrı ünvanlarda iki və ya daha çox eyni proqram / firmware olduğunda aparılır, ancaq birdən çoxu bir anda aktiv olacaqdır. Bir və ya bir neçə proqram / proqram təminatının reaksiya göstərməməsi bilinsə, başqa bir proqram / firmware-ə keçin. Bu yanaşmanı istifadə etmək üstünlüyü, səhvlərin aşkar edilməsindən və düzəldilməsindən (bir peyk vəziyyətində, nəzarət mərkəzi adətən istifadə olunur) aşkarlanan və düzəldən məsuliyyət daşıyan hər hansı bir xarici sistem / partiyanın heç bir təmasisiz bir səhv meydana gəlməsindən dərhal sonra funksional dəyişdirmə ola bilər. uçuşlar (MCC)).

      Şübhəsiz ki, lazımsız avadanlıq olmadan, bunun əlverişsiz olması, həqiqətən, bütün fərdi səhvləri aradan qaldırmaq mümkün deyil. Ən azından, hələ də özünü bir keçid (və ya tez-tez bir kodun başlanğıcı) olan bir uğursuzluq nöqtəsinə sahib olacağıq. Bununla belə, yüksək ionlaşmış mühitdə (məsələn, pico / femto peykləri) ölçüləri məhdud olan bir qurğunun əlavə avadanlıq olmadan bir nöqtəyə çatmağı azaltmaq hələ də nəzərə alınmalıdır. Somemore, keçid üçün kodu snippet, əlbəttə ki, bütün proqramın kodundan daha kiçik olacaq və bu, bir hadisə əldə etmək riskini əhəmiyyətli dərəcədə azaldır.

    • Amma bunu etməsəniz, xarici sisteminizdə cihazla əlaqə saxlaya biləcək və proqram təminatını / proqram təminatını yeniləyə biləcək ən az bir nüsxə olmalıdır (bir peyk vəziyyətində, bu yenə də nəzarət mərkəzinin vəzifəsi).

    • Cihazınızdakı daimi saxlama yerinizdə bir nüsxə də ola bilər, bu da sistem / proqram təminatı işləyən proqram təminatının bərpası üçün başlana bilər.
  • ... təsbit edilə bilən səhv vəziyyət. Səhv, bir qayda olaraq, hardware səhv düzəldilməsi / aşkarlama sxemi və ya səhv düzəldilməsi / aşkarlanması üçün kiçik bir kod parçası yardımı ilə aşkar edilməlidir. Əsas kodu / proqram təminatından kiçik, çoxlu və müstəqil kod qoymaq yaxşıdır. Onun əsas vəzifəsi yalnız yoxlamaq / düzəltməkdir. Hardware circuit / firmware (məsələn, qalıqları daha çox radiasiya məruz) və ya bir neçə circuit / məntiq var, etibarlıdır varsa, səhv düzəldilməsi haqqında düşünmək olar. Ancaq bu vəziyyət yoxdursa, səhv aşkarlama kimi bunu etmək daha yaxşıdır. Düzəliş xarici bir sistem / qurğu ola bilər. Səhv düzəldilməsi üçün Hamming / Golay23 kimi əsas səhv düzəldilməsi alqoritmindən istifadə edə bilərsiniz, çünki onlar bir şemada / proqramda olduğu kimi daha asan tətbiq oluna bilər. Amma nəticədə sizin komandanızın imkanlarından asılıdır. CRC tez-tez səhv aşkarlanması üçün istifadə olunur.

  • ... bərpa dəstəkləyən avadanlıq . İndi bu problemin ən çətin cəhəti. Nəhayət, bərpa ən azı funksional bərpa üçün cavabdeh olan hardware tələb edir. Donanma daimi şəkildə zərər görərsə (adətən bu ümumi ionlaşdırıcı doza müəyyən bir səviyyəyə çatdıqdan sonra olur), onda (təəssüf ki) bərpa proqramında kömək etmək üçün heç bir yol yoxdur. Beləliklə, yüksək səviyyədə radiasiya (məsələn, peyk kimi) məruz qalmış bir cihaz üçün donanma doğru əhəmiyyət kəsb edir.

Yuxarıda göstərilən təklifə əlavə olaraq, bir hadisə məruz qalması səbəbindən bir proqram təminatı səhvini təklif edərkən, sizə də təklif etmək istərdim:

  • Altsistemlər arasında rabitə protokolunda səhvlərin və / və ya səhvlərin aşkarlanması üçün alqoritm. Başqa bir sistemdən alınan natamam / səhv siqnallardan qaçmaq üçün mövcud olan başqa bir nümunədir.

  • ADC oxumalarını süzün. ADC-ni birbaşa istifadə etməyin. Orta süzgəc, orta filtr və ya hər hansı digər süzgə ilə süzun - bir oxuma dəyərinə heç vaxt güvənməyin. Nümunə daha çox, daha az - məqbul.

698
25 апр. cavab verildi Ian 25 Apr 2016-04-25 05:58 '16 saat 17:58 'da 2016-04-25 05:58

NASA radiasiya qabiliyyətli proqram təminatı haqqında bir məqalə yazmışdır. Bu üç əsas vəzifəni təsvir edir:

  • Səhvlər üçün yaddaşın mütəmadi olaraq monitorinqi, sonra bu səhvləri təmizləmək,
  • etibarlı səhv bərpa mexanizmləri və
  • bir şey artıq işə yaramırsa yenidən qurma qabiliyyəti.

Yaddaş tarama sürətinin kifayət qədər tez-tez olması lazımdır ki, çoxlu bit səhvləri nadirdir, çünki ECC yaddaşının əksəriyyəti çox bitli səhvlər deyil, tək-bit səhvlərindən bərpa edilə bilər.

Etibarlı səhvlərin bərpası nəzarət axınının ötürülməsini (adətən, əvvəlki səhv nöqtəsində prosesi yenidən başladın), resursları azad etməkdən və məlumatları bərpa etməyi nəzərdə tutur.

border=0

Məlumatların bərpası üçün onların əsas tövsiyəsi onun ehtiyacının qarşısını almaqdır, çünki aralıq məlumatlar müvəqqəti olaraq nəzərdən keçirilir, belə ki, bir səhv əvvəl təhlükəsiz vəziyyətə qaytarılır. Bu verilənlər bazasında "əməliyyatlar" anlayışına bənzəyir.

C ++ kimi obyektlərə yönəlmiş dillərə uyğun üsulları müzakirə edirlər. Məsələn,

  • Qarışıq yaddaş obyektləri üçün proqram ECC
  • Müqaviləyə əsasən proqramlaşdırma : şərtləri yoxlamaq və sonrakı şəraitin yoxlanılması, sonra iş qabiliyyətinin yoxlanılması üçün obyektin yoxlanması.
356
24 апр. cavab verildi rsjaffe 24 apr. 2016-04-24 22:32 '16 saat 10:32 'da 2016-04-24 22:32

Burada bəzi fikirlər və fikirlər var:

ROMu daha yaradıcılıqla istifadə edin.

ROMda hər şeyi saxlaya bilərsiniz. Nə şeyi hesablamaq yerinə, ROMdakı axtarış masalarını saxlaya bilərsiniz. (Kompilyatorunuzun axtarış masalarınızı yalnız oxu bölməsində siyahılarındakı siyahılarındakı siyahılarındakı siyahılarındakı siyahılarındakı siyahılarındakı siyahılarındakı siyahılarındakı siyahılarını yerləşdirin. Əlbəttə ki, ROM sizin RAM ilə müqayisə necə bir neçə test run.

Yığın üçün ən yaxşı RAM istifadə edin.

Yığındakı SEUlar, ehtimal ki, ən başlıca uğursuzluq qaynağıdır, çünki index dəyişənləri, dövlət dəyişənləri, geri dönən ünvanlar və müxtəlif tipli göstəricilər adətən orada yaşayır.

Bir timer-timer və nəzarət timers həyata keçirir.

Hər bir timer üçün bir sağlamlıq yoxlama prosedurunu və sistemin kilidlənməsi üçün gözləmə prosedurunu çalıştırabilirsiniz. Master kodunuz da sayğacınızı periyodik olaraq artıra bilər, irəliləyişi göstərir və sağlamlıq yoxlama proseduru bunun baş verdiyini təmin edə bilər.

Proqramda səhv düzəliş kodlarını tətbiq edin.

Səhvləri aşkarlamaq və / və ya düzəltmək üçün məlumatlarınızı əlavə edə bilərsiniz. Bu prosessorun işlənmə müddətini artıra bilər, bu da prosessorun daha uzun müddətə radiasiyaya məruz qalmasına gətirib çıxara bilər ki, bu da səhvlərin olma ehtimalı artır.

Önbellekleri saxla.

İşlemci önbelleğinin ölçüsünü yoxlayın. Son zamanlarda qəbul etdiyiniz və ya dəyişdirdiyiniz məlumatlar ehtimalla önbellekte. İnanıram ki, ən azı bəzi önbellektləri söndürə bilərsiniz (böyük bir performans ilə); Bunu SEU'lara necə həssas önbelleklerin olduğunu anlamaq üçün bunu denemelisiniz. Önbellekler RAM'dan daha dayanıklıysa, önbellekten kalan ve RAM'yi geri döndürdüğünden emin olmaq üçün kritik verileri düzenli olaraq okuyup yeniden yazabilirsiniz.

Səhifə səhv işləyicilərindən istifadə edin.

Yaddaş səhifəsini mövcud olmayan kimi qeyd etsəniz, ona daxil olmağa çalışdığınız zaman CPU səhifə səhv edir. Bir oxunuş tələbinə xidmət etməzdən əvvəl bir neçə qiymətləndirmə yerinə yetirən bir səhifə səhv işləyicisi yarada bilərsiniz. (PC əməliyyat sistemləri bu disklə əvəz edilmiş şəffaflıqla yükləmə səhifələrindən istifadə edirlər.)

Kritik şeylər üçün montaj dili istifadə edin (bu hər şey ola bilər).

Bir assembler ilə qeydiyyatdan və RAM-da nə olduğunu bilirsiniz; prosessorun hansı RAM xüsusi masalarından istifadə etdiyini bilirsiniz və riskləri azaltmaq üçün şeyləri qeyri-adi şəkildə tərtib edə bilərsiniz.

Əslində yaradılan montaj dilinə baxmaq və alt proqramlarınızın hər birinin hansı kodunu yerinə objdump etmək üçün objdump istifadə edin.

Linux kimi daha böyük bir OS istifadə edirsinizsə, narahatlıq soruşur; çox mürəkkəblik və bir çox şey yanlış getmək var.

Bu ehtimalı olan bir oyun olduğunu unutmayın.

Şərh yazdı

Səhvləri tutmaq üçün yazdığınız hər bir qaydanız eyni səbəbdən eyni olacaq.

Bu doğru olsa da, 100 bayt kod və səhvlərin testin düzgün aparılması üçün zəruri olan məlumatlar digər yerlərdə səhvlərin ehtimalı ilə müqayisədə çox azdır. ROMunuz kifayət qədər etibarlı olsa və kodun / məlumatların demək olar ki, hamısı ROMda olduqda, şansınız daha da yaxşıdır.

Aşırı avadanlıq istifadə edin.

Eyni kodla 2 və ya daha çox eyni cihaz parametrlərini istifadə edin. Nəticələr bir-birindən fərqlənirsə, bir sıfırlama işləməlisiniz. 3 və ya daha çox cihaz ilə, səsvermə sistemindən hansılarının təhlükəyə məruz qaldığını müəyyən etmək üçün istifadə edə bilərsiniz.

100
25 апр. Artelius tərəfindən verilmiş cavab 25 Apr 2016-04-25 02:11 '16 saat 02:11 'də 2016-04-25 02:11' də

Ayrıca, alqoritmik esneklik mövzusu ilə əlaqədar zəngin bir ədəbiyyat da maraqlana bilər. Buraya köhnə tapşırıq daxildir: sabit müqayisələrin sayı uğursuz olduqda (ya da müvəqqəti müqayisə asimptotik sayının müqayisələr üçün log(n) kimi qiymətləndirildiyi zaman bir az daha pis versiya) girişini düzgün şəkildə sıralayan bir növ yazmaq.

Oxumağa başlayacaq bir yer, Huang və İbrahim 1984-cü ildə " Matrix əməliyyatları üçün alqoritmlərə əsaslanan yanlış tolerantlıq " adlı məqalədir. Onların fikirləri homomorfik şifrəli hesablamalara qeyri-müəyyəndir (lakin bu, iş səviyyəsində səhvləri aşkarlamaq / düzəltməyə çalışdıqları kimi eyni deyildir) .

Bu yazının sonrakı nəslindən Bosilca, Delmas, Dongarra və >Yüksək Performanslı Hesablamalarda İstifadə Olunan Alqoritmik Möhkəmlik " dir.

87
25 апр. Eric Towers tərəfindən aprelin 25-də cevap verildi 2016-04-25 00:13 '16 'da 0:13 2016-04-25 00:13

Radioaktiv mühit üçün yazı kodu heç bir kritik tətbiq üçün kodu yazmaqdan fərqli deyil.

Artıq qeyd olunanlara əlavə olaraq, burada müxtəlif məsləhətlər var:

  • Gündəlik çörək və yeyinti təhlükəsizliyi tədbirlərini hər hansı yarı-peşəkar quraşdırılmış sistemdə təqdim etməlidirlər: daxili watchdog timer, daxili aşağı gərginlik aşkarlanması, daxili saat monitor. Bunlar 2016-cı ildə qeyd olunmaq lazım deyil və demək olar ki, bütün müasir mikrokreditlər üzrə standartlaşdırılır.
  • Təhlükəsiz və / və ya avtomobil MCU'niz varsa, watchdog timerını yeniləmək üçün lazım olan bir müəyyən edilmiş vaxt pəncərəsi kimi müəyyən watchdog funksiyaları olacaq. Bu kritik bir real vaxt sisteminiz varsa, bu seçimdir.
  • Ümumiyyətlə, bu cür sistemlərə uyğun bir MCU istifadə edin və mısır giləmeyvə paketində qəbul etdiyiniz ümumi tüklərdən istifadə etməyin. Hələ demək olar ki, hər bir MCU istehsalçısı təhlükəsizlik proqramları üçün hazırlanmış ixtisaslaşdırılmış mikro nəzarətçilərə (TI, Freescale, Renesas, ST, Infineon və s.) Malikdir. Onlar kilidlənmiş çekirdekler də daxil olmaqla bir çox daxili təhlükəsizlik xüsusiyyətlərinə malikdir: bu, eyni kodu işləyən iki CPU nüvəsi var və bir-biri ilə razılaşmalıdır.
  • Vacib: Daxili MCU reyestrlərinin bütövlüyünü təmin etməlisiniz. Yazıla bilən hardware periferik cihazlarının bütün nəzarət və statusu qeydləri RAM-da yerləşdirilə bilər və buna görə də həssasdır.

    Qeydiyyatındakı uğursuzluqlardan qorunmaq üçün daxili "bir dəfə yazma" funksiyası olan mikrokontrolör seçmək məsləhətdir. Ayrıca, NVM'deki bütün donanım qeydlerinin varsayılan değerlerini tutmalısınız ve düzenli olaraq bu değerleri kopyalamanız lazımdır. Eyni şəkildə əhəmiyyətli dəyişənlərin bütövlüyünü təmin edə bilərsiniz.

    Qeyd: həmişə təhlükəsizlik proqramlarından istifadə edin. Bu deməkdir ki, bütün registrləri MCU-da konfiqurasiya etməliyik. Birdən təsadüfi hardware periferiya oyanmasını istəmirsiniz.

  • RAM və ya NVM-də səhvləri yoxlamaq üçün hər cür yol var: checksum, "walk patterns", ECC proqramı və s. Ən yaxşı həllər bu günlərdə onlardan heç birini istifadə etmir, ancaq ECC-də və oxşar çeklərlə MCU-dan istifadə etməkdir. Proqramda bunu etmək çətindir və özünü yoxlayan səhvlər səhvlərə və gözlənilməz problemlərə səbəb ola bilər.

  • Təkrarlıq istifadə edin. Həm uçucu, həm də uçucu olmayan yaddaşları hər zaman eşvivalent olması lazım olan iki eyni "ayna" seqmentində saxlaya bilərsiniz. Hər bir seqmentdə bir CRC checksum ola bilər.
  • MCU xaricində xarici saxlama cihazlarından istifadə etməyin.
  • Bütün mümkün interrupt / istisnalar üçün default interrupt handling / default istisna işləyicisi funksiyasını həyata keçirin. Hətta istifadə etməyin. Səmərəliliyin proqramı öz aralıq mənbəyini söndürmək istisna olmaqla başqa bir şey etməməlidir.
  • Müdafiə proqramlarının konsepsiyasını anlayın və qəbul edin. Bu, proqramınızın bütün mümkün halları, hətta nəzəriyyədə yaranmayanların hamısını idarə etməsi deməkdir. Nümunələr

    Yüksək keyfiyyətli, kritik proqram təminatı mümkün qədər çox səhv aşkarlayır və onları təhlükəsiz bir şəkildə gözardı edir.

  • Həddindən artıq müəyyən edilmiş davranışlara əsaslanan proqramları heç vaxt yazmayın. Çox ehtimal ki, bu davranış şüalanma və elektromaqnit müdaxiləsinin yaratdığı gözlənilməz hardware dəyişiklikləri ilə dramatik şəkildə dəyişə bilər. Proqramınızın bu crapdan azad olmasını təmin etmək üçün ən yaxşı üsul statik analiz cihazı ilə birlikdə MISRA kimi bir kodlama standartından istifadə etməkdir. Bu da müdafiə proqramlarına və səhvlər düzəltməyə kömək edir (niyə hər hansı tətbiqdə səhvləri aşkar etmək istəmirsiniz?).
  • ВАЖНО: не используйте какую-либо зависимость значений по умолчанию от статических переменных продолжительности хранения. То есть не доверяйте содержимому по умолчанию .data или .bss . Между точкой инициализации до точки, где фактически используется переменная, может быть любое количество времени, возможно, было достаточно времени для того, чтобы ОЗУ получило повреждение. Вместо этого напишите программу так, чтобы все такие переменные были установлены из NVM во время выполнения, незадолго до того момента, когда такая переменная используется в первый раз.

    На практике это означает, что если переменная объявлена ​​в области файлов или в качестве static , вы никогда не должны использовать = для ее инициализации (или можете, но это бессмысленно, потому что вы не можете полагаться на значение так или иначе). Всегда устанавливайте его во время выполнения, как раз перед использованием. Если можно многократно обновлять такие переменные из NVM, сделайте это.

    Аналогично в С++ не полагайтесь на конструкторы для переменных статической продолжительности хранения. Попросите конструктора (-ов) вызвать общедоступную "настройку", которую вы также можете вызвать позже во время выполнения, прямо из приложения-вызывающего.

    Если возможно, удалите код запуска "copy-down", который полностью инициализирует .data и .bss (и вызывает конструкторы С++), так что вы получаете ошибки компоновщика, если вы пишете код, полагающийся на такой. Многие компиляторы имеют возможность пропустить это, обычно называемое "минимальным/быстрым запуском" или аналогичным.

    Это означает, что любые внешние библиотеки должны быть проверены, чтобы они не содержали такой уверенности.

  • Внедрить и определить безопасное состояние для программы, где вы вернетесь в случае критических ошибок.

  • Внедрение системы отчетов об ошибках/журнала ошибок всегда полезно.
31
ответ дан Lundin 27 апр. '16 в 17:11 2016-04-27 17:11

Возможно, можно использовать C для написания программ, которые ведут себя устойчиво в таких средах, но только в том случае, если большинство форм оптимизации компилятора отключены. Оптимизация компиляторов предназначена для замены многих, казалось бы, избыточных шаблонов кодирования на "более эффективные", и, возможно, не имеет понятия, что причина, по которой программист тестирует x==42 , когда компилятор знает, что нет способа x потому что программист хочет предотвратить выполнение определенного кода с x , удерживая какое-то другое значение, даже в тех случаях, когда единственным способом, которым он мог бы удерживать это значение, было бы, если система получила какой-то электрический сбой.

Объявление переменных как volatile часто полезно, но не может быть панацеей. Особо важно отметить, что безопасное кодирование часто требует, чтобы опасные операции имеют аппаратные блокировки, требующие нескольких шагов для активации, и этот код записывается с использованием шаблона:

 ... 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(); 

Если компилятор переводит код относительно буквальным образом, и если все проверки состояния системы повторяются после prepare_for_activation() , система может быть устойчивой к практически любому правдоподобному событию с одним сбоем, даже те, которые произвольно испортили бы счетчик программ и стек. Если сбой происходит сразу после вызова prepare_for_activation() , что подразумевает что активация была бы подходящей (поскольку нет другой причины prepare_for_activation() было бы вызвано до сбоя). Если сбой приводит к тому, что код достигает prepare_for_activation() ненадлежащим образом, но там не являются последующими событиями с ошибками, не будет никакого способа для последующего кода достигните trigger_activation() , не пройдя проверку проверки или сначала вызвав cancel_preparations [если глюк стека, выполнение может перейти к месту непосредственно перед trigger_activation() после возврата контекста, который вызвал prepare_for_activation() , но вызов cancel_preparations() произошли между вызовами prepare_for_activation() и trigger_activation() , тем самым делая последний вызов безвредным.

Такой код может быть безопасным в традиционном C, но не в современных компиляторах C. Такие компиляторы могут быть очень опасны в такой среде, потому что агрессивные они стремятся включить только код, который будет иметь значение в ситуациях, которые могут возникнуть через какой-то четко определенный механизм и чьи последствия будут также хорошо определены. Код, целью которого является обнаружение и очистка после сбоев, может в некоторых случаях ухудшить ситуацию. Если компилятор определяет, что попытка восстановления в некоторых случаях вызывает поведение undefined, он может сделать вывод о том, что условия, которые потребуют такого восстановления в таких случаях, не могут произойти, тем самым устраняя код, который был бы проверен для них.

27
ответ дан supercat 25 апр. '16 в 19:14 2016-04-25 19:14

Это очень широкий предмет. В принципе, вы действительно не можете восстановить повреждение памяти, но вы можете хотя бы попытаться быстро выполнить . Вот несколько методов, которые вы могли бы использовать:

  • данные контрольной суммы . Если у вас есть какие-либо данные конфигурации, которые остаются постоянными в течение длительного времени (включая настроенные аппаратные регистры), вычислите его контрольную сумму при инициализации и проверите ее периодически. Когда вы видите несоответствие, время для повторной инициализации или reset.

  • хранить переменные с резервированием . Если у вас есть важная переменная x , напишите ее значение в x1 , x2 и x3 и прочитайте ее как (x1 == x2) ? x2 : x3 .

  • реализовать мониторинг потока программ . XOR - глобальный флаг с уникальным значением в важных функциях/ветвях, вызываемых из основного цикла. Запуск программы в безрисковой среде с почти 100% -ным охватом тестирования должен дать вам список допустимых значений флага в конце цикла. Reset, если вы видите отклонения.

  • отслеживать указатель стека . В начале основного цикла сравните указатель стека с его ожидаемым значением. Reset при отклонении.

25
ответ дан Dmitry Grigoryev 25 апр. '16 в 20:05 2016-04-25 20:05

Что может вам помочь - watchdog . В 1980-х годах сторожевые псы широко использовались в промышленных вычислениях. Аппаратные сбои были гораздо более распространены тогда - другой ответ также относится к этому периоду.

Watchdog - это комбинированная аппаратная/программная функция. Аппаратное обеспечение - это простой счетчик, который отсчитывает от числа (например, 1023) до нуля. TTL или другая логика.

Программное обеспечение разработано таким образом, что одна рутина контролирует правильную работу всех основных систем. Если эта процедура завершится правильно = обнаруживает, что компьютер работает нормально, он устанавливает счетчик обратно на 1023.

Общая конструкция такова, что при нормальных обстоятельствах программное обеспечение предотвращает достижение нуля счетчика оборудования. Если счетчик достигает нуля, аппаратное обеспечение счетчика выполняет свою единственную задачу и сбрасывает всю систему. С точки зрения счетчика, нуль равен 1024, и счетчик продолжает отсчет снова.

Этот сторожевой таймер гарантирует перезагрузку подключенного компьютера во многих случаях отказа. Должен признать, что я не знаком с оборудованием, которое может выполнять такую ​​функцию на сегодняшних компьютерах. Интерфейсы для внешнего оборудования теперь намного сложнее, чем раньше.

Врожденным недостатком сторожевого таймера является то, что система недоступна с момента ее провала, пока счетчик сторожевого таймера не достигнет нуля + время перезагрузки. Хотя это время, как правило, намного короче любого внешнего или человеческого вмешательства, поддерживаемое оборудование должно будет продолжать работать без управления компьютером на этот таймфрейм.

23
ответ дан OldFrank 27 апр. '16 в 1:41 2016-04-27 01:41

В этом ответе предполагается, что у вас есть система, которая работает правильно, сверх того, у которой минимальная стоимость или скорость системы; большинство людей, играющих с радиоактивными вещами, ценят правильность/безопасность по скорости/стоимости

Несколько человек предложили аппаратные изменения, которые вы можете сделать (хорошо - там много хороших вещей здесь, в ответах уже, и я не собираюсь повторять все это), а другие предложили избыточность (в принципе это принципиально), но я Думаю, кто-то предложил, как это избыточность может работать на практике. Как вы терпите неудачу? Откуда вы знаете, когда что-то "пошло не так"? Многие технологии работают на основе того, что все будет работать, и неудача, таким образом, является сложной задачей. Однако некоторые распределенные вычислительные технологии, разработанные для масштабирования, ожидают неудачи (ведь с достаточным масштабом неудача одного node из многих неизбежна с любым MTBF для одного node); вы можете использовать это для своей среды.

Вот несколько идей:

  • Убедитесь, что все ваше оборудование реплицировано n раз (где n больше 2, а предпочтительно нечетно) и что каждый аппаратный элемент может связываться друг с другом аппаратным элементом. Ethernet - один из очевидных способов сделать это, но есть много других гораздо более простых маршрутов, которые обеспечивали бы лучшую защиту (например, CAN). Минимизируйте общие компоненты (даже источники питания). Это может означать, например, выборки АЦП в нескольких местах.

  • Убедитесь, что состояние вашего приложения находится в одном месте, например. в машине конечного состояния. Это может быть полностью основано на ОЗУ, но не исключает стабильного хранения. Таким образом, он будет храниться в нескольких местах.

  • Принять протокол кворума для изменения состояния. Например, смотрите RAFT . Поскольку вы работаете на С++, для этого существуют хорошо известные библиотеки. Изменения в FSM будут сделаны только тогда, когда большинство узлов согласуются. Используйте известную хорошую библиотеку для стека протоколов и протокол кворума, а не скатывайте самостоятельно, или вся ваша хорошая работа по избыточности будет потрачена впустую, когда протокол кворума зависает.

  • Обеспечьте контрольную сумму (например, CRC/SHA) вашего FSM и сохраните CRC/SHA в самом FSM (а также передайте в сообщении и проверив сами сообщения). Получите узлы, чтобы регулярно проверять их FSM на эту контрольную сумму, входящие сообщения контрольной суммы и проверять их контрольную сумму на контрольную сумму кворума.

  • Постройте как можно больше внутренних проверок в вашей системе, создавая узлы, которые обнаруживают свою собственную перезагрузку отказа (это лучше, чем переносить половину работы, если у вас достаточно узлов). Попытайтесь позволить им очистить себя от кворума во время перезагрузки, если они не появятся снова. При перезагрузке имейте контрольную сумму программного образа (и всего остального, что они загружают), и выполняйте полный тест RAM, прежде чем повторно вводить себя в кворум.

  • Используйте оборудование для поддержки, но делайте это осторожно. Например, вы можете получить ОЗУ ECC и регулярно читать/записывать через него для исправления ошибок ECC (и паники, если ошибка не исправляется). Однако (из памяти) статическая ОЗУ гораздо более терпима к ионизирующей радиации, чем DRAM, в первую очередь, поэтому лучше использовать статическую DRAM. См. Первый пункт под "вещами, которые я бы не сделал".

Скажем, у вас есть 1% -ный шанс выхода из строя любого данного node в течение одного дня, и пусть притворяется, что вы можете сделать неудачи полностью независимыми. С 5 узлами вам понадобится три, чтобы провалиться в течение одного дня, что является вероятностью .00001%. Более того, вы получите эту идею.

Вещи, которые я бы не сделал:

  • Недооценить значение, которое не имеет проблемы для начала. Если вес не вызывает беспокойства, большой блок металла вокруг вашего устройства будет намного дешевле и надежнее, чем может предложить команда программистов. Точно оптическое соединение входов EMI является проблемой и т.д. Независимо от того, пытаетесь ли вы подключить ваши компоненты к источникам, которые лучше всего подходят для ионизирующего излучения.

  • Создайте собственные алгоритмы. Люди делали это раньше. Используйте их работу. Отказоустойчивость и распределенные алгоритмы сложны. По возможности используйте других людей.

  • Используйте сложные настройки компилятора в наивной надежде, что вы обнаружите больше сбоев. Если вам повезет, вы можете обнаружить больше сбоев. Скорее всего, вы будете использовать код-код в компиляторе, который был менее проверен, особенно если вы сами его выполнили.

  • Использовать методы, не прошедшие проверку в вашей среде. Большинство людей, пишущих программное обеспечение высокой доступности, должны моделировать режимы отказа, чтобы проверить работоспособность их HA, и, в результате, пропустить многие режимы отказа. Вы находитесь в "счастливой" позиции с частыми неудачами по требованию. Поэтому проверяйте каждую технику и убедитесь, что ее применение действительно улучшает MTBF на сумму, превышающую сложность ее внедрения (при сложностях возникают ошибки). Особенно примените это к моим рекомендациям по алгоритму кворума и т.д.

19
ответ дан abligh 27 апр. '16 в 18:41 2016-04-27 18:41

Поскольку вы специально запрашиваете программные решения и используете С++, почему бы не использовать перегрузку оператора, чтобы создавать собственные безопасные типы данных? Məsələn:

Вместо использования uint32_tdouble , int64_t и т.д.) создайте свой собственный SAFE_uint32_t , который содержит несколько (минимум 3) из uint32_t. Перегрузите все операции, которые вы хотите (* + -/< < → = ==!= И т.д.), Чтобы выполнить перегруженные операции независимо от каждого внутреннего значения, т.е. Не делать это один раз и копировать результат. И до, и после убедитесь, что все внутренние значения совпадают. Если значения не совпадают, вы можете обновить неверный до значения с наиболее распространенным. Если нет наиболее распространенного значения, вы можете спокойно уведомить об ошибке.

Таким образом, не имеет значения, происходит ли коррупция в ALU, регистры, оперативная память или на шине, вы все равно будете иметь несколько попыток и очень хорошие шансы поймать ошибки. Однако обратите внимание, что это работает только для переменных, которые вы можете заменить - ваш указатель стека, например, будет по-прежнему восприимчивым.

Боковая история: у меня возникла аналогичная проблема, также на старом чипе ARM. Оказалось, что это инструментальная цепочка, в которой использовалась старая версия GCC, которая вместе с конкретным чипом, который мы использовали, вызвала ошибку в некоторых случаях кросс, которые (иногда) передавали коррумпированные значения в функции. Убедитесь, что у вашего устройства нет никаких проблем, прежде чем обвинять его в радио-активности, и да, иногда это ошибка компилятора =)

18
ответ дан jkflying 27 апр. '16 в 18:32 2016-04-27 18:32

Отказ от ответственности: я не профессионал в области радиоактивности и не работал для такого приложения. Но я работал над мягкими ошибками и избыточности для долговременного архивирования критических данных, что несколько связано (одна и та же проблема, разные цели).

Основная проблема с радиоактивностью, на мой взгляд, заключается в том, что радиоактивность может переключать биты, поэтому радиоактивность может/будет изменять любую цифровую память . Эти ошибки обычно называются мягкие ошибки , бит-гниль и т.д.

Вопрос заключается в следующем: как надежно вычислить, когда ваша память ненадежна?

Чтобы значительно снизить скорость мягких ошибок (за счет вычислительных издержек, поскольку в основном это программные решения), вы можете:

  • полагаются на старую схему резервирования , а точнее - более эффективную коды исправления ошибок (такие же цели, но более умные алгоритмы, чтобы вы могли восстановить больше бит с меньшей избыточностью). Это иногда (ошибочно) также называют контрольным суммированием. С помощью такого решения вам нужно будет в любой момент сохранить полное состояние вашей программы в главной переменной/классе (или структуре?), Вычислить ECC и проверить правильность ECC, прежде чем что-либо делать, и если не ремонтировать поля. Это решение, однако, не гарантирует, что ваше программное обеспечение может работать (просто потому, что оно будет работать правильно, когда это возможно, или перестанет работать, если нет, потому что ECC может сказать вам, что-то не так, и в этом случае вы можете остановить свое программное обеспечение, чтобы вы не получайте поддельные результаты).

  • или вы можете использовать отказоустойчивые алгоритмические структуры данных , которые гарантируют, до некоторой степени, что ваша программа все равно даст правильные результаты даже при наличии мягких ошибок. Эти алгоритмы можно рассматривать как сочетание общих алгоритмических структур с схемами ECC, изначально смешанными, но это гораздо более устойчиво, чем это, потому что схема отказоустойчивости тесно связана с структурой, так что вам не нужно кодировать дополнительные процедуры чтобы проверить ECC, и, как правило, они намного быстрее. Эти структуры обеспечивают возможность гарантировать, что ваша программа будет работать в любых условиях, вплоть до теоретической границы мягких ошибок. Вы также можете смешивать эти устойчивые структуры с схемой резервирования /ECC для дополнительной безопасности (или кодировать ваши наиболее важные структуры данных как устойчивые, а остальные - расходные данные, которые вы можете перекомпилировать из основных структур данных, в качестве нормальных структур данных с бит ECC или проверка четности, которая очень быстро вычисляется).

Если вас интересуют устойчивые структуры данных (это последнее, но захватывающее, новое поле в области алгоритмики и избыточности), я советую вам прочитать следующие документы:

  • Встраиваемые структуры данных алгоритмов Джузеппе Ф. Илиано, Universita di Roma "Tor Vergata"

  • Christiano, P., Demaine, ED, and Kishore, S. (2011). Отказоустойчивые отказоустойчивые структуры данных с накладными расходами. В алгоритмах и структурах данных (стр. 243-254). Springer Berlin Heidelberg.

  • Ферраро-Петрильо, У., Грандони, Ф. и Итальяно, Г. Ф. (2013). Структуры данных, устойчивые к ошибкам памяти: экспериментальное исследование словарей. Journal of Experimental Algorithmics (JEA), 18, 1-6.

  • Italiano, GF (2010). Устойчивые алгоритмы и структуры данных. В алгоритмах и сложностях (стр. 13-24). Springer Berlin Heidelberg.

Если вам интересно узнать больше о области устойчивых структур данных, вы можете проверить работы Giuseppe F. Italiano (и проделайте свой путь через refs) и модель Faulty-RAM (представленная в Finocchi et al., 2005; Finocchi and Italiano 2008).

/EDIT: Я проиллюстрировал предупреждение/восстановление от мягких ошибок, главным образом, для ОЗУ и хранения данных, но я не говорил о ошибках вычисления (CPU) . Другие ответы уже указывали на использование атомных транзакций, например, в базах данных, поэтому я предлагаю другую, более простую схему: избыточность и большинство голосов .

Идея состоит в том, что вы просто выполняете x раз такое же вычисление для каждого вычисления, которое вам нужно сделать, и сохранить результат в x разных переменных (с x >= 3). Затем вы можете сравнить переменные x :

  • если все согласны, тогда нет никакой ошибки вычисления.
  • Если они не согласны, тогда вы можете использовать большинство голосов, чтобы получить правильное значение, и поскольку это означает, что вычисление было частично повреждено, вы также можете запустить сканирование состояния системы/программы, чтобы проверить, что все в порядке.
  • Если большинство голосов не может определить победителя (все значения x различны), тогда это идеальный сигнал для запуска процедуры отказоустойчивости (перезагрузка, повышение оповещения пользователя и т.д.).

Эта схема резервирования очень быстро по сравнению с ECC (практически O (1)) и предоставляет вам сигнал очистки , когда вам нужно отказоустойчивое . Большинство голосов также (почти) гарантировано никогда не выдают поврежденный выход , а также восстанавливаются из-за незначительных ошибок вычисления , поскольку вероятность того, что вычисления x дают один и тот же результат, бесконечно мала ( потому что существует огромное количество возможных выходов, практически невозможно случайным образом получить в 3 раза то же самое, еще меньше шансов, если x > 3).

Таким образом, с большинством голосов вы защищены от поврежденного вывода и с избыточностью x == 3, вы можете восстановить 1 ошибку (при x == 4 это будет 2 ошибки восстановления и т.д. - точное уравнение nb_error_recoverable == (x-2) где x - количество повторений вычислений, потому что вам нужно как минимум 2 согласованных расчета для восстановления с использованием большинства голосов).

Недостаток заключается в том, что вам нужно вычислить x раз, а не один раз, так что у вас есть дополнительные вычислительные затраты, но линейная сложность, поэтому асимптотически вы не теряете много преимуществ, которые вы получаете. Быстрый способ сделать большинство голосов - вычислить режим в массиве, но вы также можете использовать медианный фильтр.

Кроме того, если вы хотите удостовериться, что расчеты выполнены правильно, если вы можете создать собственное оборудование, вы можете построить свое устройство с помощью x процессоров и подключить систему, чтобы вычисления автоматически дублировались по x процессорам с мажоритарное голосование сделано механически в конце (например, с использованием ворот И/ИЛИ). Это часто реализуется в самолетах и ​​критически важных устройствах (см. тройное модульное резервирование ). Таким образом, у вас не было бы вычислительных накладных расходов (так как дополнительные вычисления будут выполняться параллельно), и у вас есть еще один уровень защиты от мягких ошибок (поскольку дублирование вычислений и большинство голосов будут управляться непосредственно аппаратными средствами, а не программное обеспечение, которое может быть более легко повреждено, поскольку программа представляет собой просто бит, хранящийся в памяти...).

13
ответ дан gaborous 01 мая '16 в 21:56 2016-05-01 21:56

Кажется, что одна точка больше не упоминается. Вы говорите, что работаете в GCC и перекрестно скомпилируете ARM. Откуда вы знаете, что у вас нет кода, который делает предположения о свободной ОЗУ, размере целого числа, размере указателя, сколько времени требуется для выполнения определенной операции, как долго система будет работать непрерывно или что-то вроде этого? Это очень распространенная проблема.

Ответ - это, как правило, автоматическое модульное тестирование. Напишите тестовые жгуты, которые используют код в системе разработки, затем запустите те же тестовые жгуты в целевой системе. Ищите различия!

Также проверьте наличие ошибок на встроенном устройстве. Вы можете найти там что-то о "не делайте этого, потому что он сбой, поэтому включите этот параметр компилятора, и компилятор будет работать вокруг него".

Короче говоря, ваш наиболее вероятный источник сбоев - это ошибки в вашем коде. До тех пор, пока вы не заметите, что это не так, не беспокойтесь (еще) о более эзотерических режимах отказа.

8
ответ дан Graham 27 апр. '16 в 19:09 2016-04-27 19:09

Вам нужны 3-х ведомые машины с мастером вне радиационной среды. Все операции ввода-вывода проходят через мастер, который содержит механизм голосования и/или повтора. Ведомые должны иметь сторожевой таймер для каждого из них, и вызов для их вызова должен быть окружен CRC или тому подобным, чтобы уменьшить вероятность непроизвольного удара. Bumping должен контролироваться мастером, поэтому потерянное соединение с мастером равно перезагрузке в течение нескольких секунд.

Одно из преимуществ этого решения заключается в том, что вы можете использовать тот же API для ведущего, что и для ведомых устройств, поэтому избыточность становится прозрачной функцией.

Изменить: Из комментариев я чувствую необходимость уточнить "идею CRC". Возможность подчиненного буксирования его собственного сторожевого таймера близка к нулю, если вы окружаете удар с помощью CRC или перевариваете проверки случайных данных от мастера. Эти случайные данные отправляются только от мастера, когда подчиненный подконтроль выравнивается с другими. Случайные данные и CRC/дайджест немедленно очищаются после каждого удара. Частота релаксации ведущего-ведомого должна быть больше double тайм-аута сторожевого таймера. Данные, отправленные от мастера, генерируются уникально каждый раз.

8
ответ дан Jonas Byström 27 апр. '16 в 17:16 2016-04-27 17:16

Как запустить много экземпляров вашего приложения. Если сбои происходят из-за случайных изменений бита памяти, скорее всего, некоторые из ваших экземпляров приложения пройдут и получат точные результаты. Вероятно, довольно легко (для кого-то со статистическим фоном) рассчитать, сколько экземпляров вам понадобится, чтобы бит-флоп мог достичь как крошечной общей ошибки, как вы пожелаете.

7
ответ дан ren 25 апр. '16 в 19:40 2016-04-25 19:40

То, что вы задаете, - довольно сложная тема - нелегко ответить. Другие ответы в порядке, но они охватывают лишь небольшую часть всех вещей, которые вам нужно сделать.

Как видно из комментариев , невозможно устранить аппаратные проблемы на 100%, однако с высокой вероятностью можно уменьшить или уловить их с помощью различных методов.

Если бы я был вами, я бы создал программное обеспечение самого высокого уровня Уровень целостности безопасности (SIL-4). Получите документ IEC 61513 (для ядерной промышленности) и следуйте за ним.

7
ответ дан BЈовић 26 апр. '16 в 15:03 2016-04-26 15:03

Кто-то упомянул об использовании более медленных чипов, чтобы не допустить, чтобы ионы сбрасывали биты. Аналогичным образом, возможно, используется специализированный CPU/RAM, который фактически использует несколько бит для хранения одного бита. Таким образом, обеспечивается аппаратная отказоустойчивость, потому что было бы очень маловероятно, чтобы все биты были перевернуты. Итак, 1 = 1111, но нужно было бы получить 4 раза, чтобы фактически перевернуться. (4 может быть плохим числом, поскольку, если 2 бита перевернут его уже неоднозначным). Таким образом, если вы идете с 8, вы получаете в 8 раз меньше бара и немного более медленное время доступа, но гораздо более надежное представление данных. Вероятно, вы можете сделать это как на уровне программного обеспечения, так и со специализированным компилятором (выделить x больше места для всего) или языковой реализацией (писать оболочки для структур данных, которые распределяют вещи таким образом). Или специализированное оборудование, которое имеет одну и ту же логическую структуру, но делает это в прошивке.

7
ответ дан Alex C 28 апр. '16 в 6:34 2016-04-28 06:34

Возможно, это поможет узнать, означает ли это, что аппаратное обеспечение "предназначено для этой среды". Как он исправляет и/или указывает на наличие ошибок SEU?

В одном проекте, связанном с исследованием космоса, у нас был специальный MCU, который мог бы вызвать исключение/прерывание ошибок SEU, но с некоторой задержкой, то есть некоторые циклы могут проходить/инструкции выполняться после одного insn, вызвавшего исключение SEU.

Особенно уязвимым был кеш данных, поэтому обработчик сделал бы недействительным строку оскорбительного кэша и перезапустил программу. Только это из-за неточного характера исключения последовательность insns, возглавляемая исключающим insn, не может быть перезапущена.

Мы идентифицировали опасные (не перезапускаемые) последовательности (например, lw $3, 0x0($2) , а затем insn, который изменяет $2 и не зависит от данных от $3 ), и я вносил изменения в GCC, поэтому такие последовательности (например, в крайнем случае, разделяя два insns на nop ).

Просто подумать...

6
ответ дан chill 28 апр. '16 в 10:42 2016-04-28 10:42

Если ваше оборудование выходит из строя, вы можете использовать механическое хранилище для его восстановления. Если ваша база кода мала и имеет некоторое физическое пространство, вы можете использовать механическое хранилище данных.

2019

ответ дан Hitul 27 апр. '16 в 17:24 2016-04-27 17:24

Учитывая комментарии суперкара, тенденции современных компиляторов и т.д., у меня возникнет соблазн вернуться к древним временам и написать весь код в сборке и распределении статической памяти везде. Для такой полной надежности я думаю, что сборка больше не несет большой процентной разницы в стоимости.

3
ответ дан Joshua 27 апр. '16 в 21:40 2016-04-27 21:40

Во-первых, создайте приложение с ошибкой . Убедитесь, что в процессе нормальной работы он ожидает reset (в зависимости от вашего приложения и типа отказа, мягкого или жесткого). Это трудно понять: критические операции, требующие некоторой степени трансакции, могут потребоваться проверять и настраивать на уровне сборки, чтобы прерывание в ключевой точке не могло приводить к противоречивым внешним командам. Сбой быстро , как только обнаружено какое-либо неустранимое повреждение памяти или отклонение потока управления. Ошибки журнала, если это возможно.

Во-вторых, по возможности, исправлять коррупцию и продолжать . Это означает, что проверка и фиксирование постоянных таблиц (и программный код, если можно) часто; возможно, перед каждой крупной операцией или при прерывании по времени и хранением переменных в структурах, которые автокорректируются (снова перед каждым крупным оператором или при прерывании по времени принимается большинство голосов от 3 и исправляется, если это одно отклонение). Корректировки журнала, если это возможно.

В-третьих, сбой теста . Настройте повторяемую тестовую среду, которая переворачивает биты в памяти psuedo-randomly. Это позволит вам реплицировать ситуации с коррупцией и помочь в разработке приложения вокруг них.

3
ответ дан MrBigglesworth 02 мая '16 в 13:47 2016-05-02 13:47

Используйте циклический планировщик . Это дает вам возможность добавлять регулярное время обслуживания для проверки правильности критических данных. Самой большой проблемой часто является повреждение стека. Если ваше программное обеспечение циклично, вы можете повторно инициализировать стек между циклами. Не используйте повторно стеки для вызовов прерываний, настройте отдельный стек каждого важного вызова прерывания.

Подобно концепции Watchdog, применяются таймеры timeline. Запустите аппаратный таймер перед вызовом функции. Если функция не вернется до истечения срока, перезагрузите стек и повторите попытку. Если он по-прежнему не работает после 3/5 попыток, вам нужно перезагрузить ROM.

Разделите свое программное обеспечение на части и изолируйте эти детали (особенно в среде управления). Пример: получение сигнала, предварительные данные, основной алгоритм и реализация/передача результата. Это означает, что сбой в одной части не приведет к сбоям через остальную часть программы.

Все нуждается в CRC. Если вы выполняете RAM, даже ваш .text нуждается в CRC. Регулярно проверяйте CRC, если вы используете циклический планировщик. Некоторые компиляторы (не GCC) могут генерировать CRC для каждого раздела, а некоторые процессоры имеют выделенное оборудование для выполнения CRC-вычислений, но я думаю, что это будет падать в сторону вашего вопроса.

3
ответ дан Gerhard 23 сент. '16 в 10:07 2016-09-23 10:07

Вот огромное количество @, но я постараюсь подвести итоги по этому поводу.

Что-то сбой или не работает должным образом, может быть результатом ваших собственных ошибок - тогда это должно быть легко исправить, когда вы обнаружите проблему. Но есть также возможность аппаратных сбоев - и это трудно, если не невозможно, исправить в целом.

Я бы порекомендовал сначала попытаться поймать проблематичную ситуацию путем регистрации (стек, регистры, вызовы функций) - либо путем записи их в файл или передачи их как-то напрямую ( "о нет, я сбой" ).

Восстановление из такой ситуации с ошибкой - либо перезагрузка (если программное обеспечение все еще жива и ногами), либо аппаратное обеспечение reset (например, hw watchdogs). Легче начать с первого.

Если проблема связана с оборудованием - тогда регистрация должна помочь вам определить, в какой проблеме с вызовом функции, и которая может дать вам знания о том, что не работает и где.

Также, если код относительно сложный - имеет смысл "делить и побеждать" - это означает, что вы удаляете или отключите некоторые вызовы функций, где вы подозреваете, что проблема - как правило, отключает половину кода и разрешает другую половину - вы можете получить ". work" / "не работает", после чего вы можете сосредоточиться на другой половине кода. (Где проблема)

Если проблема возникает через некоторое время - возможно подозрение на переполнение стека - тогда лучше контролировать регистры точек стека - если они постоянно растут.

И если вам удастся полностью свести к минимуму ваш код до тех пор, пока приложение типа "привет мир" - и оно все равно не удастся случайным образом - тогда ожидаются аппаратные проблемы - и там должно быть "обновление аппаратного обеспечения" - что означает изобретать такие процессоры cpu/ram/... - комбинация, которая лучше переносит излучение.

Самое главное, вероятно, вы вернете свои журналы, если машина полностью остановлена ​​/перезагружена/не работает - возможно, первое, что нужно сделать bootstap, - это вернуться домой, если затронута проблема.

Если в вашей среде также возможно передать сигнал и получить ответ - вы можете попробовать создать какую-то сетевую удаленную среду отладки, но тогда у вас должно быть хотя бы от среды связи, и какой-то процессор/рабочее состояние. И путем удаленной отладки я имею в виду либо подход GDB/gdb-заглушки, либо собственную реализацию того, что вам нужно, чтобы вернуться из вашего приложения (например, загружать файлы журналов, загружать стек вызовов, загружать баран, перезапускать).

1
ответ дан TarmoPikaro 28 апр. '16 в 10:06 2016-04-28 10:06

Другие вопросы по меткам или Задайте вопрос