Yüksek radyoaktif ortamlarda kullanım için bir uygulama derleme

İyonize radyasyon ile bombardımana tutulan bir ortamda korumalı bir cihaza yerleştirilmiş gömülü bir C / C ++ uygulaması derliyoruz . ARM için GCC ve çapraz derleme kullanıyoruz. Dağıtıldığında, uygulamamız bazı hatalı veriler üretir ve istediğimizden daha sık kilitlenir. Donanım bu ortam için tasarlanmıştır ve uygulamamız birkaç yıldır bu platformda çalışmaktadır.

Kodumuzda yapabileceğimiz değişiklikler veya tekli olayların neden olduğu yumuşak hataları ve bellek bozulmasını tanımlamak / düzeltmek için yapılabilecek derleme zamanı iyileştirmeleri var mı? Başka geliştiriciler, yumuşak hataların uzun süren bir uygulama üzerindeki zararlı etkilerini azaltmada başarılı oldu mu?

Yaklaşık 4-5 yıl boyunca, minyatür uyduların * yazılım / ürün yazılımı geliştirme ve çevre testi ile çalışarak , deneyimlerimi burada paylaşmak istiyorum.

* ( minyatürleştirilmiş uydular, elektronik bileşenleri için nispeten küçük, sınırlı boyutları nedeniyle tekli olay yığılmalarından daha büyük uydulara göre çok daha eğilimlidir )

Çok özlü ve doğrudan olmak için: kurtarmak için hiçbir mekanizma yoktur algılanabilir, hatalı durumun yazılım tarafından / kendini firmware olmadan en azından bir tane, kopyalama ve asgari çalışma sürümü yazılım / firmware ait bir yere için kurtarma amaçlı - ve birlikte donanım destekleyen kurtarma (fonksiyonel).

Şimdi, bu durum normalde hem donanım hem de yazılım düzeyinde ele alınmaktadır. Burada, talep ettiğiniz gibi, yazılım düzeyinde neler yapabileceğimizi paylaşacağım.

1. ... kurtarma amaçlı ... . Yazılımınızı / ürün yazılımınızı gerçek ortamda güncelleme / yeniden derleme / yeniden boyutlandırma yeteneği sağlayın. Bu, oldukça iyonize ortamlardaki herhangi bir yazılım / ürün yazılımı için neredeyse sahip olunması gereken bir özelliktir. Bu olmadan, istediğiniz kadar yedek yazılım / donanımınız olabilir , ancak bir noktada hepsi patlayacak. Bu özelliği hazırlayın!

2. ... minimum çalışma sürümü ... Kodunuzda yanıt veren, birden fazla kopya, yazılımın / ürün yazılımının minimum sürümüne sahip olun. Bu, Windows'ta Güvenli mod gibidir. Yazılımınızın yalnızca bir tamamen işlevsel sürümüne sahip olmak yerine, yazılımınızın / ürün yazılımının minimum sürümünün birden çok kopyasına sahip olun. Minimum kopya genellikle tam kopyadan çok daha az boyuttadır ve neredeyse her zaman yalnızca aşağıdaki iki veya üç özelliğe sahiptir:

   1. harici sistemden komutu dinleyebilme,
   2. mevcut yazılımı / ürün yazılımını güncelleyebilir,
   3. temel operasyonun temizlik verilerini izleyebilir.

3. ... kopyala ... bir yerde ... Bir yerde yedekli yazılım / bellenim var.

   1. Sen ile olabilir veya gereksiz donanım olmadan, ARM UC'de gereksiz yazılım / firmware var çalışın. Bu normalde , birbirine kalp atışı gönderen ayrı adreslerde iki veya daha fazla özdeş yazılım / bellenime sahip olmakla yapılır - ancak bir seferde yalnızca bir tane etkin olacaktır. Bir veya daha fazla yazılım / bellenimin yanıt vermediği biliniyorsa, diğer yazılıma / bellenime geçin. Bu yaklaşımı kullanmanın yararı, bir hata meydana geldikten hemen sonra işlevsel olarak değiştirilebilmemizdir - hatayı tespit etmek ve onarmaktan sorumlu olan herhangi bir harici sistem / parti ile herhangi bir temas olmadan (uydu durumunda, genellikle Görev Kontrol Merkezi'dir ( MCC)).

      Kesinlikle gereksiz donanım olmadan, konuşma, bunu yapmanın dezavantajı aslında olamaz ortadan kaldırmak bütün hataların tek nokta. En azından, hala sahip olacak biri olan bir noktada devre dışı, anahtar kendisi (genellikle veya kod başlangıcı). Bununla birlikte, yüksek oranda iyonize olmuş bir ortamda (pico / femto uydular gibi) boyutla sınırlı bir cihaz için, tek bir arıza noktasının ek donanım olmadan bir noktaya indirilmesi dikkate alınmaya değer olacaktır. Dahası, anahtarlama için kod parçası kesinlikle tüm programın kodundan çok daha az olacaktır - bu da Tek Etkinlik'e girme riskini önemli ölçüde azaltır.

   2. Ancak bunu yapmıyorsanız, harici sisteminizde cihazla temas edebilecek ve yazılımı / bellenimi güncelleyebilecek en az bir kopyaya sahip olmalısınız (uydu durumunda, yine görev kontrol merkezidir).

   3. Kopyayı, çalışan sistemin yazılımını / ürün yazılımını geri yüklemek için tetiklenebilen, cihazınızdaki kalıcı bellek belleğinizde de olabilir

4. ... tespit hatalı durum .. hata olmalıdır tespit genellikle donanım ile, hata düzeltme / algılama devresi veya hata düzeltme / tespiti için küçük bir kod parça. Bu kodu küçük, çoklu ve ana yazılımdan / bellenimden bağımsız olarak koymak en iyisidir . Ana görevi sadece kontrol etmek / düzeltmektir. Donanım devresi / bellenimi güvenilirse(diğerlerinden daha fazla radyasyonla sertleştirilmiş - veya birden fazla devreye / mantığa sahipse), onunla hata düzeltme yapmayı düşünebilirsiniz. Ancak eğer değilse, hata tespiti olarak yapmak daha iyidir. Düzeltme harici sistem / cihaz tarafından yapılabilir. Hata düzeltmesi için Hamming / Golay23 gibi temel bir hata düzeltme algoritması kullanmayı düşünebilirsiniz, çünkü bunlar hem devrede / yazılımda daha kolay uygulanabilir. Ama sonuçta ekibinizin yeteneğine bağlı. Hata tespiti için normalde CRC kullanılır.

5. ... kurtarmayı destekleyen donanım Şimdi, bu konuda en zor yönü geliyor. Sonuç olarak kurtarma işlemi, kurtarma işleminden en az işlevsel olan donanımın gerekli olmasını gerektirir . Donanım kalıcı olarak kırılırsa (normalde Toplam iyonlaştırıcı dozu belirli bir seviyeye ulaştıktan sonra gerçekleşir ), o zaman yazılımın iyileşmeye yardımcı olması için (ne yazık ki) bir yol yoktur. Bu nedenle, donanım, yüksek radyasyon seviyesine (uydu gibi) maruz kalan bir cihaz için en önemli konudur.

Tek bir olay bozukluğu nedeniyle bellenimin hatasını önceden tahmin etmenin önerisine ek olarak, aşağıdakilere sahip olmanızı da öneririm:

1. Sistemler arası iletişim protokolünde hata algılama ve / veya hata düzeltme algoritması. Bu, diğer sistemden alınan eksik / yanlış sinyalleri önlemek için neredeyse sahip olması gereken bir başka şeydir.

2. ADC değerinizi filtreleyin. Do not doğrudan okuma ADC kullanın. Bunu medyan filtreye, ortalama filtreye veya diğer filtrelere göre filtreleyin - asla tek okuma değerine güvenmeyin. Daha fazla örnek alın, daha az değil - makul olarak.

NASA'nın radyasyonla sertleştirilmiş yazılım hakkında bir makalesi vardır . Üç ana görevi açıklar:

1. Belleğin hatalar için düzenli olarak izlenmesi ve ardından bu hataların silinmesi,
2. sağlam hata kurtarma mekanizmaları ve
3. bir şey artık çalışmazsa yeniden yapılandırma yeteneği.

Çoğu ECC belleği çok bitli hataları değil, tek bitli hatalardan kurtarabileceğinden , bellek tarama hızının çok bitli hataların nadiren meydana gelebileceği sıklıkta olması gerektiğini unutmayın .

Sağlam hata kurtarma, kontrol akış aktarımını (genellikle bir işlemin hatadan önceki bir noktada yeniden başlatılması), kaynak yayınını ve veri geri yüklemesini içerir.

Veri restorasyonu için ana önerileri, ara verilerin geçici olarak ele alınması yoluyla buna ihtiyaç duymamaktır, böylece hatadan önce yeniden başlatma da verileri güvenilir bir duruma geri döndürür. Bu, veritabanlarındaki "işlemler" kavramına benziyor.

C ++ gibi nesneye yönelik diller için özellikle uygun teknikleri tartışırlar. Örneğin

1. Bitişik bellek nesneleri için yazılım tabanlı ECC'ler
2. Sözleşme ile Programlama : ön koşulları ve son koşulları doğrulamak, ardından nesneyi hala geçerli bir durumda olduğunu doğrulamak için kontrol etmek.

NASA, Mars Rover gibi büyük projeler için C ++ kullandı .

C ++ sınıfı soyutlama ve kapsülleme, birden fazla proje ve geliştirici arasında hızlı geliştirme ve test yapılmasını sağladı.

Sorun yaratabilecek bazı C ++ özelliklerinden kaçındılar:

1. İstisnalar
2. Şablonlar
3. Iostream (konsol yok)
4. Çoklu kalıtım
5. Operatör aşırı yüklenmesi ( newve hariç delete)
6. Dinamik ayırma ( newsistem yığını bozulması olasılığını önlemek için özel bir bellek havuzu ve yerleşim kullanılır ).

İşte bazı düşünce ve fikirler:

ROM'u daha yaratıcı kullanın.

ROM'da yapabileceğiniz her şeyi saklayın. Bir şeyleri hesaplamak yerine, arama tablolarını ROM'da saklayın. (Derleyicinizin arama tablolarınızı salt okunur bölüme çıkardığından emin olun! Kontrol etmek için çalışma zamanında bellek adreslerini yazdırın!) Kesme vektör tablonuzu ROM'da saklayın. Tabii ki, ROM'unuzun RAM'inizle ne kadar güvenilir olduğunu görmek için bazı testler yapın.

Yığın için en iyi RAM'inizi kullanın.

Yığında bulunan SEU'lar muhtemelen en olası çökme kaynağıdır, çünkü dizin değişkenleri, durum değişkenleri, dönüş adresleri ve çeşitli türlerin işaretçileri gibi şeyler genellikle yaşar.

Zamanlayıcı-kene ve bekçi köpeği zamanlayıcı rutinlerini uygulayın.

Sistem kilitlemesini idare etmek için her zamanlayıcı işaretini bir "sağlık kontrolü" rutininin yanı sıra bir bekçi köpeği rutini de çalıştırabilirsiniz. Ana kodunuz ayrıca ilerlemeyi belirtmek için bir sayacı periyodik olarak artırabilir ve sağlık kontrolü rutini bunun gerçekleşmesini sağlayabilir.

Uygulamak hata düzeltme kodlarını yazılımında.

Hataları algılamak ve / veya düzeltmek için verilerinize artıklık ekleyebilirsiniz. Bu, işlem süresini artıracak ve işlemciyi daha uzun süre radyasyona maruz bırakacak, böylece hata olasılığını artıracak, bu nedenle ödünleşimi dikkate almalısınız.

Önbellekleri hatırla.

CPU önbelleklerinizin boyutlarını kontrol edin. Son zamanlarda eriştiğiniz veya değiştirdiğiniz veriler büyük olasılıkla bir önbellek içinde olacaktır. Önbelleklerin bazılarını devre dışı bırakabileceğinize inanıyorum (büyük bir performans maliyetiyle); önbelleklerin SEU'lara ne kadar duyarlı olduğunu görmek için bunu denemelisiniz. Önbellekler RAM'den daha sertse, önbellekte kalmasını ve RAM'i tekrar sıraya sokmasını sağlamak için kritik verileri düzenli olarak okuyabilir ve yeniden yazabilirsiniz.

Sayfa hatası işleyicilerini akıllıca kullanın.

Bir bellek sayfasını mevcut değil olarak işaretlerseniz, CPU erişmeye çalıştığınızda bir sayfa hatası verir. Okuma isteğine hizmet vermeden önce bazı kontroller yapan bir sayfa hatası işleyicisi oluşturabilirsiniz. (PC işletim sistemleri bunu diske değiştirilen sayfaları şeffaf bir şekilde yüklemek için kullanır.)

Kritik şeyler için montaj dilini kullanın (her şey olabilir).

Montaj dili ile kayıtlarda ve RAM'de neler olduğunu bilirsiniz ; Eğer biliyor CPU kullanarak hangi özel RAM tabloları ve riskini düşük tutmak için dolaylı bir şekilde bir şeyler tasarlayabilirsiniz.

Kullanım objdumpaslında montaj üretilen dilde bakmak ve rutinleri her kaplıyor ne kadar kod egzersiz yapın.

Linux gibi büyük bir işletim sistemi kullanıyorsanız sorun mu yaşıyorsunuz? çok fazla karmaşıklık ve yanlış gidecek çok şey var.

Unutmayın, bir olasılık oyunu.

Bir yorumcu dedi

Hataları yakalamak için yazdığınız her rutin aynı nedenden dolayı kendini başarısızlığa uğratır.

Bu doğru olsa da, bir kontrol rutininin doğru çalışması için gerekli olan (bay) 100 bayt kod ve verilerin hata şansı, başka bir yerde hata olasılığından çok daha azdır. ROM'unuz oldukça güvenilirse ve neredeyse tüm kod / veriler aslında ROM'daysa, oranlarınız daha da iyidir.

Yedekli donanım kullanın.

Aynı kodla 2 veya daha fazla özdeş donanım kurulumu kullanın. Sonuçlar farklıysa, bir sıfırlama tetiklenmelidir. 3 veya daha fazla cihazla, hangisinin tehlikeye atıldığını belirlemeye çalışmak için bir "oylama" sistemi kullanabilirsiniz.

Ayrıca algoritmik hata toleransı konusundaki zengin literatürle de ilgilenebilirsiniz. Bu yaşlı atama içerir: karşılaştırmalar sabit bir sayı başarısız olur ne zaman doğru şekilde girişini sıralar bir tür yaz (veya, biraz daha kötü versiyonu olduğu gibi başarısız karşılaştırmalar ölçeklerin asimptotik sayısı log(n)için nkarşılaştırmalar).

Okumaya başlamak için bir yer Huang ve Abraham'ın 1984 tarihli " Matris İşlemleri için Algoritma Tabanlı Hata Toleransı " dır . Fikirleri belirsiz bir şekilde homomorfik şifreli hesaplamaya benzer (ancak çalışma düzeyinde hata algılama / düzeltme girişiminde bulundukları için gerçekte aynı değildir).

Bu makalenin daha yeni bir torunu Bosilca, Delmas, Dongarra ve Langou'nun " Yüksek performanslı hesaplamalara uygulanan Algoritma tabanlı hata toleransı " dır .

Radyoaktif ortamlar için kod yazmak, kritik öneme sahip uygulamalar için kod yazmaktan farklı değildir.

Daha önce bahsedilenlere ek olarak, bazı çeşitli ipuçları:

• Herhangi bir yarı profesyonel gömülü sistemde bulunması gereken günlük "ekmek ve tereyağı" güvenlik önlemlerini kullanın: dahili bekçi köpeği, dahili düşük voltaj algılama, dahili saat monitörü. Bunların 2016 yılında belirtilmesine bile gerek yoktur ve hemen hemen her modern mikrodenetleyicide standarttır.
• Güvenlik ve / veya otomotiv odaklı bir MCU'nuz varsa, belirli bir zaman penceresi gibi içinde bekçi köpeğini yenilemeniz gereken belirli bekçi köpeği özelliklerine sahip olacaktır. Görev açısından kritik bir gerçek zamanlı sisteminiz varsa bu tercih edilir.
• Genel olarak, bir paket mısır gevreği içinde aldığınız bazı genel ana akım tüylerini değil, bu tür sistemler için uygun bir MCU kullanın. Günümüzde hemen hemen her MCU üreticisi, güvenlik uygulamaları (TI, Freescale, Renesas, ST, Infineon vb.) İçin tasarlanmış özel MCU'lara sahiptir. Bunlar, kilit adımlı çekirdekler de dahil olmak üzere birçok yerleşik güvenlik özelliğine sahiptir: yani aynı kodu yürüten 2 CPU çekirdeği vardır ve birbirleriyle anlaşmalıdırlar.

• ÖNEMLİ: Dahili MCU kayıtlarının bütünlüğünü sağlamalısınız. Yazılabilir olan donanım çevre birimlerinin tüm kontrol ve durum kayıtları RAM belleğinde bulunabilir ve bu nedenle savunmasızdır.

  Kendinizi kayıt bozulmalarına karşı korumak için, tercihen kayıtların yerleşik "bir kez yaz" özelliklerine sahip bir mikro denetleyici seçin. Ayrıca, tüm donanım kayıtlarının varsayılan değerlerini NVM'de depolamanız ve bu değerleri düzenli aralıklarla kayıtlarınıza kopyalamanız gerekir. Önemli değişkenlerin bütünlüğünü aynı şekilde sağlayabilirsiniz.

  Not: her zaman savunma programlaması kullanın. Bu , yalnızca uygulama tarafından kullanılanları değil, MCU'daki tüm kayıtları ayarlamanız gerektiği anlamına gelir . Birden bire rastgele donanım çevre biriminin aniden uyanmasını istemezsiniz.

• RAM veya NVM'deki hataları kontrol etmek için her türlü yöntem vardır: sağlama toplamları, "yürüme düzenleri", yazılım ECC vb. Günümüzde en iyi çözüm bunlardan herhangi birini kullanmak değil, yerleşik ECC ile bir MCU kullanmaktır. benzer kontroller. Çünkü bunu yazılımda yapmak karmaşıktır ve bu nedenle hata kontrolü kendi başına hatalar ve beklenmedik problemler getirebilir.

• Artıklık kullanın. Hem geçici hem de geçici olmayan belleği, her zaman eşdeğer olması gereken iki özdeş "ayna" parçasında saklayabilirsiniz. Her segmente bir CRC sağlama toplamı eklenmiş olabilir.
• MCU dışında harici bellek kullanmaktan kaçının.
• Olası tüm kesintiler / istisnalar için varsayılan bir kesme hizmeti rutini / varsayılan istisna işleyicisi uygulayın. Kullanmadığınız bile. Varsayılan yordam, kendi kesme kaynağını kapatmak dışında hiçbir şey yapmamalıdır.

• Savunma programlama kavramını anlayın ve kucaklayın. Bu, programınızın teoride gerçekleşemeyen olası durumları bile ele alması gerektiği anlamına gelir. Örnekler .

  Yüksek kaliteli, kritik görevli ürün yazılımı mümkün olduğunca çok hatayı algılar ve ardından bunları güvenli bir şekilde yok sayar.

• Asla kötü belirlenmiş davranışa dayanan programlar yazmayın. Radyasyon veya EMI'nin neden olduğu beklenmedik donanım değişiklikleri ile bu tür davranışların büyük ölçüde değişmesi muhtemeldir. Programınızın böyle bir boktan arınmış olmasını sağlamanın en iyi yolu, statik bir analiz aracıyla birlikte MISRA gibi bir kodlama standardı kullanmaktır. Bu aynı zamanda savunma programlama ve hataları ayıklama ile yardımcı olacaktır (neden herhangi bir uygulamada hataları tespit etmek istemeyesiniz?).

• ÖNEMLİ: Statik depolama süresi değişkenlerinin varsayılan değerlerine güvenmeyin. Olduğunu, varsayılan içeriğini güvenmiyorum .dataya .bss. Başlatma noktası ile değişkenin gerçekte kullanıldığı nokta arasında herhangi bir süre olabilir, RAM'in bozulması için çok zaman olabilirdi. Bunun yerine, bu tür değişkenlerin ilk kez kullanılmasından hemen önce, tüm bu değişkenlerin çalışma zamanında NVM'den ayarlanması için programı yazın.

  Uygulamada bu, bir değişkenin dosya kapsamında veya farklı bir şekilde bildirilmesi durumunda static, hiçbir zaman =onu başlatmak için kullanmamanız gerektiği anlamına gelir (ya da bunu yapabilirsiniz, ancak anlamsızdır, çünkü yine de değere güvenemezsiniz). Kullanmadan hemen önce daima çalışma zamanında ayarlayın. Bu tür değişkenleri NVM'den tekrar tekrar güncellemek mümkünse, yapın.

  C ++ 'da benzer şekilde, statik depolama süresi değişkenleri için yapıcılara güvenmeyin. Yapıcı (lar) dan daha sonra çalışma çağrısında doğrudan arayan uygulamasından çağırabileceğiniz genel bir "kurulum" rutini çağırmasını sağlayın.

  Mümkünse, tamamen başlatan .datave .bss(ve C ++ kurucularını çağıran) "kopyalama" başlatma kodunu tamamen kaldırın , böylece böyle bir kod yazmanız durumunda linker hataları alırsınız. Birçok derleyici, genellikle "minimum / hızlı başlatma" veya benzeri olarak adlandırılan bu seçeneği atlama seçeneğine sahiptir.

  Bu, herhangi bir harici kütüphanenin böyle bir güven içermemesi için kontrol edilmesi gerektiği anlamına gelir.

• Kritik hatalarda geri döneceğiniz program için güvenli bir durum uygulayın ve tanımlayın.

• Bir hata raporu / hata günlüğü sistemi uygulamak her zaman yardımcı olur.

C'yi bu tür ortamlarda sağlam davranan programlar yazmak için, ancak derleyici optimizasyonunun çoğu biçimi devre dışı bırakılmışsa kullanmak mümkün olabilir. Optimize edici derleyiciler, görünüşte gereksiz birçok kodlama desenini "daha verimli" olanlarla değiştirmek için tasarlanmıştır ve derleyici, başka bir şey tutamayacağının x==42hiçbir yolu olmadığını bildiğinde programcının test etme nedeninin, programcıyı xönlemek istemesidir. belirli bir kodun xbaşka bir değer tutmasıyla yürütülmesi - bu değeri tutabilecek tek yolun bile, sistem bir tür elektriksel aksaklık alması durumunda olacaktır.

Değişkenleri volatilegenellikle yararlı olarak bildirmek , ancak her derde deva olmayabilir. Güvenli kodlamanın genellikle tehlikeli işlemlerin etkinleştirmek için birden fazla adım gerektiren donanım kilitlerine sahip olmasını ve bu kodun desen kullanılarak yazılmasını gerektirdiğini unutmayın:

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

Bir derleyici kodu nispeten değişmez bir şekilde çevirirse ve sistem durumuyla ilgili tüm denetimler bundan sonra tekrarlanırsa prepare_for_activation(), sistem, program sayacını ve yığınını keyfi olarak bozacak olanlar dahil olmak üzere, neredeyse tüm makul tek aksaklık olaylarına karşı sağlam olabilir. Bir çağrıdan hemen sonra bir aksaklık meydana gelirse prepare_for_activation(), aktivasyonun uygun olacağı anlamına gelir (çünkü prepare_for_activation()aksaklıktan önce başka bir neden çağrılmazdı). Aksaklık kodun prepare_for_activation()uygunsuz bir şekilde ulaşmasına neden oluyorsa , ancak daha sonraki aksaklık olayları yoksa, kodun trigger_activation()doğrulama denetiminden geçmeden veya önce cancel_preparations çağırmadan sonra ulaşması mümkün olmaz [yığın bozulursa, yürütme bir noktaya ilerleyebilir hemen öncetrigger_activation()denilen bu bağlamda sonra prepare_for_activation()döner, fakat çağrısına cancel_preparations()çağrıları arasında meydana olurdu prepare_for_activation()ve trigger_activation()dolayısıyla ikinci çağrı karşı zararsız render.

Bu kod geleneksel C'de güvenli olabilir, ancak modern C derleyicileriyle olmayabilir. Bu tür derleyiciler bu tür ortamlarda çok tehlikeli olabilir, çünkü agresif, sadece iyi tanımlanmış bir mekanizma ile ortaya çıkabilecek durumlarla ilgili olan ve sonuçlarının da iyi tanımlanacağı kodu içermeye çalışırlar. Amacı başarısızlıklardan sonra tespit etmek ve temizlemek olan kod, bazı durumlarda işleri daha da kötüleştirebilir. Derleyici, kurtarma girişiminin bazı durumlarda tanımlanmamış davranışı gerektireceğini belirlerse, bu gibi durumlarda böyle bir kurtarmayı gerektirecek koşulların gerçekleşemeyeceği sonucunu çıkarabilir ve böylece bunları kontrol edecek kod ortadan kaldırılabilir.

Bu son derece geniş bir konudur. Temel olarak, bellek bozulmasından gerçekten kurtulamazsınız, ancak en azından derhal başarısız olmaya çalışabilirsiniz . İşte kullanabileceğiniz birkaç teknik:

• sağlama toplamı sabit verileri . Uzun süre sabit kalan herhangi bir yapılandırma verileriniz varsa (yapılandırdığınız donanım kayıtları dahil), başlatmadaki sağlama toplamını hesaplayın ve periyodik olarak doğrulayın. Bir uyumsuzluk gördüğünüzde, yeniden başlatma veya sıfırlama zamanı.

• yedekli değişkenleri depola . Eğer önemli bir değişken varsa x, onun değerini yazmak x1, x2ve x3gibi okumak (x1 == x2) ? x2 : x3.

• program akış izlemesi uygular . XOR, ana döngüden çağrılan önemli fonksiyonlarda / dallarda benzersiz bir değere sahip global bir bayrak. Programı,% 100'e yakın test kapsamına sahip radyasyon içermeyen bir ortamda çalıştırmak, döngünün sonunda bayrağın kabul edilebilir değerlerinin listesini vermelidir. Sapmalar görürseniz sıfırlayın.

• yığın işaretçisini izleyin . Ana döngünün başlangıcında, yığın işaretçisini beklenen değeriyle karşılaştırın. Sapmada sıfırla.

Size yardımcı olabilecek bir bekçi köpeğidir . Watchdogs 1980'lerde endüstriyel bilgisayarlarda yaygın olarak kullanıldı. Donanım arızaları o zamandan çok daha yaygındı - başka bir cevap da o döneme atıfta bulunuyor.

Bir bekçi köpeği, birleşik bir donanım / yazılım özelliğidir. Donanım, bir sayıdan (örneğin 1023) sıfıra geri sayan basit bir sayaçtır. TTL veya başka bir mantık kullanılabilir.

Yazılım, bir rutinin tüm temel sistemlerin doğru çalışmasını izleyeceği şekilde tasarlanmıştır. Bu yordam doğru şekilde tamamlanırsa = bilgisayarın iyi çalıştığını bulursa, sayacı 1023'e geri ayarlar.

Genel tasarım, yazılım normal koşullar altında donanım sayacının sıfıra ulaşmasını önler. Sayacın sıfıra ulaşması durumunda, sayacın donanımı tek ve tek görevini gerçekleştirir ve tüm sistemi sıfırlar. Sayaç açısından bakıldığında, sıfır 1024'e eşittir ve sayaç tekrar geri saymaya devam eder.

Bu bekçi, bağlı bilgisayarın birçok arıza durumunda yeniden başlatılmasını sağlar. Bugünün bilgisayarlarında böyle bir işlevi yerine getirebilecek donanıma aşina olmadığımı itiraf etmeliyim. Harici donanıma arayüzler artık eskisinden çok daha karmaşık.

Bekçi köpeğinin doğal bir dezavantajı, sistemin başarısız olduğu andan itibaren bekçi sayacı sıfır + yeniden başlatma süresine ulaşıncaya kadar kullanılabilir olmamasıdır. Bu süre genellikle herhangi bir harici veya insan müdahalesinden çok daha kısa olsa da, desteklenen ekipmanın o zaman çerçevesi için bilgisayar kontrolü olmadan ilerleyebilmesi gerekir.

Bu cevap, düzgün çalışan bir sisteme sahip olmanın, minimum maliyet veya hızlı bir sisteme sahip olmanın üstesinden geldiğinizi varsayar; radyoaktif şeylerle oynayan çoğu insan hız / maliyet üzerinde doğruluğa / güvenliğe değer verir

Birkaç kişi yapabileceğiniz donanım değişiklikleri önerdi (iyi - cevaplarda zaten çok iyi şeyler var ve hepsini tekrarlamak istemiyorum) ve diğerleri artıklık önerdi (prensipte harika), ama sanmıyorum Herkes işten çıkarmanın pratikte nasıl çalışabileceğini önerdi. Nasıl başarabilirsin? Bir şeyin 'yanlış gittiğini' nasıl anlarsınız? Birçok teknoloji, her şeyin çalışacağı temelde çalışır ve başarısızlık, başa çıkılması zor bir şeydir. Bununla birlikte, ölçek için tasarlanmış bazı dağıtılmış bilgi işlem teknolojileri başarısızlık beklemektedir (sonuçta yeterli ölçekte, bir düğümün başarısızlığı, tek bir düğüm için herhangi bir MTBF ile kaçınılmazdır); bunu ortamınız için kullanabilirsiniz.

İşte bazı fikirler:

• Tüm donanımınızın çoğaltılmış nzamanlarından ( n2'den büyük ve tercihen tek) emin olun ve her donanım öğesinin birbiriyle donanım öğesiyle iletişim kurabildiğinden emin olun. Ethernet bunu yapmanın açık bir yoludur, ancak daha iyi koruma sağlayacak çok daha basit yollar vardır (örneğin CAN). Ortak bileşenleri (hatta güç kaynakları) en aza indirin. Bu, örneğin birden fazla yerde ADC girişlerini örneklemek anlamına gelebilir.

• Uygulama durumunuzun tek bir yerde, örneğin sonlu durum makinesinde olduğundan emin olun. Bu, tamamen RAM tabanlı olabilir, ancak sabit depolamayı engellemez. Böylece birkaç yerde depolanacaktır.

• Durum değişiklikleri için bir çekirdek protokolü benimseyin. Örneğin bkz. RAFT . C ++ ile çalışırken, bunun için iyi bilinen kütüphaneler vardır. FSM'deki değişiklikler sadece düğümlerin çoğunluğu kabul ettiğinde yapılır. Protokol yığını ve çekirdek protokolü için kendiniz yuvarlamak yerine bilinen iyi bir kitaplık kullanın, aksi takdirde yeterlilik protokolü kapatıldığında artıklık konusundaki tüm iyi çalışmalarınız boşa gidecektir.

• FSM'nizi kontrol ettiğinizden emin olun (örn. CRC / SHA) ve CRC / SHA'yı FSM'nin kendisinde saklayın (ayrıca iletiyi iletin ve iletileri kendiniz kontrol edin). Düğümleri FSM'lerini bu sağlama toplamı, sağlama toplamı gelen iletileri karşı düzenli olarak kontrol etmelerini ve sağlama toplamlarının çekirdeğin sağlama toplamıyla eşleşmelerini kontrol edin.

• Sisteminizde mümkün olduğunca çok sayıda dahili kontrol oluşturun ve kendi arızalarının yeniden başlatılmasını algılayan düğümler yapın (bu, yeterli düğümünüz varsa, yarı çalışmayı sürdürmekten daha iyidir). Yeniden gelmedikleri takdirde, yeniden başlatma sırasında kendilerini yeterli sayıda çekirdekten temizlemelerini sağlamaya çalışın. Yeniden başlatma sırasında, yazılım görüntüsünü (ve yükledikleri herhangi bir şeyi) kontrol etmelerini sağlayın ve kendilerini yetersayıya sokmadan önce tam bir RAM testi yapın.

• Sizi desteklemek için donanım kullanın, ancak bunu dikkatli bir şekilde yapın. Örneğin, ECC RAM'i alabilir ve ECC hatalarını düzeltmek için düzenli olarak okuyabilir / yazabilirsiniz (ve hata düzeltilemezse panik yapabilirsiniz). Bununla birlikte (bellekten) statik RAM, iyonlaştırıcı radyasyona ilk etapta çok daha toleranslıdır, bu nedenle bunun yerine statik DRAM kullanmak daha iyi olabilir . 'Yapmayacağım şeyler' altındaki ilk noktayı da görün.

Diyelim ki bir gün içinde herhangi bir düğümde% 1 başarısızlık şansınız var ve diyelim ki hataları tamamen bağımsız hale getirebilirsiniz. 5 düğüm ile, bir gün içinde başarısız olmak için üçe ihtiyacınız olacak, bu da .00001% şans. Daha fazlasıyla, fikri anladınız.

Ben ediyorum şeyler değil yapın:

• Başlamak için sorun yaşamamanın değerini küçümseyin. Ağırlık bir endişe olmadıkça, cihazınızın etrafındaki büyük bir metal bloğu, bir programcı ekibinin gelebileceğinden çok daha ucuz ve daha güvenilir bir çözüm olacaktır. EMI girişlerinin Ditto optik kuplajı bir sorun, vb.

• Kendi algoritmalarınızı döndürün . İnsanlar bunu daha önce yapmışlardı. İşlerini kullan. Hata toleransı ve dağıtılmış algoritmalar zordur. Mümkün olan yerlerde başkalarının çalışmalarını kullanın.

• Daha fazla hata tespit edeceğiniz umuduyla karmaşık derleyici ayarlarını kullanın. Şanslıysanız, daha fazla hata tespit edebilirsiniz. Büyük olasılıkla, derleyici içinde, özellikle kendiniz yuvarladıysanız, daha az test edilmiş bir kod yolu kullanacaksınız.

• Ortamınızda test edilmemiş teknikleri kullanın. Yüksek kullanılabilirlik yazılımı yazan çoğu insan, HA'larının doğru çalışıp çalışmadığını kontrol etmek için arıza modlarını simüle etmek ve sonuç olarak birçok arıza modunu kaçırmak zorundadır. Talep üzerine sık sık başarısız olmanın 'şanslı' pozisyonundasınız. Bu nedenle, her tekniği test edin ve uygulamasının gerçekte MTBF'yi tanıtmak için karmaşıklığı aşan bir miktarda geliştirdiğinden emin olun (karmaşıklıkla birlikte hatalar gelir). Özellikle benim tavsiye çekirdek yeterlilik algoritmaları vb.

Özellikle yazılım çözümleri talep ettiğinizden ve C ++ kullandığınızdan, neden kendi güvenli veri türlerinizi oluşturmak için operatör aşırı yüklemesini kullanmıyorsunuz? Örneğin:

Kullanmak uint32_t(ve double, int64_tvb.) Yerine, SAFE_uint32_tuint32_t katı (en az 3) içeren kendiniz yapın. Gerçekleştirmek istediğiniz tüm işlemleri (* + - / << >> = ==! = Vb.) Aşırı yükleyin ve aşırı yüklenmiş işlemlerin her dahili değerde bağımsız olarak çalışmasını sağlayın, yani bir kez yapmayın ve sonucu kopyalayın. Hem önceki hem de sonraki tüm dahili değerlerin eşleşip eşleşmediğini kontrol edin. Değerler eşleşmezse, yanlış olanı en yaygın olanla güncelleyebilirsiniz. En yaygın değer yoksa, bir hata olduğunu güvenle bildirebilirsiniz.

Bu şekilde, ALU'da, kayıtlarda, RAM'de veya bir otobüste bozulma meydana gelmesi önemli değildir, yine de birden fazla denemeniz ve hataları yakalama şansınız çok yüksektir. Bununla birlikte, bunun yalnızca değiştirebileceğiniz değişkenler için çalışmasına rağmen - örneğin yığın işaretçinizin yine de duyarlı olacağını unutmayın.

Bir yan hikaye: Eski bir ARM çipinde de benzer bir sorunla karşılaştım. Kullandığımız spesifik çip ile birlikte, bazı kenar durumlarda (bazen) değerlerin işlevlere geçmesini sağlayacak bir hatayı tetikleyen GCC'nin eski bir sürümünü kullanan bir araç zinciri olduğu ortaya çıktı. Cihazınızın radyo etkinliğinde suçlamadan önce sorun yaşamadığından emin olun ve evet, bazen derleyici hatasıdır =)

Feragatname: Ben bir radyoaktivite uzmanı değilim, ne de bu tür bir uygulama için çalıştım. Ancak, kritik verilerin uzun süreli arşivlenmesi için yumuşak hatalar ve artıklık üzerinde çalıştım, ki bu biraz bağlantılı (aynı sorun, farklı hedefler).

Bence radyoaktivite ile ilgili temel sorun radyoaktivitenin bitleri değiştirebileceği, dolayısıyla radyoaktivitenin herhangi bir dijital belleği kurcalayabileceği / kurcalayacağıdır . Bu hatalara genellikle yumuşak hatalar , bit çürümesi vb. Denir.

O zaman soru şu: hafızanız güvenilmez olduğunda nasıl güvenilir bir şekilde hesaplanır?

Yumuşak hataların oranını önemli ölçüde azaltmak için (çoğunlukla yazılım tabanlı çözümler olacağı için hesaplama yükü pahasına), aşağıdakilerden birini yapabilirsiniz:

• eski iyi yedeklilik şemasına ve daha spesifik olarak daha etkin hata düzeltme kodlarına güvenir (aynı amaç, ancak daha az yedeklemeyle daha fazla bit kurtarabilmeniz için akıllı algoritmalar). Buna bazen (yanlış) sağlama toplamı da denir. Bu tür bir çözümle, programınızın tam durumunu herhangi bir anda bir ana değişken / sınıfta (veya bir yapıda) depolamanız, bir ECC hesaplamanız ve herhangi bir şey yapmadan önce ECC'nin doğru olup olmadığını kontrol etmeniz ve alanları tamir etmeyin. Bununla birlikte, bu çözüm yazılımınızın çalışabileceğini garanti etmez (basitçe çalışabildiği zaman doğru çalışacağını veya yoksa çalışmayı durdurduğunu, çünkü ECC bir şeylerin yanlış olup olmadığını söyleyebilir ve bu durumda yazılımınızı durdurabilirsiniz. sahte sonuçlar elde etmeyin).

• veya esnek algoritmik veri yapılarını kullanabilirsinizbazı sınırlara kadar programınızın yumuşak hatalar olsa bile doğru sonuçları vereceğini garanti eder. Bu algoritmalar, doğal olarak karıştırılmış ECC şemaları ile ortak algoritmik yapıların bir karışımı olarak görülebilir, ancak bu, bundan daha esnektir, çünkü esneklik şeması yapıya sıkıca bağlıdır, böylece ek prosedürleri kodlamanız gerekmez. ECC'yi kontrol etmek için ve genellikle çok daha hızlı. Bu yapılar, programınızın yumuşak hataların teorik sınırına kadar her koşulda çalışmasını sağlamak için bir yol sağlar. Bu esnek yapıları ek güvenlik için artıklık / ECC şeması ile karıştırabilir (veya en önemli veri yapılarınızı esnek ve geri kalanı ana veri yapılarından yeniden hesaplayabileceğiniz sarf edilebilir verileri kodlayabilirsiniz,

Esnek veri yapılarıyla ilgileniyorsanız (algoritma ve artıklık mühendisliğinde yeni, ancak heyecan verici yeni bir alan), aşağıdaki belgeleri okumanızı tavsiye ederim:

• Esnek algoritmalar veri yapıları giriş Giuseppe F.Italiano, Universita di Roma "Tor Vergata"

• Christiano, P., Demaine, ED ve Kishore, S. (2011). Ek yükü ile kayıpsız hataya dayanıklı veri yapıları. Algoritmalar ve Veri Yapılarında (s. 243-254). Springer Berlin Heidelberg.

• Ferraro-Petrillo, U., Grandoni, F. ve Italiano, GF (2013). Bellek hatalarına dirençli veri yapıları: sözlükler üzerinde deneysel bir çalışma. Deneysel Algoritma Dergisi (JEA), 18, 1-6.

• Italiano, GF (2010). Esnek algoritmalar ve veri yapıları. Algoritmalar ve Karmaşıklıkta (s. 13-24). Springer Berlin Heidelberg.

Esnek veri yapıları alanı hakkında daha fazla bilgi edinmek istiyorsanız, Giuseppe F. Italiano'nun çalışmalarına göz atabilirsiniz (ve referanslardan geçebilirsiniz) ve Arızalı RAM modeli (Finocchi ve diğerleri 2005; Finocchi ve Italiano 2008).

/ EDIT: Temel olarak RAM belleği ve veri depolama için yumuşak hatalardan korunma / kurtarmayı gösterdim, ancak hesaplama (CPU) hataları hakkında konuşmadım . Diğer cevaplar zaten veritabanlarında olduğu gibi atomik işlemlerin kullanılmasına işaret etti, bu yüzden daha basit bir plan önereceğim: artıklık ve çoğunluk oyu .

Buradaki fikir, yapmanız gereken her hesaplama için x ile aynı hesaplamayı x kez yapmanız ve sonucu x farklı değişkente (x> = 3 ile) saklamanızdır. Daha sonra x değişkenlerinizi karşılaştırabilirsiniz :

• eğer hepsi aynı fikirde ise, hiçbir hesaplama hatası yoktur.
• kabul etmiyorlarsa, doğru değeri elde etmek için çoğunluk oyu kullanabilirsiniz ve bu, hesaplamanın kısmen bozulduğu anlamına geldiğinden, geri kalanın iyi olup olmadığını kontrol etmek için bir sistem / program durumu taramasını tetikleyebilirsiniz.
• çoğunluk oyu bir kazananı belirleyemezse (tüm x değerleri farklıdır), güvenli prosedürü tetiklemeniz için mükemmel bir sinyaldir (yeniden başlat, kullanıcıya bir uyarı ver, vb.).

Bu fazlalık şeması ECC'ye (pratik olarak O (1)) kıyasla çok hızlıdır ve güvenli olmanız gerektiğinde size net bir sinyal sağlar . Çoğunluk oyunun da (neredeyse) asla bozuk çıktı üretmediği ve küçük hesaplama hatalarından kurtulacağı garanti edilmektedir. , çünkü x hesaplamalarının aynı çıktıyı verme olasılığı sınırsızdır (çünkü çok sayıda olası çıktı olduğundan, neredeyse imkansızdır. rastgele 3 kat aynı olsun, hatta daha az şans x> 3).

Çoğunluk oyu ile bozuk çıktıdan güvende olursunuz ve artıklık x == 3 ile 1 hatayı kurtarabilirsiniz (x == 4 ile 2 hata kurtarılabilir, vb.) - tam denklem nb_error_recoverable == (x-2)x'in sayı olduğu yerdir çoğunluk oyunu kullanarak kurtarmak için en az 2 kabul edilen hesaplamaya ihtiyacınız olduğu için).

Dezavantajı, bir kez yerine x kez hesaplamanız gerektiğidir, bu nedenle ek bir hesaplama maliyetiniz vardır, ancak lineer karmaşıklığı asimptotik olarak elde ettiğiniz faydalar için çok fazla kaybetmezsiniz. Çoğunluk oyu yapmanın hızlı bir yolu, bir dizideki modu hesaplamaktır, ancak medyan bir filtre de kullanabilirsiniz.

Ayrıca, hesaplamaların doğru bir şekilde yapıldığından emin olmak istiyorsanız, kendi donanımınızı yapabilirseniz, cihazınızı x CPU ile yapılandırabilir ve sistemi kablolayabilirsiniz, böylece hesaplamaların çoğunluk oyu ile otomatik olarak x CPU'larda çoğaltılmasını sağlayabilirsiniz. mekanik olarak sonda (örneğin AND / OR kapılarını kullanarak). Bu genellikle uçaklarda ve kritik görev aygıtlarında uygulanır (bkz. Üçlü modüler artıklık ). Bu şekilde, herhangi bir hesaplama yükünüz olmaz (ek hesaplamalar paralel olarak yapılacaktır) ve yumuşak hatalardan başka bir koruma katmanınız olur (çünkü hesaplama tekrarı ve çoğunluk oyu doğrudan donanım tarafından yönetilecek ve yazılım - bir program basitçe bellekte saklanan bitler olduğu için daha kolay bozulabilir ...).

Kimsenin bahsetmediği bir nokta var. GCC'de geliştiğini ve ARM'ye çapraz derlediğini söylüyorsun. Ücretsiz RAM, tamsayı boyutu, işaretçi boyutu, belirli bir işlemin ne kadar sürdüğü, sistemin ne kadar süre boyunca çalışacağı veya bunun gibi çeşitli şeyler hakkında varsayımlar yapan bir kodunuz olmadığını nasıl anlarsınız? Bu çok yaygın bir sorundur.

Cevap genellikle otomatik birim testidir. Geliştirme sistemi üzerindeki kodu kullanan test kayışlarını yazın, ardından hedef sistemde aynı test kayışlarını çalıştırın. Farklılıklar arayın!

Ayrıca gömülü cihazınızda hata olup olmadığını kontrol edin. "Bunu yapma çünkü çökecek, bu yüzden derleyici seçeneğini etkinleştirin ve derleyici etrafında çalışacaktır" hakkında bir şeyler bulabilirsiniz.

Kısacası, en büyük çökme kaynağınız kodunuzdaki hatalardır. Durumun böyle olmadığından emin olana kadar, daha ezoterik başarısızlık modları hakkında endişelenmeyin (henüz).

Radyasyon ortamının dışında bir efendi olan 3+ köle makinesi istiyorsun. Tüm G / Ç, bir oylama ve / veya yeniden deneme mekanizması içeren master'dan geçer. Kölelerin her biri bir donanım izleme köpeğine sahip olmalı ve onları vurma çağrısı, istemsiz çarpma olasılığını azaltmak için CRC'ler veya benzeri ile çevrelenmelidir. Darbeleme master tarafından kontrol edilmelidir, bu yüzden master ile kaybedilen bağlantı birkaç saniye içinde yeniden başlatılır.

Bu çözümün bir avantajı, slave'lerle aynı master'ı kullanabilmenizdir, böylece artıklık şeffaf bir özellik haline gelir.

Düzenleme: Yorumlar "CRC fikri" açıklığa ihtiyacım var hissediyorum. Köpeğin kendi bekçi köpeğini çarpma olasılığı, yumru CRC ile çevrilirse veya master'dan rastgele veriler üzerinde sindirilirse sıfıra yakındır. Rastgele veriler, yalnızca inceleme altındaki köle diğerleriyle hizalandığında master'dan gönderilir. Rastgele veriler ve CRC / özet her bir darbeden sonra derhal temizlenir. Master-slave yumru frekansı , bekçi köpeği zaman aşımının iki katından fazla olmalıdır . Master'dan gönderilen veriler her seferinde benzersiz bir şekilde oluşturulur.

Uygulamanızın birçok örneğini çalıştırma hakkında. Çökmeler rastgele bellek biti değişikliklerinden kaynaklanıyorsa, uygulama örneklerinizden bazıları bunu gerçekleştirir ve doğru sonuçlar üretir. İstediğiniz kadar küçük bir genel hataya ulaşmak için bit flop olasılığı verilen kaç örneğe ihtiyacınız olduğunu hesaplamak muhtemelen (istatistiksel arka planı olan biri için) oldukça kolaydır.

Sorduğunuz şey oldukça karmaşık bir konu - kolayca cevaplanamıyor. Diğer cevaplar tamam, ama yapmanız gereken her şeyin sadece küçük bir kısmını kapladılar.

Yorumlarda görüldüğü gibi, donanım sorunlarını% 100 düzeltmek mümkün değildir, ancak yüksek olasılıkla çeşitli teknikler kullanarak bunları azaltmak veya yakalamak mümkündür.

Ben senin yerinde olsaydım, en yüksek Güvenlik bütünlüğü seviyesi (SIL-4) yazılımını yaratırdım . IEC 61513 belgesini alın (nükleer sanayi için) ve izleyin.

Birisi iyonların bitleri kolayca çevirmesini önlemek için daha yavaş yongalar kullandığından bahsetti. Benzer bir şekilde, belki de tek bir biti depolamak için birden fazla bit kullanan özel bir cpu / ram kullanın. Böylece bir donanım arıza toleransı sağlamak, çünkü tüm bitlerin ters çevrilmesi pek olası değildir. Yani 1 = 1111 ama aslında tersine çevrilmek için 4 kez vurulması gerekiyordu. (Eğer 2 bit ters çevrilirse, belirsiz olan 4 sayı kötü olabilir). 8 ile giderseniz, 8 kat daha az koç ve biraz daha yavaş erişim süresi ancak çok daha güvenilir veri gösterimi elde edersiniz. Muhtemelen bunu hem özel bir derleyici (her şey için x miktar daha fazla alan ayırın) hem de dil uygulaması (işleri bu şekilde ayıran veri yapıları için sarmalayıcılar) ile yazılım düzeyinde yapabilirsiniz.

Belki de donanımın "bu ortam için tasarlanması" anlamına geldiğini bilmek yardımcı olacaktır. SEU hatalarının varlığını nasıl düzeltir ve / veya gösterir?

Uzay araştırmaları ile ilgili bir projede, SEU hatalarında bir istisna / kesinti oluşturacak özel bir MCU'muz vardı, ancak biraz gecikmeyle, yani SEU istisnasına neden olan bir insn'den sonra bazı döngüler geçebilir / talimatlar yürütülebilir.

Veri önbelleği özellikle savunmasızdı, bu nedenle işleyici rahatsız edici önbellek satırını geçersiz kılacak ve programı yeniden başlatacaktı. Ancak, istisnanın kesin olmayan doğası nedeniyle, istisna uyandıran insn tarafından yönetilen insns dizisi yeniden başlatılamayabilir.

Tehlikeli (yeniden başlatılamaz) sekansları belirledik (örneğin lw $3, 0x0($2), değiştiren $2ve verilere bağlı olmayan bir insn izleyen $3) ve GCC'de değişiklikler yaptım, bu nedenle bu tür sekanslar oluşmaz (örn. iki insns a nop).

Dikkate alınması gereken bir şey ...

Donanımınız arızalanırsa, kurtarmak için mekanik depolama kullanabilirsiniz. Kod tabanınız küçükse ve biraz fiziksel alanınız varsa, mekanik bir veri deposu kullanabilirsiniz.

Radyasyondan etkilenmeyecek bir malzeme yüzeyi olacaktır. Birden fazla vites olacak. Tüm viteslerde mekanik bir okuyucu çalışacak ve yukarı ve aşağı hareket etmek için esnek olacaktır. Aşağı, 0 ve yukarı 1 anlamına gelir. 0 ve 1'den kod tabanınızı oluşturabilirsiniz.

Döngüsel bir zamanlayıcı kullanın . Bu, kritik verilerin doğruluğunu kontrol etmek için düzenli bakım süreleri eklemenizi sağlar. En sık karşılaşılan sorun yığının bozulmasıdır. Yazılımınız döngüsel ise, döngüler arasındaki yığını yeniden başlatabilirsiniz. Yığınları kesme aramaları için yeniden kullanmayın, her önemli kesme aramasından ayrı bir yığın oluşturun.

Watchdog konseptine benzer şekilde son tarih zamanlayıcıları da vardır. Bir işlevi çağırmadan önce bir donanım zamanlayıcısı başlatın. Son tarih zamanlayıcısı kesilmeden önce işlev geri dönmezse, yığını yeniden yükleyin ve tekrar deneyin. 3/5 denemelerinden sonra hala başarısız olursa ROM'dan yeniden yüklemeniz gerekir.

Yazılımınızı parçalara ayırın ve ayrı bellek alanları ve yürütme süreleri kullanmak için bu parçaları izole edin (Özellikle bir kontrol ortamında). Örnek: sinyal toplama, ön değerlendirme verileri, ana algoritma ve sonuç uygulama / iletimi. Bu, bir bölümdeki bir hatanın programın geri kalanında arızalara neden olmayacağı anlamına gelir. Bu yüzden sinyal alımını onarırken geri kalan görevler eski veriler üzerinde devam eder.

Her şeyin CRC'lere ihtiyacı var. RAM'den yürütürseniz, .text'inizin bile bir CRC'ye ihtiyacı vardır. Döngüsel bir zamanlayıcı kullanıyorsanız CRC'leri düzenli olarak kontrol edin. Bazı derleyiciler (GCC değil) her bölüm için CRC üretebilir ve bazı işlemciler CRC hesaplamaları yapmak için özel donanıma sahiptir, ancak sanırım bu, sorunuzun kapsamının dışına düşecektir. CRC'leri denetlemek, bellekteki ECC denetleyicisini bir sorun haline gelmeden önce tek bit hatalarını onarmasını da ister.

İlk olarak, uygulamanızı hataya göre tasarlayın . Normal akış işleminin bir parçası olarak sıfırlamanın beklendiğinden emin olun (uygulamanıza ve yumuşak veya sert arıza türüne bağlı olarak). Mükemmel olmak zordur: belli derecede işlem gerektiren kritik işlemlerin bir montaj seviyesinde kontrol edilmesi ve ayarlanması gerekebilir, böylece kilit noktadaki bir kesinti tutarsız harici komutlara yol açamaz. Hızlı Fail en kısa sürede herhangi bir şekilde kurtarılamayan bellek bozulması veya kontrol akış sapma tespit edilmiştir. Mümkünse günlük hataları.

İkinci olarak, mümkünse, yolsuzluğu düzeltin ve devam edin . Bu, sabit tabloları (ve mümkünse program kodunu) sık sık denetleme ve düzeltme anlamına gelir; belki de her büyük işlemden önce veya zamanlanmış bir kesmede ve değişkenleri otomatik olarak düzelten yapılarda saklamak (yine her bir büyük op veya zamanlanmış bir kesmeden önce 3'ten çoğunluk oyu alır ve tek bir sapma ise doğrudur). Mümkünse düzeltmeleri günlüğe kaydedin.

Üçüncüsü, test hatası . Bir ayarlama tekrarlanabilir pseudo-rastgele bellekte bit çevirir test ortamı. Bu, yolsuzluk durumlarını çoğaltmanıza ve uygulamanızı bunların etrafında tasarlamanıza yardımcı olur.

Supercat'in yorumları, modern derleyicilerin eğilimleri ve diğer şeyler göz önüne alındığında, antik günlere geri dönüp tüm kodu montaj ve statik bellek ayırmalarında her yere yazmayı tercih ederim. Bu tür mutlak güvenilirlik için, montajın artık maliyette büyük bir yüzde fark yaratmadığını düşünüyorum.

İşte çok sayıda cevap, ama bununla ilgili fikirlerimi özetlemeye çalışacağım.

Bir şeyler çöküyor veya düzgün çalışmıyorsa kendi hatalarınızdan kaynaklanabilir - o zaman sorunu bulduğunuzda kolayca düzeltilmelidir. Ancak donanım arızaları olasılığı da vardır - ve genel olarak düzeltilmesi imkansız değilse bile bu zordur.

İlk önce (yığın, kayıtlar, işlev çağrıları) - ya onları bir yere dosyaya kaydederek veya bir şekilde doğrudan ileterek ("oh hayır - çöküyorum") sorunlu durumu yakalamaya çalışmanızı tavsiye ederim.

Bu tür hata durumlarından kurtarma, yeniden başlatma (yazılım hala canlıysa ve tekme yapıyorsa) veya donanım sıfırlamasıdır (örn. Hw watchdogs). İlkinden başlamak daha kolay.

Sorun donanımla ilgili ise - günlük kaydı, hangi işlev çağrısı sorununun oluştuğunu belirlemenize yardımcı olur ve bu size neyin çalışmadığı ve nerede çalışmadığı hakkında bilgi verebilir.

Ayrıca kod nispeten karmaşıksa - "bölmek ve fethetmek" mantıklıdır - yani sorunun şüphelendiğiniz bazı işlev çağrılarını kaldırır / devre dışı bırakırsınız - genellikle kodun yarısını devre dışı bırakır ve başka bir yarı etkinleştirirsiniz - "işe yarar" / "işe yaramaz" tür bir karar daha sonra kodun yarısına odaklanabilirsiniz. (Sorun nerede)

Bir süre sonra sorun oluşursa - o zaman yığın taşması şüphesi olabilir - o zaman sürekli büyürlerse yığın noktası kayıtlarını izlemek daha iyidir.

Ve "merhaba dünya" tür bir uygulama olana kadar kodunuzu tamamen en aza indirmeyi başarırsanız - ve hala rastgele başarısız olursa - o zaman donanım sorunları beklenir - ve "donanım yükseltme" olması gerekir - bu tür cpu / ram / icat anlamına gelir ... - radyasyonu daha iyi tolere edecek donanım kombinasyonu.

En önemli şey, makine tamamen durduysa / sıfırlanırsa / çalışmazsa muhtemelen günlüklerinizi nasıl geri alacağınızdır - muhtemelen bottap'ın yapması gereken ilk şey - sorunlu bir durum ortaya çıkarsa, eve bir kafa.

Ortamınızda bir sinyal iletmek ve yanıt almak da mümkünse - bir tür çevrimiçi uzaktan hata ayıklama ortamı oluşturmayı deneyebilirsiniz, ancak en azından iletişim ortamının çalışması ve çalışma durumunda bir miktar işlemci / bazı koç olması gerekir. Uzaktan hata ayıklama ile ya GDB / gdb saplama tür yaklaşımı ya da uygulamanızdan geri almak için neye ihtiyacınız olduğunu kendi uygulamanızı kastediyorum (örn. Günlük dosyalarını indir, çağrı yığınını indir, ram indir, yeniden başlat)

Gerçekten birçok harika cevap okudum!

İşte benim 2 sent: belleği kontrol etmek veya sık kayıt karşılaştırmaları yapmak için bir yazılım yazarak, bellek / kayıt anormalliğinin istatistiksel bir modelini oluşturun. Ayrıca, sorunu deneyebileceğiniz sanal bir makine tarzında bir emülatör oluşturun. Eğer bağlantı boyutu, saat frekansı, satıcı, kasa, vb değişirse sanırım farklı bir davranış gözlemlemek olacaktır.

Masaüstü bilgisayar belleğimiz bile belirli bir hata oranına sahiptir, ancak günlük işlere zarar vermez.