FMEA для микроконтроллеров🔍 Каждый практик безопасности и/или надежности, независимо от отрасли, сталкивался с инструментом
FMEA-анализа.
Казалось бы, всё просто: есть некий компонент (шестерёнка, резистор) с известной или рассчитанной надежностью. У него существуют виды отказов: эмпирические или статистические. И вот уже можно проводить качественную и количественную оценку последствий этих видов отказов снизу вверх.
Звучит достаточно просто, пока не столкнёшься со
сложным элементом аппаратуры (СЭА) - микроконтроллером или ПЛИС.
❓ При выполнении FMEA-анализа для СЭА часто возникают вопросы:
▪️Что такое отказ контроллера?
▪️Может ли отказать код?
▪️Нужно ли изучать даташиты (обязательно вместе с эрратошитами)?
На эти темы давно ведутся как публичные, так и кулуарные дискуссии. Отдельным направлениям посвящены научные работы. Но мы предлагаем рассматривать вопрос в практической плоскости, то есть отталкиваться от реальной задачи каждого специалиста по надежности и безопасности: выполнить анализ для некоторого блока, в составе которого находится СЭА.
📚 В
Р-4761 для выполнения FMEA выделяют два подхода:
▪️компонентный анализ;
▪️функциональный анализ.
Компонентный анализ применяется для относительно простых изделий с детерминированным поведением в ожидаемых условиях эксплуатации. При этом авторы стандарта отдельно предупреждают, что для СЭА такой подход может быть неприемлем, и рекомендуют использовать
функциональный анализ.
⚙️ В чём суть функционального FMEA?
Как следует из названия, рассматриваются функции устройства или блока, которым может являться и СЭА.
Для такого элемента обычно несложно определить функциональность: известно, какие входные сигналы он получает и какие выходные сигналы формирует. Оперировать входами и выходами СЭА (не кодом, а именно его пинами) гораздо понятнее и ближе к физической реализации системы.
Рассматривается каждая ножка микросхемы и проверяется отсутствие единичных причин отказа, способных привести к неприемлемым ситуациям.
⚠️ Но достаточно ли этого?
И здесь мы подходим к главному подводному камню.
Функциональный подход на уровне пинов
необходим, но недостаточен, поскольку не учитывает внутреннюю архитектуру СЭА.
Представьте многоядерный процессор, в котором каждое ядро отвечает за свою функцию, например, управление и мониторинг. Формально пины разных ядер не пересекаются, однако их может объединять общая точка отказа:
▫️общий тактовый генератор;
▫️общая память;
▫️общая шина данных;
▫️ошибки в кэше.
💡 И именно здесь появляется ответ на один из самых популярных вопросов конструкторов:
«Можно ли использовать один мощный контроллер вместо двух, если задействовать разные ядра для резервирования?»Категорически нет.
При проведении FMEA для такого решения вы неизбежно обнаружите общую точку отказа. Её отказ одновременно выведет из строя оба ядра, и резервирование превратится в фикцию.
🛠 Что делать на практике?
Для СЭА в FMEA мы рекомендуем использовать
комбинированный подход:
🔻функциональный анализ на уровне пинов и потенциальных общих точек отказа;
🔻учёт внешних воздействий.
Например, как мы упоминали в
посте про SEE-эффекты (сбои от радиации), одиночный тяжёлый ион может изменить состояние бита в общей ячейке памяти. В результате отказ проявится сразу на нескольких выходных пинах одновременно.
Это классический пример комбинации отказов, которую нельзя игнорировать.
📌
ИтогПри выполнении FMEA для сложной электроники не стоит пытаться спуститься на уровень машинного кода или отдельных транзисторов, в деталях легко утонуть.
Оперируйте функциями и пинами, но обязательно учитывайте возможные общие причины отказов.
И помните:
резервирование имеет смысл только тогда, когда резервируемые каналы физически разделены - разные кристаллы, разные цепи питания и разные ресурсы.Один микроконтроллер - это всегда потенциальная единая точка отказа.
💬
А как вы решаете эту дилемму в своих проектах? Используете ли резервирование на уровне отдельных контроллеров или доверяете многоядерным решениям? Делитесь опытом в комментариях.😃
[FTS] Экварта | Лицом к безопасности