Вот некоторые мысли и идеи:
Используйте ROM более творчески.
Храните все, что вы можете в ROM. Вместо того, чтобы вычислять вещи, храните таблицы поиска в ПЗУ. (Убедитесь, что ваш компилятор выводит таблицы поиска в раздел только для чтения! Распечатайте адреса памяти во время выполнения, чтобы проверить!) Сохраните таблицу векторов прерываний в ПЗУ. Конечно, запустите несколько тестов, чтобы увидеть, насколько надежна ваша ПЗУ по сравнению с вашей ОЗУ.
Используйте вашу лучшую оперативную память для стека.
SEU в стеке, вероятно, являются наиболее вероятным источником сбоев, потому что именно там обычно живут такие вещи, как индексные переменные, переменные состояния, адреса возврата и указатели различных типов.
Реализуйте процедуры таймера-тика и сторожевого таймера.
Вы можете запускать процедуру проверки работоспособности каждый тик таймера, а также подпрограмму сторожевого таймера для обработки блокировки системы. Ваш основной код также может периодически увеличивать счетчик, чтобы указывать прогресс, и процедура проверки работоспособности может гарантировать, что это произошло.
Реализуйте коды исправления ошибок в программном обеспечении.
Вы можете добавить избыточность к своим данным, чтобы иметь возможность обнаруживать и / или исправлять ошибки. Это добавит время обработки, потенциально оставляя процессор подверженным облучению в течение более длительного времени, увеличивая тем самым вероятность ошибок, поэтому вы должны учитывать компромисс.
Помните тайники.
Проверьте размеры кэшей вашего процессора. Данные, к которым вы недавно обращались или изменяли, вероятно, будут в кеше. Я полагаю, что вы можете отключить по крайней мере некоторые из кэшей (с большой производительностью); Вы должны попробовать это, чтобы увидеть, насколько кеши восприимчивы к SEU. Если кеши более устойчивы, чем ОЗУ, то вы можете регулярно читать и перезаписывать критически важные данные, чтобы убедиться, что они остаются в кеше и вернуть ОЗУ в рабочее состояние.
Умно используйте обработчики ошибок страниц.
Если вы отметите страницу памяти как отсутствующую, ЦП выдаст ошибку страницы при попытке доступа к ней. Вы можете создать обработчик ошибок страницы, который выполняет некоторую проверку перед обслуживанием запроса на чтение. (Операционные системы ПК используют это для прозрачной загрузки страниц, которые были выгружены на диск.)
Используйте язык ассемблера для критических вещей (которые могут быть всем).
С языком ассемблера вы знаете, что находится в регистрах, а что в оперативной памяти; Вы знаете, какие специальные таблицы ОЗУ использует ЦП, и можете разрабатывать обходные пути, чтобы снизить риск.
Используйте, objdumpчтобы реально посмотреть на сгенерированный ассемблер и выяснить, сколько кода занимает каждая ваша подпрограмма.
Если вы используете большую ОС, такую как Linux, вы напрашиваетесь на неприятности; просто так много сложности и так много вещей, которые могут пойти не так.
Помните, что это игра вероятностей.
Комментатор сказал
Каждая подпрограмма, которую вы пишете для обнаружения ошибок, будет сама по себе приводить к отказу по той же причине.
Хотя это действительно так, вероятность ошибок в (скажем) 100 байтах кода и данных, необходимых для правильной работы процедуры проверки, намного меньше, чем вероятность ошибок в других местах. Если ваш ПЗУ достаточно надежен и почти весь код / данные фактически находятся в ПЗУ, ваши шансы еще выше.
Используйте избыточное оборудование.
Используйте 2 или более идентичных аппаратных настроек с идентичным кодом. Если результаты отличаются, необходимо выполнить сброс. С 3 или более устройствами вы можете использовать систему «голосования», чтобы попытаться определить, какое из них было взломано.
