Доцент-беспилотник из ИТМО

Провели хакатон на Архипелаге 2026 по роевому взаимодействию. Впервые соревнования по программированию дронов обошлись без непосредственного программирования железа, а сосредоточились над решением алгоритмических и оптимизационных задач. Прошло все гладко, есть над чем поработать и может быть увидимся в Сириусе.

Представили некоторую аналитику на конференции в Военмехе. Расширяем границы экспертизы. Спасибо RuDrone за организацию мероприятия.

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

Моё маленькое увлечение, а ему уже больше лет, чем многим нашим спортсменам 😂Ждем всех на наши соревнованиях, оно того стоит! #времялетать #фгдло

🙂В эти выходные прошли мега гонки в ИТМО! По-мимо "классических" 75 и 200 мм были и уникальный 125 класс, и DJ, и конкурсы. Вместе совершенствуемся в проведении соревнований для Вас! Подробнее в канале секции гонок дронов ИТМО в тг и вк

Рассказал как защитить свои денежные средства в программе "Финансовая среда" 🤓

Умеем летать не только на маленьких дронах. Группа из 3-х Геоскан 401. Дальше - больше

Григорий Миронов, Университет ИТМО, сборная ЛО, сборная РФ. Видео не ускоренное.

Гоночка в политехе, вторая квала

https://www.kkinstagram.com/reel/DWRerxMReja/?igsh=MWJiMGFleTRxbDI1MQ==

Можно сказать реклама на дронах :)

🛡 Safety и Security: вечный конфликт двух стандартов 📃 Современные автомобили проектируются по двум ключевым стандартам: ISO 26262 (функциональная безопасность) и ISO/SAE 21434 (кибербезопасность). На бумаге они дополняют друг друга, на практике - постоянно конфликтуют. ➖ Функциональная безопасность требует отключать неисправные компоненты, чтобы избежать аварийных ситуаций. Но с точки зрения кибербезопасности отключение компонента - именно то, чего добивается атакующий, поэтому система должна сохранять работоспособность даже под атакой. ➖ Диагностике нужен глубокий доступ к электронным блокам для выявления проблем, а кибербезопасность требует жёсткого контроля этого доступа, чтобы исключить вмешательство извне. ➖ Функциональная безопасность заинтересована в стабильности и минимизации обновлений, тогда как кибербезопасности нужны оперативные патчи для закрытия уязвимостей. Даже резервирование, повышающее отказоустойчивость, одновременно расширяет поверхность для атаки. Проблема усугубляется тем, что команды часто работают в изоляции, используют разные инструменты, а кибербезопасность воспринимают как дополнение к уже сертифицированной функциональной безопасности. 💡 Анализ рисков HARA и TARA надо делать вместе, требования проектировать едиными — например, "обеспечить безопасное торможение при кибератаке" означает одновременно и отказоустойчивость, и защищённую коммуникацию. Архитектуру закладывать сразу под оба аспекта, тестировать комбинированно: внесение отказов плюс пентесты. ❗️ Безопасный автомобиль без киберзащиты становится опасным при атаке. Защищённый, но небезопасный, угрожает пассажирам сам по себе. Совместная разработка - не компромисс, а единственный рабочий вариант. 🚙 [AutoVisor] - ландшафт автомобильной кибербезопасности

Очень тезисно и понятно, не устаю каждый раз про это рассказывать на публичных сессиях