МОСКВА, 24 дек — РИА Новости
Истребитель Т-50 (Су-57) потерпел крушение под Комсомольском-на-Амуре в Хабаровском крае, машина не военная и принадлежит заводу-изготовителю, сообщил РИА Новости представитель силовых структур.
Летчик катапультировался, его подобрал вертолет Ми-8, добавил собеседник. По его словам, крушение произошло в 120 километрах от аэродрома "Дзёмги". Самолет принадлежит Комсомольскому-на-Амуре авиазаводу имени Гагарина.
"Произошла авария, пилот успел катапультироваться", — подтвердил РИА Новости представитель правительства края.
Собеседник агентства добавил, что инцидент произошел во время испытания двигателя.
"Двигатель испытывали, летчик катапультировался, его подобрали вертолетом заводским и доставил на завод", — уточнил источник РИА Новости.
Как сообщил агентству представитель силовых структур, основными версиями крушения истребителя являются неисправность и ошибка пилотирования. По словам собеседника РИА Новости, специалисты приступили к поиску черных ящиков.
Использованные источники:
Комментарии
На то и испытания, что проходят они иногда при пороговых нагрузках компонентов истребителя.
А может банально человеческий фактор...
Если техническое, то необходимо теперь выяснить причину и сделать так, чтобы подобное в этим самолетом больше не случалось. Лучше сейчас, чем когда самолет пойдет в серию.
Главное: "пилот успел катапультироваться".
Я был знаком с лётчиками-испытателями, в т.ч. с Авиардом Гавриловичем - потеря машины при испытаниях некоторых - НОРМА, на каких-то реже на каких-то чаще. С "лаптем" было гораздо проще чем с некоторыми вроде серийными машинами но с некоторыми доработками.
В Ейске несколько недель волею случая жил в семье инструктора и там был разбор катастрофы, когда завод выпустивший новую, как тогда говорили, версию МиГ-25 (1978 годом дело было) - изменили кажется алтиметра расположение, по-видимому новый прибор а там ДРУГАЯ шкала на 30 градусов или около того повёрнутая. А у лётчиков до рефлексов всё отлажено и ничего менять из ключевых приборов нельзя. Машина ушла в землю или воду вместе с пилотом.
Возможно что или это или банальный смартфон в кармане пилота или техника с ВЧ навязыванием на систему управления. Флешка могла быть воткнута не туда куда или не там где нужно.
Исполнители заказов часто не выполняют условия восприятия образов. Вплоть до откровенной безграмотности несмотря на то что есть пионерские работы Раушенбаха и других.
Возвращаясь к лётной работе - было такое испытание в 1930-х на разрушение планера РотФронт-1 в воздухе, проводил Сергей Анохин, в буквальном смысле сверхчеловек. Восстановил себя после тяжёлого увечья, обладал и другими способностями начисто отсутствующими почти у всех людей.
Из пилотов высококлассные планеристы много чего умеют того, что недоступно обычным профессионалам. http://xn--80aafy5bs.xn--p1ai/aviamuseum/aviatory/letchiki/sssr-3/sssr-2...
Это не те испытания о которых вы подумали.
Это заводские испытания. На них никто не гоняет самолёт на предельных режимах.
Когда самолёт выходит с завода, его не сразу передают заказчику. Его сначала поднимают в воздух заводские испытатили и проверяют все-ли правильно собрано)
После облета передают заказчику.
Если в процессе заводских испытаний что-то случается, обычно это значит что на заводе что-то не так "спаяли".
Типо тачка с конвейера - тоже не сразу попадает на стоянку в автосалоне и... до предельных режимов конечно не доходят, но всёж таки да - бывает) Особенно если поведение тачки в каком-то режиме отличается от привычного.
Как вариант диверсия, как уже неоднократно было и с пассажирскими самолетами и космическими ракетами
Вот, только как в Америке что-то упадёт или взорвётся, так сразу ехидные шуточки про их "отсталость и ненадёжность". А у нас - На то и испытания, что проходят они иногда при пороговых нагрузках компонентов
Так это на заводе... Слава Богу. Лучше там, чем во время службы.
Ну вот это - совершенно обычный ход вещей при создании новой авиационной техники, почитайте историю создания знаковых машин нашей авиации, хотя бы Су - 24 - катастрофы в значительном количестве.
Никто не погиб, спасательные службы сработали как надо, а железа еще наклепают.
У МИГ-31 то же были серьезные проблемы.
Более чем, без указания типа мне рассказывали те кто видели лётные происшествия и испытывали его.
Не надо было убирать с двигателя НР. Идеология, которую продвигает отдел автоматики двигателя ОКБ Люльки - бред. Идеологический бред.
Некоторым пора увольняться и уступать дорогу молодым, готовым вернуться к классическим схемам.
НР?
Насос-регулятор.
Не нужны в интернетах технические детали совершенно мммм... новых образцов. А то дядя, который по должности бдит, мехом внутрь вывернет.
Пару лет тому повязали дурачка, няп, на заводе в КнА - в интернетах на форумах сливал инфу троллю-жидёнку. Этот слабоумный ишшо и фоточки прикладывал доказывая что наши литакии ого-го...
А почему Вы решили, что там именно этот момент? Вполне возможно, что СУ работала исправно до падения.
Может быть более банальный отказ той же ГС или еще чего, ну и плюсом, не самые грамотные действия того же летчика.
PS. А Вы видели какой-нибудь НР в реале? И знаете как он работает?
Гораздо технологичней и проще реализовать большинство из его функций электроникой.
Дюже сложное и дорогое изделие, подверженное, к тому же, механическому износу.
Я как вспомню насосы-регуляторы на МиГ-21, так вздрогну ;) а ведь это не самые сложные из подобных изделий. Прецезионная жуть.
О них жалеть - это всё равно что карбюраторы на автомобильных двигателях любить. Или прерыватели-распределители.
Ушли от них - и слава Богу. Вон, у меня на машине 88 года выпуска распределённый впрыск с компьютерным управлением пашет и слава Богу. Без поломок и регулировок.
Вот и я об этом же.
Все-таки есть разница в степени сложности между
банальной кофемолкойавтомобилем и ТРД.Я кагэбэ в курсе :)
В данном случае это не сравнение самолёта с автомобилем, а прогреесса в авиационной технике и прогресса в автомобильной. Могу добавить и ракетную туда же. Переход там на компьютерное управление как раз повышает надёжность и упрощает конструкцию.
Проблема в том, что вы, инженеры-механики, не знаете о проблемах, возникающих при разработке программного управления. Обычно это выглядит так: хочу, чтобы процессор управлял данным узлом так-то и так-то. Все. А дальше все проблемы - у "тупого программиста". Который, начиная разбираться, осознает, что степень сложности алгоритмов выходит на порядок выше, чем кажется на первый взгляд. А сложность = ошибки, как ошибки при программировании, так и теоретические ошибки. И начинается бодание: программист, чтобы повысить надежность, пытается упростить программу управления, которую ему надо запрограммировать. А инженер-механик, ничего не смыслящий в вычислительной математике, думает, что все программисты такие лентяи и за что им только деньги платят. В результате зачастую получается "не рыба - не мясо".
... это для вас конструкция упрощается. А на самом деле - нифига не упрощается.
P.S. Два Боинга уже упало именно по этой причине. Из-за попытки "попростому" запрограммировать управление нелинейными процессами.
А вот тут вы ошибаетесь. Знаем. Много пришлось работать и по тому, и по другому.
Если в конструкции уменьшается число деталей и узлов при сохранении функционала - конструкция упрощается.
И да, надо дружить с теорией автоматического управления. Когда алгоритмы разрабатываешь. Это, кстати, именно к Боингам.
И надо помнить об ограниченных возможностях исполнительных механизмов.
Кстати, в насосах-регуляторах - алгоритмы "запрограммированы" весьма примитивные. Линейная аппроксимация. В лучшем случае - кусочно-линейная.
Вот именно. Только приходится это скрывать. Потому что если говоришь вслух слова "передаточная функция" или, не дай бог, "дифференциальное уравнение", некоторые умные механики смотрят на тебя, как на выскочку, который не знает, как мотор устроен, а туда же, рассуждать норовит.
А разве нет такой дилеммы: либо один сложный механизм, либо много исполнительных механизмов?
Вот и хорошо, что кусочно-линейная. Я как раз столкнулся с тем, что в некоторых случаях это предел. Дальше начинается полная неуправляемость.
В авиации таких "умных механиков" нет. Вывелись под корень ещё в конце 30-х годов.
Под ограниченными возможностями исполнительных механизмов я имею в виду их скорость, точность и развиваемые усилия.
Ограниченность линейных и кусочно-линейных алгоритмов осознавалась ещё в 50-х годах. Бороться с ней сил и технических возможностей раньше не было. Относились к ситуации не как к благу великому, а как к неизбежному злу.
Когда я заканчивал ВУЗ, кроме линейных систем управления нам ничего не давали. Даже систем с одной нелинейностью не давали. Я сам краем глаза присматривался, но там был такой бодрый матаппарат, что для моих тогдашних мозгов всё выглядело....ммм... ладно, признаюсь - устрашающим. Какие-то частные случаи, годографы, матрицы с размерностью явно более трёх... Там вообще аналитические решения предполагаются, или же это область незамутнённых численных методов?
В общем случае аналитических решений там не густо, только в некоторых частных случаях. А так - да, численные методы и эксперимент.
Любопытно было читать в учебнике конца 70-х слова "мера энтропии", "хаос"... Нам на втором курсе вычислительную математику дали в изрядно отстойном варианте, без малейшей привязки к реальным задачам - оттого матаппарат, который использовался в ТАР нелинейных систем, категорически не заходил. Жаль, конечно - интересная тема.
Ну да, сделать несмещенную оценку в нелинейных системах управления - практически анриал. Потому - чистая эпмирика.
Можно применять крутую вычислительную математику в двух сферах: в диагностике и в управлении двигателем. В управлении использовать ее стремно, поэтому моя точка зрения такая: пускай остаются кусочно-линейные функции.
А вот в диагностике надо двигаться. Но тут у нас как в том анекдоте про алкоголика и обезьяну: "Что тут думать, тут прыгать надо!". В смысле - тащить математику на борт. Мне ближе позиция обезьяны, которая сначала думала, а потом прыгала. В смысле - сначала применение в диагностике. А это не всем интересно.
э тут это
за работу отвечает программный кулачек или эвм как у пс90 (правда кулачек полностью дублирует электронику на всех режимах )
и там нет простой линейности
Отсюда
Мдя...
именно поэтому и возникла новая сфера деятельности - мехатроника
с приходом электроники и приводов - механика механизмов может быть существенно упрощена
вместо всяких мальтийских механизмов - которые изучают инженеры механики по справочникам механизмов и машин артоболевского
http://techliter.ru/load/uchebniki_posobya_lekcii/spravochniki/mekhanizm...
- надо изучать обычные направляющие привода и базовые основы программирования микроконтроллеров
попытка скрестить разные сферы - это всегда компромис - точка эффективности в котором меняется и чтоб понимать где эта точка надо владеть обоими дисциплинами
Для начала - соглашусь с этим утверждением. Должен сказать, что весь этот спор, который я здесь затеял - он, конечно, чисто идеологический. Надо все делать разумно, без экстремизма, находить компромисс.
Более подробно отпишусь в комментах к другим вашим комментам.
это первый наш двигун без нр
но не только там могут затыки
может банальная стружка в канале
короче разберутся
странно что и второй двигун не помог
как бы не разрушение турбины
Да, пока неизвестно, в чем там дело.
НР в реале видел, внутрь не лазил, но представление имею.
А вы пробовали этим заняться? Я вот несколько лет на это потратил, правда, не на замену НРа, а на замену другого, не менее важного, агрегата. Для себя вывел следующие недостатки цифрового управления перед аналоговым:
1. Меньшая надежность,
2. Меньшая скорость передачи информации,
3. Меньшая интеллектуальность: инженер, занимающийся оцифровкой управления, тупеет, перестает понимать физические принципы.
А я и разбирал, и собирал...
Основной недостаток аналоговых систем - большое количество деталей. Которые могут отказывать. И невозможность их совместного использования. Огромное число проводков, трубочек, соединений.
не говоря уже о внутренних линиях, дросселях и клапанах...
Ой, далеко не факт - электроника давно уже сильно надежней механики
Тут даже говорить не о чем - рабочие частоты электронных устройств - десятки, а то и сотни мегагерц, против гидравлики....
А вот это и есть самый "узкий" момент.
Хорошо, если инженер вообще понимает процессы и их влияние друг на друга, происходящие в НР.
Постоянно сталкиваюсь с отказами электроники. Впрочем, тут спорить бесполезно, каждый сталкивается с отказами в своей сфере деятельности.
А частоты интерфейсов - единицы-десятки-сотни герц :):):). Многие важные бинарные сигналы в очень современных ТРД передаются с частотой, скажем, 4Гц.
Что касается гидравлики и прочих аналоговых схем, то скорость тут измеряется вообще не в Гц. В цифровом сигнале для распознавания смены уровня напряжения с 0 на 1 нужен немаленький промежуток времени, а в аналоговом уровень - он уже и есть уровень.
К сожалению, наши (и не только наши) мудрые разработчики систем считают, что программисту незачем знать, что именно он программирует. Общение идет "на пальцах", как будто мы садовые скамейки собираем, а не создаем сложную технику.
если говорить о силовой электронике - то она сейчас применяется в такой рисковой зоне с такими реактивными составляющими - что там да есть риски
и на них идут лишь по той причине - что она позволяет делать то что или не доступно или дорого по старинке
что касается сигнальной электроники - это самая надежная часть что есть в технике
ну может тока ядерный взрыв не держит
в остальном сигнальная уже не жрет не греется и практически устаревает раньше чем выходит из строя
для механических систем имеет значение величина обратной связи - и она крайне редко может быть больше 1 миллисекунды
в реалиях для механики в 90% достаточно диаипазона реакции в десятые и сотые доли секунды
а нередко нужны и единицы и десятки секунд
вот гараздо труднее программными средствами потушить низкочастотные автоколебания механики - поскольку в системе ( обьект управления датчики - компьютер - исполнительные механизмы )
- компьютер - самая простая вещ
Это так. Причины отказов кроются в другом:
1. Ошибки программиста конкретного процессора. Сразу здесь же надо упомянуть ошибки настройщика системы, который может вкатить в процессор не ту прошивку или ошибиться при настройке констант.
2. Ошибки при согласовании взаимодействия разных процессоров. Один программист забыл о чем-то сообщить другому. Или не предусмотрел все случаи взаимодействия систем.
В обоих случаях, кстати, самолет может летать годами, пока не наступит критическое событие.
Вы скажете, что это и так ясно. Проблема в том, что сложность систем, состоящих из нескольких компьютеров, взаимодействующих обычно недооценивают.
Вот взять хотя бы пример с недавней катастрофой АН-148. У нас один мужик откопал схему. Судя по всему, дело было так: по какой-то причине добавили еще один, третий, датчик. И принцип, по которому различные системы выбирали, какому датчику верить, оказался очень запутанным. Мы с полчаса смотрели на схему их взаимодействия и пытались понять, как оно там все могла сработать - черт ногу сломит. А всего-то добавили один датчик недостаточно продуманным образом. Тут пахнет все той же идеологией: "Программисты все разрулят".
Вот тут - самое интересное.
1. Цифровое управление тоже подразумевает механические части, как минимум - датчик с одной стороны и сервопривод - с другой, об этом приходится помнить. Раз уж мы беседуем в теме про упавший СУ-57, то можно сказать, что авария на первом серийном самолете у нас становится доброй традицией :) - первый серийный СУ-35 тоже сгорел. И причина тогда была такая: железяка, закрепленная на сервоприводе, зацепилась за край люка и летчик не мог убрать форсаж.
2. Тут уже говорили про то, что обычно ограничиваются линейными или кусочно-линейными программами регулирования. Вы же понимаете, почему это так. Любая нелинейность может вызывать серьезные труднопредсказуемые эффекты, особенно когда обратная связь существенна, особенно когда мы имеем дело с дискретным временем (а в случае цифры время дискретно). Я тут наблюдал, как ребята лет пять бились над тем, чтобы подобрать координаты всего-то 5 точек перелома и меня дергали постоянно. Постоянно получалось "все не так", отказы случались, слава богу, что не в полете.
В общем, вы поняли, я за все хорошее и против всего плохого :) , то есть надо делать все разумно и не переборщить с цифровизацией.
P.S. Совсем другое дело - заниматься всякой сложной математикой в целях диагностики. Я могу месяцами экспериментировать с обработкой данных, строить сложные нелинейные модели, попивая кофе, и не один самолет из-за этого не упадет.
когда я был вьюношей - то история как американский б1 - срезал холм - была у всех на устах
первая борьба систем
это потом уже добавился израильский ф16 со збросом всей электроники при полете над мертвым морем
но если в вашем окружении молодежь забывает такие вещи - то это обескураживает
в моем окружении думают тока о вэб дизайне
У меня другая фишка - я все на стариков наезжаю. Молодежь вокруг вся какая-то правильная.
Наверное, это я сам еще слишком молодой, за полтинник еще не перевалило.
Эх, где-то там, в глубине лет, мой полтинник затерялся(((
Был у нас в стране такой министр образования по фамилии ФурсенкО (хотел, чтобы его называли фУрсенко). Он как-то сказал, что математика не очень нужна , так как она не позволяет развивать воображение (цитирую не дословно, но смысл такой).
У вас, похоже, что физикам математика не нужна.
Вот именно так "у нас" и происходит, к сожалению.
Слишком много лжи нагородили( с начала века)+реформа Колмогорова в полный рост.
разьясните пожалста - под аналоговым вы имеете ввиду - механическую автоматику или аналоговую электронику ?
дело в том что я разрабатывал как чисто цифровую управляющую электронику так и смешанную - в которой часть работы делала аналоговая электроника на операционных усилителях
это в том случае когда не хватало быстродействия цифровой - но там речь шла о крайне специфической вещи - к которой не было мат модели - и шли по принципу управляемых полосовых аналоговых фильтров
и делалось это на 580 микропроцессоре с частотой 2 мгц и двух дюжинах счетверенных операционных усилителей 30 лет назад
с точки зрения современной электроники - она кроет все потребности механики - как бык овцу
Конечно же, и то, и то. Где что лучше подходит.
Интересно. У меня сейчас в одной задаче тоже полосовой фильтр бегает по сигналу.
Все живы и слава богу!
Страницы