Oto kilka myśli i pomysłów:
Korzystaj z ROM w bardziej kreatywny sposób.
Przechowuj wszystko, co możesz, w pamięci ROM. Zamiast obliczać rzeczy, przechowuj tabele przeglądowe w pamięci ROM. (Upewnij się, że Twój kompilator wyświetla tabele przeglądowe w sekcji tylko do odczytu! Wydrukuj adresy pamięci w czasie wykonywania, aby to sprawdzić!) Przechowuj tabelę wektorów przerwań w pamięci ROM. Oczywiście, uruchom kilka testów, aby zobaczyć, jak niezawodna jest twoja pamięć ROM w porównaniu do pamięci RAM.
Użyj swojej najlepszej pamięci RAM dla stosu.
Jednostki SEU na stosie są prawdopodobnie najbardziej prawdopodobnym źródłem awarii, ponieważ tam zwykle występują takie rzeczy, jak zmienne indeksowe, zmienne statusu, adresy zwrotne i wskaźniki różnego rodzaju.
Wdrożenie procedur timera tykania i watchdoga.
Możesz uruchomić procedurę „sprawdzania rozsądku” przy każdym tyknięciu zegara, a także procedurę kontrolną do obsługi blokowania systemu. Twój główny kod może również okresowo zwiększać licznik wskazujący postęp, a procedura sprawdzania czystości może zapewnić, że tak się stało.
Zaimplementuj kody korekcji błędów w oprogramowaniu.
Możesz dodać redundancję do swoich danych, aby móc wykryć i / lub poprawić błędy. To wydłuży czas przetwarzania, potencjalnie pozostawiając procesor narażony na promieniowanie przez dłuższy czas, zwiększając w ten sposób ryzyko błędów, więc musisz rozważyć kompromis.
Pamiętaj o pamięci podręcznej.
Sprawdź rozmiary pamięci podręcznej procesora. Dane, do których ostatnio uzyskano dostęp lub które zmodyfikowano, prawdopodobnie znajdą się w pamięci podręcznej. Uważam, że możesz wyłączyć przynajmniej niektóre pamięci podręczne (przy dużym koszcie wydajności); powinieneś spróbować, aby zobaczyć, jak podatne są pamięci podręczne na SEU. Jeśli pamięci podręczne są trudniejsze niż pamięć RAM, możesz regularnie odczytywać i ponownie zapisywać krytyczne dane, aby upewnić się, że pozostają one w pamięci podręcznej i przywracają pamięć RAM z powrotem do linii.
Używaj sprytnie procedur obsługi błędów stron.
Jeśli zaznaczysz stronę pamięci jako nieobecną, procesor spowoduje błąd strony podczas próby uzyskania do niej dostępu. Można utworzyć moduł obsługi błędów strony, który sprawdza niektóre elementy przed obsłużeniem żądania odczytu. (Systemy operacyjne PC używają tego do przezroczystego ładowania stron, które zostały zamienione na dysk).
Używaj języka asemblera do krytycznych rzeczy (które mogą być wszystkim).
Dzięki językowi asemblera wiesz, co jest w rejestrach, a co w pamięci RAM; ty wiesz jakie tabele specjalny RAM CPU korzysta i można projektować rzeczy w okrężny sposób, aby zachować swoje ryzyko w dół.
Służy objdump
do przeglądania wygenerowanego języka asemblera i obliczania ilości kodu, jaką zajmuje każda z procedur.
Jeśli używasz dużego systemu operacyjnego, takiego jak Linux, to prosisz o kłopoty; jest tyle złożoności i tylu rzeczy do zrobienia.
Pamiętaj, że to gra prawdopodobieństwa.
Komentator powiedział
Każda procedura napisana w celu wychwycenia błędów będzie ulegać awarii z tej samej przyczyny.
Chociaż jest to prawda, szanse na błędy w (powiedzmy) 100 bajtach kodu i danych wymaganych do prawidłowego działania procedury sprawdzającej są znacznie mniejsze niż prawdopodobieństwo wystąpienia błędów w innym miejscu. Jeśli twój ROM jest dość niezawodny i prawie cały kod / dane faktycznie znajdują się w ROM, twoje szanse są jeszcze większe.
Użyj nadmiarowego sprzętu.
Użyj 2 lub więcej identycznych konfiguracji sprzętowych z identycznym kodem. Jeśli wyniki różnią się, należy uruchomić reset. Na 3 lub więcej urządzeniach możesz użyć systemu „głosowania”, aby spróbować ustalić, które zostało naruszone.