Часто можно слышать, что С++ выбирают за быстроту при большом многообразии выразительных средств. И вот читая очередную статью про противоестественную ошибку на пустом месте у меня вдруг возник вопрос: а как вообще в более-менее крупных проектах выполняется контроль сгенерированного кода? Вот допустим описал программист нетривиальный конструктор у класса, который должен по всем правилам избегать двойного копирования (copy elision, move semantics, etc.), но запутался в l-value и r-value ссылках, в итоге код получился неоптимальным. Но если судить по тем статьям, что описывают такие случаи, то проблема обнаруживается или когда бинарный код начинает неимоверно жиреть, или когда производительность заметно падает в узких местах. Получается, что чтобы пользоваться всеми преимуществами С++, нужно или каждый метод при каждом изменении прогонять через godbolt и глазами убеждаться, что компилятор понял идею автора правильно, или обложиться тестами производительности по самое не хочу. Или есть какой-то другой метод? Вариант "мы нанимаем только экспертов С++" я не рассматриваю, потому что вся история ЭВМ построена на уменьшении влияния человеческого фактора на процесс построения корректных и эффективных программ. И вот ещё одно интересное наблюдение: многие именитые фигуры из мира С++ вроде Герба Саттера как таковой рабочий код не пишут, они могут обсуждать новый стандарт, разные скользкие моменты, идиоматичность разных конструкций и вообще что-угодно, кроме написания production-ready кода. А один из самых известных авторов и проповедников С++, Скотт Мейерс, вообще ни разу в жизни не работал программистом, если верить ему самому. Только вдумайтесь — человек, который консультирует в области использования С++, сам никогда не писал на нём!
Данная тема — не попытка развязать сотый holly war на тему, просто мне всегда было интересно, как пользоваться С++ правильно. На тех, проектах, где я работал, ситуация всегда была в духе "хотели как лучше, а получились как всегда" в том смысле, что кодовая база росла, программисты была разного качества, кто-то писал идиоматичных С++, кто-то на Си с конструкторами, всё это было приправлено сегфолтами и всё в таком духе.
Здравствуйте, cppguard, Вы писали:
C>Данная тема — не попытка развязать сотый holly war на тему, просто мне всегда было интересно, как пользоваться С++ правильно. На тех, проектах, где я работал, ситуация всегда была в духе "хотели как лучше, а получились как всегда" в том смысле, что кодовая база росла, программисты была разного качества, кто-то писал идиоматичных С++, кто-то на Си с конструкторами, всё это было приправлено сегфолтами и всё в таком духе.
Смотря что за проект. Если результат не сильно критичен по скорости, то ляпы могут закрадываться. Если критичен, то пишутся тесты на корректность результата и скорость работы. Запустили, тесты прошло, медленнее не стало — ок. Если стало медленнее, то уже разбираться.
Здравствуйте, cppguard, Вы писали:
C>Часто можно слышать, что С++ выбирают за быстроту при большом многообразии выразительных средств. И вот читая очередную статью про противоестественную ошибку на пустом месте у меня вдруг возник вопрос: а как вообще в более-менее крупных проектах выполняется контроль сгенерированного кода? Вот допустим описал программист нетривиальный конструктор у класса, который должен по всем правилам избегать двойного копирования (copy elision, move semantics, etc.), но запутался в l-value и r-value ссылках, в итоге код получился неоптимальным. Но если судить по тем статьям, что описывают такие случаи, то проблема обнаруживается или когда бинарный код начинает неимоверно жиреть, или когда производительность заметно падает в узких местах. Получается, что чтобы пользоваться всеми преимуществами С++, нужно или каждый метод при каждом изменении прогонять через godbolt и глазами убеждаться, что компилятор понял идею автора правильно, или обложиться тестами производительности по самое не хочу. Или есть какой-то другой метод? Вариант "мы нанимаем только экспертов С++" я не рассматриваю, потому что вся история ЭВМ построена на уменьшении влияния человеческого фактора на процесс построения корректных и эффективных программ. И вот ещё одно интересное наблюдение: многие именитые фигуры из мира С++ вроде Герба Саттера как таковой рабочий код не пишут, они могут обсуждать новый стандарт, разные скользкие моменты, идиоматичность разных конструкций и вообще что-угодно, кроме написания production-ready кода. А один из самых известных авторов и проповедников С++, Скотт Мейерс, вообще ни разу в жизни не работал программистом, если верить ему самому. Только вдумайтесь — человек, который консультирует в области использования С++, сам никогда не писал на нём!
C>Данная тема — не попытка развязать сотый holly war на тему, просто мне всегда было интересно, как пользоваться С++ правильно. На тех, проектах, где я работал, ситуация всегда была в духе "хотели как лучше, а получились как всегда" в том смысле, что кодовая база росла, программисты была разного качества, кто-то писал идиоматичных С++, кто-то на Си с конструкторами, всё это было приправлено сегфолтами и всё в таком духе.
Все вышеозначенные саттеры и мейерсы пишут о языке, а упомянутые проблемы это не проблемы языка, а проблемы архитектуры скорее, проблемы стиля, проблемы организации проекта.
Те же самые проблемы могли быть с любым языком
Здравствуйте, cppguard, Вы писали:
C>как вообще в более-менее крупных проектах выполняется контроль сгенерированного кода? Вот допустим описал программист нетривиальный конструктор у класса, который должен по всем правилам избегать двойного копирования (copy elision, move semantics, etc.), но запутался в l-value и r-value ссылках, в итоге код получился неоптимальным.
По-моему, в подавляющем большинстве проектов, хоть крупных, хоть мелких, на это тупо забивают большой болт.
C>Но если судить по тем статьям, что описывают такие случаи, то проблема обнаруживается или когда бинарный код начинает неимоверно жиреть, или когда производительность заметно падает в узких местах.
И при этом пороги "неимоверно" и "заметно" тоже значительно завышены. То есть, ситуация, когда двоичный код на порядок-два жирнее и/или тормознее оптимального, уже давно считается нормой. С объемом и вовсе уже страх потеряли — если помещается на диск и в ОЗУ более-менее типичного компьютера, то и ладно. С производительностью разбираться начинают, только если тормоза совсем уж запредельные, а выполнение за секунды операций, которые можно достаточно легко уложить в сотни, а то и десятки, миллисекунд, тоже считается вполне комильфо.
C>Получается, что чтобы пользоваться всеми преимуществами С++, нужно или каждый метод при каждом изменении прогонять через godbolt и глазами убеждаться, что компилятор понял идею автора правильно, или обложиться тестами производительности по самое не хочу. Или есть какой-то другой метод?
Ну я периодически поглядываю на результаты трансляции в ассемблерный код. Но у меня много кода, где даже лишние единицы миллисекунд создают проблемы, поэтому он имеет относительно простую структуру. В некритичных местах использую простенькие (по нынешним временам) вложенные шаблонные классы, создающие временные объекты, так вот порожденный ими код анализировать уже весьма неуютно. Представляю, что получается при активном использовании современных библиотечных средств, вместе с исключениями и RTTI. Там уже только тесты.
C>Вариант "мы нанимаем только экспертов С++"
Современному эксперту C++ положено знать только синтаксис и семантику языка, но не объем/быстродействие результирующего кода.
C>многие именитые фигуры из мира С++ вроде Герба Саттера как таковой рабочий код не пишут
Конкретно за Саттера не помню, но многие именитые авторы временами упоминают те или иные реальные проекты. Другое дело, что упоминают лишь вскользь и весьма абстрактно, особо практических выводов из этого не сделаешь.
C>они могут обсуждать новый стандарт, разные скользкие моменты, идиоматичность разных конструкций и вообще что-угодно, кроме написания production-ready кода.
Они все исходят из того, что достаточно устаканить форму, свойства и методы соединения отдельных элементарных блоков, а дальше из этих блоков любой сможет собрать конструкцию любой сложности. Именно так и происходит в схемотехнике, но там ограничения по месту/объему, скорости и потреблению энергии гораздо строже. Грубо говоря, нынешняя технология софтописания на словах напоминает разработку красивой печатной платы на микросхемах, с автоматизированной разводкой и монтажом, а результаты больше напоминают ЭВМ 50-60-х, состоящие из множества шкафов, набитых блоками и жгутами проводов, к которым прилагался инженерный отдел для сопровождения и ремонта.
А один из самых известных авторов и проповедников С++, Скотт Мейерс, вообще ни разу в жизни не работал программистом, если верить ему самому. Только вдумайтесь — человек, который консультирует в области использования С++, сам никогда не писал на нём!
C>Данная тема — не попытка развязать сотый holly war на тему, просто мне всегда было интересно, как пользоваться С++ правильно. На тех, проектах, где я работал, ситуация всегда была в духе "хотели как лучше, а получились как всегда" в том смысле, что кодовая база росла, программисты была разного качества, кто-то писал идиоматичных С++, кто-то на Си с конструкторами, всё это было приправлено сегфолтами и всё в таком духе.
Здравствуйте, Nuzhny, Вы писали:
N>Смотря что за проект. Если результат не сильно критичен по скорости, то ляпы могут закрадываться. Если критичен, то пишутся тесты на корректность результата и скорость работы. Запустили, тесты прошло, медленнее не стало — ок. Если стало медленнее, то уже разбираться.
Почему бы тогда не писать на Java или Haskell? Скорость та же, вероятность ошибиться — меньше.
Здравствуйте, Lucky Cat, Вы писали:
LC>Те же самые проблемы могли быть с любым языком
Не, не с любым, плюсы в этом плане сильно выделяются. На всяких питонах узкие куда более очевидны.
Здравствуйте, Lucky Cat, Вы писали:
LC>Все вышеозначенные саттеры и мейерсы пишут о языке, а упомянутые проблемы это не проблемы языка, а проблемы архитектуры скорее, проблемы стиля, проблемы организации проекта. LC>Те же самые проблемы могли быть с любым языком
В том-то и дело, что не с любым! Перед тем, как написать пост, я пытался вспомнить случаи из практики, связанные с Python или Java, и не смог. Лишь могу вспомнить баг Java на x86, когда запись long не была атомарной, и в случае состояния гонки простая запись в переменную могла создать там мусор.
Здравствуйте, cppguard, Вы писали:
C>Данная тема — не попытка развязать сотый holly war на тему, просто мне всегда было интересно, как пользоваться С++ правильно. На тех, проектах, где я работал, ситуация всегда была в духе "хотели как лучше, а получились как всегда" в том смысле, что кодовая база росла, программисты была разного качества, кто-то писал идиоматичных С++, кто-то на Си с конструкторами, всё это было приправлено сегфолтами и всё в таком духе.
Потому все известные ныне бест-практикс давно описали формально и запихнули в статические анализаторы кода.
В случае использования на проекте того же Golang статический анализ тоже присутствует в обязательном порядке, только называются линтерами.
В общем, чего-то не в тех командах, не в тех проектах довелось работать. Вещь настолько банальная, как и юнит-тесты. Можно сказать, вопрос на уровне того, как лет 15 назад не все пользовались баг-треккингом и VCS, да спрашивали о том надо ли, а как и зачем.
Здравствуйте, cppguard, Вы писали:
N>>Смотря что за проект. Если результат не сильно критичен по скорости, то ляпы могут закрадываться. Если критичен, то пишутся тесты на корректность результата и скорость работы. Запустили, тесты прошло, медленнее не стало — ок. Если стало медленнее, то уже разбираться. C>Почему бы тогда не писать на Java или Haskell? Скорость та же, вероятность ошибиться — меньше.
Потому что исторически моя предметная область живёт на С++. Может быть, часть переедет на Rust, но пока к этому особых предпосылок нет.
Здравствуйте, Skorodum, Вы писали:
LC>>Те же самые проблемы могли быть с любым языком
S>Не, не с любым, плюсы в этом плане сильно выделяются.
Когда-то плюсы тоже не выделялись. Сильно выделяться они стали только после того, как нормой программирования на плюсах стало извращенное и неумеренное использование сложношаблонных конструкций, отслеживать которые гораздо труднее, чем макросы того же уровня сложности.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Когда-то плюсы тоже не выделялись. Сильно выделяться они стали только после того, как нормой программирования на плюсах стало извращенное и неумеренное использование сложношаблонных конструкций, отслеживать которые гораздо труднее, чем макросы того же уровня сложности.
Не только. Например, у меня программа использует код на CUDA или что-то с тяжёлыми вычислениями на CPU. Что мне делать? Какие инструкции можно использовать? Получается, что я ставлю CUDA компилятору флаги, чтобы код собирался под пяток последних архитертур видеокарты — код распухает. Также я подключаю библиотеки от Nvidia, которые также собраны под несколько архитектур — они размером в сотни мегабайт. Аналогично для CPU: у меня серия бинарников, собранных для SSE, AVX, AVX2... Далее у меня Intel MKL, который тоже содержит в себе реализацию одних и тех же функций, оптимизированных под разные архитектуры — тоже сотни мегабайт.
Вот это всё хозяйство включается в установщик и кажется: что так много?!! Да, можно сократить объём кода на порядок, но он либо будет работать не оптимально на современном железе, либо вообще не будет работать у кучи пользователей. Теперь можно подумать, что важнее пользователю экономить память или скорость работы приложения (это ещё и батарейка ноута, его нагрев, экономия ядер на сервере)? По факту оказывается, что для экологии логичней экономить такты, а не объёмы.
Здравствуйте, Nuzhny, Вы писали:
N>Например, у меня программа использует код на CUDA или что-то с тяжёлыми вычислениями на CPU. Что мне делать? Какие инструкции можно использовать?
Ну, на низком уровне это всегда было проблемой. Тут ни сам C++, ни новые технологии его использования ничего нового не внесли.
N>Получается, что я ставлю CUDA компилятору флаги, чтобы код собирался под пяток последних архитертур видеокарты — код распухает.
В этом случае он распухает, как я понимаю, чисто за счет добавления поддержки разной аппаратуры. Это тоже было всегда, и тоже не зависит от языка.
N>Также я подключаю библиотеки от Nvidia, которые также собраны под несколько архитектур — они размером в сотни мегабайт. Аналогично для CPU: у меня серия бинарников, собранных для SSE, AVX, AVX2... Далее у меня Intel MKL, который тоже содержит в себе реализацию одних и тех же функций, оптимизированных под разные архитектуры — тоже сотни мегабайт.
А вот это уже интересно. Что там может занимать сотни мегабайт, кроме каких-нибудь таблиц для оптимизации вычислений?
Здравствуйте, cppguard, Вы писали:
C> И вот читая очередную статью про противоестественную ошибку на пустом месте
Лично я не считаю использование преобразование типов в стиле Си пустым местом. А если б его не было, то компилятор выдал бы хотя бы предупреждение
C> у меня вдруг возник вопрос: а как вообще в более-менее крупных проектах выполняется контроль сгенерированного кода?
Это не надо. У тебя есть два три типа проектов:
1) 99% это проекты где тебе не очень важно что там сгенерирует компилятор. Ты знаешь что двоичный код C++ достаточно эффективен и тебе этого хватает. В таком случае ты включаешь динамические (sanitizer-ы) и статические (clang-tidy и компания) анализаторы, пишешь модульные тесты и радуешься тому что у тебя такой классный и не падучий код. Код реально будет очень классным и почти не будет падать по причинам плохого знания C++. Что значит "почти"? Почти значит — ты всё еще можешь устроить гонки, если постараешься, но в каком языке ты не можешь? ааа... правильно, в любом можешь если хорошо постараешься!
2) ты в 0.5% проекторв где важна safety (хрен знает как на русский перевести, ОБЖ короче). Это когда у тебя атомный реактор или критический компонент в самолете или самоходной карете. Ну, ты в жопе, тут ничего иного не скажешь. Если ты вдруг в неё залез, то ты пишешь на Си-с-классами где нельзя кидать исключения, нельзя выделять память динамически и много других "нельзя". Из хороших моментов, тот компилятор что ты исполняешь тебя сразу бьет по рукам за попытку прыжка на месте (а иногда и расстреливает), а статический анализатор (за который ты отвалил дохулиард не-рублей) так же, сцуко, люто бдит. В итоге у тебя код где ты точно знаешь что и почему происходит, но за очень много денег, т.к. твоя производительность упала в 5-10 раз.
3) ты в другой части 0.5% проектов, которые пишут трейдеры. Ну... тут ты прав и godbolt, кажется написанный трейдером, твой лучший друг и советник
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А вот это уже интересно. Что там может занимать сотни мегабайт, кроме каких-нибудь таблиц для оптимизации вычислений?
Я хз. Но сами разработчики MKL рассказывали, что у них множество независимых реализаций одних и тех же функций на своих интрисиках/ассемблере и со своими настройками. Оно всегда было объёмным, но с каждым годом становится всё больше и больше.
включаю в настройках проекта режим сохранения ассемблерного листинга вместе с исходным с++ кодом
смотрю какой ассемблерный код генерится в интересующих меня местах
гдето меняю с++ код и перекомпиливаю, потом Araxis Merge сравниваю новый ассемберный код со старым, делаю выводы.
Здравствуйте, kaa.python, Вы писали:
KP>2) ты в 0.5% проекторв где важна safety (хрен знает как на русский перевести, ОБЖ короче).
Я бы перевел как "надежность".
KP>Из хороших моментов, тот компилятор что ты исполняешь тебя сразу бьет по рукам за попытку прыжка на месте (а иногда и расстреливает), а статический анализатор (за который ты отвалил дохулиард не-рублей) так же, сцуко, люто бдит.
Сейчас опенсорсные статические анализаторы стали очень даже. Не удивлюсь, если они более толковые на практике, чем эти, за большие деньги.
Проблема дорогих инструментов в том, что у них три с половиной пользователя, да и те не по своей воле. Сколько бы в их разработку денег не вкладывалось, большая пользовательская база очень важна.
Здравствуйте, cppguard, Вы писали:
C>Часто можно слышать, что С++ выбирают за быстроту при большом многообразии выразительных средств. И вот читая очередную статью про противоестественную ошибку на пустом месте у меня вдруг возник вопрос: а как вообще в более-менее крупных проектах выполняется контроль сгенерированного кода?
Да никак он там не выполняется, по большей части.
Ценность контроля за бинарным выхлопом компилятора очень переоценена. Большая часть кода любой программы исполняется очень редко, и совершенно не важно, сколько ресурсов этот код потребляет, лишь бы укладывался в разумно достижимые.
C>Часто можно слышать, что С++ выбирают за быстроту при большом многообразии выразительных средств. И вот читая очередную статью про противоестественную ошибку на пустом месте
так там нет ошибки
и в комментах там очень сильно все разжевали
Контролировать надо не код, а способность его решать бизнес-задачи. На критичные по производительности задачи пишутся тесты, где проверяется время исполнения. Если время удовлетворяет требованиям, то пусть там хоть тройное неявное копирование вектора строк выполняется — пользователь этого не заметит.
А если производительность падает ниже желаемой, то подключается профайлер и все быстро оптимизируется до нужной степени.
Здравствуйте, Nuzhny, Вы писали:
N>Я хз. Но сами разработчики MKL рассказывали, что у них множество независимых реализаций одних и тех же функций на своих интрисиках/ассемблере и со своими настройками. Оно всегда было объёмным, но с каждым годом становится всё больше и больше.
А можно сделать такой пакетный менеджер, чтоб он автомагически подтягивал подходящие под фичесет проца сборки? Вместо чтоб устанавливать весь багаж? Или с учётом объёмов современного медиа, это неоправданная трата ресурсов на поддержку зоопарка?
Здравствуйте, Тёмчик, Вы писали:
Тё>А можно сделать такой пакетный менеджер, чтоб он автомагически подтягивал подходящие под фичесет проца сборки? Вместо чтоб устанавливать весь багаж? Или с учётом объёмов современного медиа, это неоправданная трата ресурсов на поддержку зоопарка?
По хорошему, так и надо делать хотя бы со своими библиотеками.
Здравствуйте, reversecode, Вы писали:
R>так там нет ошибки R>и в комментах там очень сильно все разжевали
Ошибки нет, есть неожиданное поведение. Я вот не могу себе представить, чтобы что-то подобное было в Java. Оно есть, конечно. Вот буквально недавно была засада с IdentityHashSet, но там причиной была реализация, а не стандарт языка. А в С++ проблемы на каждом шагу именно из-за невероятной сложности стандарта, а его всё расширают и расширают...
Здравствуйте, Pzz, Вы писали:
Pzz>совершенно не важно, сколько ресурсов этот код потребляет, лишь бы укладывался в разумно достижимые.
Беда лишь в том, что эта "разумная достижимость" почти всегда оценивается на машине разработчика, которая, как правило, по ресурсам значительно превосходит среднюю пользовательскую. Поэтому, когда разработчик полагает, что у него еще есть значительный запас по ресурсам, у пользователя ситуация уже приближается к критической, а когда до разработчика наконец дойдет, что пользователи недовольны не зря, вернуть ситуацию под контроль может быть непросто.
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>совершенно не важно, сколько ресурсов этот код потребляет, лишь бы укладывался в разумно достижимые.
ЕМ>Беда лишь в том, что эта "разумная достижимость" почти всегда оценивается на машине разработчика, которая, как правило, по ресурсам значительно превосходит среднюю пользовательскую. Поэтому, когда разработчик полагает, что у него еще есть значительный запас по ресурсам, у пользователя ситуация уже приближается к критической, а когда до разработчика наконец дойдет, что пользователи недовольны не зря, вернуть ситуацию под контроль может быть непросто.
Мне ведь не надо тебе объяснять, что нет смысла вылизывать до микросекунды (и, даже, до 1/10 секунды) код, который один раз при старте программы читает ее конфигурационный файл. А код, который медленно и уныло рисует на экране карту, надо оптимизировать изо всех сил, потому что он все равно будет слишком тормозным. Ты и сам это прекрасно понимаешь. А многие не понимают, в том и беда.
А так, я с тобой не спорю, разработчики склонны переоценивать количество ресурсов на компьютере у пользователя. У меня, например, Яндекс.Карты в режиме навигатора высаживают батарейку на телефоне быстрее, чем беспроводная зарядка успевает ее заряжать. А когда телефон был новым, это было не так — тогда Яндекс ориентировался на мощности, сравнимые с мои телефоном, а теперь мощность того, на что они ориентируются, сильно возрасла.
Здравствуйте, Pzz, Вы писали:
Pzz>нет смысла вылизывать до микросекунды (и, даже, до 1/10 секунды) код, который один раз при старте программы читает ее конфигурационный файл.
До десятой секунды можно и не вылизывать, но уже давно стало нормой открывать/закрывать тот файл при запросе каждого параметра. В итоге, при тестировании на мелких файлах, оно работает очень быстро, а когда файл разрастается до тысяч и десятков тысяч строк, "внезапно" начинает тормозить.
Pzz>разработчики склонны переоценивать количество ресурсов на компьютере у пользователя.
Подозреваю, что многие разработчики вообще не представляют себе компьютер среднего пользователя. На работе им дают продвинутую рабочую станцию, дома у них продвинутый игровой компьютер (ибо платят хорошо), поэтому они искренне полагают, что у всех остальных не хуже.
Pzz>У меня, например, Яндекс.Карты в режиме навигатора высаживают батарейку на телефоне быстрее, чем беспроводная зарядка успевает ее заряжать. А когда телефон был новым, это было не так — тогда Яндекс ориентировался на мощности, сравнимые с мои телефоном, а теперь мощность того, на что они ориентируются, сильно возрасла.
А возросло ли с тех пор удобство пользования картами? Если да, то пропорционально ли?
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>У меня, например, Яндекс.Карты в режиме навигатора высаживают батарейку на телефоне быстрее, чем беспроводная зарядка успевает ее заряжать. А когда телефон был новым, это было не так — тогда Яндекс ориентировался на мощности, сравнимые с мои телефоном, а теперь мощность того, на что они ориентируются, сильно возрасла.
ЕМ>А возросло ли с тех пор удобство пользования картами? Если да, то пропорционально ли?
Нет, ухудшилось. Они еще гуйню периодически переверстывают. Только к одному варианту привыкнешь, сразу другой выкатят.
Здравствуйте, Pzz, Вы писали:
ЕМ>>А возросло ли с тех пор удобство пользования картами? Если да, то пропорционально ли?
Pzz>Нет, ухудшилось. Они еще гуйню периодически переверстывают. Только к одному варианту привыкнешь, сразу другой выкатят.
О том и речь. "Этакое состояние запора при бурной работе организма".
КД>>1. вагоны ассертов внизу. КД>>2. эшелоны многоуровневых тестов вверху. КД>>3. круглосуточное тестирование. S>В чем разница между 2 и 3?
Наверное, имелось ввиду, что тесты прогоняются не один раз перед релизом, а при каждом коммите. Или даже fuzzy-testing, который действительно имеет смысл гонять круглосуточно.
Здравствуйте, flаt, Вы писали:
КД>>>2. эшелоны многоуровневых тестов вверху. КД>>>3. круглосуточное тестирование. S>>В чем разница между 2 и 3?
F>Наверное, имелось ввиду, что тесты прогоняются не один раз перед релизом, а при каждом коммите.
Сейчас вроде 2021, а не 2001 и очевидно, что "есть тесты" значит "что есть CI/CD с тестами на каждый коммит" По другому смысла не особо много.
F>Или даже fuzzy-testing, который действительно имеет смысл гонять круглосуточно.
Это уже интереснее.
KP>2) ты в 0.5% проекторв где важна safety (хрен знает как на русский перевести, ОБЖ короче). Это когда у тебя атомный реактор или критический компонент в самолете или самоходной карете. Ну, ты в жопе, тут ничего иного не скажешь. Если ты вдруг в неё залез, то ты пишешь на Си-с-классами где нельзя кидать исключения, нельзя выделять память динамически и много других "нельзя". Из хороших моментов, тот компилятор что ты исполняешь тебя сразу бьет по рукам за попытку прыжка на месте (а иногда и расстреливает), а статический анализатор (за который ты отвалил дохулиард не-рублей) так же, сцуко, люто бдит. В итоге у тебя код где ты точно знаешь что и почему происходит, но за очень много денег, т.к. твоя производительность упала в 5-10 раз.
И при этом все равно на выходе получается MCAS, минус два самолета, минус овер триста человек и никто уже не считает сколько убытков
Здравствуйте, landerhigh, Вы писали:
L>И при этом все равно на выходе получается MCAS, минус два самолета, минус овер триста человек и никто уже не считает сколько убытков
Уже 100500 раз было разжевано, что тот MCAS сам по себе ни разу не фатален. Да, он тупил, но было достаточно несложно ему противодействовать. Если бы пилоты лучше понимали устройство и работу самолета, принципы управления, они бы с высокой вероятностью вытянули ситуацию. Но большинство пилотов предпочитает тупо зазубрить типовые варианты, как большинство водителей — типовые схемы поведения на дороге.
Здравствуйте, landerhigh, Вы писали:
L>И при этом все равно на выходе получается MCAS, минус два самолета, минус овер триста человек и никто уже не считает сколько убытков
Мне кажется, уровень сложности систем уже зашкаливает и несмотря на все эти методологии иногда выходит хтонь. В итоге что ты не делай, вероятность ошибки повышается, ещё ведь и коммерчески выгодное решение должно быть.
Здравствуйте, Евгений Музыченко, Вы писали:
L>>И при этом все равно на выходе получается MCAS, минус два самолета, минус овер триста человек и никто уже не считает сколько убытков ЕМ>Уже 100500 раз было разжевано, что тот MCAS сам по себе ни разу не фатален.
Нет.
При анализе (FMEA) состояния, когда система войдет в состояние, которое требует немедленного вмешательства оператора для предотвращения аварии, считаются катастрофическими сценариями отказа. При наличии подобных сценариев система к продакшену не допускается и отправляется на переработку, возможно даже с нуля.
Направление самолета носом в землю — хрестоматийный вид катастрофический отказа. Как раз сам по себе MCAS — фатален.
ЕМ>Да, он тупил, но было достаточно несложно ему противодействовать. Если бы пилоты лучше понимали устройство и работу самолета, принципы управления, они бы с высокой вероятностью вытянули ситуацию. Но большинство пилотов предпочитает тупо зазубрить типовые варианты, как большинство водителей — типовые схемы поведения на дороге.
Оператор не может рассматриваться в качестве защиты от катастрофичного сценария поведения оборудования.
Здравствуйте, kaa.python, Вы писали:
KP>Мне кажется, уровень сложности систем уже зашкаливает и несмотря на все эти методологии иногда выходит хтонь. В итоге что ты не делай, вероятность ошибки повышается, ещё ведь и коммерчески выгодное решение должно быть.
Да нет, просто этот MCAS писали обезьяны под управлением ослов. Или наоборот.
Это, по сути, вообще довольно тривиальный конечный автомат, который, будучи написан прямыми руками, даже в случае одного датчика вставал бы в безопасный отказ.
Здравствуйте, landerhigh, Вы писали:
L>При анализе (FMEA) состояния, когда система войдет в состояние, которое требует немедленного вмешательства оператора для предотвращения аварии, считаются катастрофическими сценариями отказа. При наличии подобных сценариев система к продакшену не допускается и отправляется на переработку, возможно даже с нуля.
Безусловно, система кривая. Но этот косяк почти везде подают, как "MCAS уронил самолет, пилоты ничего не могли сделать". А они могли, и еще как.
L>Направление самолета носом в землю — хрестоматийный вид катастрофический отказа.
MCAS не "направлял самолет носом в землю" целенаправленно, а неадекватно реагировал на неисправность датчиков. Это хрестоматийный случай "перерегулирования". Если бы в алгоритме были жесткие ограничения, то в другой ситуации он из-за них не выправил бы самолет.
L>Оператор не может рассматриваться в качестве защиты от катастрофичного сценария поведения оборудования.
Это будет верно, когда люди в кабине самолета будут называться "операторами", и их задачей будет лишь наблюдение за показаниями приборов, и нажатие аварийной кнопки в нештатной ситуации. Пока же они называются "пилотами", а их деятельность называется "управление самолетом".
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Безусловно, система кривая. ЕМ>Но этот косяк почти везде подают, как "MCAS уронил самолет, пилоты ничего не могли сделать". А они могли, и еще как.
Совершенно верно. MCAS уронил самолет.
Пилоты не смогли понять, что происходит. На минутку — о том, что в самолете есть какой-то MCAS, им рассказать "забыли".
L>>Направление самолета носом в землю — хрестоматийный вид катастрофический отказа. ЕМ>MCAS не "направлял самолет носом в землю" целенаправленно, а неадекватно реагировал на неисправность датчиков. Это хрестоматийный случай "перерегулирования".
Это и есть "целенаправленно". Оно было реализовано так, чтобы направлять самолет носом в землю, если показания датчиков того велят. В соответствии со спецификациями.
ЕМ>Если бы в алгоритме были жесткие ограничения, то в другой ситуации он из-за них не выправил бы самолет.
В этом и состоит предназначение FMEA, чтобы выяснить, какие ограничения должен алгоритм иметь.
L>>Оператор не может рассматриваться в качестве защиты от катастрофичного сценария поведения оборудования.
ЕМ>Это будет верно, когда люди в кабине самолета будут называться "операторами", и их задачей будет лишь наблюдение за показаниями приборов, и нажатие аварийной кнопки в нештатной ситуации. Пока же они называются "пилотами", а их деятельность называется "управление самолетом".
Это верно всегда. Без исключений.
Пилот может быть банально перегружен.
Добавим еще одну нештатную ситуацию на взлете. Птицы. Пожар двигателя. Отказ гидравлики. Кстати, любая из этих ситуаций может вывести из строя еще и датчик угла атаки за компанию, тем самым инициировав работу MCAS в режиме камикадзе.
Все, четырех рук банально не хватит, какими бы опытными не были оба пилота.
Здравствуйте, landerhigh, Вы писали:
L>MCAS уронил самолет.
Самолет уронили пилоты. MCAS этому только способствовал.
L>Пилоты не смогли понять, что происходит.
Именно. Потому, что были подготовлены на уровне "вот это — газ, это — тормоз, а это лучше вообще не трогай".
L>о том, что в самолете есть какой-то MCAS, им рассказать "забыли".
Верно, это косяк Боинга. А косяк пилотов — в том, что не интересовались устройством самолета за пределами типового обучения.
L>Это и есть "целенаправленно". Оно было реализовано так, чтобы направлять самолет носом в землю, если показания датчиков того велят. В соответствии со спецификациями.
Ну, тогда опишите, каким образом MCAS отслеживает тангаж, чтобы "целенаправленно" ориентировать нос в сторону земли. Или используйте более адекватные понятия.
L>>>Оператор не может рассматриваться в качестве защиты от катастрофичного сценария поведения оборудования. L>Это верно всегда. Без исключений.
Тогда попробуйте объяснить, для чего в кабине самолета нужны люди, если оборудование ни при каких условиях не может войти в катастрофический сценарий, для защиты от которого может потребоваться человек.
L>Пилот может быть банально перегружен.
Может. Но он должен быть способен за вменяемое время распознать ситуации, на которые может повлиять.
L>Добавим еще одну нештатную ситуацию на взлете. Птицы. Пожар двигателя. Отказ гидравлики. Кстати, любая из этих ситуаций может вывести из строя еще и датчик угла атаки за компанию, тем самым инициировав работу MCAS в режиме камикадзе. L>Все, четырех рук банально не хватит, какими бы опытными не были оба пилота.
А на все случаи никогда всего не хватит. В данных случаях сошлись вместе косяк MCAS и недостаточная подготовка пилотов. Тогда MCAS перекладывал стабилизатор, когда в этом не было нужды, а будь он зажат более строгим алгоритмом, в другой раз не переложил бы его, когда нужно, с тем же результатом.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Самолет уронили пилоты. MCAS этому только способствовал.
Уронил самолеты MCAS.
Пилоты ниасилили помешать этому.
L>>о том, что в самолете есть какой-то MCAS, им рассказать "забыли".
ЕМ>Верно, это косяк Боинга. А косяк пилотов — в том, что не интересовались устройством самолета за пределами типового обучения.
И как они должны были узнать о вообще наличии этой системы, если она даже в регламенте техобслуживания описании была просто упомянута без деталей?
Напомню — Боинг продвигал Max как "это тот же самый 737NG, только лучше, переподготовки пилотов не надо".
L>>Это и есть "целенаправленно". Оно было реализовано так, чтобы направлять самолет носом в землю, если показания датчиков того велят. В соответствии со спецификациями. ЕМ>Ну, тогда опишите, каким образом MCAS отслеживает тангаж, чтобы "целенаправленно" ориентировать нос в сторону земли. Или используйте более адекватные понятия.
Датчик угла атаки выглядит где-то так.
По сути — пластинка, трепыхающаяся в потоке воздуха, подключенная к некоему энкодеру или вообще банальному потенциометру. Это неважно.
Важно то, что ввиду конструкции вероятность отказа такого датчика крайне высока.
Дятлы, которые оригинальный MCAS писали, родили что-то вроде
WHILE (AoA.read() > threshold) DO
TrimDown(X);
Sleep(Y);
END;
ЕМ>Тогда попробуйте объяснить, для чего в кабине самолета нужны люди, если оборудование ни при каких условиях не может войти в катастрофический сценарий, для защиты от которого может потребоваться человек.
А вот не надо мешать в кучу аварию, например, разрушение двигателя с разлетом шрапнели куда попало и неправильное, но предвиденное поведение автоматики. Первое полностью исключить невозможно. Второе не просто возможно, а необходимо.
L>>Пилот может быть банально перегружен. ЕМ>Может. Но он должен быть способен за вменяемое время распознать ситуации, на которые может повлиять.
Не было там никакого вменяемого времени.
Была невменяемая система. Уже выяснили, что отреагировать на поведение MCAS нужно было в течение первых чуть ли не 90 секунд.
L>>Добавим еще одну нештатную ситуацию на взлете. Птицы. Пожар двигателя. Отказ гидравлики. Кстати, любая из этих ситуаций может вывести из строя еще и датчик угла атаки за компанию, тем самым инициировав работу MCAS в режиме камикадзе. L>>Все, четырех рук банально не хватит, какими бы опытными не были оба пилота.
ЕМ>А на все случаи никогда всего не хватит. В данных случаях сошлись вместе косяк MCAS и недостаточная подготовка пилотов. Тогда MCAS перекладывал стабилизатор, когда в этом не было нужды, а будь он зажат более строгим алгоритмом, в другой раз не переложил бы его, когда нужно, с тем же результатом.
Никто и не говорит о всех возможных случаях.
Основное правило автоматики — она должна снижать загрузку оператора и не подкидывать дополнительных проблем.
Именно следованием этим правилам за 50 лет в гражданской авиации смогли избавиться от тех же бортинженеров в кабине, попутно уменьшив количество ручек, которые можно дернуть невовремя и угробить самолет, при этом повысив безопасность перелетов на порядки.
Оригинальная реализация MCAS нарушает базовые правила автоматики.
Здравствуйте, landerhigh, Вы писали:
L>Уронил самолеты MCAS.
Нет. MCAS только нарушил нормальный полет, и препятствовал его восстановлению силами пилотов, но отнюдь не отобрал у них возможность управления. Пилот являются в кабине главными действующими лицами, они в итоге и уронили.
L>Пилоты ниасилили помешать этому.
Верно, но не потому, что у них не было физической возможности (как если бы, например, полностью разрушились приводы рулей). А потому, что были подготовлены на уровне "нам сказали делать так, вот мы и делали, а другого мы делать не умеем".
L>И как они должны были узнать о вообще наличии этой системы, если она даже в регламенте техобслуживания описании была просто упомянута без деталей?
Хотя бы из этого самого упоминания. Если считаешь себя ответственным за дело, которое делаешь, и от этого зависят твоя и чужие жизни, то матчасть должен знать досконально. А если делаешь, как получится, то и получается, как получилось.
L>Боинг продвигал Max как "это тот же самый 737NG, только лучше, переподготовки пилотов не надо".
Обязательной — не надо. Но для ответственного пилота это не повод игнорировать отличия и нововведения.
ЕМ>>Ну, тогда опишите, каким образом MCAS отслеживает тангаж, чтобы "целенаправленно" ориентировать нос в сторону земли.
L>Датчик угла атаки выглядит где-то так.
Я спрашивал о том, как выглядит датчик направления в землю, или как это направление вычисляется из сигналов других датчиков.
L>Дятлы, которые оригинальный MCAS писали, родили что-то вроде L>
Как, по-Вашему, это должно выглядеть правильно?
L>А вот не надо мешать в кучу аварию, например, разрушение двигателя с разлетом шрапнели куда попало и неправильное, но предвиденное поведение автоматики. Первое полностью исключить невозможно. Второе не просто возможно, а необходимо.
Опишите правильное, на Ваш взгляд, поведение автоматики, и я опишу ситуацию, в которой оно снова окажется неправильным.
L>Не было там никакого вменяемого времени. L>Была невменяемая система. Уже выяснили, что отреагировать на поведение MCAS нужно было в течение первых чуть ли не 90 секунд.
В такой ситуации 90 секунд — это просто-таки до фигища, особенно для пилота, который понимает, что происходит. А чтобы не понять, нужно быть не пилотом, а тем самым оператором, который умеет нажимать кнопки, но лишь отдаленно представляет себе, как управляется самолет.
Привод стабилизатора в 737 — два здоровенных колеса между креслами пилотов, их вращение и видно, и слышно гораздо лучше, чем какая-нибудь мигающая лампочка на панели. На колесах есть ручки аварийного ручного привода, пилотов обучают им пользоваться при отказе электропривода. У любого вменяемого пилота должна автоматически возникать мысль: "если возможна ситуация, когда мне придется крутить эту хрень рукой, то возможно и обратное, когда она будет крутиться сама, а мне нужно будет ее остановить". Если такая мысль возникала, и на ее обдумывание было потрачено хотя бы несколько минут, то 90 секунд с большим избытком достаточно для того, чтобы понять ситуацию и воздействовать на нее. А если она не возникала ни у одного из пилотов, то они и будут тянуть штурвалы до пупа под треск привода перекладки, пока не убьются.
L>Никто и не говорит о всех возможных случаях.
Тогда как заведомо повысить безопасность в случаях, подобных этим двум катастрофам, и при этом не понизить ее в других случаях?
L>Оригинальная реализация MCAS нарушает базовые правила автоматики.
Сомневаюсь, что вообще возможна надежная (на уровне подготовки гражданских пилотов) реализации MCAS для аэродинамически нестабильной конструкции самолета.
Здравствуйте, Евгений Музыченко, Вы писали:
L>>Уронил самолеты MCAS. ЕМ>Нет. MCAS только нарушил нормальный полет, и препятствовал его восстановлению силами пилотов, но отнюдь не отобрал у них возможность управления.
MCAS не имел права нарушать нормальный полет. И по достижении определенной скорости ручное противодействие ему могло стать вообще невозможным. Так что мимо.
ЕМ>Пилот являются в кабине главными действующими лицами, они в итоге и уронили.
В момент, когда какая-то система, которая в документации не описана и отключить которую невозможно, решает, что она тут главная, пилот становится пассажиром.
ЕМ>Верно, но не потому, что у них не было физической возможности (как если бы, например, полностью разрушились приводы рулей). А потому, что были подготовлены на уровне "нам сказали делать так, вот мы и делали, а другого мы делать не умеем".
А как они должны были быть подготовлены к борьбе с системой, о наличии которой им не сказали?
L>>И как они должны были узнать о вообще наличии этой системы, если она даже в регламенте техобслуживания описании была просто упомянута без деталей? ЕМ>Хотя бы из этого самого упоминания.
Регламент техобслуживания вообще не предназначен для пилотов. Пилоты не обязаны его читать, не факт, что имеют к нему доступ и вообще, ты представляешь себе его объем?
ЕМ>Если считаешь себя ответственным за дело, которое делаешь, и от этого зависят твоя и чужие жизни, то матчасть должен знать досконально. А если делаешь, как получится, то и получается, как получилось.
Вот именно, и в Боинге про это забыли.
L>>Боинг продвигал Max как "это тот же самый 737NG, только лучше, переподготовки пилотов не надо". ЕМ>Обязательной — не надо. Но для ответственного пилота это не повод игнорировать отличия и нововведения.
Так и как они должны были узнать о том, что есть MCAS и как он может поломаться, если даже симулятора MAX Боинг не соизволил построить "до"?
ЕМ>>>Ну, тогда опишите, каким образом MCAS отслеживает тангаж, чтобы "целенаправленно" ориентировать нос в сторону земли. L>>Датчик угла атаки выглядит где-то так. ЕМ>Я спрашивал о том, как выглядит датчик направления в землю, или как это направление вычисляется из сигналов других датчиков.
MCAS принимала решение об активации на основе показаний одного лишь датчика угла атаки.
L>>Дятлы, которые оригинальный MCAS писали, родили что-то вроде
ЕМ>Как, по-Вашему, это должно выглядеть правильно?
Как простейший конечный автомат. Сейчас некогда, попозже нарисую диаграмму.
Ключевой момент — MCAS должен был реагировать исключительно на событие перехода через критический угол. Если в момент включения MCAS угол уже превышен, он должен отключиться и зажечь лампочку "MCAS fault".
L>>Не было там никакого вменяемого времени. L>>Была невменяемая система. Уже выяснили, что отреагировать на поведение MCAS нужно было в течение первых чуть ли не 90 секунд.
ЕМ>В такой ситуации 90 секунд — это просто-таки до фигища, особенно для пилота, который понимает, что происходит. А чтобы не понять, нужно быть не пилотом, а тем самым оператором, который умеет нажимать кнопки, но лишь отдаленно представляет себе, как управляется самолет.
Каждый мнит себя стратегом.
Но имеем — минус два самолета.
Так что не дофигища ни разу.
Отказ датчика ведь еще привел к куче ложных сообщений об аварии, на которые пилот тоже обязан среагировать.
Есть даже понятие такое "alarm avalanche".
ЕМ>Привод стабилизатора в 737 — два здоровенных колеса между креслами пилотов, их вращение и видно, и слышно гораздо лучше, чем какая-нибудь мигающая лампочка на панели. На колесах есть ручки аварийного ручного привода, пилотов обучают им пользоваться при отказе электропривода. У любого вменяемого пилота должна автоматически возникать мысль: "если возможна ситуация, когда мне придется крутить эту хрень рукой, то возможно и обратное, когда она будет крутиться сама, а мне нужно будет ее остановить". Если такая мысль возникала, и на ее обдумывание было потрачено хотя бы несколько минут, то 90 секунд с большим избытком достаточно для того, чтобы понять ситуацию и воздействовать на нее. А если она не возникала ни у одного из пилотов, то они и будут тянуть штурвалы до пупа под треск привода перекладки, пока не убьются.
Посмотри видео Дениса Оканя.
Во время взлета это колесо автоматикой крутится туда-сюда постоянно. Пилот просто не обращает на него внимания.
L>>Никто и не говорит о всех возможных случаях.
ЕМ>Тогда как заведомо повысить безопасность в случаях, подобных этим двум катастрофам, и при этом не понизить ее в других случаях? L>>Оригинальная реализация MCAS нарушает базовые правила автоматики. ЕМ>Сомневаюсь, что вообще возможна надежная (на уровне подготовки гражданских пилотов) реализации MCAS для аэродинамически нестабильной конструкции самолета.
Вооот. Что означает, что такой системы быть не должно было в первую очередь и нужно было не мучать дедушку, а строить новый самолет.
Что интересно, вышло бы дешевле.
Здравствуйте, Skorodum, Вы писали:
КД>>>>2. эшелоны многоуровневых тестов вверху. КД>>>>3. круглосуточное тестирование. S>>>В чем разница между 2 и 3?
F>>Наверное, имелось ввиду, что тесты прогоняются не один раз перед релизом, а при каждом коммите. S>Сейчас вроде 2021, а не 2001 и очевидно, что "есть тесты" значит "что есть CI/CD с тестами на каждый коммит" По другому смысла не особо много.
F>>Или даже fuzzy-testing, который действительно имеет смысл гонять круглосуточно. S>Это уже интереснее.
Такое тоже практикуется.
В третьем пункте я имел ввиду то, что тесты работают постоянно.
Тесты выполняются в несколько потоков, за счет этого (плюс OOM на 32-х битах) появляется некоторая рандомизация. Плюс всякие внешние изменения влияют.
Несколько раз, за счет этих тупых бесконечных прогонов, обнаруживались многолетние баги связанные с некорректным кодом. Типа забыл написать return.
----
Еще раз перечитал стартовый топик — вообще я стараюсь писать как можно проще.
Тут в начале нулевых смеялись над кодом вида:
if(a==b)
return true;
return false;
Я так и пишу.
Только перед "return false;" добавляю еще "assert(a!=b)"
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, landerhigh, Вы писали:
L>MCAS не имел права нарушать нормальный полет.
Так он не знал, что полет нормальный, ибо глючил[и] датчик[и].
L>И по достижении определенной скорости ручное противодействие ему могло стать вообще невозможным.
Противодействие ему возможно всегда — путем банального электрического отключения.
L>В момент, когда какая-то система, которая в документации не описана и отключить которую невозможно, решает, что она тут главная, пилот становится пассажиром.
У Вас неверные представления о пилотировании. Пассажиром пилот становится лишь тогда, когда теряет физическую возможность управлять (например, при отказе ЭДСУ и отсутствии механической проводки). Ну, или когда он исчерпал свой уровень понимания матчасти.
Судя по предыстории (авиакомпании Lion Air давно запрещено летать в страны Евросоюза из-за больших претензий к уровню безопасности) и материалам расследования (диалог пилотов ни разу не похож на грамотное взаимодействие в экипаже), они там были пассажирами всегда.
L>А как они должны были быть подготовлены к борьбе с системой, о наличии которой им не сказали?
Обнаружив незапрошенную и неадекватную перекладку стабилизатора, они первым делом должны были ее прекратить, вернув себе управление. Случаи неадекватного ухода стабилизатора бывали и раньше, в большинстве случаев пилоты вовремя это обнаруживали, и принимали меры.
L>Регламент техобслуживания вообще не предназначен для пилотов. Пилоты не обязаны его читать
Так же, как и водитель автомобиля не обязан понимать его устройство. Но хороший водитель таки понимает.
L>не факт, что имеют к нему доступ
Техническая документация не является секретной.
L>ты представляешь себе его объем?
Представляю. Все вычитывать не обязательно, а как работают системы, непосредственно влияющие на управление, понимать следует.
ЕМ>>Если считаешь себя ответственным за дело, которое делаешь, и от этого зависят твоя и чужие жизни, то матчасть должен знать досконально.
L>Вот именно, и в Боинге про это забыли.
А в Боинге, подозреваю, тоже ориентировались на тех самых пилотов-операторов, которым любое новое слово в документации поперек души.
L>Так и как они должны были узнать о том, что есть MCAS и как он может поломаться, если даже симулятора MAX Боинг не соизволил построить "до"?
Им не обязательно было об этом знать. Какая, в конце концов разница, включался привод стабилизатора по командам MCAS, или просто провода коротили, или ключ замыкался от помех? Важно то, что привод включался несанкционированно — именно это пилоты должны были обнаружить и пресечь.
ЕМ>>Я спрашивал о том, как выглядит датчик направления в землю, или как это направление вычисляется из сигналов других датчиков.
L>MCAS принимала решение об активации на основе показаний одного лишь датчика угла атаки.
Еще раз: я спросил о том, каким образом MCAS определяла, где находится земля, чтобы именно в нее (как Вы настойчиво утверждали) направить самолет.
L>Ключевой момент — MCAS должен был реагировать исключительно на событие перехода через критический угол. Если в момент включения MCAS угол уже превышен, он должен отключиться и зажечь лампочку "MCAS fault".
То есть, если вблизи момента перехода через критический угол произошел сбой (глюкнул датчик, где-то пропал контакт, прошла помеха и т.п.), то нехай самолет и дальше уходит в сваливание, а только зажжем лампочку и будем надеяться, что пилоты ее вовремя заметят? Если Вы вдруг не в курсе, из-за несвоевременной реакции пилотов на сваливание было угроблено во много раз больше самолетов и людей, чем в эти два раза.
L>Но имеем — минус два самолета. L>Так что не дофигища ни разу.
Для тех пилотов-операторов, что там сидели — да, не дофигища. Им, подозреваю, и десяти минут не хватило бы.
L>Отказ датчика ведь еще привел к куче ложных сообщений об аварии, на которые пилот тоже обязан среагировать. L>Есть даже понятие такое "alarm avalanche".
Сами по себе alarm'ы нервируют, но внимание пилота должно быть в первую очередь направлено на фактические режимы самолета. Если все орет и мигает, но самолет при этом не трясет и не крутит, а лишь плавно уводит — почти всегда есть время сообразить, что делать сразу, а что можно и потом.
L>Посмотри видео Дениса Оканя.
То, где показано, как останавливать тот привод рукой, если он вдруг сошел с ума?
L>Во время взлета это колесо автоматикой крутится туда-сюда постоянно.
Не постоянно, а сообразно с положением закрылков. MCAS работает только при убранных закрылках. Если закрылки убраны, а стабилизатор вдруг куда-то поехал, то пилот, понимающий свой самолет, должен закономерно удивиться.
L>Пилот просто не обращает на него внимания.
Пилот обращает внимание на все, что происходит с его самолетом. Оператор, как и блондинка за рулем автомобиля — да, может не обращать.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Тут в начале нулевых смеялись над кодом вида:
КД>
КД>if(a==b)
КД> return true;
КД>return false;
КД>
КД>Я так и пишу.
Я тоже с недавних пор стал заменять привычные сокращения вроде if (a) на if (a != 0) (или nullptr), и использовать другие развернутые конструкции, которые умеет схлопывать оптимизатор.
КД>Только перед "return false;" добавляю еще "assert(a!=b)" КД>
А я, без шуток, уже больше двадцати лет обильно уснащаю все assert'ами, в том числе и подобного рода, чтобы в ветке, выполняемой при определенных условиях, контролировать соблюдение этих самых условиях. Уже много раз помогало выявить неочевидные ляпы на ранних стадиях.
Здравствуйте, Евгений Музыченко, Вы писали:
L>>MCAS не имел права нарушать нормальный полет. ЕМ>Так он не знал, что полет нормальный, ибо глючил[и] датчик[и].
Это отмаза уровня "на моем компьютере все работает".
Вероятность отказа подобного датчика крайне высока.
Реализация MCAS должна была предусматривать поведение в режиме его отказа. End of story.
L>>И по достижении определенной скорости ручное противодействие ему могло стать вообще невозможным. ЕМ>Противодействие ему возможно всегда — путем банального электрического отключения.
Опять двадцать пять.
Не было возможности отключить эту систему. Ее вообще с точки зрения пилота не существовало.
Можно было отключить электрический привод стабилизатора, тем самым нейтрализовав ее, но перед этим нужно было вручную предпринять определенные действия по выводу стабилизатора в более-менее нормальное положение. Причем, такая инструкция появилась только после второй катастрофы.
L>>В момент, когда какая-то система, которая в документации не описана и отключить которую невозможно, решает, что она тут главная, пилот становится пассажиром. ЕМ>У Вас неверные представления о пилотировании.
У меня нет никаких представлений о пилотировании.
Я инженер. Система, которую я проектирую, обязана обеспечивать безопасность операторов, пользователей и окружающих ее людей. В том числе в аварийных режимах.
MCAS нарушает все эти принципы.
ЕМ>Пассажиром пилот становится лишь тогда, когда теряет физическую возможность управлять (например, при отказе ЭДСУ и отсутствии механической проводки). Ну, или когда он исчерпал свой уровень понимания матчасти.
Так они в итоге и потеряли эту физическую возможность.
ЕМ>Судя по предыстории (авиакомпании Lion Air давно запрещено летать в страны Евросоюза из-за больших претензий к уровню безопасности) и материалам расследования (диалог пилотов ни разу не похож на грамотное взаимодействие в экипаже), они там были пассажирами всегда.
Не имеет отношения к обсуждаемому вопросу.
Если бы этих аварий не было, рано или поздно MAX спикировал бы в школу в пригороде Амстердама.
L>>А как они должны были быть подготовлены к борьбе с системой, о наличии которой им не сказали? ЕМ>Обнаружив незапрошенную и неадекватную перекладку стабилизатора, они первым делом должны были ее прекратить, вернув себе управление. Случаи неадекватного ухода стабилизатора бывали и раньше, в большинстве случаев пилоты вовремя это обнаруживали, и принимали меры.
Как инженера, меня это не интересует.
Моя задача — минимизировать вероятность некорректной перекладки стабилизатора.
L>>Регламент техобслуживания вообще не предназначен для пилотов. Пилоты не обязаны его читать ЕМ>Так же, как и водитель автомобиля не обязан понимать его устройство. Но хороший водитель таки понимает.
Ну бред же пишешь.
L>>не факт, что имеют к нему доступ ЕМ>Техническая документация не является секретной. L>>ты представляешь себе его объем? ЕМ>Представляю. Все вычитывать не обязательно, а как работают системы, непосредственно влияющие на управление, понимать следует.
В регламенте техобслуживания, где-то на 1345 странице 18 тома она обозначена квадратиком. Удачи в понимании
L>>Вот именно, и в Боинге про это забыли. ЕМ>А в Боинге, подозреваю, тоже ориентировались на тех самых пилотов-операторов, которым любое новое слово в документации поперек души.
В боинге очень хотели бонус.
На пилотов, пассажиров и людей внизу эффективные менеджеры срать хотели.
ЕМ>Им не обязательно было об этом знать. Какая, в конце концов разница, включался привод стабилизатора по командам MCAS, или просто провода коротили, или ключ замыкался от помех? Важно то, что привод включался несанкционированно — именно это пилоты должны были обнаружить и пресечь.
Привод включается автоматикой все время.
Еще раз — посмотри любое видео взлета от Дениса Оканя.
Автоматика крутит его туда-сюда с пердиодичностью раз в несколько секунд. MCAS активируется абсолютно точно так же. Чтобы понять, что аткивация несанкционировна, кто-то должен некоторое довольно продолжительное время пристально наблюдать исключительно за поведением этого привода.
В полете, предшествовавшем первой катастрофе Lion Air, в кабине был третий пилот, которому больше нечего было делать, и который этот полтергейст заметил.
ЕМ>>>Я спрашивал о том, как выглядит датчик направления в землю, или как это направление вычисляется из сигналов других датчиков. L>>MCAS принимала решение об активации на основе показаний одного лишь датчика угла атаки. ЕМ>Еще раз: я спросил о том, каким образом MCAS определяла, где находится земля, чтобы именно в нее (как Вы настойчиво утверждали) направить самолет.
Демагогия.
L>>Ключевой момент — MCAS должен был реагировать исключительно на событие перехода через критический угол. Если в момент включения MCAS угол уже превышен, он должен отключиться и зажечь лампочку "MCAS fault". ЕМ>То есть, если вблизи момента перехода через критический угол произошел сбой (глюкнул датчик, где-то пропал контакт, прошла помеха и т.п.), то нехай самолет и дальше уходит в сваливание, а только зажжем лампочку и будем надеяться, что пилоты ее вовремя заметят?
Погоди, ты только что выше написал, что пилот обязан досконально знать и понимать. Сам себе противоречишь.
Это уже вопрос принципиальный, который ставит под сомнение вообще разумность всего проекта MAX.
Напомню — согласно данным самого Боинга, отказ MCAS, когда не происходит ее срабатывания в нужный момент, оценивался как Hazardous. То есть не приводящий непосредственно к аварийной ситуации. И это в принципе понятно.
Еще раз напомню — MCAS был прибит гвоздями к старичку 737 только для того, чтобы удовлетворить требованиям сертифицирующих органов о линейной реакции на команды штурвала.
И да, отказ MCAS в данном случае должен был зажечь лампочку, и пилоты должны были бы действовать в соответствии с инструкцией "действия в случае отказа MCAS".
L>>Но имеем — минус два самолета. L>>Так что не дофигища ни разу. ЕМ>Для тех пилотов-операторов, что там сидели — да, не дофигища. Им, подозреваю, и десяти минут не хватило бы.
У тех пилотов было по 10 тысяч часов налета на других модификациях 737.
L>>Посмотри видео Дениса Оканя. ЕМ>То, где показано, как останавливать тот привод рукой, если он вдруг сошел с ума?
Любое видео взлета.
ЕМ>Не постоянно, а сообразно с положением закрылков. MCAS работает только при убранных закрылках. Если закрылки убраны, а стабилизатор вдруг куда-то поехал, то пилот, понимающий свой самолет, должен закономерно удивиться.
Не только, там есть еще и автоматика от скорости, которая работает все время.
[На самом деле нет — STS работает только когда выпущены закрылки. Но задачу пилота о диагностике полтергейста этот факт никак не облегчает]
L>>Пилот просто не обращает на него внимания.
ЕМ>Пилот обращает внимание на все, что происходит с его самолетом. Оператор, как и блондинка за рулем автомобиля — да, может не обращать.
Еще раз — речь идет ни о том, какой должен быть идеальный крутой пилот. Речь идет о реализации инженерных систем таким образом, чтобы обеспечить safety в случае их отказа.
Здравствуйте, Коваленко Дмитрий, Вы писали:
ЕМ>>больше двадцати лет обильно уснащаю все assert'ами,
КД>Не, ну это вообще начальная стадия "C++-а головного мозга".
При чем здесь C++? Это полезно в любом языке, без исключений.
КД>Там потом const-ы идут.
Константы я оценил еще с паскалевских времен. Но в плане надежности они слабее assert'ов.
Здравствуйте, landerhigh, Вы писали:
L>Реализация MCAS должна была предусматривать поведение в режиме его отказа.
Должна. Но то, что она этого не предусматривала, не снимает ответственности с пилотов.
L>Не было возможности отключить эту систему.
Выборочно и насовсем отключить только MCAS — не было. А способы временного отключения или физического противодействия — были.
L>Ее вообще с точки зрения пилота не существовало.
И что с того? Подробностей прокладки кабелей, устройства переключателей и других подобных мелочей для пилота тоже не существует. Однако, если замкнут или разойдутся провода в кабеле, не сработает или залипнет переключатель, система управления также может начать работать неадекватно. И пилот по поведению самолета должен понять, в каком из каналов управления произошел сбой, и предпринять доступные ему действия по исправлению ситуации.
L>Можно было отключить электрический привод стабилизатора, тем самым нейтрализовав ее, но перед этим нужно было вручную предпринять определенные действия по выводу стабилизатора в более-менее нормальное положение.
А можно было управлять стабилизатором штатной кнопкой триммирования, которая имеет приоритет над MCAS, и быстро вернуть стабилизатор в нормальное положение, после чего отключить привод. У пилота, который понимает, как все это устроено и работает, такое решение возникает автоматически. А пилот, который только зазубрил последовательности действий для типовых ситуаций, может вообще никогда не догадаться об этом.
L>У меня нет никаких представлений о пилотировании.
Тогда Вам не следует рассуждать о действиях и компетенции пилотов, ограничившись сугубо обсуждением матчасти.
L>Я инженер. Система, которую я проектирую, обязана обеспечивать безопасность операторов, пользователей и окружающих ее людей. В том числе в аварийных режимах.
Ваша система способна делать это в любых условиях? Если да, то для чего ей нужен еще и оператор? И Вы согласны в полной мере лично ответить за любые последствия, которые повлечет сбой системы, даже при условии явного непрофессионализма оператора?
ЕМ>>Пассажиром пилот становится лишь тогда, когда теряет физическую возможность управлять (например, при отказе ЭДСУ и отсутствии механической проводки). Ну, или когда он исчерпал свой уровень понимания матчасти.
L>Так они в итоге и потеряли эту физическую возможность.
Да, но по второй причине (из вышепроцитированного), а не по первой.
L>Если бы этих аварий не было, рано или поздно MAX спикировал бы в школу в пригороде Амстердама.
Хороший пилот этого бы не допустил. Или допустил лишь в крайнем случае, когда глюк MCAS добавился бы к и без того сложной обстановке (дождь, туман, сложная схема маневрирования, плохая связь с диспетчером, отказы других приборов и т.п.).
L>Моя задача — минимизировать вероятность некорректной перекладки стабилизатора.
Как Вы сможете сделать это без понижения вероятности его корректной перекладки во всех остальных ситуациях, когда это необходимо?
ЕМ>>Так же, как и водитель автомобиля не обязан понимать его устройство. Но хороший водитель таки понимает.
L>Ну бред же пишешь.
С точки зрения "чистого инженера" это, возможно, и бред. А с точки зрения любого опытного водителя, пилота, капитана судна — обыденность.
L>В боинге очень хотели бонус. L>На пилотов, пассажиров и людей внизу эффективные менеджеры срать хотели.
А пилоты очень хотели тратить время только на обязательные занятия и процедуры, в надежде, что обо всем остальном подумают другие (в том числе и менеджеры Боинга).
L>Автоматика крутит его туда-сюда с пердиодичностью раз в несколько секунд. MCAS активируется абсолютно точно так же. Чтобы понять, что аткивация несанкционировна, кто-то должен некоторое довольно продолжительное время пристально наблюдать исключительно за поведением этого привода.
Автоматика крутит стабилизатор не "туда-сюда", а в соответствии с установленными режимами, положением закрылков, скоростью и т.п. Пилот, знающий свой самолет, постоянно отслеживает адекватность работы всех этих систем. Для пилота-оператора это просто назойливый шум, на который он может не обращать внимания, но это не делает ему чести.
L>В полете, предшествовавшем первой катастрофе Lion Air, в кабине был третий пилот, которому больше нечего было делать, и который этот полтергейст заметил.
А должны были заметить и оба основных.
ЕМ>>Еще раз: я спросил о том, каким образом MCAS определяла, где находится земля, чтобы именно в нее (как Вы настойчиво утверждали) направить самолет.
L>Демагогия.
Используйте адекватные формулировки — не получите демагогии в ответ.
ЕМ>>То есть, если вблизи момента перехода через критический угол произошел сбой (глюкнул датчик, где-то пропал контакт, прошла помеха и т.п.), то нехай самолет и дальше уходит в сваливание, а только зажжем лампочку и будем надеяться, что пилоты ее вовремя заметят?
L>Погоди, ты только что выше написал, что пилот обязан досконально знать и понимать.
Ну да, опытный пилот, скорее всего, заметит ту лампочку вовремя. Но пилот-оператор, которого Вы защищаете, не заметит ее вовсе, и самолет благополучно уйдет в сваливание, а затем в штопор. Процессы будут разными, результат — тем же.
L>И да, отказ MCAS в данном случае должен был зажечь лампочку, и пилоты должны были бы действовать в соответствии с инструкцией "действия в случае отказа MCAS".
А успели бы те пилоты-операторы действовать вовремя и правильно при реальном превышении угла атаки? Когда самолет самопроизвольно увеличивает угол атаки, он быстро теряет скорость, а следовательно — управляемость. На большой высоте, даже свалившись в штопор, он еще может успеть набрать скорость и выйти из него, а на малой высоте на это тупо нет времени.
L>У тех пилотов было по 10 тысяч часов налета на других модификациях 737.
И что с того, если они никогда не вникали в устройство и поведение самолета сверх обязательных инструкций и упражнений, и никогда раньше не сталкивались с непонятным сбоем управления?
L>STS работает только когда выпущены закрылки. Но задачу пилота о диагностике полтергейста этот факт никак не облегчает
Еще как облегчает. Если в Вашем компьютере вдруг завыл вентилятор во время простоя, когда вы не запускали никаких тяжелых процессов, и Вы этого даже не отметили для себя, то Вы не администратор компьютера, а рядовой пользователь. На пилотов же пока возложены именно административные, управляющие функции. Если после уборки закрылков стабилизатор вдруг куда-то поехал — это прямой повод предположить неисправность системы управления им. А откуда эта неисправность взялась — хоть от MCAS, хоть от замыкания проводки — на тот момент дело десятое.
L>речь идет ни о том, какой должен быть идеальный крутой пилот. Речь идет о реализации инженерных систем таким образом, чтобы обеспечить safety в случае их отказа.
У нас речь и о том, и о другом. Я сразу же подчеркнул, что согласен с претензиями к реализация MCAS и документации по ней. Но Вы стали утверждать, будто "MCAS уронил самолет", а пилоты якобы ничего не могли сделать. Вот я и объясняю, что могли, но вели себя непрофессионально.
Здравствуйте, Евгений Музыченко, Вы писали:
L>>Реализация MCAS должна была предусматривать поведение в режиме его отказа. ЕМ>Должна. Но то, что она этого не предусматривала, не снимает ответственности с пилотов.
Ответственность за аварию лежит исключительно на Боинге.
Если бы пилоты смогли вывезти, стали бы героями. Но героизм одного — это всегда результат головотяпства других.
ЕМ>И пилот по поведению самолета должен понять, в каком из каналов управления произошел сбой, и предпринять доступные ему действия по исправлению ситуации.
Ага, при этом правой лихо разбираясь с тревогой о превышении воздушной скорости или о скором сваливании и еще 100500 других сигналов, на которые он должен по инструкции отреагировать тоже.
ЕМ>А можно было управлять стабилизатором штатной кнопкой триммирования, которая имеет приоритет над MCAS, и быстро вернуть стабилизатор в нормальное положение, после чего отключить привод.
Пилоты именно это и делали.
Только загвоздка в том, что бюллетень о том, что нужно:
1. Не верить автоматике
2. Перевести в нормальное положение
3. И только потом отключать
Боинг выпустил уже тогда, когда было несколько поздно.
L>>У меня нет никаких представлений о пилотировании. ЕМ>Тогда Вам не следует рассуждать о действиях и компетенции пилотов, ограничившись сугубо обсуждением матчасти.
Так я о них и не рассуждаю. Я делюсь опытом о принципах разработки сложных систем, обеспечивающих безопасность операторов, пользователей и окружающей публики.
L>>Я инженер. Система, которую я проектирую, обязана обеспечивать безопасность операторов, пользователей и окружающих ее людей. В том числе в аварийных режимах. ЕМ>Ваша система способна делать это в любых условиях? Если да, то для чего ей нужен еще и оператор? И Вы согласны в полной мере лично ответить за любые последствия, которые повлечет сбой системы, даже при условии явного непрофессионализма оператора?
Предлагаю в первую очередь задать этот вопрос Боингу. А тут воздержаться от перехода на личности.
L>>Если бы этих аварий не было, рано или поздно MAX спикировал бы в школу в пригороде Амстердама. ЕМ>Хороший пилот этого бы не допустил. Или допустил лишь в крайнем случае, когда глюк MCAS добавился бы к и без того сложной обстановке (дождь, туман, сложная схема маневрирования, плохая связь с диспетчером, отказы других приборов и т.п.).
Я об этом написал пять постов назад.
Вероятность отказа датчика AOA крайне высока. Емнип, фактическая статистика отказов — значительно больше одного на тысячу полетов. Соответственно, отказ MCAS при наличии других проблем (выделенное выше) — лишь вопрос времени, и он намного выше "приемлемой" 10^-9 вероятности. И тут уже неважно, насколько пилот "хороший".
L>>Моя задача — минимизировать вероятность некорректной перекладки стабилизатора. ЕМ>Как Вы сможете сделать это без понижения вероятности его корректной перекладки во всех остальных ситуациях, когда это необходимо?
Такого требования нет. Любая система может выйти из строя.
Есть требование fail-safe.
Отсутствие срабатывания тогда, когда оно надо, имеет меньший риск и не приводит само по себе к аварийной ситуации — объяснение ниже.
ЕМ>>>Так же, как и водитель автомобиля не обязан понимать его устройство. Но хороший водитель таки понимает. L>>Ну бред же пишешь. ЕМ>С точки зрения "чистого инженера" это, возможно, и бред. А с точки зрения любого опытного водителя, пилота, капитана судна — обыденность.
Капитан судна умеет диагностировать поломку судового дизеля по звуку?
ЕМ>Автоматика крутит стабилизатор не "туда-сюда", а в соответствии с установленными режимами, положением закрылков, скоростью и т.п. Пилот, знающий свой самолет, постоянно отслеживает адекватность работы всех этих систем. Для пилота-оператора это просто назойливый шум, на который он может не обращать внимания, но это не делает ему чести. L>>В полете, предшествовавшем первой катастрофе Lion Air, в кабине был третий пилот, которому больше нечего было делать, и который этот полтергейст заметил. ЕМ>А должны были заметить и оба основных.
Но не заметили. Как минимум дважды. Твой аргумент не выдерживает проверку практикой.
ЕМ>>>Еще раз: я спросил о том, каким образом MCAS определяла, где находится земля, чтобы именно в нее (как Вы настойчиво утверждали) направить самолет. L>>Демагогия. ЕМ>Используйте адекватные формулировки — не получите демагогии в ответ.
Это адекватная формулировка. Отверстие — это когда берут правильный инструмент, сверло нужного диаметра, предназначенное для данного материала в нужном месте его просверливают. Все остальное — это дырки.
Система сошла с ума и направляла самолет носом в землю. Это не "перерегуляция", это факап. Рафинированый.
ЕМ>>>То есть, если вблизи момента перехода через критический угол произошел сбой (глюкнул датчик, где-то пропал контакт, прошла помеха и т.п.), то нехай самолет и дальше уходит в сваливание, а только зажжем лампочку и будем надеяться, что пилоты ее вовремя заметят? L>>Погоди, ты только что выше написал, что пилот обязан досконально знать и понимать. ЕМ>Ну да, опытный пилот, скорее всего, заметит ту лампочку вовремя. Но пилот-оператор, которого Вы защищаете, не заметит ее вовсе, и самолет благополучно уйдет в сваливание, а затем в штопор. Процессы будут разными, результат — тем же.
Начнем с того, что в нормальном полете подобные углы атаки достигнуты не будут.
Продолжим тем, что для "оператора" действия самолета в ответ на его команды очевидны.
И подытожим тем, что в отличие от А, в Боинге нет защиты от пилота — идиота, и если он очень хочет, то никакой MCAS ему не помешает тянуть на себя до упора. Но при этом ни авиагоризонт, ни тревога по воздушной скорости, да и аэродинамические эффекты никуда не денутся и будут орать ему в ухо "что ж ты делаешь, дебил".
Сравни теперь с отказом MCAS "я вижу, вы тут заняты. Я вам тут тихонечко стаб подкрутил.. и еще подкрутил... и еще подкрутил.. и опять подкрутил".
L>>И да, отказ MCAS в данном случае должен был зажечь лампочку, и пилоты должны были бы действовать в соответствии с инструкцией "действия в случае отказа MCAS". ЕМ>А успели бы те пилоты-операторы действовать вовремя и правильно при реальном превышении угла атаки? Когда самолет самопроизвольно увеличивает угол атаки,
MCAS не предназначен для защиты от "самопроизвольного увеличения угла атаки".
Он предназначен для компенсации аэродинамики планера, нарушенной установкой новых двигателей. Он никак в принципе не может помешать пилоту тянуть на себя до упора.
L>>У тех пилотов было по 10 тысяч часов налета на других модификациях 737. ЕМ>И что с того, если они никогда не вникали в устройство и поведение самолета сверх обязательных инструкций и упражнений, и никогда раньше не сталкивались с непонятным сбоем управления?
Для справки — вся "переподготовка" пилотов некоторых американских компаний а полетам на MAX заключалась в просмотре паверпоинта на планшете по дороге в аэропорт.
Ничего другого не предполагалось.
И никакой информации о работе MCAS, предназначенной для пилотов, до аварий вообще доступно не было.
L>>STS работает только когда выпущены закрылки. Но задачу пилота о диагностике полтергейста этот факт никак не облегчает ЕМ>Еще как облегчает. Если в Вашем компьютере вдруг завыл вентилятор во время простоя, когда вы не запускали никаких тяжелых процессов, и Вы этого даже не отметили для себя, то Вы не администратор компьютера, а рядовой пользователь.
Скорее так: тебе пишет пользователь "в твоей библиотеке ошибка", ты можешь вот сразу выслать патч, да?
L>>речь идет ни о том, какой должен быть идеальный крутой пилот. Речь идет о реализации инженерных систем таким образом, чтобы обеспечить safety в случае их отказа. ЕМ>У нас речь и о том, и о другом. Я сразу же подчеркнул, что согласен с претензиями к реализация MCAS и документации по ней. Но Вы стали утверждать, будто "MCAS уронил самолет",
Уронил самолет MCAS ввиду кривой реализации. Факап Боинга.
ЕМ>а пилоты якобы ничего не могли сделать. Вот я и объясняю, что могли, но вели себя непрофессионально.
Ввиду того, что Боинг не объяснил им, как диагностировать отказ MCAS. Факап Боинга.
И вообще — спор ни о чем. Полеты MAX были запрещены из-за означенных факапов.
Здравствуйте, landerhigh, Вы писали:
L>Если бы пилоты смогли вывезти, стали бы героями.
Подобные происшествия случаются регулярно, в большинстве случаев пилоты справляются, и никто не делает из этого героизма. Еще раз предлагаю представить, что привод стабилизатора включала не MCAS, а неисправная проводка или контакты переключателя. В этом случае глюк не зависел бы от положения закрылков, не было бы пятисекундной задержки от последней ручной операции — то есть, ситуация была бы еще сложнее. А информации у пилотов было бы ровно столько же, что и в первом случае.
L>Только загвоздка в том, что бюллетень о том, что нужно:
Вот в том и разница, что пилот-оператор (aka обезьяна) действует строго по бюллетеню, а грамотный пилот, понимающий свой самолет — по обстановке. У него требования документации запомнены не в виде тупой последовательности действий, а в виде путей решения проблемы и граничных условий, в которых они применимы.
L>>>Я инженер. Система, которую я проектирую, обязана обеспечивать безопасность операторов, пользователей и окружающих ее людей. В том числе в аварийных режимах.
ЕМ>>Ваша система способна делать это в любых условиях?
L>Предлагаю в первую очередь задать этот вопрос Боингу. А тут воздержаться от перехода на личности.
На личности первым перешли Вы, заявив, что Ваша собственная система "обязана обеспечить". Вот мне и стало интересно — обеспечит она по факту, или только "обязана", и кто во втором случае за это ответит — лично Вы или Ваши менеджеры.
L>Отсутствие срабатывания тогда, когда оно надо, имеет меньший риск и не приводит само по себе к аварийной ситуации
А когда срабатывание требуется как раз для выхода из аварийной ситуации, которая уже наступила?
L>Капитан судна умеет диагностировать поломку судового дизеля по звуку?
Сам факт поломки — безусловно (если, конечно, он слышит звук двигателя — на крупных судах, наверху часто не слышен). А суть поломки (треснул вал, оборвался шатун или еще что) ему диагностировать не особо нужно — важно лишь понимать, осталось судно вообще без хода, или хоть какой-то ход имеется, каковы возможности управления и т.п.
ЕМ>>А должны были заметить и оба основных.
L>Но не заметили. Как минимум дважды. Твой аргумент не выдерживает проверку практикой.
Эта практика лишь показывает уровень подготовки пилотов. Собственно, у индусов, арабов и им подобных, подготовка традиционно формальная. Они нормально летают до тех пор, пока все идет в пределах нормы, или отклоняется совсем немного. Шаг влево, шаг вправо — серьезный инцидент или катастрофа.
L>Система сошла с ума и направляла самолет носом в землю.
Нет, это просто Вам (и многим другим) очень нравятся подобные формулировки — за то, что они яркие, эмоциональные и образные. Но действительности они не соответствуют.
L>в нормальном полете подобные углы атаки достигнуты не будут.
Так MCAS и не должна работать в нормальном полете. По замыслу, она должна работать только при выходе из нормальных условий.
L>для "оператора" действия самолета в ответ на его команды очевидны.
Примерно так же, как для блондинки "очевидно" поведения автомобиля: нажала на газ — ускорился, нажала на тормоз — замедлился. То, что на скользкой дороге автомобиль вдруг отказывается замедляться, становится для нее сюрпризом.
L>в отличие от А, в Боинге нет защиты от пилота — идиота, и если он очень хочет, то никакой MCAS ему не помешает тянуть на себя до упора.
Защиты от пилота-идиота нет ни в одном самолете, ибо идиотов пока еще не допускают к пилотированию. А пока пилот остается главным действующим лицом в самолете, автоматика будет ему содействовать или противодействовать, но исключительно с совещательным голосом. А если вроде бы адекватный пилот вдруг превратился в идиота, он угробит любой самолет, самый дуракоустойчивый.
L>Сравни теперь с отказом MCAS "я вижу, вы тут заняты. Я вам тут тихонечко стаб подкрутил..
Мы уже выяснили, что крутит он ни разу не тихонечко. Нужно быть глухим или очень загруженным, чтобы не услышать. В тех случаях пилоты не были очень загружены, когда MCAS только начинала работу. А потом, когда стабилизатор уехал далеко, уже не было разницы, слышно тот привод, или нет.
L>MCAS не предназначен для защиты от "самопроизвольного увеличения угла атаки". L>Он предназначен для компенсации аэродинамики планера, нарушенной установкой новых двигателей.
Это и есть "самопроизвольное", без прямого запроса от [авто]пилота.
L>Он никак в принципе не может помешать пилоту тянуть на себя до упора.
А вот тянуть на себя — это как раз произвольное действие по управлению.
L>Для справки — вся "переподготовка" пилотов некоторых американских компаний а полетам на MAX заключалась в просмотре паверпоинта на планшете по дороге в аэропорт. L>Ничего другого не предполагалось.
Плохо, что руководство не озаботилось. И еще хуже, что большинство пилотов не поинтересовалось даже аэродинамикой самолета с новыми двигателями. То есть, они воспринимали двигатель, как некий волшебный артефакт, который как-то двигает самолет вперед, а как именно — не их забота. В точности, как та блондинка.
L>тебе пишет пользователь "в твоей библиотеке ошибка", ты можешь вот сразу выслать патч, да?
Сравнение было бы корректным, если бы в тех случаях на панели зажигалось табло с надписью вроде "you have a problem", а от пилотов требовалась бы действия по устранению этой неведомой проблемы. Патч — это аналог исправления работы MCAS, а от пилотов требовалось лишь удержать стабилизатор от перекладывания. Если пользователь напишет, что моя библиотека создает определенный файл в ситуации, когда не должна этого делать, и этот файл мешает ему работать, то наиболее адекватным решением будет предложить удалить его вручную, а с библиотекой разбираться потом.
ЕМ>>а пилоты якобы ничего не могли сделать. Вот я и объясняю, что могли, но вели себя непрофессионально.
L>Ввиду того, что Боинг не объяснил им, как диагностировать отказ MCAS.
Да, пилотам-операторам не объяснили. В рамках должностных инструкций они ничего не нарушили. Как и водитель, который, строго в соответствии с требованиями ПДД, лишь тормозил, пытаясь избежать наезда на пешехода, хотя имел реальную возможность его объехать. Наказания такому водителю не последует, но отношение к нему будет соответствующее.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Подобные происшествия случаются регулярно, в большинстве случаев пилоты справляются, и никто не делает из этого героизма. Еще раз предлагаю представить, что привод стабилизатора включала не MCAS, а неисправная проводка или контакты переключателя.
В этом случае был бы явный runaway стабилизатор. Который уверенно крутится в одну сторону. Диагностируется это намного проще, нежели периодическая активация, которую "оператор" может, а то и обязан правомерно отнести к работе автоматики.
L>>Только загвоздка в том, что бюллетень о том, что нужно: ЕМ>Вот в том и разница, что пилот-оператор (aka обезьяна) действует строго по бюллетеню, а грамотный пилот, понимающий свой самолет — по обстановке. У него требования документации запомнены не в виде тупой последовательности действий, а в виде путей решения проблемы и граничных условий, в которых они применимы.
Пилоты EA401 тоже действовали по обстановке. И утопили свой абсолютно исправный самолет в болоте.
А должны были действовать по бюллетеню.
L>>>>Я инженер. Система, которую я проектирую, обязана обеспечивать безопасность операторов, пользователей и окружающих ее людей. В том числе в аварийных режимах. ЕМ>>>Ваша система способна делать это в любых условиях? L>>Предлагаю в первую очередь задать этот вопрос Боингу. А тут воздержаться от перехода на личности. ЕМ>На личности первым перешли Вы, заявив, что Ваша собственная система "обязана обеспечить". Вот мне и стало интересно — обеспечит она по факту, или только "обязана", и кто во втором случае за это ответит — лично Вы или Ваши менеджеры.
Могу ответить на конкретные вопросы по практике FMEA. С собственным примерами.
Только без перехода на личности.
L>>Отсутствие срабатывания тогда, когда оно надо, имеет меньший риск и не приводит само по себе к аварийной ситуации ЕМ>А когда срабатывание требуется как раз для выхода из аварийной ситуации, которая уже наступила?
Нет. Она для этого не предназначена.
L>>Капитан судна умеет диагностировать поломку судового дизеля по звуку? ЕМ>Сам факт поломки — безусловно (если, конечно, он слышит звук двигателя — на крупных судах, наверху часто не слышен).
Ну то есть не может.
L>>Но не заметили. Как минимум дважды. Твой аргумент не выдерживает проверку практикой. ЕМ>Эта практика лишь показывает уровень подготовки пилотов. Собственно, у индусов, арабов и им подобных, подготовка традиционно формальная. Они нормально летают до тех пор, пока все идет в пределах нормы, или отклоняется совсем немного. Шаг влево, шаг вправо — серьезный инцидент или катастрофа.
Напомню AF447. Там тоже "арабы" виноваты?
L>>Система сошла с ума и направляла самолет носом в землю. ЕМ>Нет, это просто Вам (и многим другим) очень нравятся подобные формулировки — за то, что они яркие, эмоциональные и образные. Но действительности они не соответствуют.
Это только какой-то альтернативной действительности они не соответствуют. В реальности имеем воронку в земле и обломки в воде.
L>>в нормальном полете подобные углы атаки достигнуты не будут. ЕМ>Так MCAS и не должна работать в нормальном полете. По замыслу, она должна работать только при выходе из нормальных условий.
Ах, по замыслу. Ну тогда бониг неуионатый совсем, да
L>>для "оператора" действия самолета в ответ на его команды очевидны. ЕМ>Примерно так же, как для блондинки "очевидно" поведения автомобиля: нажала на газ — ускорился, нажала на тормоз — замедлился. То, что на скользкой дороге автомобиль вдруг отказывается замедляться, становится для нее сюрпризом.
Аналогия не к месту.
L>>в отличие от А, в Боинге нет защиты от пилота — идиота, и если он очень хочет, то никакой MCAS ему не помешает тянуть на себя до упора. ЕМ>Защиты от пилота-идиота нет ни в одном самолете, ибо идиотов пока еще не допускают к пилотированию. А пока пилот остается главным действующим лицом в самолете, автоматика будет ему содействовать или противодействовать, но исключительно с совещательным голосом. А если вроде бы адекватный пилот вдруг превратился в идиота, он угробит любой самолет, самый дуракоустойчивый.
Еще раз — самолет угробило неправильное срабатывание MCAS. Который написали обезъяны под руководством ослов.
То, что пилоты ниасилили ему противодействовать, лишь повод задать вопрос Боингу.
L>>Сравни теперь с отказом MCAS "я вижу, вы тут заняты. Я вам тут тихонечко стаб подкрутил.. ЕМ>Мы уже выяснили, что крутит он ни разу не тихонечко. Нужно быть глухим или очень загруженным, чтобы не услышать. В тех случаях пилоты не были очень загружены,
Да, не очень. Всего лишь штурвал трясет вибратором и в ухо орет то ли oversepeed, то ли stall warning. А так — обычный день, ничего особенного.
L>>MCAS не предназначен для защиты от "самопроизвольного увеличения угла атаки". L>>Он предназначен для компенсации аэродинамики планера, нарушенной установкой новых двигателей. ЕМ>Это и есть "самопроизвольное", без прямого запроса от [авто]пилота.
И как угол атаки может измениться без прямого запроса от пилота?
L>>Он никак в принципе не может помешать пилоту тянуть на себя до упора. ЕМ>А вот тянуть на себя — это как раз произвольное действие по управлению.
L>>Для справки — вся "переподготовка" пилотов некоторых американских компаний а полетам на MAX заключалась в просмотре паверпоинта на планшете по дороге в аэропорт. L>>Ничего другого не предполагалось. ЕМ>Плохо, что руководство не озаботилось.
Руководство Боинга.
Еще раз — Боинг продавал MAX как "тот же самый NG, только лучше".
ЕМ>И еще хуже, что большинство пилотов не поинтересовалось даже аэродинамикой самолета с новыми двигателями. То есть, они воспринимали двигатель, как некий волшебный артефакт, который как-то двигает самолет вперед, а как именно — не их забота. В точности, как та блондинка.
И как они должны были поинтересоваться? Построить модель? Арендовать аэродинамическую трубу?
Еще раз — им сам производитель сказал "Все как обычно, садись — лети".
L>>Ввиду того, что Боинг не объяснил им, как диагностировать отказ MCAS.
ЕМ>Да, пилотам-операторам не объяснили.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Несколько раз, за счет этих тупых бесконечных прогонов, обнаруживались многолетние баги связанные с некорректным кодом. Типа забыл написать return.
А можно было просто прочитать предупреждения от любого современного компилятора.
КД>Еще раз перечитал стартовый топик — вообще я стараюсь писать как можно проще. КД>Тут в начале нулевых смеялись над кодом вида: КД>
КД>if(a==b)
КД> return true;
КД>return false;
КД>
КД>Я так и пишу.
Так это не проще, а сложнее для человека, соответсвенно выше вероятность ошибки.
КД>Только перед "return false;" добавляю еще "assert(a!=b)" КД>
Информационный шум.
Здравствуйте, Skorodum, Вы писали:
КД>>Только перед "return false;" добавляю еще "assert(a!=b)" КД>>
S>Информационный шум.
В том случае, если функция гарантированно будет оставаться столь же тривиальной — да. Если же она со временем разрастется за счет дополнительных условий и/или действий, в этом месте уже не будет столь очевидно, что a всегда равно b. В какой-то момент исходное условие может слегка измениться, и может оказаться, что в ту ветку, которая полагается на соблюдение равенства, приходят и некоторых других случаях.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В том случае, если функция гарантированно будет оставаться столь же тривиальной — да. Если же она со временем разрастется за счет дополнительных условий и/или действий, в этом месте уже не будет столь очевидно, что a всегда равно b. В какой-то момент исходное условие может слегка измениться, и может оказаться, что в ту ветку, которая полагается на соблюдение равенства, приходят и некоторых других случаях.
Ты серьезно агитируешь вот за этот код?
Здравствуйте, Nuzhny, Вы писали:
N>По хорошему, так и надо делать хотя бы со своими библиотеками.
А теперь добавь сюда кросскомпиляцию, сложность такого пакетного менеджера и окажется, что вариант такой как сейчас получается проще.
А еще многие большие программы тянут с собой пачки интелловских либ, чтобы не заморачиваться на несовместимость между версииями тех либ.
Хотя как юзеру интеловских либ мне бы тоже хотелось красивого и удобного пакетного менеджера.
Вот сколько у вас сейчас реализаций dgemm,например, под все возможные и невозможные реализации железа и осей.
Здравствуйте, cppguard, Вы писали:
C>Часто можно слышать, что С++ выбирают за быстроту при большом многообразии выразительных средств. И вот читая очередную статью про противоестественную ошибку на пустом месте у меня вдруг возник вопрос: а как вообще в более-менее крупных проектах выполняется контроль сгенерированного кода? Вот допустим описал программист нетривиальный конструктор у класса, который должен по всем правилам избегать двойного копирования (copy elision, move semantics, etc.), но запутался в l-value и r-value ссылках, в итоге код получился неоптимальным. Но если судить по тем статьям, что описывают такие случаи, то проблема обнаруживается или когда бинарный код начинает неимоверно жиреть, или когда производительность заметно падает в узких местах. Получается, что чтобы пользоваться всеми преимуществами С++, нужно или каждый метод при каждом изменении прогонять через godbolt и глазами убеждаться, что компилятор понял идею автора правильно, или обложиться тестами производительности по самое не хочу. Или есть какой-то другой метод? Вариант "мы нанимаем только экспертов С++" я не рассматриваю, потому что вся история ЭВМ построена на уменьшении влияния человеческого фактора на процесс построения корректных и эффективных программ.
Вообще, проблемы решаются по мере возникновения.
А так, тесты, код ревью, различные статические анализаторы кода и программы типа valgrind, и конечно же CI.
Что касается производительности, в CI запускаются также нагрузочные тесты, если производительность просела, то тест зафейлится, потом можно разбираться почему она просела. Особо критичные участки можно и нужно внимательно просматривать, измерять производительность, и смотреть ассемблерный код сгенерированный компилятором. Некритичные участки тестируются только на корректность, но иногда, когда появляется время на рефакторинг можно и их пооптимизировать.
Что касается разбухания бинарника, сейчас на это всем обычно пофиг, но если вдруг он слишком уж разбух, то можно попробовать понять, почему и что-то с этим сделать.
В целом ничего такого уж сложного нет, если постоянно мониторить наиболее критичные параметры. Но конечно ляпы случаются, куда же без них.
C> И вот ещё одно интересное наблюдение: многие именитые фигуры из мира С++ вроде Герба Саттера как таковой рабочий код не пишут, они могут обсуждать новый стандарт, разные скользкие моменты, идиоматичность разных конструкций и вообще что-угодно, кроме написания production-ready кода. А один из самых известных авторов и проповедников С++, Скотт Мейерс, вообще ни разу в жизни не работал программистом, если верить ему самому. Только вдумайтесь — человек, который консультирует в области использования С++, сам никогда не писал на нём!
Вообще, если бы настоящие программисты, которые успели написать миллионы строк говнокода, который как-то работает в продакшене но может посыпаться в любой момент, следовали бы советам Мейерса, мир был бы чуть лучше.
Хоть Мейерс и не работал программистом, в его книгах реомендации дельные и практичные, их можно и нужно применять в том числе и в продакшене.
У Саттера да, по большей части про всякие особо тонкие моменты, которые в реальности редко кому нужны. Но про это тоже иногда полезно почитать и послушпать...
Но у меня много кода, где даже лишние единицы миллисекунд создают проблемы, поэтому он имеет относительно простую структуру. В некритичных местах использую простенькие (по нынешним временам) вложенные шаблонные классы, создающие временные объекты, так вот порожденный ими код анализировать уже весьма неуютно. Представляю, что получается при активном использовании современных библиотечных средств, вместе с исключениями и RTTI. Там уже только тесты.
