İyonlaştırıcı radyasyon ile bombardıman edilmiş bir ortamda korumalı bir cihaza yerleştirilmiş gömülü bir C/C++ uygulamasını derliyoruz. ARM için GCC kullanıyor ve çapraz derleme yapıyoruz. Dağıtıldığında, uygulamamız bazı hatalı veriler üretiyor ve istediğimizden daha fazla çöküyor. Donanım bu ortam için tasarlanmıştır ve uygulamamız bu platformda birkaç yıldır çalışmaktadır.
Kodumuzda yapabileceğimiz değişiklikler var mı, veya tekli olayların neden olduğu bellek bozulmalarını/düzeltmek için - yumuşak hataları ve hafıza bozulmasını belirlemek için yapılabilecek derleme zamanı iyileştirmeleri var mı? Diğer geliştiricilerin, uzun süredir devam eden bir uygulamada yumuşak hataların zararlı etkilerini azaltmada başarılı olduğu oldu mu?
minyatür uyduların * yazılım/ürün yazılımı geliştirme ve çevre testi ile yaklaşık 4-5 yıl çalışarak, deneyimlerimi burada paylaşmak istiyorum.
* (minyatürleştirilmiş uydular, elektronik bileşenleri için nispeten küçük, sınırlı boyutlarından dolayı, tek olaylardaki rahatsızlıklara göre daha büyük uydulara göre daha fazla eğilimlidir)
Çok özlü ve doğrudan olmak için: algılanabilir, hatalı Durum tarafından yazılım/bellenimin kendisi tarafından algılanabilir, hatalı Durum tarafından kurtarılacak bir mekanizma yoktur. kopya of asgari çalışma sürümü yazılımın/bellenimin bir yerdekurtarma amacı için - ve kurtarmayı destekleyen donanım) ile } _ (işlevsel).
Şimdi, bu durum normalde hem donanım hem de yazılım düzeyinde ele alınmaktadır. Burada, istediğiniz gibi, yazılım seviyesinde neler yapabileceğimizi paylaşacağım.
... kurtarma amacı .... Yazılımınızı/donanım yazılımınızı gerçek ortamda güncelleme/yeniden derleme/yeniden başlatma yeteneği sağlayın. Bu, yüksek oranda iyonlaşmış ortamdaki herhangi bir yazılım/ürün yazılımı için _ {(neredeyse olması gereken özelliğidir. Bu olmadan, olabilir istediğiniz kadar gereksiz yazılıma/donanıma sahip olursunuz, ancak bir noktada hepsi patlayacak. Öyleyse bu özelliği hazırla!
... minimum çalışma sürümü ... Sorumlu, çoklu kopyaları, kodunuzdaki yazılımın/bellenimin minimum sürümünü bulun. Bu, Windows'ta Güvenli mod gibidir. Yazılımınızın yalnızca bir tam işlevsel sürümüne sahip olmak yerine, yazılımın/donanım yazılımının minimum sürümünün birden fazla kopyası vardır. Asgari kopya genellikle tam kopyadan çok daha az boyutta olacaktır ve neredeyse her zaman yalnızca izleyen iki veya üç özelliğe sahiptir:
... copy ... bir yere ... Bir yere gereksiz yazılım/ürün yazılımı yükleyin.
Gereksiz donanım olmadan veya ile, ARM uC’nizde yedekli yazılım/ürün yazılımı bulundurmayı deneyebilirsiniz. Bu normalde, birbirine kalp atışı gönderen iki veya daha fazla aynı yazılıma/ürün bilgisine ayrı adreslerde sahip olur - ancak bir seferde yalnızca biri aktif olur. Bir veya daha fazla yazılımın/bellenimin yanıt vermediği biliniyorsa, diğer yazılıma/bellenime geçin. Bu yaklaşımı kullanmanın yararı, bir hata oluştuktan hemen sonra işlevsel bir şekilde değiştirebilmemizdir - hatayı tespit etmekten ve ondan sorumlu olan herhangi bir harici sistem/tarafla temas etmeden (uydu durumunda, genellikle Görev Kontrol Merkezi'dir) MCC)).
Kesin olarak konuşursak, gereksiz donanım olmadan, bunu yapmanın dezavantajı aslında yapamazsınız) _ _ _ ortadan kaldırıyor _ {(tümü tek hata noktasıdır. En azından, hala bir tek başarısızlık noktanız olacak, bu da anahtarın kendisi (ya da genellikle kodun başlangıcı) olacaktır. Bununla birlikte, büyük ölçüde iyonlaşmış bir ortamda (pico/femto uyduları gibi) büyüklüğü ile sınırlandırılmış bir cihaz için, tek bir hata noktasının bir noktaya indirilmesi olmadan ilave donanımlar yine de dikkate değer olacaktır. Bir başka deyişle, anahtarlama için kod parçası kesinlikle tüm programın kodundan çok daha az olacaktır - bu, içinde Tek Olay olma riskini önemli ölçüde azaltır.
Ancak, bunu yapmıyorsanız, harici sisteminizde cihazla temasa geçebilecek ve yazılımı/bellenimi güncelleyebilecek en az bir kopyaya sahip olmalısınız (uydu durumunda yine görev kontrol merkezidir).
... algılanabilir hatalı durum .. Hata, algılanabilir olmalıdır, genellikle donanım hata düzeltme/algılama devresi veya hata düzeltme için küçük bir kod parçası ile/tespiti. Bu kodun en küçük, çoklu ve bağımsız ana yazılımdan/bellenimi koymak en iyisidir. Başlıca görevi kontrol etmek/düzeltmek için yalnızca'dur. Donanım devresi/bellenimi güvenilir ise (diğerlerinden daha fazla radyasyona maruz kalmış - veya çoklu devrelere/mantıklara sahipse), bununla birlikte hata düzeltmeyi düşünebilirsiniz. Fakat değilse, hata tespiti yapmak daha iyidir. Düzeltme harici sistem/cihaz olabilir. Hata düzeltmesi için Hamming/Golay23 gibi temel bir hata düzeltme algoritmasını kullanmayı düşünebilirsiniz, çünkü her ikisi de devrede/yazılımda daha kolay uygulanabilir. Ama sonuçta ekibinizin yeteneğine bağlı. Hata tespiti için normal olarak CRC kullanılır.... kurtarmayı destekleyen donanım Şimdi, bu konuda en zor olanı geliyor. Sonuçta, kurtarma, kurtarma işleminden sorumlu olan donanımı en azından işlevsel kılmak zorundadır. Donanım kalıcı olarak arızalanırsa (normalde Toplam iyonize etme dozunun belirli bir seviyeye ulaşmasından sonra gerçekleşir), o zaman (ne yazık ki) yazılımın kurtarma işlemine yardımcı olması için hiçbir imkan yoktur. Bu nedenle, donanım yüksek radyasyon seviyesine (uydu gibi) maruz kalan bir cihaz için haklı olarak en büyük önem taşır.
ADC okumaya filtre uygulayın. Değil ADC değerini doğrudan kullanın. Filtreyi medyan filtre, ortalama filtre veya başka bir filtre ile filtrele - asla tekil okuma değerine güvenir. Daha fazla numune al, daha az değil - makul olarak.
Filter in your ADC reading. Do not use the ADC reading directly. Filter it by median filter, mean filter, or any other filters - never trust single reading value. Sample more, not less - reasonably.
NASA'da radyasyonla sertleştirilmiş kağıt yazılımı var. Üç ana görevi anlatıyor:
Bellek tarama hızının, çok bitli hataların nadiren ortaya çıkabileceği kadar sık olması gerektiğine dikkat edin, çünkü çoğu ECC belleği, çoklu bit hatalarından değil, tek bit hatalarından kurtarabilir.
Sağlam hata kurtarma, kontrol akışı aktarımını (tipik olarak hatadan önceki bir noktada yeniden başlatmak), kaynak yayın ve veri restorasyonunu içerir.
Veri restorasyonu için temel önerileri, ara verinin geçici olarak ele alınması yoluyla buna ihtiyaç duymamaktan kaçınmaktır, böylece hatanın yeniden başlatılması da verileri güvenilir bir duruma döndürür. Bu, veritabanlarındaki "işlemler" kavramına benzer.
C++ gibi nesne yönelimli diller için özellikle uygun teknikleri tartışıyorlar. Örneğin
Ve, aynen böyle olur, 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ı bir gelişim ve test sağladı.
Sorun yaratabilecek bazı C++ özelliklerinden kaçınıyorlardı:
newve
deletedışında)
newkullanılır).
İşte bazı düşünce ve fikirler:
ROM öğesini 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örel tablonuzu ROM'da saklayın. Elbette, ROM cihazınızın RAM’inize kıyasla ne kadar güvenilir olduğunu görmek için bazı testler yapın.
Yığın için elinizden gelenin en iyisini RAM kullanın.
Yığındaki SEU'lar muhtemelen en büyük çöküş kaynağıdır, çünkü indeks değişkenleri, durum değişkenleri, dönüş adresleri ve çeşitli türdeki işaretçiler gibi şeylerin yaşadığı yerdir.
Zamanlayıcı-onaylama ve izleme zamanlayıcı zamanlayıcı yordamlarını uygulayın.
Her kilitleniş onay kutucuğunun bir "sağlıklılık kontrolü" rutini ve sistemin kilitlenmesi için bir bekçi uygulaması rutini ç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.
Uygula hata düzeltme kodları yazılım içinde.
Hataları tespit edebilmek ve/veya düzeltebilmek için verilerinize fazlalık ekleyebilirsiniz. Bu, işlemciyi daha uzun süre radyasyona maruz bırakacak şekilde potansiyel olarak bırakacak, böylece hata olasılığını artıracak şekilde işlem süresi ekleyecektir, bu yüzden değiş tokuş yapmalısınız.
Önbellekleri unutma.
CPU önbelleklerin 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. En azından bazı önbellekleri devre dışı bırakabileceğinizi düşünüyorum (büyük bir performans maliyetiyle); önbelleklerin SEU'lara ne kadar duyarlı olduğunu görmek için bunu denemelisiniz. Önbelleklerin RAM 'dan daha sert olması durumunda, önbellekte kaldığından emin olmak ve RAM satırına geri getirmek için kritik verileri düzenli olarak okuyabilir ve yeniden yazabilirsiniz.
Sayfa hatası işleyicilerini akıllıca kullanın.
Bellek sayfasını mevcut değil olarak işaretlerseniz, erişmeye çalıştığınızda CPU bir sayfa hatası verir. Okuma isteğini yerine getirmeden önce bir miktar kontrol yapan bir sayfa hatası işleyicisi oluşturabilirsiniz. (PC işletim sistemleri bunu, diske değiştirilmiş sayfaları şeffaf bir şekilde yüklemek için kullanır.)
Assembly dilini kritik şeyler için kullanın (ki her şey olabilir).
Assembly dili ile, know, kayıtlardakileri ve RAM'dekileri; know hangi özel RAM CPU’nun kullandığı tabloları gösterir ve riskinizi düşük tutmak için işleri dolambaçlı bir şekilde tasarlayabilirsiniz.
Oluşturulan Assembly diline bakmak için
objdump komutunu kullanın ve her bir yordamınızın ne kadar kod alacağını hesaplayın.
Eğer Linux gibi büyük bir işletim sistemi kullanıyorsanız sorun mu istiyorsunuz? sadece çok fazla karmaşıklık ve yanlış giden bir çok şey var.
Unutmayın, bir olasılıklar oyunu.
Bir yorumcu dedi
Hataları yakalamak için yazdığınız her rutin, aynı nedenden dolayı başarısızlığa maruz kalacaktır.
Bu doğruysa, (örneğin) 100 bayt kodundaki hataların ve bir kontrol rutininin doğru çalışması için gereken verilerin başka yerlerde hata yapma ihtimalinden çok daha küçük olması. ROM cihazınız oldukça güvenilirse ve neredeyse tüm kod/veriler aslında ROM 'da ise, ihtimaliniz daha da iyi olacaktır.
Yedek donanım kullanın.
Aynı kodla 2 veya daha fazla aynı donanım kurulumu kullanın. Sonuçlar farklıysa, sıfırlama tetiklenmelidir. 3 veya daha fazla cihazda, hangisinin tehlikeye atıldığını tespit etmek için bir "oylama" sistemi kullanabilirsiniz.
Ayrıca algoritmik hata toleransı konusundaki zengin literatürle de ilgilenebilirsiniz. Bu eski atamayı da içerir: Sabit sayıda karşılaştırma başarısızlıkla sonuçlandığında (veya, biraz daha kötü sürümde, asemptolojik başarısız karşılaştırmaların
n karşılaştırmaları için
log(n) olarak ölçeklendiğinde) girişini doğru sıralayan bir sıralama yazın.
Okumaya başlama yeri Huang ve Abraham'ın 1984 tarihli makalesi " Matris İşlemlerinde Algoritma Tabanlı Hata Toleransı " dır. Fikirleri açıkça homomorfik şifreli hesaplamaya benziyor (ancak işlem düzeyinde hata bulma/düzeltme yapmaya çalıştıkları için gerçekten aynı değil).
Bu makalenin daha yeni soyundan gelenler Bosilca, Delmas, Dongarra ve Langou'nun " Yüksek Performanslı Hesaplamaya Uygulanan Algoritma Tabanlı Hata Toleransı " dır.
Radyoaktif ortamlar için kod yazmak, kritik bir uygulama için kod yazmaktan gerçekten farklı değildir.
Bahsedilenlere ek olarak, işte bazı çeşitli ipuçları:
ÖNEMLİ: Dahili MCU kayıtlarının bütünlüğünü sağlamalısınız. Yazılabilir donanım çevre birimlerinin tüm kontrol ve durum kayıtları RAM belleğinde yer alabilir ve bu nedenle savunmasızdır.
Kayıt bozulmalarına karşı kendinizi korumak için, tercihen kayıtların yerleşik "bir kez yaz" özelliklerine sahip bir mikroişlemci seçin. Ek olarak, tüm donanım kayıtlarının varsayılan değerlerini NVM'de saklamanız ve bu değerleri düzenli aralıklarla kayıt defterinize kopyalamanız gerekir. Önemli değişkenlerin bütünlüğünü aynı şekilde sağlayabilirsiniz.
Not: daima savunma amaçlı programlama kullanın. Yani, sadece uygulama tarafından kullanılanları değil, MCU'ya tümü kaydını ayarlamak zorundasınız. Bazı 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", ECC yazılımı vb. Günümüzde en iyi çözüm bunlardan herhangi birini kullanmamak, yerleşik bir MCU kullanmaktır. - ECC ve benzeri kontrollerde. Çünkü bunu yazılımda yapmak karmaşıktır ve kendi içinde hata kontrolü bu nedenle hataları ve beklenmedik sorunları doğurabilir.
Savunma programlaması kavramını anlayın ve benimseyin. Bu, programınızın tüm olası durumları, teoride oluşamayanları bile ele alması gerektiği anlamına gelir. Örnekler .
Yüksek kalite kritik görevli bellenim, olabildiğince fazla hata algılar ve bunları güvenli bir şekilde dikkate almaz.
ÖNEMLİ: Statik depolama süresi değişkenlerinin varsayılan değerlerine güvenmeyin. Yani,
.data veya
.bss öğelerinin varsayılan içeriğine güvenmeyin. Başlatma noktası ile değişkenin gerçekte kullanıldığı nokta arasında herhangi bir zaman olabilir, RAM öğesinin bozulması için çok zaman olabilirdi. Bunun yerine, programı, bu tür değişkenlerin ilkinde bu tür bir değişkenin kullanıldığı zamanın hemen öncesinde NVM'den çalışma zamanında ayarlanacak şekilde yazın.
Pratikte bunun anlamı, eğer bir değişken dosya kapsamında bildirilirse veya
static olarak bildirilirse, onu başlatmak için asla
= kullanmamalısınız (ya da olabilirsiniz, ama bu anlamsızdır, çünkü hiçbir şekilde değere güvenemezsiniz). Her zaman kullanmadan hemen önce çalışma zamanında ayarlayın. Bu tür değişkenleri NVM'den art arda güncellemek mümkün ise, o zaman yapın.
Benzer şekilde C++ 'da, statik saklama süresi değişkenleri için yapıcılara güvenmeyin. Yapıcı (lar) ın daha sonra çalışma anında doğrudan arayan uygulamasından da arayabileceğiniz ortak bir "kurulum" rutini çağırmasını sağlayın.Mümkünse,
.data ve
.bss (ve C++ yapıcılarını çağıran) tamamen başlatan "aşağı-yukarı" başlangıç kodunu kaldırın, böylelikle buna bağlı olarak kod yazdığınızda bağlantı hataları alırsınız. Çoğu derleyicide, bunu genellikle "minimal/hızlı başlangıç" veya benzeri olarak adlandırılan seçenekler atlayabilir.
Bu, herhangi bir dış kütüphanenin böyle bir güven içermemesi için kontrol edilmesi gerektiği anlamına gelir.
.
Bir hata raporu/hata günlüğü sistemi uygulamak her zaman yardımcı olur.
Size yardımcı olabilecek bir bekçi köpeği . Watchdog'lar 1980'lerde endüstriyel bilgisayarlarda yoğun bir şekilde kullanıldı. Donanım arızaları o zaman çok daha yaygındı - başka bir cevap da o döneme işaret ediyor.
Bir bekçi köpeği, birleşik bir donanım/yazılım özelliğidir. Donanım, sayıdan (1023) sıfıra kadar geri sayım yapan basit bir sayaçtır. TTL veya başka bir mantık kullanılabilir.
Yazılım, bir rutin bütün temel sistemlerin doğru çalışmasını izleyecek şekilde tasarlanmıştır. Bu yordam doğru tamamlanırsa = iyi çalışan bilgisayarı bulursa, sayacı 1023'e geri ayarlar.
Genel tasarım, normal şartlar altında, yazılım 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 yerine getirir ve tüm sistemi sıfırlar. Bir sayaç açısından, sıfır, 1024'e eşittir ve sayaç, geri saymaya devam eder.
Bu bekçi eki, bağlı bilgisayarın çok sayıda başarısızlık 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. Dış donanıma arabirimler artık eskisinden çok daha karmaşık.
Bekçi köpeğinin doğal bir dezavantajı, bekçi sayacı sıfıra + yeniden başlatma zamanına ulaşana kadar sistemin başarısız olduğu andan itibaren mevcut olmamasıdır. Bu süre genellikle herhangi bir dış veya insan müdahalesinden çok daha kısa olsa da, desteklenen ekipmanın bu süre boyunca bilgisayar kontrolü olmadan devam edebilmesi gerekir.
Bu son derece geniş bir konudur. Temel olarak, bellek bozulmasından gerçekten kurtulamazsınız, ancak en azından hemen başarısız'ı deneyebilirsiniz. İşte kullanabileceğiniz birkaç teknik:
sağlama toplamı sabiti verisi. Uzun süre sabit kalan herhangi bir konfigürasyon verileriniz varsa (konfigüre ettiğiniz donanım kayıtları dahil), başlangıçtaki kontrol toplamını hesaplayın ve periyodik olarak doğrulayın. Bir uyumsuzluk gördüğünüzde, yeniden başlatma veya sıfırlama zamanı gelmiştir.
yedeklemeli değişkenleri sakla.
x önemli bir değişkeniniz varsa, değerini
x1,
x2 ve
x3 yazın ve
(x1 == x2) ? x2 : x3 olarak okuyun.
uygulayın program akışı izleme. 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ı ile radyasyon içermeyen bir ortamda çalıştırmak, size bayrağın sonunda bayrağın kabul edilebilir değerlerinin bir listesini vermelidir. Sapma görürseniz sıfırlayın.
yığın işaretçisini izler. Ana döngünün başında, yığın işaretçisini beklenen değeri ile karşılaştırın. Sapma sıfırlayın.
Bu cevap, asgari maliyet veya hızlı bir sisteme sahip olan, doğru çalışan, sürekli ve daha yüksek olan bir sisteme sahip olduğunuzu varsayar; radyoaktif şeylerle oynayan çoğu kişi hız/maliyet üzerinden doğruluğu/güvenliği önemser
Bazı insanlar yapabileceğiniz donanım değişikliklerini önerdiler (para cezası - burada cevaplarda çok fazla iyi şeyler var ve hepsini yinelemeyi düşünmüyorum) ve diğerleri fazlalık önerdi (ilke olarak büyük) kimse bu fazlalığın pratikte nasıl çalışabileceğini önerdi. Nasıl başarısız oluyorsun? Bir şeylerin “yanlış gittiğini” nasıl anlarsınız? Birçok teknoloji, her şeyin işe yarayacağına dayanarak çalışır ve bu nedenle başarısızlık uğraşması zor bir şeydir. Bununla birlikte, ölçeği için tasarlanan bazı dağıtılmış hesaplama teknolojileri başarısızlık bekler (sonuçta yeterli ölçeğe sahip, bir çoğunun düğümünün başarısızlığı, herhangi bir MTBF bir düğüm için kaçınılmazdır); Bunu çevreniz için kullanabilirsiniz.
İşte bazı fikirler:
Tüm donanımınızın
n times (burada
n'nin 2'den büyük ve tercihen garip olduğu) çoğaltıldığından ve her donanım öğesinin diğer 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 var (örneğin, CAN). Yaygın bileşenleri en aza indirin (hatta güç kaynakları). Bu, örneğin ADC girişlerini birçok yerde örnekleme anlamına gelebilir.
Başvuru durumunuzun tek bir yerde olduğundan emin olun, ör. sonlu durumlu bir makinede. Tamamen RAM tabanlı olabilir, ancak sabit depolama alanı engellemez. Böylece birkaç yerde depolanacaktır.
Devlet değişiklikleri için bir çekirdek protokolü kabul edilmesi. Bkz. RAFT örneğin. C++ 'da çalışırken, bunun için iyi bilinen kütüphaneler vardır. FSM’de yapılan değişiklikler ancak çoğu düğümün kabul etmesi durumunda gerçekleşir. Protokol yığını ve çekirdeği protokolü için bilinen bir kitaplığı kullanın; kendiniz yuvarlamak yerine, fazlalık konusundaki tüm iyi işler, çekirdek protokolü kapatıldığında boşa gider.
FSM'nizi sağlama aldığınızdan emin olun (örn. CRC/SHA) ve CRC/SHA'yı FSM'nin içinde saklayın (ayrıca iletiyi iletir ve mesajları kendileri denetler). Düğümlerini, FSM'lerini düzenli olarak bu sağlama toplamı, sağlama toplamı gelen iletilere karşı denetleyin ve sağlama toplamının sağlama toplamı ile aynı olup olmadığını kontrol edin.
Sisteminize mümkün olduğu kadar çok sayıda iç kontrol kurun, böylece kendi hatalarının yeniden başladığını tespit eden düğümler oluşur (bu, yeterince düğümünüz olması koşuluyla yarı çalışmaya devam etmekten daha iyidir). Tekrar gelmemeleri durumunda yeniden başlatma sırasında kendilerini çekirdeğinden temiz bir şekilde çıkarmalarına izin vermeye çalışın. Yeniden başlatırken, çekirdeğe yeniden girmeden önce yazılım görüntüsünü (ve yükledikleri herhangi bir şeyi) kontrol etmelerini sağlayın ve tam RAM test yapın.
Sizi desteklemek için donanım kullanın, ancak 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 paniklebilirsiniz). Bununla birlikte (bellekten) statik RAM iyonlaştırıcı radyasyona DRAM'de olduğundan daha fazla toleranslıdır, bu nedenle yerine statik DRAM kullanmak daha iyi olabilir. 'Yapmayacağım şeylerin' altındaki ilk noktayı da görün.
Diyelim ki herhangi bir düğümde bir gün içinde% 1 başarısızlık şansınız var ve hadi tamamen başarısızlıklar yapıyormuş gibi yapalım. 5 düğümle, bir günde üç başarısızlığa ihtiyacınız olacak, bu da% 10000 şans. Dahası, iyi, sen fikir olsun.
Yapacağım şeyler değil yaparlar:
Başlamakta sorun yaşamamanın değerini küçümseyin. Ağırlık bir endişe olmadığı sürece, cihazınızın etrafındaki büyük bir metal blok, bir programcı ekibinin gelebileceğinden çok daha ucuz ve daha güvenilir bir çözüm olacaktır. EMI girişlerinin aynen optik olarak bağlanması bir sorundur, vb. Her ne olursa olsun, iyonize radyasyona karşı en iyi puan alanlara kaynak sağlamak için bileşenlerinizi tedarik etmeye çalışın.
Kendi algoritmalarınızı döndürün. İnsanlar bunu daha önce yapmış. İşlerini kullan. Hata toleransı ve dağıtılmış algoritmalar zordur. Mümkünse başkalarının çalışmalarını kullanın.
Karmaşık derleyici ayarlarını, daha fazla hata tespit edeceğiniz umuduyla kullanın. Şanslıysanız, daha fazla başarısızlık tespit edebilirsiniz. Daha büyük olasılıkla, derleyicide daha az test edilmiş olan bir kod yolunu kullanacaksınız, özellikle de kendiniz yuvarladıysanız.
Ortamınızda test edilmeyen teknikleri kullanın. Yüksek kullanılabilirlik yazılımı yazan çoğu kişi, HA'larının doğru çalıştığını kontrol etmek için arıza modlarını simüle etmek zorunda kalır ve bunun sonucunda birçok arıza modunu kaçırır. Talep üzerine sık sık başarısızlık yaşadığınız için 'şanslı' konumdasınız. Bu nedenle, her tekniği test edin ve uygulamasının gerçekliğin MTBF, onu tanıtmak için karmaşıklığı aşan bir miktarla geliştirmesini sağlayın (karmaşıklıkla birlikte hatalar gelir). Özellikle bunu benim önerim ve yeterlilik algoritmaları vs. için de geçerlidir.
Özellikle yazılım çözümleri istediğiniz ve C++ kullandığınız için neden kendi güvenli veri türlerinizi oluşturmak için operatör aşırı yüklemesini kullanmıyorsunuz? Örneğin:
uint32_t (ve
double,
int64_t etc) kullanmak yerine, birden fazla (en az 3) uint32_t içeren kendi
SAFE_uint32_t'nuzu yapın. Gerçekleştirmek istediğiniz tüm işlemleri (* + -/<< >> = ==! = Etc) yapın ve aşırı yüklenmiş işlemlerin her bir iç değer üzerinde bağımsız olarak çalışmasını sağlayın, yani bir kez yapmayın ve sonucu kopyalayın. Hem öncesi hem de sonrası, tüm dahili değerlerin eşleştiğini kontrol edin. Değerler eşleşmiyorsa, yanlış olanı en yaygın olanı olan değere güncelleyebilirsiniz. En yaygın kullanılan değer yoksa, bir hata olduğunu güvenle bildirebilirsiniz.
Bu şekilde, ALU'da, kayıt defterlerinde, RAM'de veya bir otobüste yolsuzluk oluşması önemli değildir, yine de birden çok denemeniz ve hata yakalama şansınız çok yüksektir. Bununla birlikte, bunun yalnızca değiştirebileceğiniz değişkenler için geçerli olmasına rağmen, örneğin yığın işaretçiniz yine de duyarlı olacaktır.
Bir yandan hikaye: Ben de eski bir ARM çipte benzer bir sorunla karşılaştım. GCC'nin eski bir sürümünü kullanan, kullandığımız özel yonga ile birlikte, bazı Edge vakalarında (bazen) işlevlerin bozulmasına neden olabilecek bozulmaları tetikleyen bir hata olduğu ortaya çıktı. Cihazınızın radyo etkinliğini suçlamadan önce herhangi bir sorunu olmadığından emin olun ve evet, bazen bir derleyici hatasıdır =)
Feragatname: Radyoaktivite uzmanı değilim ya da bu tür uygulamalar için çalıştım. Ancak, biraz bağlantılı (aynı sorun, farklı hedefler) olan uzun vadeli kritik verilerin arşivlenmesi için yumuşak hatalar ve artıklık üzerinde çalıştım.
Radyoaktivite ile ilgili temel sorun bence radyoaktivitenin bit değiştirebileceği, yani radyoaktivite herhangi bir dijital belleği değiştirebilir/değiştirebilir. Bu hatalara genellikle yumuşak hatalar , bit rot, vb. Denir.
O zaman soru şudur: belleğiniz 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ğından hesaplama yükü pahasına), aşağıdakilerden birini yapabilirsiniz:
eski güzel artıklık şeması 'e ve daha spesifik olarak daha verimli hata düzeltme kodları' e (aynı amaç, ancak daha akıllıca olan algoritmalar) daha az fazlalık olan bitler). Bu bazen (yanlış) checksumming olarak da adlandırılır. 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ı?) Saklamanız, bir ECC hesaplamanız ve herhangi bir şey yapmadan önce ECC'nin doğru olup olmadığını kontrol etmeniz gerekir. değil, alanları tamir et. Ancak bu çözüm, yazılımınızın çalışabileceğini garanti etmiyor (yalnızca çalışabildiği zaman doğru çalışacağını veya çalışmamasını durduracağını, çünkü ECC bir şeylerin yanlış olup olmadığını söyleyebilir ve bu durumda yazılımınızı durdurabilirsiniz. sahte sonuçlar alamadım).
ya da bazı sınırlara kadar programınızın yumuşak hataların varlığında bile doğru sonuçlar vermesini garanti eden esnek algoritmik veri yapıları kullanabilirsiniz. Bu algoritmalar, ECC şemaları ile doğal olarak karıştırılmış ortak algoritmik yapıların bir karışımı olarak görülebilir, ancak esneklik şeması yapıya sıkıca bağlı olduğundan, ek prosedürleri kodlamanıza gerek kalmaması için bundan çok daha esnektir ECC'yi kontrol etmek için, ve genellikle daha hızlıdırlar. Bu yapılar, programınızın yumuşak hataların teorik sınırlarına kadar her koşulda çalışmasını sağlamak için bir yol sağlar. Ayrıca, bu esnek yapıları ek güvenlik için artıklık/ECC şemasıyla karıştırabilir (veya en önemli veri yapılarınızı esnek olarak kodlayabilir ve geri kalanını, ana veri yapılarından yeniden hesaplayabileceğiniz harcanabilir verileri kodlayabilirsiniz. ECC veya hesaplanması çok hızlı olan bir parite kontrolü bit).
Esnek veri yapılarıyla ilgileniyorsanız (algoritmalar ve artıklık mühendisliğinde yeni ama heyecan verici, yeni bir alan), aşağıdaki belgeleri okumanızı tavsiye ederim:
Christiano, P., Demaine, E.D., ve Kishore, S. (2011). Ek yükü olan kayıpsız hataya dayanıklı veri yapıları. Algoritma ve Veri Yapıları (s. 243-254). Springer Berlin Heidelberg.
Ferraro-Petrillo, U., Grandoni, F., ve Italiano, G.F. (2013). Hafıza hatalarına dirençli veri yapıları: sözlüklerin deneysel bir çalışması. Deneysel Algoritma Dergisi (JEA), 18, 1-6.
Italiano, G.F. (2010). Esnek algoritmalar ve veri yapıları. Algoritma ve Karmaşıklıkta (s. 13-24). Springer Berlin Heidelberg.
Esnek veri yapılarının alanı hakkında daha fazla bilgi edinmek istiyorsanız,/- Giuseppe F. Italiano ('nın çalışmalarını referansları üzerinden inceleyebilirsiniz) ve Hatalı RAM modeli (Finocchi ve diğerleri, 2005; Finocchi ve Italiano 2008'de tanıtıldı).
/ EDIT: Öncelik/kurtarma hatalarını temel olarak RAM bellek ve veri depolama için gösterdi, fakat hesaplama (CPU) hataları hakkında konuşmadım. Diğer cevaplar, veritabanlarında olduğu gibi atomik işlemleri kullanmaya dikkat çekti, bu yüzden başka, daha basit bir şema önereceğim: yedeklilik ve çoğunluk oyu.
Buradaki fikir, yapmanız gereken her hesaplama için basitçe aynı hesaplamanın x katını yapın ve sonucu x farklı değişkenlerde (x> = 3 ile) saklamanızdır. Daha sonra x değişkenlerinizi karşılaştırın:
Böylece, çoğunluk oyuyla, bozuk çıktıdan güvende olursunuz ve fazlalık x == 3 ile 1 hatayı düzeltebilirsiniz (x == 4 ile 2 hata kurtarılabilir, vs. olur) - tam denklem
nb_error_recoverable == (x-2), burada x, hesaplama tekrarı sayısı, çoğunluk oyu ile geri kazanmak için en az 2 kabul edilen hesaplamaya ihtiyacınız var çünkü).
Dezavantajı, bir defa yerine x kere hesaplamanız gerektiği, bu nedenle ek bir hesaplama maliyetine sahip olmanız, ancak lineer karmaşıklığı böylece asimptotik olarak kazandığınız faydalar için çok fazla kaybetmezsiniz. Çoğunlukla oy kullanmanın hızlı bir yolu, bir dizideki modu hesaplamaktır, ancak ayrıca bir medyan filtresi de kullanabilirsiniz.
Ayrıca, hesaplamaların doğru yapıldığından emin olmak istiyorsanız, kendi donanımınızı yapabilirseniz, cihazınızı x CPU'lar ile yapılandırabilir ve sistemi, hesaplamalar otomatik olarak x CPU'lar arasında çoğaltılmış oylamalarla kopyalanacak şekilde yapabilirsiniz. mekanik olarak sonunda (ö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 yolla, herhangi bir hesaplama ek yükünüz olmaz (ek hesaplamalar paralel olarak yapılacaksa) ve yazılım hatalarından başka bir koruma katmanınız olur (hesaplama çoğaltması ve çoğunluk oyu doğrudan donanım tarafından yönetilir, çünkü bir program bellekte saklanan bitler olduğundan daha kolay bozulabilen yazılımlar ...).
Also, if you want to make extra sure the calculations are conducted correctly, if you can make your own hardware you can construct your device with x CPUs, and wire the system so that calculations are automatically duplicated across the x CPUs with a majority vote done mechanically at the end (using AND/OR gates for example). This is often implemented in airplanes and mission-critical devices (see triple modular redundancy ). This way, you would not have any computational overhead (since the additional calculations will be done in parallel), and you have another layer of protection from soft errors (since the calculation duplication and majority vote will be managed directly by the hardware and not by software -- which can more easily get corrupted since a program is simply bits stored in memory...).
Radyasyon ortamı dışında bir efendiye sahip 3+ köle makinesi istiyorsunuz. Tüm G/Ç'ler, oylama ve/veya yeniden deneme mekanizması içeren ana sistemden geçer. Köleler her birinin bir donanım gözetleyicisine sahip olmalı ve onları çarpma çağrısı, istem dışı çarpma olasılığını azaltmak için CRC'ler veya benzeriyle çevrelenmelidir. Çarpma, master tarafından kontrol edilmelidir, bu yüzden master ile olan bağlantınız kopması birkaç saniye içinde yeniden başlar.
Bu çözümün bir avantajı, efendi ile aynı API'yi kölelerle kullanabilmenizdir, böylece artıklık şeffaf bir özellik haline gelir.
Edit: Yorumlardan "CRC fikrini" netleştirmeye ihtiyacım olduğunu hissediyorum. Köse çarpmanın kendi bekçi köpeği olma olasılığı, kaburgayı CRC ile çevreleyen veya masterdan rasgele veri üzerindeki kontrolleri sindirirseniz sıfıra yakındır. Bu rasgele veriler yalnızca denetim altındaki köle diğerleriyle aynı hizada olduğunda ana birimden gönderilir. Rastgele veri ve CRC/özet her yumrudan hemen sonra temizlenir. Master-slave çarpma frekansı, bekçi zaman aşımı çift 'den fazla olmalıdır. Master'dan gönderilen veriler her seferinde benzersiz bir şekilde oluşturulur.
Bir nokta kimsenin bahsetmediği anlaşılıyor. GCC'de geliştiğini ve ARM ile çapraz derlendiğini söylüyorsun. Serbest RAM, tamsayı boyutu, işaretçi boyutu, belirli bir işlemin ne kadar sürdüğü, sistemin sürekli olarak ne kadar süreyle çalışacağı veya bunun gibi çeşitli şeylerle ilgili varsayımlar yapan kodunuz olmadığını nasıl biliyorsunuz? Bu çok yaygın bir sorundur.
Cevap genellikle otomatik birim testidir. Geliştirme sistemindeki kodu kullanan test donanımları yazın, ardından hedef sistemde aynı test donanımlarını çalıştırın. Farklılıkları ara!
Ayrıca gömülü cihazınızdaki hataları kontrol edin. "Bunu bozmadığı için yapmayın, bu nedenle derleyici seçeneğini etkinleştirin ve derleyici bunun üzerinde çalışacaktır" hakkında bir şeyler bulabilirsiniz.
Kısacası, en olası çöküş kaynağınız kodunuzdaki hatalardır. Durumun böyle olmadığından emin olana kadar, daha ezoterik arıza modları için endişelenme (henüz).
Uygulamanızın birçok örneğini çalıştırmaya ne dersiniz? Çökmeler rasgele bellek bit değişikliklerinden kaynaklanıyorsa, şansınız uygulama örneklerinden bazılarının bunu yapıp doğru sonuçlar üretmesidir. İstediğiniz kadar küçük bir hata elde etmek için bit flop olasılığı verilmiş olan kaç örneğe ihtiyacınız olduğunu hesaplamak muhtemelen oldukça kolaydır (istatistiksel arka planı olan biri için).
Donanımınız arızalanırsa, geri yüklemek için mekanik depolama alanını kullanabilirsiniz. Kod tabanınız küçükse ve biraz fiziksel alana sahipseniz, mekanik bir veri deposu kullanabilirsiniz.
Radyasyondan etkilenmeyecek bir malzeme yüzeyi olacaktır. Birden fazla vites orada olacak. Mekanik bir okuyucu tüm dişliler üzerinde çalışacak ve yukarı ve aşağı hareket etmek için esnek olacaktır. Aşağı, 0 ve yukarı 1 demektir. 0 ve 1'den kod tabanınızı oluşturabilirsiniz.
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 yaratabilecek özel bir MCU'muz vardı, ancak bazı gecikmelerde, örneğin, bazı döngüler SEU istisnasına neden olan insn'den sonra geçebilir/komutlar uygulanabilir.
Özellikle savunmasız olanlar veri önbelleğiydi, bu nedenle bir işleyici rahatsız edici önbellek satırını geçersiz kılar ve programı yeniden başlatır. Ancak, istisnanın kesin doğası gereği istisna artırıcı insanoğlunun yönlendirdiği insn dizisi yeniden başlatılamaz.
Tehlikeli (yeniden başlatılamaz) dizileri belirledik (
lw $3, 0x0($2) gibi, ardından
$2'yi değiştiren ve
$3'ye göre veri bağımlı olmayan bir insn) ve GCC'de değişiklikler yaptım, bu nedenle bu diziler oluşmadı (örneğin, son çare olarak , iki insın bir
nop ile ayrılması).
Sadece dikkate alınması gereken bir şey ...
Birisi iyonların bitleri kolayca çevirmesini önlemek için daha yavaş cips kullanmaktan bahsetti. Benzer bir şekilde, belki de aslında tek bir bit depolamak için birden fazla bit kullanan özel bir cpu/ram kullanın. Böylece bir donanım hata toleransı sağlamak, çünkü tüm parçaların çevrilmesinin çok düşük olması muhtemeldir. Öyleyse 1 = 1111 ama gerçekte ters çevirmek için 4 kez vurulmaya ihtiyaç duyuluyor. (2 bit, önceden belirsiz olarak çevrildiyse, 4 hatalı bir sayı olabilir). Bu yüzden, 8 ile giderseniz, 8 kat daha az çarpma ve bazı kesirlere daha yavaş erişim süresi ancak çok daha güvenilir bir veri sunumu elde edersiniz. Muhtemelen bunu hem yazılım düzeyinde hem de özel bir derleyici (her şey için x miktar daha fazla yer ayırın) ya da dil uygulaması (işleri bu şekilde tahsis eden veri yapıları için yazıcılar) kullanarak yapabilirsiniz. Veya aynı mantıksal yapıya sahip, ancak bunu donanım yazılımında yapan özel donanım.
İstediğiniz şey oldukça karmaşık bir konudur - kolayca yanıtlanamaz. Diğer cevaplar tamam, ama yapmanız gereken her şeyin küçük bir kısmını kapsıyorlardı.
Yorumlarda görüldüğü gibi , donanım problemlerini% 100 düzeltmek mümkün olmamakla birlikte, çeşitli teknikler kullanarak bunları azaltmak veya yakalamak muhtemelen mümkün.
Senin yerinde olsam, en yüksek Güvenlik bütünlüğü seviyesi seviyesinin (SIL-4) yazılımını oluştururdum. IEC 61513 belgesini (nükleer endüstri için) edinin ve takip edin.
A döngüsel zamanlayıcı kullanın. Bu, kritik verilerin doğruluğunu kontrol etmek için düzenli bakım süreleri ekleyebilmenizi 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üleri arasındaki yığını yeniden başlatabilirsiniz. Araya girme aramaları için yığınları tekrar kullanmayın, her önemli kesme aramasından ayrı bir yığın oluşturun.
Bekçi köpeği kavramına benzer şekilde son zamanlayıcılar var. Fonksiyon çağırmadan önce bir donanım zamanlayıcı başlatın. Son tarih sayacı kesintiye uğramadan önce işlev geri dönmezse, yığını yeniden yükleyin ve tekrar deneyin. 3/5 denemesinden 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 çalıştırma zamanları kullanmak için bu parçaları ayırın (Özellikle bir kontrol ortamında). Örnek: sinyal toplama, ön kayıt verisi, ana algoritma ve sonuç uygulaması/aktarımı. Bu, bir kısımdaki bir başarısızlığın programın geri kalanında arızalara neden olmayacağı anlamına gelir. Böylece, sinyal alımını tamir ederken, kalan görevler eski veriler üzerinde devam eder.
Her şeyin CRC'ye ihtiyacı var. RAM 'ın dışında yürütürseniz, .text bile CRC'ye ihtiyaç duyar. 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ı yapacak donanıma sahiptir, ancak bunun sorunuzun kapsamı dışında kaldığını tahmin ediyorum. CRC'lerin kontrol edilmesi ayrıca, bir problem çıkmadan önce tek bit hatalarını onarmak için bellekteki ECC kontrol cihazına yönlendirir.
Öncelikle, uygulamanızı başarısızlık etrafında tasarlayın. Normal akış işleminin bir parçası olarak sıfırlanacağını bekleyin (uygulamanıza ve arızanın tipine göre yumuşak veya sert). Bu mükemmel olmak zordur: Bir dereceye kadar işlemellik gerektiren kritik işlemlerin bir Meclis seviyesinde kontrol edilmesi ve ayarlanması gerekebilir, böylece kilit noktadaki bir kesinti, tutarsız harici komutlarla sonuçlanamaz .Hızlı başarısız Herhangi bir kurtarılamaz hafıza bozulması veya kontrol akış sapması algılanır algılanmaz. Mümkünse log arızaları.
İkincisi, mümkünse yolsuzluğu düzeltin ve devam edin. Bu, sabit tabloların (ve eğer varsa program kodunun) sık sık kontrol edilmesi ve sabitlenmesi anlamına gelir; belki de her büyük operasyondan önce veya zamanlanmış bir kesme işleminde ve değişkenleri kendiliğinden düzeltilen yapılarda saklamak (her büyük operasyondan önce veya zamanlanmış bir kesme işleminden önce, 3'ten çoğunluk oyu alır ve tek bir sapma ise doğru olur). Mümkünse düzeltmeleri günlüğe kaydedin.
Üçüncüsü, test hatası. Hafızada bitleri rastgele çeviren bir tekrarlanabilir test ortamı kurun. Bu, yolsuzluk durumlarını çoğaltmanıza ve uygulamanızı buralarda tasarlamanıza yardımcı olur.
Supercat'in yorumları, modern derleyicilerin ve diğer şeylerin eğilimleri göz önüne alındığında, eski günlere dönüp kodun tamamını Meclis'te ve her yerde statik bellek tahsislerinde yazmaya özendiririm. Bu tür bir güvenilirlik için, Meclis'in artık maliyetlerin büyük bir yüzde farkına maruz kalmayacağını düşünüyorum.
İşte çok fazla cevap var ama bu konudaki düşüncelerimi özetlemeye çalışacağım.
Bir şeyler çöküyor veya düzgün çalışmıyorsa, kendi hatalarınızdan kaynaklanabilir - o zaman sorunu tespit ettiğinizde kolayca çözmeniz gerekir. Ancak donanım arızaları olasılığı da vardır - ve genel olarak düzeltilmesi imkansız değilse de bu zor.
Öncelikle sorunlu durumu günlüğe kaydederek (yığın, kayıtlar, işlev çağrıları) - onları bir yere dosyaya kaydederek veya bir şekilde doğrudan ileterek ("oh hayır - çarpıyorum") yakalamayı denemeyi tavsiye ederim.
Böyle bir hata durumundan kurtarma ya yeniden başlatma (yazılım hala hayatta ve tekme yapıyorsa) ya da donanım sıfırlamadır (örneğin, saat bekçisi köpekleri). İlk olandan başlamak daha kolay.
Sorun donanımla ilgiliyse - o zaman günlüğe kaydetme, hangi işlev çağrısı sorununun ortaya çıktığını belirlemenize yardımcı olur ve bu, neyin işe yaramadığını ve nerede çalışmadığını bilmenizi sağlar.
Ayrıca, kod göreceli olarak karmaşıksa - onu "bölmek ve fethetmek" mantıklıdır - yani, sorun olduğundan şüphelendiğiniz bazı işlev çağrılarını kaldırır/devre dışı bırakırsınız - tipik olarak kodun yarısını devre dışı bırakır ve başka bir yarıyı etkinleştirirsiniz - "çalışabilir"/“işe yaramaz” kararını verdikten sonra başka bir kodun yarısına odaklanabilirsiniz. (Problem nerede)
Bir süre sonra sorun oluşursa - o zaman yığın taşmasından şüphelenilebilir - o zaman yığın noktası kayıtlarını izlemek daha iyidir - eğer sürekli büyürlerse.
Ve eğer "merhaba dünya" türünde bir uygulamaya kadar kodunuzu tamamen küçültmeyi başarırsanız - ve hala rastgele başarısız oluyorsa - o zaman donanım sorunları beklenir - ve "donanım yükseltmesi" olması gerekir - yani cpu/ram/... radyasyonu daha iyi tolere edebilecek donanım kombinasyonu.
En önemli şey, makine tamamen durduğunda/sıfırlandığında/işe yaramazsa - muhtemelen önyüklemenin yapması gereken ilk şey - eğer sorunlu bir durum ortaya çıkarsa, eve geri dönmektir.
Ortamınızda ayrıca bir sinyal iletmek ve yanıt almak da mümkün ise - bir tür çevrimiçi uzaktan hata ayıklama ortamı oluşturmayı deneyebilirsiniz, ancak o zaman en azından çalışan bir iletişim ortamına ve çalışma durumunda bazı işlemcilere/bazı koçlara sahip olmalısınız. Ve uzaktan hata ayıklama ile, GDB/gdb saplama tür yaklaşımı veya uygulamanızdan geri almanız için gerekenleri kendi uygulamanız anlamına gelir (örneğin, günlük dosyalarını indirmek, çağrı yığınını indirmek, ram indirmek, yeniden başlatmak)
Gerçekten birçok harika cevap okudum!
İşte benim 2 kuruş: hafızayı kontrol etmek için veya bir yazılım sık sık kayıt karşılaştırması yapmak için bir yazılım yazarak, hafıza/kayıt anormalliğinin istatistiksel bir modelini oluşturmak. Dahası, sorunu deneyebileceğiniz sanal bir makinenin tarzında bir emülatör oluşturun. Sanırım kavşak büyüklüğünü, saat frekansını, satıcıyı, kasayı vb. Değiştirirseniz farklı bir davranış gözlemlersiniz.
Masaüstü PC hafızamız bile belirli bir arıza oranına sahiptir, ancak günlük işleri engellemez.