LINUX.ORG.RU
ФорумTalks

У марсианского зонда случилось переполнение

 ,


1

5

Такая новость сегодня вышла про зонд Schiaparelli: https://www.gazeta.ru/science/2016/11/24_a_10365155.shtml

Вскоре после раскрытия парашюта произошел «глюк» - переполнение отсчетов так называемого Инерциального измерительного устройства (Inertial Measurement Unit — IMU), в состав которого входят гироскопы и который следит за параметрами вращения аппарата в пространстве.

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

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

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

PS: Наверняка код написан на каком то языке не очень высокого уровня, например на Си. Было бы лучше, если бы писали на лиспе, например?

★★★★

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

sholom ()

профессия программиста дискредитирует саму себя, превращаясь из инженерной специальности в профессию для ПТУ?

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

Sadler ★★★ ()

профессия программиста дискредитирует саму себя, превращаясь из инженерной специальности в профессию для ПТУ?

Поразительно странный вывод. А знаешь сколько раз учёные ошибаются при проведении экспериментов? Там 99.999% экспериментов — ошибки. Значит ли это, что профессия учёного себя дискредитировала и учёным достаточно 5 классов средней школы вместо университета?

Было бы лучше, если бы

Писали на том языке, который подходит под то железо. Это раз. А во-вторых такие ошибки — алгоритмические. Т.е. смена языка не изменила бы ничего. Ты думаешь в лиспе -100 с точки зрения арифметики сильно отличается от сишного -100?

Stahl ★★☆ ()

профессия программиста дискредитирует саму себя, превращаясь из инженерной специальности в профессию для ПТУ?

Еще Дейкстра всех предупреждал, что инженерный подход в разработке ПО - это неправильно.

Solace ★★ ()
Ответ на: комментарий от Stahl

От смены языка дефолтные целые могут смениться на непереполняемые.

Miguel ★★★★★ ()

Казалось бы при чем тут язык. Датчик показал чепуху, а тестов не завезли и в коде проверок таких ситуаций не предусмотрели.

vazgen05 ★★ ()
Ответ на: комментарий от Stahl

А знаешь сколько раз учёные ошибаются при проведении экспериментов?

Ученый - это исследователь, ему положено ошибаться. А программист - это инженер. Инженер работает с понятными, исследованными и описанными сущностями. Что бы было, если бы инженеры-строители ошибались так же часто, как ученые? Да даже если так же часто, как программисты.

Программист превращается в быдлокодера из ПТУ, которому на помощь должен придти аналитик (как это когда-то было), который уже будет иметь высшее образование и инженерную культуру.

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

В лиспе по крайней мере нет переполнения.

Puzan ★★★★ ()
Ответ на: комментарий от Solace

Еще Дейкстра всех предупреждал, что инженерный подход в разработке ПО - это неправильно.

Если бы был инженерный подход, то такой ошибки наверняка бы не было.

Puzan ★★★★ ()

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

ilovewindows ★★★★★ ()
Ответ на: комментарий от vazgen05

Казалось бы при чем тут язык. Датчик показал чепуху, а тестов не завезли и в коде проверок таких ситуаций не предусмотрели.

Так переполнение же. В одних языках это возможно, а в других нет.

Puzan ★★★★ ()

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

EXL ★★★★★ ()
Ответ на: комментарий от Miguel

Главное в таких ошибках, что вылезло некорректное число. Если отрицательные значения автоматически обнулять, то проблема не только не будет исправлено, но и станет намного более хитро замаскированной.
Это ошибка логическая. И Си хорош как раз тем, что эти ошибки не скрывает.

Stahl ★★☆ ()
Ответ на: комментарий от Puzan

Чего переполнение, наркоман? Это не целочисленное переполнение, это с датчика пришло значение вне диапазона. На чем угодно переписывай код, но он от этого точнее не станет же.

However, saturation – maximum measurement – of the Inertial Measurement Unit (IMU) had occurred shortly after the parachute deployment. The IMU measures the rotation rates of the vehicle. Its output was generally as predicted except for this event, which persisted for about one second – longer than would be expected.

vazgen05 ★★ ()
Ответ на: комментарий от vazgen05

Ну, строго говоря, в датчике тоже, скорее всего, есть какой-то код. И в нём и была ошибка.

Stahl ★★☆ ()
Ответ на: комментарий от Puzan

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

Почему бы ему тогда и код не писать? Зачем ему макака, за которой еще всё перепроверять?

Loki13 ★★★★★ ()
Ответ на: комментарий от Stahl

Ну, строго говоря, в датчике тоже, скорее всего, есть какой-то код. И в нём и была ошибка.

По описанию выглядит как то, что из датчика, в какую то секунду, пришел Int32, а положили его в Int16, т.к. не ожидали что такое вообще придти может. Вот и получили переполнение.

//типы для примера просто, какие там у них были, хрен его знает.

Loki13 ★★★★★ ()
Ответ на: комментарий от vazgen05

Чего переполнение, наркоман?

А ты дятел. Inertial Measurement Unit имеет на борту управляющий контроллер, который выдает на выход оцифрованные данные с гироскопа.

Puzan ★★★★ ()

Какой язык теперь получил звание "не тормозит"?

alozovskoy ★★★★★ ()
Ответ на: комментарий от Loki13

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

Stahl ★★☆ ()

Такая новость сегодня вышла про зонд Schiaparell

ну...что сказать. Далеко не сегодня.

darkenshvein ★★★★★ ()
Ответ на: комментарий от Puzan

Ну и что ты этим хочешь сказать? А еще ниже этого контроллера находится какая-нибудь сраная 10-разрядная микросхема ацп, которая тупо отдает '1111111111' и знать не знает про ЛИШП и С.

vazgen05 ★★ ()

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

«К нам сегодня забрело
С толстым пузом трололо
Ололо, трололо
Дверь входную разнесло» (ц)

tailgunner ★★★★★ ()

С тем же успехом можно все сбросить на качество QA. Тесты должны покрывать все. В каком то предельном, идеальном случае программа должна автоматически выводиться из тестов каким-нибудь machine learning алгоритмом.

wieker ★★ ()

Не нашёл в тексте по ссылке чьи были быдлокодеры.

trueshell ★★★★★ ()
Ответ на: комментарий от ilovewindows

Это действительно так. Сейчас повсюду пихают всякие умные микросхемы вместо простых аналоговых. Причина — умная электроника легче в разработке. Зато аналоговые схемы почти никогда не отказывают.

Vsevolod-linuxoid ★★★★★ ()
Ответ на: комментарий от vazgen05

которая тупо отдает '1111111111'

Ну так а кто за этим должен следить?

Puzan ★★★★ ()

Было бы лучше, если бы писали на лиспе, например?

Да, но согласились есть дерьмо, как всегда.

Oxdeadbeef ★★★ ()
Ответ на: комментарий от Vsevolod-linuxoid

Зато аналоговые схемы почти никогда не отказывают.

бугагашеньки

registrant ★★★★★ ()
Ответ на: комментарий от Puzan

И как это $LANG_NAME определит, что контроллер выдал неверные данные? И самое главное, что он в этом случае должен делать? Вариант «ничего» не канает, т.к. там realtime и промедление смерти подобно.

WARNING ★★★★ ()

PS: Наверняка код написан на каком то языке не очень высокого уровня, например на Си. Было бы лучше, если бы писали на лиспе, например?

Слишком толсто, не пройдет

kravich ★★★★ ()
Ответ на: комментарий от ilovewindows

Причем здесь вообще программисты

При том, что если ты не учел отрицательную высоту, то ты не программист, а халявщик

record ★★★★★ ()
Последнее исправление: record (всего исправлений: 1)
Ответ на: комментарий от Stahl

Обнуление конечно не помогло бы. Помогла бы установка чего нибудь типа (y>INT_MAX)?x = INT_MAX:x=y; но на уровне языка.

Loki13 ★★★★★ ()
Ответ на: комментарий от trueshell

Не нашёл в тексте по ссылке чьи были быдлокодеры.

Уже все поняли(да никто и не скрывал) что европейцы накосячили, а вы все пытаетесь русских виноватыми найти?

Loki13 ★★★★★ ()
Ответ на: комментарий от kravich

Слишком толсто, не пройдет

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

Puzan ★★★★ ()
Ответ на: комментарий от WARNING

И как это $LANG_NAME определит, что контроллер выдал неверные данные?

Ну наверное прошивка для контроллера тоже написана на $LANG_NAME?

Puzan ★★★★ ()
Ответ на: комментарий от Loki13

Как помогло? Замаскировало бы ошибку? Ну так она вылезла бы где-то ещё.
Ты же когда лезешь в карман за деньгами не проверяешь а не отрицательное ли у тебя количество денег? А если вдруг у тебя в кармане оказалось -100 рублей, то это беда не твоего кармана или рук, а исправлять нужно что-то в самих деньгах.

Stahl ★★☆ ()
Ответ на: комментарий от Stahl

Как помогло? Замаскировало бы ошибку? Ну так она вылезла бы где-то ещё.

Да хрен его знает, изначально был посыл что во все виновато переполнение. Если его устранить, то аппарат скорее всего бы не разбился. А так то понятно что виновато недостаточное тестирование.

Loki13 ★★★★★ ()

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

Deleted ()
Ответ на: комментарий от WARNING

И как это $LANG_NAME определит, что контроллер выдал неверные данные?

А кто сказал что данные неверные? Вроде написано что «данные которых никто не ожидал», то что они при этом являются неверными нигде не написано.

Loki13 ★★★★★ ()
Ответ на: комментарий от Loki13

Виновато не переполнение. Виновата логическая ошибка в коде, которая в данном конкретном случае привела к переполнению. Она могла привести в тому, что все показания были бы на 5 метров больше. Или ещё чего.
Но ты на всякий случай пропатчь себе карман и руки, чтобы они могли корректно работать с банкнотами отрицательного номинала.
А то мало ли что:)

Stahl ★★☆ ()
Ответ на: комментарий от Stahl

И чем помог бы язык, который обнулил бы отрицательное значение?

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

Puzan ★★★★ ()
Ответ на: комментарий от Stahl

Виновата логическая ошибка в коде

Что в ней логического? Ошибка проектирования или математическая ошибка. Если с датчика пришло больше чем ждали, чего тут логического? У меня вот когда синус через 0 переходил в 3д, камера улетала неизвестно куда, это тоже логическая ошибка?

Loki13 ★★★★★ ()
Последнее исправление: Loki13 (всего исправлений: 1)
Ответ на: комментарий от Stahl

И как бы это исправило ошибку?

Так ошибки не было бы, все бы работало штатно.

Puzan ★★★★ ()

в бортовой компьютер была передана неверная информация.

Аппаратное решение: в бортовой компьютер передавать медианное значение 3-х датчиков.

quickquest ★★★★★ ()
Ответ на: комментарий от Stahl

/facepalm

То же могу сказать в ответ. Но не скажу, а попробую объяснить для тугих.

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

Puzan ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.