TGViewer
Channel Public Channel
[FTS] Экварта | Лицом к безопасности

[FTS] Экварта | Лицом к безопасности

@facetosafe

🛡Лицом к безопасности!

🔐 Экварта обеспечивает безопасность критичных систем

🚗 Функциональная безопасность
⚡️ Отказобезопасность
🖥 Кибербезопасность

Мы помогаем проектировать транспортные средства и системы в критичных отраслях промышленности: ✈️🚘🚂⚛️
Subscribers
375
Photos
205
Videos
50
Links
161

Showing posts older than #289 · Back to latest

Older Posts 15 shown
Post #288 459
Почему буквальный консерватизм парализует HARA: границы применимости метода σ × T в ISO 26262

🔍 В процессе анализа опасностей и оценки рисков (HARA) по стандарту ISO 26262-3 инженеры часто сталкиваются с методологической дилеммой при оценке параметра Exposure (E). Особенно остро этот вопрос стоит для систем, работающих «по требованию» (on-demand), таких как подушки безопасности или ABS.

Приложение B.3 стандарта предлагает использовать для таких систем вероятностный подход через формулу σ × T. На бумаге математика выглядит логично, но на практике буквальное и избыточно консервативное применение этой формулы к скрытым отказам заводит процесс в тупик. Почти любая on-demand функция искусственно «раздувается» до уровня ASIL D, что парализует разработку.

В этой статье разберём, почему так происходит, где кроется математическая ошибка и как каталог ситуаций VDA 702 от Немецкой ассоциации автомобильной промышленности предлагает решать эту проблему без потери здравого смысла.

[читать далее]

😃 [FTS] Экварта | Лицом к безопасности
  • 👍 5
  • ❤ 4
Post #287 1.02K
FMEA для микроконтроллеров

🔍 Каждый практик безопасности и/или надежности, независимо от отрасли, сталкивался с инструментом FMEA-анализа.

Казалось бы, всё просто: есть некий компонент (шестерёнка, резистор) с известной или рассчитанной надежностью. У него существуют виды отказов: эмпирические или статистические. И вот уже можно проводить качественную и количественную оценку последствий этих видов отказов снизу вверх.

Звучит достаточно просто, пока не столкнёшься со сложным элементом аппаратуры (СЭА) - микроконтроллером или ПЛИС.
❓ При выполнении FMEA-анализа для СЭА часто возникают вопросы:
▪️Что такое отказ контроллера?
▪️Может ли отказать код?
▪️Нужно ли изучать даташиты (обязательно вместе с эрратошитами)?

На эти темы давно ведутся как публичные, так и кулуарные дискуссии. Отдельным направлениям посвящены научные работы. Но мы предлагаем рассматривать вопрос в практической плоскости, то есть отталкиваться от реальной задачи каждого специалиста по надежности и безопасности: выполнить анализ для некоторого блока, в составе которого находится СЭА.

📚 В Р-4761 для выполнения FMEA выделяют два подхода:
▪️компонентный анализ;
▪️функциональный анализ.

Компонентный анализ применяется для относительно простых изделий с детерминированным поведением в ожидаемых условиях эксплуатации. При этом авторы стандарта отдельно предупреждают, что для СЭА такой подход может быть неприемлем, и рекомендуют использовать функциональный анализ.

⚙️ В чём суть функционального FMEA?
Как следует из названия, рассматриваются функции устройства или блока, которым может являться и СЭА.
Для такого элемента обычно несложно определить функциональность: известно, какие входные сигналы он получает и какие выходные сигналы формирует. Оперировать входами и выходами СЭА (не кодом, а именно его пинами) гораздо понятнее и ближе к физической реализации системы.
Рассматривается каждая ножка микросхемы и проверяется отсутствие единичных причин отказа, способных привести к неприемлемым ситуациям.

⚠️ Но достаточно ли этого?
И здесь мы подходим к главному подводному камню.
Функциональный подход на уровне пинов необходим, но недостаточен, поскольку не учитывает внутреннюю архитектуру СЭА.

Представьте многоядерный процессор, в котором каждое ядро отвечает за свою функцию, например, управление и мониторинг. Формально пины разных ядер не пересекаются, однако их может объединять общая точка отказа:
▫️общий тактовый генератор;
▫️общая память;
▫️общая шина данных;
▫️ошибки в кэше.

💡 И именно здесь появляется ответ на один из самых популярных вопросов конструкторов:
«Можно ли использовать один мощный контроллер вместо двух, если задействовать разные ядра для резервирования?»

Категорически нет.

При проведении FMEA для такого решения вы неизбежно обнаружите общую точку отказа. Её отказ одновременно выведет из строя оба ядра, и резервирование превратится в фикцию.

🛠 Что делать на практике?
Для СЭА в FMEA мы рекомендуем использовать комбинированный подход:
🔻функциональный анализ на уровне пинов и потенциальных общих точек отказа;
🔻учёт внешних воздействий.
Например, как мы упоминали в посте про SEE-эффекты (сбои от радиации), одиночный тяжёлый ион может изменить состояние бита в общей ячейке памяти. В результате отказ проявится сразу на нескольких выходных пинах одновременно.
Это классический пример комбинации отказов, которую нельзя игнорировать.

📌 Итог
При выполнении FMEA для сложной электроники не стоит пытаться спуститься на уровень машинного кода или отдельных транзисторов, в деталях легко утонуть.
Оперируйте функциями и пинами, но обязательно учитывайте возможные общие причины отказов.

И помните: резервирование имеет смысл только тогда, когда резервируемые каналы физически разделены - разные кристаллы, разные цепи питания и разные ресурсы.
Один микроконтроллер - это всегда потенциальная единая точка отказа.

💬 А как вы решаете эту дилемму в своих проектах? Используете ли резервирование на уровне отдельных контроллеров или доверяете многоядерным решениям? Делитесь опытом в комментариях.

😃 [FTS] Экварта | Лицом к безопасности
  • 🔥 5
  • 👍 2
Post #286 402
🇷🇺 С Днём России!

Россия - это не только история и традиции, но и технологии, промышленность, наука и инженерная мысль.

Этот праздник объединяет всех, кто своим трудом, знаниями и ответственностью создаёт настоящее и будущее нашей страны.

Желаем новых достижений, интересных проектов, смелых инженерных решений и уверенности в завтрашнем дне.

😃 [FTS] Экварта | Лицом к безопасности
  • ❤ 7
Post #285 414
Недавно провели обучение по функциональной безопасности для команды компании САЭ (Системы Автономной Энергии) - разработчика и производителя тяговых аккумуляторных батарей и преобразователей для электротранспорта 🔋

Программа обучения разрабатывалась индивидуально под задачи компании, и за сравнительно небольшой период времени нам удалось очень плотно поработать над ключевыми аспектами современной безопасной разработки:

🔹 взаимосвязь ISO 26262 и ASPICE

🔹 риск-ориентированный подход, HARA и основы ISO/SAE 21434

🔹 разработка концепций функциональной и технической безопасности

🔹 процессы разработки ПО и аппаратной части

🔹 подготовка доказательной документации и Safety Case

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

Особенно радуют результаты итогового тестирования: уровень правильных ответов по сравнению со стартовыми показателями вырос почти в 3 раза 📈

Спасибо команде САЭ за вовлечённость, сильные вопросы и интерес к развитию процессов функциональной безопасности в электротранспорте 🤝

😃 [FTS] Экварта | Лицом к безопасности
  • 👍 12
  • ❤ 6
  • 🏆 3
Post #284 423
Мы начинаем подготовку к Третьему Форуму по функциональной безопасности. О дате и месте проведения расскажем совсем скоро.

Наша цель — сделать форум максимально полезным и интересным для профессионального сообщества. Поэтому обращаемся к вам за помощью.

💡 Какие темы, вопросы и проблемы в области функциональной безопасности вам хотелось бы обсудить?

🎤 Каких спикеров вы хотели бы увидеть и какие доклады услышать?

🛠 Какие практические кейсы или направления сегодня вызывают у вас наибольший интерес?

Пишите свои идеи в комментариях. Ваши предложения помогут сформировать программу форума и сделать его действительно полезным для всех участников.

Ставьте 🔥 если ждете Форум так же как и мы.

😃 [FTS] Экварта | Лицом к безопасности
  • 🔥 16
  • 👍 2
  • 👎 2
Post #277 494
✈️ Мы уже обсуждали ТОП-5 самых безопасных самолётов России. Теперь пришло время взглянуть на зарубежную статистику.

Представляем ТОП-6 самых безопасных зарубежных самолётов, составленный на основе данных об авиационных инцидентах с 1980 года по настоящее время.

📊 Кто-то может заметить, что в нашем рейтинге Airbus A380 опережает Airbus A340 по соотношению количества авиационных инцидентов к числу выпущенных самолётов, и решить, что места распределены неверно. Однако это не так.

Дело в том, что количество произведённых воздушных судов у этих моделей существенно различается. Поэтому для более объективной оценки мы сравнивали показатели в сопоставимом масштабе, а не только абсолютные значения.

⚠️ При составлении рейтинга особое внимание мы уделили отношению количества жертв авиационных инцидентов к числу произведённых самолётов, поскольку именно этот показатель позволяет наиболее объективно оценить уровень безопасности каждой модели.

💬 Какой самолёт вы считаете самым безопасным в мире? Поделитесь мнением в комментариях! ✈️

😃 [FTS] Экварта | Лицом к безопасности
Post #275 407
🚗 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] Экварта | Лицом к безопасности
  • 🔥 5
  • 👍 2
Post #274 359
✈️ 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] Экварта | Лицом к безопасности
  • 👍 4
  • ❤ 1
  • ✍ 1
  • 🔥 1
Post #273 374
🚘 Почему Tesla отказалась от технологии, которую многие считают обязательной для автопилота?

Лидар - это своего рода лазерное зрение автомобиля.
Он постоянно сканирует пространство вокруг и строит точную 3D-карту окружающего мира.

Многие инженеры считают лидар обязательным элементом беспилотного транспорта. Фактически страховкой от ошибок камер.

Но Tesla пошла против всей индустрии.

❌ Компания отказалась от лидаров и сделала ставку только на камеры и нейросети.

Идея Илона Маска звучит просто:

человек управляет машиной глазами, значит и автопилоту достаточно “зрения”


Tesla собирает миллиарды километров реальных поездок с автомобилей по всему миру и обучает ИИ распознавать дорожные ситуации так же, как это делает человек.

⚙️ По сути, ставка делается не на датчики, а на интеллект системы.

Но у такого подхода есть и критики.

Камеры можно ослепить:

▪️ярким солнцем,
▪️снегом,
▪️дождем,
▪️грязью,
▪️туманом.

А лидар в таких условиях часто работает стабильнее и точнее.

Поэтому сегодня автопром разделился на два лагеря:

🔹 одни считают, что беспилотнику нужны дополнительные “органы чувств”
🔹 другие уверены, что достаточно камер и ИИ

И, возможно, именно этот спор определит, какими будут автомобили будущего.

❓ А вы в каком лагере?
Надежнее “лазерное зрение” или камер и нейросетей достаточно?

😃 [FTS] Экварта | Лицом к безопасности
  • 🤔 4
Post #272 386
Технологии меняют мир,
но неизменными остаются человеческое мужество, память и цена мирного неба.

С Днём Победы!🎗️
  • ❤ 3
  • 🕊 3
  • 🫡 1
Post #271 426
✈️ Искусственный интеллект в авиации: как его сертифицировать?

📄 В декабре прошлого года Европейское агентство по авиационной безопасности (EASA) опубликовало свою первую регуляторную инициативу, касающуюся использования искусственного интеллекта в авиационной отрасли: NPA 2025-07 (B) — Proposed detailed specifications and associated acceptable means of compliance and guidance material for AI trustworthiness (DS.AI).

Этот важный шаг соответствует стремительному развитию технологий и необходимости обеспечить их безопасность и надежность в рамках существующих нормативных требований.

Документ - часть усилий по адаптации нормативной базы к быстро развивающимся технологиям ИИ, чтобы обеспечить их безопасное применение в будущем.

❗️ Что еще раз убедительно демонстрирует: применение искусственного интеллекта в авиационной индустрии - это не фантазия, а уже наступившая реальность, которую невозможно игнорировать.

📘 Краткое содержание документа NPA 2025-07 (B)

Документ NPA 2025-07 (B) - это предложение по стандартам и руководствам, предназначенным для повышения доверия к системам искусственного интеллекта (ИИ) в авиационной отрасли.
Он содержит подробные технические спецификации, допустимые методы подтверждения соответствия и рекомендации по обеспечению надежности ИИ-систем.

🎯 Основная цель документа: обеспечить безопасность и предсказуемость ИИ, внедряемых в авиацию, через установление общих требований и процедур оценки.

В нем описаны ключевые аспекты проверки, включая:
▪️управление рисками,
▪️тестирование,
▪️прозрачность,
▪️постоянный мониторинг систем во время эксплуатации.

🛡 Обоснование необходимости стандартов для доверия к ИИ
В документе подчеркивается, что развитие технологий ИИ требует выработки единых нормативных требований, способных обеспечить системное подтверждение их безопасности и эффективности.
Особо выделяется, что системы, связанные с критическими для авиационной безопасности компонентами, требуют особых мер контроля и надежности, реализуемых посредством строгих процедур оценки и сертификации.

🧭 Области применения ИИ в авиации
Определены сферы использования ИИ, к которым применимы эти стандарты.
В основном - это системы, важные для авиационной безопасности, такие как:
▪️автоматизированные системы управления полетом,
▪️навигации,
▪️мониторинга.

Также описывается, кто должен соблюдать эти требования:
▪️разработчики,
▪️операторы,
▪️регуляторы.

[читать далее]

😃 [FTS] Экварта | Лицом к безопасности
  • 🔥 3
Post #270 362
🚗 Безопасность vs инновации: что не так с электрическими ручками

🆕 Инновации

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

Электрические выдвижные ручки появились в ответ на потребность в аэродинамике и эстетике, особенно для электромобилей (EV), где каждый показатель сопротивления воздуха влияет на запас хода.

🔑 Их история началась с премиум-моделей. Так, Tesla Model S в 2012 году ввела полностью электрические ручки, выдвигающиеся автоматически при приближении ключа. Это решение снизило коэффициент сопротивления, добавив небольшой запас хода, эффект от которого может быть заметен при интенсивном использовании автомобиля. Однако в реальности, выигрыш составляет менее 1% от пробега.

Аналогично Porsche, Audi и другие премиальные бренды используют выдвижные механизмы без выступов для футуристического вида автомобилей. Получается, что эстетика крутого дизайна не ухудшает аэродинамические характеристики, а позволяет даже немного сэкономить на топливе или зарядке.

Устройство таких ручек относительно простое: моторчик или соленоид в двери реагирует на сигнал от бесключевого доступа, выдвигая захват на 2–5 см. Они интегрированы в кузов, минимизируя накопление грязи и шум ветра на скоростях свыше 100 км/ч.

Популярны в Китае (около 60% EV), в частности на моделях BYD, Zeekr и других.

❗️ Однако эта мода столкнулась с критикой:
исследования Китайского института исследований страхования (CIRI) показывают, что при боковых столкновениях электронные ручки открываются лишь в 67% случаев против 98% для механических.

[читать далее]

😃 [FTS] Экварта | Лицом к безопасности
  • 😱 3
  • 🔥 2
  • ❤ 1
  • 👏 1
Post #269 399
✈️ Вчера обсуждали, как в небе всё строго и регламентировано.

Сегодня наткнулись на видео, где пилоты в эфире… мяукают и гавкают!

Диспетчер: соблюдайте профессионализм
Пилоты: *не соблюдают*
Диспетчер: поэтому вы всё ещё на региональных линиях 😂

Вывод: даже в системе, где всё отточено до идеала,
человеческий фактор остаётся самым непредсказуемым элементом.

#юмор

😃 [FTS] Экварта | Лицом к безопасности
  • 😁 5
  • 🤔 2
Older posts →
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →