Комментарии 571
Как сказано ниже «это проблема приемки»
Не знаю, правда ли, но, говорят, французские танки имеют сходную надежность, и до поломки накатывают километров 60-100 — так, что их даже на учения возят только трейлерами, от греха.
Думаю выгода там и в преодолении пересеченной месности: лес, склоны, брод, поле, трасса
Невыгодно. Гусеничный движитель — вовсе не образец эффективности. У вполне гражданского, и довольно легкого ГТС-М (двигатель от ГАЗ-66) пробег до капремонта составляет, емнип, 5000 км. Танк и тяжелее, и дороже, и требования к двигателю у него повыше.
Но основное назначение танка, как бы странно это не звучало, вовсе не те пятнадцать минут гипотетического боя. Основное назначение танка — боевая учеба, именно ей на танке занимаются долгие годы. А это занятие, как ни крути, связано с расходом моторесурса: чтобы учиться, надо ездить и ездить.
Поэтому на полигон своим ходом — тоже оправдано.
Да и половину Конкорда французы делали :)
Танки, конечно, разбивают дорогу быстрее, чем колесная техника, а тяжелая колесная техника делает это быстрее, чем легковушки, но если асфальт положен правильно, то периодические проезды современного танка сильно ему не повредят.
Да и скорость движения современного танка на дороге с твердым покрытием составляет по меньшей мере 50 км/ч, а у некоторых и заметно больше. Мадленнее легковушки, но движение не станет.
Единственная причина, по которой танки катают на трейлерах (кстати, если и быстрее собственного хода танка, то ненамного) — высокая стоимость покатушек танка своим ходом, что проистекает из трех составляющих: малый ресурс ходовой части (как у любой тяжелой гусеничной техники), большой расход горючки (как не в себя) и (в мирное время) необходимость дополнительных мероприятий по обеспечению безлпасности движения (танки "забыли" оснастить хорошим обзором для мехвода и сигналами поворота и остановки).
Да и скорость движения современного танка на дороге с твердым покрытием составляет по меньшей мере 50 км/ч, а у некоторых и заметно больше. Мадленнее легковушки, но движение не станет.а если разрешённая скорость — 120?
В остальном — так и есть.
Во-первых, с такой сеоростью танк и на трейлере не поедет.
Во-вторых, движение замедлится, но не станет.
Маловероятно. Самые шустрые танки из распространенных по достаточно твердой и ровной поверхности делают до 80.
Так что либо скорость преувеличили, либо спидометр врал (кстати говорят, что спидометры завышают показания скорости, чтобы не превышали).
Или случилось чудо и они встретили Т-15, который может больше 80, но это маловероятно.
Они ездят не по асфальту, а по специальной грунтовке для танков и прочей техники. Асфальтовую дорогу пересекают один раз, и в этом месте дорогу забетонировали. Так что "своим ходом" - это не совсем так, просто у них обучение начинается не на самом полигоне а прям от училища, и дорога как-бы входит в полигон.
Ничего против французской техники не имею. Но заявленная вами надежность ИМХО не очень реальна. Откуда такие данные? Катастрофа из-за отказа двигателя и отказ двигателя — разные вещи. Открытую статистику отказов военного самолета сложно представить.
A3-79 — отказ двигателя в полете, самолет потерян, пилот погиб
A3-4, A3-18, A3-28, A3-46, A3-52, A3-67, A3-70, A3-82, A3-94, A3-95 — отказ двигателя в полете, самолет потерян, пилот успешно катапультировался
A3-97 — отказ двигателя в полете, самолет поврежден, пилот не постардал
A3-2, A3-41 — отказ двигателя в полете, пилот успешно посадил самолет
A3-63 — разрушение двигателя при опрбовании на земле, пилот не пострадал
A3-74, A3-75 — попадание птиц или осколков в двигатель, самолет потерян, пилот успешно катапультировался
Итого 15 серьезных происшествий по вине двигателя. И это только один тип и одна страна c 116 закупленными самолетами. А были еще Mirage IV, 5, F-1, 2000 — всего порядка 3500 выпущенных.
A3-74, A3-75 — попадание птиц или осколков в двигатель, самолет потерян, пилот успешно катапультировался
Ну тут как бы немного не вина двигателя. Не удивлюсь, если и среди остальных проишествий имеются спорные моменты, связанные с возможной неправильной эксплуатацией.
Я всеже думаю что имеется в виду Rafale с M88 у которых ЕМНИП небыло серьезных происшествий по вине двигателей. Но Rafale двухдвигательный и суммарный налет парка не очень большой.
Если завод не напротив полигона — иначе никак, гусеницы разрушают дороги уже за 1 проезд.
Как житель Донецка, могу сказать однозначно: это миф. Танки и САУ, конечно, оставляют царапины на асфальте, но никакого сколь-нибудь заметного вреда ему не наносят. Наверное, если взять полуразвалившуюся дорогу без основы, её и размолотят. Но по обычной нормальной городской дороге хоть сто танков проедет, ничего особого ей не делается, кроме вот таких царапин:
pbs.twimg.com/media/BsqqrOsCEAAoc3-.jpg
Плиты прочнее асфальта, и не подвержены разрушению от воды.
Затем, что до поля боя еще нужно доехать и это будет совсем не катание до полигона.
Как думаете, какое среднее время танка с отказавшим двигателем в бою?
Это вроде вообще статистика по боям во время второй мировой войны. С того момента живучесть танков значительно повысилась. Да и пехоты тоже.
Зачем ему ради 15 минут супернадежный двигатель?
Потому что не каждый бой это Курская дуга, до первого серьезного боя может быть несколько недель маневров, ну и среднее время жизни это как и среднее время пехотинца в бою (которое тоже что-то минут 10), кто-то погибает в первой минуте первого боя, кто-то проходит всю войну от начала до конца.
Это нужно спросить у французов, в суперджете их двигатели
Доля НПО «Сатурн» в совместном предприятии составляет 49,84%.
Доля НПО «Сатурн» в общем объёме работ над двигателем SaM146 составляет около 38%.
Пока что списывают на то, что французы не умеют делать камеру сгорания, но, по странному стечению обстоятельств, это — именно та версия, которая устраивает всех. По ещё более странному стечению обстоятельств, о проблемах с двигателем известно только из Ведомостей и их источников: никто из незаинтересованных лиц проверить слив не смог.
Так или иначе,
Мы испытываем мощнейшие сложности, связанные с нашим партнерством с французскими партнерами по двигателю SaM146. У коллег жесткая бизнес-модель и идти на симметричные снижения стоимости владения двигателем они не готовы. Разбирая все проблемы эксплуатации двигателя с региональными компаниями, мы видим, что и они пользуются сложившейся ситуацией, стремятся занять более выгодное для себя положение, в наших спорах с французами. (Фотография очень грустного кота) Мы понимаем, что нам надо создать банк подменных двигателей. Такая программа у ОДК есть. Документацию на полную разборку/сборку двигателей на территории рыбинского завода мы получили. Первый двигатель там уже полностью отремонтирован, то есть, разобран-собран. Вопрос коммерческий – идет торговля, за сколько мы с французами сговоримся. Мы понимаем, что условия, которые они выставляют по покупке/аренде подменных двигателей у компании PowerJet, неприемлемы для российских региональных авиакомпаний. Просто не приемлемы и все. А качество самого двигателя вне гарантийного срока и внутри гарантийного срока, вызывает вопросы по горячей части (горячая часть — французская производственная зона ответственности). С этим двигателем нам все равно жить и дальше. Это решение предшествующих периодов и никто не мог знать, что оно так пойдет. Безусловно, будем мучиться с этим двигателем, пока не произведем свой.
TL;DR: Каким бы плохим двигатель ни был — будете мучаться. О чём вы собираетесь спрашивать французов я не совсем понимаю.
Эти же французы (Safran) поставляют движки для A320 и 737MAX и даже второй знаменит не отказом движка. Так что наверное проблема где-то ещё.
Ещё есть на просторах интернета интересное заявление главы Роснефти о "немного нечестной конкуренции" когда европейские производители занижают ресурс своим двигателям в случае использования для заправки топлива произведённого российскими компаниями.
Ссылка на статью про сокращение ресурса производителями https://www.kommersant.ru/doc/3869044
Тогда я понимаю занижение ресурса двигателей, да.
Общее в истории с Боингом — рост диаметров современных двигателей. Больший диаметр движков требует иных компоновочных решений, на которые авиапроизводители идти не хотят, прибегая к паллиативам (костылям).
Индусы может и написали код точно в рамках ТЗ, но как это отменяет тестирование?
По сути софт могут писать и спецы с оплатой 1 копейка в сутки, лишь бы корретно работало, но если софт кривой и написан спецами с зарплатой в 1 миллион долларов в секунду, то как это отменяет кривость софта?
Имхо, это проблема приемки, а не зарплат.
По сути софт могут писать и спецы с оплатой 1 копейка в сутки, лишь бы корретно работалоКривой софт могут написать и за 1 копейку и за миллион, а вот прямой за копейку не напишут.
как это отменяет тестирование? Имхо, это проблема приемки, а не зарплат.Тестирование может пройти и кривой код, в сложной системе абсолютно все варианты развития событий протестировать невозможно.
Это комплексная проблема, корни которой все же лежат в первую очередь в экономии.
Кривой софт могут написать и за 1 копейку и за миллион, а вот прямой за копейку не напишут.
так 9 баксов в час — это не копейка. Если вы не умеете в преувеличение — используйте исходные данные.
Тестирование может пройти и кривой код, в сложной системе абсолютно все варианты развития событий протестировать невозможно.
вы, видимо, плохо представляете себе правильное тестирование. Это не только юнит-тесты. Это целая методика. Наши тестеры для каждой (намного более простой и менее ответственной, чем самолет) фичи пишут сценарии тестирования, определяют корнер кейсы и т.д. И у нас оно еще (осознанно) далеко от идеала. Потому, что от нашего софта жизни не зависят.
вы, видимо, плохо представляете себе правильное тестирование. Это не только юнит-тесты. Это целая методика. Наши тестеры для каждой (намного более простой и менее ответственной, чем самолет) фичи пишут сценарии тестирования, определяют корнер кейсы и т.д. И у нас оно еще (осознанно) далеко от идеала. Потому, что от нашего софта жизни не зависят.
Задача юнит-тестов — зафиксировать поведение кода, чтобы он не ломался при рефакторинге. А вот проверить правильность работы сложного кода с помощью юнит-тестов попросту нельзя. Но многие до сих пор считают, что 100% покрытие тестами гарантирует правильность работы кода.
А вот более сложное высокоуровневое тестирование с написанием сценариев, обнаружением крайних случаев — всё это уже требует высокой квалификации тестировщика и его компетенции в смежных областях. Программист, который пилит маленький модуль в большой системе, о которой ничего не знает, не сможет написать интеграционные тесты.
Инженеры — отдельная тема. Как правило, редко человек бывает одновременно и хорошим инженером, и хорошим кодером. Человек достигает высокой квалификации, если занимается чем-то одним.
В итоге проблема заключается не в переводе спецификации в код, а в переводе спецификации на язык, понятный кодеру, потому что если кодер не понимает (да и не должен понимать) спецификацию, то это будет только зря потраченное время.
а в переводе спецификации на язык, понятный кодеру
В боинге с этим все было ок, по крайней мере, в те полгода, когда я участвовал в написании юнит-тестов для 787. Спецификации были очень подробными и понятными, и не требовали знаний по разработке авиации.
P.S. У нас в иехархии были люди, которые тщательно проверяли, что юнит-тесты написаны правильно :)
более высокоуровневые тесты должны писать не те, кто имеет компетенцию в смежных областях, а те, кто имеет компетенцию в более высокоуровневых областях
В идеале компетенция в низкоуровневых вещах тоже должна быть.
Кто видит картину шире
Так я это и написал.
Непонятно где производственный выигрыш такой модели — экономите на разработчиках, увеличиваете расходы на тестирование, да еще и сроки проекта увеличиваете, т.к. проходите больше итераций.
А вот такой зерг раш прекрасно масштабируется и работает.
Видел я такой "Зерг раш". За пару дней до конца спринта завершается тестирование с результатами, что ни один юз-кейс полностью пройти нельзя. При этом команда раздута до десятков человек, суб-команды перекидывают ответственность друг на друга, из-за размеров команды частенько кто-то нужный сваливает в запланированный отпуск, центральный менеджемент мечет молнии но ничего не понимает, т.к. не в состоянии погрузиться глубоко. Неизбежно начинается игра с Заказчиком в "Это было в требованиях, а этого не было".
И все равно это проще, чем найти чудо-разработчика.
Бортовые системы самолёта по тем же принципам работают?
Мне кажется, вы как-то не правильно вопрос задали.
Вопрос: нужны ли все эти микросервисы-фронтэнд-бэкэнд в бортовой системе самолёта?
Вот поэтому мне и хочется понять, насколько популярные сейчас методы и инструменты разработки подходят под rocket science.
Не отказоустойчивым, а выполняемым в реальном времени. То есть программа должна гарантированно выполниться за xx миллисекунд при любых входных условиях. Большее время выполнения равнозначно отказу ПО.
Да, про чудо-разработчика абсолютно согласен. И сложно найти и массу рисков несёт. Нужны крепкие миддлы, выстроенные процессы, железная дисциплина (чему кстати способствуют кажущиеся бессмысленными приседания в Скраме). Но вам понадобится чудо-менеджер, которых наверное еще меньше чем чудо-разработчиков.
Вот только одна проблема: крепкие мидлы остаются мидлами очень ограниченный срок.
Это прозвучит не очень красиво, но я в какой-то момент понял что основная часть команды не должна состоять из амбициозных людей. Они действительно стремительно вырастают и улетают из гнезда.
Другое дело, работодатели любят дуть в уши про то, сколько они в тебя вложили, поэтому ты должен работать за сильно меньшую зп, чем мог бы получать.
если вы создаете условия для дальнейшего роста
в одной команде сложно ужиться нескольким сеньорам. Они хотят либо тимлидить либо принимать общие архитектурные решения, а не исполнять в коде чьи-то идеи.
А вот такой зерг раш прекрасно масштабируется и работает.
Данная статья показывает, что для высокотехнологичных задач зерг раш не работает, а может стоить даже дороже.
Это комплексная проблема, корни которой все же лежат в первую очередь в экономии.
Абсолютно верно, проблема по существу, в ускорении конкуренции
Если код проходит автотесты, это лишь означает, что при определённых входных данных он выдаёт соответствующие выходные значения. А вот о правильности код речи идти не может.
Работал как-то над софтиной, написанной индусами. Прилично удивил кусок кода вида (примерно, на псевдокоде):
function CalculateSomething(int id, ...params...) {
...
distance = GetOdometer(id)
...
if (id = 123456) {
return
}
...
PerformSomeComputations(distance, ...params...)
...
}
В отличие от прочих «программистов» компании, я стал в этом коде ковыряться и докапываться до истины — благо базы были доступны. Оказалось, что у одного из клиентов какой-то *удак в графу «показания одометра» у автомобиля с id=123456 забил число вроде 3786731 (если кто не знает — редкий автомобиль может проехать 200'000 миль, не развалившись на запчасти, а тут имелось в виду 37867,31 — но забивальщик отвлёкся и пропустил запятую), соответственно при обработке конкретно этой записи у конкретно этой компании PerformSomeComputations() падала из-за переполнения и рушила всю систему. В нашу компанию пришёл баг вида «у клиента X при обработке автомобиля id=123456» падает система". «А, понятно!» — сказал индийский программист и исправил (как мог). Результат Вы видите.
Автотесты код, естественно, проходил…
«А, понятно!» — сказал индийский программист и исправил (как мог). Результат Вы видите.А ревью кода у них отсутствовал как класс? СММ какого уровня у конторы?
Автотесты код, естественно, проходил…
Так данные-то корректные (формально). Просто они оказались неожиданными конкретно для функции PerformSomeComputations().
Мы вот как-то в базе прода "нашли" 78-осный грузовик, и он так же "не пролез" через одну из функций. Означает ли это, что грузовик некорректный?
>>Означает ли это, что грузовик некорректный
Зачем Вы подменяете понятия? Вопрос не в грузовике, а отсутствии контроля входных данных при импорте/входной форме, это же грёбаные азы.
Тут мы упираемся в парадокс кучи: где та граница, ниже которой значения еще реальные, но свыше которой ни одна машина ни одного километра проехать не может?
Почему вы даже не рассматриваете вариант, при котором функция PerformSomeComputations должна работать с любыми числами?
Или тот вариант, при котором она должна на них падать, но не рушить при этом всю систему?
Кто вообще писал ТЗ и проектировал этот бардак?
Компания называлась ADP — гигантский когломерат, производящий автоматизацию всего и вся. Я в то время работал в подразделении, которое автоматизировало (вернее, привносило зачатки big data в) работу автосалонов. Подразделение почти целиком состояло из индусов. :) Дело было лет 12 назад, тогда код-ревью и проч. ещё не были buzzwords.
Кроме того уверен, что в той базе данных предыдущие показания одометра по данному ТС есть.
Одной из характеристик выставленных на продажу б/у автомобилей как раз и является пробег — он фиксируется, когда продавец привозит машину на продажу, и, естественно, не меняется, когда машина стоит на продажной площадке. Поэтому предыдущих значений нету.
Пример работы эффективных менеджеров в действии.
а что, код белого человека проверять не надо? Он ошибок не совершает? А это, повторюсь, самолет.
И пишет он неделю, а проверяют час
В том-то и дело, что не час. Это же самолёт.
По хорошему, значительную часть работы в виде покрытия тестами аутсорсы сделают сами.
Юнит-тесты не проверяют правильность кода. А более высокоуровневые тесты индусы писать не смогут.
Чем больше и разнообразнее опыт инженера и чем лучше он знает для чего он пишет софт и как это работает не только программно, тем меньше вероятность получить комплексную проблему на выходе (а к пуговицам то претензий нет), но такой инженер стоит, обычно, немного дороже, работает, часто, медленней, в общем пока гром не грянет — сплошные убытки :)
p.s. наблюдаю такую картину постоянно, кусочки работают по регламенту и по т.з. а в сумме то тут то там что-то идёт не так...
Чем больше и разнообразнее опыт инженера
В данном случае дело даже не в опыте. Специфическая для индийских хм… «инженеров» (а равно и программистов в инженерных доменах) проблема закладывается еще во время учебы, и отлично описана Фейнманом в его известной книге. Конечно, там место действия — Бразилия, НО. Удивительным образом все совпадает до деталей. Поэтому не буду плодить сущности и просто процитирую (извиняюсь за размер)
Но потом я спросил, можно ли, имея всего один кусок поляроида, определить, в каком направлении он поляризует свет. Они совершенно не представляли себе. Я знал, что это требует известной доли находчивости, поэтому я подсказал: «Посмотрите на залив. Как от него отражается свет?» Все молчат. Тогда я сказал: – Вы когда-нибудь слышали об угле Брюстера? – Да, сэр. Угол Брюстера – это угол, отражаясь под которым от преломляющей среды, свет полностью поляризуется. – В каком направлении свет поляризуется при отражении? – Свет поляризуется перпендикулярно плоскости падения, сэр. Даже теперь я не могу этого понять. Они знали все наизусть. Они знали даже, что тангенс угла Брюстера равен показателю преломления! Я сказал: «Ну?» По-прежнему, ничего. Они только что сказали мне, что свет, отражаясь от преломляющей среды, как, например, воды в заливе, поляризуется. Они даже сказали, в каком направлении он поляризуется. Я сказал: «Посмотрите на залив через поляроид. Теперь поворачивайте поляроид». – О-о-о, он поляризован! – воскликнули они. После длительного расследования я, наконец, понял, что студенты все запоминали, но ничего не понимали. Когда они слышали «свет, отраженный от преломляющей среды», они не понимали, что под средой имеется в виду, например, вода. Они не понимали, что «направление распространения света» – это направление, в котором видишь что-то, когда смотришь на него, и т.д. Все только запоминалось, и ничего не переводилось в осмысленные понятия. Так что, если я спрашивал: «Что такое угол Брюстера?», я обращался к компьютеру с правильными ключевыми словами. Но если я говорил: «Посмотрите на воду», – ничего не срабатывало. У них ничего не было закодировано под этими словами.
Вот это нынешняя система технического (= не гуманитарного) образования в Индии как она есть.
bool value;
if(value.ToString.Length() == 4)
return true;
else if(value.ToString.Length() == 5)
return false;
else
return !true && !false;
Приемка тестирует функцию — она работает? работает.
Потому что, согласно спецификации, работа toString гарантируется только на корректных входных данных, а здесь на вход пришли неинициализированные. На корректных тестах всё работало. Undefined behavior, однако.
Это, конечно, была ирония. Протестировать тестами полностью всё невозможно — два int' а во входных данных уже дадут де-факто бесконечное время для перебора.
Тут разве что оом может упасть при попытке строчку выделить, но это такое.
Неинициализированный bool нормально сравнится, оба if будут ложными либо сравнение на true будет заменено компилятором на "не ноль". Дальше если оптимизатор вырезал "недостижимый" код, то все плохо, иначе сработает последний return и всё хорошо.
toString для bool можно сделать как return constantStrings[boolValue], которая полагается на то, что bool превращается в 0 или 1. Неинициализированный, соответственно, даст выход за границы массива и там можно схватить вообще что угодно, NPE в том числе. Но тут надо будет старательно завернуть всё в unsafe и выкрутить оптимизатор.
Но я C#, считайте, не знаю, мне правда интересно.Хвала Аллаху, что подобные системы ещё не докатились до шарпа.
Такой код, скорее всего не пройдет по стандартам.
ИСТИНА/ЛОЖЬ — и мы поворачиваем не в ту сторону.
Почти, но мимо. В C# не предусмотрена локализация для типа bool.
Только "True", "False".
Почти, но мимо. В C# ToString() — функция, а не свойство.
PS. А Length — наоборот, свойство.
Вы вообще о чём?
bool.ToString() возвращает всегда либо "True", либо "False".
ToString != ToString().
На случай, если не видели исходного комментария:
bool value;
if(value.ToString.Length() == 4)
return true;
else if(value.ToString.Length() == 5)
return false;
else
return !true && !false;
Более того, если это переписать на С++, компилятор все равно оптимизирует что индусятину, что прекрасный код. !true && !false точно уйдет.
Самолеты не летают. Предзаказы отменены. Новых контрактов на авиасалоне не заключено.
поправлю вас — «сделанные дешевыми индусами».
Может, следует поправить сразу до "сделанных дешевыми программистами"? И даже не "дешевыми", а просто "плохими"?
У нас тут тоже завелись индусы, и их всё больше. Жду когда нас призовут переходить с С++ на Яву
Как проверить, что функция, перемножающая два числа и делящая результат на третье, работает всегда корректно? Кроме "открыть, почитать, подумать", я другого способа не вижу. Можно скормить ей произвольные данные, но это будет вероятностный тест. Вдруг внутри этой функции какое-то значение промежуточного результата используется как код ошибки? Это отсылка к функции MulDiv из winbase.h.
Речь о том, что люди, которые выползли из трущоб не могут мыслить широко и глубоко, иначе они бы не жили там десятилетиями. А те, кто могут, уверяю вас, уже давно там не живут и работают далеко не за 10, а может даже и не за 40 в час.
Качественно протестировать код тоже стоит денег и хороших инженеров. Кстати если брать метрики за строчки кода (да, такие встречаются), то протестировать строчку кода стоит примерно в 2 раза дороже (в часах), чем её написать.
Например у меня была история с одним самолетом. Было, казалось бы, пустяковое изменение — изменение частоты процесса в 2 раза. Это не подразумевало никаких других изменений в коде и тестах, а тесты стали падать (т.к. их требовалось просто перепрогнать). Весь модуль был давно написан и протестирован (угадайте с одной попытки — кем ;)). Но даже когда он попал к нам, специалисты уровня Middle не смогли даже подступиться к причине на первом этапе.
Чтобы не раздувать пост, скажу только что были требования, был код, написанный четко по этим требованиям, и тесты, которые, о боже, тоже написаны по требованиями. Проблема была в том, что требования были неоднозначны.
За полтора года за не сколько итераций удалось привести требования в нормальный вид, и тесты заодно. Почему так долго? Потому что вместо того чтобы плавно и аккуратно исправлять косяки на следующей итерации они выкатывают один CR за 2 дня до дедлайна, в котором «запилены» все непонятные_им_проблемы_в_виде_костылей. Инженер, который не принимал участие в тестировании этого модуля сразу упадет в обморок. Человек с опытом будет громко кричать что это всё г****но и надо переделать, но большинство его замечаний будет проигнорировано. Там по большому счету надо было пару месяцев плотной переписки, чтобы всё привести в порядок. А когда это 2 дня раз в 5 месяцев… ну сами понимаете.
А вот код не успели, потому что сертификация закончилась и времени и бюджета на исправление косяка в одну строчку уже не было, хотя первый раз я им ткнул на эту строчку за подлгода до дедлайна.
К чему это я…
А к тому, что даже очень опытный и дотошный тестировщик не имеет нормальных возможностей убедить разработчиков исправить косяк до того, как этот код начнет перевозить пассажиров. В тех реалиях, которые есть на данный момент.
Вот так оно и есть. Вся эта возня с делегированием задач оправдывает себя, если работник обладает собственными разумом. Индусу сказали копать — он и копает, не загружая мозг посторонними задачами.
Вы составили ТЗ, индус что-то написал в точном соответствии с ТЗ. Но тут внезапно оказывается, что то, что для вас очевидно, для индуса не является таковым. В итоге ТЗ выполнено, но на выходе совсем не то, что вы ожидали. Поэтому приходится уточнять ТЗ и отправлять на доработку и т.д. Но у вас нет времени на переделку, поэтому в какой-то момент просто принимаете работу в том виде, в котором она есть.
Чтобы индус написал нужный код, придётся скрупулёзно составлять ТЗ, расписывая всё до самых мелочей. И в какой-то момент окажется, что накладные расходы на делегирование задачи окажутся выше, чем решение задачи собственными силами. И если в случае штатных сотрудников такое оправдано (сотрудник наберётся опыта и станет более автономным), то в случае аутсорса каждый раз нужно начинать всё с нуля.
Что касается исходной статьи, ты прав, в целом она — «плач Ярославны» про то, что хороших американских инженеров заменяют в пропорции 1 к 5 на неопытных инженеров из Индии (собственно, большая часть статьи — слова бывших/уволенных инженеров), что со временем должно привести к плачевным результатам (тут я согласен, и, некоторым образом, жду отложенного эффекта). Даже такая пропорция не позволяет компенсировать опыт, необходимый в авиационной индустрии для разработки новых устройств, хоть и позволяет значительно сэкономить.
При этом, если почитать другие статьи по теме MCAS на том же Блумберге, можно увидеть, что основная проблема как раз не в софте — он мог вполне отработать согласно разработанным системным/функциональным требованиям.
Ошибки, скорее, оказались заложены еще на уровне разработки системы (стандарт ARP-4754A), и, что еще точнее, на уровне проведения анализов отказобезопасности (ARP-4761).
В тех самых других статьях писали, что изначально система MCAS должна была компенсировать кабрирование самолета (задирание носа) на малых скоростях из-за изменения расположения новых двигателей под крылом и изменение направления их вектора тяги, при этом за раз она могла уменьшить это самое задирание носа на 0.5 градуса.
Функционал устройства был согласован с экспертами отказобезопасности FAA и ему был назначен уровень критичности B по стандарту DO-178C (собственно, устройство не приводящее к катастрофе в случае отказа, но при этом уже возникают вопросы — как даже для уровня б разрешили снимать данные с одного датчика угла атаки...).
Ну и далее пошли совсем странные вещи (ручаться не буду, рядом совсем не стоял, но пишут): эксперты FAA были изрядно завалены работой, поэтому анализ отказобезопасности они делегировали инженерам Боинга, «тут-то им фишка и поперла» — устройство неожиданно стало «исправлять» задирание носа не на 0.5 градуса, а на 2.5, при этом делать это не один раз, а много раз, последовательно, что сделало возможным катастрофические последствия, которые и реализовались (если не ошибаюсь, в первом случае отказал датчик угла атаки, во втором — там что-то провода отсоединились от датчика из-за тряски на взлете).
Т.е. по факту — разработчикам спустили какие-то требования, может быть ни их реализовали правильно, проверить их тоже могли вполне полностью и хорошо, но кто из разработчиков кода или тестов задумывается, почему один из выходов изменил диапазон рабочий с 0.5 до 2.5? Нет таких в принципе, эти должны заниматься писатели системных требований и safety engineer, который и делает анализ отказобезопасности.
В целом же, по ситуации можно сказать следующе — боинг давит всех своих поставщиков последние несколько лет очень активно на предмет снижения стоимости поставки устройств и сервисов, те вынуждены снижать издержки за счет дешевого аутсорсинга (это все-таки из разрешенных методов), вынуждены объединяться для противостояния давлению боинга (RCI + UTC + (возможно) Raytheon) и т.п.
Боинг, в свою очередь, возвращает разработку некоторых устройств, в частности Flight Control, FBW и т.п. внутрь себя, тоже сокращает собственные издержки за счет увольнения опытных и найма пачек неопытных и так далее. В целом, в индустрии идут довольно сильные изменения, которые снаружи могут быть не так заметны.
Там жесть жестяная. Фактически, 737 «сертифицировался» не FAA, а самой корпорацией Boeing.
FAA «делегировала полномочия по сертификации» разработанного тем, кто это разрабатывал.
www.nytimes.com/2019/03/26/us/politics/boeing-faa.html
medium.com/@alexlee611/faa-delegates-aircraft-certification-to-boeing-and-yet-they-recorded-the-best-safety-record-ever-e72fc38af274
Потому что точно так же любая другая госконтора может «делегировать» надзор за Боингом кому-то другому, в том числе и менеджерам самого Боинга :)
Код реально писали индусы (у нас был доступ к VCS с историей коммитов), и да, код был плохим. При том, что на каждый маленький модуль было четкое описание, что он должен получать и отдавать, они умудрялись написать код, не соответствующий этим требованиям.
Мы не разрабатывали код, мы только писали юнит-тесты на готовый код, сами же их прогоняли и в случае каких-то несоответствий с документацией писали репорты по установленным образцам. Все это перепроверялось старшими, а потом отсылалось на уровень выше. Что там дальше с этими репортами происходило, я не знаю, но обычно потом ошибки фиксились в новых ревизиях. Я был всего лишь джуном на аутсорсе, и у меня естественно не было полной картины происходящего.
“Генеральное руководство компании”, — говорится в заявлении, — “не участвовало в данной проверке”.
один из менеджеров на всеобщем собрании заявил, что компания Боинг не нуждается в сеньорах, так как их продукты уже достаточно зрелые.
Мне вот довелось — врагу не пожелаю. Описывать элементарную задачу пришлось несколько раз и в конечном варианте я написал спеку… которою можно было копипастить в код… что они и сделали наделав еще и ошибок.
Нет, я допускаю что мне не повезло с конкретными индусами, но только они работали на подряде у автомобильного гиганта с мировым именем.
Размер нет, а сложная схема передачи ответственности вполне может спасти головы в руководстве, но всё зависит от уровня возникших проблем. Моё личное ИМХО если бы вторым самолётом оказался самолёт American airlines, уже бы не один человек считал годы до окончания срока...
Если сравнивать с однокурсниками, это было чуть ниже среднего. Но зато было интересно )).
Ну и опять же, мы не знаем, сколько из этих $9 в час забирал аутсорсер. Программисты же компании-заказчику обходились в $9 в час. Если аутсорсер ещё минимум 30% забирал, то всё вообще плохо. Хотя в оригинале статьи и написано, что это был именно доход разработчиков, но кто знает.
Если взять разработку в самой Boeing, где есть инженер, заложивший дублирование, тест-писатель, описавший известные ему и компании случаи отказов в тестах, и менеджер, который не примет код до того, как он пройдёт тесты — то да, можно заменить разработчика на дешёвого. Будет ли дешевле час работы сотрудника за $50 или неделя возни и возвратов индусу с $9 — другой вопрос.
А если вся задача делегирована людям, которые, условно, раньше делали софт уровня 1С — то ТЗ будет выглядеть как «типа надо компенсировать недостаток манёвренности», тесты буду выглядеть как «взлетаем, не хватает управления, триммирование включается, всё хорошо начальникама» — разработчик ПО (который, в отличие от менеджера и инженера, не обязан хоть что-то знать про самолёты) мог написать с первого раза идеальный код, который на 100% делает ровно то, что описано в ТЗ.
Но ТЗ неадекватно требованиям к подсистемам в авиации. В этом и проблема, насколько я понял — в делегировании проектирования целых подсистем в компании-подрядчики
Мне знакома изнутри ситуация, когда компания сначала зарабатывает себе имя и репутацию, растёт, и в какой-то момент оказывается, что заказов набрали больше, чем возможно выполнить. И менеджмент принимает решение воспользоваться контракторами, стажерами, вообще всеми подряд, лишь бы побольше и подешевле.
Что, в свою очередь, приводит к снижению качества, потере репутации, ухудшению продаж, увольнениям и в конце концов к коллапсу.
Да, у Boeing запас прочности большой, но вот этот «эффективный менеджмент» и погоня за краткосрочными прибылями точно до добра не доведёт.
Чтобы не путать с IA-64, которую Intel выкатила двумя годами ранее.
Вспоминается как минимум K6-III vs Pentium 3
K6-III нет, т.к. это был рывок только по сравнению с К6-2, и лебединая песня всей тогда уже бесповоротно устаревшей архитектуры. Athlon XP конкурировал на равных, хоть и не был лидером, зато его младший брат Duron рвал в нижнем сегменте Celeronы как Тузик грелку. Звездный час у них наступил с появлением Athlon 64. Вот тогда они уложили Pentium 4 на обе лопатки. Сначала с появлением 64-битного ядра, потом они же первыми вывели на рынок многоядерные процессоры.
Вообще, как по мне, сейчас АМД находится в стратегически более выигрышной позиции, и по сути, это плоды уже находящегося в далёком прошлом решения — продать свои фабрики. Риски и огромную стоимость освоения новых техпроцессов они делегировали контрактным производителям, и те с ними вполне справляются. А Intel пытается их тянуть на себе, и пока неуспешно. А когда освоят свои 10nm, TSMC уже даст для АМД 5 nm и так далее.
Делать что-то с нуля они скорее всего не вытянут, а из современного успешного выбора и нет.
Хорошо сказано. Беда в том, что у монополиста обычно запас капитала большой. Плюс инертность покупателей и долгосрочные поставки. В итоге, когда жареный петух клюет, компания нехотя начинает вновь следить за качеством.
Из недавнего: Intel. Боинг тоже не помрёт.
А если в ценах и долларах 2010, это вообще 30 получалось, в то время вполне себе средняя зарплата даже для инженеров, не говоря уж о программистах
А вот тут другие данные
Инженеры в Индии зарабатывали около $5 в час, сейчас это $9 или $10, в сравнении с $35-40 для тех, кто находится в США по визе H1B, добавляет Хильдерман. Но он объясняет своим клиентам, что в реальности, дешевая цена за час равняется примерно $80, из-за необходимости контроля,
Вот самая важная часть статьи. Это критика «эффективных менеджеров», которые сокращая расходы втрое увеличили их вдвое. И очередное напоминание что чудес не бывает
Существует ФОТ для департамента, в котором обитают программисты. Финансисты, в процессах разработки ПО не понимающие ничего, и потому ставящие расходы на разработку ПО в один ряд с расходами на закупки, спустили сверху указание «Снизить ФОТ на 20%». Возможно, даже реальной необходимости в этом и не было, а просто новый начальник решил выслужиться перед высшим руководством с самого начала. Или KPI ему самому такой прописали. Но указание сверху получено, пришлось взять под козырек Менеджеры нижнего звена поменяли часть дорогих офисных программистов на дешевых оутсорсеров и обновили свои резюме, чтобы свалить, когда придет время платить по счетам. И, в общем, не так уж они и виноваты — правила игры задаются сверху, и объяснять тут что-то бесполезно.
Это совершенно нормальная практика сейчас для не-программистких крупных предприятий, скорее, странно, когда бывает наоборот. Краткосрочные цели годовой прибыли имеют преимущество перед долгосрочными целями развития компании. Есть курс и прибыльность акций — это главное. Поэтому любой ценой надо добиться прибыльности в этом году, а в следующем — зальем деньгами от повышения курса этот проблемный участок. Но иногда, редко, получается и вот так, как с Боингом.
Те же индусы едут в США, пытаясь зарабатывать среднюю ЗП по рынку, причем они идут на всякие хитрости, чтобы скрыть свой низкий уровень образования/обучения. Иногда едут в США как body shopper ы, зарабатывая 1/2 средней ЗП, потом меняя работу на нормальную. Они везде, в общем. Лезут во все щели, ибо для них такая сытая жизнь великое благо, а благодаря уже осевшим индусам в корпорациях их и берут чаще, более лояльны к визовому спонсорству. Кто ее видел Кремниевую долину тот, в частности, не ощутил лёгкую панику от вездесущих индусских программистов.)
Знаю компанию, которая работала с Боингом, продавала час за $40, а сотрудникам платила фикс 20-30 тыщ(по ценам середины 2000х, не знаю, как сейчас, но вряд ли в корне изменилось).
И кстати, ходит там легенда, что один проект отдали индусам со словами «у них дешевле, передайте проект с доками» и год вернулись со словами «сколько будет стоить вернуть проект в читаемое и рабочее состояние?» — то, что наворотили индусы, ещё 5 месяцев разгребали и приводили во вменяемое состояние.
К счастью у нас для тестов была так круто разработана методика тестирования, что испортить её даже индусы не могли (хотя пытались, честно)))
Её мы применяли для всех новых и переделанных индусовских тестов.
Кстати в какой-то момент заказчик отдал кучу работы китайцам. Сначала было нормально, пока, видимо, самые умные китайцы стажировались в США. А вот когда они вернулись домой и стали учить своих коллег. Результат стал очень сильно похож на индусовский код. Сложно сказать — какой лучше, а какой хуже… он просто чуть другой :)
It was my first serious job, I got such a great experience, I went through so many trainings and learned english at work. / Это была моя первая серьёзная работа, я получил отличный опыт, ходил на всякие тренинги и учил английский прямо на работе
Nice place to start your aviation career and extend the engineering knowledge in aviation / Отличное место, чтобы начать свою карьеру в авиастроении и улучшить инженерные знания по авиации
Один мой знакомый туда рвался, потом сходил на собес или два, поговорил с кем-то из сотрудников, посмотрел на офис и свернул удочки с формулировкой типа: «Да это ж конвейерная соковыжималка для студентов: берут за копейки совершенно зелёных ребят, заставляют работать в режиме аврала 12 часов в сутки плюс обучение прямо по ходу, как только ребята начинают немного разбираться в теме и сбегают из рабства, набираем новых». При этом он не как прогер туда ходил, а как инженер-конструктор, так что там, похоже, подход один ко всем этапам разработки и своё мнение насчёт того, кому из российских специалистов стоит доверять разработку современного самолёта.
FYI у нас в регионе (на восточном побережье) минималка $9, это уровень уборщиц.
На западном побережье, где боинг, уже и уборщицы не получают $9 в час.
у меня была работа джуном — я получал 25 тысяч рублей в месяц
с клиента брали 1200 рублей за 1 час моей работы
но это рекорд был, обычно брали 600-800, что все равно интересно,
т.к. мне за 1 час давали 125 рублей примерно
Тут надо понимать, что я не возражал, мне нравилось учиться, кроме того калькуляция стоимости часа фирмы учитывает массу побочных расходов, те же компы, тот же отдел бухгалтерии, та же уборщица, тот же сисадмин — все они должны были что-то кушать, ну и масса других нош, которые несет фирма по сравнению с фрилансером
Я к тому, что надо уточнить — расценка за 1 час для клиента или действительна зарплата. Если смотреть по расценкам для клиента, то расценки я бы сказал нормальные даже в РФ. Может быть, даже низкие местами. Там где я работал, фирма бы и разговаривать не стала за такой прайс )
А я так понял что $9 получает компания-аутсорсер. А зная что маржа таких компаний обычно не менее 50%, то индус получает $4.5 до налогов.
и миллионов строк кода,
Вот этот момент интересен. Это считали вместе с кодом операционок, видеоплейеров и прочего в довесок? Код программы автоматики управления вряд ли может иметь миллионы строк. Или там действительно нужны эти самые миллионы строк?
Однако то, что заливается в контроллер, разворачивает связанные библиотеки (как минимум, cmsis для взаимодействия с железом и math) и занимает уже десятки тысяч строк кода (С) или сотни (инструкции процессора).
Если добавить сюда работу нескольких дублированных устройств, сетевой протокол, механизм голосования/выбора неисправных, и всё это так же будет содержать библиотеки — вот вам и миллионы строк кода (инструкций).
У настоящих микроконтроллеров (AVR, PIC, STM и далее) и обвязки к ним довольно мало место в ПЗУ, поэтому никакие миллионы строк там физически не уместятся. А каждые 2 КБ сверху стоят около ста евро в прайсе Siemens.
Заодно поржал от наличия в скобочках STM наравне с PIC и AVR.
— С уважением,
Генрих Мюллер, группенфюрер
Ну и да, я в своих личностных характеристиках несколько скромнее, и думаю, что если где-то и сморозил глупость, то вполне приемлемую — я с МК не работаю, пересекался раз или два по работе и когда делал маленького робота.
— С уважением,
Генрих Мюллер, группенфюрер
Естественно, речь не о ядрах ARM Cortex A*, а о линейках M и R.
ARM занимает 37% общего рынка МК и более 50% рынка IoT. Квадрокоптеры все на АРМах, автомобили на них переходят. Сейчас не проблема найти МК с ПЗУ 512кб или даже 1024кб.
Ранее я работал с 8 битными МКшками, и на момент написания своего комментария полностью забыл о существовании ARM Cortex-M.
Посыпаю голову пеплом.
Мне, наверное, не стоило комментировать на тему, в которой я недостаточно разбираюсь.
Во-вторых, думаю, в 737 Max стоят сотни устройств с МК внутри (я не учитываю развлекательные панели в креслах, только авионику и автоматику), и если в каждом хотя бы по тысяче строк кода на асме — это уже миллионы строк. Здесь нет речи о ревизиях, разных моделях и комплектациях.
Платят, думаю, почасовую ставку, и в этом может быть одна из проблем — на мой взгляд, инженеру лучше платить за выполнение хорошо поставленной задачи, покрытой тестами и имеющей чёткие критерии выполнения и работоспособности, но увы.
Если добавить сюда работу нескольких дублированных устройств, сетевой протокол, механизм голосования/выбора неисправных, и всё это так же будет содержать библиотеки
Практически не будет. Мы всё это делали почти без всяких библиотек на Миландровском контроллере и на таком чуде, как аналог TMS3020C3 (да, для ВПК). Кстати, если кто случайно знает для TMS320C3 компилятор хотя бы с Си99, буду очень благодарен за информацию, где его можно взять (а то Си89 на нём уже достал). :)
Блок в смысле ECU с мелким реалтаймовым МК, или всё-таки речь про голову с цветным экраном?
У меня машина начала нулевых, и там вся прошивка весит сотню килобайт для ECU и десятки кб для всяких блоков комфорта.
Эксперты вынуждены уходить в другие отрасли с направлений, где они были сильны, потому что их работа обесценена «молодыми» специалистами, умеющими считать лишь на калькуляторах (условное название всех «помогайзеров»). Доходит до того, что электротехники не знают закон Ома.
В итоге проблемой для заказчика (желающего нормальной работы) стало НАЙТИ тех, кто МОЖЕТ нормально спроектировать в куче-мале псевдоспециалистов.
Если в промышленных гигантах, ответственных за человеческие жизни, такая неразбериха с процессами, то о чем говорить в более мелких конторах
Как раз наоборот: вероятнее, что именно в маленькой конторе подойдут к процессу проектирования с большим вниманием и ответственностью. А в «промышленных гигантах» обязательно найдутся тучи «эффективных менеджеров», озабоченных лишь снижением издержек и повышением прибыли.
Наша главная цель — всегда быть уверенными в том, что наши продукты безопасны, высочайшего качества и выполнены по всем правилам
Наглая, паршивая ложь. Ненавижу менеджеров за это.
Уже ж выяснилось что Боинг намеренно не сказал пилотам про эту систему mcas. Они руководствовались лишь одним — не просрать сроки и не допустить доминирование airbus
Кому лень гуглить/вникать — краткое содержание:
На предыдущий моделях 737 у летчиков и mcas (а также остальных систем управления стабилизатором было 2 отдельных электромотора, runaway stabilizer отключал электромотор автоматики, в то время как пилоты по прежнему могли пользоваться своим электромотором для управления стабилизатором). На Max решили сэкономить и завели все на один общий электромотор. Соотвественно, единственным способом управлять стабилизатором после runaway stabilizer (который на Max обесточивает этот единственный мотор) можно только вручную через тросики, что экипаж эфиопской компании и пытался делать. Только, как выяснилось, что на скорости >300 км/ч это уже выше пределов человеческих возможностей, в чем пилоты довольно быстро и убедились (на взлете у них скорость была сильно выше). После чего пилоты решили включить мотор обратно, видимо чтобы управлять стабилизатором со штурвала, но тут им просто не повезло т.к MCAS на включении моментально загнала их в штопор.
Резюме — офигительно боинг помог со своей инструкцией после первой катастрофы (где они как раз акцентировали внимание на runaway stabilizer)
Даьи вообще эти фразы НАША цель безопасность… блабла, наша цель сделать мир лучше, наша цель сплотить общество… это все такая лапша противно даже. Ниразу таких целей не слышал на собраниях инвесторов или топ руководителей
Нет разу не слышал на собраниях, чтобы глава фирмы открыто озвучил свои цели. Обычно давят на совесть: нам верят клиенты, мы должны сделать все, что можем. При этом всем ясно, что в заявленный срок никогда не получится сделать качественно. Идёт подгонка под требования приемки, а не под опыт реальной работы у заказчика.
Работа пиарщика врать. Вам и мне противно. Ему часто тоже.
один из сотрудников пожаловался, что 18 раз отправил чертежи команде в Россию, прежде чем они поняли, что детекторы дыма должны быть подключены к электрической системе
То есть боинговские сеньоры смогли предоставить техдокументацию надлежащего качества только с 18 попытки. Может тогда и правильно их аутсорсерами заменили?
Интересно-интересно.
Как эксперт, расскажите, что изменилось за 18 попыток: эти ужасные русские выучили-таки английский или страдающие от аутсорса боинговские инженеры техдокументацию на русский перевели?
Однажды знакомые ребята меня попросили узнать, сколько будет стоить на российском заводе выточить одну деталь из цельного куска алюминиевой плиты. Кое-как на пальцах объяснили, что они хотят, я кое-как сделал 3D модельку, сделал несколько скриншотов разных сечений, указал размеры в мм и отправил на известные мне заводы мехобработки. Дело было осенью 2015 года, когда с экономикой было ну совсем все плохо. Из всех заводов мне ответил только один, что, дескать, пока документация не по ЕСКД они ничего считать не будут. На мой уточняющий вопрос, могут ли они привести имеющиеся данные к ЕСКД за деньги, мне с завода уже никто не ответил.
С тех пор, знакомые ребята сотрудничают с китайцами — они, конечно, не очень, зато сообразительности им не занимать, когда дело деньгами хотя бы пахнет.
НО все меняется, когда вы начинаете работать с людьми, простыми, но хотящими что-то сделать. Такие есть, они даже что-то знают и умеют делать, но их уровень не позволяет им готовить все необходимое в соответствии с представленными требованиями. В таком случае, по-человечески, можно сделать какой-то сервис, который будет говорить с клиентом, принимать модель и проставлять опущенные детали, опираясь на область применения детали. Если это обычная хоббийная штучка, то там 0.1мм будет вполне себе нормальным допуском.
Теже китайцы просто не парятся на эту тему, есть какой-то обычный допуск для станка, например 0.05 мм и они с ним делают детали не задавая лишних вопросов.
В России на сайтах всяких компаний черт ногу сломит, прежде чем найти хоть какую-то информацию о том, как сделать заказ и т.д.
Допуски всё же не просто так, возможно ваша модель была оценена технологом "на глазок" в сумму, подразумевающую что вы не захотите её платить если даже чертежи толком сделать не можете, штучное производство всё же иметь особенности.
И про допуска, допуск не просто в n-xxxxxметров, он ещё в плюс и в минус и это не просто так...
В результате плиту продали, материал закупали уже китайцы и делали же китайцы.
Конечно, ценообразование в России и в Китае отличается, но в России мы даже до цен не дошли.
Завод можно понять, на кой ему единичная возня с некрупным заказом?
Но только вы никогда не узнаете, какой у вас случай до того момента, пока вы не доведете первый заказ до ума.
Вот например я делаю маленькие устройства для себя. Если у меня получится устройство, которым заинтересуются другие, я могу заказать больше и начать их продавать в малом объеме. Начальный доход от продаж позволит мне создать стартовый капитал. Я смогу оценить рынок, изучить аудиторию, исправить ошибки и довести устройство до качественно нового уровня. Сделать вторую версию гораздо лучше первой и продать еще больше устройств.
Но только если никто не согласится делать мне то самое первое устройство в буквально единичном экземпляре, я никогда не смогу выйти на рынок.
Как итог мы имеет плохие устройства на рынке, потому что люди, способные сделать лучше, не могут их реализовать по причине отсутствия средств, а компании не заинтересованы в новинках, пока нет конкуренции.
Получается замкнутый круг, разорвать который могут только заводы, у которых есть реальная возможность что-то производить. Но им лень, ибо проще отшивать людей формальностями и жить за счет госзаказов или 2-3 больших клиентов.
ТаоБао вообще задуман как оптовая площадка. Там никто не будет вам что-то поштучно делать. А вот на AliExpress вполне можно найти конторки, которые могут делать что-то практически поштучно, просто дорого.
ТаоБао вообще задуман как оптовая площадка. Там никто не будет вам что-то поштучно делать.Об этом я и писал. Завод вообще задуман как оптовый производитель. Потому там обычно не связываются со штучными заказами.
А вот на AliExpress вполне можно найти конторки, которые могут делать что-то практически поштучно, просто дорого.А это уже не завод а скажем мастерские.
Вот как раз он за деньги клиента готов хоть фоторамку из чугуния выфрезеровать.
И довольно интересно о процессе пишет.
Вы может с Алибабой спутали?
На публичную почту завода наверняка ежедневно приходит тонна спама с коммерческими предложениями от кулибиных разного калибра. Если отвечать каждому, то потребуется отдельного человека на это заводить. Будет ли конверсия кулибиных покрывать затраты на поддержание штучного производства?
По человечески тоже все просто. Почту читает человек, который допуски считать не умеет. Напрямую обратиться к человеку, умеющему считать, он не может/не хочет. Нужно задействовать насяльнике, а он в отпуске..
«Выточить с помощью стажера и какой-то матери напильником, точность — на глаз: ХХХ руб.
На обрабатывающем центре по программе подготовленной инженером по согласованному с заказчиком ТЗЖ 2*ХХХ руб.
То же но с командировкой инжинера для уточнения ТЗ к заказчику: 5*ХХХ руб.
То же но с перевозкой обрабатывающего центра к заказчику и выполнения работ на месте: ХХХ^5 руб.»
Получит ли он премию, если начнет переписку с выяснением, что именно нужно делать и сколько это будет стоить? (Нет)
Получит ли он выговор за то, что отрывает от работы кучу народа? (Возможно)
По человечески оно где-то так…
есть какой-то обычный допуск для станка, например 0.05 мм
Я знаю одного "бухгалтера", который в «домашних условиях» выдаёт точность 0.01 мм.
Согласен.
Неправда, китайцы очень любят раздувать штат, чем больше штат, тем более серьезная у тебя Компания. И работа с клиентами — одна из точек раздувания. Просто они больше нацелены на результат.
1) Китайцы готовы делать горбатого. Т.е. ты скидываешь им какую-то херню, они её делают, что-то косячат, что-то додумывают и так далее. Но как итог, ты получаешь деталь.
2) У нас обсуждение начинается с документации. Ибо инженер на заводе знает, что если он сделает что-то горбатое, сам что-то додумает, то потом к нему же придут и скажут «Нахера ты это делал. Вот претензия от заказчика, исправляй как хочешь или плати из своего кармана!». Поэтому без нормальной документации никто зад не поднимет.
__
Это как в IT. Кто-то работает с заказчиками, которые сами не знают, что им надо и требуется. А кто-то любые заявки без четкого ТЗ даже рассматривать не будут.
Да, первые получают больше заказов по итогу, но если ты сам прямой, то со вторыми работать надежней.
А если посмотреть на эту модель со стороны, то очень-очень часто самые большие деньги могут прийти от тех клиентов, у которых нет ТЗ на то, что им требуется.
Взгляните, у кого будет самое подробное ТЗ на заказ? Только у того, кто сам знает-умеет-занимался. Скорее всего у него просто станков на текущий заказ не хватает, вот и дозаказал у посредника. Ещё он в мелочах знает вашу структуру издержек и будет торговаться так, чтобы оставить вас на грани маржинальности.
Противопоставим этому какой-либо программный продукт со схемой прямых продаж: вы сами стучитесь к клиенту (даже не ждёте пока он к вам), отлично знаете боли в его бизнесе (верифицируете, что у него они действительно есть), предлагаете как эксперт готовое решение и готовы объяснить, как и почему оно поможет.
Вот там как раз и начинается большая маржа, потому что клиент не знает вашу специфику, не хочет в ней разбираться, зато вы его боли (и сколько он готов платить) знаете прекрасно.
1) Что там через этот «вентиль» будет идти, где этот кран будет применяться, от этого весьма некисло зависит какие допуски можно сделать, т.к. для пивного крана и для вентиля, которым там метан будет перекрываться много чего различается, да хоть давление например, плюс если дриснет пивной кран — ну будет от бармена вонять пивом и бар закроется пораньше, а если дриснет метановый вентиль, то проблемы будут куда больше.
2) На какой станок надо зарядить эту деталь, на «Имени 20 летия Октябрьской революции» с Петровичем или на Mitushiba MegadrukerDrillerLatte. Цена работы этих станков как вы понимаете весьма некисло различается.
Можно врубить режим «И так сойдет», но тогда мы получим на выходе очередную деталь, которая будет являться массогабаритным макетом, который иногда(и не долго) может даже будет работать.
Ну или вам завод может выкатить «От 10000р до 1 млн. р.», что будет очень ценной и полезной информацией.
В конце концов, клиент готов платить, так почему бы с него не взять деньги еще и за это? Собственно пока у нас производство работает по принципу «без ТЗ результат ХЗ» все так и будет в жопе. Т.к. у нормальных людей принципы несколько иные — «У вас есть задача? Отлично. Мы ее решим, только платите». Чем меньше клиент думает тем больше он приносит денег. Так не заставляйте его излишне думать. А то он ведь додумается до того, что вы ему нахрен не уперлись.
Т.к. предприятие серийное, все бизнеса процессы заточены под серию, включая создание и утверждение документации, что выражается в чудовищный бюрократические проволоки в единичных заказах. По сути вы приходите на автомат и говорите выложите мне деталь, ясно что пошлют.
Такие работы для фирм персоналом человек 10, правда зачастую тогда нет термички и гальваники. В общем не там искали.
Зато в бизнесе бывает вот что: «Ой, нам какой-то хер написал, хочет штучный заказ сделать. Что ему ответить? — Да ну его нафиг, ещё с ним возиться».
И вот это самое — особенность, как ни странно, российского бизнеса.
Поэтому да, любой бизнес в любой стране пошлёт вас нафик, если вы на 5 порядков по платёжеспособности меньше основныъ клиентов.
Вообще, нет. В других странах на подобные предложения принято отвечать. Пусть с отказом: «Извините, мы ваш заказ не сможем выполнить вот по такой-то причине», но обоснованный ответ вы получите. Там не морозятся. Причем это касается не только европейского бизнеса, но и, например, китайского. Хотя китайцы нередко не отказывают, даже если и сделать не могут, там будут вокруг да около ходить с разными контрпредложениями, ибо все равно клиент, вдруг чего с него выгорит.
«Здравствуйте, яшкольникруководитель отдела из11Б физ-мат лицеяуважаемой компании, мне дляурока информатикиработы нужно написать веб-страничку для составления расписания дежурств моего11Ботдела.Сколько это будет стоит?Бутылки коньяка XO хватит?»
Обычно я за такие заказы берусь, если денег дают.
Аналог ВК habr.com/en/post/458188
спорим, такое могут сделать на фрилансе за деньги?
Решал похожую проблему в 2010. Довольно быстро нашёл предприятие (кажется, в Златоусте), которое вырезало из 80 мм алюминиевой плиты нужный корпус, и по цене в три раза меньшей, чем наш предыдущий смежник из Калуги.
Американцы могли даже разобраться с ГОСТами и перечертить все, я бы этому тоже не удивился.
Если вы оцениваете американских инженеров по байкам Задорнова, то обсуждать тут нечего.
Инженеры в Америке, как и в России сильно разные, соотношение раздолбаев и идиотов к нормальным там такое же как в России.
У меня множество знакомых именно из боинга (Россия), в том числе которые частенько в Америку в командировку ездили, по их отзывам там в целом так же как в России, маразма там не меньше, а кое где и больше. Так что идеализировать я б не стал.
Если конкретно про боинг, то чихать он хотел на ескд и ГОСТ, у них даже система единиц другая и работают в Москве по их инструкциям и нормам полностью. Плюс что боинг что аирбас любят прогибать под себя субподрядчиков (как по используемому по так и по стандартам)
А ещё я очень хорошо знаю русское «да пошло оно», «мне влом» и «нахрен он мне сдался». Так уж получилось, что я встречал это повсюду, от спившихся колхозников до руководителей компаний. Я знаю, что у инженеров это распространено реже, все таки есть какая-то профессиональная культура, но тоже проскакивает.
Работа обычно выстроена очень четко и такие проблемы всегда решаются.
Это делается за счёт бюрократии, рано или поздно она становится крайне неповоротливой и действует с большим лагом
Если нужно взаимодействовать с людьми говорящими на других языках и они совсем плохо говорят по-английски, то выгоднее нанять переводчика, чем терять время на бесполезные туда-сюда.
В данном то случае вся документация и инструкции на английском, в том числе все руководства, никакого отношения ни к ЕСКД ни к Российской нормативной документации отношения не имеющие.
А ещё я очень хорошо знаю русское «да пошло оно», «мне влом» и «нахрен он мне сдался».
Это, это есть, но пожалуй не только в россии, это скорее противление новому, хорошо видно на примере смены интерфейса программ.
соотношение раздолбаев и идиотов к нормальным там такое же как в России
Эм, вы работали во всехамериканскихроссийских компаниях и можете отвечать за все компании?
Бывает так, не спорю, но случается и вариант, в котором у сложной детали есть всего два размера — внешние габариты. И объяснить, что даже внешних габаритов надо минимум три — очень непросто. И ничего другого добиться не получается. Потому, что производится эта деталь на полуавтоматической линии, которую спроектировал один подрядчик, а произвел другой. А те, кто собственно делает и продает могут в лучшем случае рулеткой померить…
И это — из моего личного опыта — встречается намного чаще, чем описанное вами. Наши люди частенько работать не хотят — это да, но средний уровень инженерной грамотности кмк значительно выше.
Ну или по-другому сформулирую: у нас на заводах, особенно старорежимных, явно избыточное количество инженеров. В той же Германии много раз был на небольших заводах — так там запросто инженер будет один, остальные — так, мастера в лучшем случае. И этот инженер званием своим зело гордится, на визитках пишет, официальное обращение. У нас на схожем по выпуску заводе будет целый техотдел штаны протирать, и в цехах половина с вышкой…
отечественный ГИП/ГАП — это как раз и будет engineer по западному.
Наш инженер — это их техник (technician).
Наш техник — ха ха, раньше в ссср были, но сейчас все инженеры. На таких местах обычно вообще студенты на практике или просто «взяли толковую девочку и подучили кнопку нажимать».
Их техник высшего образования тамошнего не имеет, равно как и наш. Другой вопрос — насколько обоснованно будет проводить параллели между нашим и их средним инженером/техником. Но что лучшие наши инженеры лучших немецких нисколько не хуже — не сомневаюсь.
Наш техник — ха ха, раньше в ссср были, но сейчас все инженеры.
За все страны бывшего СССР не скажу, но, внезапно, техники в России и сейчас есть.
Наш инженер — это их техник (technician).
Это не так. technician — это наше среднее-специальное максимум, насколько я знаю.
Много работаю с немцами, англичанами, небольшой опыт работы с испанцами. У нас все делается намного быстрее и с меньшей бюрократией. Хуже всего работать с англичанами. Долго, дорого, низкое качество. Все эти штампы про умных трудолюбивых европейцев и ленивых русских порядочно надоели.
Да там по разному может быть, после института я приходил в Boeing в Москве к "прочнистам" они тогда напротив кремля сидели, условия такие:
- Полписываешь бумагу о том что согласен на платное обучение ПО и должен компенсировать его либо работой в течении 2-3 лет (не помню) либо выплатить пропорционально остатку срока при увольнении, сумма более 10000$
- Зарплата на это время в районе 15т.р.(2006-2007 год), до окончания рабства шансы на повышение около нуля (со слов нанимающего, намекающего что заокеанские манагеры не дураки)
- Режим работы офиса сменный либо с 6 утра либо с обеда либо к ночи (или 2 варианта) офис то дорогой аренду платить надо + лицензии на ПО. Смену вроде как можешь выбрать но всё не так просто.
- К концу рабства, если повезёт, могут быть командировки в США, могут не быть но права нужны…
В общем сами подумайте на кого там могли нарваться, ведь конкретный работник мог и Итальянскую забастовку устроить…
p.s. никого не хотел обидеть но был в шоке ;)
Как итог образование на свалке (очень нужное нашей стране да я помню...), и привет сектор финансов и программирование...
Вот про это:
"В 2008 году, во время встречи с главным инженером, ответственным за Boeing-787, один из сотрудников пожаловался, что 18 раз отправил чертежи команде в Россию, прежде чем они поняли, что детекторы дыма должны быть подключены к электрической системе".
Мне стало просто до безобразия интересно.
Если у кого-нибудь есть контакты знающие подробности — дайте знать, плиз.
Как по мне — так это выглядит либо придуманным от начала до конца (навроде истории с закладками в чипах Supermucro), либо здесь не хватает какой-то ключевой детали в повествовании. Ибо 18 раз — это перебор, ИМХО.
...18 раз он отправлял чертежи ХЗ куда, а после чего как с российской стороны наконец спросили «ну и когда нам пришлют чертежи?» сильно обиделся на невежливость вопроса и пошел жаловаться менеджеру.
Чуть выше оставил комментарий https://m.habr.com/ru/post/458224/comments/#comment_20342732
Если честно очень странно, даже с нами индусы не работают менее чем за 20 долларов в час… А тут боинг, здоровая компания, за 9 долларов в час, это только действительно, если студенты, но тогда им надо давать работу, которя вообще не связана с разработкой продукта, ну типа внутренний сайт для поддержки IT запросов, в параллель с запросами по почте…
18 раз отправил чертежи команде в Россию, прежде чем они поняли, что детекторы дыма должны быть подключены к электрической системеЗначит, чертежи такие
Нанимать индусов писать КОД — самое последнее дело. Хотя, не удивительно для Boeing, который решил сотрудничать с индусским Microsoft. Code of conduct им в помощь, как говорится)
Нет проблемы в двигателях, он ведь летает, есть проблема в нежелании пересертифицировать, менять программы обучения и т.д. а вот решение этих проблем было "некорректно закостылено"
Спасибо я знаком с этой особенностью, у современных самолётов много особенностей, но сами по себе они не являются проблемами.
Как у ан-148 включение подогрева трубок ППД не более чем за 20 минут, или как то что стабилизатор на Боинге 737 очень долго вручную крутить, можно их много найти, но если все варианты работы этих систем должным образом доносятся до пилотов и есть работающие способы преодолеть возникшие трудности штатно, то самолёты с этим летают, а вот Боинге приземлили из-за того что по их же инструкции с особенностями работы системы не справиться...
что может привести к остановке самолета
«Делать остановку» самолёты умеют только на земле.
Меня во всей этой истории беспокоит то, что код между моделями наверняка переиспользуется, вот и летай потом на Боингах. Ну или даже если не код, то подход к разработке точно...
Кажется, что-то подобное уже было
https://ko.com.ua/kachestvo_vstraivaemogo_po_ili_pogrom_vsyo-taki_sluchilsya_98518
Boeing-737 Max был обновлением конструкции 50-летней давности, и изменения должны были быть достаточно ограниченными, чтобы Боинг мог штамповать новые самолёты как горячие пирожки, с небольшими изменениями для сборочных линий или авиакомпаний. “Для инженера, это не самая лучшая работа”, добавил Лемм.
Странно, всегда думал, что жто наивсышый челендж для инженера. Что-то сродни «подковать блоху». На ферарри конечно после этого не уедешь, но ограниченные условия всегда заставляют блеснуть мыслью и необычным подходом.
К тому же новые движки, которые имеют другую массу, габариты, управление, и главное существнно бОльшую тягу. Именно эти факторы приводили к выводу на запредельные углы и сваливанию. «Пофиксили» введя MCAS. С единственным датчиком. С сигнальной лампочкой, которая ни разу не проверялась и по факту не работала.
и главное существнно бОльшую тягу.
10% — это «существенно большая» тяга? Самое главное преимущество — экономичность. Нос склонны задирать все 737 и классика и NG. У MAXа есть проблемы с управляемостью на закритических углах атаки.
С единственным датчиком.
У вас есть доказательство, что с единственным датчиком?.или вы переиначиваете то, что вам достоверно неизвестно? То, что нельзя опираться на единственный датчик, когда их в конструкции два — это понятно даже детсадовцам. Почему сделали именно так, что MCAS не отключилась, а использовала косячные показания — вопрос. Возможно проблема в архитектуре борт. компьютера. Возможно еще какие-то особенности, о которых мы не знаем. По крайней мере, на презентации патча, боинг даже словом не обмолвился, что MCAS перестанет опираться на кривые данные в случае дилеммы.
С сигнальной лампочкой, которая ни разу не проверялась и по факту не работала.
Вы откуда этот бред берете???
Табло IAS disagree горело во всех трех случаях. В первом случае экипаж все сделал правильно, два остальных закончились катастрофой.
И повторюсь: боинг — косяки признала и фиксит. Кто же пофиксит авиакомпании и пилотов? Обе катастрофы — следствие низкой квалификации экипажей.
По поводу датчиков. Да можете хоть увешаться ими как новогодняя елка. Если вы читаете вы только один это означает, что в _системе_ по-прежнему единственный датчик.
По поводу лампочки. Это не относится к катастрофам, Но мы тут обсуждаем вообще подходы к проектированию и выпуску 737MAX, поэтому проблемы с лампочкой, выявленные и пофикшенные уже _после_ выхода в production имеют прямое отношение к теме.
По поводу датчиков. Да можете хоть увешаться ими как новогодняя елка. Если вы читаете вы только один это означает, что в _системе_ по-прежнему единственный датчик.
Давайте исходить из того, что пресса о максах рассказывает на уровне «ученый изнасиловал журналиста». У вас откуда данные, что читается только один датчик? То, что в MCAS есть косяк — это понятно. Это даже ленивые уже обмусолили.
По поводу лампочки. Это не относится к катастрофам, Но мы тут обсуждаем вообще подходы к проектированию и выпуску 737MAX, поэтому проблемы с лампочкой, выявленные и пофикшенные уже _после_ выхода в production имеют прямое отношение к теме.
Что за история с лампочками? Как-то я это пропустил.
Ну и подходы боинга понятны. Осталось понять, почему не обсуждаются подходы АВИАКОМПАНИЙ? Пилоты явно виноваты в обоих катастрофах. Боинг свои косяки исправит. Кто же исправит пилотов?
У вас откуда данные, что читается только один датчик?
Не читается, а читался. Теперь об этом можно говорить в прошедшем времени.
О том что это так работало известно из множества публикаций. О том что это *теперь* не так и читаются оба — указано в манифесте к очередному софтверному апдейту к MCAS. В нем явно и недвусмысленно сказано, что *теперь* MCAS читает оба датчика и сравнивает их показания и рассказано как эти показания сравниваются и что система делает когда они рассогласованы. Наличие фикса проблемы явно признает наличие самой проблемы. Кроме того, проблемы именно с одним датчиком приводили к неадекватной работе MCAS.
Как-то я это пропустил.
Про лампочки — я в вас верю. Вы разберетесь. Начните с чтения статьи, которую мы тут обсуждаем. Тут про лампочки тоже говорится.
Что касается авиакомпаний — из вина, видимо, обсуждается в комментариях к другим статьям. Тут про боинг.
Начните с чтения статьи, которую мы тут обсуждаем.
Эту статью я перестал читать после слов «систему MCAS, по вине которой произошли две катастрофы». Уровень желтизны просто зашкаливает. Не хочу засирать мозг.
Что касается авиакомпаний — из вина, видимо, обсуждается в комментариях к. другим статьям. Тут про боинг.
Вы уж извините, что влезаю в ваш уютный мирок, но боинг и авиакомпании связаны неразрывно. Если уж обсуждаются катастрофы максов, то не указывать вину пилотов нельзя.
Простите, а что именно в этой статье написано про лампочки? Я нашел только вот это:
Также, по словам Боинга, ни одна из этих компаний не связана с проблемой, обнаруженной после катастроф — неработающей у большинства покупателей сигнальной лампой в кабине.
Но тут не написано никакой конкретики, как будто всем уже известно про эти самые неработающие лампочки. А это не так, я вот впервые про них читаю. И есть сильное подозрение, что автор что-то напутал.
Другое дело, что конкуренция на рынке порой заставляет производителей выжимать все соки, строить не эффективную систему производства (эффективность стоит дополнительных денег) а потом все ахают «как такое получилось»?
Да и зарплата ничего не говорит о скилах. Один и тот же индус в Индии будет зарабатывать $9 в час, а в США — $50 и больше.
Смысл в том, что проектировать систему, код писать и его тестировать должна элита — нельзя в таких системах допускать никаких «детских» ошибок, просто по определению. То, что у HCL или у кого там 18к человек в бодишопе американском — это как раз показатель, что всё плохо, а не хорошо. Уберите вообще аргумент про з/п и ответьте — хотели бы вы, чтобы ваши знакомые программисты (естественно, не имевшие опыта в авиации), писали бы код для самолета, на котором вы полетите? При этом будет и стоимость проекта и дедлайн, то есть они не могут код писать и тестировать 30 лет, никто не даст.
Хотя, конечно, сложный датчик может имеет свой софт внутри, но за него отвечает другая компания — производитель датчика. И они не индусы.
Увольнение инженеров и особенно ведущих инженеров — это более правдоподобная причина. И, судя по статье, прослеживается попытка спихнуть с больной головы, нет не на здоровую, но на существенно менее больную.
Поэтому компании, типа Боинга, которое производят железо — начинают сильно проседать из-за уровня зп инженеров. (Плюс опять же конкуенция в лице Аирбас из Европы, где нет таких раздутых зп).
Поэтому, они и ищут способ снизить издержки, переводя разработку софта и узлов (тут как раз Россия) на аутсорс. Что из этого получается горбатый — ну это риски аутсорса.
Это все произошло из-за компаний типа Гугла, Оракла, Амазона и Майкрософта, которые по сути продают воздух.То же самое что электричество или связь воздухом назвать.
Нет, конечно, означенные вами компании не выпускают воздух и вовсе не они привели к росту зарплат инженеров. Это рынок. Если на рынке не хватает специалистов в какой-то области, то ищут на стороне и поднимают зарплаты. Искать на стороне — есть квоты квоты на рабочие визы. Этих квот не хватает и на несколько дней. Своих специалистов — выпускают, разумеется, с задержкой на время обучения. Т.е. зарплату подняли сегодня, а приток на рынке от этого будет через несколько лет. Т.е. это работает медленно. Да и, в принципе, не такие уж и высокие эти зарплаты. В настоящее время, я говорю о восточном побережье Штатов, не-junior программист получает от 100 до 180. Основные предложения в районе от 120 до 140. Это больше, чем учитель в школе, но сильно меньше, чем профессор в универе или врач или юрист. И, потом, не нужно сравнивать с Россией. В Штатах всё дороже. И жилье и продукты и медицина и образование — это основные статьи расходов и эти расходы таковы, что остается, после оплаты обязательных платежей, едва ли больше затрат на продукты, т.е. это близко к уровеню бедности.
Проблема с 737макс мне видится по-другому. Они решили поиграть в эффективность. Эффективные менеджеры сказали что опытные инженеры не нужны и наняли неопытных, но дешевых. С управлением ими справились, видимо, не очень хорошо.
Вторая проблема — это тут в Штатах обсуждается широко — как же так получилось, что компания Боинг, выпуская 737MAX, получила право сама себя регулировать, т.е. самой устанавливать что и как сертифицировать в целом ряде вопросов?
Третья проблема, отчасти связанная со второй, — это где проведена граница между выпуском новой модели, которую нужно заново сертифицировать и апгрейдом, который можно (и можно ли?) сертифицировать частично? Замена двигателей — на более мощные, имеющие очень существенные отличия, выглядит как слишком глубокое изменение для рядового апгрейда и контролирующие органы (TSA) явно промограли этот момент. Боинг, похоже, скрыл от них проблемы с управляемостью, которые они пытались пофиксить введя MCAS. Это тоже ускользнуло от TSA.
Но, в целом, я уверен — Боинг справится. Уроки будут извлечены и правильный баланс будет найден. Это далеко не первая проблема у Боинг и все предыдущие они решили.
Софт для Boeing-737 Max писался аутсорсерами, зарабатывающими $9 в час
И конструкция самолета тоже. И не только для Max, но и для всех остальных моделей. И не только у Boeing, но и у Airbus. Они в принципе на стафф-лизинге плотно сидят.
новые экономичные двигатели из-за большого размера сместили несколько вперед и вверх, но это техническое решение ухудшило летные качества планера. И в результате выбрали самое простое решение — компенсировать конструкторский недостаток программным путем. Если это так, то я просто интуитивно чувствую, что это плохое (кривое, некрасивое) решение, а интуиция в таких вещах меня обычно не подводит, я бы спать не мог. Кстати, именно этот момент (кривая конструкция планера) вероятно и является причиной того, что об этом программном решении решили умолчать. По сути это означало бы признание в том, что конструктивно лайнер стал хуже, чем был (стал неустойчивым в полете).
Не думаю, что компоновочное решение так уж повлияло на проблемы с B737MAX
Извините, но КАК тогда пилотам управлять в ручном режиме, если эти особенности лайнера даже в документации не были описаны??? На ходу изучать особенности планера?
Смотрите, что получается:
1) Лайнер имеет косяк — он неустойчив.
2) Эта неустойчивость отличается, от той, что была на старых лайнерах (если там была неустойчивость).
3) В документации этот факт не отразили.
4) Посчитали, что достаточно имеющихся правил, т.е. пилотам надо было отключить автоматику и перейти на ручное управление рулями.
5) Но при ручном управлении они неизбежно должны столкнуться с неустойчивостью планера, к которой не готовы, т.к. это не отражено в документации. Т.е. самолет поведет себя не так, как ожидается.
Считаете, это нормально?
Извините, но КАК тогда пилотам управлять в ручном режиме, если эти особенности лайнера даже в документации не были описаны??? На ходу изучать особенности планера?
Спокойно управлять. Более того, поведение самолета отличается от NG весьма незначительно. Все, что нужно для пилотирования, в инструкциях есть. И в первую очередь — на случаи отказов, как с косячной MCAS.
И да, по результатам двух катастроф, Боинг признала, что их стратегическая ошибка — думать, будто в кабине пилотов сидят профессионалы. Инструкциям IAS unreliable и runaway stabilizier — уже много десятилетий. Но да, нельзя опираться на знание экипажем инструкций.
1) Лайнер имеет косяк — он неустойчив.
Вы хоть уточните, в чем проблема. Проблема в том, что движки имеют склонность задирать нос самолета. И в определенных режимах (при малой скорости), это может создавать угрозу сваливания. В этих режимах самолет летать не должен. Т.е. если самолет подвели к этой черте, это уже косяк пилотирования. Называется «пролюбили скорость». Для того, чтобы этот косяк конструкции нивелировать, внедрили MCAS, которая должна определять, что лайнер на грани сваливания, и автоматически опускать нос вместо зазевавшегося пилота.
2) Эта неустойчивость отличается, от той, что была на старых лайнерах (если там была неустойчивость).
С учетом работающей функции MCAS — нет, не отличается.
3) В документации этот факт не отразили.
Опробовать MCAS есть возможность на тренажерах. В документации есть упоминание системы MCAS. И есть упоминание ее назначения. Да, недостаточно подробное.
4) Посчитали, что достаточно имеющихся правил, т.е. пилотам надо было отключить автоматику и перейти на ручное управление рулями.
Не про рули речь. Про стабилизатор, который самопроизвольно перекладывается. И да, имеющихся инструкций было достаточно. После Индонезии, Боинг разослала последнее китайское предупреждение всем операторам. Эфиопия показала, что не помогло.
5) Но при ручном управлении они неизбежно должны столкнуться с неустойчивостью планера, к которой не готовы, т.к. это не отражено в документации. Т.е. самолет поведет себя не так, как ожидается.
Это не так. Все, что должны сделать пилоты — это отключить электропривод стабилизатора, после чего управлять им вручную. Более того, если бы они правильно выполнили чек-лист IAS unreliable, который предусматривает выпуск закрылков, то они просто не узнали бы, что у них в самолете есть MCAS. Потому что MCAS отключается при выпуске закрылков.
Считаете, это нормально?
Боинг свои косяки признал. Признал еще после Индонезии, когда они вскрылись. Боинг свои косяки поправит. Уже правит.
А вот кто поправит пилотов? Всем понятно, что боинг — знатные поросята. Но в этой истории есть еще одни герои. И неизвестно сколько таких «специалистов» живые и ждут своей очереди угробить очередной самолет.
А вообще странно всё там выглядит… Датчика там этих было как минимум два, т.е. какое-то резервирование всё же было, хоть и не достаточное для полностью автоматического решения проблемы. Индикация неисправности датчика также была предусмотрена, но… по умолчанию (в базовой комплектации) отключена.
В итоге хоть мне и сильно не нравится кривизна конструкторского решения, должен с вами согласиться, что вероятно не это было основной причины катастроф, основной причиной были, по видимому, управленческие решения, т.к. если бы экипаж понимал бы, что происходит и почему, то с большой долей вероятности спокойно вырулил бы…
Однако тупое формальное выполнение всех правил без понимания сути происходящего тоже ни к чему хорошему не приведет.
1) Действия по памяти специально разработаны для того, чтобы в экстренной ситуации пилоты тупо формально, не думая, их исполняли. Ровно потому, что порефлексировать времени нет.
2) Во время обучения смысл действий из чек-листов пилотам понятен. Они прекрасно понимают, почему чек-лист именно такой, а не другой.
3) Если пилот не понимает сути происходящего, то нечего ему делать в кабине пилота. Может пылесосом в торговом-центре поуправлять. Или за кассой посидеть.
В данном случае, если бы летчики были бы осведомлены об особенностях работы MCAS, а также были бы оповещены о неисправности датчика, то скорей всего они смогли бы справится с ситуацией.
Они были снабжены всей необходимой информацией:
1) До катастрофы в Индонезии, предыдущий борт, почему-то спокойно разрулил проблемы и приземлился. А неквалифицированный экипаж, столкнулся с теми же самыми проблемами и уронил самолет.
2) IAS disagree не возможно не заметить. Тряска штурвала с одной стороны и горит табло. Другой информации просто не нужно. В этот момент нужно выполнять чеклист airspeed unreliable. Если бы эфиопы его выполнили, как того требовала ситуация, то остались бы живы и даже не узнали про то, что у них есть MCAS.
3) после индонезийской катастрофы боинг всем разослала письмо. Я выше уже писал про это.
4) Грамотный квалифицированный экипаж смог бы справиться с проблемой. Зачем в самолетах сидит неквалифицированный неграмотный экипаж — мне решительно непонятно.
Датчика там этих было как минимум два
Датчиков там ровно два. Столько же, сколько и на подавляющем большинстве других типов самолетов. И подобные отказы — не редкость.
хоть и не достаточное для полностью автоматического решения проблемы.
Трех датчиков тоже недостаточно для полностью автоматического решения проблемы. Думаю, именно поэтому их ставят два. Пилот нужен для того, чтобы принимать решение.
Индикация неисправности датчика также была предусмотрена, но… по умолчанию (в базовой комплектации) отключена.
Это не так. IAS disagree есть в базовой комплектации. Опциональный датчик AOA disagree не дает новую полезную информацию и является прикольной свистоперделкой.
В итоге хоть мне и сильно не нравится кривизна конструкторского решения, должен с вами согласиться, что вероятно не это было основной причины катастроф, основной причиной были, по видимому, управленческие решения, т.к. если бы экипаж понимал бы, что происходит и почему, то с большой долей вероятности спокойно вырулил бы…
Как я понимаю ситуации, есть две виноватых стороны:
1) Боинг. Косяк в MCAS есть и он провоцирует летчиков на ошибки, а потом роняет самолет. Этот косяк является преодолимым, не является фатальным, но — это косяк. Боинг этот косяк признала и работает над его устранением.
2) Пилоты. И вот тут самое ужасное. Никто из журналюг не говорит о том, что пилоты непосредственно виноваты в катастрофах, потому что совершили вполне конкретные ошибки. И имеем то, что боинг косяки исправляет, а авиакомпании — нет. И это реально страшно. Верю, что у нас подготовка летчиков организована лучше, чем в индонезии и эфиопии, но катастрофа суперджета намекает, что тоже не все слава богу.
Они были снабжены всей необходимой информацией:
Пилоты (более 400) подали на Боинг в суд. жалуются, что таки не были снабжены (обвинение предъявлено "в намеренном сокрытии дефектов самолета 737 Max.")
1) Действия по памяти специально разработаны для того, чтобы в экстренной ситуации пилоты тупо формально, не думая, их исполняли
Я (не один десяток лет в IT) давеча устанавливал на комп один специализированный сервис (для картографии)… Разбираться было лень, в наличии имелась пошаговая инструкция, поэтому решил решить эту задачу с наскока… Не срослось… Не вышел сходу каменный цветок… Несколько движений наугад также к успеху не привели. Хотя… делал всё по инструкции, при наличии опыта, но… без понимания работы конкретного сервиса.
Потом пошел с ребенком погулять и пока ребенок бегал, на смартфоне просмотрел документацию на сервис, понял принцип работы и… придя домой сходу сервис этот запустил.
Это я один пример (буквально вчерашний) подробно расписал, но это не единичные случаи, уверен, любой айтишник сталкивается с этим постоянно: без понимания процессов инструкции малополезны, иногда вредны.
И еще момент из моей практики: когда я недавно писал код, я поставил на один критичный блок кода условие (проверку) на ситуацию… которая не должна происходить..., т.е. это условие можно было бы и не ставить. Зачем поставил? Да, потому что кусок кода — критичный, и интуитивно чувствовал, что лучше явно перестраховаться.
А в сабжевом случае разработчик создает код, принудительно направляющий самолет в пикирование… И… у него на интуитивном уровне не возникло ощущение, что что-то не так, что надо бы подстраховаться? У меня бы возникло…
без понимания процессов инструкции малополезны, иногда вредныЕсли инструкция некорректная — то, да, конечно, она бесполезна и вредна. Если бы инструкция была корректная, то у вас бы и с наскоку все бы получилось.
Если бы инструкция была корректная, то у вас бы и с наскоку все бы получилось.
Да ни фига. Корректная инструкция корректна только к конкретному окружению. Если окружение хоть немного отличается, то легко может что-то пойти не так. А окружение как правило отличается.
Я (не один десяток лет в IT) давеча устанавливал на комп один специализированный сервис (для картографии)…
Какая связь между отказом в летящем самолете и сервисом, инструкцию к которому вам лень было прочитать? Существенно разные ситуации. Их некорректно сравнивать. Равно как и некорректно перенимать опыт.
К тому же, я специально указал: пилоты понимают смысл происходящего. Их для этого обучают. Если пилот не понимает смысла, такое бывает, то ему нечего делать в самолете.
Вы на авто ездили? Там тоже полно универсальных 100% работающих рецептов. Например, «в любой непонятной ситуации тормози, уходи на обочину, останавливайся и включай аварийку». Работает безотказно для любой проблемы.
В самолете тоже самое. Не важно, по какой причине случился отказ. Не важно, какие механизмы к этому отказу привели. Это все потом выяснят техники на земле. Важно, как этот отказ парировать. И на этот случай придуманы чек-листы и действия по памяти.
И… у него на интуитивном уровне не возникло ощущение, что что-то не так, что надо бы подстраховаться? У меня бы возникло…
Не стоит считать себя умнее всех :) У Боинга тоже возникло. Не случайно Боинг признали, что их стратегическая ошибка — полагать, что за штурвалом не может оказаться идиот. Код, принудительно загоняющий самолет в пикирование, отключается тысячей и одним условием работы в этом же самом коде. Например, включенный автопилот отключает MCAS, выпущенные закрылки отключают MCAS. Триммирование со штурвала отключает MCAS на период триммирования + 5 сек. после.
И самое главное: MCAS и все остальные системы и глюки, жаждущие отправить самолет в пикирование, надежно отключаются всего двумя тумблерами на центральной консоли «stab trim cutout». Щелкнул тумблером и MCAS заглох.
Перефразирую:
1) Если бы пилоты выполнили чек-лист airspeed unreliable (что они должны были сделать, поскольку горело табло IAS disagree), то самолет не пытался бы клевать носом.
2) Если бы пилоты выполнили чек-лист runaway stabilizier (что они должны были прочувстовать, по бешенно вращающемуся колесу стаба с диким треском), то MCAS не смогла бы дальше пакостить.
3) Если бы они не считали ворон, а триммировали самолет со штурвала, то они бы с легкостью перебороли MCAS. И с матюками, но — живые, долетели бы до места.
4) Даже если бы произошло невероятное и они в нарушение всех инструкций врубили бы автопилот, то MCAS опять же надежно успокоился бы.
На самом деле посыл простой: такие конструкторские и организационные решения резко повышают вероятность нехорошего исхода.
Я и говорю, что разговор идет не в то русло. Есть плохое решение от Боинга. Это очевидно и мусолится всеми, кому не лень. А вот другая вопиющая проблема — подготовка пилотов, вообще не рассматривается как класс. И это удручает.
И что из этого следует? У них используется трех — пяти кратное резервирование, плюс система катапультирования, плюс к тому наверняка военные летчики хорошо знают особенности планера истребителя при отказе автоматики. А теперь сравните с пассажирским самолетом на три сотни человек, с отсутствием какого-либо резервирования датчиков, с отсутствием оповещения о неисправности датчиков, и… с полным неведением экипажа касаемо того, как поведет себя лайнер при отключении автоматики, т.е. в ручном режиме (априори неустойчиво, но как — об этом в документации умолчали)…
А теперь сравните с пассажирским самолетом на три сотни человек, с отсутствием какого-либо резервирования датчиков
Это не так. Датчики резервируются. Есть 2 (ДВА!!!) датчика.
с отсутствием оповещения о неисправности датчиков
Это не так. Табло IAS disagree загорается при отказе любого из датчиков. Табло IAS disagree входит в стандартную комплектацию, а не в опцию.
и… с полным неведением экипажа касаемо того, как поведет себя лайнер при отключении автоматики,
И это тоже не так. Вы вообще не в курсе, в чем проблема, но из раза в раз повторяете одни и теже ошибки. Пилоты в курсе как себя поведет лайнер при отключении автоматики. Это не проблема. Проблема в том, что автоматика глючит и ведет себя неправильно в некоторых случаях. И главная проблема — в плохой подготовке пилотов, у которых есть все инструкции, но навыки не позволяют избежать катастрофы.
(априори неустойчиво, но как — об этом в документации умолчали)
Зачем вы продолжаете писать глупости, хотя я именно вам уже раз 5 писал о том, в чем именно проблема?
Повторю 6 раз: при отключении автоматики пилоты спокойно пилотируют самолет. А вот в редких случаях отказа датчика угла атаки, ошибка в одной из многочисленных систем, начинает дурить. При этом грамотные экипажи отключают дурную систему и летят дальше. Неграмотные экипажи два раза уронили самолет. Со слов пилотов MAXа, зафиксировано около 60 случаев отказа датчика угла атаки. Из них два случая закончились катастрофами. Т.е. в 58 случаях грамотные экипажи сделали все, что нужно и пассажиры не узнали о проблеме.
Это не так. Датчики резервируются. Есть 2 (ДВА!!!) датчика.
О каком резервировании можно вести речь, если корректирующая система работает на базе показаний одного датчика? Максимум на что способна резервирование из двух датчиков — это сообщить о неисправности одного из них, но и с этим были проблемы, как я понял.
Пилоты в курсе как себя поведет лайнер при отключении автоматики. Это не проблема.
И как же пилоты могут быть в курсе поведения лайнера при отключении автоматики, если они даже не были ознакомлены с целями и особенностями работы этой автоматики?
Проблема в том, что автоматика глючит и ведет себя неправильно в некоторых случаях.
Так вот именно об этой проблеме я и веду речь. Причем проблема эта больше организационная, т.к. об этой проблеме было известно производителю.
Повторю 6 раз: при отключении автоматики пилоты спокойно пилотируют самолет
Пилоты утверждают обратное — они весьма обеспокоены ситуацией.
Со слов пилотов MAXа, зафиксировано около 60 случаев отказа датчика угла атаки. Из них два случая закончились катастрофами. Т.е. в 58 случаях грамотные экипажи сделали все, что нужно и пассажиры не узнали о проблеме.
Уже было 60 случаев неисправности этого датчика? На недавно введенной в эксплуатацию модели самолета? Два случая из 60-ти закончились катастрофой? Из-за глюков датчика?
Извините за грубое слово, но это — дохрена. Ситуация, похоже, значительно хуже, чем я думал.
О каком резервировании можно вести речь, если корректирующая система работает на базе показаний одного датчика?
Резервирование включает в себя пилотов. А система да, глючная получилась. Просто все достаточно сложно, потому я поостерегся бы делать заявления вида «даже мне очевидно, что надо делать вот так». Очевидно, только не привязано к реальности. Поскольку подробностей никто кроме боинга не знает.
Максимум на что способна резервирование из двух датчиков — это сообщить о неисправности одного из них, но и с этим были проблемы, как я понял.
Поняли неправильно. Я об этом тоже раз пять писал. Табло IAS disagree горело. А значит нужно было выполнять чек-лист airspeed unreliable.
И как же пилоты могут быть в курсе поведения лайнера при отключении автоматики, если они даже не были ознакомлены с целями и особенностями работы этой автоматики?
Вы опять забыли, в чем суть проблемной системы. Проблема возникает при ВКЛЮЧЕНИИ автоматики, а не при отключении оной.
А сама система нужна для повышения управляемости самолета на грани сваливания. Т.е. в таком режиме, в котором самолет не должен оказываться вообще никогда. Назначение MCAS — парировать ошибки пилотов. Беда только в том, что в самой MCAS оказались ошибки.
Напротив, если эту автоматику отрубить, то управление вполне предсказуемое и понятное пилотам.
И потом, Боинг признала свои косяки. И стала их исправлять. Прошивка — правится. Письмо с разъяснениями экстренно разослали еще после Индонезии.
А вот вы так и не можете ответить на вопрос, что делать с пилотами, которые ждут своего часа, чтобы намудить и угробить очередной самолет с собой и пассажирами.
Так вот именно об этой проблеме я и веду речь. Причем проблема эта больше организационная, т.к. об этой проблеме было известно производителю.
Об этой проблеме стало известно производителю после Индонезии.
Пилоты утверждают обратное — они весьма обеспокоены ситуацией.
Какие пилоты? Денис Окань — пилот MAXа. Он явно понимает в проблеме побольше нас с вами вместе взятых. Более того, он не просто КВС, а инструктор. Т.е. пилот весьма и весьма квалифицированный. Его мнение для меня более весомо, нежели мнение журнашлюх, изнасиловавших Боинг.
Более того, индонезийский экипаж, который остался жив — как раз таки отключил автоматику.
Ваша проблема в том, что вы не поняли ситуацию, но имеете по ней свое мнение.
Уже было 60 случаев неисправности этого датчика? На недавно введенной в эксплуатацию модели самолета?
Ну да. А сколько таких отказов не на MAXах было — я даже и не в курсе. Как видите, массовость отказа — совсем не повод ронять самолет.
Два случая из 60-ти закончились катастрофой? Из-за глюков датчика?
Из-за глючной прокладки между штурвалом и креслом.
Ан-148 под Москвой, кстати, разбился тоже из-за этого датчика. Знаете какая система там вогнала самолет в землю? Пилоты. Позабыли обо всем на свете, отдали штурвал до конца от себя и привет земля. А надо было делать все тот же чек-лист airspeed unreliable (не знаю как называется он для АН-148).
Извините за грубое слово, но это — дохрена.
Вы просто не в теме. И упорно не хотите видеть реальную проблему авиации. А именно — никакосовая подготовка летчиков. А потом у вас и MAX плохой, и суперджет — опасный.
Вы опять забыли, в чем суть проблемной системы.
Вам не надоело повторять, что я ничего не понял. Всё я понял, не надо повторяться. Просто у нас разные оценки одних и тех же моментов.
Проблема возникает при ВКЛЮЧЕНИИ автоматики, а не при отключении оной.
Ох, ну, неужели не очевидно, что это связанные вещи? Если пилоты не имеют понятия о существовании программной системы коррекции, то они по логике должны быть также в неведении относительно того, что эта система корректирует.
Ну да. А сколько таких отказов не на MAXах было — я даже и не в курсе. Как видите, массовость отказа — совсем не повод ронять самолет.
На неМАКСах катастроф из-за этих датчиков вроде вообще не было, а на максах — аж 2%. Вот это действительно огромная разница.
И упорно не хотите видеть реальную проблему авиации. А именно — никакосовая подготовка летчиков.
Я вижу эту проблему (вернее подозреваю, т.к. инфой из первых рук не обладаю). Однако, не исключаю, что проблема с боингом — более серьезная. Я действительно не понимаю, как могли допустить такое конструкторское решение (на всех уровнях) и так организовать работу.
Проведу аналогию. Представьте, что новый автомобиль по каким то причинам спроектировали так, что его при определенных условиях уводит вправо. И вы решаете это скомпенсировать автоматикой, зависящей от ОДНОГО датчика. Вам не придет сразу в голову, что это, мягко говоря, плохое решение, т.к. очевидно, что в случае сбоя (датчика или софта) машину принудительно автоматом уведет влево — на встречку. И я уж не говорю о том, что сама конструкция, уводящая авто в сторону — не нормальна и по хорошему счету надо ее решать в первую очередь.
ЗЫ:
В детали нет смысла сильно углубляться, мы их не знаем. Но проблема по факту имеется, ей озабочены пилоты, производитель и пр.
Вам не надоело повторять, что я ничего не понял. Всё я понял, не надо повторяться. Просто у нас разные оценки одних и тех же моментов.
Надоело. Вы порете чушь и полностью игнорируете аргументы. Я вижу, что вы вообще ничего не поняли. Вы продолжаете долбить глупости. Очевидные глупости, не имеющие отношения к реальности. Вам аирбас платит, чтобы топить боинг? :)
Я бы перестал повторять одно и тоже, если бы вы по крайней мере адекватные вещи говорили. Но вы долбите про то, чего вообще в реальности нет — про какое-то «при отключенной автоматике самолет ведет себя непредсказуемо». Блин, вам откуда знать как ведет себя самолет и что написано, а что — не написано в инструкциях? Вы их читали? Вы пилотировали MAX?
При отключенной автоматике ни одной катастрофы с MAXом не было. Катастрофы были при ВКЛЮЧЕННОЙ автоматике.
Ох, ну, неужели не очевидно, что это связанные вещи?
Мне очевидно, что именно ВЫ не имеете представления о происходящем, но имеете веское мнение.
Если пилоты не имеют понятия о существовании программной системы коррекции, то они по логике должны быть также в неведении относительно того, что эта система корректирует.
1) пилоты ЗНАЮТ о существовании MCAS. Даже до индонезийской катастрофы упоминание об этой системе присутствует в мануалах. Ссылкой ткнуть?
2) В нормальных условиях полет самолета корректируют сотни систем. Пилотам нет нужды держать все это в памяти.
3) В НЕНОРМАЛЬНЫХ ситуациях пилотам нужно парировать отказ. И на каждую ненормальную ситуацию есть стандартные процедуры их парирования. Вскрывшийся косяк MCAS парируется любым из двух чек-листов: а) runaway stabilizier б) airspeed unreliable. MCAS приводит самопроизвольной перекладке стабилизатора. И если это не то, что ожидает пилот — это можно остановить двумя тумблерами.
Иными словами, для пилотов нет нужды описывать новую систему MCAS. Она не несет никаких новых ни точек отказа, ни новых знаний для пилотирования.
4) Поскольку вскрылась хреновая подготовка пилотов, Боинг ВСЕМ операторам MAXа сразу же после индонезийской катастрофы разослала письмо с подробным описанием MCAS и тыканьем в морду, как и чем парируется отказ. Т.е. уже после октября 18года некорректно говорить о том, что «пилоты что-то не знали». Все пилоты знали.
5) Очередной раз повторяю: Боинг признала косяк. Боинг работает над его устранением. Кто исправит пилотов?
На неМАКСах катастроф из-за этих датчиков вроде вообще не было
Было. В 94м году, если не ошибаюсь. и Вот буквально недавно — Ан-148 разбился под Москвой. Если вас не впечатляет, то учтите, что в Боинге есть косячная система, которая пытается клевать носом. А вот в Ан-148 пилоты добровольно и с музыкой воткнулись в землю.
а на максах — аж 2%. Вот это действительно огромная разница.
Это означает, что около 2% экипажей — неграмотные и неквалифицированные, не способные запомнить и правильно выполнить инструкции. Зачем такие экипажи сидят в самолетах, мне решительно непонятно.
Я вижу эту проблему (вернее подозреваю, т.к. инфой из первых рук не обладаю).
Ну, определенную предвзятость вижу :) Как вы думаете, для чего сидят пилоты в самолетах? Пассажиров развлекать? Или все же справляться с отказами техники и любой ценой вернуть пассажиров на землю живыми?
Я действительно не понимаю, как могли допустить такое конструкторское решение
Какое конструкторское решение? Наличие системы MCAS? Так это элементарно. Без переделки планера ( = дешевый и самый простой путь), новые мощные движки имеют склонность к задиранию носа. Если дурной пилот пролюбит скорость и прошляпает задирание носа, то самолет свалится. Для исключения такого поведения сделали систему, которая будет автоматически определять опасное задирание носа и опускать его.
При чем делает это мягко и нежно. Порциями с перерывами.
Я не знаю, почему при расхождении показаний скорости MCAS вообще включается в работу, возможно это косяк. Возможно, мы не знаем каких-то деталей. Но я бы поостерегся считать себя самым умным и называть программеров боинга дебилами. Решение «если датчики гарантированно врут, то отключить систему на фиг» — слишком очевидное и лежит на поверхности.
(на всех уровнях)
Если вы про аутсорс, то не вижу проблем. 9$ в час, это больше, чем у некоторых программистов в России. К тому же здесь уже показывали, что процесс организован сильно не так, что индусу на почту скидываешь тз, а он тебе в ответ шлет говнокод.
зависящей от ОДНОГО датчика.
Ну вот опять :)
От двух датчиков зависит система. Другое дело, что мне непонятно, почему в случае дилеммы система просто не отключается. И на сколько я понял из разъяснений боинга, им этот вариант даже в голову не пришел, значит есть какие-то подводные камни.
И я уж не говорю о том, что сама конструкция, уводящая авто в сторону — не нормальна и по хорошему счету надо ее решать в первую очередь.
В том же авто есть системы ESP и ABS. Если ее заглючит, то машину может спокойно выбросить на встречку. Я уж не говорю о том, что самолеты просто напичканы системами, которые вмешиваются в управление. Они не должны глючить, это правда. Но сам факт их наличия криминалом не является.
Но проблема по факту имеется, ей озабочены пилоты, производитель и пр.
Проблема-то имеется. Беда в том, что акценты недвусмысленно расставляются так, что виноват только боинг. В то время как на самом деле виноват и боинг и пилоты.
Если вы решите проблему на 50%, то аварий меньше не станет. За примерами далеко ходить не надо — Ан-148, Суперджет. В конструкции вроде все ок, а катастрофы есть.
Вы порете чушь
Снизьте обороты, не нервничайте, я вас не оскорблял.
Но вы долбите про то, чего вообще в реальности нет — про какое-то «при отключенной автоматике самолет ведет себя непредсказуемо».
Я исхожу из опубликованной информации: новые двигатели изза бОльших габаритов пришлось вынести вперед, из-за чего нос стал иметь тенденцию задираться. Компенсировали это программным путем, завязав эту систему на один датчик.
Блин, вам откуда знать как ведет себя самолет и что написано, а что — не написано в инструкциях? Вы их читали? Вы пилотировали MAX?
А это как раз один из ключевых моментов. Послушать вас, так можно сделать вывод, что любой никогда не летавший человек справился бы в такой ситуации — главное инструкцию наизусть выучить и четко следовать ей. Так?
Даже до индонезийской катастрофы упоминание об этой системе присутствует в мануалах. Ссылкой ткнуть?
Да, ткинете ссылокой, где было бы сказано, что в инструкции было не только упоминание этой системы в оглавлении, но и было бы подробно расписано, как она работает.
3) В НЕНОРМАЛЬНЫХ ситуациях пилотам нужно парировать отказ. И на каждую ненормальную ситуацию есть стандартные процедуры их парирования. Вскрывшийся косяк MCAS парируется любым из двух чек-листов: а) runaway stabilizier б) airspeed unreliable. MCAS приводит самопроизвольной перекладке стабилизатора. И если это не то, что ожидает пилот — это можно остановить двумя тумблерами.
А в самолетах уже машину времени устанавливают? Можно пилотам в будущее сгонять и посмотреть разъяснения по работе MCAS?
Вскрывшийся косяк MCAS
О каком косяке MCAS можно в тот момент вести речь, если о назначении этой системы пилотам не было известно?
MCAS приводит самопроизвольной перекладке стабилизатора. И если это не то, что ожидает пилот — это можно остановить двумя тумблерами.
Не вижу проблем, если знать об особенностях работы MCAS, но в инструкции этих разъяснений не было, как я понял. Просто самолет стал вести себя непредсказуемо (если не знать об особенностях работы MCAS). А почему непредсказуемо (из-за программных, механических или внешних причин) — это надо разбираться, для чего нужно время и железные нервы (причем одновременно). А вот эти секунды в такой ситуации, полагаю, очень важны.
Какое конструкторское решение? Наличие системы MCAS? Так это элементарно. Без переделки планера ( = дешевый и самый простой путь), новые мощные движки имеют склонность к задиранию носа
Завязывание работы такой системы на один датчик (угловой скорости). Из своего опыта (разработчика) я сразу (на уровне интуиции) вижу, что это нехорошее решение. Причина? Простая: любая вспомогательная автоматическая система при выходе из строя (или при получении неверных данных) должна просто отключиться и не вводить самолет в пике. Т.е. не должна влиять негативно.
И еще здесь есть важный момент: знали ли пилоты об этом выносе двигателей вперед и о склонности самолета к задиранию носа? Как я понял, не знали. Это знание напрямую завязано на MCAS, поэтому логично предположить, что если о MCAS не знали, то и о задирании носа тоже.
Я не знаю, почему при расхождении показаний скорости MCAS вообще включается в работу, возможно это косяк.
Потому что по факту MCAS оказался завязанным на один датчик. Как я написал выше, именно этот момент считаю основным конструкторским косяком, лежащим на поверхности (если не считать, что конструкцию самолета хорошо бы по нормальному сделать — устойчивой). Вот она по хорошему счету и должна была отключиться. Именно такой её надо было разработать. Не учесть такой момент, лежащий на поверхности? Вот именно это пугает больше всего, т.к. говорит скорее о системной проблеме, чем о случайной.
Ну вот опять :)
От двух датчиков зависит система. Другое дело, что мне непонятно, почему в случае дилеммы система просто не отключается.
Вы занимаетесь казуистикой. Да хоть десять датчиков там будет, какое это имеет значение, если по факту система принимала решение только на основании одного датчика?..
И на сколько я понял из разъяснений боинга, им этот вариант даже в голову не пришел, значит есть какие-то подводные камни.
А мне пришел сходу!!! Поэтому для меня дико выглядит такое решение. Эти последние пункты и есть те основные проблемы, которые меня беспокоят.
Вы про летчиков, про инструкции говорите, а ведь у конструкторов и инженеров также должны быть принципы проектирования безопасных систем, которые нарушать нельзя. Хотя… сдается мне, что проблема лежит еще на несколько уровней выше…
Снизьте обороты, не нервничайте, я вас не оскорблял.
Я не нервничаю и вас не оскорбляю. Но, увы, вы порете чушь.
Я исхожу из опубликованной информации: новые двигатели изза бОльших габаритов пришлось вынести вперед, из-за чего нос стал иметь тенденцию задираться. Компенсировали это программным путем, завязав эту систему на один датчик.
Ближе к делу, но не совсем. Компенсировали только ОПАСНЫЕ режимы полета, в которые самолет вообще не должен попадать. Опасный режим — это малая скорость и критический угол атаки. Датчиков угла атаки — два. Выбирает ли MCAS какому датчику верить или всегда использует только один, мне неведомо. Факт в том, что в этой системе вскрылся косяк.
А теперь скажите мне, каким боком относится это изменение, которое вы почти правильно описали к произошедшим катастрофам?
Само конструкторское решение в виде выноса движков вперед и вверх и добавка к MCAS ни к чему фатальному не привели, как вы пытались настаивать. Это, наверно, плохое решение, но оно работает. И оно дешевое.
А проблема вылезает с другой стороны. Проблема вылезает в момент отказа датчика угла атаки. MCAS начинает чудить и клевать носом.
Я не вижу никакой связи между конструкторским решением и глюком MCAS. Да, глюк есть. Да, самолет начинает клевать носом. Да, это надо исправлять. Но это лечится.
А это как раз один из ключевых моментов. Послушать вас, так можно сделать вывод, что любой никогда не летавший человек справился бы в такой ситуации — главное инструкцию наизусть выучить и четко следовать ей. Так?
Это действительно ключевой момент. И нет, не так. Я как раз настаиваю, что случайному прохожему за штурвалом делать нечего. А профессионал априори знает инструкцию наизусть, четко следует ей и она ему поможет.
Да, ткинете ссылокой, где было бы сказано, что в инструкции было не только упоминание этой системы в оглавлении, но и было бы подробно расписано, как она работает.
Я вам уже не раз писал, что MCAS не дает никаких новых требований к навыкам пилотирования. Равно как и письмо боинга с последним китайским разъяснением не содержало новой информации. Просто привели ссылки на главы инструкций, как это парировать.
И вы ловко проигнорировали, что на разбившемся в Индонезии самолете, отказ происходил дважды: в предпоследнем рейсе и в последнем. Отказывал один и тот же датчик. Но в первом случае экипаж четко и правильно выполнил требуемые инструкции, а во втором — нет.
А в самолетах уже машину времени устанавливают? Можно пилотам в будущее сгонять и посмотреть разъяснения по работе MCAS?
При чем тут машина времени? Вам что именно непонятно во фразе «ничего нового не несет»? :) Перед индонезийской катастрофой, экипаж успешно поборол эту ситуацию. После индонезийской катастрофы вышло письмо с разъяснениями. И к моменту эфиопской катастрофы все разъяснения уже были.… Но вы опять предпочли это проигнорировать :)
О каком косяке MCAS можно в тот момент вести речь, если о назначении этой системы пилотам не было известно?
Пилотам не нужно знать ни как ведет себя система MCAS, ни о том, что в ней есть косяк. Есть стандартный чек-лист, которому 40 лет и который решает эту проблему.
Не вижу проблем, если знать об особенностях работы MCAS, но в инструкции этих разъяснений не было, как я понял. Просто самолет стал вести себя непредсказуемо
Не нужно думать ни о каких особенностях работы MCAS. Есть инструкция: «при самопроизвольном перекладывании стабилизатора выполнить действия… ». И как только началось самопроизвольное перекладывание стабилизатора, нужно выполнить эту инструкцию, не рефлексируя о том, почему так происходит. Происходит и все тут. Контакт залип, провода замкнулись, MCAS сбрендила. По фиг. Стаб перекладывается? Перекладывается. Вырубаем его на фиг.
это надо разбираться, для чего нужно время и железные нервы (причем одновременно). А вот эти секунды в такой ситуации, полагаю, очень важны.
Именно для того, чтобы не тратить драгоценные минуты (речь о минутах, а не о секундах все же) и созданы memory items. Каждый пилот их обязан знать наизусть. И созданы они, чтобы не нужно было разбираться, что произошло. Разбираются пусть техники на земле. А пилот должен просто парировать отказ.
Из своего опыта (разработчика) я сразу (на уровне интуиции) вижу, что это нехорошее решение.
Я об этом уже писал. У меня тоже есть интуиция. Не стоит считать себя умнее боинга. Решение — на поверхности. Если оно не применяется, значит были какие-то причины. Вам и мне неведомые.
И еще здесь есть важный момент: знали ли пилоты об этом выносе двигателей вперед и о склонности самолета к задиранию носа? Как я понял, не знали. Это знание напрямую завязано на MCAS, поэтому логично предположить, что если о MCAS не знали, то и о задирании носа тоже.
Т.е. вы не знаете, но предполагаете. :) Ну ок. Хорошо, у самолета есть склонность задирать нос. Она есть у любого самолета на самом деле. Движки мощные. Например, катастрофы в Ростове и в Казани произошли именно из-за этой тенденции задирать нос и неподготовленного экипажа, оказавшегося за рулем.
Вы мне еще раз объясните, при чем тут тенденция задирать нос и две катастрофы, которые произошли из-за опускания носа, а не из-за его задирания? От меня ускользает ваша логика, кроме «я не могу признать не правоту и мне не нравится боинг, а еще я умнее боинга».
Не учесть такой момент, лежащий на поверхности?
А еще не учесть его после того, как произошли две катастрофы и боинг рассказала об изменениях в прошивке… Не считайте себя умнее других. Возможно, вы чего-то не знаете. Это слишком на поверхности, чтобы не заметить.
если по факту система принимала решение только на основании одного датчика?..
С чего вы взяли, что на основании одного датчика? В открытом доступе только информация уровня «ученый изнасиловал журналиста».
А мне пришел сходу!!! Поэтому для меня дико выглядит такое решение.
И мне пришел сходу. И вообще любому человеку придет сходу. Даже индусу. Если огромной корпорации с поставленными процессами разработки ПО не пришел в голову простейший вариант, значит есть какие-то неведомые причины, почему этот вариант не прокатывает. Не возможны детские ошибки в таких масштабах.
Эти последние пункты и есть те основные проблемы, которые меня беспокоят.
Так вас беспокоит не совсем правильно. Боинг поправит свои косяки. Даже если они системные. Работать будет надежно. Но катастроф меньше не станет. Потому что системная проблема подготовки пилотов существует. И, судя по всему, никого не заботит.
Вы про летчиков, про инструкции говорите, а ведь у конструкторов и инженеров также должны быть принципы проектирования безопасных систем, которые нарушать нельзя.
Нет уверенности, что они эти принципы нарушали.
И я точно знаю, что 99% публикаций про боинг — это какой-то шлак, не имеющий отношения к реальности.
Но, увы, вы порете чушь
Уже смешно становится. Наша дискуссия принимает нелепый вид. По сути вы мне не возражаете, а цепляетесь к второстепенным мелочам. У меня в свою очередь по существу также к вашим доводам нет возражений. У нас просто разная оценка одних и тех же фактов.
Просто в истории с системой MCAS (а ключевые моменты мы понимаем примерно одинаково) я вижу проблему, причем системную Вы же в этом проблемы не видите, считаете, что регламентированных действий было бы достаточно, чтобы обойти эту проблему. Т.е. вы считаете, что проблемы с MCAS нет вообще (правда тогда не понятно, что ж такую бучу в мире подняли). Но я не могу спорить с вами по поводу вашего мнения относительно тезиса и доводов, которые мы понимаем одинаково, в этом нет смысла, это ваша оценка.
Такое часто бывает, например, в спорах о том, кто виноват, когда машина на переходе сбивает пешехода, беспечно выходящего из-за пропускающего его ряда. Тут же сыпятся обвинения в сторону пешехода, что, дескать, он сам виноват, что был невнимателен, что надо было выглянуть и посмотреть, не мчится ли там неадекват… и т.д. Ну, что можно на такую оценку возразить? Да, надо быть внимательней пешеходам, кто ж спорит, и внимательный пешеход избежал бы наезда.
Но… почему то забывают о другом моменте… что если водила — неадекват, то наезд на пешехода или на другое авто — это лишь вопрос времени. Даже трижды внимательному человеку некомфортно себя чувствовать среди неадекватов, постоянно грубо плюющих на ПДД. Это вопрос вероятностей. Если например, либо пешеход, либо водитель (один из них) будут невнимательны с вероятностью 0.01, то вероятность наезда упрощенно говоря будет 0.0001. А если они оба будут с той же вероятностью невнимательны, то вероятность наезда будет 0.01, т.е. в 100 раз больше. Я сильно упростил, не придирайтесь.
То же самое и в технике — если беспечность в разработке, в управлении… если многие взаимосвязанные системы будут иметь высокую вероятность отказов, да еще с (недокументированным) влиянием на остальные подсистемы непредсказуемым образом, то… при неопытном (невнимательном) экипаже вероятность катастрофы очень сильно возрастает. И меня не утешают аргументы типа того, что опытный пилот должен справиться. Даже с суперпрофи может случиться так, что вместо туза выпадет пиковая дама…
Вы же в этом проблемы не видите, считаете, что регламентированных действий было бы достаточно, чтобы обойти эту проблему.
Так может, вы оба как-то вот этот именно момент и проясните со своим оппонентом? Почему вы считаете, что действия в соответствии с существующими правилами не помогли бы избежать катастрофы, и почему ваш оппонент считает иначе?
Почему вы считаете, что действия в соответствии с существующими правилами не помогли бы избежать катастрофы, и почему ваш оппонент считает иначе?
Избежать могли бы. Да и мы с вами наверно смогли бы… на симуляторе, детально изучив инструкцию… А вот в реальной жизни всё несколько непредсказуемо и часто (правильней сказать — всегда) реальная обстановка отличается от той, по которой составлялась инструкция. Поэтому к инструкции нужно еще прилагать мозги и опыт. А как их приложить, если о работе MCAS в инструкции по сути ничего не сказано? Без понимания происходящих процессов строгое следование инструкции — это рулетка. Может повезет, а может и нет.
Также надо учесть, что мы рассуждаем задним числом, основываясь на знании (пусть и поверхностном), как работает MCAS. Но… представьте, что вы едете на авто по федеральной трассе на скорости 130 км/ч. И вдруг машину повело влево. Вам сразу будет понятно, что проблема в бортовом компьютере, а не каких-нибудь механических причинах? Скорей всего даже если вы профи, но не сталкивались ранее с такой ситуацией, вам понадобится какое-то время на анализ (попробовать отключить какую-нибудь подсистему, посмотреть реакцию и т.д.). И только поняв, что дело скорей всего в бортовом компьютере, вы можете выполнить соответствующий пункт инструкции. А вы несётесь по трассе в этот момент, на нервах, каждая секунда на счету…
Также даже на интуитивном уровне будет казаться маловероятным, что бортовой компьютер специально отклоняет машину в сторону, тем более если вы о существовании такой системы не знаете. И с инженерной точки зрения такое решение также выглядит неправильным: не должна вспомогательная система в случае неисправности оказывать такое влияние — направлять самолет в пике. Это даже неинженеру очевидно. Хотя инженеры там возможно изначально разработали всё нормально, но потом по каким-то причинам часть функционала не была задействована.
В общем вырулить, соблюдая инструкцию пилоты может быть и могли бы, но вероятность выруливания очевидно была бы значительно выше, если бы экипаж знал о системе MCAS и понимал, что происходит.
Но… представьте, что вы едете на авто по федеральной трассе на скорости 130 км/ч. И вдруг машину повело влево.
Замечательный пример. Именно в точку!
В тот момент, когда у вас машину повело влево, вам нет нужды думать о том, что произошло: колесо у вас прокололось или ABS с ума сошел или ESP решила, что вот прям сейчас вам нужно на встречке оказаться.
В момент, когда у вас машину повело влево, вам нужно выполнить чек-лист:
1) Немедленно приступить к торможению
2) Пытаться парировать рулем движение влево.
А уже когда вы успешно остановитесь, у вас будет время подумать и разобраться, что же произошло.
Собственно, на любую непонятную критическую ситуацию в машине, нужно тормозить и останавливаться, а не думать, что происходит.
Самолет остановиться не может. Но на любую непонятную ситуацию есть чек-листы.
Пример: у вас недостоверные показания воздушной скорости. Вам должно быть плевать, по какой причине они недостоверны. Вам нужно сделать так, чтобы самолет не упал. И эти действия прописаны:
1) Автопилот — отключить
2) Автомат тяги — отключить
3) Флайт директоры — отключить оба
…
<Там много пунктов, но если кратко — установить обороты по таблице и выдерживать тангаж по таблице, выпустить закрылки по таблице>
Эта инструкция на ЛЮБЫЕ СЛУЧАИ ЖИЗНИ, когда у вас недостоверные показания скорости.
Не важно, что случилось — забыли чехол снять, трубка Пито замерзла, датчик угла атаки отказал, что-то еще.
Важно выполнить четко прописанные действия в указанной последовательности.
Этих действий достаточно, чтобы разрулить ЛЮБУЮ МЫСЛИМУЮ И НЕМЫСЛИМУЮ ситуацию, если у вас недостоверные показания скорости.
Тоже самое есть и на случай MCAS.
У вас стабилизатор стал самопроизвольно перекладываться. Вам нет нужды понимать, почему это происходит. Толи движок закоротило, толи контакты залипли, толи MCAS дурит, толи Высшая Божественная Сила решила покарать грешников — вам не важно. Важно, что стаб крутится. Щелкаем двумя тумблерами и стаб останавливается… PROFIT!
А как их приложить, если о работе MCAS в инструкции по сути ничего не сказано?
Одиннадцатый раз вам повторяю: вы не думаете, что и как работает. У вас сработал триггер: стаб — перекладывается. По этому триггеру вы выполняете инструкцию. Если у вас останется время, после того, как полет стабилизируется, можно поразмышлять на тему, что это было. Но не в момент парирования отказа.
но вероятность выруливания очевидно была бы значительно выше,
Очевидно, что это не так. Произошедшие катастрофы говорят о том, что экипаж не подготовлен к аварийным действиям, предусмотренными инструкциями.
Очевидно, что это не так
Так! Я сейчас буду краток. Только что около меня сбили мужчину, похоже наглухо. В парке! на маленькой улочке, ведущей к усадьбе, по которой гуляют родители с детьми и пр. Слышу резкое рычание авто, краем глазом из-за деревьев замечаю скорость (около 90 км/ч, а может и больше), а через несколько секунд слышу сильный глухой удар. Вышел на дорогу — лежит мужик, водила звонит. Народ подсказал, что этот парень на роликах выезжал…
Ну, что сказать… Да, надо быть внимательным, надо выглядывать на дороги, даже маленькие, даже в парковой зоне. Если бы выглянул, если соблюдал все инструкции, то всё обошлось бы. Но! Ситуацию эту (когда кто-то гоняет со скоростью под стольник в парковой зоне) НЕЛЬЗЯ назвать нормальной. Если бы этот водитель ехал бы как все (20 км/ч), то вероятность выжить у пешехода, даже при невнимательности, была бы близкой к 100%. А при скорости более 57 км/ч вероятность смертельного исхода стремится вверх по экспоненте. При скорости > 80 км/ч — стремится к 100%. Вот и вся разница — жизнь или смерть. Для меня эта разница существенна.
Второй вывод, который я делаю из сегодняшней прогулки, на которой мы катали вчера купленную радиомашинку. Специально для вас провел эксперимент: что произойдет с машинкой, когда она потеряет связь (т.е. когда произойдет нештатная ситуация)? Продолжит выполнение команды «ехать вперед» или остановится?
Сами что думаете? Какой вариант вы бы предусмотрели на месте инженера?
Правильно, машинка остановилась!!! Так и должно быть. И китайцы в игрушке это предусмотрели.
Так что не надо меня пытаться подловить на мелочах, тем более я фактологической стороне с вами не спорю, я просто делаю выводы, противоположные вашим, и обосновываю их.
Могли пилоты выйти сухими из той ситуации, тупо соблюдая чек-лист? Возможно, могли, не спорю.
Ситуация в целом нормальная? Я считаю, что нет. Так проектировать нельзя. Если бы система эта была спроектирована нормально, снизило бы это вероятность катастрофы? Уверен, что да.
Если бы этот водитель ехал бы как все (20 км/ч)
Погодите, ну так в вашем примере виноват водитель, который превысил скорость, а не автомобиль.
Тогда логично, что и в случае самолета то же самое? Человек не выполнил правила, ну а автоматика подчиняется человеку (ведь человек с-но и сидит в самолете зе тем, чтобы если что чинить сбои автоматики, т.е. автоматика его не может страховать).
разве нет?
Ну это например как если у нас есть робоавтомобиль, тестовый. Едет по городу, в автомобиле человек, который если что должен подстразовать ИИ (за тем там человек и сидит). Происходит некоторый сбой (например, машину начинает заносить куда-то) и человек водитель вместо того, чтобы вырулить на обочину и затормозить (как предписано правилами) выруливает на встречку и топит газ.
Где проблема будет в данном случае?
Заметьте, в данном случае не важно что там в автомобиле сломалось. Мби это вообще не автопилот, а просто техническая неполадка (детали автомобилей иногда ломаются, да) — в любом случае надо сбавить скорость и съехать на обочину. Но точно не выезжать на встречку газуя.
Правильно, машинка остановилась!!! Так и должно быть.
Нет, так быть не должно. В случае нештатной ситуации, которую должен разрулить человек, автоматика должна продолжать работать в том же самом режиме. Это универсальное правило. Какие-то изменения должны в данном случае происходить только в результате вмешательства человека.
Менять режим работы автоматика может только тогда, когда может с достаточной долей вероятности устранить проблему без постороннего вмешательства (ну или человек заведомо не может, например, в силу ограниченного времени реакции, тогда надо делать что-нибудь для минимизации потерь, но это не наш случай).
Заметьте, в данном случае не важно что там в автомобиле сломалось.
Проблема не в том, что что-то сломалось, а в том, что это сломанное не отключилось, а наоборот направила самолет в пике.
Давайте вернемся к машинке, котрую мы сегодня катали. Можно было бы не предусматривать отключение двигателей при потере связи, а ограничиться пунктом инструкции, запрещающим превышать дистанцию 20 метров? Ну, можно конечно. Этим самым мы переложим все последствия на оператора машинки. Если машинка уедет куда-нибудь в овраг и разобъется, то обвинить можно оператора, нарушившего инструкцию и товар бесплатно не ремонтировать… Но вы не чувствуете, что эта ситуация не нормальна?
Системно-организационную проблему, т.е. если вокруг будет ездить много неадекватов (не важно — люди это или неправильно спроектированные роботы)
Вы под неадекватами-водителями подразумеваете пилотов, которые не выполняют регламенты, или что? Тогда же наоборот получается. Уточните, а то как-то непонятна аналогия.
Проблема не в том, что что-то сломалось, а в том, что это сломанное не отключилось
Оно и не должно отключаться, я пост не успел отредактировать до вашего ответа, так что повторюсь:
В случае нештатной ситуации, которую должен разрулить человек, автоматика должна продолжать работать в том же самом режиме. Это универсальное правило. Какие-то изменения должны в данном случае происходить только в результате вмешательства человека.
Менять режим работы автоматика может только тогда, когда может с достаточной долей вероятности устранить проблему без постороннего вмешательства (ну или человек заведомо не может, например, в силу ограниченного времени реакции, тогда надо делать что-нибудь для минимизации потерь, но это не наш случай).
Вы под неадекватами-водителями подразумеваете пилотов, которые не выполняют регламенты
Нет, я по неадекватами подразумеваю неадекватную окружающую среду, включая технику с программным обеспечением.
В случае нештатной ситуации, которую должен разрулить человек, автоматика должна продолжать работать в том же самом режиме. Это универсальное правило.
Т.е. машинка должна продолжать ехать в овраг при потери связи? Ракета при неполадках не должна самоликвидироваться, а должна продолжать лететь «туда, не знаю куда»???
Вообще то потенциально опасные действия должны при неполадках отключаться. А коррекция угла, потенциально уводящая самолет в пике, — это очевидно опасное действие.
Т.е. машинка должна продолжать ехать в овраг при потери связи?
Машинка как раз может разрулить ситуацию — остановившись. Самолет не может просто взять и остановиться. Он может только изменить режим полета.
Когда электроника в случае нештатной ситуации начинает рандомно менять режим работы — это существенно усложняет задачу оператора.
Вообще то потенциально опасные действия должны при неполадках отключаться.
А при управлении самолетом есть потенциально безопасные действия?
Нет, я по неадекватами подразумеваю неадекватную окружающую среду, включая технику с программным обеспечением.
Погодите, так неадекватно себя в данном случае ведут пилоты, не выполняя инструкции, разве нет?
В случае нештатной ситуации, которую должен разрулить человек, автоматика должна продолжать работать в том же самом режиме.
Т.е. автоматика принимает сигнал с датчика, знает об этом (сравнивая с показаниями второго датчика) и… должна продолжать работать в том же режиме? Загонять самолет в пикирование? В этом случае как раз надо было бы отключиться и оповестить экипаж. Всё.
Самолет не может просто взять и остановиться.
Достаточно не усугублять ситуацию направлением самолета в пикирование, да еще непредсказуемым образом — то слушаемся, то не слушаемся.
А при управлении самолетом есть потенциально безопасные действия?
У нас только два варианта — полностью опасные и полностью безопасные действия? Градаций нет?
Погодите, так неадекватно себя в данном случае ведут пилоты, не выполняя инструкции, разве нет?
Трижды Да! Но если на неадекватность пилотов накладывается неадекватность техники, неадекватность инженеров, конструкторов и менеджеров, то…
и… должна продолжать работать в том же режиме? Загонять самолет в пикирование?
1) Да, в этом случае мы имеем отказ техники, вызванный конструктивными недостатками. И с этим отказом пилоты и должны бороться. Это их прямая обязанность.
2) Деятельность MCAS сильно демонизируется. Именно в полном согласии с вашей логикой, MCAS перемещает стаб на пикирование порциями. По 0.27 градусов за цикл. После перекладки MCAS выключается на 30 секунд. Немыслимо, чтобы с такой медлительностью экипаж не разобрался с проблемой. Но идиотизм экипажа победил идиотизм конструкторов Боинга.
На минуточку, чтобы переложить стаб полностью на пикирование, нужно отклонить его на 5 градусов. Сколько минут потребуется, чтобы MCAS выполнила свою работу? Так что «загонять самолет в пикирование» — не совсем корректное выражение. Правильнее будет «клевать носом». А это уже звучит не так фатально… Но это все фигня. Косяк есть и его признали. И вариант «отключиться при рассогласовании показаний» слишком очевиден, чтобы обвинять боинг в тупости. Скорее всего, есть какие-то тонкости, которые мешали так сделать. Скорее всего, полученное решение — некий компромисс между разными вариантами.
Вы же разработчик? У вас не было ситуаций, когда система, которой вы пользуетесь, глючит слишком детским образом, что вам хочется вырвать руки программистам? И вы ведь про себя проговариваете небось «да там в одной строчке поправить, идиоты, разобраться не могут»? А потом, внезапно, вам эту систему отдают на поддержку и вы видите ее начинку.
И начинаете понимать, что архитектура слишком отличается от того, что вы предполагали. И простое и очевидное решение в вашей архитектуре, попросту вообще не перекладывается на существующую архитектуру. А в ней эту ошибку исправить чрезвычайно сложно… И ведь нельзя обвинить разрабов в выборе кривой архитектуры? Нет, напротив, архитектура решает кучу насущных проблем… Но как назло, проявилась такая досадная ошибка… Точно не бывало такого? А у меня бывало. Поэтому, я бы поостерегся с обвинениями криворуких программистов.
Да, они накосячили. Но 99%, что все сложно. И дело вовсе не в индусах или хреново поставленных процессах.
и оповестить экипаж. Всё.
Экипаж, внезапно, был оповещен. У экипажа (в обоих катастрофах) горело табло IAS disagree.
А это — триггер. Значит на ПНД погода на Марсе, а не скорость. Значит, нужно выполнять чек-лист airspeed unreliable. По результатам которого, вы гарантированно будете лететь горизонтально с безопасной скоростью. А попутно у вас отрубится и перестанет гадить MCAS, поскольку аодно из условий чек-листа — выпустить закрылки. А это действие вырубает MCAS.
да еще непредсказуемым образом — то слушаемся, то не слушаемся.
Не было такого. Загадка, почему Эфиопы даже не пытались триммировать самолет со штурвала.
У нас только два варианта — полностью опасные и полностью безопасные действия? Градаций нет?
А теперь представьте себе, что действия MCAS в целом-то виделись достаточно безопасными. Поскольку работает система достаточно медленно. Но пилоты превзошли все ожидания.
Трижды Да! Но если на неадекватность пилотов накладывается неадекватность техники, неадекватность инженеров, конструкторов и менеджеров, то…
… то именно пилотам нужно исправлять косяки всех вышеперечисленных. Ибо это единственное, зачем пилоты вообще нужны в кабине.
Но в результате разбора почему-то вопрос концерна боинга мусолится и в пух и в прах, а вопрос подготовки пилотов не рассматривается вообще.
Что, по вашему, произойдет с аварийностью, после того, как боинг по человечески исправит все ошибки? Вы думаете, что катастрофы прекратятся? Их станет сильно меньше?
Щщщааазззз! Ростов, Казань, Ан-148 под Москвой — это все примеры, когда полностью исправные самолеты вгонялись в землю криворукими экипажами. Так что после исправления косяков боинга, самолеты продолжат падать. И очередные журнашлюхи продолжат выискивать несуществующие проблемы в самолетах. А хреновая подготовка пилотов продолжит маскироваться.
Но сообщить то об этой особенности (как планера, так и корректирующей системе) надо ведь было.
Ну во первых, пилоты проходят подготовку на тренажере. Соответственно, поведение самолета пилотам полностью известно. Пилоты его щупают до полетов еще.
Во вторых, в самолетах сотни разных систем, десятки из которых вмешиваются в управление. Внезапно, логика их работы не расписывается. Как я понимаю причины — у пилотов хватает проблем, которыми нужно нагружать мозг. Технические подробности просто излишни.
В третьих, на сегодняшний день это замечание излишне, поскольку до каждого пилота логика MCAS доведена. С подробными отсылками, какие главы руководства нужно повторить.
как ведет себя планер без автоматики (задирает нос)
Напоминаю, все самолеты имеют склонность задирать нос. На эту тему было 2 катастрофы — ростов и казань.
Просто у MAXа, на критических углах атаки большие проблемы с управляемостью. Кстати, об этом как раз, пилоты были предупреждены. И в этом, как раз, проблем не было.
Если компания считает такие моменты неважными, то мне что-то стрёмно делается…
Мне очень странно, почему вам не делается стремно от того факта, что в кабине могут сидеть «мимо крокодил», а не пилоты. Потому как на тему косяков боинга кричат все кому не лень. И это понятно. Непонятно, почему не кричат про пилотов. Там ведь как раз и есть самая настоящая системная проблема. Квалификация летчиков хромает из-за регламентов авиакомпаний, которые недостаточное внимание уделяют качественной подготовке.
Моя же логика говорит, что есть две виноватых стороны: боинг, пилоты. Странно, что именно этого вы и не слышите. Я в каждом своем комменте повторяю, что боинг — виноват. С этим спорить бессмысленно.
Но вина боинга — это только 50%. Еще 50% — это пилоты.
А меж тем посмотрите на заголовки и канву обсуждения подобных статей: «из-за проблемы БОИНГА, которая привела к двум катастрофам». Ни кто не говорит, что из-за проблем АВИАКОМПАНИЙ И БОИНГА произошли две катастрофы.
И именно эта мысль — пилоты — герои, боинг — козлы, пережевывается во всех медиа. В итоге, в том числе и под давлением общественности, боинг получит по самый не балуйся, что правильно, а вот авиакомпании выйдут сухими из воды. А вот это уже беда. Поскольку пилоты сами по себе не имеют возможности качественно поднять свою подготовку. Им эту подготовку должны обеспечить авиакомпании.
Вот как-то вот так. Еще раз повторю, чтобы вы услышали, наконец: виноватых стороны две: боинг и пилоты (авиакомпании)
Моя же логика говорит, что есть две виноватых стороны: боинг, пилоты.
Моя логика тоже простая. При наличии на борту неграмотного экипажа… такие косяки с оборудованием увеличивают вероятность катастрофы на порядок (в прямом математическом смысле), и скрытие информации увеличивает вероятность того, что неопытный экипаж запутается, увеличивает эту вероятность еще на один порядок…
А если учесть, что, похоже, такие проблемы с обучением экипажей, инженерные проблемы, организационные и пр. — не частные, а системные, то совсем грустно становится.
Поэтому и спору нет, что проблема комплексная и перепрошивкой бортового компьютера вряд ли решаема.
При наличии на борту неграмотного экипажа… такие косяки с оборудованием увеличивают вероятность катастрофы на порядок (в прямом математическом смысле),
Ну так и давайте говорить, что есть ДВЕ виноватые стороны и проблема комплексная. А то подобные заголовки нереально режут глаз. Выгораживанием одной из виноватых сторон. При этом я могу согласиться, что сами пилоты, которые накосячили и погибли, не виноваты. Виновата система, которая допустила их в кабину и не обеспечила им надежную подготовку.
Пилоты пытались перебороть стабилизатор руками, но даже не попытались отключить систему которая его перекладывает.
И тут автомобиль самопроизвольно начинает вести влево, на встречку
Этого пункта уже достаточно, чтобы ужаснуться сконструированной таким образом системой. Система знает, что датчик неисправен, что его показаниям верить нельзя, но… пофиг… (молча) продолжает рулить…
Что вы будете делать? Отключите автопилот
У них была там кнопка отключения этой хрени, они ее нажимали и всё становилось нормально… но на пять минут… потом начиналось всё по новой. А вы ведь под стольник на машине несетесь. Много у вас времени на оценку ситуации? Кто-то справится, кто-то нет.
У них была там кнопка отключения этой хрени
Вы видимо не изучали эти ситуации подробно.
MCAS может отключаться несколькими способами. При триммировании стаба вручную со штурвала — он отключается на 5 секунд, затем снова включается.
И есть два тумблера, называются stab trim cutout. Расположены между пилотами, дотянуться может любой. Эти тумблеры гарантированно отключают вмешательство любой автоматики в управление стабилизатором, полностью. Но пилоты этого не сделали. Вместо этого они пытались вручную триммировать самолет со штурвала до контакта с землей.
Так вот подготовки пилотов двух самолетов было недостаточно, чтобы четко выполнить определенный порядок действий, который бы спас всех
Я не спорю с этим тезисом. Я веду речь о вероятности. Так вот вероятность вырулить была бы значительно выше при правильном проектировании данного устройства.
Им даже думать не нужно было, просто выполнять
Там где не надо думать, надо заменять на САУ (систему автоматического управления). Да и не в этом дело. Просто автоматическая система при неисправности должна просто отключиться и всё! Это же очевидно. Даже в отрыве от произошедшего, видно, что такое решение опасно: бортовой компьютер видит неисправность и продолжает работать… Это даже китайцы в дешевых игрушках предусматривают. Всего то надо было предусмотреть три простые и очевидные вещи: 1) бортовой компьютер при неисправности датчика должен был прекратить влиять на управление, 2) необходимо включить оповещение о неисправности датчика, 3) описать работу этой системы в документации. А получается, у самолета смещен центр тяжести, что компенсируется автоматической системой, а мне говорят, что это не важно и что пилотам знать об этом незачем…
Вы видимо не изучали эти ситуации подробно.
MCAS может отключаться несколькими способами. При триммировании стаба вручную со штурвала — он отключается на 5 секунд, затем снова включается.
И есть два тумблера, называются stab trim cutout. Расположены между пилотами, дотянуться может любой. Эти тумблеры гарантированно отключают вмешательство любой автоматики в управление стабилизатором, полностью.
Это задним числом хорошо рассуждать, когда всё уже известно. А в реальности прежде чем перейти к выполнению чек листа необходимо разобраться, что произошло, чтобы выбрать правильный пункт. Причина такого поведения, предполагаю, теоретически могла быть вызвана не только сбоем автоматики, но например механическими проблемами. Да и… нажали они кнопку и ситуация временно стабилизировалась. Зачем им было полностью отключать автоматику? Конечно, после энного раза наверно можно было бы догадаться полностью ее отключить, но… стресс, непонимание ситуации (неведомая сила наклоняет непредсказуемо нос)…
Так вот вероятность вырулить была бы значительно выше при правильном проектировании данного устройства.
Полностью согласен и поддерживаю. Но проектирование такого сложного устройства как самолет это всегда компромиссы между стоимостью разработки, производства, дальнейшего обслуживания, безопасностью, комфортом пилотов и еще кучи параметров. И как раз для того, чтобы компенсировать недостатки техники в кабине сидят профессионалы. Которые знают именно этот тип самолета, перед каждым вылетом читают бортжурнал чтобы быть в курсе об особенностях поведения конкретного борта, и должны знать как действовать в критических ситуациях.
А в реальности прежде чем перейти к выполнению чек листа необходимо разобраться, что произошло, чтобы выбрать правильный пункт.
Для этого в обоих случаях было достаточно времени, от начала странного поведения стаба до момента когда вытянуть самолет уже было бы невозможно прошло прилично времени. И им не надо выбирать никакой пункт. У них есть однозначная ситуация, runaway stabilizer. И на эту ситуацию есть один чек лист. И его нужно выполнять начиная с первого пункта. Если первый не помогает — переходим ко второму, и т.д. Не нужно ничего придумывать и диагностировать, нужно выполнить и всё.
Посмотрите на график, это расшифровка Индонезийского Боинга.
![image](https://habrastorage.org/getpro/habr/comment_images/537/1a0/752/5371a075282c628fe4a9f16dd5cc88f0.jpg)
Голубая линия — триммирование вручную, пилотом. Оранжевая — триммирование автоматикой, а именно MCAS. И мы видим, примерно посередине полета MCAS начинает глючить и перекладывать стаб. Пилот крутил триммер вручную до самого падения, около 6 минут. Он видел что это не помогает, но продолжал упорно делать одно и то же, вместо отключения автоматики.
Причина такого поведения, предполагаю, теоретически могла быть вызвана не только сбоем автоматики, но например механическими проблемами.
Им не нужно думать о причинах когда самолет колбасит. Пилотам нужно стабилизировать полет, и тогда уже можно размышлять о причинах. Неважно от чего стабилизатор крутится на пикирование.
Зачем им было полностью отключать автоматику?В смысле зачем? Стабилизатор перекладывается. Сам. Ни один из пилотов не дает команду на перекладку. Кто еще может давать эту команду? Верно, автоматика, больше некому. Что нужно сделать? Как думаете?
На том же графике мы видим что довольно долгое время самолет имел нормальную, стабильную скорость, и так же плюс-минус держал высоту. Даже если пилоты и паниковали (а это точно пилоты?) первые две минуты, далее у них было масса времени на то чтобы разобраться с поведением самолета.
У них была там кнопка отключения этой хрени, они ее нажимали и всё становилось нормально… но на пять минут… потом начиналось всё по новой.
А можно пруф?
А можно пруф?
Так график жеж
Голубая линия — триммирование вручную, (нажатие кнопки пилотом). Оранжевая — триммирование автоматикой (MCAS).
А где на нём отключение автоматики?
Ну так посмотрите — там, где голубая линия не на нуле, жёлтая на нуле (и наоборот).
Ну так голубая линия — это не кнопка отключения автоматики.
Это кнопка триммирования стабилизатора на штурвале, её нажатие а) перемещает стабилизатор, и б) отключает автоматику на (кажется) 30 секунд.
Да, и это временное отключение автоматики — правильное. Причем правильное тут как отключение, так и повторное включение.
Тем не менее, кнопкой отключения автоматики кнопка триммирования на штурвале от наличия этой доп. функции не становится. А значит, и говорить "У них была там кнопка отключения этой хрени, они ее нажимали" некорректно. Они не ее нажимали.
Тем не менее, кнопкой отключения автоматики кнопка триммирования на штурвале от наличия этой доп. функции не становится.
Я понял, где у нас разогласие. Когда Вы говорите "кнопка отключения автоматики", Вы хотите сказать "кнопка постоянного отключения автоматики", а я — "кнопка любого, пусть даже временного отключения автоматики".
Так "кнопка" постоянного отключения тоже была — предохранитель триммера за спиной у пилота, достаточно было его отщёлкнуть, и питание мотор привода стабилизатора отключилось бы. Эта операция, кстати, тоже была предусмотрена, ниже по списку runaway stabilizer (на который пилоты забили).
Осталось понять что именно вы с такими разногласиями пытаетесь доказать. То, что "кнопка любого, даже временного, отключения автоматики" должна была отключить автоматику навсегда?
Напомню, я-то возражал против выставления автоматики якобы неотключаемой.
Всё началось с этого комментария. irgen сказал, что "была там кнопка отключения этой хрени, они ее нажимали и всё становилось нормально". Вы сказали — "А можно пруф?". Я привёл вам пруф, что 1) кнопка действительно была; 2) её действительно нажимали, и 3) после её нажатия действительно "всё становилось нормально". Что ещё Вы от меня хотите???
Т.е. автоматика принимает сигнал с датчика, знает об этом (сравнивая с показаниями второго датчика) и… должна продолжать работать в том же режиме? Загонять самолет в пикирование?
Еще раз. Если автоматика может решить проблему — она решает проблему. Если автоматика не может решить проблему, то она оповещает оператора и ничего больше не делает. Т.к. любые дальнейшие действия автоматики помешают оператору.
и ничего больше не делает
Это и означает, что надо просто отключиться, а не продолжать влиять на самолет, опираясь на заведомо недостоверные данные. Это же очевидно.
Это и означает, что надо просто отключиться
Нет, не значит. Отключиться — это действие, которое меняет режим работы системы, и тем самым существенно усложняет работу оператора.
Если оператор считает, что надо что-то отключить — он сам отключает. Для этого он там и сидит.
Нет, не значит. Отключиться — это действие, которое меняет режим работы системы
В данном случае значит! Без вариантов.
и тем самым существенно усложняет работу оператора
Наоборот, усложняет работу система, продолжающая влиять на управление на основе априори неверных показаний неисправного датчика. Что она там науправляет, никому не известно — рулетка. Так что единственный вариант — такую систему отключить. Без вариантов! Да вы и сами это знаете и постоянно мне пытаетесь доказать. Вы же пытаетесь меня убедить, что пилоты в той ситуации (неисправности датчика) обязаны были по инструкции тупо отключить эту автоматику и перейти на ручное управление. И это, заметьте, без вариантов, без альтернатив. Отключить и точка! Ведь именно в этом вы меня уже несколько дней убеждаете. Так вот, я то с этим не спорю, а лишь вношу поправку: отключиться MCAS должна была сама! Датчика — два? Два. Информация о том, что датчик неисправный бортовму компьютеру известна? Известна. Является опасной САУ с неисправными датчиками? Однозначно ДА и без вариантов, об это и говорит инструкция и чек-лист, а также фактическое подтверждение — две катастрофы нового самолета за короткое время. Поэтому надо этой САУ самой отключаться, здесь не о чем спорить.
И я выше привел несколько примеров, показывающих, что производители техники именно так и поступают — потенциально опасные устройства в таких случаях отключаются автоматически.
Вы же пытаетесь меня убедить, что пилоты в той ситуации (неисправности датчика)
Ситуация (с точки зрения пилотов) заключалась не в неисправности датчика, а в том, что автоматика делала вещи, которые делать была не должна. По каким причинам и из-за каких датчиков это происходит — в сущности, для пилотов было не важно. По крайней мере в рамках вопроса надо или не надо чего-то отключать. Если автоматика делает явно что-то не то -0 отключаем.
Так вот, я то с этим не спорю, а лишь вношу поправку: отключиться MCAS должна была сама!
Ни в коем случае не должна, это опасно! Не должна именно потому, что датчик был сломан. Если датчик сломан — значит, автоматика получает неверные данные. Если автоматика получает неверные данные (и уже знает об этом) — она никаких действий, меняющих режим работы системы, совершать не должна. Она должна посигналить лампочкой оператору и замереть.
Вы, оценивая ситуацию, исходите из знаний пилотов об этой ситуации (ну и даже не из знаний пилотов и уже из последующей инфы), а у автоматики не было таких знаний. С точки зрения данных, которые имелись у автоматики, навредить могло как неотключение — так и отключение с равной вероятностью, ведь конкретная ситуация неизвестна (это вам она известная и вы знаете, что отключение бы помогло — но могло бы быть иначе и к катастрофе привело бы как раз то, что автоматика сама отключилась). И раз неизвестно, что навредит, а что нет, — надо ничего не делать, т.к. если что-то делать — это помешает оператору разрулить ситуацию.
Еще раз — если надо звать оператора, то ситуацию должен разруливать оператор, автоматика в этом случае не должна ничего не делать.
Ни в коем случае не должна, это опасно! Не должна именно потому, что датчик был сломан. Если датчик сломан — значит, автоматика получает неверные данные. Если автоматика получает неверные данные (и уже знает об этом) — она никаких действий, меняющих режим работы системы, совершать не должна.
Ага, по вашему: ракета, потерявшая связь, не должна самоликвидироваться; дрон, улетевший за пределы радиосвязи, должен упорно продолжать полет, а не возвращаться назад… Так что-ли? На практике всё наоборот: ракета самоликвидируется, дрон возвращается или садится (прекращает полет), и… даже китайская радиоуправляемая машинка останавливается при потере связи, а не продолжает движение. Да и о каком продолжении работы может идти речь, если датчик неисправен, т.е. продолжение работы априори ведет к опасной ситуации, что в итоге и произошло.
автоматика в этом случае не должна ничего не делать
Так вот она и должна отключиться, а не уводить упорно самолет в пикирование.
Ага, по вашему: ракета, потерявшая связь, не должна самоликвидироваться; дрон, улетевший за пределы радиосвязи, должен упорно продолжать полет, а не возвращаться назад… Так что-ли?
Вы придуриваетесь, что ли? Ни дрон, ни ракета, ни машинка не могут помигать палочкой и позвать оператора разобраться. Т.к. связь потеряна. В нашем же сдлучае ситуация строго обратная.
Да и о каком продолжении работы может идти речь, если датчик неисправен, т.е. продолжение работы априори ведет к опасной ситуации, что в итоге и произошло.
Неверно. Для того, чтобы сделать вывод об опасности ситуации нужен исправный датчик. В случае, если датчик неисправен — к опасной ситуации, в общем случае, может вести как продолжение работы, так и отключение. По-этому единственный фактор — это удобство оператора. А оператору удобнее, когда автоматика не предпринимает никаких действий, меняющих режим работы.
Так вот она и должна отключиться, а не уводить упорно самолет в пикирование.
"отключиться" — это действие, которое помешает оператору. Представьте, что автоматика уводит самолет не в пикирование, а наоборот, вверх. Оператор ведет самолет вниз. Самолет в итоге летит ровно. Автоматика отключается — самолет уходит в пикирование.
Вы исходите в своих рассуждениях из того, что автоматика обладает всеми знаниями пилота. Но это не наша ситуация, в нашей ситуации датчик неисправен. В случае, когда датчик неисправен — автоматика не должна ничего не делать.
Вы же предлагаете автоматике совершать некие действия в условиях неисправности. Это неверно. Это опасно.
Вы же предлагаете автоматике совершать некие действия в условиях неисправности. Это неверно. Это опасно.
Ну, откуда вы берете то, что я не говорил? Моя мысль проста: если автоматика уже делает некие действия (уже делает, Карл!!!), основываясь на некорректных данных, т.е. делает эти действия априори неправильно (априори, Карл!!!), то эти априори неправильные действия надо прекратить. Это же очевидно!
Да и вчера в ЖЖ кто-то привел ссылку на выступление высшего руководства Боинга, где они после соболезнований признают, что проблема была именно в некорректной работе MCAS, которая направляла самолет в пикирование и которую пилоты не смогли отключить, хотя пытались. Для меня этот вопрос закрыт.
то эти априори неправильные действия надо прекратить
Так она и прекратила — она продолжала работать в исходном режима, не меняя его. Т.е. не совершала никаких действий.
Кроме того — это вы сейчас знаете, что пикирование было неправильным. Но автоматика-то не знала! Так что ничего "априорного" там не было! И если бы автоматика отключилась — это точно так же могло бы привести к катастрофе (причем более вероятно), в тех случаях, когда пикирование было бы правильным действием.
Ну давайте на примере, чтобы вам было понятнее.
Представьте, едете вы на машине с автопилотом, и ее резко начинает вести вправо. Вы сразу выкручиваете руль влево, чтобы просто не улететь в кювет, фиксируете, машина едет ровно. Далее отключаете автопилот и контролируете это действие обратным движением руля (по-хорошему, конечно надо было бы вообще остановиться, но на самолете вы остановиться по очевидным причинам не можете). В итоге все хорошо. Почему? Потому что автоматика не меняла режим работы — как тянула руль вправо, так и продолжала его тянуть. А что было бы, если бы она отключилась? В любой неожиданный для вас момент, машина резко бы ушла влево, и вы вылетели бы на встречку, прямо под едущий на вас камаз.
Или, например, на машине стоит пара датчиков, дублирующий — сломался. В итоге машина начинает входить поворот, видит, что датчик сломался и прекращает поворот, едет прямо и влетает в столб у дороги. Тоже ничего так ситуация?
Понимаете теперь, почему автоматику в случае чс должен отключать оператор, а не она сама?
проблема была именно в некорректной работе MCAS, которая направляла самолет в пикирование
Все верно, с этим никто и не спорит.
которую пилоты не смогли отключить, хотя пытались.
Так они не пытались.
Так они не пытались.
Пытались и у них получалось — на пять минут MCAS прекращала работу, но потом всё начиналось сначала. Это ввело пилотов в заблуждение, они не были уведомлены об особенностях работы этой системы. Они не пытались полностью отключить автоматику управления стабилизаторами, но саму MCAS они отключали неоднократно.
Письмо с разъяснениями экстренно разослали еще после Индонезии
Думаю, что это чрезмерно формальная и недостаточная мера.
Пилоты это не офисный планктон. Подозреваю что письма им приходят так же редко, как случаются катастрофы.
В этом случае было бы эффективнее отправить пилотов на повторную аттестацию (ну или как там правильно называется), в которой обратили бы внимание на проблему.
Пилоты и так проходят переподготовку (точнее, это скорее освежение-проверка) каждые полгода на тренажерах, и учебно-методический центр может туда добавить и эти упражнения…
По каждому случаю останавливать полеты каждого пилота пока он снова не пройдет тренинги — это ставить кучу самолетов на землю, т.к. емкость тренажеров конечна.
Более того, если обучение производится правильно, это и не требуется, если неправильно, то и не поможет…
Ну если у пилотов в итоге проводятся хотя бы повторные инструктажи, то это совсем другое дело.
Однако процедура проведения инструктажей тоже может выродиться а подписывание бумажек без дополнительной смысловой нагрузки. "Очередная формальность"
Ну если у пилотов в итоге проводятся хотя бы повторные инструктажи, то это совсем другое дело.
Не инструктаж проводится, а занятия на тренажерах. Отрабатываются различные отказы. Плюс теория сдается. Из того, что известно мне, профанации там нет.
Тогда что-то не сходится. Если занятия и экзамены проводятся ответственно, то как так может получиться что в катастрофе (пусть даже на 50%) виноваты пилоты?
Забыли инструкцию, которую они сдавали на экзамене и отрабатывали на тренажере?
Я понимаю, что они люди и могут что-то забывать. Но ведь ситуация с MCAS особенная и на нее будет обращено явно больше внимания. Может быть просто эту ситуацию не отработали?
Тогда что-то не сходится. Если занятия и экзамены проводятся ответственно, то как так может получиться что в катастрофе (пусть даже на 50%) виноваты пилоты?
1) Я говорю про подготовку пилотов даже не в России, а конкретно в UTAir. Потому как знаю ситуацию непосредственно от пилотов. Ну так ЮтЭйр больно-то и в катастрофах замечен не был. И из рассказов, сколько они вырулили ситуаций на грани, у меня не повернется язык назвать их операторами бортовой ЭВМ.
2) Вот такая вот бывает беда. Подготовка — не профанация, инструкции не забывают, а навыков — не достаточно. Подробно эта тема разбирается у Дениса Оканя. Т.е. сам подход к подготовке, без профанаций и по всей строгости, не обеспечивает должного уровня подготовки пилотов. Ярко это проявилось с катастрофой суперджета, которую некоторые попытались спихнуть на, якобы, сырую технику. На деле же, у пилотов не было подготовки по управлению лайнеров режиме direct mode, и, когда, лайнер перешел в этот режим, пилот просто не был готов к этому. Хотя 2 раза в год пилоты тренируются на тренажерах и обкатывают отказы.
Я понимаю, что они люди и могут что-то забывать.
На этот случай, у них с собой в каждом полете распечатанные чек-листы. Но некоторые моменты должны все же отлетать от зубов.
Но ведь ситуация с MCAS особенная и на нее будет обращено явно больше внимания. Может быть просто эту ситуацию не отработали?
Могу предположить, что в эфиопии совсем все плохо с КПК.
Условный низкооплачиваемый аутсорсер пишет говнокод и допускает по 100 ошибок в каждом программном модуле.
Условный штатный программист пытается вдумчиво писать хороший код, но всё равно допускает по две ошибки в каждом программном модуле.
Условный штатный тестировщик в ходе тестов выявляет ошибку с вероятностью 999 из 1000.
Количество критичных для безопасности программых модулей равно 100.
Вопрос: при условии трёх ступенчатой проверки каждого модуля штатными тестировщиками, посчитайте сколько людей погибло из-за м***цкого решения по использованию труда аутсорсеров на разработке критичных узлов конструкции и модулей ПО?
Я думал что в Америке не нанимают в топ-менеджмент конченых идиотов с купленными дипломами. Походу ошибался.
Условно это решается тем, что каждый модуль продублирован или протроирован и пишется разными программистами, то есть подразумевается, что они не наделают одинаковых ошибок и если один модуль сбойнет в каком-то месте, дублирующий все вытянет.
Аутсорсеру такое отдавать нельзя.
Так вроде в статье прямым текстом указано, что безопасность аутсорсерам не давали
И есть данные что
Rockwell Collins, производящая электронику для кабин самолётов, была одной из первых самолётостроительных компаний, передавших значительную часть своей работы в Индию, где начиная с 2000 года HCL начала тестировать их программное обеспечение. К 2010 году в HCL работало более 400 человек, занятых разработкой и тестированием ПО для Rockwell Collins, в офисах располагающихся в Ченнаи и Бангалоре.
А вот тут неоднозначно — речь идёт о том же дисплее что и выше или о более широком круге задач. Скорее всего второе.
Там прямо написано, что им давали писать ПО для основной приборной панели (интересно, за что она ещё может отвечать?).
Я думаю, что за отображение информации. Я бы не относил это к функциям, связанным с безопасностью.
Но пилоты таки видели достоверную информацию о параметрах полета (за исключением идущей от неисправного датчика)
Ну как сказать. Вот у вас в автомобиле, например, поломался спидометр и теперь он показывает всякую чушь. Будет ли это относиться к безопасности? Если да, то стоит ли ради этого дублировать спидометр и принимать другие дополнительные меры, чтобы вероятность этой неисправности снизилась до 1e-12 или сколько там требуется по стандартам безопасности?
У самолёта например положение механизации крыла, высота, скорость (она влияет на возможность управляемого полёта) — параметры, без которых полёт может и даже с большой долей вероятности закончится не по плану.
Но именно с 737MAX и MCAS условия дублирования не выполняются, и, как пишут на форумах авиации, у Боинга 3-м голосующим является человек, просто у человека не хватает времени, особенно если ему не объясняли что происходит когда "вспомогатель" основываясь на данных только одного канала решает переложить стабилизатор....
Но именно с 737MAX и MCAS условия дублирования не выполняются,
С чего это? У подавляющего большинства самолетов по два датчика угла атаки. И это не случайно, поскольку 3 датчика тоже не дают достаточной надежности для автоматического выбора правильных показаний.
В MCAS был косяк, не вижу смысла постоянно это мусолить. Плохо, что проблема подготовки пилотов вообще не рассматривается как проблема.
просто у человека не хватает времени,
У человека времени больше чем достаточно. MCAS работает циклами. За один цикл стаб перекладывается не более чем на 0.27 градуса. Между циклами перерыв — 30 секунд. Посчитайте, за сколько времени MCAS создаст аварийную ситуацию (полная перекладка на пикирование — 5 градусов).
А как посчитаете, скажите, зачем в кабине нужны пилоты, которые за 5 минут не способны сообразить, что у них стаб крутится куда-то не туда, да еще и не пытаются триммировать самолет, а противодействуют усилиям тем, что тянут штурвал на себя?
особенно если ему не объясняли что происходит когда «вспомогатель» основываясь на данных только одного канала решает переложить стабилизатор....
Зачем пилотам знать, по какой причине MCAS перекладывает стаб? Они 1) видят, что стаб перекладывается, 2) знают, что на взлете это происходить не должно.
У них на этот случай есть 2 чек-листа (которым много лет):
1) airspeed unreliable. Этот чек-лист нужно выполнять тут же, как только у них загорелось табло IAS disagree. А табло у них загорелось. Выполни они этот чек-лист и знать бы не знали, что у них есть MCAS.
2) runaway stabilizier. Ее нужно выполнять когда стаб начинает самопроизвольно перекладываться. Экипаж видит, что стаб перекладывается, но почему-то не выполняет инструкцию. Кто они после этого?
А вот нормальный экипаж в аналогичной ситуации спокойно разруливает проблему. Предпоследний полет разбившегося в индонезии лайнера. Таже картина, что и в последнем полете. Пилоты выполняют чек-лист — отключают привод стаба и спокойно летят не в аэропорт вылета, а в аэропорт назначения. Спокойно приземляются и сообщают о проблеме техникам. При чем, сообщают криво. Они не придали значения всей серьезности ситуации, в которую они попали. А все потому, что никакой серьезной проблемы не было. Была мелкая неприятность, которая, почему-то, смогла убить два самолета.
зарабатывающим всего лишь $9 в час
Что значит «всего лишь»? Это так-то $1500 в месяц (в рублях -100 тысяч) — нормальная зарплата для хорошего аутсорсера из бедной страны.
Делегирование всегда рождает накладные расходы на постановку задачи и контроль результата. Как и в программировании, разделяя две системы нужен интерфейс/протокол. К его проектированию нужно подходить особенно тщательно. Если не уделить этому должного внимания, то мы получим б итоге неэффективную систему. Так и тут, если экономия от аутсорса перекрывает расходы на дополнительную коммуникацию, то аутсорс выгоден, в противном случае нет.
Аутсорсить можно, если у тебя есть четкое представление как будут устроены коммуникация, контроль и управление. Если нет — будет все очень трудно.
У меня ощущение, что этим пренебрегают и подменяют эти необходимые стратегические решения правовыми регламентами. Кто кому что будет должен если что-то пойдет не так. Вместо того чтобы решить проблему которую мы не знаем как по-быстрому решить — решим ту которую мы знаем как решить.
Обычно Boeing/Airbus/Cessna… заключает договора на стафф-лизинг с целым ворохом компаний. Например в РФ это Прогресстех и Nic, также там дофига Индии и Китая.
Затем берется техлид с группой инженеров из компании подрядчика и перевозится в США по визе на обучение — не скажу точно какой код. Они там сидят примерно полгода на сайте у заказчика и работают там за ±60$ в день, также им оплачивают проживание, автомобиль и прочее (это дешевле чем нанимать своих, которые стоят примерно в 4-5 раз дороже). Параллельно на родине на подхвате сидит еще бригада. Через полгода они ротируются.
Ключевые специалисты обычно находятся в штате заказчика.
Не скажу за индусов и китайцев, наши при этом параллельно еще получают свою з/п. Она небольшая, но в сумме с такими «коммандировочными» получается неплохо. В итоге довольны остаются все.
Это не чистый аутсорс. Просто эти компании берут в аренду инженеров на проектной основе и скидывают с себя весь кадровый головняк (больничные, отпуска и прочее).
Самые высокооплачиваемые специалисты — прочнисты. Их мало и их очень часто хантят в голубые бэджи.
хантят в голубые бэджи
Можно поподробнее, что это? Про аренду инженеров я в курсе — немецкие автомобилисты тоже этим довольно сильно промышляют.
У меня есть пара знакомых прочнистов которые получили такие офферы. Им делают нормальные визы по спонсируемым квотам, дают американскую зарплату и все положенные бенефиты.
Но то есть человек тупо эмигрирует в США и работает в Боинге/Цессне итп как обычный белый человек.
А от чего пошло название "голубые бэджи"?
У меня просто жена работала в этой отрасли и добрая половина знакомых по универу. Я от них нахватался.
Жена вот реально по полгода в году там проводила трипами по 2-3 месяца. Больше нельзя, так как становишься налоговым нерезидентом. Понапроектировала много всяких элементов конструкции для всяких разных ихних самолетов.
У нее как раз одна из задач была — тусить там на сайте и выхватывать работу. На сайте в смысле в офисе, а не веб-сайте)
Ну в принципе это же можно сказать про "езди после этого" после очередных багов в коде какого-нибудь автопроизводителя. "лечись после этого" после бага в рентгеновском аппарате и т.д.
Это кризис отраслей, где софт начинает играть доминирующую роль.
Сейчас везде, в принципе, действительно опасно, потому что многие делают не на совесть, а так, «работает и ладно», а компании (даже крупные) стараются экономить на всем, на чем можно — и от этого страшно не только летать, но и в целом, как вы подметили, даже в поликлинику ходить. Нет уверенности, что та техника, которая есть, не подведет. Да и среди людей сложно найти шарящих в своей работе
долго меня переубедить пытались, что самолеты — самый безопасный транспорт
ИМХО если в сегодняшних реалиях собрать статистику по авариям по отношению к количеству взлетов/посадок, то и среди самолетов будут явные лидеры и аутсайдеры. И вполне возможно, что аутсайдеры будут менее безопасными, чем поезда.
долго меня переубедить пытались, что самолеты — самый безопасный транспорт
В России поезд — самый безопасный. У нас часто падают самолёты, а происшествия на поездах со смертельными исходами крайне редки. =
Сначала работала девушка. Весь день она курила, пила кофе, на её лице всё время было выражение страдания. И при этом в доме было грязно, настолько, что жильцы пожаловались и её убрали.
Заменили на парня, который прибегает, не курит, не пьёт кофе, улыбается, вставляет наушники с музыкой и подкастами и часа за 4-5 делает дневной объем работы и сваливает домой. И в доме чисто, жильцы довольны.
Я думаю зарплата у них обоих что-то в районе минималки. Дело в отношении — или берись за работу и делай на совесть, или (если считаешь, что тебе мало платят) не берись совсем, ищи что-то более соответствующее твоим знаниями и умениям. Вот эти вот страдания на рабочем месте — просто оправдания.
Но в ряде случаев жизнь ставит перед людьми совсем другой выбор — браться или умереть, например, от голода.
А если речь идёт о программировании или тестировании (как в комментарии выше), то я вообще не понимаю в чём проблема. Даже в провинции вам хватит на обычную жизнь. И зарплата среднего или пусть даже низкого уровня совсем не означает, что работу надо делать левой пяткой.
Браться или умереть — это что-то из рабовладельческого строя.
Но не во всех компаниях адекватно оценивают труд сотрудников.
И есть еще такое понятие как мотивация.
Кто-то сейчас говорит «ах, это современное слово, ну да ну да», но оно есть и применимо.
Энтузиазм это хорошо, но на одном нем далеко не уедешь и рано или поздно он сходит на нет, если ты работаешь хорошо, а тебя не продвигают и не ценят.
Нормальный человек уходит на другое место работы, но не всегда есть возможность уйти быстро и на условия лучше.
Поэтому работаешь, спустя рукава. Не обязательно не качественно. Просто не делаешь больше, чем нужно.
Я уже давно пришел к выводу, что люди работают лучше при нормальном к ним отношении со стороны руководства и достойной зп.
Прочие плюшки — довесок.
Долгие дискуссии натолкнули меня на мысль, что мол типа «эффективные менеджеры» в Боинг (подставь сюда почти любую компанию), считают, что писать программы могут быдлокодеры, которые работают у суб-суб-субподрядчиков и все будет хорошо. А «эффективные менеджеры» в авиакомпаниях тоже думают похоже: самолеты умные, можно на пилотах сэкономить! Зачем нам высококлассные (высокооплачваемые) пилоты, зачем переобучение, проверки и т.д. Тоже самое с наземными службами, зачем нам хорошие техники и инженеры! Можно тут тоже сэкономить. А потом то датчтик «соплями» забрызгают, то тряпку забудут вытащить из трубок Пито. То дырку насковозь сделают… Так что не зря есть старая украинская пословица: Дешева рибка — погана юшка.
Ну в отличии от бизнеса, в R&D все же существуют определенные и достаточно хорошо проработанные процессы разработки, благодаря которым действительно программы могут быть написаны быдлокодерами, но благодаря процессу, не будут содержать ошибок. Такие процессы обычно включают различные Gate и Peer-to-Peer Review, Чеклисты и прочие. И без заполнения тонн документов, никто не пропустит проект в следующую стадию.
Главное, чтобы этот процесс не отменили "эффективные менеджеры"
судя по всему, детские ошибки при разработке софта, приведшие к двум катастрофам с человеческими жертвами.
Двойной facepalm!!!
Сколько еще нужно объяснять, что катастрофы с человеческими жертвами произошли по вине ПИЛОТОВ, подготовка которых не отличается от уровня оператора пылесоса в бизнес-центре.
Сама Боинг признала: «наша стратегическая ошибка — проектируя самолет мы полагались на пилотов. Это было ошибкой».
Да, в софте боинга был косяк. Да, его начали исправлять после катастрофы. Но стратегическая ошибка боинга в том, что внедрив MCAS, они полагались на пилотов, которые из QRH должны были помнить действия при airspeed unreliable и runaway stabilizier и должны были с легкостью решить проблему.
На деле квалификация пилотов такова, что они тупо забили на выполнение чек-листов, в результате получили две катастрофы.
Боинг-то косяки исправит. А кто исправит пилотов?
(супер)профессионалы,
Супер — не требуется. За штурвалом должен сидеть профессионал. Достаточно, чтобы не супер. Но и не деревяшка, которая не знает своих прямых обязанностей. Никто от пилотов не требует сверхспособностей чтобы на скорости 850км/ч пролететь в узкой расщелине, как показывают в некоторых фильмах. Но, блин, мне не хочется садиться в самолет, понимая, что это игра в русскую рулетку.
Но почему Боинг может закладываться, что за штурвалом сидят (супер)профессионалы
Только из понимания, что единственное назначение пилота в кабине — парирование отказов.
а авиакомпании не могут положиться на Боинг и сказать, что самолэт умный, как-то разрулит…
А авиакомпании и полагаются на боинг. И говорят, что самолет умный и как-то разрулит. И разруливает, что самое интересное. Но — до поры до времени. Самолет буквально напичкан всевозможными системами обеспечения безопасности. Даже MCAS — одна из таких систем. Кто бы мог предположить, что в системе, единственное назначение которой — исправлять косяки пилотов, в ней самой есть косяк.
В пилоты просто так не попасть. Вася с улицы не окажется за штурвалом. Так что там профессионалы по определению.
Я это и имел в виду в комментариях, что без необходимых навыков не попасть на работу пилотом. В отличие от работы программистом, где можно пройти курсы в интернете и устроиться на работу.
Непонятно, за что заминусовали.
Для пилотов тоже есть курсы, которые дают право летать на одноместном одномоторном самолете.
Это примерно такой же уровень сложности, как и у программистов после курсов.
Например, самолет пытается взлететь. Пробежал рассчитанное для взлета расстояние, но не влетает. Что-то не так? А хз, прибавь тяги. Тяга на полную, полоса уже вот-вот кончится, может подумаем почему не взлетаем? Нэт, жми! Самолет уже катится по траве, точно уже пора тягу уменьшать и попытаться остановиться. Ты что делаешь! Тягу вернул быстро!
Три идиота угробили 40 человек.
Почитайте того же Дениса Оканя.
В опросе, проведенном профсоюзом пилотов BALPA (британская лётная ассоциация), более половины пилотов (56%) признались, что засыпали прямо в кабине, и почти треть опрошенных (29%) просыпаясь, обнаруживали, что второй пилот тоже спит.
У того же Ершова в «Исповеди ездового пса» есть как заснули все, хотя вроде как следили друг за другом…
А Денокан, если правильно помню, описывает что в их АК, например, на эшелоне разрешен «контролируемый сон», когда в кабину приглашается кто-то из стюардов/стюардесс, и один из пилотов дремлет какое-то время. Потом второй.
2я катастрофа, когда mcas включилась после взлёта, всё же есть мнение что не успели вручную открутить стаб (надо много и энергично) отрубив mcas по инструкции...
всё же есть мнение что не успели вручную открутить стаб (надо много и энергично) отрубив mcas по инструкции...
А есть мнение, что как только у них вылезло IAS disagree, незамедлительно следует выполнять чек-лист IAS unreliable. Если бы они его выполнили, то спокойно вернулись бы в аэропорт вылета. Т.е. ребята вообще ничего не делали в течении нескольких минут, пока у них стаб откручивался на пикирование, а когда наконец соизволили выключить электропривод, то уже ничего исправить было нельзя. Никто не знает, какого лешего они руками триммировать не пытались, как экипаж в Индонезии. Плюс у них разъяснение от боинга было. Прошляпать такое… Это просто вопиющий непрофессионализм. У них еще свежа в памяти индонезийская катастрофа должна была быть. Чегож они по полочкам ту катастрофу не разобрали?
А в IAS unreliable выключается mcas?
Более того, единственное заявление которое сейчас удалось найти, это то что пилоты эфиопской авиакомпании следовали строго указаниям, но до сих пор нет (вроде как) официального отчёта, поэтому утверждать о виновности пилотов некорректно. (А из-за ошибок есть ненулевая вероятность того, что системы самолёта работали ровно так как описано производителем)
Более того, единственное заявление которое сейчас удалось найти, это то что пилоты эфиопской авиакомпании следовали строго указаниям, но до сих пор нет (вроде как) официального отчёта,
Пилоты вообще не следовали указаниям:
1) Не было даже попытки выполнить airspeed unreliable. Как результат — не отключили автомат тяги. Как результат, набрали такую скорость, что руками стаб крутить бесполезно.
2) Не пытались триммировать самолет. Несмотря на то, что со штурвала все прекрасно триммировалось. Как результат, MCAS спокойно открутил стаб на пикирование
3) Когда MCAS закончил свою работу по максимальной перекладке стабилизатора. Пилоты догадались отключить электропривод стаба. А в письме от Боинга было указано, что перед отключением электропривода нужно оттриммировать самолет со штурвала, а то это может быть проблематичным.
MCAS делает больше и лучше всего по одной причине — пилоты забили на стаб.
В случае с Индонезией, пилоты успешно боролись с MCAS, пока им это не надоело. Эфиопы вообще не пытались триммировать самолет. А когда очухались, выполнили инструкцию криво и загнали себя в ситуацию, из которой не смогли выбраться. Беда в том, что попадать в такую ситуацию не следовало.
Вы всё ещё склоеяетесь к вине пилотов в том что не знали как бороться с самолётом который ведёт нюсебя не так как указано в документации? Сколько уже "проблем" нашли за время пока МАХ-ы стоят на земле? Дело видать не только в MCAS
mcas включилась после взлёта
никак не комментируя то, что после взлета эта система (по заявлениям Боинга) технически не может работать.
Проблем нашли наверное действительно много, видать копнули получше, и черти из процесса производства полезли. Надо понимать, что Боинг это что-то вроде нашего ТУ. Он предназначен бомбы, личный состав и грузы возить. Это производство двойного назначения. В отличие от эйрбасов, которые хоть и не чураются военных заказов, но все же контора, более нацеленная на потребительные свойства своих в первую очередь коммерческих изделий. Однажды Боинг уже был на грани банкротства.
А как вы определяете момент "после взлёта", разве тут было "после отрыва"? Как раз убирание закрылков это и есть окончание "взлёта", в какой момент это произошло? Там высота над уровнем моря и возможно неполная загрузка, триггером на убирание закрылков является вроде как скорость...
Далее не ного лирики:
Боинг много что писал и про то что MCAS не влияет на управление самолётом и про то что сертификация не нужна, очень много было написано Боингом в т.ч. в официальных документах, это называется заврались, а цели у этого были вполне конкретные, снижение расходов, сохранение рынка ну и всё это подкреплялось идеей о том что "ну ничего страшного, прокатит" а после первого самолёта никто не решился на себя взять ответственность, потому что дело было уже не в деньгах, а в желании жить на свободе…
Далее, про MCAS проблема даже не в том что она сработала, а оказалось что она срабатывает совсем не так как "хотел внедрявший этот костыль" а это вынужденный костыль (как выяснилось в последствии, да и не такой уж страшный если довести алгоритм его работы до ума, но тут сработал принцип "разделения ответственности" внутри корпорации, когда отдельные команды отвечают за отдельные куски и при этом даже не видят, что их системам на вход могут подаваться не достоверные данные, да и зачем им это, это же дело связующего звена в виде менеджмента, интересы которого сильно разошлись с интересами безопасности, не везде но местами. Это всё лирика, да, но увы 2 самолёта и, возможно, разрушенная база и человеческий потенциал накопленный годами.
p.s про то что в документации написано, два дня назад поймал ошибочную работу 12го оракла, очень длинный запрос, много left join к одной строке, так вот после добавления последнего, получаем пустой результат, убираем одна строка, сначала подумал, да ну его, не может быть… но разные клиенты/хинты/дни… Результат повторяется… Отослал архитектору, говорит, да та же… что и у меня… А ведь "так не может быть", "документация", "крупная компания", годами проверенная версия (12) крутое схд, платформа не непонятный х86 а настоящий IBM power и т.д… но увы… Судя по всему, исходя из того что было написано за прошедшее время после катастрофы, когда копнули, там уже и непонятно стало, как там эта система отработала в конкретном случае...
Вопрос как это потом сертифицировалось by FAA in acc with FAR21/25 plus Do-178B требованиями. Платить Боинг мог столько сколько хотел 9, 10, 5 баксов в час… Задача Aviation Authorities (Faa USA, EASA Eu ) через процесс разработки сертифицировать софт через жесткий контроль процесса его создания.
Естественно, под давлением менеджеров «давай давай» возникает соблазн срезать углы…
Да у Боинга есть так называемая Design Organization Approval который дает право на определенные изменения давать approvals, причем дают это спец представители FAA(delegate engineers), которые независимые от менеджмента и отвечают своими sign offs головой.
Не буду спорить что в любой ситуации виноват менеджмент :))
И, что самое страшное, непрофессионализм захватывает все больше и больше и все более серьезхные сферы жизнедеятельности. Куда мы катимся?
Программное обеспечение для серии 737-Max было написано во времена, когда компания Боинг увольняла опытных инженеров и оказывала давление на поставщиков.
Более того, икона американского самолетостроения и ее субподрядчики, доверяли временным работникам, зарабатывающим всего лишь $9 в час, разрабатывать и тестировать свое программное обеспечение. Зачастую, это были работники из стран с неразвитым самолетостроением, а именно из Индии.
Ржали всей Индией.
При этом, в той, части, где речь идет о функциональной безопасности, процент нового кода желательно чтобы был еще меньше. В идеале 0.
В свете этого, решение «а давайте индусы нам все перепишут с нуля» выглядит не очень умным. Ведь обычно при переписывании «всего и с нуля» что-то ломается даже у экспертов.
Урезать зарплату ТОП менеджерам? Нет, не могу себе представать.
PS Но это всё к вам не относится, судя по вот этой вашей цитате:
… на Земле работ еще до фига (...) Когда будет общепланетарный бесплатный транспорт, без границ и таможен, единый язык, базовые потребности каждого жителя планеты будут бесплатно обеспечены, когда будет ликвидирован голод, когда…, во тогда можно и о полётах к Луне подумать.Хотелось бы более полно ознакомиться с вашей картиной предпочтительного будущего (не сарказм).
Что изменилось с тех пор? Неужели всю команду инженеров заменили на аутсорс?
Блумберг конечно передергивает (сложилось такое впечатление), так как их задача — хайп и просмотры, поэтому написанное нужно делить на два.
Ну если учесть, что им наверняка известны не все случаи (даже если предположить, что пишут о всех, которые известны), то я бы наоборот умножил: )
Софт для Boeing-737 Max писался аутсорсерами, зарабатывающими $9 в час