✈️Инженеры намеренно ломают самолеты! И вот почему...

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

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

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

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

Все не просто так - катастрофы, произошедшие из-за разрушения крыла:
🔻Катастрофа L-188 под Каннелтоном
🔻Катастрофа Gippsland GA8 Airvan под Умео

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

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

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

Катастрофы, произошедшие из-за попадания воды:
🔻Катастрофа Boeing 737 под Джокьякартой
🔻Катастрофа B-2 Spirit в Тихом океане

🛫 На козла?
Минимальная скорость отрыва (Velocity Minimum Unstick) - одно из самых сложных и зрелищных испытаний для пилотов, цель которого - определить минимальную скорость, при которой самолет может безопасно оторваться от земли.

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

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

Катастрофа, произошедшая из-за недостаточной скорости отрыва от земли:
🔻Авиакатастрофа в Мюнхене 6 февраля 1958 года

🔥 Торможение на износ
Представим, что самолет разогнался до взлетной скорости, но что-то пошло не так, и нужно экстренно тормозить.

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

Это испытание моделирует худший сценарий - прерванный взлет при максимальной кинетической энергии.

Кстати, в отличие от автомобильной промышленности, краш-тесты пассажирских самолетов практически не проводятся. Единственный сертификационный краш-тест был проведен в декабре 1984 года на базе ВВС Эдвардс по заказу FAA, но объектом было не само судно, а топливо в баках.

Катастрофа, одной из причин которой стали изношенные шины:
🔻Катастрофа DC-8 в Джидде

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

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

📌 Вывод
Испытания - не просто формальность для получения сертификата.
Каждый этап моделирует реальные ситуации - от столкновения с птицами до торможения на максимальной энергии. За каждым "забавным" испытанием стоят годы инженерной работы и тысячи часов испытаний.

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

📚 Нашли для вас кое-что интересное

Если вы уже используете 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 в своих проектах? Делитесь опытом в комментариях.

Задача верификатора имени Марселя Пруста

🔧 Этап верификации особенный. Планы, по которым следует работать, уже написаны, дописаны и переписаны ни один раз. Требования разработаны. Даже железка собрана и стоит в углу красивая с зашитым в нее ПО. И казалось бы, отправляй в машину или на самолет, что с ней будет?
Но конечно сначала надо доказать, что реализованный прибор работает именно так, как от него требовалось. И доказывается это в том числе испытаниями.

🧩 В одном из наших проектов мы столкнулись с типовой задачей: надо измерить время реакции прибора на изменение входного воздействия. А вот решать ее пришлось не типовыми способами.

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

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

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

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

💡 Идея №1
Первая мысль: «а давайте просто заведем сигнал с задатчика в наш измерительный компьютер, который фиксирует вольтметр!». Компьютер узнает, когда задатчик выдал сигнал, засечет время, и мы вычтем задержку.
Проблема: стенд аттестован и поверен. Любое вмешательство в его конфигурацию ведет к необходимости проводить эту процедуру повторно. Хорошо, но все задачи должны быть решены вчера, поэтому не подходит.

📱 Идея №2
Раз стенд менять нельзя, значит, будем снимать показания глазами. Но глазами невозможно измерить миллисекунды. В ход пошла тяжелая артиллерия, камера смартфона.

План был красив: снимаем на видео экран задатчика (момент, когда входное значение начало расти) и одновременно показания вольтметра на выходе прибора. Разбиваем видео на кадры, вуаля, задержка вычислена с точностью до периода съемки.

И тут мы натыкаемся на стену. Камера телефона ведь тоже не аттестована! И пусть кадры будут красивые, но для заключения о соответствии требования не подойдут.

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

📱📱Идея №3
С камерой разобрались, она измерит непонятно что и как. Верить нельзя. Но что, если одновременно снимать двумя телефонами?

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

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

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

⚠️ Но снова неудача, оказывается в паспорте задатчика не указана задержка его собственного экрана!

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

Надежда рухнула. Мы уткнулись в механику и электронику самого задатчика, которые мы не контролируем.

💻 Идея №4
Оставался последний рубеж, измерить время реакции на уровне ПО самого прибора. На стенде интеграционного тестирования ПО такую возможность мы предусмотрели заранее.

Но и тут нас ждал подвох.