🚗 Менеджер по ФБ: формальность или ключевая роль?

Слово "Менеджер" с большой долей сомнений прижилось в нашей стране, а уж тем более в узких кругах разработчиков. Часто за ним видят бумаги, сроки и абстрактные задачи, но не ответственность за результат.

Однако в 2011 году с появлением ISO 26262 ситуация немного изменилась. Вместе со стандартом в практику пришёл менеджмент функциональной безопасности (ФБ), и роль менеджера по ФБ.

❓Так кто же он и почему слово "Менеджер" соседствует с таким серьезным понятием, как безопасность? Давайте разбираться.

Менеджер по ФБ - это роль с чётко определённой зоной ответственности. Она закрепляется за конкретным человеком, но на разных уровнях разработки такие роли могут выполнять разные люди (это нормальная практика, прямо предусмотренная стандартом).

Второй важный момент: менеджер по ФБ не обязан делать всё своими руками. Он не тот человек, который в последний момент садится и доделывает FMEA, пересчитывает ASIL или собирает Safety Case.
Его задача другая - обеспечить, чтобы всё это было сделано. Причём сделано правильными людьми, с нужной компетенцией и в нужный момент.

Как это выглядит на практике?

📋 В начале проекта появляется План обеспечения функциональной безопасности (Safety Plan). Это не просто формальный документ - это основа всей дальнейшей работы: кто, что, когда и как делает. Менеджер по ФБ задаёт эту структуру.

Не успеваешь оглянуться, как начинается HARA. И тут быстро выясняется, что у каждого своё понимание рисков, терминов и подходов. Результаты начинают расходиться, цели безопасности непонятны в формулировках, ASIL искусственно снижен (или завышен). В этот момент нужен тот, кто сведёт всё в единую картину. Это и есть зона ответственности менеджера по ФБ - обеспечить согласованность и утвердить итоговые решения.

☑️ Та же логика работает и для требований безопасности и концепции безопасности. Менеджер по ФБ не обязан писать их сам, но он отвечает за то, чтобы они были корректными, непротиворечивыми и согласованными между собой.

Отдельная классика - изменения. Требования поменялись, архитектура поехала, сроки сдвинулись. Менеджер по ФБ обязан убедиться, что:
• анализ влияния изменения выполнен,
• влияние на безопасность оценено,
• все связанные артефакты обновлены.

🔎 Менеджер по ФБ также организует процесс валидации, анализирует результаты и утверждает обоснование безопасности (Safety Case).
При появлении сообщений о проблемах в процессе эксплуатации, менеджер по ФБ инициирует расследование инцидентов, поиск и устранение корневых причин, чтобы предотвратить подобные инциденты в дальнейшем.

Если попробовать упростить до одной мысли, она будет такой:
Менеджер по ФБ - это тот, кто связывает команды, процессы и требования стандарта в единую систему.

Он не делает всё сам. Но именно он отвечает за то, чтобы всё было сделано правильно, согласованно и вовремя.

А как думаете вы, менеджер по ФБ это формальность или всё-таки действительно ключевой человек, без которого цели безопасности могут остаться только на бумаге?

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

✈️ Язык неба: как самолеты предупреждают об опасности.

Мы уже рассказывали о системах, которые спасают жизни в полете. Например, о TCAS – системе предупреждения столкновения самолётов в воздухе.

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

Практически на всех приборах в кабине пилота предусмотрена разноцветная индикация для упрощения восприятия информации о состоянии систем:

🟢 Зелёные или белые индикаторы - уведомительные, они говорят: «Все в порядке, действия не требуются, время на принятие решения стремится к бесконечности»

🟡 Жёлтые индикаторы - предупредительные: «Командир, есть проблема, у тебя примерно 15-30 секунд на принятие решения»

🔴 Красные индикаторы - Аварийные. Они уже кричат: «Действуй сейчас!!!»

В самолете есть и звуковые сигналы. Именно система TCAS, в прямом смысле говорит пилоту, что делать. В ней существует 2 вида голосовых команд:

⚠️ Предупреждающие – спокойный, но твердый голос говорит: «Traffic, Traffic», что означает, что рядом находится другой самолет и нужно быть готовым к маневру

‼️ Аварийные – система уже не предупреждает, а дает приказы громким голосом. В зависимости от ситуации сигналы звучат по-разному:
«Climb, Climb!» - Набор высоты;
«Descend, Descend!» - Снижение;
«Increase Climb!» - Увеличить вертикальную скорость;
«Monitor vertical speed» - Контролируй вертикальную скорость;

☝️ Важно, аварийные сигналы имеют абсолютный приоритет над указаниями диспетчера.

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

❗️ «Pan-Pan» (Пан-Пан) – Ситуация «На пределе». Слово происходит от французского panne – «поломка». Этим сигналом экипаж сообщает, что возникла проблема, но ситуация остается под контролем. В таком случае борт имеет право на приоритетное обслуживание.
Представьте, что у вас в машине лопнуло колесо на трассе. Вы съехали на обочину, вас не заносит, вы контролируете ситуацию, но ехать дальше нельзя, нужна помощь.

🆘 «Mayday» (Мэйдэй) – Крик о спасении. Из французского venez m’aider – «придите на помощь» – высший приоритет в авиационном пространстве. Сигнал означает, что пассажиры и экипаж находятся в непосредственной и серьезной опасности, требуют немедленной помощи, и время пошло на секунды. После этого сигнала диспетчер автоматически становится координатором всех служб спасения. Чтобы сигнал не спутали с чем-то похожим в плохой слышимости, его повторяют трижды: «Mayday, Mayday, Mayday».

⚡️«Securite» (Секьюрите) – Предупреждение для всех, с французского – «безопасность». Это сообщение для окружающих, например, впереди опасная гроза или выключился маяк на аэродроме. Для передачи важной навигационной информации, влияющей на безопасность полета. Это не просьба о помощи, а предупреждение, чтобы беды не случилось у других. Аналогично морганию дальним светом на трассе))

Любопытный факт: некоторые сигналы в авиации звучат на французском.

Так что, по сути, в критический момент пилоты по всему миру “переходят на французский”.

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

✈️ Вчера обсуждали, как в небе всё строго и регламентировано.

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

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

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

#юмор

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

🚗 Безопасность vs инновации: что не так с электрическими ручками

🆕 Инновации

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

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

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

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

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

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

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

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

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

✈️ Искусственный интеллект в авиации: как его сертифицировать?

📄 В декабре прошлого года Европейское агентство по авиационной безопасности (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] Экварта | Лицом к безопасности

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

С Днём Победы!🎗️

🚘 Почему Tesla отказалась от технологии, которую многие считают обязательной для автопилота?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

✈️ 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] Экварта | Лицом к безопасности

🚗 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] Экварта | Лицом к безопасности

Мы начинаем подготовку к Третьему Форуму по функциональной безопасности. О дате и месте проведения расскажем совсем скоро.

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

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

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

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

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

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

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

Недавно провели обучение по функциональной безопасности для команды компании САЭ (Системы Автономной Энергии) - разработчика и производителя тяговых аккумуляторных батарей и преобразователей для электротранспорта 🔋

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

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

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

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

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

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

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

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

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

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

🇷🇺 С Днём России!

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

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

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

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

FMEA для микроконтроллеров

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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