Монитор-Э готов

[Feol]

...Но как он выключится, так после включения от 3-х до 5 сеанса связи надо было грузить туда по КРЛ программы-вставки, стандартные циклограммы, уставочные данные и т.д. и т.п. Устанешь пыль глотать...

Сейчас на Глонассах-М всё в точности так же   ! + постоянные мучения с загрузками массивов из-за отвратительной связи из-за никуда негодных КИС и наземки.

[Feol]

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

И вообще в те времена очень старались экономить вычислительные ресурсы, поэтому придумывали всякие хитроумные способы ...

Сейчас участвую в разработке алгоритмов работы прибора ориентации по звёздам. Занимаемся тем же  :lol: . Процессор там от НТЦ Модуль, 40 Мгц. Плавающей точки нет. Любопытно, что, по моим чисто качественным и очень приблизительным прикидкам, иногда производительность такого ПО на этом процессоре эквивалентна работе реализации тех же алгоритмов на C/C++ с использованием плавающей точки (пишем модель для отладки), выполняющимся на процессоре  Pentium с тактовой частотой около 1500 Мгц.
Чего только русские не придумают  :lol:

[пежмарь]

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

[Feol]

Сейчас Модуль, вроде бы, до 80 Мгц частоту поднял. А вообще, конечно, плавающая точка там существенно ускорила бы разработку ПО. И, что важнее, снизила бы вероятность ошибок при применении метода смещений и масштабирований.

[ДалекийГость]

На счёт потери смысла, это ещё не так даже для ПК. Многое из внутренней математики таких известных графических библиотек, как OpenGL, DirectX, реализовано как арифметика с масштабированием и смещением.

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

Сейчас участвую в разработке алгоритмов работы прибора ориентации по звёздам.

Если не секрет, то - это БОКЗ?

Плавающей точки нет.

Искренне сочувствую. Я когда-то тоже программировал без плавающей точки, причем в ассемблере (TASM).

А вообще, конечно, плавающая точка там существенно ускорила бы разработку ПО.

А почему ее нет? Этот самый НТЦ Модуль в прошлом веке остался что-ли?

[Feol]

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

Насколько мне известно, в ПО системы ориентации всех КА с БЦВМ пр-ва НПО ПМ, начиная с Лучей, но исключая Молнию-3к, использовалась арифметика с плавающей точкой.

Если не секрет, то - это БОКЗ?

Нет, это прибор Геофизики. Планируется к применению на нескольких перспективных КА НПО ПМ. Про другие фирмы - не знаю.

Искренне сочувствую. Я когда-то тоже программировал без плавающей точки, причем в ассемблере (TASM).

К счастью, я тут как алгоритмист   . Конкретнее пишу модель БПО на Си/Си++ для отладки алгоритмов с использованием универсальных вычислительных средств. Так что мне в этой работе повезло   . А реальное БПО пишут тоже на ассемблере, хотя Модуль представляет какие-то средства трансляции с Си.

А почему ее нет? Этот самый НТЦ Модуль в прошлом веке остался что-ли?

Вот уж этого я не знаю.. Но кремниевое железо Модуля вроде хвалят.

[ДалекийГость]

Насколько мне известно, в ПО системы ориентации всех КА с БЦВМ пр-ва НПО ПМ, начиная с Лучей, но исключая Молнию-3к, использовалась арифметика с плавающей точкой.

То есть уже больше двадцати лет. Обогнали Энергию.

А реальное БПО пишут тоже на ассемблере.

Но вот это уже точно прошлый век.

Нет, это прибор Геофизики.

Понятно. ИКИ вроде бы собиралось или даже уже поставило в БОКЗ  процессор, интересно было бы узнать подробности, и я почему-то подумал,  что Вы написали про БОКЗ.

[Александр Ч.]

А реальное БПО пишут тоже на ассемблере.

Но вот это уже точно прошлый век.

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

[пежмарь]

Давайте не будем отвлекаться от пациента.
Как выясняется, прошлый век это не турбо ассемблер, а Монитор-Ё и его система команд.

[А.Коваленко]

Следующим этапом, наверное, будет переход с float на double.

Вовсю используется. Во всех программах навигационного, динамического и кинематического контуров. На РС МКС. И бортовое ПО пишется на С. Не уверен про C++.

[ДалекийГость]

Вовсю используется. Во всех программах навигационного, динамического и кинематического контуров. На РС МКС. И бортовое ПО пишется на С. Не уверен про C++.

Да, в программах РС МКС, в том числе и СУДН, используется double,
но переменных типа folat, возможно даже больше, чем переменных типа double. Иметь два различных типа переменных одновременно - неудобно, многие подпрограммы сделаны в двух вариантах - для float и для double, это является источником возможных ошибок. Но ресурсы компьютера не позволили сделать все переменные double.

[Старый]

...Но как он выключится, так после включения от 3-х до 5 сеанса связи надо было грузить туда по КРЛ программы-вставки, стандартные циклограммы, уставочные данные и т.д. и т.п. Устанешь пыль глотать...

Сейчас на Глонассах-М всё в точности так же   ! + постоянные мучения с загрузками массивов из-за отвратительной связи из-за никуда негодных КИС и наземки.

Тс! Осторожно! Ато Панарин узнает...

[Старый]

12.08.2006 / 19:13    Успешная работа КА "Монитор-Э"

     Пресс-служба Роскосмоса сообщает об успешной работе спутника "Монитор-Э". Ежедневно Космическим аппаратом проводятся съемки, запланированные по заявкам потребителей информации с использованием панхроматической съемочной аппаратуры с линейным разрешением порядка 10-11 метров и спектрозональной аппаратуры с разрешением порядка 22–25 метров. За прошедшие 5 месяцев опытной эксплуатации КА "Монитором–Э" выполнена съемка более 70 млн. кв. км поверхности Земли.

Чтото я усомнился. 70 млн. км за 5 мес это не маловато? Это в районе 500 тыс кв. км в день? Если спутник снимает 100-км полосу то её длина всего 5 тысяч км в день? Это он работает всего 10 мин в сутки, чтоли?
Информационный поток камер 122 и 62 Мбит/сек. Ёмкость каждого из двух ЗУ - 200 Гбит. То есть даже писАть в ЗУ он может больше чем 10 минут...

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

Я рад за них! Ещё и года не прошло (послезавтра юбилей) а они уже начали настраивать каналы!

[Feol]

Старый, да ладно вы... Люди (МОКБ Марс) учатся новому для них делу. И, если долго мучится, то может, и получится  :wink: .

[пежмарь]

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

[behappy_now]

Поздравляю всех участников разработки и сопровождения КА "Монитор-Э" с первым годом на орбите!

to Feol: МОКБ Марс разработчик системы управления КА (по ТЗ), а не съемочной аппаратуры. А съемки идут до десяти сеансов в сутки (по примерно 10 мин сеанс   ). Насчет настройки, которая идет до сих пор, где-то с Вами согласен, но, с другой стороны, хорошо, что есть возможности по перенастройке, перезаписи ПО, набору опыта. Аппарат все-таки экспериментальный. Дай Бог на других аппаратах таких граблей не будет.
Насколько я знаю предположения в этой ветке о вычислителе на Мониторе-Э очень далеки от действительности.

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

[N2H4]

Присоединяюсь к поздравлениям, все-таки худо бедно, а год работает машинка.

Только терзают смутные сомнения, что другой аппарат будет делать какое-нибудь ЦКБ Рубин,  и пройдутся по тем же граблям.

Но Хруники все равно молодцы, а еще большими молодцами будут, когда сделают нормальный ДЗЗ (не экспериментальный).  

_____________________________
Свободу пежмарю!

[TAU]

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

Ребята, наличие/отсутствие плавающей точки не является столь принципиальным. Плавающая точка реально необходима только в расчетных алгоритмах, их тут правильно уже перечислили. А бортовое ПО к ним совсем не сводится.

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

[ДмитрийК]

Ребята, наличие/отсутствие плавающей точки не является столь принципиальным.

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

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

Проблема в том что FPGA умеют нормально делать 3-4 фирмы в мире, и к свей интеллектуальной собственности они относятся очень бережно, масса нужной инфы доступна только через NDA (подписку о неразглашении) а чаще сразу кукиш показывают, на себе испытал.

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

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

[Not]

типа формальные спецификации быстро становятся больше по объему чем сама программа и встает вопрос а как доказать корректность спецификаций итд. рекурсивно Пока особого прогресса не видно.

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

Если речь о верификации, то там много чего сделано, тов. Хольцманн в JPL не зря свой хлеб ест. Есть также ряд интересных направлений в CSAIL. MIT. В частности, достаточно давно научились генерировать спецификации автоматически из кода программы и верифицировать их. Естественно, с ограничениями (предполагая что P != NP), но работает.