Я бы не стал смотреть на эти графики. Не то качество. Можно прийти к ложным выводам.
Волею судьбы у меня была возможность сравнить рабочие графики по одной катастрофе и то, что попало в отчет. Небо и земля.
Я бы не стал смотреть на эти графики. Не то качество. Можно прийти к ложным выводам.Но смотрим график
Другое разрешение. Тот же график, но на формате А0х3 а не А4. Не испорченный масштабированием.Линии другого цвета? WinArm-ом точки исправляли?
Но ведь там и величины указаны тех или иных параметров - нет необходимости пальцем по линиям водить.Я бы не стал смотреть на эти графики. Не то качество. Можно прийти к ложным выводам.
Вносить изменения "на лету" и не отображать их в эксплуатационной документации - нормальная практика, даже в древности. Морщить лоб, не имея действующих исходников софта, (и, в случае непоняток, машинного кода) - пустая трата времени. Этим сейчас занимается МАК.Но ведь там и величины указаны тех или иных параметров - нет необходимости пальцем по линиям водить.
Но в любом случае - БРУ "на себя" была отклонена и РВ должен был следовать за ней пока αLIMIT не будет достигнут. И только по достижению αLIMIT РВ уже слушался бы не пилотов, а систему защиты. Косвенное подтверждение того что показания ДУА не превысили αLIMIT - не сработала защита по αFLOOR. А ведь αFLOOR меньше αLIMIT.
Рисунок из РЛЭ, который комиссия в ПО использует:Вносить изменения "на лету" и не отображать их в эксплуатационной документации - нормальная практика, даже в древности. Морщить лоб, не имея действующих исходников софта, (и, в случае непоняток, машинного кода) - пустая трата времени.
Я так понимаю что просто график что за чем следует. А вот какие цифры и какие погрешности к этим цифрам, это внутри кодов надо смотреть.Думаю это из действующей ревизии? Или что то поменялось но МАК использует для отчета старую ревизию?
Недавние мои сообщения именно на этом основаны.
Так вопрос даже не в цифрах! Как раз пишу о том что, когда и как должно сработать и сравниваю с тем что видим в отчете.Я так понимаю что просто график что за чем следует. А вот какие цифры и какие погрешности к этим цифрам, это внутри кодов надо смотреть.
Сбой был из-за убогости алгоритмов и их реализации. Вопрос разделения факторов влияющих на работу автоматики классическая задача. Основная суть в том, чтобы разные процедуры работали строго тогда, когда это нужно при любых комбинациях входных параметров. Вот оно, чем дальше в лес, тем все грустнее и грустнее.Мне все же кажется, что там на программном уровне был конфликт между защитами по оверспиду и уа. Отсюда и некоторая неадекватность в их работе. Где-то там в алгоритмах был сбой из-за странных входных данных.
А какие конкретно вопросы по подготовке экипажей?Возникли вопросы и к подготовке в современных условиях летных экипажей,
почему нигде не мелькает сведения о команде ПРЕДУПРЕЖДЕНИЕ: NAV AoA DISAGREE (предусмотрено " СУХОЙ летное руководство RRJ-95, 3.10.34стр6), а ведь рассогласования по углам атаки в приведенных в Отчёте двух событиях куда были больше допустимых 2,5 градуса.
Не предовратило бы.Срабатывание Предупреждения о несоответствии АоА по моему предотвратило в обеих случаях взлеты в Луховицах.
Есть.А что с записью переговоров пилотов , очем говорили есть перед крушением ?
А Вы понимаете разницу между "особым случаем в полёте" и повседневной рутиной на исправной машине?
абсолютно не согласен. Это "некачественное" конструкция. Событие было уже заложено конструкторами.Последствия неисправности, а причины неисправности известны - некачественное ТО.
это, извините, игра слов.Под "обычным" наверное имелся в виду отказ, который не тянет на авиационный инцидент.
Предлагаете совсем не делать самолеты? Потому что как ни делай, некачественное ТО самолет испортит.абсолютно не согласен. Это "некачественное" конструкция. Событие было уже заложено конструкторами.
Вот Чеховское ружьё и выстрелило. "некачественное ТО" лишь ускороило цепь событий.