>Существует ещё мнение, что сама FreeRTOS плохо, почти никак, не подходит для управления космической техникой
А на скольких КА она стояли или стоит?
Не знаю. Но спуском Скипарелли вроде бы FreeRTOS управляла.
СКИАПАРЕЛЛИ
http://www.vzpp-s.ru/production/catalog.pdf
Так что, будем говорить об электронике и софте для космоса?
Так что, будем говорить об электронике и софте для космоса?
Рассказывай, что они делают космического.
Вот, например:
ПЛИС 5578ТС034
ТУ – АЕНВ.431260.216ТУ;
может быть использована для замены следующих аналогов:
EPF10K100E (ф. Altera), RT54SX72S, A54SX72A,
RTSX72SU, AX125, APA075 ф. Microsemi, XC2S100 ф. Xilinx.;
напряжение питания ядра – 1,8 В 5%;
напряжение питания периферии – 3,3 0,3 В;
стойкая к СВВФ;
Количество эквивалентных логических элементов: 4992
Объем встроенной памяти, Кбит: 48
Количество пользовательских выводов: 212
Маловато, но не так уж и мало. Для управления чем-либо вполне сгодится.
Вообще то радостойкой электронике, не нужны высокие герцы и нанометры. Наоборот крупный транзистор лучше.
В космосе же несколько поражающих факторов - против одник лучше крупный транзистор, против других лучше мелкий.
Против поражающего фактора под названием Рогозин ничего не устоит.
Зачем на Веббе будут использовать нонейм реализацию джаваскрипта? Почему не существующую с миллионными сообществами, уже изрядно поевшую говна и вылечившуюся от детских болезней?
>джаваскрипта
Это понятие не совместимо с космосом ни в какой ипостаси. Давайте не будем засорять тему.
Могу попытаться тебе доказать что ты тоже в некотором роде поражающий фактор.
>тоже
На говно похоже.
Ребята и девчвта, если вдруг случайно у кого-то под рукой многолучевой осциллограф, то нет ли у кого возможности показать сигнал на обмотках? Интересно смещение фаз и форма сигнала.
>Существует ещё мнение, что сама FreeRTOS плохо, почти никак, не подходит для управления космической техникой.
Херня. ОСРВ или обеспечивает РВ, или не обеспечивает (и тогда она не РВ), а в каких задачах используется РВ — ей строго поебать. Всё, что делает ОС — гонет биты в регистры, а на что заведены эти регистры, на исполнительные механизмы станка или космического аппарата — она тупо не ебёт.
>Херня. ОСРВ или обеспечивает РВ, или не обеспечивает (и тогда она не РВ),
Реальное время разное бывает - кому-то хватает гарантированного времени отклика, а кому-то нужен изохронный реалтайм.
> Всё, что делает ОС — гонет биты в регистры, а на что заведены эти регистры, на исполнительные механизмы станка или космического аппарата — она тупо не ебёт.
Судя по количеству фейлов АМС в XXI веке, вышеописанный подход весьма популярен в современном мире. Смею предположить что первые аппараты, которые были вообще без ОС, были более надёжны. При чём же здесь FreeRTOS? Сама идеология её построения толкает разработчика к ошибкам, загоняет в рамки, из которых трудно выйти.
>Смею предположить что первые аппараты, которые были вообще без ОС, были более надёжны.
То есть ты сперва изниоткуда предположил, что Скиапарелли разбился из-за FreeRTOS, потом изниоткуда предположил, что применение RTOS является причиной снижения надёжности современных космических аппаратов. Молодец, далеко пойдёшь с таким подходом.
>изниоткуда предположил, что Скиапарелли разбился из-за FreeRTOS
По обрывкам информации и на основе опыта.
> предположил, что применение RTOS является причиной снижения надёжности современных космических аппаратов
Опять же, на основе богатого опыта разработки. И на основе анализа популярных принципов построения систем управления. Не думаю что космический софт разрабатывают суперлюди - разрабатывают (плюс/минус) те же самые, кто выклаюдывает видео самоделок на youtube.
Второй момент - я не говорил вообще за все RTOS, а конкретно за FreeRTOS. Что не отменяет того, факта что кривым рукам не помогут ни QNX/Neutrino, ни VxWorks.
>Судя по количеству фейлов АМС в XXI веке, вышеописанный подход весьма популярен в современном мире.
Можно подумать, bare metal программы (которые без ОС) используют какой-то другой подход. Сохранять биты в регистры — это в принципе все инструменты, которыми любой софт имеет возможность влиять на реальность.
>я не говорил вообще за все RTOS, а конкретно за FreeRTOS
А есть статистика, с какой осью космические аппараты бьются чаще?
>bare metal программы
При этом полностью теряется гибкость, зато появляются проблемы энергопотребления и тепловыделения. Как только ты отказался от ОС, у тебя остаётся суперцикл, который периодически опрашивает датчики и реагирует на них. К тому же разработчикам приходится считать буквально по тактам каждый блок кода и при необходимости вручную выравнивать задержки. Технологии дедов.
Ох уж эти ардуинщики, которые даже не слышали про прерывания.
Допустим, прерываниями ты можешь гарантировать время отклика, да и то не факт. Как прерывания уживается с требованием изохронности всей системы? Твоё прерывание перебъёт более высокоприоретное прерывание - и что ты сделаешь?
Пророк - http://os.itec.kit.edu/downloads/in-memoriam-jochen-liedtke_en.pdf
Апостолы - http://www.l4ka.org/67.php
В принципе, на этом можно тред закрывать - дальше он может вылиться в срач и в травлю.
Апостолы - http://www.l4ka.org/67.php
В принципе, на этом можно тред закрывать - дальше он может вылиться в срач и в травлю.
>Допустим, прерываниями ты можешь гарантировать время отклика, да и то не факт.
Лол. Ты в курсе, что ОСРВ берёт на себя управление процессами по прерыванию от таймера?
>Как прерывания уживается с требованием изохронности всей системы? Твоё прерывание перебъёт более высокоприоретное прерывание - и что ты сделаешь?
Как ОСРВ уживаются с требованием изохронности всей системы? Твой процесс перебьёт более высокоприоритетный процесс — и что ты сделаешь?
>Как ОСРВ уживаются с требованием изохронности всей системы?
В целом - никак. Ставишь более быстрый процессор и он вроде бы всё успевает. Для большинства задач этого достаточно. Но не для космоса.
>Ты в курсе, что ОСРВ берёт на себя управление процессами по прерыванию от таймера?
Угу. Вытесняющая многозадачность называется. Однако не одним Скиапарелли единым. Вот ещё:
> Доклад с выводами комиссии по причине нештатной ситуации с "Фобосом" был вчера представлен Владимиру Поповкину Юрием Коптевым лично. По сведениям "Ъ", в итоговом отчете комиссии основной причиной инцидента называется "программный сбой, вызвавший одновременный перезапуск двух работающих каналов бортового вычислительного комплекса".
Ты за что топишь-то? За то, чтобы вообще от бортовых управляющих канплуктеров отказаться и делать всё на тёплых ламповых операционниках и кулачковых механизмах?
> Ты за что топишь-то?
Вот священное писание - http://l4ka.org/l4ka/l4-x2-r7.pdf
Придумать лучше, чем описано в этом документе, невозможно.
Я агитирую за то, чтобы перенести на отечественное радиационно-стойкое "железо микроядро L4 Pistachio. Результат переноса использовать в качестве RTOS на космической технике.
И за вппаратную реализацию и развитие идей L4-X2. В обозримом будущем.
О чем тред?
Космос в плане софта и железа не сложнее лифта, с меньшими требованиями по надежности. Хотя и со специфической элементной базой.
Космос в плане софта и железа не сложнее лифта, с меньшими требованиями по надежности. Хотя и со специфической элементной базой.
>О чем тред?
О проблемах российской микроэлектроники.
>Космос в плане софта и железа не сложнее лифта,
А если я тебе скажу что некоторый процент отказа электроники в космосе происходит не от вредного излучения, а из за перегрева? Поверишь?
При том, что причиной перегрева может быть криво написанная программа.
Понятно, опять изохронность не завезли.
>В космосе же несколько поражающих факторов
ок
Как бы пафосно это ни звучало, но вот эта спекцификация есть лучшее, что было изобретено в этой области.
При определённой сноровке на основе этой спеки ты можешь построить изохронную систему. Вот прям как деды - по тактам посчитать. Более того, ты получищь непревзойдённую надёжность - при правильном построении системы, даже если у тебя половина электроники помрёт, оставшаяся продолжит функционировать. Наконец, энергоэффективность, а значит и уменьшенное тепловыделение - большую часть времени устройство находится в режиме ожидания.
Вот три фактора - изохронность, надёжность, энергоэффективность. Готов с примерами обосновать каждый фактор. И пояснить о недостаттке, который тоже имеется.
Смысла нет. Всё равно никто так делать не будет, и тебя к соответствующим задачам тоже никто не подпустит.
Тогда будь готов к тому, что спутники и АМС будут и дальше выходить из строя.
Индия:
Vikram began its descent at 20:08:03 UTC, 6 September 2019 and was scheduled to land on the Moon at around 20:23 UTC. The descent and soft-landing were to be done by the on-board computers on Vikram, with mission control unable to make corrections
Израиль:
On 11 April 2019, the lander crash-landed on the lunar surface. An Inertial Measurement Unit (IMU2) gyroscope failed during the braking procedure on approach to the landing site, and the ground control crew was unable to reset the individual component due to a sudden loss of communications with the control network.
Европейское космическое агентство:
К утру 20 октября была получена вся телеметрия с TGO о маневрах «Скиапарелли» во время посадки. После неполного анализа данных было подтверждено, что, возможно, отстрел парашюта произошёл несколько раньше запланированного, а двигатели мягкой посадки могли выключиться на слишком большой высоте[
Фобос-Грунт:
По сообщению газеты «Коммерсантъ» со ссылкой на источник в ракетно-космической отрасли, во время третьего витка АМС вокруг Земли специалисты не смогли получить информацию о коррекции орбиты маршевой двигательной установкой. Тогда же провалилась одна из первых попыток получить телеметрическую информацию: электроника реагировала на сигналы с Земли со сбоями. БВК уже не действовал согласно заложенной циклограмме полёта. После автоматического одновременного перезапуска бортовой компьютер не смог реализовать ни единого манёвра по выводу аппарата на отлётную орбиту — не сработала двигательная установка, а также не произошло отделения её топливных баков. На последующие команды с Земли станция никак не реагировала
Допустим, что Фобос-Грунт сгубила радиация. Как насчёт других неудач? Особенно при посадках. Отсутствие опыта? Ошибки в ПО?
Всё же Валерий Шунков про радиационно-стойкую электронику пишет чуть интереснее, чем Михаил Сваричевский. У Сваричевского слишком популярно написано, для народа с небольшим техническим бэкрграундом в предметной области.
Да все что угодно, начиная от ошибок допущенных при создании эскизного проекта заканчивая неправильной последовательностью выдачи КПИ уже на сеансе связи. Роль собственно недостатков каких то "микросхем" тут крайне мала, если смотреть в контексте общего числа всех косяков и НС в космической сфере вообще и в жизненном цикле конкретного космического аппарата в частности.
А я тебе скажу, что ВСЕ отказы всей электроники в мире связаны с перегревом. Элекроника 99.(9)% поступающей энергии преобразует в тепло.
Эти проблемы не были озвучены
>если смотреть в контексте общего числа всех косяков и НС в космической сфере вообще
Вот буквально пару несколько минут назад прочитал про альтернативный формат представления чисел с плавающей запятой - https://habr.com/ru/post/467933/
Две цитаты достойны, чтобы их привести здесь:
"Думаю многие из вас могут с ходу вспомнить хотя бы один случай из истории, когда революционные идеи на момент своего становления наталкивались на неприятие сообществом экспертов. Как правило, виной такому поведению выступает обширный багаж уже накопленных знаний, не позволяющий взглянуть на старую проблему в новом свете."
"Ну и не забывайте первый закон Кларка (вольная интерпретация): Когда уважаемый и опытный эксперт утверждает, что новая идея будет работать, то он почти наверняка прав. Когда он утверждает, что новая идея работать не будет — то он, весьма вероятно, ошибается. "
А уж если говорить о космической отрасли, то цена ошибки делает разработчиков чуть ли не суеверными, как студента, носящего на экзамен один и тот же "счастливый" галстук.
Мой посыл следующий - популярные ныне средства управления космическими аппаратами буквально подталкивают разработчиков к ошибкам. Никто не готов принять на себя ответственность за внедрение новых решений. И очень зря.
Ну всё же не все - радиацию за пределами пояса Ван Аллена, да и в самом поясе, никто не отменял.
Что касается температуры... я проводил эксперимент с ПЛИС, запитав её через амперметр и вольтметр. Схема была достаточно сложной, поэтому потребляла немало и грелась ощутимо. Но стоило оборвать тактовый синхроимпульс, как потребление снижалось в 10 раз. Вопрос лишь в том, когда и как "обрывать" синхроимпульс - таким образом можно значительно снизить энергопотребление и нагрев.
О, еще немного - и ты до спящих режимов дойдешь!
Еще один секрет - разрущающий эффект радиации на электронику бывает разных видов, но суть одна - локальный перегрев в месте воздействия.
>но суть одна - локальный перегрев в месте воздействия.
Не совсем. Если в атом кремния попадает достаточно энергичный электрон, то начнется электроядерная реакция. А если резвый гамма-квант, то фотоядерная реакция. Итог один - чипу пиздарики.
>но суть одна - локальный перегрев в месте воздействия.
Не совсем. Если в атом кремния попадает достаточно энергичный электрон, то начнется электроядерная реакция. А если резвый гамма-квант, то фотоядерная реакция. Итог один - чипу пиздарики.
>О, еще немного - и ты до спящих режимов дойдешь!
Вот только не надо грязи. Особенно насчёт "режимов". Ты тянешь "десктопные" понятия в мир встраиваемой электроники. Для космоса обрывать тактовый синхроимпульс более чем достаточно. Во всяком случае это утвреждение справедливо сегодня. А завтра - посмотрим.
И какова вероятность этого события за пределами пояса Ван Аллена?
Каков поражающий эффект на устройство, к которому не подведено напряжение питания?
>спящий режим
>десктопные понятия
Все понятно, проходите мимо. Режимов управления тактированием в микроконтроллерах гораздо больше, чем в "десктопных" микропроцессорах. Современные радстойкие кортексы умеют снимать тактовую частоту, например, с CAN-интерфейса, если он не используется. А могут и не снимать, а просто снизить напряжение питания и отключить выходной каскад - чтобы интерфейс после простоя завелся быстрее. Но это все есть и гражданских чипах.
>Современные радстойкие кортексы умеют снимать тактовую частоту,
Снижать ты хотел сказать? Ты просто не знаешь что это не нужно. Вот вообще не нужно.
> например, с CAN-интерфейса, если он не используется.
И сколько кушает CAN по сравнению с ядром процессора? Пол процента хотя бы есть?
> А могут и не снимать, а просто снизить напряжение питания и отключить выходной каскад - чтобы интерфейс после простоя завелся быстрее.
Это детали. И в зависимости от интерфейса отключение выходного каскада недалеко ушло от выключения питания - устройству понадобится время на синхронизацию с удалённым устройством.
Заметь, я не обвиняю тебя что ты не соображаешь. Соображаешь. Но ты классический пример вот этой проблемы
Как это не нужно? Пример с CAN-шиной. В состоянии ожидания линии он обязан смочь поглотить 175мА тока. Для этого всегда должен быть включен нижний полевик в каскаде. То есть 3-4мкА. Всегда. Теперь ядро - современные ядра могут вплоть до 30мкА/МГц. На частоте 128кГц, так, чтобы работали часики и интерфейсы, будет 3-4мкА. Уже сравнимо. Но если в задаче сказано спать, то можно уйти в стоп (400нА все ядро) или в гибернацию (180нА на все ядро) и потребление интерфейса, регенерация SRAM, компараторы, LCD-контроллер - все это отключается. В том числе и полным отключением PLL того или иного блока.
Пассаж про соображение я пропустил мимо ушей.
>Теперь ядро - современные ядра могут вплоть до 30мкА/МГц.
А смысл? Количество тактов от мегагерц не зависит.
Если зависит - ваш программно-аппаратный комплекс негодный.
Ради потребления. Да, MIPS падают, но в embedded часто потребление нужнее. Да даже больше, процентов 90 микооконтроллерных задач выполняется за нужное время и на килогерцовых тактовых частотах
Да я как бы не спорю с тем, что килогерцевые частоты бывают достаточны для управления оборудованием.
Я о другом - вот эта вот "кухня", которую ты описываешь, тратит драгоценные такты на самоподдержку. Накладные расходы. Особенно асинхронная обработка чего-либо. И вот эти накладные расходы зря греют устройство. На Земле пофиг - так или иначе тепло уйдёт в воздух. А на космическом аппарате отвод тепла уже серьёзная задача.
Я так надеялся что спросишь кто и как должен управлять остановкой тактового генератора...
ап
Тема актуальная всвязи с санкциями и ограничениями на экспорт компонентов двойного назначения. Хочется посеять некоторые мысли на этот счёт в буйных головах.
Для затравки возьмём спускаемый аппарат Скипарелли от Европейского Космического Агенства, который упал на Марс. Существует мнение, что аппарат упал из за ошибки в софте. Известно что управление аппаратом было построено на основе FreeRTOS. Существует ещё мнение, что сама FreeRTOS плохо, почти никак, не подходит для управления космической техникой. Вот из этого частного случая мы разберём ситуацию с космической электроникой и софтом.