backup_f20: (Default)
backup_f20 ([personal profile] backup_f20) wrote2012-11-01 10:41 am

Воштыль: подтверждаю показания относительно захода Ту-154М на высоту 50м

Поручик Артур Воштыль, пилот Як-40, на котором 10 апреля 2010 года на мероприятия в Катынь летели журналисты, сообщил, что подтверждает показания бортового техника ЯК-40 Ремигиуша Муся, касающиеся захода Ту-154М на аэродром в Смоленске на высоту 50 метров. «Я могу подтвердить его (Муся) показания в части, которая касается «Туполева» и захода на посадку в Смоленске на высоту принятия решения. В этом смысле всё то, что было сказано, я подтверждаю, (...) я не тот человек, который бы спутал 50 метров со 100 метрами», - сказал Воштыль во вторник на заседании парламентской группы по расследованию причин катастрофы.
На прямой вопрос, слышал ли он команду диспетчеров в Смоленске, обращённую к Ту-154М, чтобы самолёт спустился до высоты 50 метров, он ответил: «Да, слышал такую команду. Многократно (это) повторял во время допросов в прокуратуре».
Заседание парламентской группы было созвано в связи со смертью прапорщика Ремигиуша Муся, который был одним из свидетелей в смоленском следствии.
Бывший бортовой техник Як-40 утверждал, что диспетчер в Смоленске позволил экипажу президентского самолёта спуститься на высоту 50 метров. Из опубликованных стенограмм следует, что диспетчер позволил спуститься до 100 метров. Мусь утверждал, что сразу после приземления Як-40 он оставался в кабине и слышал по радио переговоры между экипажем Ту-154 и диспетчерской. По его словам, экипаж Як-40 также получил согласие на снижение до 50 метров. Як-40 приземлился в трудных условиях, примерно за час до катастрофы президентского самолёта. На его борту было несколько десятков журналистов, которые летели освещать мероприятия в Катыни.
Глава парламентской группы по расследованию причин катастрофы Антони Мачеревич объявил, что группа обратится к руководителю МВД и к генеральному прокурору, чтобы обеспечили «физическую безопасность» поручика Воштыля.
 



[identity profile] flanker20.livejournal.com 2012-11-06 12:34 pm (UTC)(link)
///Какая все же частота указана в докладе?///

Именно эта и указана - 116.3
Указано также, что частота маяка была настроена, но сигнал от маяка не принимался. Я думаю просто был выходной, там аэродром не очень крупный, запросто был выключен.

///Как сами поляки это объяснили?///

Естественно, никак. Ни словом не обмолвились. :-)

///Вы уже где-то в жж анализировали это момент?///

http://flanker20.livejournal.com/19790.html

[identity profile] askepak.livejournal.com 2012-11-06 07:01 pm (UTC)(link)
Ну, Вы меня этим постом прям таки взбудоражили. У Вас есть собеседник, который придерживается чудесной версии кино-боевика. Странно, что его этот пост не заинтересовал.

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

Это может свидетельствовать всего лишь о том, что последний раз когда пользовались навигацией по VOR маякам, самолет находился в этой точке.

Кстати, Вы обратили внимание, что в п.3.3.1.5 приложения к докладу в ячейке
ILS Course (L105) декодировщики не обнаружили "осмысленных" данных.

Ну, а по поводу "не в Смоленске" - в логах же есть цифры 3-х GPS - приемников и время. Все со Смоленскими координатами. Да, Вы и сами в эту версию не верите.
Edited 2012-11-06 19:21 (UTC)

[identity profile] flanker20.livejournal.com 2012-11-08 07:14 am (UTC)(link)
///Ну, Вы меня этим постом прям таки взбудоражили.///

:-)))

///Да, Вы и сами в эту версию не верите.///

Верить-то я не верю, но момент непонятный. Те false, о которых Вы говорите, относятся к ILS-ным вещам, они к той навигационной задачке, которую мы решаем, отношения не имеют, поэтому о них поговорим позже.

Конечно, логику работы системы может прояснить только кто-то из разработчиков, да вот как их спросишь? Я уверен, что система пересчитывает в реальном времени азимут и удаление от маяка до текущего положения самолета даже если не получает от маяка сигнал, координаты-то известны. Если это так, то вопрос становится очень серьезным.

Даже если это не так, и как Вы говорите "Это может свидетельствовать всего лишь о том, что последний раз когда пользовались навигацией по VOR маякам, самолет находился в этой точке.", то все равно возникает вопрос: а когда это он в ней находился? Я прикидывал, ни в одном из восьми последних полетов самолет не мог быть на удалении 325км от Шяуляя, я уж не говорю про азимут и второй маяк VOR. Непонятно также, зачем вообще нужно было забивать этот маяк. 101-й по захолустьям всяким не летал (кроме Смоленска), думаю на каждом аэродроме, куда он садился был свой VOR или TACAN, по которым и строилась бы навигация (про GPS вообще пока молчим). Зачем была нужна настройка на TACAN в Шяуляе? Если только в одном из полетов Шяуляй был запасным аэродромом? В каком? Под последние полеты этот запасной тоже вроде бы не подходит.

Неприятно удивило наличие в искомой точке военного аэродрома. Это был такой небольшой шок. :-)


Теперь о false-ах и данных 3-х GPS-приемников. Я с недоверием отношусь к логам TAWS. Мне не нравится, что цифры, которые там есть (в том числе и координаты взятые от GPS), не укладываются в алгоритм генерации алертов. Поэтому там тоже есть много вопросов, которые хотелось бы задать ребятам из UASC.

[identity profile] askepak.livejournal.com 2012-11-08 07:11 pm (UTC)(link)
> Я с недоверием отношусь к логам TAWS. Мне не нравится, что цифры, которые там есть (в том числе и координаты взятые от GPS), не укладываются в алгоритм генерации алертов.

Я рассуждал о данных, "снятых" с памяти FMS (п.4.9.5 приложения). Ведь именно о них шла речь в связи с Шауляйским маяком (и данные GPS тоже имел ввиду те, что взяты из памяти - п.3.3.1.6.3). Уточню. Употребленный мной там термин "логи" неправильный - я имел ввиду именно состояние памяти. Логи - это специально ведущаяся запись, т.е., по-существу, некий результат работы программы, который программист хочет увидеть после выполнения программы для целей отладки или выявления ошибок программы; может включать в себя также и конечные результаты програмных вычислений. Данные памяти - это то, что осталось в "програмных переменных" в "характерных" точках при исполнении программы, т.е. они могут и не отражать конечный результат, а содержать промежуточные значения (или значения предыдущего решения задачи) или вообще мусор. Что конкретно означают эти данные может сказать только программист, писавший конкрет. прогр.

> Те false, о которых Вы говорите, относятся к ILS-ным вещам, они к той навигационной задачке, которую мы решаем, отношения не имеют

Нет, я говорил о п.3.3.1.6.4. Который описывает "состояние" и настройку системы VOR/DME. Возможно, она относится (в данном случае) не к посадке (просто остались старые, предыдущие настройки системы), а к процедуре навигации на трассе (которая происходила когда-то раньше). Приемники оставались настроены на эти частоты, в программных переменных (ячейках памяти) остались результаты предыдущих вычислений. Но в последнем полете сигналов от маяков не было, что и отражают програмные флаги VORCON, VORFLG для 1-го маяка и TACANCON, VTFLG для второго. В расшифровке специалиста это звучит, как "Station tuned, but no bearing received" (Приемник настроен, но сигналов для определения азимута не получено) и "TACAN tuned, but no bearing/distance received". Любопытно, но в этом случае речь идет о неполучении данных не только по азимуту, но и по дальности. Дальше там идет еще пара флагов (отдельно) конкретно о DME. Возможно, первый маяк просто не имеет DME. Не суть.

> Я уверен, что система пересчитывает в реальном времени азимут и удаление от маяка до текущего положения самолета даже если не получает от маяка сигнал, координаты-то известны.

Зачем? Смысл VOR маяков именно в навигации в полете на трассе, т.е. определении азимута (и иногда дальности) на маяк. По двум VOR маякам (зная их координаты) можно определить свое местоположение. Какой практический смысл в теоретическом высчитывании координат? Другое дело, что на сегодняшний день эти маяки (также, как и советские NDB) не актуальны и имеют для навигации серьезной авиатехники факультативное значение, поскольку сейчас используются высокоточные инерциальные системы (автономные) и контроль по GPS.

Актуальным остается применение навигационных маяков только при подходе к полосе и при посадке (т.к. даже при заходе по ILS в сму необходимо "уточнение" по VOR с какого торца производим посадку), а для этого достаточно всего лишь одного VOR маяка (ну или пары NDB - ближний, дальний).

> все равно возникает вопрос: а когда это он в ней находился? Я прикидывал, ни в одном из восьми последних полетов самолет не мог быть на удалении 325км от Шяуляя, я уж не говорю про азимут и второй маяк VOR

Ориентируясь на факт бардака в польск. авиаполку, могу допустить все что угодно. Руководство зачастую имеет "хорошую" привычку поручать ремонты не только не по профилю, но даже той техники, которую не имеешь права ремонтировать. Допускаю, например, что поляки могли доморощенно "обслуживать" FMS самолетов своего полка. Ремонты сложной техники (и как частенько бывает - документации никакой нет) начинаются с поиска неисправного блока (платы... и т.д.) путем перестановок с исправным оборудованием. Зачастую этим ремонт и заканчивается, к тому же блоки из разных приборов могут в конце-концов оказаться и не на "родных" местах. Хорошо бы для начала убедиться по номерам, эти ли блоки были установлены на 101 при кап-ремонте. В общем, вариантов тут может быть много разных.


[identity profile] flanker20.livejournal.com 2012-11-09 09:46 am (UTC)(link)
///Зачем?///

Например, захотели Вы посмотреть в полете статус маяка. На соответствующей страничке Вы увидете его код, азимут, удаление и пр. Если там нет DME, то система покажет рассчитанное по координатам удаление. Или Вы строите флайт-план, в котором говорите, что на таком-то удалении от такого-то маяка нужно изменить курс на такой-то. В этом случае система, если не получит удаление от маяка (нет DME, маяк выключен) будет использовать рассчитанное значение удаления. Так что, я думаю, удаления от маяков по координатам система считает в реальном времени независимо ни от чего.

[identity profile] askepak.livejournal.com 2012-11-09 10:36 am (UTC)(link)
Нет. Пропадает смыл навигации по маякам, для чего собственно они и предназначены. Все построения , изменения, прокладка курса (наподобии того, о чем Вы говорите) строят (т.б. при наличии инерциальных систем) относительно исходной (опорной) точки. Предполагаемые координаты "маяка" не дают никаких преимуществ, подумайте сами (я поверхностно интересовался вопросами навигации). Маяки они для того и предназначены, чтобы вносить коррективы в теоретически рассчитанный маршрут, никакие теоретические координаты маршрут не откорректируют, а для его теоретического изменения достаточно координат исходной точки.

[identity profile] flanker20.livejournal.com 2012-11-09 11:02 am (UTC)(link)
///Пропадает смыл навигации по маякам///

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

///Предполагаемые координаты "маяка" не дают никаких преимуществ///

Разумеется не дают. Система использует их как "запасные", см. выше. А если у Вас чистый VOR? Где Вы возьмете для него удаление?

[identity profile] askepak.livejournal.com 2012-11-09 01:51 pm (UTC)(link)
> Просто данные, получаемые от маяка более приоритетны, чем рассчитанные системой. Когда они есть, то используются они. Когда от маяка нет сигнала, то используются рассчитанные значения.

Сваливать в кучу реальные координаты и виртуальные... Дискредитируется сама суть навигации.

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

Для навигационной части программы необходимы входные данные. Логично заключить, что в пункте 3.3.1.6.4 именно они (в случае маяков) и содержатся. Вроде так и написано: "An RRS was configured on ARINC input port 3. The RRS contains DME, VOR, and TACAN receivers." Т.е. это данные ОТ приемников.

А вот заключать, что во ВХодные данные навигационной программы будут заноситься ВЫХодные данные программы визуализации по запросу "а прикинь-ка мне, компьютер...", имхо, совсем не логично. Да и приемнику эти данные ни к чему. А ведь это как раз порт приемника.

У меня вариант обсчетов запросов "а прикинь-ка мне, компьютер..." в блоке приемников не кажется убедительным, вернее - я его практически исключаю. Впрочем, с FMS я не знаком.

Вычисление дальности, при отсутствии сигнала DME, но наличии двух сигналов курсовых маяков, ес-но, должна считать программа "навигации".

Ремарка "вычислены" для дальности в распечатке "приемников"? Ну, что ж... не знаю, возможно и блок приемников просчитал...

В этом случае имеющиеся данные азимутов и дальностей зафиксированы в одно время (но как предполагалось выше, возможно, не с тех маяков, что указаны)... Можно, если есть желание, по-примерять по карте, где такое могло произойти еще, кроме как...

[identity profile] askepak.livejournal.com 2012-11-09 04:14 pm (UTC)(link)
> Ремарка "вычислены" для дальности в распечатке "приемников"? Ну, что ж... не знаю, возможно и блок приемников просчитал...

Нет, все же остаюсь при первоначальном мнении.
Переменные названы программистом "в одном духе": 'VORBRG', 'VORDIST'. Т.е. "происхождение" их идентичное - это конкретно реальные азимут и дальность, полученные от блока приемников. Это совершенно определенно.

Ремарку "Computed distance to VOR station", полагаю, объясняет то обстоятельство, что дальность-таки действительно необходимо вычислять. Если для азимута достаточно простой аналоговой обработки сигнала (определяется соотношением фаз), то дальность необходимо вычислять исходя из разности времени между отсылкой сигнала в сторону маяка и получением от него ответа. Это - чисто "человеческая" ремарка. С точки зрения же программинга - все ок!

[identity profile] askepak.livejournal.com 2012-11-08 07:12 pm (UTC)(link)
Продолжение

Трудно сказать что либо определенное. Посмотрел Key Press History не вникая. Но бросилось в глаза, что во время полета "тыкались" кнопки для активации, например, след.
[Error: Irreparable invalid markup ('<started [...] "vno">') in entry. Owner must fix manually. Raw contents below.]

Продолжение

Трудно сказать что либо определенное. Посмотрел Key Press History не вникая. Но бросилось в глаза, что во время полета "тыкались" кнопки для активации, например, след. <Started to insert waypoint "VNO">. В колонке результат пишут <Started to insert "VNO", the Vilnius VOR/DME, into the flight plan>. Потом, правда, нажимается "Отмена". Но вот, интересно, происходила ли настройка на маяк Vilnius VOR/DME или нет? Таких тыканий насчитывается 3 штуки. Еще - Глубокое и Могилев. И все. Происходила ли настройка приемников на эти маяки, и когда произошла настройка на тот VOR, что отмечен в таблице пункта 3.3.1.6.4 - не знаю. Кстати, это - Витебск. Т.е., как бы их запасной. Но по выходным дням аэропорт там не работает, не удивительно, что "отклика" не было. И еще, в таблице по п.3.3.1.5 опять же стоит <VOR Tuning Code = 112,7> Т.е. тот же Витебск. В этой же табличке <TACAN Tuning Code = No Computed Data>. И также <No Computed Data> отмечено в строчках <ILS Course> и <Pseudo ILS Course>.

В табличке по п.3.3.1.2 есть графа "навигационные средства и аэродромы для фоновой карты". Снизу вверх там перечисляются и Шауляй, и куча других городов, потом Минск, еще какие-то, а также и Глубокое, и Могилев, а после Могилева последним Витебск. Возможно, Вы и правы, и по п.3.3.1.6.4 в "ячейках" удаления и азимута мы видим расчитанные величины для отображения на этой фоновой карте, а не резудьтат навигации. В таком случае, Ваши вычисления по 2-м последним результатам явл. интересным курьезом. В любом случае, думаю, нам не прояснить этот вопрос.

[identity profile] flanker20.livejournal.com 2012-11-09 07:49 am (UTC)(link)
///В любом случае, думаю, нам не прояснить этот вопрос.///

:-) Ну, вот и я так считаю.

Странно, что все попытки манипулировать с флайт-планом (Вильнюс, Могилев, Глубокое) не нашли отражения на записи переговоров экипажа.

[identity profile] askepak.livejournal.com 2012-11-09 10:40 am (UTC)(link)
Я вообще не вникал и не представляю как выполняется флайт-план. Если предположить, что - "от точки к точке", то для выполнения плана, очевидно, такие шараханья совершенно ни к чему. В таком случае эти "нажимания" служили какой-то другой цели. Например, навигационный контроль по маякам, если предположить, что это вызывало перенастройку приемников... Или вообще (к чему я склоняюсь) - штурманское "любопытство". У штурмана ведь, практически, не было совершенно никакого опыта работы, и ес-но ему было бы интересно в реальном полете посмотреть что как работает.

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

1. Устройство не представляет из себя ничего заоблачного. Обычные технологии 90-х, 2000-х годов. Даже Windows упоминается, возможно, что устройство работало на какой-то из этих ОС. Память энергозависимая. 99,99% что элементы питания такие же, как применялись до последнего времени в обычных материнках ПК и другой аппаратуре. Т.е. - оборудование требует техобслуживания (замена ист. пит. м/c памяти) не реже раз в 5 лет, фактически, наверно, чаще. Большая вероятность, что поляки производили его самостоятельно. Т.о. есть вероятность, что блоки могли меняться (как я и описывал ситуацию с ремонтами. Блок состоит из нескольких печатных плат (судя по фото). Обычно переставляют платы, "собирая" один "гроб" из нерабочих плат (правда, не всегда так возможно, что впрочем не исключает обратное в данном случае), который потом уже можно и отправить в капиталку, а не отправлять в ремонт при каждом чихе).

2. Как я уже писал, состояние памяти представляет собой "срез" последних записанных туда значений. Первоначально по пункту данных по VOR, DME я предположил, что они представляют собой "срез" на одно и тоже время. Но, увидев, что последний зафиксированный VOR маяк - витебский, и он очевидно зафиксирован в последнем полете, и поскольку никаких данных по азимуту и дальности от этого маяка в этом полете получить было невозможно (аэропорт не работал в субботу), то эти данные остались от какого-то другого маяка. Точно также и во втором канале. Т.е. нельзя достоверно утверждать о связи между ID маяка и теми данными курса и дальности, что на первый взгляд "приписаны" к нему.

Но казус, безусловно, очень занятный.

UP
А, ну и - да (написал выше):

3. Поскольку маяки предназначены, чтобы вносить реальную поправку в теоретический расчет, то данные по удалению и дальности - реальные, а не теоретические.
Edited 2012-11-09 10:56 (UTC)

[identity profile] flanker20.livejournal.com 2012-11-09 11:22 am (UTC)(link)
///Если предположить, что - "от точки к точке", то для выполнения плана, очевидно, такие шараханья совершенно ни к чему. В таком случае эти "нажимания" служили какой-то другой цели.///

Эти "нажимания" были отмененными попытками редактирования флайт-плана с целью добавления в него новых вэйпойнтов. Отсюда и вопрос: кто и почему ковырялся во флайт-плане не согласовывая свои действия с командиром/др.членами экипажа? Или вернее: почему на записи разговоров нет этого согласования?

///Или вообще (к чему я склоняюсь) - штурманское "любопытство"///

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


Пункт 2, пожалуй, очень близок к истине.

[identity profile] askepak.livejournal.com 2012-11-09 01:56 pm (UTC)(link)
> Во-первых, вряд ли он не был знаком с этой штуковиной.

Знакомили. Но "пощупать" на практике всегда хочется.

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

Может, логи "кнопок" пишутся общие?

Ладно... малоперспективно что-либо выяснить по этому вопросу.

> Пункт 2, пожалуй, очень близок к истине.

И первый - тоже. Вряд ли что мешало полякам там лазить, мало того - замена и.п. - насущная необходимость, каждый раз приглашать представителей фирмы - нереально.
Edited 2012-11-09 14:00 (UTC)

[identity profile] flanker20.livejournal.com 2012-11-15 12:19 pm (UTC)(link)
///Ладно... малоперспективно что-либо выяснить по этому вопросу.///

Точно. Без разговора со специалистами разработчика системы это бессмысленно.