Технологии меняют мир,
но неизменными остаются человеческое мужество, память и цена мирного неба.
С Днём Победы!🎗️
но неизменными остаются человеческое мужество, память и цена мирного неба.
С Днём Победы!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3🕊3🫡1
🚘 Почему Tesla отказалась от технологии, которую многие считают обязательной для автопилота?
Лидар - это своего рода лазерное зрение автомобиля.
Он постоянно сканирует пространство вокруг и строит точную 3D-карту окружающего мира.
Многие инженеры считают лидар обязательным элементом беспилотного транспорта. Фактически страховкой от ошибок камер.
Но Tesla пошла против всей индустрии.
❌ Компания отказалась от лидаров и сделала ставку только на камеры и нейросети.
Идея Илона Маска звучит просто:
Tesla собирает миллиарды километров реальных поездок с автомобилей по всему миру и обучает ИИ распознавать дорожные ситуации так же, как это делает человек.
⚙️ По сути, ставка делается не на датчики, а на интеллект системы.
Но у такого подхода есть и критики.
Камеры можно ослепить:
▪️ярким солнцем,
▪️снегом,
▪️дождем,
▪️грязью,
▪️туманом.
А лидар в таких условиях часто работает стабильнее и точнее.
Поэтому сегодня автопром разделился на два лагеря:
🔹 одни считают, что беспилотнику нужны дополнительные “органы чувств”
🔹 другие уверены, что достаточно камер и ИИ
И, возможно, именно этот спор определит, какими будут автомобили будущего.
❓ А вы в каком лагере?
Надежнее “лазерное зрение” или камер и нейросетей достаточно?
😃 [FTS] Экварта | Лицом к безопасности
Лидар - это своего рода лазерное зрение автомобиля.
Он постоянно сканирует пространство вокруг и строит точную 3D-карту окружающего мира.
Многие инженеры считают лидар обязательным элементом беспилотного транспорта. Фактически страховкой от ошибок камер.
Но Tesla пошла против всей индустрии.
❌ Компания отказалась от лидаров и сделала ставку только на камеры и нейросети.
Идея Илона Маска звучит просто:
человек управляет машиной глазами, значит и автопилоту достаточно “зрения”
Tesla собирает миллиарды километров реальных поездок с автомобилей по всему миру и обучает ИИ распознавать дорожные ситуации так же, как это делает человек.
⚙️ По сути, ставка делается не на датчики, а на интеллект системы.
Но у такого подхода есть и критики.
Камеры можно ослепить:
▪️ярким солнцем,
▪️снегом,
▪️дождем,
▪️грязью,
▪️туманом.
А лидар в таких условиях часто работает стабильнее и точнее.
Поэтому сегодня автопром разделился на два лагеря:
🔹 одни считают, что беспилотнику нужны дополнительные “органы чувств”
🔹 другие уверены, что достаточно камер и ИИ
И, возможно, именно этот спор определит, какими будут автомобили будущего.
❓ А вы в каком лагере?
Надежнее “лазерное зрение” или камер и нейросетей достаточно?
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔4
✈️ NSWC-11: инженерный подход к надёжности.
Без количественной оценки надёжности сложно посчитать деревья отказов и доказать соответствие требованиям FHA.
С электроникой всё относительно понятно: есть справочники надёжности ЭРИ, MIL-HDBK-217 и другие источники.
⚙️ С механикой сложнее: часто используют NPRD, но его данные слабо привязаны к конкретным материалам, геометрии, нагрузкам, режимам работы и среде. Поэтому доказать, что строка BEARING из NPRD действительно соответствует именно моему подшипнику в моей конструкции, почти невозможно.
В качестве более инженерной альтернативы мы хотим поделиться Handbook of Reliability Prediction Procedures for Mechanical Equipment, или NSWC-11.
Иногда его расчёты дают неожиданные результаты и даже приводят к переработке конструкции, зато такой подход гораздо честнее с инженерной точки зрения.
📘 Что такое NSWC-11
Цель NSWC-11 можно сформулировать так: дать инженеру не просто «среднюю по больнице вероятность отказа механического компонента», как часто делают со справочниками NPRD, а способ связать отказ с физикой работы изделия.
Справочник покрывает:
▪️уплотнения и прокладки,
▪️пружины,
▪️соленоиды и контакторы,
▪️клапаны,
▪️подшипники,
▪️шестерни и шлицевые соединения,
▪️актуаторы,
▪️насосы,
▪️фильтры,
▪️муфты,
▪️компрессоры,
▪️резьбовые соединения и многое другое.
Это видно уже по структуре его содержания.
🛠 Главная особенность NSWC-11
Главная особенность NSWC-11 в том, что он требует инженерного понимания изделия.
Формулы в нём обычно имеют вид базовой интенсивности отказов, умноженной на набор корректирующих коэффициентов. Но эти коэффициенты — не магические «поправки на всякий случай».
Они отражают физические причины деградации:
давление увеличивает нагрузку на контакт,
загрязнение ускоряет износ,
плохая шероховатость ухудшает герметичность,
температура влияет на свойства резины,
вязкость жидкости меняет режим смазки,
цикличность влияет на усталость.
📌 Поэтому NSWC-11 особенно полезен тогда, когда у инженера есть реальные параметры изделия:
▪️чертежи,
▪️материалы,
▪️размеры,
▪️режимы работы,
▪️давление,
▪️температура,
▪️частота циклов,
▪️допуски,
▪️данные о среде.
Если этих данных нет, расчёт превращается в набор предположений.
Результат может выглядеть математически точным, но инженерно быть слабым.
[читать далее]
😃 [FTS] Экварта | Лицом к безопасности
Без количественной оценки надёжности сложно посчитать деревья отказов и доказать соответствие требованиям FHA.
С электроникой всё относительно понятно: есть справочники надёжности ЭРИ, MIL-HDBK-217 и другие источники.
⚙️ С механикой сложнее: часто используют NPRD, но его данные слабо привязаны к конкретным материалам, геометрии, нагрузкам, режимам работы и среде. Поэтому доказать, что строка BEARING из NPRD действительно соответствует именно моему подшипнику в моей конструкции, почти невозможно.
В качестве более инженерной альтернативы мы хотим поделиться Handbook of Reliability Prediction Procedures for Mechanical Equipment, или NSWC-11.
Иногда его расчёты дают неожиданные результаты и даже приводят к переработке конструкции, зато такой подход гораздо честнее с инженерной точки зрения.
📘 Что такое NSWC-11
Цель NSWC-11 можно сформулировать так: дать инженеру не просто «среднюю по больнице вероятность отказа механического компонента», как часто делают со справочниками NPRD, а способ связать отказ с физикой работы изделия.
Справочник покрывает:
▪️уплотнения и прокладки,
▪️пружины,
▪️соленоиды и контакторы,
▪️клапаны,
▪️подшипники,
▪️шестерни и шлицевые соединения,
▪️актуаторы,
▪️насосы,
▪️фильтры,
▪️муфты,
▪️компрессоры,
▪️резьбовые соединения и многое другое.
Это видно уже по структуре его содержания.
🛠 Главная особенность NSWC-11
Главная особенность NSWC-11 в том, что он требует инженерного понимания изделия.
Формулы в нём обычно имеют вид базовой интенсивности отказов, умноженной на набор корректирующих коэффициентов. Но эти коэффициенты — не магические «поправки на всякий случай».
Они отражают физические причины деградации:
давление увеличивает нагрузку на контакт,
загрязнение ускоряет износ,
плохая шероховатость ухудшает герметичность,
температура влияет на свойства резины,
вязкость жидкости меняет режим смазки,
цикличность влияет на усталость.
📌 Поэтому NSWC-11 особенно полезен тогда, когда у инженера есть реальные параметры изделия:
▪️чертежи,
▪️материалы,
▪️размеры,
▪️режимы работы,
▪️давление,
▪️температура,
▪️частота циклов,
▪️допуски,
▪️данные о среде.
Если этих данных нет, расчёт превращается в набор предположений.
Результат может выглядеть математически точным, но инженерно быть слабым.
[читать далее]
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤1✍1🔥1
🚗 SEooC: продукт для автомобиля, которого еще нет 🧩
Как обеспечить функциональную безопасность по ISO 26262, если заранее неизвестно, в какой именно автомобиль попадет продукт?
Именно для этого в стандарте существует подход Safety Element out of Context (SEooC) — продукт вне контекста безопасности.
Система, чип или библиотека ПО создаются не под конкретное ТЗ заказчика, а на основе собственных гипотез и допущений.
🎯 Фундамент SEooC - допущения (Assumptions of Use)
Technical Safety Concept (TSC) в случае SEooC начинается не с «железа», а с допущений.
Разработчик обязан предположить:
▪️Assumed Safety Goals: какую цель безопасности на уровне автомобиля помогает достичь продукт.
▪️Assumed FSR: какие Functional Safety Requirements мог бы назначить OEM.
📌 Важно помнить:
ASIL Capability подтверждена только в рамках этих допущений.
Если проект выходит за их границы — это риск, который ложится на плечи интегратора.
📂 Что входит в Safety Manual
Чтобы разработчик устройства смог собрать свой Safety Case, вместе с SEooC-элементом передается Safety Manual — основной документ по интеграции элемента.
Для SEooC-System:
▪️Item Definition assumptions - границы и условия эксплуатации, на которые рассчитывал разработчик;
▪️стратегия Safe State - как элемент переходит в безопасное состояние, если что-то пошло не так.
Для SEooC-HW (например, MCU):
▪️FMEDA - расчет FIT-рейтов, метрик и эффективности диагностических мер;
▪️External Measures - перечень мер, которые должны быть реализованы снаружи, чтобы внутренние механизмы работали корректно.
Например:
внешний супервизор питания.
Для SEooC-SW (стеки, ОС):
▪️SWSR - Требования к софту и интерфейс HSI (Software Safety Requirements);
▪️ресурсный бюджет;
▪️Structural Coverage — доказательства полноты тестирования. Для ASIL D это MC/DC.
⚖️ Меры подтверждения: доверяй, но проверяй
Безопасность SEooC подтверждается не только заявлениями разработчика, но и отдельными отчетами по Confirmation Measures:
▪️Confirmation Reviews — подтверждение того, что TSC и FMEDA не содержат пробелов;
▪️Safety Audit Report — доказательство соответствия процессов разработки ISO 26262;
▪️Safety Assessment Report — итоговое заключение по безопасности.
📌 Для уровня ASIL D обычно привлекаются независимые эксперты уровня I3.
🤝 Нужен ли DIA?
Здесь есть важный нюанс.
Если поставляется готовый продукт из каталога (COTS), DIA обычно не требуется — условия уже описаны в Safety Manual.
Но если элемент дорабатывается совместно с заказчиком в рамках Distributed Development, DIA становится документом, который фиксирует зоны ответственности сторон.
🔍 Главная задача интегратора
При работе с SEooC особое внимание необходимо уделять разделу Assumptions.
Главная задача интегратора — провести Validation of Assumptions.
⚠️ Если допущения поставщика не совпадают с реальными условиями применения системы, Safety Case закрыть не получится.
Как вы считаете, что сложнее всего при интеграции SEooC-компонентов?
😃 [FTS] Экварта | Лицом к безопасности
Как обеспечить функциональную безопасность по ISO 26262, если заранее неизвестно, в какой именно автомобиль попадет продукт?
Именно для этого в стандарте существует подход Safety Element out of Context (SEooC) — продукт вне контекста безопасности.
Система, чип или библиотека ПО создаются не под конкретное ТЗ заказчика, а на основе собственных гипотез и допущений.
🎯 Фундамент SEooC - допущения (Assumptions of Use)
Technical Safety Concept (TSC) в случае SEooC начинается не с «железа», а с допущений.
Разработчик обязан предположить:
▪️Assumed Safety Goals: какую цель безопасности на уровне автомобиля помогает достичь продукт.
▪️Assumed FSR: какие Functional Safety Requirements мог бы назначить OEM.
📌 Важно помнить:
ASIL Capability подтверждена только в рамках этих допущений.
Если проект выходит за их границы — это риск, который ложится на плечи интегратора.
📂 Что входит в Safety Manual
Чтобы разработчик устройства смог собрать свой Safety Case, вместе с SEooC-элементом передается Safety Manual — основной документ по интеграции элемента.
Для SEooC-System:
▪️Item Definition assumptions - границы и условия эксплуатации, на которые рассчитывал разработчик;
▪️стратегия Safe State - как элемент переходит в безопасное состояние, если что-то пошло не так.
Для SEooC-HW (например, MCU):
▪️FMEDA - расчет FIT-рейтов, метрик и эффективности диагностических мер;
▪️External Measures - перечень мер, которые должны быть реализованы снаружи, чтобы внутренние механизмы работали корректно.
Например:
внешний супервизор питания.
Для SEooC-SW (стеки, ОС):
▪️SWSR - Требования к софту и интерфейс HSI (Software Safety Requirements);
▪️ресурсный бюджет;
▪️Structural Coverage — доказательства полноты тестирования. Для ASIL D это MC/DC.
⚖️ Меры подтверждения: доверяй, но проверяй
Безопасность SEooC подтверждается не только заявлениями разработчика, но и отдельными отчетами по Confirmation Measures:
▪️Confirmation Reviews — подтверждение того, что TSC и FMEDA не содержат пробелов;
▪️Safety Audit Report — доказательство соответствия процессов разработки ISO 26262;
▪️Safety Assessment Report — итоговое заключение по безопасности.
📌 Для уровня ASIL D обычно привлекаются независимые эксперты уровня I3.
🤝 Нужен ли DIA?
Здесь есть важный нюанс.
Если поставляется готовый продукт из каталога (COTS), DIA обычно не требуется — условия уже описаны в Safety Manual.
Но если элемент дорабатывается совместно с заказчиком в рамках Distributed Development, DIA становится документом, который фиксирует зоны ответственности сторон.
🔍 Главная задача интегратора
При работе с SEooC особое внимание необходимо уделять разделу Assumptions.
Главная задача интегратора — провести Validation of Assumptions.
⚠️ Если допущения поставщика не совпадают с реальными условиями применения системы, Safety Case закрыть не получится.
Как вы считаете, что сложнее всего при интеграции SEooC-компонентов?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍2
✈️ Мы уже обсуждали ТОП-5 самых безопасных самолётов России. Теперь пришло время взглянуть на зарубежную статистику.
Представляем ТОП-6 самых безопасных зарубежных самолётов, составленный на основе данных об авиационных инцидентах с 1980 года по настоящее время.
📊 Кто-то может заметить, что в нашем рейтинге Airbus A380 опережает Airbus A340 по соотношению количества авиационных инцидентов к числу выпущенных самолётов, и решить, что места распределены неверно. Однако это не так.
Дело в том, что количество произведённых воздушных судов у этих моделей существенно различается. Поэтому для более объективной оценки мы сравнивали показатели в сопоставимом масштабе, а не только абсолютные значения.
⚠️ При составлении рейтинга особое внимание мы уделили отношению количества жертв авиационных инцидентов к числу произведённых самолётов, поскольку именно этот показатель позволяет наиболее объективно оценить уровень безопасности каждой модели.
💬 Какой самолёт вы считаете самым безопасным в мире? Поделитесь мнением в комментариях! ✈️
😃 [FTS] Экварта | Лицом к безопасности
Представляем ТОП-6 самых безопасных зарубежных самолётов, составленный на основе данных об авиационных инцидентах с 1980 года по настоящее время.
📊 Кто-то может заметить, что в нашем рейтинге Airbus A380 опережает Airbus A340 по соотношению количества авиационных инцидентов к числу выпущенных самолётов, и решить, что места распределены неверно. Однако это не так.
Дело в том, что количество произведённых воздушных судов у этих моделей существенно различается. Поэтому для более объективной оценки мы сравнивали показатели в сопоставимом масштабе, а не только абсолютные значения.
⚠️ При составлении рейтинга особое внимание мы уделили отношению количества жертв авиационных инцидентов к числу произведённых самолётов, поскольку именно этот показатель позволяет наиболее объективно оценить уровень безопасности каждой модели.
💬 Какой самолёт вы считаете самым безопасным в мире? Поделитесь мнением в комментариях! ✈️
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Мы начинаем подготовку к Третьему Форуму по функциональной безопасности. О дате и месте проведения расскажем совсем скоро.
Наша цель — сделать форум максимально полезным и интересным для профессионального сообщества. Поэтому обращаемся к вам за помощью.
💡 Какие темы, вопросы и проблемы в области функциональной безопасности вам хотелось бы обсудить?
🎤 Каких спикеров вы хотели бы увидеть и какие доклады услышать?
🛠 Какие практические кейсы или направления сегодня вызывают у вас наибольший интерес?
Пишите свои идеи в комментариях. Ваши предложения помогут сформировать программу форума и сделать его действительно полезным для всех участников.
Ставьте🔥 если ждете Форум так же как и мы.
😃 [FTS] Экварта | Лицом к безопасности
Наша цель — сделать форум максимально полезным и интересным для профессионального сообщества. Поэтому обращаемся к вам за помощью.
💡 Какие темы, вопросы и проблемы в области функциональной безопасности вам хотелось бы обсудить?
🎤 Каких спикеров вы хотели бы увидеть и какие доклады услышать?
🛠 Какие практические кейсы или направления сегодня вызывают у вас наибольший интерес?
Пишите свои идеи в комментариях. Ваши предложения помогут сформировать программу форума и сделать его действительно полезным для всех участников.
Ставьте
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16👍2👎2
Недавно провели обучение по функциональной безопасности для команды компании САЭ (Системы Автономной Энергии) - разработчика и производителя тяговых аккумуляторных батарей и преобразователей для электротранспорта 🔋
Программа обучения разрабатывалась индивидуально под задачи компании, и за сравнительно небольшой период времени нам удалось очень плотно поработать над ключевыми аспектами современной безопасной разработки:
🔹 взаимосвязь ISO 26262 и ASPICE
🔹 риск-ориентированный подход, HARA и основы ISO/SAE 21434
🔹 разработка концепций функциональной и технической безопасности
🔹 процессы разработки ПО и аппаратной части
🔹 подготовка доказательной документации и Safety Case
Обучение включало не только теорию, но и практические задания на примерах, близких к реальным задачам отрасли.
Особенно радуют результаты итогового тестирования: уровень правильных ответов по сравнению со стартовыми показателями вырос почти в 3 раза 📈
Спасибо команде САЭ за вовлечённость, сильные вопросы и интерес к развитию процессов функциональной безопасности в электротранспорте 🤝
😃 [FTS] Экварта | Лицом к безопасности
Программа обучения разрабатывалась индивидуально под задачи компании, и за сравнительно небольшой период времени нам удалось очень плотно поработать над ключевыми аспектами современной безопасной разработки:
🔹 взаимосвязь ISO 26262 и ASPICE
🔹 риск-ориентированный подход, HARA и основы ISO/SAE 21434
🔹 разработка концепций функциональной и технической безопасности
🔹 процессы разработки ПО и аппаратной части
🔹 подготовка доказательной документации и Safety Case
Обучение включало не только теорию, но и практические задания на примерах, близких к реальным задачам отрасли.
Особенно радуют результаты итогового тестирования: уровень правильных ответов по сравнению со стартовыми показателями вырос почти в 3 раза 📈
Спасибо команде САЭ за вовлечённость, сильные вопросы и интерес к развитию процессов функциональной безопасности в электротранспорте 🤝
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤6🏆3
🇷🇺 С Днём России!
Россия - это не только история и традиции, но и технологии, промышленность, наука и инженерная мысль.
Этот праздник объединяет всех, кто своим трудом, знаниями и ответственностью создаёт настоящее и будущее нашей страны.
Желаем новых достижений, интересных проектов, смелых инженерных решений и уверенности в завтрашнем дне.
😃 [FTS] Экварта | Лицом к безопасности
Россия - это не только история и традиции, но и технологии, промышленность, наука и инженерная мысль.
Этот праздник объединяет всех, кто своим трудом, знаниями и ответственностью создаёт настоящее и будущее нашей страны.
Желаем новых достижений, интересных проектов, смелых инженерных решений и уверенности в завтрашнем дне.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7
FMEA для микроконтроллеров
🔍 Каждый практик безопасности и/или надежности, независимо от отрасли, сталкивался с инструментом FMEA-анализа.
Казалось бы, всё просто: есть некий компонент (шестерёнка, резистор) с известной или рассчитанной надежностью. У него существуют виды отказов: эмпирические или статистические. И вот уже можно проводить качественную и количественную оценку последствий этих видов отказов снизу вверх.
Звучит достаточно просто, пока не столкнёшься со сложным элементом аппаратуры (СЭА) - микроконтроллером или ПЛИС.
❓ При выполнении FMEA-анализа для СЭА часто возникают вопросы:
▪️Что такое отказ контроллера?
▪️Может ли отказать код?
▪️Нужно ли изучать даташиты (обязательно вместе с эрратошитами)?
На эти темы давно ведутся как публичные, так и кулуарные дискуссии. Отдельным направлениям посвящены научные работы. Но мы предлагаем рассматривать вопрос в практической плоскости, то есть отталкиваться от реальной задачи каждого специалиста по надежности и безопасности: выполнить анализ для некоторого блока, в составе которого находится СЭА.
📚 В Р-4761 для выполнения FMEA выделяют два подхода:
▪️компонентный анализ;
▪️функциональный анализ.
Компонентный анализ применяется для относительно простых изделий с детерминированным поведением в ожидаемых условиях эксплуатации. При этом авторы стандарта отдельно предупреждают, что для СЭА такой подход может быть неприемлем, и рекомендуют использовать функциональный анализ.
⚙️ В чём суть функционального FMEA?
Как следует из названия, рассматриваются функции устройства или блока, которым может являться и СЭА.
Для такого элемента обычно несложно определить функциональность: известно, какие входные сигналы он получает и какие выходные сигналы формирует. Оперировать входами и выходами СЭА (не кодом, а именно его пинами) гораздо понятнее и ближе к физической реализации системы.
Рассматривается каждая ножка микросхемы и проверяется отсутствие единичных причин отказа, способных привести к неприемлемым ситуациям.
⚠️ Но достаточно ли этого?
И здесь мы подходим к главному подводному камню.
Функциональный подход на уровне пинов необходим, но недостаточен, поскольку не учитывает внутреннюю архитектуру СЭА.
Представьте многоядерный процессор, в котором каждое ядро отвечает за свою функцию, например, управление и мониторинг. Формально пины разных ядер не пересекаются, однако их может объединять общая точка отказа:
▫️общий тактовый генератор;
▫️общая память;
▫️общая шина данных;
▫️ошибки в кэше.
💡 И именно здесь появляется ответ на один из самых популярных вопросов конструкторов:
«Можно ли использовать один мощный контроллер вместо двух, если задействовать разные ядра для резервирования?»
Категорически нет.
При проведении FMEA для такого решения вы неизбежно обнаружите общую точку отказа. Её отказ одновременно выведет из строя оба ядра, и резервирование превратится в фикцию.
🛠 Что делать на практике?
Для СЭА в FMEA мы рекомендуем использовать комбинированный подход:
🔻функциональный анализ на уровне пинов и потенциальных общих точек отказа;
🔻учёт внешних воздействий.
Например, как мы упоминали в посте про SEE-эффекты (сбои от радиации), одиночный тяжёлый ион может изменить состояние бита в общей ячейке памяти. В результате отказ проявится сразу на нескольких выходных пинах одновременно.
Это классический пример комбинации отказов, которую нельзя игнорировать.
📌 Итог
При выполнении FMEA для сложной электроники не стоит пытаться спуститься на уровень машинного кода или отдельных транзисторов, в деталях легко утонуть.
Оперируйте функциями и пинами, но обязательно учитывайте возможные общие причины отказов.
И помните: резервирование имеет смысл только тогда, когда резервируемые каналы физически разделены - разные кристаллы, разные цепи питания и разные ресурсы.
Один микроконтроллер - это всегда потенциальная единая точка отказа.
💬 А как вы решаете эту дилемму в своих проектах? Используете ли резервирование на уровне отдельных контроллеров или доверяете многоядерным решениям? Делитесь опытом в комментариях.
😃 [FTS] Экварта | Лицом к безопасности
🔍 Каждый практик безопасности и/или надежности, независимо от отрасли, сталкивался с инструментом FMEA-анализа.
Казалось бы, всё просто: есть некий компонент (шестерёнка, резистор) с известной или рассчитанной надежностью. У него существуют виды отказов: эмпирические или статистические. И вот уже можно проводить качественную и количественную оценку последствий этих видов отказов снизу вверх.
Звучит достаточно просто, пока не столкнёшься со сложным элементом аппаратуры (СЭА) - микроконтроллером или ПЛИС.
❓ При выполнении FMEA-анализа для СЭА часто возникают вопросы:
▪️Что такое отказ контроллера?
▪️Может ли отказать код?
▪️Нужно ли изучать даташиты (обязательно вместе с эрратошитами)?
На эти темы давно ведутся как публичные, так и кулуарные дискуссии. Отдельным направлениям посвящены научные работы. Но мы предлагаем рассматривать вопрос в практической плоскости, то есть отталкиваться от реальной задачи каждого специалиста по надежности и безопасности: выполнить анализ для некоторого блока, в составе которого находится СЭА.
📚 В Р-4761 для выполнения FMEA выделяют два подхода:
▪️компонентный анализ;
▪️функциональный анализ.
Компонентный анализ применяется для относительно простых изделий с детерминированным поведением в ожидаемых условиях эксплуатации. При этом авторы стандарта отдельно предупреждают, что для СЭА такой подход может быть неприемлем, и рекомендуют использовать функциональный анализ.
⚙️ В чём суть функционального FMEA?
Как следует из названия, рассматриваются функции устройства или блока, которым может являться и СЭА.
Для такого элемента обычно несложно определить функциональность: известно, какие входные сигналы он получает и какие выходные сигналы формирует. Оперировать входами и выходами СЭА (не кодом, а именно его пинами) гораздо понятнее и ближе к физической реализации системы.
Рассматривается каждая ножка микросхемы и проверяется отсутствие единичных причин отказа, способных привести к неприемлемым ситуациям.
⚠️ Но достаточно ли этого?
И здесь мы подходим к главному подводному камню.
Функциональный подход на уровне пинов необходим, но недостаточен, поскольку не учитывает внутреннюю архитектуру СЭА.
Представьте многоядерный процессор, в котором каждое ядро отвечает за свою функцию, например, управление и мониторинг. Формально пины разных ядер не пересекаются, однако их может объединять общая точка отказа:
▫️общий тактовый генератор;
▫️общая память;
▫️общая шина данных;
▫️ошибки в кэше.
💡 И именно здесь появляется ответ на один из самых популярных вопросов конструкторов:
«Можно ли использовать один мощный контроллер вместо двух, если задействовать разные ядра для резервирования?»
Категорически нет.
При проведении FMEA для такого решения вы неизбежно обнаружите общую точку отказа. Её отказ одновременно выведет из строя оба ядра, и резервирование превратится в фикцию.
🛠 Что делать на практике?
Для СЭА в FMEA мы рекомендуем использовать комбинированный подход:
🔻функциональный анализ на уровне пинов и потенциальных общих точек отказа;
🔻учёт внешних воздействий.
Например, как мы упоминали в посте про SEE-эффекты (сбои от радиации), одиночный тяжёлый ион может изменить состояние бита в общей ячейке памяти. В результате отказ проявится сразу на нескольких выходных пинах одновременно.
Это классический пример комбинации отказов, которую нельзя игнорировать.
📌 Итог
При выполнении FMEA для сложной электроники не стоит пытаться спуститься на уровень машинного кода или отдельных транзисторов, в деталях легко утонуть.
Оперируйте функциями и пинами, но обязательно учитывайте возможные общие причины отказов.
И помните: резервирование имеет смысл только тогда, когда резервируемые каналы физически разделены - разные кристаллы, разные цепи питания и разные ресурсы.
Один микроконтроллер - это всегда потенциальная единая точка отказа.
💬 А как вы решаете эту дилемму в своих проектах? Используете ли резервирование на уровне отдельных контроллеров или доверяете многоядерным решениям? Делитесь опытом в комментариях.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍2
Почему буквальный консерватизм парализует HARA: границы применимости метода σ × T в ISO 26262
🔍 В процессе анализа опасностей и оценки рисков (HARA) по стандарту ISO 26262-3 инженеры часто сталкиваются с методологической дилеммой при оценке параметра Exposure (E). Особенно остро этот вопрос стоит для систем, работающих «по требованию» (on-demand), таких как подушки безопасности или ABS.
Приложение B.3 стандарта предлагает использовать для таких систем вероятностный подход через формулу σ × T. На бумаге математика выглядит логично, но на практике буквальное и избыточно консервативное применение этой формулы к скрытым отказам заводит процесс в тупик. Почти любая on-demand функция искусственно «раздувается» до уровня ASIL D, что парализует разработку.
В этой статье разберём, почему так происходит, где кроется математическая ошибка и как каталог ситуаций VDA 702 от Немецкой ассоциации автомобильной промышленности предлагает решать эту проблему без потери здравого смысла.
[читать далее]
😃 [FTS] Экварта | Лицом к безопасности
🔍 В процессе анализа опасностей и оценки рисков (HARA) по стандарту ISO 26262-3 инженеры часто сталкиваются с методологической дилеммой при оценке параметра Exposure (E). Особенно остро этот вопрос стоит для систем, работающих «по требованию» (on-demand), таких как подушки безопасности или ABS.
Приложение B.3 стандарта предлагает использовать для таких систем вероятностный подход через формулу σ × T. На бумаге математика выглядит логично, но на практике буквальное и избыточно консервативное применение этой формулы к скрытым отказам заводит процесс в тупик. Почти любая on-demand функция искусственно «раздувается» до уровня ASIL D, что парализует разработку.
В этой статье разберём, почему так происходит, где кроется математическая ошибка и как каталог ситуаций VDA 702 от Немецкой ассоциации автомобильной промышленности предлагает решать эту проблему без потери здравого смысла.
[читать далее]
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤4
✈️Инженеры намеренно ломают самолеты! И вот почему...
Мы уже писали о, пожалуй, самом необычном испытании самолетов.
Сегодня хотелось бы продолжить эту тему.
🪽 А они не перегибают?
Представьте, что вы длительное время разрабатываете проект, а потом намеренно ломаете его.
Именно так и происходит испытание крыла: новое крыло закреплено в стальной раме, десятки гидравлических упоров тянут его вверх. Инженеры постепенно увеличивают нагрузку, и крыло начинает изгибаться всё сильнее. В какой-то момент оно сгибается почти под прямым углом - зрелище одновременно завораживающее и пугающее.
Зачем это нужно? Чтобы узнать, при какой нагрузке крыло сломается, и убедиться, что эта точка находится далеко за пределами того, что может случиться в реальной эксплуатации.
По сути, инженеры намеренно ломают конструкцию, чтобы доказать, что в небе она выдержит гораздо больше, чем потребуется.
Для создания нагрузки используют либо мешки с песком, уложенные на крыло, либо специальные клеточные конструкции, которые тянут его вверх.
Все не просто так - катастрофы, произошедшие из-за разрушения крыла:
🔻Катастрофа L-188 под Каннелтоном
🔻Катастрофа Gippsland GA8 Airvan под Умео
🌧 Двигатель в луже
Взлет и посадка иногда происходят в условиях сильного ливня. Чтобы проверить, как двигатель поведет себя в таких условиях, самолет разгоняют по специально оборудованной взлетно-посадочной полосе с искусственным водяным слоем.
Цель проста: убедиться, что большие объемы воды не попадают в двигатель и не приводят к его отказу.
Современные двигатели имеют системы слива воды, но при определенных условиях (низкие обороты, большой угол атаки) вода может накапливаться и создавать проблемы.
Это испытание моделирует худший сценарий, когда самолету необходимо взлететь буквально из бассейна, и инженеры должны гарантировать, что двигатели не "захлебнутся".
Катастрофы, произошедшие из-за попадания воды:
🔻Катастрофа Boeing 737 под Джокьякартой
🔻Катастрофа B-2 Spirit в Тихом океане
🛫 На козла?
Минимальная скорость отрыва (Velocity Minimum Unstick) - одно из самых сложных и зрелищных испытаний для пилотов, цель которого - определить минимальную скорость, при которой самолет может безопасно оторваться от земли.
Как это выглядит?
Пилот разгоняет самолет и намеренно цепляет хвостовой частью фюзеляжа взлетно-посадочную полосу, затем осторожно поднимает нос на 10°. Это необходимо, чтобы понять пределы возможностей машины.
Перед таким испытанием экипаж проходит дополнительный инструктаж, потому что ощущения от цепляния хвостом земли на скорости - не из приятных.
Но именно эти данные потом попадают в руководство по эксплуатации и помогают пилотам безопасно взлетать с коротких ВПП.
Катастрофа, произошедшая из-за недостаточной скорости отрыва от земли:
🔻Авиакатастрофа в Мюнхене 6 февраля 1958 года
🔥 Торможение на износ
Представим, что самолет разогнался до взлетной скорости, но что-то пошло не так, и нужно экстренно тормозить.
Чтобы проверить, выдержат ли тормоза, самолет загружают до максимального посадочного веса, устанавливают изношенные тормозные колодки и разгоняют до взлетной скорости. После этого выполняется экстренное торможение до полной остановки, в результате чего колеса нагреваются до очень высоких температур.
Аварийные службы ждут некоторое время, чтобы проверить, не распространится ли огонь на конструкцию самолета.
Это испытание моделирует худший сценарий - прерванный взлет при максимальной кинетической энергии.
Кстати, в отличие от автомобильной промышленности, краш-тесты пассажирских самолетов практически не проводятся. Единственный сертификационный краш-тест был проведен в декабре 1984 года на базе ВВС Эдвардс по заказу FAA, но объектом было не само судно, а топливо в баках.
Катастрофа, одной из причин которой стали изношенные шины:
🔻Катастрофа DC-8 в Джидде
🔧 Что происходит после того, как самолет начал летать
Даже после получения сертификата и начала коммерческой эксплуатации испытания не заканчиваются.
Техники регулярно демонтируют двигатели, очищают их, инспектируют, заменяют изношенные детали, собирают, тестируют и возвращают на борт.
Перед каждым полетом командир или второй пилот проводит визуальный осмотр критических компонентов: датчиков, приемников воздушного давления, структурных элементов, двигателей.
Это многоуровневая система безопасности - от сертификационных испытаний до ежедневных предполетных проверок.
📌 Вывод
Испытания - не просто формальность для получения сертификата.
Каждый этап моделирует реальные ситуации - от столкновения с птицами до торможения на максимальной энергии. За каждым "забавным" испытанием стоят годы инженерной работы и тысячи часов испытаний.
Следующий раз, когда сядете в самолет, вспомните: эта машина прошла через изгиб крыла почти на 90 градусов, обстрел птицами, взлет через лужу и экстренное торможение на максимальной скорости.
И только после этого ей доверили перевозить вас.
Мы уже писали о, пожалуй, самом необычном испытании самолетов.
Сегодня хотелось бы продолжить эту тему.
🪽 А они не перегибают?
Представьте, что вы длительное время разрабатываете проект, а потом намеренно ломаете его.
Именно так и происходит испытание крыла: новое крыло закреплено в стальной раме, десятки гидравлических упоров тянут его вверх. Инженеры постепенно увеличивают нагрузку, и крыло начинает изгибаться всё сильнее. В какой-то момент оно сгибается почти под прямым углом - зрелище одновременно завораживающее и пугающее.
Зачем это нужно? Чтобы узнать, при какой нагрузке крыло сломается, и убедиться, что эта точка находится далеко за пределами того, что может случиться в реальной эксплуатации.
По сути, инженеры намеренно ломают конструкцию, чтобы доказать, что в небе она выдержит гораздо больше, чем потребуется.
Для создания нагрузки используют либо мешки с песком, уложенные на крыло, либо специальные клеточные конструкции, которые тянут его вверх.
Все не просто так - катастрофы, произошедшие из-за разрушения крыла:
🔻Катастрофа L-188 под Каннелтоном
🔻Катастрофа Gippsland GA8 Airvan под Умео
🌧 Двигатель в луже
Взлет и посадка иногда происходят в условиях сильного ливня. Чтобы проверить, как двигатель поведет себя в таких условиях, самолет разгоняют по специально оборудованной взлетно-посадочной полосе с искусственным водяным слоем.
Цель проста: убедиться, что большие объемы воды не попадают в двигатель и не приводят к его отказу.
Современные двигатели имеют системы слива воды, но при определенных условиях (низкие обороты, большой угол атаки) вода может накапливаться и создавать проблемы.
Это испытание моделирует худший сценарий, когда самолету необходимо взлететь буквально из бассейна, и инженеры должны гарантировать, что двигатели не "захлебнутся".
Катастрофы, произошедшие из-за попадания воды:
🔻Катастрофа Boeing 737 под Джокьякартой
🔻Катастрофа B-2 Spirit в Тихом океане
🛫 На козла?
Минимальная скорость отрыва (Velocity Minimum Unstick) - одно из самых сложных и зрелищных испытаний для пилотов, цель которого - определить минимальную скорость, при которой самолет может безопасно оторваться от земли.
Как это выглядит?
Пилот разгоняет самолет и намеренно цепляет хвостовой частью фюзеляжа взлетно-посадочную полосу, затем осторожно поднимает нос на 10°. Это необходимо, чтобы понять пределы возможностей машины.
Перед таким испытанием экипаж проходит дополнительный инструктаж, потому что ощущения от цепляния хвостом земли на скорости - не из приятных.
Но именно эти данные потом попадают в руководство по эксплуатации и помогают пилотам безопасно взлетать с коротких ВПП.
Катастрофа, произошедшая из-за недостаточной скорости отрыва от земли:
🔻Авиакатастрофа в Мюнхене 6 февраля 1958 года
🔥 Торможение на износ
Представим, что самолет разогнался до взлетной скорости, но что-то пошло не так, и нужно экстренно тормозить.
Чтобы проверить, выдержат ли тормоза, самолет загружают до максимального посадочного веса, устанавливают изношенные тормозные колодки и разгоняют до взлетной скорости. После этого выполняется экстренное торможение до полной остановки, в результате чего колеса нагреваются до очень высоких температур.
Аварийные службы ждут некоторое время, чтобы проверить, не распространится ли огонь на конструкцию самолета.
Это испытание моделирует худший сценарий - прерванный взлет при максимальной кинетической энергии.
Кстати, в отличие от автомобильной промышленности, краш-тесты пассажирских самолетов практически не проводятся. Единственный сертификационный краш-тест был проведен в декабре 1984 года на базе ВВС Эдвардс по заказу FAA, но объектом было не само судно, а топливо в баках.
Катастрофа, одной из причин которой стали изношенные шины:
🔻Катастрофа DC-8 в Джидде
🔧 Что происходит после того, как самолет начал летать
Даже после получения сертификата и начала коммерческой эксплуатации испытания не заканчиваются.
Техники регулярно демонтируют двигатели, очищают их, инспектируют, заменяют изношенные детали, собирают, тестируют и возвращают на борт.
Перед каждым полетом командир или второй пилот проводит визуальный осмотр критических компонентов: датчиков, приемников воздушного давления, структурных элементов, двигателей.
Это многоуровневая система безопасности - от сертификационных испытаний до ежедневных предполетных проверок.
📌 Вывод
Испытания - не просто формальность для получения сертификата.
Каждый этап моделирует реальные ситуации - от столкновения с птицами до торможения на максимальной энергии. За каждым "забавным" испытанием стоят годы инженерной работы и тысячи часов испытаний.
Следующий раз, когда сядете в самолет, вспомните: эта машина прошла через изгиб крыла почти на 90 градусов, обстрел птицами, взлет через лужу и экстренное торможение на максимальной скорости.
И только после этого ей доверили перевозить вас.
🔥5
📚 Нашли для вас кое-что интересное
Если вы уже используете STPA (System-Theoretic Process Analysis) или только начинаете знакомиться с этим методом, рекомендуем обратить внимание на SAE J3187.
Этот документ посвящен практическому применению STPA в автомобильной отрасли и во многом опирается на STPA Handbook, адаптируя его подходы для инженерной практики.
📖 А если хочется глубже разобраться в самом методе, рекомендуем начать именно с STPA Handbook. В нем подробно рассмотрены как теоретические основы, так и практические примеры применения метода.
В руководстве рассмотрены:
- определение опасностей (Hazards) и потерь (Losses);
- построение структур управления (Control Structures);
- анализ небезопасных управляющих действий (Unsafe Control Actions, UCA);
- разработка причинных сценариев (Causal Scenarios).
🚗 Особую ценность представляют примеры для автомобильной отрасли:
- адаптивный круиз-контроль (ACC);
- система Auto-Hold;
- автоматизированные транспортные средства (AGV).
Также руководство показывает, как учитывать:
- человеческий фактор;
- ошибки программного обеспечения;
- взаимодействие компонентов без физических отказов;
- интеграцию анализа безопасности с кибербезопасностью.
💡 Почему это может быть полезно инженерам по функциональной безопасности?
STPA позволяет анализировать не только отказы отдельных компонентов, но и опасные взаимодействия внутри системы. Метод можно применять уже на этапе разработки концепции, что помогает сформировать требования безопасности до выбора окончательной архитектуры и снизить стоимость последующих изменений.
📎 STPA Handbook прикрепили в первом комментарии. Он распространяется бесплатно и станет отличной отправной точкой для изучения метода. SAE J3187 является более новой отраслевой рекомендацией, развивающей и адаптирующей подходы, изложенные в руководстве.
💬 А вы уже использовали STPA в своих проектах? Делитесь опытом в комментариях.
Если вы уже используете STPA (System-Theoretic Process Analysis) или только начинаете знакомиться с этим методом, рекомендуем обратить внимание на SAE J3187.
Этот документ посвящен практическому применению STPA в автомобильной отрасли и во многом опирается на STPA Handbook, адаптируя его подходы для инженерной практики.
📖 А если хочется глубже разобраться в самом методе, рекомендуем начать именно с STPA Handbook. В нем подробно рассмотрены как теоретические основы, так и практические примеры применения метода.
В руководстве рассмотрены:
- определение опасностей (Hazards) и потерь (Losses);
- построение структур управления (Control Structures);
- анализ небезопасных управляющих действий (Unsafe Control Actions, UCA);
- разработка причинных сценариев (Causal Scenarios).
🚗 Особую ценность представляют примеры для автомобильной отрасли:
- адаптивный круиз-контроль (ACC);
- система Auto-Hold;
- автоматизированные транспортные средства (AGV).
Также руководство показывает, как учитывать:
- человеческий фактор;
- ошибки программного обеспечения;
- взаимодействие компонентов без физических отказов;
- интеграцию анализа безопасности с кибербезопасностью.
💡 Почему это может быть полезно инженерам по функциональной безопасности?
STPA позволяет анализировать не только отказы отдельных компонентов, но и опасные взаимодействия внутри системы. Метод можно применять уже на этапе разработки концепции, что помогает сформировать требования безопасности до выбора окончательной архитектуры и снизить стоимость последующих изменений.
📎 STPA Handbook прикрепили в первом комментарии. Он распространяется бесплатно и станет отличной отправной точкой для изучения метода. SAE J3187 является более новой отраслевой рекомендацией, развивающей и адаптирующей подходы, изложенные в руководстве.
💬 А вы уже использовали STPA в своих проектах? Делитесь опытом в комментариях.
👍2🔥2