The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

SpaceX использует Linux и обычные x86-процессоры в Falcon 9, opennews (??), 03-Июн-20, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


40. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +3 +/
Сообщение от Аноним (-), 03-Июн-20, 23:05 
> Больше изумляет полное отсутствие хоть пары модулей на пихоне. Наверное, нам просто
> забыли об этом рассказать.

Судя по описанию системы им тупо не хотелось отвечать за дохлых космонавтов. Тройное резервирование + МК на последней линии вполне нормальное сочетание, имхо. Я бы ему свою тушку доверил.

А на пихоне трабла в том что статического анализа нет. А узнать о том что у тебя баг в runtime на комическом корабле... "уже не то".

Ответить | Правка | Наверх | Cообщить модератору

83. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +3 +/
Сообщение от anonimous (?), 04-Июн-20, 01:20 
>Тройное резервирование + МК на последней линии вполне нормальное сочетание, имхо. Я бы ему свою тушку доверил.

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

Ответить | Правка | Наверх | Cообщить модератору

104. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +1 +/
Сообщение от Аноним (104), 04-Июн-20, 03:12 
Ну так использование питона только ухудшает ситуацию, поскольку помимо багов в скрипте появляется риск получения багов рантайма, да и к тому же всё равно прийдётся крашить программу и перезапускать её, а на ходу переписывать софт в падающей ракете глупо как то
Ответить | Правка | Наверх | Cообщить модератору

112. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от anonymous (??), 04-Июн-20, 04:14 
>Ну так использование питона только ухудшает ситуацию, поскольку помимо багов в скрипте появляется риск получения багов рантайма

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

Вот только это все мимо, поскольку в реальности никто из них обычно и не виноват. И в случае с ариан-5, и в случае с Б737, и во многих других известных случаях, софт делал именно, то что задумывалось и как задумывалось. А проблема была в самом исходном алгоритме.

Ответить | Правка | Наверх | Cообщить модератору

118. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Карабьян (?), 04-Июн-20, 04:59 
То есть было доказано соответствие софта алгоритму?
Ответить | Правка | Наверх | Cообщить модератору

148. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  –1 +/
Сообщение от Аноним (148), 04-Июн-20, 09:14 
Сначала правильность алгоритма докажите.
А дальше  - пойдут нежданчики со стороны форматов представления данных, их выравнивания, округлений, точностей...
И, даже с доказанным "соответствием алгоритму", вы не застрахованы от "фейерверков"...
Ответить | Правка | Наверх | Cообщить модератору

154. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +1 +/
Сообщение от Карабьян (?), 04-Июн-20, 09:25 
> Сначала правильность алгоритма докажите.
> А дальше  - пойдут нежданчики со стороны форматов представления данных, их
> выравнивания, округлений, точностей...
> И, даже с доказанным "соответствием алгоритму", вы не застрахованы от "фейерверков"...

Как раз ниже был приведен пример с переполнением в Аде

Ответить | Правка | Наверх | Cообщить модератору

321. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Аноним84701 (ok), 04-Июн-20, 18:35 
> Сначала правильность алгоритма докажите.
> А дальше  - пойдут нежданчики со стороны форматов представления данных, их выравнивания, округлений, точностей...

Вообще-то, любой мал-мальско серьезный "formal verification" различает между понятиями "логика" и "реализация". И в нормальное доказательство соотв. конкретной реализации алгоритму, вот это все вышеупомянутое вполне входит.
Классика:
https://web1.cs.columbia.edu/~junfeng/09fa-e6998/papers/sel4...
> Formal Verification of an OS Kernel
> The most detailed layer in our verification is the C implementation. The translation from C into Isabelle is correctness-critical and we take great care to model the semantics of our C subset precisely and foundationally. Precisely means that we treat C semantics, types, and memory model

...
> As kernel programmers do, we make assumptions about the compiler (GCC) that go beyond the standard, and about the architecture used (ARMv6). These are explicit in the model, and we can therefore detect violations. Foundationally means that we do not just axiomatise the behaviour of C on a high level, but we derive it from first principles as far as possible. For example, in our model of C, memory is a primitive function from addresses to bytes without type information or restrictions. On top of that, we specify how types like unsigned int are encoded, how structures are laid out, and how implicit and explicit type casts behave. We managed to lift this low-level memory model to a high-level calculus that allows efficient,

...
> 4.4 Machine model
> Programming in C is not sufficient for implementing a kernel. There are places where the programmer has to go outside the semantics of C to manipulate hardware directly. In the easiest case, this is achieved

Недостаток (помимо требования нехилой такой квалификации):
> seL4, a third-generation microkernel of L4 provenance, comprises 8,700 lines of C code and 600 lines of assembler.

...
> The cost of the proof is higher, in total about 20 py.

.

Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

454. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Аноним (454), 05-Июн-20, 14:00 
Вообще, хорошо разжевано на https://space.stackexchange.com/posts/9446/revisions

И как делают, и кто такой string и judge, и как это работает. И как они тестируют что это работает ("table rocket"). А что, они симулируют различные сбои и смотрят чего их система будет делать. Неплохо придумано.

Ответить | Правка | Наверх | Cообщить модератору

464. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Аноним84701 (ok), 05-Июн-20, 15:00 
> Вообще, хорошо разжевано на https://space.stackexchange.com/posts/9446/revisions
> И как делают, и кто такой string и judge, и как это

Это совершенно другой уровень тестирования, никаким боком к формальной верификации "доказательства правильности алгоритмов" не относящийся.


Ответить | Правка | Наверх | Cообщить модератору

533. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +1 +/
Сообщение от Аноним (-), 06-Июн-20, 22:12 
Однако их тестовый сетап судя по описанию поймал бы факап ариана 5. В проекте ариана проблеяли нечто о том что это "сложно протестировать". А у Маска его "table rocket" должен такое поймать, раз реалистичную симуляцию прогоняют, с параметрами как в полете и случайными отказами.

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

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

Ответить | Правка | Наверх | Cообщить модератору

282. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +1 +/
Сообщение от Аноним (-), 04-Июн-20, 15:10 
> Так ведь рантайм сейчас везде

На сях в микроконтроллере можно и совсем без рантайма. И собственно в last line of defence это не такая уж и глупая идея - когда все остальное вас уже подвело, будет очень кстати если хотя-бы это все-таки не лажанется. Поскольку это было последним что отделяет вас от бабаха. Может еще совсем хардварные защиты. Но если на Земле вырубить вон тот агрегат совсем может и нормально, то будучи на полпути к орбите вы можете и не испытать оптимизм от такого парирования проблемы. Врядли вам понравится в мертвом куске металла на полпути к звездам. Поскольку в этом случае вы таки умрете.

Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

135. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +2 +/
Сообщение от ананас (?), 04-Июн-20, 07:53 
С таким же успехом можно говорить и про C/C++, потому что там может случиться UB.
Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

252. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  –1 +/
Сообщение от Аноним (252), 04-Июн-20, 13:59 
Так это просто язык назван, может там использованы с ними либы или фреймворке для безопасной работы с указателями и прочее, пусть работу оно и замедлит, зато надежнее.
Ответить | Правка | Наверх | Cообщить модератору

455. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Аноним (455), 05-Июн-20, 14:15 
> Так это просто язык назван, может там использованы с ними либы или
> фреймворке для безопасной работы с указателями и прочее, пусть работу оно
> и замедлит, зато надежнее.

Когда вы уже чешете на орбиту, runtime error по поводу плохого указателя ничем не лучше плохого указателя.

Ответить | Правка | Наверх | Cообщить модератору

279. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Аноним (279), 04-Июн-20, 15:01 
> потому что там может случиться UB.

Думаете, они не смогли прогнать ubsan? Да, на _вашем_ космическом корабле я бы таки не полетел...

Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

141. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +2 +/
Сообщение от dannix (?), 04-Июн-20, 08:49 
Системы управления, которые участвуют в схеме резервирования, разрабатываются различными группами программистов, которым даже запрещено взаимодействовать друг с другом (во всяком случае так поступают в авиационной отрасли). К тому же эти системы исполняются на различных аппаратных конфигурациях.
Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

150. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +1 +/
Сообщение от Аноним (148), 04-Июн-20, 09:20 
Да, да, да, да.... :)
Это - во всём мире заявляется.. и - везде же - на это и или кладётся, или - выдаётся, что это - именно так сделано.
ОЧЕНЬ редка, где "по книжкам" делается.
Да, и - потом, часто прикладная область настолько специализирована, что решения имеются в единственном подходе или методе и на всех дублирующих блоках "крутятся одни и те же реализации. И это может спасти только от аппаратных сбоев или ошибок на линиях связи.
Ответить | Правка | Наверх | Cообщить модератору

335. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Анан (?), 04-Июн-20, 19:07 
это может спасти и от отдельных программных ошибок, полагая что все эти блоки работают асинхронно и каждый обрабатывает набор входных сигналов разделенных во времени или поступающих от разных физических датчиков. В этом случае есть шанс, что не все блоки разом словят такой набор входов, который приведет к проявлению ошибки в коде
Ответить | Правка | Наверх | Cообщить модератору

493. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от dannix (?), 05-Июн-20, 21:18 
Очевидно, что вы не можете знать, как делается "везде". Дело не "книжках", а в реальных требованиях, которые предъявляются к системам такого рода.
Ответить | Правка | К родителю #150 | Наверх | Cообщить модератору

197. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Совершенно другой аноним (?), 04-Июн-20, 12:12 
> Проблема в том, что три копии программы с багом выдадут три одинаковых результата и все ок.

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

> А от железных отказов это слегка спасает (при условии, что мажоритарная логика сама не сломается).

Мажоритарная логика обычно на порядок проще всей верхней логики. Так-что там, обычно, и ломаться нечему. Например, какой-нибудь 2 из 3.

> Но вот вероятность отказа железа нынче несколько меньше, вероятности ошибок в коде.

Если учесть, что внутри железа уже давно есть разные там микроконтроллеры со своим встроенным ПО, то всё уже выглядит не так однозначно.

Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

233. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +2 +/
Сообщение от Я (??), 04-Июн-20, 13:23 
на космических кораблях отказ железа происходит чаще чем отказ софта..
Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

278. "SpaceX использует Linux и обычные x86-процессоры в Falcon 9"  +/
Сообщение от Аноним (279), 04-Июн-20, 14:59 
> Но вот вероятность отказа железа нынче несколько меньше, вероятности ошибок в коде.

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

> Т.е. тушка все равно доверяется одной точке отказа

Можно и проинвертировать: если есть 3 разные программы, на 3 разных ЯП, логично ожидать минимум в 3 раза больше багов по их площади. И закидоны в интерфейсах, вероятно, квадратично. Так что логика 2-из-3 нервничать будет, видимо, в 9 раз чаще, когда результат счета разойдется. И чем больше тот механизм тыкать палочкой, да еще с разным кодом, тем выше вероятность что все три начнут хотеть разного. И тогда чего?!

А чем больше рантайм и сложность ЯП - тем выше вероятность бага не только в ЯП, но и в окружении вокруг. Для питона вон вообще нет статического анализа - а рантайм еррор в космическом корабле - картинка "Your trial period is over" неплохо отражает общую идею.

> Или даже в логике заложенной в сам алгоритм.

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

Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру