Статистика: очередной КА убит софтом

Tico>> Вообще, по личному опыту, мой глубокое ИМХО что основная проблема индустрии софта - отсутствие нормальной инженерной культуры.

"Если бы строители строили дома так же, как програмисты пишут программы, то первый залетевший дядел разрушил бы цивилизацию"(с)

Ник

Tico> Вообще, по личному опыту, мой глубокое ИМХО что основная проблема индустрии софта - отсутствие нормальной инженерной культуры. А чисто в техническом плане - неумение (пока что) создавать надёжные программные инфраструктуры, точнее отсутствие должного внимания к ним. Но я вижу подвижки в этом деле, и наиболее они очевидны как раз в области космического софта. IMHO.

Ммм, а можно расширить ваше мнение ?

А то я признаться вот вас не понял... видать сказывается отсутствие нормальной инженерной культуры

au>> Лично меня в этом всём достаёт в основном одно: patching culture. Все могут напортачить, но прежде чем железка улетает, все же и подписались под испытаниями, а значит с высокой вероятностью всё было работоспособно, что позже и подтвердилось в эксплуатации. Но потом пошли патчи "because we can".
russo> Ну и что? Первый ФОБОС (и много других АМС) например потеряли из-за неправильных команд с земли, чем это лучше передачи неправильных патчей? Человеческий фактор - он везде, а софт становится все сложнее, и следовательно увеличивается доля аварий из-за него

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

pokos> В данном случае проблема в том, что нет нормального управления проектом. Пишут кто в лес, кто по дрова.

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

Свежий пример того, насколько основанные на алгоритмах программы непригодны для управления в реальном мире:

" Американские боевые роботы TALON SWORDS отправляются домой. Причиной тому стал сбой в программе, который мог привести к непредсказуемым последствиям. Первое поколение таких роботов уже было отозвано из Ирака из-за целой волны случаев, когда машины не подчинялись приказам человека
........
Возожно ли просчитать все шансы сбоев, которые сделают робота неуправляемым? Если мы возьмём то, что у нас уже есть — виртуальная среда и виртуальные жители этой среды — вирусы, — то окажется, что несмотря на старания десятков специалистов коды программ становятся настолько сложными, что дать 100% гарантию от возникновения ошибок просто невозможно. Поймёт ли человечество это вовремя — вот в чём ключевой вопрос. "

Вот такие реалии создания сложных программ для работы в реальном мире. Так что
нужно использовать другой принцип для написания 100% надежных программ. Другого пути просто нет.

Tico>>> Вообще, по личному опыту, мой глубокое ИМХО что основная проблема индустрии софта - отсутствие нормальной инженерной культуры.
Wyvern-2> "Если бы строители строили дома так же, как програмисты пишут программы, то первый залетевший дядел разрушил бы цивилизацию"(с)
Wyvern-2> Ник
Знаешь, я долго думал над этим вопросом. Вот когда рядовой дом будет состоять 30 лимонов кирпичей и будет высотой в 300 этажей, при этом любой этаж можно заменять по жизни строения без переустановки всего другого — вот тогда строительство можно будет сравнивать с программированием.

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

В сад.

V.O.> Наивная точка зрения. Даже если управление проектом будет идеальным, это всего лишь уменьшит число сбоев в работе программы. Но абсолютно надежно работающую на основе алгоритмов программу не создать. Существует верхний предел сложности для безошибочной работы таких программ.
V.O.> Еще нужно заметить - программа, основанная на алгоритмах, и выглядевшая вполне устойчивой, может неожиданно перестать работать после малейшего исправления ее текста. Достаточно одну-единственную точку не туда поставить.

То же самое происходит и в живой природе.

V.O.> Свежий пример того, насколько основанные на алгоритмах программы непригодны для управления в реальном мире:
V.O.> " Американские боевые роботы TALON SWORDS отправляются домой. Причиной тому стал сбой в программе, который мог привести к непредсказуемым последствиям. Первое поколение таких роботов уже было отозвано из Ирака из-за целой волны случаев, когда машины не подчинялись приказам человека

Надо читать оригиналы. В сад.

V.O.> ........
V.O.> Возожно ли просчитать все шансы сбоев, которые сделают робота неуправляемым? Если мы возьмём то, что у нас уже есть — виртуальная среда и виртуальные жители этой среды — вирусы, — то окажется, что несмотря на старания десятков специалистов коды программ становятся настолько сложными, что дать 100% гарантию от возникновения ошибок просто невозможно. Поймёт ли человечество это вовремя — вот в чём ключевой вопрос. "

Как и в живой природе — гарантировать 100% выживаемость никто не может.

V.O.> Вот такие реалии создания сложных программ для работы в реальном мире. Так что
V.O.> нужно использовать другой принцип для написания 100% надежных программ. Другого пути просто нет.

В сад.

au> // Перевод: ...однако бортовой анализатор пыли подох как раз когда КА пролетал через газопылевое облако. Косяк вышел за два часа до пролёта, когда команда гениев, заведующих инструментом, пыталась загрузить патч чтобы улучшить, как обычно увеличить скорость подсчёта частиц до 100 в секунду. Загрузка патча заняла всего несклолько микросекунд, но как обычно этого хватило в это же время поступил превед от системных программистов прошла суперважная команда от КА, и уникальный эксперимент просрали.

au, а кто виноват, что считалка не могла быстрее считать? Тоже программисты?

Mishka> au, а кто виноват, что считалка не могла быстрее считать? Тоже программисты?

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

V.O.>> Наивная точка зрения. Даже если управление проектом будет идеальным, это всего лишь уменьшит число сбоев в работе программы. Но абсолютно надежно работающую на основе алгоритмов программу не создать. Существует верхний предел сложности для безошибочной работы таких программ.
V.O.>> Еще нужно заметить - программа, основанная на алгоритмах, и выглядевшая вполне устойчивой, может неожиданно перестать работать после малейшего исправления ее текста. Достаточно одну-единственную точку не туда поставить.
Mishka> То же самое происходит и в живой природе.

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

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

За флуд ты уже получил.

V.O.> Так что советую, прежде чем делать дилетантские заявления, немного ознакомится с темой, о которой Вы пытаетесь высказатся. А тема эта весьма сложная и уже достаточно развита, так что не стоит делать бессмысленные заявления.

А вот здесь советую самому почитать. И за дальнейший флуд будешь ещё раз наказан.

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

au> Она и не должна быстрее считать. У программистов эта считалка под рукой, и все их творения проверяются на аналоге перед передачей на КА.

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

Проблема состоит в том, что любые обновления и поправки на время полёта оставляют на программёров. Как правильно сказал Тика — больно легко. И в этом примере очевидно, что произошло рассогласование параллельно работающих частей — пришла важная команда в момент апдейта. А предусмотреть вариант, когда можно нахрен всё закрыть, чтобы никакого прерывания — инженеры не захотели — отложили на программёров. Более того, не захотели сделать специальную команду, которая закроет на время, а потом откроет, даже, если софт глюкнет (основная причина инженеров не делать команду, которая закрывает всё и вся), чтобы через 20 секунд всё открылось и стало бы работать.

au> Более того, те считалки по современным меркам архаика в кубе, так напороть в их коде можно только от большой спешки или от некомпетентности. Спешки в этих делах нет, все орбиты известны наперёд, а вот старая гвардия явно уже на отдыхе, и заменили их наверняка те же молодые люди, что попали в новости после всех последних провалов НАСА (сначала КА-инспектор, потом стыковка двух спутников). НАСА само их отпинало за грубое нарушение собственных правил и методик, но это наверное просто неизлечимо.


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

V.O.>> Похоже, Ваше знание о живой природе основывется исключительно на изучении поведении чипсов и гамбергеров.
Mishka> За флуд ты уже получил.
V.O.>> Так что советую, прежде чем делать дилетантские заявления, немного ознакомится с темой, о которой Вы пытаетесь высказатся. А тема эта весьма сложная и уже достаточно развита, так что не стоит делать бессмысленные заявления.
Mishka> А вот здесь советую самому почитать. И за дальнейший флуд будешь ещё раз наказан.

Интересно, отчего дилетанты в области обработки информации столь самоуверенны?
Каждый, кто немного умеет программировать отчего-то уверен, что он уже знает все на свете. Да, невысокий нынче уровень программирования...

V.O.> Интересно, отчего дилетанты в области обработки информации столь самоуверенны?
V.O.> Каждый, кто немного умеет программировать отчего-то уверен, что он уже знает все на свете. Да, невысокий нынче уровень программирования...

Так за флуд ты получил. Как супер дилентанту в области ОИ советую больше читать. Флуд прекратить.

Mishka> Нет, конечно. Проблема в чистой воде в перекладывании всё на программистов в очередной раз.
Mishka> Дело не в считалке. Дело в тех самых железячниках, которые не могут кучу сделать. А огрехи приходится чинить за счёт программистов. Хотя и программисты виноваты — спору нет.

Ты не прав. Только программисты и виноваты по одной простой причине. Железо делалось под спецификацию, и соответствие спецификации проверяется на испытаниях. Ниасилили — переделают, но до тех пор изделие не примут. А программисты лазят в своё хозяйство всю дорогу, вплоть до ковыряния работающего КА. Всё что сломали после запуска — сломали программисты, больше ни у кого такой физической возможности нет.

Mishka> Проблема состоит в том, что любые обновления и поправки на время полёта оставляют на программёров. Как правильно сказал Тика — больно легко. И в этом примере очевидно, что произошло рассогласование параллельно работающих частей — пришла важная команда в момент апдейта. А предусмотреть вариант, когда можно нахрен всё закрыть, чтобы никакого прерывания — инженеры не захотели — отложили на программёров. Более того, не захотели сделать специальную команду, которая закроет на время, а потом откроет, даже, если софт глюкнет (основная причина инженеров не делать команду, которая закрывает всё и вся), чтобы через 20 секунд всё открылось и стало бы работать.

Оставляют. Но либо программеры не способны ответить "учёным" (в кавычках, потому что какой-то сенайл планетолог может погонять проект, в котором лыка не вяжет, тот же бортовой комп) что "делать то-то не рекомендуем, успех операции не гарантирован", и потом с чувством выполненного долга показать пальцем на виновника всех бед. Либо программеры сами виноваты, потому что не отдают себе отчёт в возможных последствиях своих действий. Это скорее свойственно молодёжи.
Так вот, я думаю там всё получилось просто. Комп там на уровне старого контроллера, сильно он давний и радхард и квалифаед — не может там быть другого. Пока туда сливалось сообщение, возникло прерывание, и сообщение ни в каком-то буфере, ни где ещё не осталось. Просто тупо прервалось. Поскольку это не заумная РТОС, а простой контроллер, эти вещи понимаются интуитивно, и в любом нормальном контроллере есть команда запрета прерываний. А немаскируемое аппаратное прерывание (ножка проца) — это для вещей, важнее которых ничего быть не может, в том числе и важнее залива софта. Что может быть важнее чем залив софта в фактически дистанционно управляемый КА — я плохо представляю. К железу претензий не может быть лишь по указанной причине: сделано как заказали. Программеры должны были быть аккуратными, а скорее всего подумали что пронесёт (указано что "время передачи было миллисекунды"), а не пронесло.

Mishka> Я бы на месте программёров послал бы всех в НАСА к инженерам со словами — патч культура кончилась. Никаких программных обновлений. Пусть железячники думают, как они собираются обновлять зонд.

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

Mishka> Старая гвардия косячила не меньше. Только про это не любят говорить. Тогда это называли — опытом.

Всё же народ был аккуратнее и знал свою матчасть лучше, и при этом возможностей что-то исправить было меньше. Пионер-6 (вроде) до сих пор летает — 40 лет в космосе, и что-то там до сих пор работает, отвечает на запросы. Сейчас возможностей куча, а всё равно не сильно помогает.

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

Mishka> Нет, конечно. Проблема в чистой воде в перекладывании всё на программистов в очередной раз.
Нет, проблема в управлении пректом в чистом виде. Либо дыра в спецификациях, либо в тестировании.

Mishka> Я бы на месте программёров послал бы всех в НАСА к инженерам со словами — патч культура кончилась. Никаких программных обновлений. Пусть железячники думают, как они собираются обновлять зонд.
Вот он, матёрый програмистище как запел!
Эх, Мишаня, железячникам обновлять ничего не нужно, у них и на Земле всё прекрасно работало. Они и не обновляют.
Это как раз чудо-программисты не смогли уложиться в срок, поэтому возможности железа не используются на 100%. Поэтому и всякие дурацкие патчи во время полёта ставят. По заветам Билла Хейса прямо-таки.

au> а вот старая гвардия явно уже на отдыхе, и заменили их наверняка те же молодые люди, что попали в новости после всех последних провалов НАСА (сначала КА-инспектор, потом стыковка двух спутников).

А что, разве стыковку они провалили???

au>> а вот старая гвардия явно уже на отдыхе, и заменили их наверняка те же молодые люди, что попали в новости после всех последних провалов НАСА (сначала КА-инспектор, потом стыковка двух спутников).
Fakir> А что, разве стыковку они провалили???

Задачей было автоматическое сближение и стыковка, обмен массой и расстыковка, и так несколько раз. В результате у них получилось что-то типа "на 96% автоматическая" (цифра 90 с чем-то), то есть нифига она не автоматическая. Подробности не помню — махнул рукой на них когда это прочитал.

Wyvern-2>> "Если бы строители строили дома так же, как програмисты пишут программы, то первый залетевший дядел разрушил бы цивилизацию"(с)
Mishka> Знаешь, я долго думал над этим вопросом. Вот когда рядовой дом будет состоять 30 лимонов кирпичей и будет высотой в 300 этажей, при этом любой этаж можно заменять по жизни строения без переустановки всего другого — вот тогда строительство можно будет сравнивать с программированием.
--
..вот хакерам раздолье будет!
"по щучьему веленью, по моему хотенью перевернитесь блоки этажей вверх ногами!"

au> Ты не прав. Только программисты и виноваты по одной простой причине. Железо делалось под спецификацию, и соответствие спецификации проверяется на испытаниях. Ниасилили — переделают, но до тех пор изделие не примут. А программисты лазят в своё хозяйство всю дорогу, вплоть до ковыряния работающего КА. Всё что сломали после запуска — сломали программисты, больше ни у кого такой физической возможности нет.

В данном конкретном случая я полностью не согласен. И софт был по спецификациям. Только вот железо уже не доделать. А софт — можно. Зачем им понадобилось обновлять софт, чтобы 100 раз в секунду успевать подсчитывать? Этого не было в изначальной спецификации. Более того, не было аппаратной поддержки обновления — посмотри, когда появился Dual Bios на мамках. А чего проще казалось бы?


au> Оставляют. Но либо программеры не способны ответить "учёным" (в кавычках, потому что какой-то сенайл планетолог может погонять проект, в котором лыка не вяжет, тот же бортовой комп) что "делать то-то не рекомендуем, успех операции не гарантирован", и потом с чувством выполненного долга показать пальцем на виновника всех бед. Либо программеры сами виноваты, потому что не отдают себе отчёт в возможных последствиях своих действий. Это скорее свойственно молодёжи.

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

au> Так вот, я думаю там всё получилось просто. Комп там на уровне старого контроллера, сильно он давний и радхард и квалифаед — не может там быть другого. Пока туда сливалось сообщение, возникло прерывание, и сообщение ни в каком-то буфере, ни где ещё не осталось. Просто тупо прервалось.

Я тоже так думаю. И думаю, что условно-временного закрытия всех масок у них не было.

au> Поскольку это не заумная РТОС, а простой контроллер, эти вещи понимаются интуитивно, и в любом нормальном контроллере есть команда запрета прерываний.

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

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

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

au> Что может быть важнее чем залив софта в фактически дистанционно управляемый КА — я плохо представляю. К железу претензий не может быть лишь по указанной причине: сделано как заказали. Программеры должны были быть аккуратными, а скорее всего подумали что пронесёт (указано что "время передачи было миллисекунды"), а не пронесло.

Ага, не может. Ещё как может. И есть. Больше, чем куча.

au> Не к инженерам, а к администратору НАСА, с вопросом: а ничего что мы поковыряемся в мозгах нашего флагшипа и супер сайнс вихикла без гарантий успеха? И если вдруг нельзя, то либо сделать аккуратно с гарантией, либо "под вашу ответственность, сэр".

Можно и к ним. Но поддержка протоколов у инженеров всегда страдала. Потому как трудно очень.

au> Всё же народ был аккуратнее и знал свою матчасть лучше, и при этом возможностей что-то исправить было меньше. Пионер-6 (вроде) до сих пор летает — 40 лет в космосе, и что-то там до сих пор работает, отвечает на запросы. Сейчас возможностей куча, а всё равно не сильно помогает.

Я соглашусь, что аккуратней. На счёт больше — тут уже проблемы. А запустить железку с функциональностью того времени и чтобы она 40 лет проработала — сейчас, ИМХО, даже проще.

au> з.ы. Кстати про кучу. У Кассини двухгиговый твердотельный накопитель, насколько я помню, так что с памятью там не жмотились. Если там нет буфера для радиокоманд, значит так заказано — все претензии к заказчику.

Блин, au, тогда все претензии по софту — тоже к заказчику.

pokos> Нет, проблема в управлении пректом в чистом виде. Либо дыра в спецификациях, либо в тестировании.

Оно, конечно, в чистом виде на морде, только никто не знает, как таким проектом управлять. С тем аппаратом много чего неизвестно.

pokos> Вот он, матёрый програмистище как запел!
pokos> Эх, Мишаня, железячникам обновлять ничего не нужно, у них и на Земле всё прекрасно работало. Они и не обновляют.

Да? А какого хера железа не хватило на то, что 100 раз в секунду собирать инфу? Что в софте изменилось до обновления?


pokos> Это как раз чудо-программисты не смогли уложиться в срок, поэтому возможности железа не используются на 100%. Поэтому и всякие дурацкие патчи во время полёта ставят. По заветам Билла Хейса прямо-таки.

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


Я не отрицаю вины программёров. Но я злой на таких железячников. Потому как они, вроде бы всё сделали и всё работало, а вот оказалось, что они сделали — не хватило там, далеко в космосе. И ничего, никто не говорит, что хреновую работу сделали. А ведь, по сути, они сами не смогли предусмотреть того, что понадобилось. И проект они делали не один и не два года. А вот понадобилось изменить — прибежали к программёрам. И много лет на патч не дали — как же, улетит Кассини на хрен за эти два года. Надо завтра, и, чтобы работало. А вот какие там условия никто сказать не может — железячники много чего не предусмотрели, сказать, что команда очень важная может пройти — тоже не сказали.