🚘 Что может сделать российские автомобили безопаснее? Функциональная безопасность!

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

В новом интервью с техническим директором инженерной компании «Экварта» Палаевым Алексеем Юрьевичем, разбираемся может ли функциональная безопасность реально повысить уровень безопасности российского автотранспорта — или это пока остаётся «бумажной» историей.

В разговоре обсуждаем:

❓откуда появилась функциональная безопасность и зачем она нужна

❓насколько она реально внедрена в России сегодня

❓почему многие производители до сих пор её избегают

❓как бороться с дефицитом специалистов

❓может ли обязательная сертификация повлиять на безопасность автомобилей

Без лозунгов и упрощений - спокойно, по-инженерному и по делу.

📺 [смотреть на Youtube]

📺 [смотреть на VK видео]

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

🚗 Семь раз отмерь, один раз ответь - почему без количественного анализа безопасность остаётся на словах?

Количественный анализ аппаратных средств — обязательный элемент функциональной безопасности для изделий с уровнями ASIL (B), C и D по ISO 26262. Его часто воспринимают как сложную и трудоёмкую часть стандарта, необходимую лишь «для галочки» и прохождения аудита.

Но именно количественный анализ позволяет подтвердить выбор безопасной аппаратуры. В отличие от качественных методов, он позволяет не просто перечислить возможные отказы, а оценить их вероятность и вклад в нарушение целей безопасности — и на основе цифр принимать инженерные решения.

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

❓В каких случаях без него не обойтись 

На практике количественный анализ используется в нескольких ключевых ситуациях:

1️⃣ Оценка архитектурных метрик аппаратуры (Clause 8, ISO 26262-5)
Применяется для оценки эффективности архитектуры с точки зрения обнаружения и контроля случайных аппаратных сбоев.

2️⃣ Оценка нарушений целей безопасности из-за случайных сбоев (Clause 9, ISO 26262-5)
Необходима для подтверждения того, что остаточный риск нарушения целей безопасности находится на допустимом уровне.

3️⃣ Разработка сложных микросхем и полупроводников
Количественный анализ дополняет качественный и используется для доказательства того, что дизайн полупроводникового компонента соответствует целевым значениям метрик.

4️⃣ Анализ по методу EEC (Evaluation of Each Cause)
Метод основан на индивидуальной оценке каждой части оборудования и ее вклада в нарушение цели безопасности. Часто реализуется в виде количественной FMEA-таблицы.

❓Зачем тратить время на расчёты

Главная цель количественного анализа — предсказать частоту отказов, а не просто перечислить их. Это принципиально отличает его от качественных методов, которые ограничиваются идентификацией видов отказов.

На практике он позволяет:

▪️сравнивать различные варианты архитектур между собой — метрики быстро показывают, какое решение действительно безопаснее;

▪️оценивать диагностическое покрытие — насколько хорошо механизмы безопасности справляются с одиночными, остаточными и скрытыми сбоями;

▪️обосновывать дизайн — находить доказательство того, что проект соответствует целям безопасности с учетом интенсивности отказов компонентов.

▪️находить слабые места — расчёт помогает определить «топ-вкладчиков» в общую интенсивность опасных отказов для их дальнейшей доработки.

❓Что в итоге должно получится

Результатом количественного анализа являются конкретные, проверяемые показатели:

▪️SPFM (Single-Point Fault Metric) — метрика одиночных точек отказа, подтверждающая устойчивость архитектуры к одиночным и остаточным сбоям.

▪️LFM (Latent-Fault Metric) — метрика скрытых отказов, подтверждающая, что механизмы контроля скрытых дефектов (например, самотестирование при включении) работают эффективно.

▪️PMHF (Probabilistic Metric for random Hardware Failures) — средняя вероятность нарушения цели безопасности в час на протяжении срока эксплуатации.

▪️Приемлемость каждого опасного отказа — подтверждается, что для каждой причины нарушения цели безопасности приняты адекватные меры (например, использование консервативных данных или специальных методов контроля)

Количественный анализ — это не формальная «галочка» для соответствия ISO 26262, а инструмент поиска безопасных решений. Он позволяет перейти от общих рассуждений о безопасности аппаратуры к численно обоснованному дизайну, понять реальные риски архитектуры и целенаправленно снижать их еще на этапе разработки.

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

🎥 Если ещё не успели посмотреть интервью с техническим директором инженерной компании «Экварта» Палаевым Алексеем Юрьевичем, обязательно уделите ему внимание на выходных!

Где смотреть?

📺 [смотреть на Youtube]

📺 [смотреть на VK видео]

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

✈️ Турбулентность в комментариях

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

Хотим еще раз подчеркнуть: рейтинг субъективный и построен на данных из открытых источников. Это не окончательная истина, а повод для разговора, и судя по комментариям, разговор получился.

В обсуждении прозвучало несколько сильных идей:

▪️безопасность корректнее считать по налёту, а не по количеству бортов и инцидентов
▪️открытые данные по авиации всегда ограничены
▪️некоторые самолёты требуют отдельного, более глубокого анализа
▪️самые безопасные самолеты, которые не летают😂
▪️и даже прислали учебник «Безопасность полетов гражданских воздушных судов».

И это как раз то, ради чего мы делаем такие посты! Чтобы обсуждать, спорить и смотреть на безопасность с разных сторон.
Мы видим интерес. Значит, продолжим.

Напишите в комментариях: какие ещё рейтинги или сравнения вам было бы интересно увидеть? Какие критерии учесть?

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

✈️🤖 Посетили NAIS и DroneTech, и вот что увидели

4-5 февраля в Крокус Экспо прошли сразу две крупные отраслевые выставки: Национальный авиационный инфраструктурный салон NAIS 2026 и специализированная экспозиция DroneTech по беспилотным, автономным и робототехническим комплексам.

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

Были представлены передовые решения:

🔹отечественные двигатели и авиационная техника;

🔹 уникальные системы связи и навигации, такие как GEOKOSMOS, которые работают даже без GPS;

🔹 высокотехнологические разработки от компаний вроде Алмаз-Антея для обеспечения как пилотируемых, так и беспилотных полётов.

🛸 DroneTech стал отдельной площадкой в рамках NAIS, где производители беспилотных авиационных систем показывали:

▪️гражданские дроны для сельского хозяйства и логистики;

▪️ робото-автономные платформы и решения для промышленного применения;

▪️ навигационные комплексы и средства интеграции в воздушное пространство.

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

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

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

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

🛫 С Днём гражданской авиации!

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

😃 Команда инженерной компании «Экварта» хорошо знает, что основа безопасного полёта - это надёжность каждой детали, каждого расчёта, каждого решения. Мы рады вносить свой вклад в это важное дело.

Желаем всегда точных расчётов и новых высот как в работе, так и в жизни! Здоровья, благополучия и новых горизонтов!

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

🤖 Инсайт по разработке требований (в частности — к ПО)

При разработке требований к ПО широко применяются неформальные нотации на основе естественного языка.

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

Типичный пример – установка одного и того же флага при обнаружении разных ошибок.

🔲 Принцип LEGO-конструктора для требований

Для неформальных нотаций часто используется подход EARS (Easy Approach to Requirements Syntax). Но его можно немного усилить, применив принцип LEGO-конструктора. Идея простая: заранее определить набор «многоразовых кубиков», из которых потом собираются полноценные требования.

Такие кубики — это типовые элементы:

▪️условия требования;
▪️обязательное выполняемое действие;
▪️временные и иные ограничения;
▪️состояния программного обеспечения;
▪️объект или субъект требования;
▪️а также другие типовые элементы требований.

Использование подобных кубиков позволяет формировать требования с единообразной и предсказуемой структурой и упрощает их восприятие и анализ. Например, требования могут быть сформулированы так:

→  «В состоянии S1, при возникновении условия C1, субъект K должен выполнить действие A1 за время t1»;

→  «В состоянии S1, при возникновении условия C2, субъект K должен выполнить действие A2 за время t2».

Что это дает на практике?

1️⃣Проще писать требования: инженер сосредотачивается на формировании базовых элементов, а затем собирает из них законченные смысловые требования.

2️⃣Легко вносить изменения: если нужно скорректировать одинаковое условие для группы требований — меняем один «кубик», и изменения распространяются на все связанные требования.

3️⃣Больше однозначности:  За счет заданных правил построения и единообразия структуры естественный язык становится ближе к полуформальным нотациям, что снижает риск неоднозначной интерпретации.

🔩Про инструменты

Концепция модульного построения требований уже поддерживается специализированными инструментами. 

Например, ANSYS Medini Analyze удобен тем, что позволяет выстраивать трассируемые связи между требованиями разных уровней, результатами анализов безопасности и архитектурными элементами системы, описанными в нотации SysML.

Дополнительное преимущество — возможность адаптации инструмента под конкретные задачи проекта за счет встроенного API, пользовательских скриптов на JavaScript, а также расширения функциональности через разработку собственных плагинов на Java в рамках платформы Eclipse.

Например, такие скрипты могут использоваться для автоматического формирования типовых шаблонов требований, проверки их структуры или массового обновления повторно используемых элементов. Это позволяет сократить объем ручной работы и обеспечить единообразие и воспроизводимость требований в рамках проекта.

Примечание: приведенные примеры требований носят иллюстративный характер и не претендуют на роль эталонных формулировок.

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

💻 Safeware: ТОП-5 главных рисков ПО

Программисты на месте? Пристегнитесь, мы взлетаем!
Наверняка, каждому представителю технической специальности доводилось хотя бы раз в жизни писать код: при выполнении лабораторных и курсовых работ в вузе, на стажировке или реальном проекте. Менеджеры и управленцы, не пропускайте этот пост, наверняка у вас тоже бывали ошибки, о которых пойдет речь.

Как часто при написании программ вы прописываете проверочные условия, которые обеспечивают безопасную и корректную работу программы? Многие думают: «Да что может пойти не так? Я же лично входные данные задаю». Но что делать если что-то произойдет с бортовым ПО прямо во время полета? Задумывались ли Вы, почему нельзя писать ПО для авиационных систем так же, как мобильного приложения? Давайте рассмотрим топ-5 проблем бортового ПО, а в помощь нам КТ-178С
и Misra C.

1️⃣Неопределенное поведение

В C/C++ есть конструкции, поведение которых не определено стандартом. Например, переполнение знакового целого.
Компилятор может:
проигнорировать ситуацию,
применить правила «дополнительного кода»
инвертировать значение

Как регулируется:

→ MISRA C, Rule 1.3, 17.3  — запрет неопределенного и критического незаданного поведения, функции не должны задаваться неявно.

→ КТ-178С, п. 6.1 —  процесс верификации направлен на выявление ошибок, внесенных на этапах разработки.

→ Обязательное тестирование граничных и «выходящих за рамки» значений.

2️⃣ Бесконтрольная рекурсия

Рекурсия (понимаем вызов функции саму себя) без ограничения глубины вызовов может переполнить стек и вызвать отказ системы управления в полете.

Пример: Ваш ребенок хочет пойти погулять, отпрашивается у мамы, но происходит следующая картина.
Мама: «спроси у папы»
Папа: «спроси у мамы»
Мама: «спроси у папы»

Как регулируется:

→ MISRA C, Rule 17.2 — функции не должны вызывать сами себя, прямо или косвенно.

→ КТ-178С, п. 11.7.e — должны быть учтены ограничения на проект, например, исключение рекурсии, динамических объектов, альтернативных имен данных и компактных выражений.


3️⃣ «Мертвый» и посторонний код

Такой код не покрывается тестами, усложняет верификацию и может содержать скрытые уязвимости.

Пример: вы подготовили универсальное резюме, чтобы отправлять его в разные компании, но забыли его проверить перед отправкой и теперь вы 18-летний Senior-разработчик с 30-летним опытом работы в IT.

Как регулируется:

→ КТ-178С, п. 5.2.4, 6.4.4.3.c и 6.4.4.3.d — мертвый и посторонний код должен быть строго обоснован или удален.

→ MISRA C, Rule 2.1-2.7  — динамическое выделение памяти запрещено, чтобы избежать «непредсказуемого» поведения.

4️⃣ Недостаточная изоляция компонентов

В авионике сбой в одном модуле не должен влиять на другие — например, отказ навигации не должен вывести из строя управление шасси.

Как регулируется:

→ КТ-178С, п. 2.4.1 — поддержка обособления (partitioning) через выделенные ресурсы процессора и памяти.

→ MISRA C, Rule 8.1-8.12 — явное указание внешних ссылок и запрет глобальных переменных без контроля.

5️⃣ Неполное покрытие тестами

Каждое условие в логическом выражении должно быть протестировано независимо. Для авиационного ПО уровня A (самый критичный) необходимо проводить дополнительную верификацию, чтобы установить корректность сгенерированных последовательностей кода.

Как регулируется:

→  КТ-178С, пп. 6.4.4 — покрытие требований высокого и низкого уровней, структуры и проведение дополнительной верификации кода (для ПО уровня гарантии разработки А) обязательны.

Вместо итога

Разработка авиационного ПО — это не просто написание кода, а целое искусство, доказывающее безопасность полета. Каждая строчка проходит через многоуровневую верификацию, чтобы гарантировать, что даже в экстремальных условиях самолет останется под контролем.

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

🛡 С Днём защитника Отечества!

Поздравляем тех, кто выбирает ответственность, стойкость и надёжность своим принципом.

Желаем твёрдости духа, уверенности в каждом решении и новых достижений во всех начинаниях!

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

🛡 Обязательна ли сертификация по функциональной безопасности?

В интервью с Дмитрием Ивановичем Катковым, экспертом-аудитором, принимавшим участие в сертификации крупных производителей авиапрома, мы обсудили: необходима ли обязательная сертификация по функциональной безопасности в автомобильной промышленности?

Ответ Дмитрия Ивановича смотрите в видео, а что вы думаете по этому поводу? Пишите в комментариях.

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

✈️ Самолет из гаража: когда сертификация не нужна? Разбираемся в исключениях

🛡 Вы когда-нибудь задумывались, можно ли собрать самолет у себя в гараже и легально летать на нем без тонны документов?

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

Сегодня поговорим о том, что связывает 115 кг, французского инженера и двигатели от бензопилы.

⚖️ Что говорит закон?

Ответ кроется в пункте 2 статьи 8 Воздушного кодекса РФ. Если кратко: не все воздушные суда должны проходить сертификацию. Самый интересный пункт исключения — пилотируемые суда с массой конструкции 115 кг и менее.

Возникает логичный вопрос: а реален ли самолет весом менее 115 кг? Ответ — да, и это не просто теория.

🐜 Знакомьтесь: Colomban Cri-Cri — «Сверчок» в мире авиации

19 июля 1973 года в небо поднялся самолет, который сломал все стереотипы. Французский инженер Мишель Коломбан создал аппарат, который поражает воображение даже сегодня:

🔹 Вес пустого прототипа: всего 63 кг!
🔹 Длина: 3,9 м
🔹 Размах крыльев: 4,9 м

Название Cri-Cri (Кри-Кри) — это одновременно и уменьшительное от имени дочери конструктора Кристины, и французское обозначение стрекотания сверчка. И это имя идеально ему подходит.

⚙️ А теперь внимание — детали!

Первый полет, который совершил пилот Робер Бюиссон, прошел на самолете, оснащенном двумя двигателями… от бензопилы! Мощность каждого составляла всего 9 л.с. Позже масса самолета в разных модификациях выросла до 78 кг, но это все равно невероятно мало.

Этот самолетик стал настоящей легендой для авиалюбителей по всему миру. Он никогда не продавался в собранном виде. Около 15 лет его выпускали как конструктор, а с 1998 года Мишель Коломбан и вовсе перешел на продажу чертежей в масштабе 1:1.

История Cri-Cri — блестящее подтверждение того, что даже в жестких рамках регулирования есть место для инженерного творчества.

✅ Если вы строите самолет и укладываетесь в 115 кг — сертификация не нужна.
❌ Но когда масса превышает 115 кг,  без подтверждения соответствия нормам летной годности не обойтись.

Так что да, маленькие «самолетики» — это исключение.

Ждем ваши реакции!👇
🔥 — поставьте, если ваша собственная масса меньше массы самолета Cri-Cri (63 кг).
😄 — если вы (как и мы, чего уж там) все-таки тяжелее этого «Сверчка».

Делимся в комментариях чертежами Сверчка. Только для самообразования, разумеется! 😉

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

🌷 С Международным Женским днем!

Сегодня особенно хочется отметить прекрасных женщин, которые выбирают такие не «девичьи» направления. Автомобильная, авиационная и другие технические сферы считаются преимущественно мужскими, и тем ценнее и ярче ваше присутствие в них.

Пусть эта весна принесёт вам новые идеи, яркие эмоции и множество поводов для улыбок. Желаем вдохновения, успехов и гармонии во всех сферах жизни!

Пусть вам всегда сопутствуют уверенность, поддержка и новые высоты — и в небе, и на дорогах, и в жизни! ✨

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