Comments 153
А у нас датчики направления силой в ракеты суют, аж следы остаются. В любой системе слабое звено — человек
Вы умеете управлять самолетом?
Да
Почтенно! А где учились? Слышал летные права получать долгая песня и дорогое удовольствие.
Это довольно длинная история, и я не уверен, что здесь правильное место обсуждать данную тему.
Насчет сроков и денег — в зависимости от типа пилотского свидетельства и полученных рейтингов, стоимость и время, затраченные на это, могут отличаться в десятки раз.
Насчет сроков и денег — в зависимости от типа пилотского свидетельства и полученных рейтингов, стоимость и время, затраченные на это, могут отличаться в десятки раз.
Как раз в начале осени узнавал про права на самолет. Обучение для получения свидетельства пилота любителя стоит 190000 рублей (обучение идет на самолете Бекас Х32). Налетать надо не менее 17 часов для сдачи экзамена.
А какой именно пилот? Частный, коммерческий или линейный?
Линейный
Требования к линейным пилотам в России (ФАВТ-СЛП)
1. Пилот должен иметь налёт не менее 1500 часов, в который засчитывается не более 100 часов налёта на тренажёре. Для пилота вертолёта требования по налёту установлены в размере 1000 и 100 часов соответственно.
2. Пилот самолёта должен иметь не менее 500 часов налёта в качестве командира воздушного судна (КВС) под наблюдением (только для самолётов). Или 250 часов налёта в качестве КВС. Или 70 часов налёта в качестве КВС и 180 часов — в качестве КВС под наблюдением.
3. Пилот самолёта должен иметь 200 часов налёта, выполняя полёты по маршруту. Из них 100 часов — в качестве командира воздушного судна или в качестве КВС под наблюдением.
4. Пилот должен иметь не менее 75 часа налёта по приборам из которых не более 30 часов — на тренажёре (для самолётов). Для пилотов вертолётов 30 и 10 часов соответственно.
5. Пилот должен иметь 100 часов налёта ночью (для самолётов) или 50 часов (для вертолётов) в качестве КВС или второго пилота.
Почет.
1. Пилот должен иметь налёт не менее 1500 часов, в который засчитывается не более 100 часов налёта на тренажёре. Для пилота вертолёта требования по налёту установлены в размере 1000 и 100 часов соответственно.
2. Пилот самолёта должен иметь не менее 500 часов налёта в качестве командира воздушного судна (КВС) под наблюдением (только для самолётов). Или 250 часов налёта в качестве КВС. Или 70 часов налёта в качестве КВС и 180 часов — в качестве КВС под наблюдением.
3. Пилот самолёта должен иметь 200 часов налёта, выполняя полёты по маршруту. Из них 100 часов — в качестве командира воздушного судна или в качестве КВС под наблюдением.
4. Пилот должен иметь не менее 75 часа налёта по приборам из которых не более 30 часов — на тренажёре (для самолётов). Для пилотов вертолётов 30 и 10 часов соответственно.
5. Пилот должен иметь 100 часов налёта ночью (для самолётов) или 50 часов (для вертолётов) в качестве КВС или второго пилота.
Почет.
Это круто. Убойная бюрократия и жесточайший вотерфол… — я бы застрелился.
Эпическая сила… Спасибо Вам за мою новую фобию — летать самолётами.
Спасибо мне за мою привычку сначала читать несколько комментов, а потом статью.
Да не переживайте так — в авиации такое количество уровней защиты, то нарушение одного-двух из них практически не снижает общий уровень безопасности.
Что мешало в этом вашем FADEC'е быть закомментированным другому куску коду — на этот раз критическому? Чем бы помогло то что этих FADEC'ов по 2 штуки на двигатель, если прошивки у них одинаковые?
Понятно, что 100% гарантии не даст вообще никто. Но даже в таком случае (если очень важный кусок кода закомментирован, и при этом проблема не проявила себя на более ранних этапах) есть большая вероятность, что FADEC перейдет в особый режим (такое в нем предусмотрено) и будет обеспечивать минимальную функциональность работы двигателя.
Ну и не забывайте, что один работает, а второй — только «слушает», т.е. в одно и то же время они выполняют разные куски программы.
А вообще — кто его знает, я не считаю себя знатоком всех нюансов работы ПО FADEC, просто более-менее представляю все это с точки зрения «продвинутого пользователя».
Ну и не забывайте, что один работает, а второй — только «слушает», т.е. в одно и то же время они выполняют разные куски программы.
А вообще — кто его знает, я не считаю себя знатоком всех нюансов работы ПО FADEC, просто более-менее представляю все это с точки зрения «продвинутого пользователя».
Более того, даже если один двигатель перестанет работать, то самолет легко сможет долететь до аэродрома и приземлиться.
Да даже если два двигателя откажут, то у самолета есть третий :) вспомогательный (научно: вспомогательная силовая установка). И тогда с ним спокойно долетит до аэродрома
Да даже если все три двигателя откажут, самолет может планировать несколько часов, этого легко хватит, чтобы долететь до ближайшего аэродрома
Да даже если…
Короче, чтобы разбить современный самолет, это надо очень и очень постараться.
Да даже если два двигателя откажут, то у самолета есть третий :) вспомогательный (научно: вспомогательная силовая установка). И тогда с ним спокойно долетит до аэродрома
Да даже если все три двигателя откажут, самолет может планировать несколько часов, этого легко хватит, чтобы долететь до ближайшего аэродрома
Да даже если…
Короче, чтобы разбить современный самолет, это надо очень и очень постараться.
Скажите, насчет ВСУ и планирования несколько часов — Вы это серьезно ???
Про несколько часов перестарался.
Но случаи успешной посадки с отказавшими двигателями есть: Планер Гимли
Но случаи успешной посадки с отказавшими двигателями есть: Планер Гимли
Очень надеюсь, что насчет ВСУ тоже пошутили. На всякий случай — ВСУ предназначена, в первую очередь, для обеспечения самолета электричеством и сжатым воздухом (для кондиционеров) на земле, чтобы не использовать для этого двигатели. Ну, еще как вспомогательный источник того же самого (электрика и воздух) в полете, не более того. Тяги ВСУ недостаточно даже для ничтожного изменения поведения самолета в полете.
Вот поэтому ПО должно сертифицироваться гораздо жестче, чем железо. Ведь в основе резервиорования заложено функционирование в случае апаратного отказа в одном из блоков. А если случается лажа по причине багов в ПО (например деление на 0), то при переключении на резервный блок такая же лажа случится и в нем с очень большой вероятностью.
Ну кроме жестких 100% повторяемых ошибок, есть еще «плавающие» ошибки и накапливающиеся ошибки. High Availability системы, как раз такие же, со вторым резервным сервером, такие ошибки «подавляют». Пока первый сервер в дауне, перегружается, второй отвечает на запросы.
Было бы интересно если бы для этого управляющий софт писался бы сразу в двух независимых друг от друга версиях, которые бы разговаривали по общему протоколу. Тогда была-бы какая-то надежда, что тупой баг в одной из версий не воспроизведется в другой.
Мне кажется невероятным, чтобы для достаточно сложного софта удавалось поддерживать соответствие обеих версий одним и тем же требованиям — при этом сохраняя независимость этих версий.
Посмотрите для примера на «совместимость» MSO и OOo
Посмотрите для примера на «совместимость» MSO и OOo
Вообще в ответственных местах так и делается. И не в двух а в трех. Притом что различается не просто версия а используемый язык программирования и аппаратная начинка. При этом, коллективы, пишущие эти части, так же не пересекаются.
Применяется иногда.
Например в одном из самолетов стоит 5 дисплеев, два из кторорых разрабатываются по уровню A, остальные по уровню B (как менее критические).
Железо там тоже разное.
Но требования… хоть документы и разные, они пересекаются почти 100% и все обновления ПО делаются параллельно в обоих ветках, причем зачастую одновременно и одними и теми же людьми.
Т.е. если будет придуман некий глючный алгоритм, то с вероятностью 99% он попадет в обе ветки ПО.
Причина такого разделения именно в том самолете мне не ясна.
Или хотели как лучше, а получилось — как всегда. Или пытались сэкономить на железе уровня A. Или от того, что дисплеев 5 (а не 4), не хватило каналов Arinc чтоб все их подключить с доблированием линий.
Например в одном из самолетов стоит 5 дисплеев, два из кторорых разрабатываются по уровню A, остальные по уровню B (как менее критические).
Железо там тоже разное.
Но требования… хоть документы и разные, они пересекаются почти 100% и все обновления ПО делаются параллельно в обоих ветках, причем зачастую одновременно и одними и теми же людьми.
Т.е. если будет придуман некий глючный алгоритм, то с вероятностью 99% он попадет в обе ветки ПО.
Причина такого разделения именно в том самолете мне не ясна.
Или хотели как лучше, а получилось — как всегда. Или пытались сэкономить на железе уровня A. Или от того, что дисплеев 5 (а не 4), не хватило каналов Arinc чтоб все их подключить с доблированием линий.
Таки были испытательные полеты типа, совсем явные ляпы в них должны были вылезти.
Убил тот факт, что не утром прислали патч или пару новеньких свежепрошитых FADEC, а повесили все это на читателей FAQ. И когда очередная футбольная команда затормозит колеса до отрыва, снова дело будет не в бобине, а кто сидел в кабине…
Еще очень удивила экономия ресурса механизма выпуска шасси. Он там какой то особый? Я бы понял про сами колеса, про механизм торможения, но уборка? И что, на бизнесджете нет ограничения по скорости полета с неубранными шасси?
Убил тот факт, что не утром прислали патч или пару новеньких свежепрошитых FADEC, а повесили все это на читателей FAQ. И когда очередная футбольная команда затормозит колеса до отрыва, снова дело будет не в бобине, а кто сидел в кабине…
Еще очень удивила экономия ресурса механизма выпуска шасси. Он там какой то особый? Я бы понял про сами колеса, про механизм торможения, но уборка? И что, на бизнесджете нет ограничения по скорости полета с неубранными шасси?
Таки были испытательные полеты типа, совсем явные ляпы в них должны были вылезти
Очевидно, они и вылезли, но не все… Более-менее ситуация с подобными вещами устаканилась ближе к концу 2016 года, когда накопился довольно приличный опыт эксплуатации данной модели в «реальной жизни».
Убил тот факт, что не утром прислали патч или пару новеньких свежепрошитых FADEC
Я же в самом конце статьи об этом писал — изменения прошивки FADEC занимают очень много времени из-за сертификации. В реальности, если правильно помню, года через два обновили…
И что, на бизнесджете нет ограничения по скорости полета с неубранными шасси?
Естественно, есть — а какая проблема с выдерживанием нужных скоростей в зависимости от конфигурации?
А вот именно после этого и у меня фобия начала где-то зарождаться… :)
практически всегда в любом более-менее большом самолете что-то неисправно
Года три назад летел на MD 80. Достаточно древнее изобретение. Сидел как раз над крылом. Практически сразу после взлета на крыле из под лючка с надписью Fuel Pump стала подтекать жидкость. Ручеек со временем только усиливался. Вызвали стюардессу, на мои замечания что у нас течет топливо, она отморозилась, сказав что это конденсат. Ага, из под герметичного лючка. Ну а что она еще могла сказать? А тем временем ручеек достиг конца крыла и стал распыляться в воздухе… Затем кол-во ручейков увеличилось. В процессе полета стюардесса еще пару раз подходила с каким-то членами экипажа, показывая им происходящее, потом подходил командир экипажа, просил не разводить панику, «Ничего страшного, это не топливо, долетим нормально»… Перед снижением, как только сбросили обороты двигателей, ручеек сразу иссяк, будто перекрыли кран, все в момент высохло, только остался след на крыле и осадочек в душе.
лючка с надписью Fuel Pump
А зачем лючку с надписью «топливный насос» быть герметичным?
Думаю, что с очень большой вероятностью это действительно был конденсат. Для начала, лючки, о которых Вы говорите, не герметичные. Под ними действительно скапливается конденсат, это совершенно нормально.
Если бы действительно было реальное подозрение на утечку топлива, то даже самый «отмороженный» экипаж совершил бы аварийную посадку, и на земле самолет ждала бы аварийная команда с пожарными машинами.
Поверьте — подавляющее большинство вещей, которые во время полета для не-авиационных людей кажутся странными или опасными, на самом деле являются совершенно обыденными, нормальными и безопасными. Мало того, даже для людей, имеющих авиационное образование, но не обладающих в ей полнотой информации, очень часто невозможно достоверно решить, что именно происходит в том или ином случае — то ли самолет вот-вот взорвется в воздухе, то ли через мгновенье совершит нормальную посадку. Именно поэтому я всегда не любил некоторых великих авиационных деятелей-экспертов, которые для попадания на экран телевизора или газетную страницу с умным видом несут разную чушь и собственные измышления по поводу событий, о которых они не имеют никакой достоверной информации.
Если бы действительно было реальное подозрение на утечку топлива, то даже самый «отмороженный» экипаж совершил бы аварийную посадку, и на земле самолет ждала бы аварийная команда с пожарными машинами.
Поверьте — подавляющее большинство вещей, которые во время полета для не-авиационных людей кажутся странными или опасными, на самом деле являются совершенно обыденными, нормальными и безопасными. Мало того, даже для людей, имеющих авиационное образование, но не обладающих в ей полнотой информации, очень часто невозможно достоверно решить, что именно происходит в том или ином случае — то ли самолет вот-вот взорвется в воздухе, то ли через мгновенье совершит нормальную посадку. Именно поэтому я всегда не любил некоторых великих авиационных деятелей-экспертов, которые для попадания на экран телевизора или газетную страницу с умным видом несут разную чушь и собственные измышления по поводу событий, о которых они не имеют никакой достоверной информации.
Ок, пусть не топливо, но почему при сбросе оборотов двигателя течь сразу прекратилась? И почему оно текло весь полет, а это чуть более чем 3,5 часа перелета.
В инете нашел описание этого явления, мол, если баки полны (топлива больше какого-то там объема) то на высоте из-за низкого давления топливо может (не знаю как правильно перевести с англ.) подсасывать из бака и оно может стекать по крылу «пугая пассажиров». www.pprune.org/archive/index.php/t-340199.html
Ну и со второго крыла оно не текло. Вообщем не претендую на то, что это именно топливо, просто описал как все было. Хотя зная положение дел в авиации у нас в Украине и компанию Роза Ветров…
В инете нашел описание этого явления, мол, если баки полны (топлива больше какого-то там объема) то на высоте из-за низкого давления топливо может (не знаю как правильно перевести с англ.) подсасывать из бака и оно может стекать по крылу «пугая пассажиров». www.pprune.org/archive/index.php/t-340199.html
Ну и со второго крыла оно не текло. Вообщем не претендую на то, что это именно топливо, просто описал как все было. Хотя зная положение дел в авиации у нас в Украине и компанию Роза Ветров…
А у меня другой случай недавно был: у Embraer при снижении из края крыла начал струиться белый дым. Причем не из двигателя, а именно из крыла. Никогда такого раньше не видел — что это могло быть?
«и остался влажный след в морщине
старого MD80»
а вообще поздравляю, что все обошлось
старого MD80»
а вообще поздравляю, что все обошлось
А вот страшилка на тему разработки встраиваемых систем в автомобилях: Качество встраиваемого ПО или погром всё-таки случился.
ещё один пример который показывает, что ПО отвечающее за безопасность должно быть с открытым исходным кодом.
какой то школяр под маркой проприетарного ПО делает позор, который гробит не одну жизнь, компания платит многомиллионные штрафы и иски, а нужно было всего лишь открыть код и им бы сразу эту рецензию выдали. Жаль, что через одно место пишется софт отвечающий за достаточно серъёзное оборудование и проверить то это могут только после серъёзного разбирательства…
(даю дословный перевод) «это позорный образец проектирования и разработки ПО».
какой то школяр под маркой проприетарного ПО делает позор, который гробит не одну жизнь, компания платит многомиллионные штрафы и иски, а нужно было всего лишь открыть код и им бы сразу эту рецензию выдали. Жаль, что через одно место пишется софт отвечающий за достаточно серъёзное оборудование и проверить то это могут только после серъёзного разбирательства…
не могу не дописать, дабы народ ленящийся ходить по ссылкам понимал о чём я
экспертиза выявила… одиннадцать тысяч глобальных переменных. Код реализации firmware назван хорошо знакомым всем программистам словом «spaghetti». Анализ цикломатической сложности программы выдал 67 не пригодных для тестирования функций, а ключевая функция определения угла дроссельной заслонки в ходе этого анализа показала какую-то удивительную оценку, при которой не только тестирование, но и вообще какое-либо сопровождение программы невозможно. Соблюдение отраслевого стандарта кодирования (для автомобильной промышленности такой есть, даже целое семейство, совокупно называемое MISRA) характеризуется выявленным числом его нарушений — их набралось 80 тысяч (в Toyota принят свой внутренний стандарт, который заимствует из MISRA всего 11 правил, при минимально требованных во время написания кода 93-х). По ходу дела было выявлено, что в такой сложной системе полностью отсутствует учёт сбоев и ошибок. При всём этом великолепии все связанные с безопасностью функции контроллера в его «прошивке» оказались реализованными одним единственным процессом.
Прочитав про 11 тысяч глобальных переменных, стал сомневаться в том, что статья основана на реальных событиях. Ибо уж слишком это как-то, особенно для в общем-то простого блока. Попахивает жареным.
Так как я в части автомобилей являюсь всего лишь непродвинутым пользователем, то не собирался это комментировать. Но сейчас не удержался и решил добавить — мне тоже очень сильно кажется, что тут совсем не так все на самом деле, как преподносится. Скорее всего, это просто самое банальное вымогательство денег из крупной компании, которой проще откупиться, чем спорить. Если я не ошибаюсь (хотя вполне мог что-то перепутать), то весь этот процесс возглавлял некий юрист, который специализируется на подобных исках. Причем он сам стал жертвой одной из этих 11 тысяч переменных. Только вот перед тем, как пожертвовать собой, он (очевидно, предчувствуя неладное), назначил небольшую пресс-конференцию, к началу которой он как раз справился с внезапно разбушевавшимся автомобилем. И еще представляет интерес запись его разговора со службой 911 во время того, как он «пытался» остановить мчащийся сам по себе автомобиль — например, почему-то он так и не выполнил рекомендации службы, оператор которой просил нажать на педаль тормоза (ну и т.д.).
грешным делом, не могли ли выдать на экспертизу какую-нибудь обфусцированную версию? Из серии «лучше потерять лицо, чем алгоритмы»?
Текст по ссылке слишком желтый.
Например, "немаленький pdf-файл" на деле — 6ти страничный документ.
Далее, в цитируемой статье:
Ссылка в цитате соответствует таковой на сайте статьи. Это официальный отчёт по анализу firmware (http://pressroom.toyota.com/article_download.cfm?article_id=3597).
Упоминания 11 тысяч глобальных переменных там не обнаружил. Результаты анализа кода firmware не то чтобы ужас-ужас, но даже не ужас. Может быть, уважаемый SVlad, активно пиарящий эту ссылку (раз, два, три) после того, как она была приведена в этой ветке и в соседней до него, приведет цитату из данного pdf, указанного, как первоисточник?
Например, "немаленький pdf-файл" на деле — 6ти страничный документ.
Далее, в цитируемой статье:
Что подтверждается здоровенным прошлогодним тематическим документом от самой Toyota (большой pdf-файл, только для любителей hardcore подробностей, он интересен потому что демонстрирует прошлогодние объяснения).
Ссылка в цитате соответствует таковой на сайте статьи. Это официальный отчёт по анализу firmware (http://pressroom.toyota.com/article_download.cfm?article_id=3597).
Упоминания 11 тысяч глобальных переменных там не обнаружил. Результаты анализа кода firmware не то чтобы ужас-ужас, но даже не ужас. Может быть, уважаемый SVlad, активно пиарящий эту ссылку (раз, два, три) после того, как она была приведена в этой ветке и в соседней до него, приведет цитату из данного pdf, указанного, как первоисточник?
Этот пример даёт мне большее осознание того, для чего я вот как раз на авиастроительном изучаю программирование, хотя я софт писать и не собирался :-)
Спасибо, интересно было почитать.
Спасибо, интересно было почитать.
Это вообще нормально, что блок управления двигателем выключает реверс в зависимости от состояния тормозов. По-моему, это как если бы база данных сайта не стала выполнять запрос, потому что решила что пароль пользователя скомпрометирован. Какая странная архитектура.
А если блок выключит реверс на земле, после того, как он уже был включен, и только для половины двигателей на одном из крыльев?
А если блок выключит реверс на земле, после того, как он уже был включен, и только для половины двигателей на одном из крыльев?
Ну это логично. Если тормоза слева не работают, то справа надо отключить реверс, чтобы скомпенсировать усилие.
Нелогично то, что блок управления реверсом вообще никак не связан с реальными тормозами, а смотрит в случайное время на скорость вращения колёс. Было бы правильнее, если бы он отслеживал ту самую скорость, например, не когда ему вздумается, а по сигналу «активирован тормоз».
Вопрос был в том, почему блок управления двигателем вообще занимается состоянием тормозной системы. Это решение должно приниматься уровнем выше. Собственно в программировании, такие вот межблочные «горизонтальные» связи означают т.н. «code smell». Так же как и с тем, что какие то системы проверяют датчик в шасси, чтоб узнать на земле самолет или нет, они у центрального компьютера должны были спросить «на земле мы или нет», а не «какой сигнал дает датчик id=XXX».
Ох, не нужно мне было это вообще начинать… В статье я специально написал, что «буду разъяснять только самое необходимое, причем чаще всего в упрощенном виде», а также упомянул о «небольшом документ размером в одиннадцать с чем-то тысяч страниц (краткая выдержка их техдокументации по самолету)».
Повторяю — эти одиннадцать тысяч с чем-то страниц — только выжимки из документации. Логика работы систем, и особенно их связи друг с другом в реальности сложнее на порядки, чем смог описать здесь я. То, что на поверхности кажется не совсем логичным, при внимательном изучении оказывается (в подавляющем большинстве случаев) очень продуманным и уходящим намного глубже, чем изначально казалось.
Я мог бы попытаться объяснить на конкретном примере с датчиком колеса на земле, но это потребует вводной части еще на несколько страниц, да и возникнет куча других вопросов аналогичного плана. Еще не забывайте, что везде предусмотрены альтернативные пути прохождения информации и принятия решений, причем базирующихся на разных наборах исходных данных.
Либо поверьте мне на слово, либо (если действительно ОЧЕНЬ интересно) попробуйте найти в интернете что-то типа «aircraft operational manual — systems description» для любого современного самолета транспортной категории, и попробуйте внимательно его прочитать — узнаете много любопытного и неожиданного.
Вообще у меня самого раньше (когда изучал первые более-менее сложные самолеты) мысль работала приблизительно в такой последовательности (по мере понимания какого-то решения):
1. Зачем они так сделали?
2. А, все понятно, нормально!
3. Не, подождите, а если вот такое произойдет?
4. Секунду, зачем это вообще нужно было ???
5. Не может быть, чтобы и это учли!
6. Ну ничего себе… Как вообще можно было это все так тщательно и глубоко продумать ???
Сейчас уже немного привык, и стараюсь не делать скоропалительных выводов — пытаюсь вникнуть в самую суть решений, а не в их легко видимую «пользовательскую» сторону.
Повторяю — эти одиннадцать тысяч с чем-то страниц — только выжимки из документации. Логика работы систем, и особенно их связи друг с другом в реальности сложнее на порядки, чем смог описать здесь я. То, что на поверхности кажется не совсем логичным, при внимательном изучении оказывается (в подавляющем большинстве случаев) очень продуманным и уходящим намного глубже, чем изначально казалось.
Я мог бы попытаться объяснить на конкретном примере с датчиком колеса на земле, но это потребует вводной части еще на несколько страниц, да и возникнет куча других вопросов аналогичного плана. Еще не забывайте, что везде предусмотрены альтернативные пути прохождения информации и принятия решений, причем базирующихся на разных наборах исходных данных.
Либо поверьте мне на слово, либо (если действительно ОЧЕНЬ интересно) попробуйте найти в интернете что-то типа «aircraft operational manual — systems description» для любого современного самолета транспортной категории, и попробуйте внимательно его прочитать — узнаете много любопытного и неожиданного.
Вообще у меня самого раньше (когда изучал первые более-менее сложные самолеты) мысль работала приблизительно в такой последовательности (по мере понимания какого-то решения):
1. Зачем они так сделали?
2. А, все понятно, нормально!
3. Не, подождите, а если вот такое произойдет?
4. Секунду, зачем это вообще нужно было ???
5. Не может быть, чтобы и это учли!
6. Ну ничего себе… Как вообще можно было это все так тщательно и глубоко продумать ???
Сейчас уже немного привык, и стараюсь не делать скоропалительных выводов — пытаюсь вникнуть в самую суть решений, а не в их легко видимую «пользовательскую» сторону.
Из под Вашего пера, 11 тысяч страниц можно было бы прочитать за пару вечеров :-)
Вы название самолета просто не приводите, из-за того, что это просто не важно или это запрещено?
Вы название самолета просто не приводите, из-за того, что это просто не важно или это запрещено?
Спасибо за комплимент, но я не уверен, что готов породить 11 тысяч страниц даже за пару лет, не говоря уже о паре вечеров…
Считаю, что название производителя в данном случае совершенно несущественно — данный случай не является особенностью конкретной компании, у других я видел вещи намного похлеще, просто они не соответствуют тематике Хабра.
Считаю, что название производителя в данном случае совершенно несущественно — данный случай не является особенностью конкретной компании, у других я видел вещи намного похлеще, просто они не соответствуют тематике Хабра.
По-моему, название самолёта совершенно очевидно и так любому, кто хоть чуть-чуть интересуется авиацией. Бьюсь об заклад, что это начинающийся на S.
К разработке самолета на S привлекались специалисты Boeing, потому отступление про «не знаю как на последних A и B» либо деза, либо странно.
ru.wikipedia.org/wiki/SaM146
там новый двигатель, сильно отличающийся от Boeng и Airbus
там новый двигатель, сильно отличающийся от Boeng и Airbus
Оно и видно, насколько «все так тщательно и глубоко» продумано, что логи вам пришлось снимать на видеокамеру и вручную переписывать.
Одним из решающих факторов было время, вернее — его отсутствие. Можно было потерять лишний день — два, дождаться соответствующих специалистов, которые выгрузили бы всю эту информацию правильным способом. Либо вообще получили бы прямо из недр самолета уже готовый ответ.
Мне это время терять не хотелось, поэтому пришлось придумать такой корявый обходной путь.
Мне это время терять не хотелось, поэтому пришлось придумать такой корявый обходной путь.
Недавно летел на А320 в аварийном ряду — специально продуманы даже такие детали как:
1. Крепеж откидного столика — вращающаяся ручка фиксируется в вертикальном положении, упираясь в штырь, дополнительно зацепляясь за маленький выступ. Чтобы при эвакуации никто локтем вперед не толкнул и столик не открылся.
2. Инструкция по открыванию аварийного люка наклеена так, что часть на защитном лючке, часть на самой двери. Если сорвать лючок — останется видна ровно та часть картинки, которая нужна уже после срывания лючка.
Везде бы так все проектировали))
1. Крепеж откидного столика — вращающаяся ручка фиксируется в вертикальном положении, упираясь в штырь, дополнительно зацепляясь за маленький выступ. Чтобы при эвакуации никто локтем вперед не толкнул и столик не открылся.
2. Инструкция по открыванию аварийного люка наклеена так, что часть на защитном лючке, часть на самой двери. Если сорвать лючок — останется видна ровно та часть картинки, которая нужна уже после срывания лючка.
Везде бы так все проектировали))
В автомобиле БК тоже управляет двигателем в зависимости от тормозов и от пробуксовки колес и от кучи других параметров.
Во во!!!
И тупит при этом некисло.
Так в повороте на снегу с пробуксовкой он всегда отрубает подачу топлива и обороты падают и как итог машину несет в отбойник. Хотя мне вот например пробуксовка и нужна была ну и т д.
Просто получается что он как бы знает лучше как управлять и помогает тебе в этом, но в реальности как правило от помощи этой только хуже.
И тупит при этом некисло.
Так в повороте на снегу с пробуксовкой он всегда отрубает подачу топлива и обороты падают и как итог машину несет в отбойник. Хотя мне вот например пробуксовка и нужна была ну и т д.
Просто получается что он как бы знает лучше как управлять и помогает тебе в этом, но в реальности как правило от помощи этой только хуже.
А если их два, то как они решают кто не прав? Если три то понятно, а с двумя вообще не понятно. Ну разные показания у них получились, и?
Round Robin… эээ, то бишь камень-ножницы-бумага :)
Где-то слышал старинную, кажется, голландскую поговорку: «Выходя в море, бери или один хронометр, или три».
Знакомый, служивший на каком-то ракетном комплексе, типа С300 в его первые годы эксплуатации, рассказывал, что там как раз использовалось 3 БК, работали параллельно, и если у кого-то результаты обсчета не совпадали, то он тупо исключался из работы, не знаю, временно или постоянно.
Здесь же, как я понял, второй вычислитель тупо на подхвате, видимо, считается, что и одного вполне достаточно и вполне надежно, а второй просто потому, что резерв обязателен.
Знакомый, служивший на каком-то ракетном комплексе, типа С300 в его первые годы эксплуатации, рассказывал, что там как раз использовалось 3 БК, работали параллельно, и если у кого-то результаты обсчета не совпадали, то он тупо исключался из работы, не знаю, временно или постоянно.
Здесь же, как я понял, второй вычислитель тупо на подхвате, видимо, считается, что и одного вполне достаточно и вполне надежно, а второй просто потому, что резерв обязателен.
Поговорка норвежская, слышать вы ее могли в «Мистическом человеко-месяце».
Вспомнились компьютеры Evangelion с именами трёх волхвов:
Это называется "троирование" и "мажоритарная логика". Объединение 3 систем может быть на разных уровнях, вплоть до совсем железного, например, 3 гидроцилиндра, и 2 могут "пересилить" несогласного с ними третьего и повернуть уже этот флюгер.
Ну и логические элементы в микросхемах соответствующие бывают, так и называется, мажоритарный элемент с 3 входами. Таблицу истинности для него несложно составить.
Снимает показания всегда один, а второй следит за тем, что у первого все ок. Скорее всего контролирующий заберет управление, только если у первого нарушится его работа (а не работа двигателя)
В случае двух блоков должна быть схема контроля, которая сама ( а не блоки ) принимает решение, кто неправ. Либо используется вариант, что второй блок висит в горячем резервировании и по сигналу error от первого подхватывает управление. Хотя я бы поставил три блока и схему мажоритарного резервирования — тупее и намного надежнее.
себестоимость около 5 тысяч долларов в час
А из чего складывается такая величина? И это постоянно, или в тестовый период она больше, чем будет при нормальной эксплуатации?
Наверное, в обычной жизни меньше, т.к. не нужно дополнительное слежение и присутствие лётчика-испытателя.
Цифра была очень приблизительная, причем для штатных полетов. В зависимости от ряда параметров, она может плавать раза в два. Стоимость работы пилотов близка к ошибке округления.
Как-то всё равно не стыкуется.
Пассажирский перелёт со ста пассажирами дешёвой авиакомпанией — это порядка $150 за пару часов с каждого, т.е. $15K за полёт, т.е. $7.5K / час.
Эта сумма включает зарплаты пилотов, стюардесс, всех сотрудников аэропорта, затраты на маркетинг и т.п. — на всё про всё остаётся $2.5K?
А ведь наверняка эксплуатация «Боингов» ещё дороже, чем вашего бизнес-джета: как минимум он тяжелее, значит и топлива больше сжигает.
Пассажирский перелёт со ста пассажирами дешёвой авиакомпанией — это порядка $150 за пару часов с каждого, т.е. $15K за полёт, т.е. $7.5K / час.
Эта сумма включает зарплаты пилотов, стюардесс, всех сотрудников аэропорта, затраты на маркетинг и т.п. — на всё про всё остаётся $2.5K?
А ведь наверняка эксплуатация «Боингов» ещё дороже, чем вашего бизнес-джета: как минимум он тяжелее, значит и топлива больше сжигает.
Но «боинги» везут больше пассажиров, что и делает их более экономически выгодными при полной загрузке.
Во-первых, экономика регулярных пассажирских перевозок — вещь настолько загадочная, что ее не понимают даже в самих авиакомпаниях. Именно поэтому практически все авиакомпании рано или поздно банкротятся и/или реструктуируются.
А вообще очень не люблю проводить совсем уж поверхностные аналогии, но сейчас буду вынужден это сделать (на развернутое описание нет времени). Начните с того, что посмотрите, сколько стоит часовая аренда добротного автобуса средней ценовой категории, и сравните с часовой арендой автомобиля типа топовых моделей Ferrari/Lamborghini. Понятно, что стоимость аренды не полностью отражает себестоимость эксплуатации, но определенная корреляция есть. Возможно, после этого ситуация со стоимостью самолетов станет немного понятней.
P.S. Стоимость топлива составляет 20% — 40% в стоимости летного часа.
А вообще очень не люблю проводить совсем уж поверхностные аналогии, но сейчас буду вынужден это сделать (на развернутое описание нет времени). Начните с того, что посмотрите, сколько стоит часовая аренда добротного автобуса средней ценовой категории, и сравните с часовой арендой автомобиля типа топовых моделей Ferrari/Lamborghini. Понятно, что стоимость аренды не полностью отражает себестоимость эксплуатации, но определенная корреляция есть. Возможно, после этого ситуация со стоимостью самолетов станет немного понятней.
P.S. Стоимость топлива составляет 20% — 40% в стоимости летного часа.
Очень грубо говоря, стоимость часа полета состоит из топлива и цены самолета деленной на его ресурс. Прочие расходы, как то экипаж, аэродромное и навигационное обслуживание, примерно равные для боинга и бизнес-джета.
По топливу. Маленькие двигатели очень неэкономичны. Як-40 не зря называли «истребитель керосина». Автор до кучи уточнил режим полетов — взлет/посадка, это самые расходные этапы полета и паспортный часовой расход тут не применим (два полета в час, съедят куда больше топлива чем прописано в ТТХ двигателей).
По самолету. Ресурс пассажирского боинга огромен, навскидку, примерно 10x от бизнесджета, соответственно и цена часа полета бизнесджета сравнима.
По топливу. Маленькие двигатели очень неэкономичны. Як-40 не зря называли «истребитель керосина». Автор до кучи уточнил режим полетов — взлет/посадка, это самые расходные этапы полета и паспортный часовой расход тут не применим (два полета в час, съедят куда больше топлива чем прописано в ТТХ двигателей).
По самолету. Ресурс пассажирского боинга огромен, навскидку, примерно 10x от бизнесджета, соответственно и цена часа полета бизнесджета сравнима.
Топливо, ГСМ, преиодическое обслуживание узлов (каждые XX часов полета).
А также, каждая посадка стоит денег. Например, если самолет рассчитан на X посадок (рассчетная величина и на шасси, и на планер), то каждая посадка стоит <стоимость самолета>/X.
Я думаю, что экипаж там — самое дешевое.
А также, каждая посадка стоит денег. Например, если самолет рассчитан на X посадок (рассчетная величина и на шасси, и на планер), то каждая посадка стоит <стоимость самолета>/X.
Я думаю, что экипаж там — самое дешевое.
Кто-то на YAC2012 заливал о взломе систем самолёта через гражданский ethernet в кресле. Есть подробности на тему?
Хотя могу что-то путать, возможно речь была о незащищённости системы приёма команд с земли, но и про сеть что-то было. Напомните, если кто в курсе.
Скорее всего, речь идет о Перехвате управления самолетом при помощи Android-приложения.
Недавно летел в A340-600 и там на LCD вделанных в спинку кресла была картинка загрузки ПО. Так вот, грузилось всё по протоколу XModem (думаю, многие тут ещё застали это чудо ;) на скорости 115к на COM1.
Так что наверное где-то есть Ethernet в креслах, но далеко не везде.
Копирайт на софт стоял 2002-2004. И A340-600 далеко не самый старый самолёт…
Так что наверное где-то есть Ethernet в креслах, но далеко не везде.
Копирайт на софт стоял 2002-2004. И A340-600 далеко не самый старый самолёт…
Прекрасная статья и отличный пример применения смекалки.
Если абстрагироваться от авиационной тематики, то у меня была немного похожая история.
Внезапно, на боевом хостинге одного из рабочих проектов (скучная система анкетирования для гос. организаций) внезапно проявилась странная ошибка — не прикреплялись некоторые файлы (жалобы поступали в основном на .doc файлы).
Размер значения не имел. Например архив в 8 Мб загружался, а хлюпенький.doc из одной странички — не хотел и падал по «connection lost».
Позже выяснилось, что PHP выдавал–таки ошибку 3, UPLOAD_ERR_PARTIAL, что значит — файл недозакачался.
В движке конечно ковырялись. У нас Zend Framework. Но он тут не причём. Mime типы не фильтровали и вообще собранный на коленке скрипт аплоада файлов, который не использовал фреймворки выдавал ту же ошибку. Естественно, поглядели в репозиторий на предмет последних изменений кода, который мог бы повлиять на загрузку файлов. Но в последнее время никто ничего связанного загрузкой файлов не трогал.
Следующим под подозрения попал сам сервер. Но и с ним в принципе было всё как обычно и никто не трогал настроек mime-типов или настроек веб-сервера. Далее под подозрения попал suhosin. Но и он оказался не при делах.
Мистика. Так подумал не только я, но и все, с кем я делился этой напастью.
И тут я от досады начал искать, какие же файлы не заливаются, и что у них общего. Появилась мысль, что происходит поиск некоей сигнатуры в файле, и если она встречается, то всё. Connection lost.
Обрезал у файла хвост. А он не льётся. Отрезал начало. Всё так же. А он уже 600 байт весит.
Посмотрел на эти 600 байт — и вижу, куча нулей (тех самых, которые \0) среди кучи байтов. Взял, сгоряча 75 байт нулей скормил. И опять не прошло. И вот тут то я и понял, в нулях дело. Отправляю 64 нуля подряд — всё окей, 65 и больше — не идёт. И тут я приклеил к хорошему.jpeg, который легко заливался, эти 65 байт нулей сзади. И файл перестал заливаться.
И вот теперь самое интересное. На хабре я читал статейку про атаку на dns, в которой специально сформированные tcp-пакеты запросов возвращали намного более длинные пакеты ответов, что в свою очередь дико напрягало трафик.
Возникла мысль, что всё это от излишне параноидальной настройки сетевого оборудования на стороне хостера. И трафик попросту фильтруется.
Хостеру в ТП конечно отписали. А пока он отвечал, я воспользовался услугой создания триального аккаунта у хостера (на этот раз хостинг был виндовый) и с радостью обнаружил косвенное подтверждение своей догадке. Тестовый скрипт возвращал ту же ошибку и рвал соединение при попытках загрузки файла с нулями. Однако, если загрузить файл через защищённое соединение, естественно, всё прокатывало.
Вообщем, история завершилась хэппи эндом. На следующий день всё неожиданно заработало, а спустя ещё пару дней хостер отписался, что проблема была с их стороны и уже решена.
Если абстрагироваться от авиационной тематики, то у меня была немного похожая история.
Внезапно, на боевом хостинге одного из рабочих проектов (скучная система анкетирования для гос. организаций) внезапно проявилась странная ошибка — не прикреплялись некоторые файлы (жалобы поступали в основном на .doc файлы).
Размер значения не имел. Например архив в 8 Мб загружался, а хлюпенький.doc из одной странички — не хотел и падал по «connection lost».
Позже выяснилось, что PHP выдавал–таки ошибку 3, UPLOAD_ERR_PARTIAL, что значит — файл недозакачался.
В движке конечно ковырялись. У нас Zend Framework. Но он тут не причём. Mime типы не фильтровали и вообще собранный на коленке скрипт аплоада файлов, который не использовал фреймворки выдавал ту же ошибку. Естественно, поглядели в репозиторий на предмет последних изменений кода, который мог бы повлиять на загрузку файлов. Но в последнее время никто ничего связанного загрузкой файлов не трогал.
Следующим под подозрения попал сам сервер. Но и с ним в принципе было всё как обычно и никто не трогал настроек mime-типов или настроек веб-сервера. Далее под подозрения попал suhosin. Но и он оказался не при делах.
Мистика. Так подумал не только я, но и все, с кем я делился этой напастью.
И тут я от досады начал искать, какие же файлы не заливаются, и что у них общего. Появилась мысль, что происходит поиск некоей сигнатуры в файле, и если она встречается, то всё. Connection lost.
Обрезал у файла хвост. А он не льётся. Отрезал начало. Всё так же. А он уже 600 байт весит.
Посмотрел на эти 600 байт — и вижу, куча нулей (тех самых, которые \0) среди кучи байтов. Взял, сгоряча 75 байт нулей скормил. И опять не прошло. И вот тут то я и понял, в нулях дело. Отправляю 64 нуля подряд — всё окей, 65 и больше — не идёт. И тут я приклеил к хорошему.jpeg, который легко заливался, эти 65 байт нулей сзади. И файл перестал заливаться.
И вот теперь самое интересное. На хабре я читал статейку про атаку на dns, в которой специально сформированные tcp-пакеты запросов возвращали намного более длинные пакеты ответов, что в свою очередь дико напрягало трафик.
Возникла мысль, что всё это от излишне параноидальной настройки сетевого оборудования на стороне хостера. И трафик попросту фильтруется.
Хостеру в ТП конечно отписали. А пока он отвечал, я воспользовался услугой создания триального аккаунта у хостера (на этот раз хостинг был виндовый) и с радостью обнаружил косвенное подтверждение своей догадке. Тестовый скрипт возвращал ту же ошибку и рвал соединение при попытках загрузки файла с нулями. Однако, если загрузить файл через защищённое соединение, естественно, всё прокатывало.
Вообщем, история завершилась хэппи эндом. На следующий день всё неожиданно заработало, а спустя ещё пару дней хостер отписался, что проблема была с их стороны и уже решена.
Эх, работая в разработке бортового ПО уже много лет могу сказать, что тенденции не самые хорошие.
Причем идут и послабления со стороны стандартов (которые пишут в США), и массовая передача самого процесса разработки в Индию и Китай.
Последние хоть и живут в современном мире, голова у них всё еще в деревне.
Как результат, качество ПО сильно падает. Причем они даже пытаются проектные стандарты править так, что они перестают соответсовать «библии» DO-178.
Причем идут и послабления со стороны стандартов (которые пишут в США), и массовая передача самого процесса разработки в Индию и Китай.
Последние хоть и живут в современном мире, голова у них всё еще в деревне.
Как результат, качество ПО сильно падает. Причем они даже пытаются проектные стандарты править так, что они перестают соответсовать «библии» DO-178.
После статьи о тестировании самолёта QA и отладка веб-сайтов почему-то кажется детским садом. Как теперь хабр дальше читать?
:))
Я вот занимаюсь отладкой насосных станций, пищевого/химического производства, энергетических установок. Иногда индустриальной археологией занимаюсь.
Средства разработки — кондовый ANSI C (это ещё неплохо), ассемблер (специфический, не x86, и иногда даже Visual — релейная логика), иногда VBA. Дебаг доставляет, это факт :) Хоть и не самолёт.
Я вот занимаюсь отладкой насосных станций, пищевого/химического производства, энергетических установок. Иногда индустриальной археологией занимаюсь.
Средства разработки — кондовый ANSI C (это ещё неплохо), ассемблер (специфический, не x86, и иногда даже Visual — релейная логика), иногда VBA. Дебаг доставляет, это факт :) Хоть и не самолёт.
Когда-то слышал что критически важные системы в авиации троируются, чуть ли не до того, что каждый «третькомплект» реализован на разном железе и со своим ПО. Это правда или байки? Еще очень интересно какие протоколы используются в современных самолетах, какой-нибудь CAN/RS485/ или что-то специализированное?
мысли вслух — каждый наступает на теже грабли. Из описания мне видно что архитектура становиться похожа на таковую у телефонных коммутаторов предыдущей реинкарнации ( до NGN ). Что стоило сделать системный анализ и найти похожие системы и учесть накопленный опыт? В частности система дабага должна работать со всей сетью, что позволило бы понять сразу что отказ TR инициирован FADEC. Логи же отдельного узла должны быть достаточно полными что бы эмулировать его эволюцию и ясно увидеть производителю почему это произошло.
Конструкция с айфонами в полностью цифровом окружении — это вообще эпик. По идее это нижний уровень взаимодействия с железом и он мало того что должен быть вылизан, но вследствие этого еще и залоггирован как надо. В нормальных системах такое делается поднятием флагов и скачиванием полного лога после теста.
В общем вашей конкретной экосистеме еще взрослеть и взрослеть.
Конструкция с айфонами в полностью цифровом окружении — это вообще эпик. По идее это нижний уровень взаимодействия с железом и он мало того что должен быть вылизан, но вследствие этого еще и залоггирован как надо. В нормальных системах такое делается поднятием флагов и скачиванием полного лога после теста.
В общем вашей конкретной экосистеме еще взрослеть и взрослеть.
Угу, напомнило пару вещей:
Качество встраиваемого ПО или погром всё-таки случился
Это про Toyota, в чьей машине блок управления двигателем как-то убил одну невинную женщину, и покалечил другую. Аудит кода показал наличие 11 тысяч глобальных переменных, отсутствие учета сбоев и ошибок, проверок результатов вызова функций RTOS, и прочую «красоту».
Ну и нетленка про американский сайт healthcare.org — на всякий случай, бюджет разработки — 93 миллиона долларов, в процессе вырос по разным оценкам до 300-400 миллионов, и при запуске он тут же упал. Нагрузочное тестирование то ли проводилось из рук вон, то ли не проводилось вообще (!), пентест выполнялся в день, предшествующий запуску (сейчас не могу найти пруфлинк, но весь интернет пестрел матами на эту тему месяц назад). Кто читает на английском — рекомендую заметки из «штаба», который разбирался с этим факапом. Там феерия почти на каждом шагу:
www.computerworld.com/s/article/9243855/_War_Room_notes_describe_IT_chaos_at_Healthcare.gov?mm_ref=http%3A%2F%2Fm.slashdot.org%2F
Качество встраиваемого ПО или погром всё-таки случился
Это про Toyota, в чьей машине блок управления двигателем как-то убил одну невинную женщину, и покалечил другую. Аудит кода показал наличие 11 тысяч глобальных переменных, отсутствие учета сбоев и ошибок, проверок результатов вызова функций RTOS, и прочую «красоту».
Ну и нетленка про американский сайт healthcare.org — на всякий случай, бюджет разработки — 93 миллиона долларов, в процессе вырос по разным оценкам до 300-400 миллионов, и при запуске он тут же упал. Нагрузочное тестирование то ли проводилось из рук вон, то ли не проводилось вообще (!), пентест выполнялся в день, предшествующий запуску (сейчас не могу найти пруфлинк, но весь интернет пестрел матами на эту тему месяц назад). Кто читает на английском — рекомендую заметки из «штаба», который разбирался с этим факапом. Там феерия почти на каждом шагу:
www.computerworld.com/s/article/9243855/_War_Room_notes_describe_IT_chaos_at_Healthcare.gov?mm_ref=http%3A%2F%2Fm.slashdot.org%2F
А вот если бы еще кто-нибудь написал о том, как отлаживают ПО на атомных электростанциях…
А Вы точно хотите это знать? Почитайте lib.ru/MEMUARY/CHERNOBYL/dyatlow.txt_with-big-pictures.html, неплохо мозги вправляет, хотя не совсем чтобы по теме отладки ПО, но по теме поиска причины «проблемы»…
За атомные не знаю, а с газотурбинными (и немного паровыми) работал. И с химическим процессом (взрывоопасные, легковоспламеняющиеся, сильнодействующие ядовитые вещества) работал. Я, собственно, промышленной автоматикой занимаюсь.
Понял, что Чернобыль — вполне обычное (если не сказать, закономерное) явление, выходящее из ряда вон только по масштабам.
Как ни странно, писаться по ночам не стал. Только знакомых пугаю разными байками.
Понял, что Чернобыль — вполне обычное (если не сказать, закономерное) явление, выходящее из ряда вон только по масштабам.
Как ни странно, писаться по ночам не стал. Только знакомых пугаю разными байками.
А я как-то руководил группой по верификации (DO-178, тогда еще B) ПО на одном джете. Тоже было много анекдотов, в частности на радаре не отрисовывались три строчки, потому что (как потом выяснилось) программист переписал часть автоматически сгенерированного кода и оставил комментарий в духе «тут кажется не оптимально сработал кодогенератор», ну и налепил ошибок.
Хотя максимум веселья был, как мне рассказывали, когда на испытательном полете оказалось, что одну часть системы оповещения о неисправностях сделали по новой версии спецификации, другую — по старой. Сразу после взлета полетели такие ошибки, что пилоты поседели, отключили автоматику и сели вручную.
Скажите одно — за такой отличный и находчивый дебаг нового самолета деньги кто кому платил, вы поставщику самолета или они совесть поимели и Вам компенсировали что-то?
Наша сторона осталась не очень довольной предложениями производителя по урегулированию данной ситуации.
Хотя на ситуацию, как всегда, можно взглянуть с разных точек зрения, так что лично у меня нет даже четко сформировавшегося мнения, что было бы правильным и справедливым.
Хотя на ситуацию, как всегда, можно взглянуть с разных точек зрения, так что лично у меня нет даже четко сформировавшегося мнения, что было бы правильным и справедливым.
Буду подсовывать эту статью заказчикам, которых возмущает неправильные значения суммарников колонок в конце смены ;-)
В прошивку FADEC нужно добавить строку условие:
IF( самолет в воздухе)
{
пропустить анализ разности вращения колесиков…
}
IF( самолет в воздухе)
{
пропустить анализ разности вращения колесиков…
}
Дело в том, что определенную информацию можно было вывести на один из штатных дисплеев в кабине пилотов. Проблема была в том, что информация обновлялась в реальном времени (2-5 отсчетов в секунду), а анализировать ее нужно было вручную
А какой смысл выводить debug-информацию в таком режиме? Неужели от нее есть какой-то толк для пилота? Слабо представляю, чтобы пилот, которому и так есть чем заняться в кабине, будет каждую секунду смотреть в дисплей на эти отсчеты и искать тенденции. Почему не логировать эту информацию для последующего анализа на земле? Понимаю, что вопросы не к автору, ну уж очень непонятно…
Удивительная история. Оказывается, отладка самолёта — не только очень просто, но и безумно интересно!
Два вопроса, если можно.
Когда определяют Мinimum Equipment List исходят из штатной ситуации на борту, когда всё работает так, как должно работать. Не может ли случиться, что в аварийном режиме Мinimum перестанет быть допустимым, и ошибка с отсутствие воды в кофейнике окажется критической?
Второй вопрос. Предположим, фантастика стала явью и компьютерами самолёта управляют извне. Или компьютер по каким-то причинам отказывается работать, или работает некорректно, или ситуация такая, с которой он заведомо не сможет справиться. Предусмотрен ли для таких случаев переход на ручное управление?
Два вопроса, если можно.
Когда определяют Мinimum Equipment List исходят из штатной ситуации на борту, когда всё работает так, как должно работать. Не может ли случиться, что в аварийном режиме Мinimum перестанет быть допустимым, и ошибка с отсутствие воды в кофейнике окажется критической?
Второй вопрос. Предположим, фантастика стала явью и компьютерами самолёта управляют извне. Или компьютер по каким-то причинам отказывается работать, или работает некорректно, или ситуация такая, с которой он заведомо не сможет справиться. Предусмотрен ли для таких случаев переход на ручное управление?
Естественно, в случае наступления какой-то аварийной ситуации наличие неработающего, но отвечающего требования MEL оборудования может эту ситуацию дополнительно усугубить. Именно поэтому разработка MEL — вопрос очень не простой (и не дешевый), и при его разработке стараются ввести такие ограничения на допустимые типы/режимы полетов, чтобы свести к минимуму возможность такого влияния. Тем не менее, понятно, что все предусмотреть невозможно. Если какая-то позиция MEL реально может снизить безопасность полетов, то первым ограничением будет запрет на наличие пассажиров на борту. Т.е. будет разрешен перегон самолета экипажем к месту ремонта, и все. Опять таки, это очень упрощенное объяснение.
Большинство самолетов с системой Fly-By-Wire (где контроль над управляющими поверхностями и двигателями осуществляется с помощью электронных систем, в настоящее время — специализированных компьютеров) не предусматривают возможности перехода на непосредственное управление. Грубо говоря, даже теоретически невозможно напрямую соединить штурвал и рули — штурвал всегда будет всего лишь просить у компьютера выполнить то или иное действие, а компьютер уже будет посылать управляющие воздействия на приводы рулей.
Большинство самолетов с системой Fly-By-Wire (где контроль над управляющими поверхностями и двигателями осуществляется с помощью электронных систем, в настоящее время — специализированных компьютеров) не предусматривают возможности перехода на непосредственное управление. Грубо говоря, даже теоретически невозможно напрямую соединить штурвал и рули — штурвал всегда будет всего лишь просить у компьютера выполнить то или иное действие, а компьютер уже будет посылать управляющие воздействия на приводы рулей.
Спасибо большое.
По первому вопросу всё предельно ясно, по второму тоже, хоть и жутковато немного.
Не знаю почему, но вероятность человеческой ошибки пугает меньше, чем полная зависимость от компьютера.
Но если люди не могут ничего исправить и изменить, может они и не нужны особо?
Есть же беспилотный гугломобиль, возможно, на очереди самолёты, которые оснащены только автоматическими системами управления?
По первому вопросу всё предельно ясно, по второму тоже, хоть и жутковато немного.
Не знаю почему, но вероятность человеческой ошибки пугает меньше, чем полная зависимость от компьютера.
Но если люди не могут ничего исправить и изменить, может они и не нужны особо?
Есть же беспилотный гугломобиль, возможно, на очереди самолёты, которые оснащены только автоматическими системами управления?
Насчет полностью беспилотного пассажирского самолета я даже сам себе ответить не могу. Мне кажется, что помимо вопросов пилотирования, на самолете есть еще очень большое количество функций, выполнить которые автоматы не смогут еще очень долго.
Я также прекрасно понимаю, что надежность современных электронных систем намного выше, чем классических. Также понимаю, что даже с классическими системами при определенных видах отказов человек тоже ничего не сможет сделать (в т.ч. чисто физически). И человек я технический, с вроде довольно неплохим пониманием многих аспектов как самолетостроения, так и пилотирования. И все равно на уровне эмоций у меня приблизительно такие же ощущения, как у Вас…
Я также прекрасно понимаю, что надежность современных электронных систем намного выше, чем классических. Также понимаю, что даже с классическими системами при определенных видах отказов человек тоже ничего не сможет сделать (в т.ч. чисто физически). И человек я технический, с вроде довольно неплохим пониманием многих аспектов как самолетостроения, так и пилотирования. И все равно на уровне эмоций у меня приблизительно такие же ощущения, как у Вас…
Беспилотный гугломобиль есть пока только на закрытых треках и на дорогах общего пользования он появится ой как не скоро.
Не вдаваясь в подробности, приведу пример. Железная дорога (и метро, как разновидность) автоматизирована и весьма (я имею в виду не подвижный состав, а полотно и инфраструктуру). В этом плане автомобильная дорога просто в каменном веке. И, тем не менее, в кабине всегда есть машинист — даже если часть пути поезд ведёт автоматика.
Не вдаваясь в подробности, приведу пример. Железная дорога (и метро, как разновидность) автоматизирована и весьма (я имею в виду не подвижный состав, а полотно и инфраструктуру). В этом плане автомобильная дорога просто в каменном веке. И, тем не менее, в кабине всегда есть машинист — даже если часть пути поезд ведёт автоматика.
Беспилотный гугломобиль есть пока только на закрытых треках и на дорогах общего пользования он появится ой как не скоро.
Вы уверены?
Дата статьи по ссылке 8 мая 2012, если что. Так что думаю уже вовсю катаются машинки на дорогах общего пользования. Конечно может и с водителем пока за рулём, но сами.
Интересно, почему система Unit тестов для ПО FADEC не отловила закомментированный кусок кода?
Судя по описанию проблемы, похоже это самое окно никто не тестировал…
Судя по описанию проблемы, похоже это самое окно никто не тестировал…
Если у разработчиков этого контроллера всё так же, как у Тойоты с её контроллером двигателя, то тестов там никогда и не было.
Несмотря на все тяжкие процессы сертификации, качество верификации ПО часто оставляет желать лучшего. И к бизнес-джетам это относится наверное даже в большей мере, чем к остальным бортам.
Возможно, что:
— этот участок кода вообще не проверялся автоматическими тестами
— проверялся, но недостаточно хорошо (пара стандартных наборов данных), поэтому факт комментирования кода не был отловлен
— были fail'ы в тестах, но проблему прохлопали/посчитали несущественной и она прошла сертификацию
— этот «умный код» иногда глючил, и решили на текущей сертификации его убрать (отразив это в требованиях). Но, как видите, что-то забыли.
Разновидность последнего вариант разгребал лично несколько лет назад как раз на бизнес-джете. Правда тогда это был испытательный полет и кривой код к заказчикам не попал (но там и «эффект» гораздо круче был :))
Возможно, что:
— этот участок кода вообще не проверялся автоматическими тестами
— проверялся, но недостаточно хорошо (пара стандартных наборов данных), поэтому факт комментирования кода не был отловлен
— были fail'ы в тестах, но проблему прохлопали/посчитали несущественной и она прошла сертификацию
— этот «умный код» иногда глючил, и решили на текущей сертификации его убрать (отразив это в требованиях). Но, как видите, что-то забыли.
Разновидность последнего вариант разгребал лично несколько лет назад как раз на бизнес-джете. Правда тогда это был испытательный полет и кривой код к заказчикам не попал (но там и «эффект» гораздо круче был :))
Не расскажете подробнее про «эффект» и причины? Если не NDA, конечно.
Как именно могли провтыкать тесты я отлично представляю, меня скорее интересует вопрос надежности работы и контроля ПО в авиации. Достоверно извесно, что в авиации массово используются системы дублирования.
Я был почти уверен, что с тестами дело обстоит аналогичным образом (один кусок кода покрыт несколькими независимыми тестами).
Выходит что-то не так!?
Я был почти уверен, что с тестами дело обстоит аналогичным образом (один кусок кода покрыт несколькими независимыми тестами).
Выходит что-то не так!?
Нет, тест пишется один на некую логически-связанную часть кода.
Стараются это максимально декомпозировать на мелкие куски, чтобы тест долго не ходил (хотя некоторые ходят неделю).
Качество написания тестов контроллируется теми же людьми. В зависимости уровня критичности, к каждому куску кода имеют отношения от 1 до как минимум 6 человек.
Автоматом контроллируется только покрытие всех веток кода, но это тоже не дает гарантий, т.к. некоторую ситуацию можно создать, но не проверить результат работы.
А также бывает, что всё покрыто, всё проверено, но тем не менее опасную ситуацию создать можно.
Стараются это максимально декомпозировать на мелкие куски, чтобы тест долго не ходил (хотя некоторые ходят неделю).
Качество написания тестов контроллируется теми же людьми. В зависимости уровня критичности, к каждому куску кода имеют отношения от 1 до как минимум 6 человек.
Автоматом контроллируется только покрытие всех веток кода, но это тоже не дает гарантий, т.к. некоторую ситуацию можно создать, но не проверить результат работы.
А также бывает, что всё покрыто, всё проверено, но тем не менее опасную ситуацию создать можно.
Не могу удержаться, уж не о Sukhoi Superjet 100-ли статья?
Может быть, конечно, но… что-то тут не складывается. С одной стороны написано, что «самолет только-только начал выпускаться, и конкретный экземпляр имеет серийный номер в первой десятке» и «нет ни опыта эксплуатации, ни опыта техобслуживания». С другой стороны, написано что речь идет о «бизнес-джете». Да, есть версия SSJ-100 в виде бизнес-джета (так-то это пассажирский региональник), но первый экземпляр был выпущен буквально этим летом, а этим летом бортовые номера SSJ уже перевалили за 50 и безусловно есть уже и опыт эксплуатации и техобслуживания и у наших и у иностранных заказчиков. Да и детская болезнь типа описываемой должна была уже давно быть обнаружена и как минимум внесена в документацию — уж при десятке-то вылетов в день, который делает каждый борт в той же Interjet. Не думаю что бизнес-версия настолько отличается от региональной что прямо там внезапно появляются такие вот баги которые за несколько лет не были обнаружены в региональнике. Да и не слышал я о конкретно этой детской болезни у SSJ.
Да, я тоже хотел прямо спросить не суперджет ли это, но засомневался. С другой стороны у них есть временные рег. номера, и вроде как последний самолет переданный по контракту для Мексики имеет номер 97008. Более, чем подходит для «первой десятки».
Видимо пока curiousGeorge не раскроет тайну, так и будем гадать :-)
Видимо пока curiousGeorge не раскроет тайну, так и будем гадать :-)
Он как бы не бизнес-джет, но подобного уровня проблемы с первыми экземплярами тоже были.
Поставил плюс собрату.
1. Чисто интересно, мы с вами не общались?
2. Бюрократия и жесткости процессов — это специфика индустрии. Мне больше интересно то, когда современными методами, которые никоим образом не нарушают стандарты разработки, разрешат пользоваться официально. А то совсем же грустно без CVS и CI-фреймворков.
3. Мне любопытно, насколько сейчас с мёртвой точки сдвинулся ГОСНИИАС и Иркут?
4. Люди, курирующие авиационные проекты, увы, старой закалки, что отзывается на всём процессе. Если честно, то моё мнение, что у молодых специалистов куда больший потенциал и куда быстрее и лучше может получиться, если их допустить до управления и экспертизы. Но здесь вам не тут, и поэтому свободное небо и космос, пока что удел энтузиастов и мелких проектов.
1. Чисто интересно, мы с вами не общались?
2. Бюрократия и жесткости процессов — это специфика индустрии. Мне больше интересно то, когда современными методами, которые никоим образом не нарушают стандарты разработки, разрешат пользоваться официально. А то совсем же грустно без CVS и CI-фреймворков.
3. Мне любопытно, насколько сейчас с мёртвой точки сдвинулся ГОСНИИАС и Иркут?
4. Люди, курирующие авиационные проекты, увы, старой закалки, что отзывается на всём процессе. Если честно, то моё мнение, что у молодых специалистов куда больший потенциал и куда быстрее и лучше может получиться, если их допустить до управления и экспертизы. Но здесь вам не тут, и поэтому свободное небо и космос, пока что удел энтузиастов и мелких проектов.
Хоть это и крайне нереально, но очень уж хочется посмотреть код прошивки FADEC.
Особенно сделать вид, что хоть что-то в этом коде пойму :))))
Особенно сделать вид, что хоть что-то в этом коде пойму :))))
Да, не. Будет как у автора статьи :-)
1. Зачем они так сделали?
2. А, все понятно, нормально!
3. Не, подождите, а если вот такое произойдет?
4. Секунду, зачем это вообще нужно было ???
5. Не может быть, чтобы и это учли!
6. Ну ничего себе… Как вообще можно было это все так тщательно и глубоко продумать ???
Приходите работать туда, где это дело разрабатывают, и посмотрите ))
Спасибо за статью, читается на одном дыхании. Конечно, как вы логи снимали… из всех слов, которые приходят на ум по этому поводу, цензурным является только слово «смекалка» :)
Спасибо за Вашу статью!
В голове не укладывается, что FADEC получает такую информацию. Я уже не говорю о последствиях :)
Очень удивила концепция «центрального компьютера». Ни в Аэробусах, ни в Боингах такого нет.
В голове не укладывается, что FADEC получает такую информацию. Я уже не говорю о последствиях :)
Очень удивила концепция «центрального компьютера». Ни в Аэробусах, ни в Боингах такого нет.
Опять таки, из-за упрощенного объяснения у кого-то могло сложиться неверное впечатление о структуре бортовой управляющей системы, поэтому добавлю пару слов.
Хотя я назвал это «центральным компьютером», физически он таковым не является. Это не один ящик, в который сходится все, а очень сложно организованная система, состоящая из ряда блоков. Причем многие блоки не просто продублированы для надежности, но изначально отличающиеся по функциональности блоки могут управлять одними и теми же частями самолета, предоставляя, таким образом, совершенно разные (как физические, так и логические) пути прохождения сигналов между критически важными системами.
Хотя снаружи это функционирует, как единая система, но внутри нет одного места, при выходе из строя которого все остальное тоже прекращает работать.
Хотя я назвал это «центральным компьютером», физически он таковым не является. Это не один ящик, в который сходится все, а очень сложно организованная система, состоящая из ряда блоков. Причем многие блоки не просто продублированы для надежности, но изначально отличающиеся по функциональности блоки могут управлять одними и теми же частями самолета, предоставляя, таким образом, совершенно разные (как физические, так и логические) пути прохождения сигналов между критически важными системами.
Хотя снаружи это функционирует, как единая система, но внутри нет одного места, при выходе из строя которого все остальное тоже прекращает работать.
Все таки, из-за упрощенного объяснения, не уверен, что я Вас понимаю :) Поэтому прошу объяснить.
Возьмем А320. Сигнал от рычага закрылок поступает на компьютер SFCC (slats flaps control computer), который с помощью гидравлики выпускает закрылки. Да, это тоже упрощенно — на самом деле там задействовано где-то 7 разных компьютеров. Так же как Вы и описали SFCC продублированы, их 2 штуки. То есть, сигнал идет так: рычаг --> компьютер SFCC --> закрылки. Но мы не можем сказать, что это центральный компьютер, потому что для выпуска шасси, например, сигнал идет так: рычаг --> LGCIU --> шасси. И хотя LGCIU и SFCC обмениваются информацией, это абсолютно независимые компьютеры.
Из Вашего же описания я понял, что (на примере A320) сигнал идет так:
рычаг закрылок --> центральный компьютер (сложная система из разных блоков, которые дублируются) --> SFCC --> закрылки
рычаг шасси --> тот же самый центральный компьютер --> LGCIU --> шасси
Я правильно понял?
PS. На А320 есть ECAM, как бы центральный компьютер мониторинга. Самолетный Nagios что-ли :) Или Zabbix. Но, все же, я уверен, Вы не это имели ввиду.
Возьмем А320. Сигнал от рычага закрылок поступает на компьютер SFCC (slats flaps control computer), который с помощью гидравлики выпускает закрылки. Да, это тоже упрощенно — на самом деле там задействовано где-то 7 разных компьютеров. Так же как Вы и описали SFCC продублированы, их 2 штуки. То есть, сигнал идет так: рычаг --> компьютер SFCC --> закрылки. Но мы не можем сказать, что это центральный компьютер, потому что для выпуска шасси, например, сигнал идет так: рычаг --> LGCIU --> шасси. И хотя LGCIU и SFCC обмениваются информацией, это абсолютно независимые компьютеры.
Из Вашего же описания я понял, что (на примере A320) сигнал идет так:
рычаг закрылок --> центральный компьютер (сложная система из разных блоков, которые дублируются) --> SFCC --> закрылки
рычаг шасси --> тот же самый центральный компьютер --> LGCIU --> шасси
Я правильно понял?
PS. На А320 есть ECAM, как бы центральный компьютер мониторинга. Самолетный Nagios что-ли :) Или Zabbix. Но, все же, я уверен, Вы не это имели ввиду.
Привет вам из 2025 года.
ИИ не надо использовать для управления автоматикой самолёта, но вот разумно использовать в процессе проектирования и анализа кода - самое то. Например, думаю, что надо собирать датасет с описанием возможных проблем эксплуатации, и на его основании пусть ИИ генерирует тесты. Поддерживать этот датасет должна сертифицирующая организация, и надо проверять им оборудование разных производителей.
Sign up to leave a comment.
Отладка самолета? Это очень просто!