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

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

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

✈️🚙 Анализ безопасности авиационного и автомобильного ПО

Основным нормативным документом, регламентирующим разработку встроенного программного обеспечения для авиационной техники, является стандарт КТ-178С. Для дорожных транспортных средств аналогичную роль выполняет серия стандартов ГОСТ Р ИСО 26262, в частности часть 6, посвящённая разработке программного обеспечения.

Подходы к разработке программного обеспечения в авиационной и автомобильной промышленности имеют как общие черты, так и существенные различия. Общность проявляется прежде всего в организации процесса разработки: и КТ-178С, и ГОСТ Р ИСО 26262 обязуют применение V-образной модели жизненного цикла, в рамках которой разработка программного обеспечения начинается с разработки требований, далее выполняется проектирование архитектуры и реализация программных компонентов, а на каждом этапе проводятся соответствующие процедуры верификации.

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

❓А как вы считаете: достаточен ли авиационный подход, при котором анализ безопасности архитектуры ПО не выполняется только на системном уровне, или же автомобильная практика с обязательным анализом программной архитектуры выглядит более обоснованной? Поделитесь своим мнением в комментариях.

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

🌳 MBSA: наши выученные уроки

Тема экологии для нас важна почти так же, как и безопасность транспортных средств. В ходе некоторых наших проектов нам удалось их совместить и перестать “рубить деревья отказов”, а воспользоваться новейшими методами анализа: MBSA (Model-Based Safety Analysis или модельно-ориентированный анализ безопасности).

Наши подписчики наверняка помнят, что с декабря 2023 года опубликована очередная ревизия документа SAE ARP 4761A, которая не только гармонизируется с обновленной ревизией SAE ARP 4754B, но и добавляет специалистам в области оценки безопасности авиационных систем больше новых обязательных и опциональных анализов. Одним из таких опциональных анализов и является MBSA. К сожалению, общепринятой и опубликованной версии перевода и сокращения еще нет, но ключевые специалисты отрасли активно работают над этим в рамках рабочей группы по переводу ARP 4761A на русский язык. Пока будем пользоваться имеющимся мировым аналогом.

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

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

✈️ Топ-5 рисков при получении свидетельства о годности комплектующего изделия (СГКИ) для готовых авиационных изделий

В идеальной картине мира разработка изделия происходит итерационно – сначала пишется ТЗ, функции, потом создаются и декомпозируются требования, архитектура, разрабатывается КД и код, пишутся тесты, происходит разработка, интеграция, верификация/валидация. И только потом - сертификация изделия.

Но что делать если изделие уже готово и его необходимо сертифицировать?

Почему нужно сертифицировать авиационные изделия по Р-4754А, КТ-178С и КТ-254?

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

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

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

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

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