×Закрыть

Отказ системы, как один из стандартных режимов её работы

Данный топик связан с темой об аварии Боинга при отказе малозначительного, практически ни на что влияющего элемента, — датчика. Но, как показали предыдущие разработки, системы работа которых связана с жизнью и безопасностью людей должны быть отказоустойчивыми, где отказ системы является её документированным и стало быть стандартным режимом работы. Это и каркас жесткости и подушки безопасности в авто, которое позволяет свести к минимуму повреждения пассажиров и водителя при столкновении и возможность посадки самолёта при отказе всех двигателей кроме одного.

В результате получилась ситуация, когда отказ двигателя — стандартный и малозначимый отказ, в то же время отказ датчика — критический, гарантированно приводящий к аварии и требующий неординарных действий экипажа.

Проблема скорее всего в том, что программисты — не инженеры, у них нет инженерного мышления и инженерного подхода к проблеме. Скорее всего проблема в том, что слишком много вайтишников не только в Украине, но и в мире, где люди идут в IT с совсем не связанных специальностей. Для любого инженера создание отказоустойчивой системы подразумевает разработку системы испытаний/тестов и граничных условий в которых система гарантированно будет работать или не ухудшит результат работы, который был бы без неё. Так что разработка отказоустойчивой системы должна начинаться с моделирования отказов и модуля тестирования в условиях отказов.

Это касается не только этого датчика, отказ датчика должен был протестирован на стенде и гарантированно нормальное поведение системы при его неработоспособности, без вмешательства экипажа, разве что с сигнализацией о неисправности экипажу. Это может быть не только датчик, а зависание программы или крах отдельного модуля программы. В embedded системах такая ситуация решалась через watchdoc чип, который просто перегружал всю систему по питания если в течении 5-10 секунд не получал «опроса» от программного модуля. То же самое с глючными socket серверами на Java, где при падении Java-машины, сервис, который только следил работоспособностью основного сервиса, просто запускал Java-сервис снова. Да, было бы правильно просто исправить баг, который вызывал краш JVM, но не всегда это возможно по ресурсам и такое решение позволяло практически не беспокоится об отказах системы, так как отказ системы был довольно редким и не более нескольких десятков секунд.

К чему это все. К тому что при проектировании отказоустойчивых систем сложнее фейсбучика (отказ которого ни на что негативно не повлияет от слова вообще), данные системы должны удовлетворять требованиям:
— сбор видов отказов и создание системы тестирования изделия в условиях этих отказов;
— система должна обеспечивать пассивную безопасность при отказе, где функциональность общей системы должна быть не ниже чем при полном отсутствии вспомогательной, при этом безопасность должна обеспечиваться без вмешательства оператора;
— любая из подсистем должна иметь модуль диагностики, который будет блокировать её работу или пытаться перезапустить при отклонениях от заданных параметров с уведомлением оператору;
— приемлемая работоспособность всей системы должна обеспечиваться при отказе до 70% подсистем.

Кто-нибудь хочет что-то добавить или оспорить?

LinkedIn

Лучшие комментарии пропустить

Вот тебе картинка с базовыми стандартами по каждому из видов транспорта, касательно безопасности софта: www.eletimes.com/...​2018/04/140863_Fig_01.jpg

Сиди, читай — там все расписано и расжевано в легкодоступной форме. Только не нужно этой отсебятины.

Вы делаете далеко идущие выводы на основании весьма зыбкого фундамента.
Я лично не могу согласиться с потоком обвинений в адрес разработчиков из Индии и ПО вообще. В этой трагедии виноват прежде всего — менеджерье. Именно они приказали на старый планер прикрутить новые двигатели, что сделало конструкцию аэродинамически нестабильной. Именно они решили пожалеть денег и сократили инженеров проектантов и потому проект MCAS вышел неадекватным. Именно они, чтобы сохранить деньги и не пересертифицировать самолет скрыли по максимуму что есть MCAS. И так далее. Теперь по поводу ПО. Было сделано именно то, что требовали. Ошибка не в ПО, а в алгоритме и требованиях к продукту. Которые неадекватены и готовы принять на веру данные одного датчика. Но это не вина разработчиков. Они сделали строго то, что требовалось.

Таким образом, заходить надо с другой стороны — надо исправлять мозги менеджерья.
Пора заканчивать эпоху «эффективных», которые сегодня ругят Pepsi а завтра — Apple.
Потому что цена управленческой некомпетентности в условиях технологичекой цивилизации стала слишком высока.

Проблема скорее всего в том, что программисты — не инженеры, у них нет инженерного мышления и инженерного подхода к проблеме.

Проблема скорее в том, что нужно прослушать хотя бы «Основы теории надежности» и «Построение отказоустойчивых систем» в рамках курса универа. Или самому прочитать. Чтобы хотя бы про базовые подходы знать.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

о как
даже Боингу рассказали как говнокод дебажить надо
полна земля талантами))

В общем пускай Боинг нанимает IT-шников с Антонова. Даже Маск украинских IT-шников очень хвалил, так как способны реализовать «магию», которая даже неплохо работает.

На Антонове там или дедушки или ждуны. Но нанимать украинских вполне разумное решение. Вот только стоят они не 9 бачей в час, а 25 минимум. Квалифицированные чаще около 50.
Но за 50 они и в Америке квалифицированных находили, но поувольняли и наняли 9-ти баксоввых.

Квалифицированные чаще около 50.
Но за 50 они и в Америке квалифицированных находили, но поувольняли

квалифицированные в штатах это $80+ за $50 это такие же ж «или дедушки или ждуны» вместо которых в Украине хотели бы б нанять «таких же ж за $1500» правда брутто и рассказать как хорошо платить налоги в Родине и получать всю социальную защищённость

вот открываешь примерно в Украине которых по $1500 вот тебе будут те которых в штатах по $50

вот ты говоришь «сделать скользящее среднее» а чтобы сделать его «по $50» понадобится 3 человека инженер + программист + математик и ещё 4 менеджера над ними вот так оно реально и работает «по $50»

ЗЫ: справедливости ради тех которых «по $100» не чтобы сильно ушли просто они всё то же ж самое но вид сбоку так менеджера якобы нет но на самом деле копроративная бюрократия даже покруче просто вместо 3-х по $50 «планируется» что будет 1 по $100 чистый профитЪ! ))

квалифицированные в штатах это $80+

Да плевать. Боинг нанимал тех, что за 9.

вот ты говоришь «сделать скользящее среднее» а чтобы сделать его «по $50» понадобится 3 человека инженер + программист + математик и ещё 4 менеджера над ними вот так оно реально и работает «по $50»

Что. Среднее — это 6 или 7 класс школы. Скользящее — считается по скользящему окну. Размер окна подбирается эмпирически на базе некоторого количества тестов. Всё.

Проблема скорее всего в том, что программисты — не инженеры, у них нет инженерного мышления и инженерного подхода к проблеме.

Как ты писал, это Boening, а не Facebook. Соответственно, инженеры выдвигают требования и спецификации, в программисты реализовывают. Свободы принятия решения у них нет от слова «совсем».

Для любого инженера создание отказоустойчивой системы подразумевает разработку системы испытаний/тестов и граничных условий в которых система гарантированно будет работать или не ухудшит результат работы, который был бы без неё.

Ты сейчас делаешь из инженеров Beining-а полных придурков. Безусловно такие тесты проводятся. А вот гарантии это уже вопрос тонкий. Только математическое доказательство может служить гарантией. А так сколько не тестируй, а всегда может быть стечение обстоятельств, которое было непредусмотрено. Например, реакция пилота, ложные параметра датчика в результате слолкновения с птицей на взлёте, и т. п. Добавим сюда давление менеджмента по срокам и получим, что если при моделировании ситуации все пилоты справились на стенде, проблема была помечена как «не препятствует вводу в эксплуатацию», а в реале всё оказалось по другому. Всё-таки вроде проблема была известна, потому как были жалобы.

В embedded системах такая ситуация решалась через watchdoc чип, который просто перегружал всю систему по питания если в течении 5-10 секунд не получал «опроса» от программного модуля.

Boening это много кода на Ada + SPARK что даёт возможность ещё и верифицировать код (доказывать некоторые свойства из пред-пост условий, например, что в нём не будет исключений и т. п.). Ну а в целом опять же, почему ты уверен, что всего этого нет? Это обязательные требования в таких системах.

система должна обеспечивать пассивную безопасность при отказе, где функциональность общей системы должна быть не ниже чем при полном отсутствии вспомогательной, при этом безопасность должна обеспечиваться без вмешательства оператора

Думаю, на практике этого не получится достичь. Подобные требования могут очень сильно усложнить систему, что приведёт к увеличению ошибок, увеличению времени на тестирование, усложнение взаимодействия с оператором и т. п. На практике достаточно, чтобы оператор мог справиться с отказом.

любая из подсистем должна иметь модуль диагностики, который будет блокировать её работу или пытаться перезапустить при отклонениях от заданных параметров с уведомлением оператору

А что есть отклонения от заданных параметров? Вот птица попала в датчик, изменила его физическую форму и он начал привирать. Во-первых, перезапускай не перезапускай делу это не поможет никак. Во-вторых, если датчики дублированы, то возникает вопрос какой из датчиков врёт? Не говоря о том, что в целом рассоглалование может быть и в пределах нормы. Плюс усложнение системы (см. выше)

Ну а в целом да, инженеры Boening совершили ошибку. Но не надо делать вид, что мы намного их умнее, потому что скорее все с точностью до наоборот.

Где то читал что по хорошему надо 3 датчика. Выход из строя двух очень моловероятен, и проще валидировать показания. Два выдают одинаковые результаты, значит третий врёт. Все три выдают разные — значит минимум два врут и никаким показателям доверять нельзя.

Где то читал что по хорошему надо 3 датчика.

Датчики — это дополнительные расходы на оборудование, монтаж, проводку (так как разместить их тоже лучше в разных местах). Но добавить модуль который будет на тех же SVM определять выход системы и отключать её — это же могли?

могли сделать все. но надо економить деньги на зарплаты топ — менеджерам.

Да, но при условии, что нет причины, которая может повлиять на все датчики. Например, проблема с обогревом трубок Пито может привести к тому, что все датчики будут врать. Проблемы с питанием могут затронуть все датчики. Так что в каждом случае нужен ещё дополнительный анализ.

Это не говоря о том, что базовая версия имеет два датчика, и переделать её в угоду новым требования ощутимо дорого.

Было бы всё так просто — на всех самолётах стояло бы по три датчика.

три датчика это не новые требования, это рассуждение по поводу надежности системы. а вот требуему надежность (один-два-три датчика) должны определять заказчки.

Может и метеорит в самолет попасть. Но в этом Боинге умудрились с MCAS всё сделать через жопу. Но, вот если бы не через жопу делали, то и самолеты не разбились бы эти.

Это метод голосования — у него один плюс — очень дешево.

С этими датчиками угла атаки. Пассажирский самолет не может очень резко изменить угол атаки, иначе развалится и тут поможет еще один простейший метод валидации показаний, скользящие среднее и дисперсия и их доверительные интервалы (справиться с таким даже 8048 чип).

скользящие среднее и дисперсия и их доверительные интервалы

Ну или так. Хотя я бы настаивал на внедрении SVM — её проще впихнуть менеджменту как систему искусственного интеллекта. Причем с уже обученной SVM на линейном ядре справиться даже 8048 чип.

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

По сути, как сделать еще кривее, я даже представить не могу.

Пассажирский самолет не может очень резко изменить угол атаки

Опасные завихрения воздуха возникают в грозовых облаках — потоки воздуха в них легко могут бросить самолет на закритические углы атаки, которые чреваты большими неприятностями.
(blog.kupibilet.ru/turbulence)

А теперь с цифферками пожалуйста, насколько могут и за какой промежуток времени измениться показания угла атаки для Боинга в грозовых облаках? Неужто показания за 1 ms изменятся на противоположные?

Здесь еще нужно смотреть на такую проблему как неизменность значений, заклинивший датчик может во временном окне отдавать одно и то же значение постоянно. Так что минимальную дисперсию тоже нужно учитывать, если её нет, то что-то случилось.

Это и есть доверительные интервалы. При заклинивании, скользящее среднее и дисперсия сразу за них вывалятся.
Дальше, Боинг не истребитель и изначально не предназначен для навороченных маневров.

Чтобы оценить эти доверительные интервалы достаточно аэродинамической трубы и нескольких испытательных полетов. ну и еще оценить размер скользящего окна.
Более того разные соответсвия показания различный датчиков и оценки их валидности для разных режимов полета. например при повороте показания двух датчиков углов атаки будут различаться, но при каждом режиме они будут удовлетворять определенным условиям.

После оценки валидности работы датчика уже можно фильтровать по тому же Калману (в вычислениях простейшая математика).
Всё это запросто на простейшем вычислители будет выполняться в реалтайме с микроскопической задержкой.

Дополнительно можно добавить в проверку валидности показаний другие датчики и вообще другие параметры полета.

Ну и обязательно сигнализировать пилотам, что такие-то системы глючат и дальше уже пилот по инструкциям и опыту разруливает ситуацию.

После оценки валидности работы датчика уже можно фильтровать по тому же Калману (в вычислениях простейшая математика).

Не, так ты слона не продашь. Менеджеры сейчас любят чтоб в технологиях встречались слова AI и Cloud технологии. Вот тогда они довольны. Фильтр Кальмана будет сложно выдать за ИИ.

Я и не продаю. Это уже другая область с которой я дела стараюсь не иметь.

Но можно фильтр калмана представить в виде нейросетки самообучающейся. Нарисовать картинки в терминах нейросети.

Фильтр Кальмана будет сложно выдать за ИИ.

Работает снимок личной нейросети Калмана!

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

А вот если отказала половина систем самолета, то кроме парашюта уже ничего не поможет.

та хз .... я не специалист в этих делах. просто забил в гугле фразу противополжную утверждению скинул сюда ссылку. на по факту этут систему ведь прилепили именно из за того что поставили слишком большие двигатели и это очень повлияло на динамику изменение угла атаки. разве нет ?

просто забил в гугле фразу противополжную утверждению скинул сюда ссылку

А там чушь в стиле, как корабли бороздят просторы Большого театра.

на по факту этут систему ведь прилепили именно из за того что поставили слишком большие двигатели и это очень повлияло на динамику изменение угла атаки. разве нет ?

Ага, но поставили через такую жопу, что ставить ее просто нельзя было. Безопаснее было это свалить на пилотов.

Уже, по-моему всем понятно, что топ-менеджеры Боинга в погоне за Золотым тельцом забили на все требования безопасности для самолетов и более того — заставили забить на эти требования конструкторов и инженеров. Кто не соглашался, тех уволили и набрали каких-то дворников. Ну не может программист, инженер стоить 9 баксов в час грязными. Сейчас они пытаются соскочить с ответсвенности и свалить всё на конструкторов и инженеров.

А там чушь в стиле, как корабли бороздят просторы Большого театра.

ок. не спорю. а можно расчеты от специалиста в этих вопросах как изменяется угол атаки этого боинга в грозовых облаках. а то как то голословные очень утверждения ....

Вот я и попросил эти циферки. Но если предоставишь Боинг и аэродинамическую трубу и пилотов, то я тебе получу эти циферки.

Но сразу скорость Боинга 700 км в час. Скорость ветра даже в грозовых облаках 200 км в час. Сложи два вектора и посчитай углы. Вот тебе грубая оценка пределов изменения угла атаки. Но не ветер не Боинг не могут за 1 ms изменить скорость с 0 до максимума. Ускорения надо в инете искать, вот тебе оценка снизу. Но это аналитические. К этому еще добавляется нормальные распределения ошибок.

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

Выше обоснование. Основываются на законах физики нашей вселенной.

это не ответ .... нужны циферки ... а то пустые слова...
иногда то что есть, кажется не тем что есть на самом деле

Вообще-то циферки:

Но сразу скорость Боинга 700 км в час. Скорость ветра даже в грозовых облаках 200 км в час. Сложи два вектора
Но не ветер не Боинг не могут за 1 ms изменить скорость с 0 до максимума.

что такое максимум ? это новая физическая величина ?

Ветер на земле не бывает быстрее. Разве что в ураганах 5 категории и торнадо. Ты не на Юпитере.
А скорость Боингов тоже ограничена и сильно.

и почему с 0 ? самолет ведь летит ? т.е. скорость не нулевая ?

Значит ускорение меньше и соответсвенно нижняя граница значений датчика выше. Точнее границы для дисперсии и изменения скользящего среднего

если поставили систему которая борется с резким изменением угла атаки

MCAS борется не с резким изменением, а с углом атаки выше некоего критического (по её представлениям).
Типа
while (attack_angle > acceptable)
enableMCAS()
Ей абсолютно побоку, наколько быстро был набран данный угол.

тем более и тут у нас возникает только задача валидации показаний датчиков и сообщение пилотам. что датчики глучат. А дальше или пилот отключает глючащие датчики или вообще отключает MCAS.

С валидацией не всё так просто. Есть 2 набора датчиков: для КВС и для 2-го пилота. Поскольку их 2, то можно только установить факт вранья 1-го из наборов, но сказать, какой именно врёт — не получится. MCAS работает с учётом набора датчиков КВС. Почему-то именно так. Безальтернативно.
Отключить датчики — такой кнопки нету. Что вполне логично. У тебя на машине нету кнопки «отключить спидометр», правда? :)
MCAS можно отключить, выполнив действия по чеклисту «runaway stabilizer». Это приведёт к отключению электроники, управляющей стабилизатором и переводу его на ручное управление крутилкой, в том числе отключит и MCAS. Хотя в самом чеклисте про MCAS ни слова.

Да не спорю я с тем, что всё просто. Но то, что было сделано, ни в какие ворота. Дурь на дури и дурью погоняла.

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

Но с другой стороны не валидировать показания датчиков — это еще больший бред

Дык для того в кабине и нужен мешок с костями, чтобы эти самые показания валидировать! С точки зрения электроники, оба варианта имеют место быть. Может быть угол атаки 5 градусов? Вполне. А 35? Тоже. А что делать компьютеру в случае, когда 1 датчик показывает 5, а другой 35?
Правильный ответ — отключить автопилот и отдать управление пилоту. Либо заставить пилота выбрать, какому из датчиков отдать предпочтение. Почему был выбран безальтернативный вариант доверять датчику КВС — я ХЗ.

На поворотах углы атаки будут разные. Мешок с костями уже не успевает все датчики провалидировать — тупой слишком.

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

не могут за 1 ms изменить скорость с 0 до максимума.

а есть информация что именно так вели себя датчики ? и что в реальности такого не может быть ? насколько я понимаю слишком большие двигатели существенно изменили аэродинамику самолета который изначально проектировался под совсем другие двигатели ?
на том же хабре писали резкое изменени угла атаки нормальное явление на военных истребителях, и без бк управлять им не возможно . и установка больших двигателей привела к такому поведению и на этом самолет ....

И вот мы внезапно превзошли скорость света и вообще всего Ньютона и Энштейна выкинули.
Посчитай ускорение, умнож на массу и получи значения силы. Такая сила превзойдет силы удерживающие металл или что там в нужной тебе форме.

а почему ? можно циферки ?

m*a = F — это Ньютон.

А ответ на почему. такая вот наша вселенная.

Скорость ветра восходящих потоков даже в грозовых облаках 200 км в час

ru.wikipedia.org/wiki/Сдвиг_ветра

Сложи два вектора и посчитай углы

очень сильный — более 6 м/с на 30 м.
21 тыс км в час. Да прилично, и поэтому мы будем пользоваться только одним датчиком и вне зависимости от желания пилотов отправлять самолет в пике. Расскажи, как текущая MCAS это учитывала?

Я просто увидел неточность. Про MCAS — я вообще против того, что бы сваливать всю вину на нее. По моему мнению, сажать на бутылку нужно авикомпании, которые, во преки рекомендации авиапроизводителя, заставляют пилотов всегда использовать автоматику, не тренируя практику ручного управления самолетов. Сгоревший суперджет, который собрал 41 фраг, еще одно подтверждение в копилку.
Чудесная AFL, например, прямо запрещала выполнять ручной заход на посадку стажерам и вторым пилотам (во время ввода в строй). Только на автоматике. В итоге — получаются вторые пилоты, которые никогда не сажали лайнер с пассажирами на руках.

много кода на Ada

серьезно? жива старушка?

Если заплатишь, то сделаем. Если не заплатишь за такую подсистему, то никто делать ее не будет.

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

— приемлемая работоспособность всей системы должна обеспечиваться при отказе до 70% подсистем.

А почему не 23.78%? Или 95.46%?

Особенно если знать КАК считается средняя наработка на отказ (MTBF). Да, этот термин [«благодаря» житрожопым юристам] значит совсем не то, чего ждёт обычный человек. Это не среднее время до отказа.

Например, у человека в Украине MTBF примерно 130 лет. Как хорошо что в пенсионном фонде пока не в теме, как можно «правильно» считать и соответственно требовать повышения налогов, снижения выплат, и дальнейшего повышения пенсионного возраста.

Особенно если знать КАК считается средняя наработка на отказ (MTBF).

И как же она считается? Результирующая формула там проста и незамысловата.

Например, у человека в Украине MTBF примерно 130 лет.

Пруфы будут? Или как обычно?

Мат.часть будет. А посчитай сам, себе-то поверишь, или как обычно?

Матчасть на уровне обзорной статьи с хабра с уровнем «пять абзацев общего текста» мне не нужна. Я знаю как наработка считается.
Но вернемся к нашим баранам. Чуть выше ты утверждаешь что

Например, у человека в Украине MTBF примерно 130 лет.

Пруфы будут? Откуда эта цифра, как считали? Как производили свертку последовательно-паралельных блоков? Что брали за минимальную еденицу? Клетку, группу клеток, орган....?
Но мне кажется, что ты сольешься. Как обычно.

Матчасть статьи мне не нужна

Логично. Тролю ничего не нужно кроме запаха.

Я знаю

Сильное утверждение

Но мне кажется

Что троля забудут покормить. Бесплатный корм — на политических форумах.

Пение, я прекрасно понимаю, что тебе охота спрыгнуть с темы. Но все же. Будь последователен. Тыжпрограмист. Пруф о том что

Например, у человека в Украине MTBF примерно 130 лет.

будет? Или как обычно, сольешься?

Если начнут подобное считать в пенсионном, то окажется, что мужиков на пенсию нужно в 55 лет отправлять, а женщин в 65 лет.

Не-а, там так не считают. Там дают готовую цифру, и уже под неё подгоняют методику.

детский сад. пацаны хотели сэкономить и вот .... зачем писать простыни ?

Проблема скорее всего в том, что программисты — не инженеры, у них нет инженерного мышления и инженерного подхода к проблеме.

Проблема скорее в том, что нужно прослушать хотя бы «Основы теории надежности» и «Построение отказоустойчивых систем» в рамках курса универа. Или самому прочитать. Чтобы хотя бы про базовые подходы знать.

Не не не.
теперь же модно не учится в универе, а сразу на галеру и «самоучение».
вот что должно случится, чтоб самоучке пришло в голову прочитать про основы надежности?
Вчера чувак разрабатывающий модули для вордпреса на полном серйозе спрашивал «что такое SQL». Почему у меня, а не в гугле — я не в курсе.

А в універі всі вчаться? Чи готові ви будь якому випускнику медичного довірити своє здоровя?

Крім того нема і не може бути універсального набору знань необхідного на всіх проектах. А вчити все підряд — контрпродуктивно. Тому тільки перевірка при прийомі на роботу по скілам які потрібні, і загальне мислення, чи є кандидат в темі загалом і яка здатність до вивчення нового. Якщо всіх заганяти по одній програмі з купою фундаментальщини то програміст готуватиметься як медики в США по 10 років. І для чого? Щоб потім писати круд і формочки на реакті? Ні, так економіка не працює, лише при совку з купою регуляцій таке можливе.

Да не вопрос. В том же вордпресс проекте мне показывали формочку, с которой данные выбирать.
Грузится 6 секунд. «быстрее нельзя, поскольку там 100000 записей©». Inner join на агрегировнную табличку.
Естественно, чуваку, который клепает формочки не надо понимать, как это работает, что такое индексы, почему они перестают работать на производной таблице и курс по базам данным.

Исправлено два слова — выполнение 0.005секунды.

Короче, универ нужен для того, чтоб чувак хотя бы гдето слышал, в чем он неправ и что можно почитать. Чтоб специалист хотя бы допускал мысль, что это МОЖНО исправить(пусть и другим человеком)

Чтоб специалист хотя бы допускал мысль, что это МОЖНО исправить

Like!
Тем не менее, я учился на инженера-электроника и там не было ничего про SQL. Или я прогулял. Но изучал уже сам начиная с курсов EPAM-а.

А при чому тут універ? Мало інформації по базам в інтернеті?

Чтоб специалист хотя бы допускал мысль, что это МОЖНО исправить

Про індекси розказують лише старі діди в університеті, більш ніде цю секретну інформацію не почерпнути, ага. Сакральність зашкалює.

Если человек не догадывается, что ему это надо, он не ищет. В этом основная проблема курсов в интернете. Типа учатся, но по сути сплошные дырки в образовании.

Як можна не догадатися про необхідність індексації при зниженні продуктивності? Я не кажу про конкретні деталі які індекси і як ставити. Це елементарщина, на всіх курсах мають згадувати. Ну і, навіть якщо не знаєш, можна погуглити «оптимізація бази даних», і там вже дізнатися. Ви описуєте не дева а трейні світчера.

Типа учатся, но по сути сплошные дырки в образовании

Це ж можна сказати про більшість випускників українських університетів.

Так же как и не знать что такое SQL
Данный кадр вообщето синьйор. Украинский, кстати.
В университете вы услышите эти слова как минимум при сдаче зачета, в списке вопросов.

Коли у нас в коледжі проходили вебщину, програмування і верстання, я ті основи вже знав. З інтернету, починав вчитися по курсу php Попова. Як бачите все можливо, і не дуже складно. А ваш синьйор може погано почувався, не знаю що з ним.

Зато не знали чегото другого. Универ потому и универ, что дает универсальный набор чего вы должны знать.
А уж как вы в нем училися — другой вопрос, но если закончили, то как минимум про вопросы в каждом зачете хоть раз слышали. Хоть краем уха.

Зато не знали чегото другого

Ви теж не знаєте всього. Ніхто не знає.

Универ потому и универ, что дает универсальный набор чего вы должны знать.

Ні, він дає лише те, що закладено в програмі.

А уж как вы в нем училися — другой вопрос

Аналогічно про самоосвіту

но если закончили, то как минимум про вопросы в каждом зачете хоть раз слышали. Хоть краем уха.

Все вирішує співбесіда. Взяли на роботу — значить і чули і користували. Не взяли — вчите далі. Універ не дає гарантій що випускник знає щось. Він міг списувати і купувати. Потім, те що дає універ є абсолютно недостатнім для праці в такій динамічній і глобальній галузі як IT.

Проблема скорее в том, что нужно прослушать хотя бы «Основы теории надежности» и «Построение отказоустойчивых систем»

Основная проблема отказоустойчивых систем, что если делать все по теории, то перелет на самолете будет стоить как запуск человека в космос. Поэтому иногда программное решение может сэкономить кучу железа и денег. Например создать модуль из нейросети который генерирует показания датчика (генеративно-состязательная сеть) и оттестировать поведение системы при сгенерированной неисправности.

Основная проблема отказоустойчивых систем, что если делать все по теории, то перелет на самолете будет стоить как запуск человека в космос. Поэтому иногда программное решение может сэкономить кучу железа и денег.

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

Например создать модуль из нейросети который генерирует показания датчика (генеративно-состязательная сеть) и оттестировать поведение системы при сгенерированной неисправности.

Тогда рекомендую почитать про методы «fault injection». Их там две большие подгруппы: «physical» и «simulation». То что ты описал, это как раз второе. Возможно, обойдется без изобретения велосипедов.

Тогда рекомендую почитать про методы «fault injection». Их там две большие подгруппы: «physical» и «simulation». То что ты описал, это как раз второе. Возможно, обойдется без изобретения велосипедов.

Я не пытаюсь изобретать велосипед, я пытаюсь понять почему такой дешевый велосипед (пару сотен часов 9-долларовых программистов) не встроили изначально в MCAS. Там совсем тупые среди топ-менеджеров, толерастия с всеобщей деградацией и туда добралась?

Один из вариантов — просто никто из топов не поставил задание сделать совместное испытание системы X с системой Y, или хотя бы сверку параметров.

В результате получается Therac-25, Ariane-5 и Gimli Glider.

Останется самая малость: заставить людей купить туда БИЛЕТЫ по заоблачным ценам.

Перший політ після повернення літаків буде по акційній ціні.

От бач, розумна людина. Це справді спрацює. Але ж не використовують.
Нащо робити надійний літак, коли можна просто поставити перші польоти по акційній ціні. Бонусом можна використати вдосконалену методику тестування.

Проблема скорее всего в том, что программисты — не инженеры

Инженеры не ошибаются? Инженер круче тыжпрограмист`а? Что за клише..

Проблема скорее всего в том, что программисты — не инженеры
Скорее всего проблема в том, что слишком много вайтишников

Так кто виноват, программисты, тем, что не инжинеры или вайтишники тем что.. тем, что?

отказ датчика должен был протестирован на стенде

он был протестирован. неоднократно.

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

Забыл, сколько у вас лет опыта проектирования этих систем? На сколько там больше от вайтишников с боинга?

система должна обеспечивать пассивную безопасность при отказе

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

должна обеспечиваться при отказе до 70%

Особо люблю когда указывают %.. Сразу видно, человек разбирает в теме.. Кстати, почему 70% а не 75% или не 85% или не 30% ?

Да, я тоже немного выпил..

Кто-нибудь хочет что-то добавить или оспорить?

С точки зрения бизнеса выгодно оплачивать за гибель пассажиров по страховой чем создавать излишнюю надежность.

Не думаю що додати один датчик і провірку на відповідність даних це

создавать излишнюю надежность

Скоріше навпаки — ефективні вирішили зекономити по максимуму.

А в боинге только 1 датчик? Или всех, что есть по +1?

Як я зрозумів, славнозвісна MCAS запускається по одному. Тепер там його продублюють.

Тогда скорее добавят 2. Иначе не выйдет мажоритарной системы.

Там 2 одинаковых. Но эта система юзала только один. Более того, есть еще куча датчиков и параметров полета, что позволяют оценить корректность данных с этих датчиков.

Но Боинг решил, что ничего этого не нужно и хватит одного датчика, причем сильно не надежного. Вот обледенение этого датчика очень вероятно, песчинка в него попала и его заклинило. И они решили в Боинге, что в этом случае лучше всего отправлять в пике.

С точки зрения МАРКЕТИНГА нужно как можно раньше вывести модель на рынок. Впрочем, надо учитывать и ложку дёгтя — кроме гибели пассажиров могут последовать тупо возвраты и неустойки по контрактам, а это уже дороже.

Мораль: надо торговать истребителями, на войне потери спишут.

Чем сложнее тем страшнее. Надо выращивать дублируюшие системы. Причем, они сами должны расти постоянно. Такой вот эволюционирующий код, как кожа.

Зачем? Отдел тестирования, тестеры получают премии за найденные отказы и условия этих отказов.

Одна нить не такая прочная, как много нитей. Один прутик не такой прочный как много прутиков.
Один датчик не такой надежный как несколько датчиков установленных в револьверном устройстве. Воркфло такое: проверка датчика, датчик тупит, револьвер срабатывает, новый датчик подставляет а старый выталкивается в корзину тупящих датчиков. Но тут есть проблема — а если револьверное устройство не отзовется? Его тоже надо вытолкнуть. Автоматика нам сообщает и верные и неверные значения. Нужно человеческими глазами видеть, что револьверное устройство проворачивается. И человеческими руками пощупать.
Итог: оно все равно не взлетит. Если взлетит, то всегда есть шанс что взорвется. В воздухе или при посадке. Кому как повезет. Я лучше велосипедом. Или махолетом (мускульная сила в электричество). Индивидуальным средством доставки за работу датчиков которого буду нести ответственность самостоятельно перед собой лично.

Хорошо, случается отказ раз на 30 лет эксплуатации. Ты таки уверен что найдут того тестера, который его предотвратил, и дадут премию? Держи карман шире!

Вот тебе картинка с базовыми стандартами по каждому из видов транспорта, касательно безопасности софта: www.eletimes.com/...​2018/04/140863_Fig_01.jpg

Сиди, читай — там все расписано и расжевано в легкодоступной форме. Только не нужно этой отсебятины.

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

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

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

В смысле? А турбина, инжектор, и автоматика его управления в двигателе стандартной малолитражки — тоже костыли походу?
была проблема впрыска топлива. Сотвориле инжектора. Работало таксебе, к ним приделали насосы высокого давления. оказалося, что надо электроника иначе это не работает уже на механике.
Так везде.
если еще дальше копнуть, изначально в двигатель просто постоянно топливо добавлялося лопатой.

Только отказоустойчивая система, только взаимозаменяемость, только хардкор!

Тут как раз руль один и управление не продублировано.

Самотестирование, самовосстановление.

Вы делаете далеко идущие выводы на основании весьма зыбкого фундамента.
Я лично не могу согласиться с потоком обвинений в адрес разработчиков из Индии и ПО вообще. В этой трагедии виноват прежде всего — менеджерье. Именно они приказали на старый планер прикрутить новые двигатели, что сделало конструкцию аэродинамически нестабильной. Именно они решили пожалеть денег и сократили инженеров проектантов и потому проект MCAS вышел неадекватным. Именно они, чтобы сохранить деньги и не пересертифицировать самолет скрыли по максимуму что есть MCAS. И так далее. Теперь по поводу ПО. Было сделано именно то, что требовали. Ошибка не в ПО, а в алгоритме и требованиях к продукту. Которые неадекватены и готовы принять на веру данные одного датчика. Но это не вина разработчиков. Они сделали строго то, что требовалось.

Таким образом, заходить надо с другой стороны — надо исправлять мозги менеджерья.
Пора заканчивать эпоху «эффективных», которые сегодня ругят Pepsi а завтра — Apple.
Потому что цена управленческой некомпетентности в условиях технологичекой цивилизации стала слишком высока.

Скажу даже более — если бы программисты на аутсорс стороне вот так решили доделать систему, анализирующую информацию с нескольких датчиков, то это было бы нарушением проектных требований и случись что — опять они виноваты.

Я лично не могу согласиться с потоком обвинений в адрес разработчиков из Индии и ПО вообще. В этой трагедии виноват прежде всего — менеджерье.

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

Вы сами правильно все сказали.Инженеров нет,есть много вайтишников.Опыт не ценится даже в Боиге ибо правят миром деньги и менеджеры а отвечать должны инженеры(которых нет)

правят миром деньги и менеджеры а отвечать должны инженеры(которых нет)

Фишка в том что инженер за ошибку отвечает максимум своей работой и репутацией, а основная ответственность, вплоть до криминальной на его менеджере и компании, которые пустили разработку в продакшен. Так что здесь менеджеры сами себя высекли.

Настало то время когда связка «менеджеры+деньги» убивают людей.Технические системы,особенно авиационные, проше не становятся.Возникает реальный вопрос как людям обезопасить себя и свою жизнь от этой связки.Вот тут бы найти ответ

Возникает реальный вопрос как людям обезопасить себя и свою жизнь от этой связки.

Штрафы, клин клином вышибают. Прописать стандартный размер штрафа в случае гибели за счет ошибки проектирования, скажем 10 млн евро за человека. На проверки начнут выделять намного больше денег.

В принципе таким же образом в США почти искоренены врачебные ошибки, так как для клиник — это очень дорого.

Море их там. Врачебных ошибок. А суды выигрывают в тех случаях, когда была вопиющая халатность, как минимум.

Никак. Но можешь молится богу или железному человеку, что именно тебя они и спасут.

Но есть один путь, против которого современные маменькины демократы и такие же либертарианцы — жесткий контроль со стороны гос регуляторов. Но есть такой момент — как коррупция, глупость и лень.

Еще в совке с ТЭЦ в Минске улетала турбина на 4 км при поломке одной лопатки. После начали думать, как сделать контроль состояния лопаток. Отдел, где мой отец начальником один из путей исследовал и даже что-то сделали. Внедрено было или нет, я не знаю. Уверен, что эту задачу решали еще в нескольких НИИ и исследовали другие пути.

Подписаться на комментарии