Особенности программирования БВК АМС

[profan]

Люфты, дрейфы, забития оптики  и премного тракта ни одна модель не покажет.

Модель всегда можно доработать и добавить все изменения и особенности реального аппарата. Вот доработать реальный аппарат обычно невозможно.

Мда. Просто на слово поверьте, описать в модели реальное устройство на 99% достоверно- не в силах современной вычислительной мощности компьютеров. МОДЕЛЬ всегда основывается на упрощениях, граничных условиях и недопонимании реальных процессов. И это в реальной работе чаще всего выходит боком.

[zyxman]

Модель всегда можно доработать и добавить все изменения и особенности реального аппарата. Вот доработать реальный аппарат обычно невозможно.

Мда. Просто на слово поверьте, описать в модели реальное устройство на 99% достоверно- не в силах современной вычислительной мощности компьютеров.

Какая по вашему сейчас доступная вычислительная мощность компьютеров?

МОДЕЛЬ всегда основывается на упрощениях, граничных условиях и недопонимании реальных процессов. И это в реальной работе чаще всего выходит боком.

Это логично. Но это происходит с каждым днем всё меньше от недостатка вычислительной мощности, а больше от недостатка человеческой мощности.

[profan]

Модель всегда можно доработать и добавить все изменения и особенности реального аппарата. Вот доработать реальный аппарат обычно невозможно.

Мда. Просто на слово поверьте, описать в модели реальное устройство на 99% достоверно- не в силах современной вычислительной мощности компьютеров.

Какая по вашему сейчас доступная вычислительная мощность компьютеров?

МОДЕЛЬ всегда основывается на упрощениях, граничных условиях и недопонимании реальных процессов. И это в реальной работе чаще всего выходит боком.

Это логично. Но это происходит с каждым днем всё меньше от недостатка вычислительной мощности, а больше от недостатка человеческой мощности.

Верьте во что хотите, хоть в логику, хоть в светлый ум. Вычислительной мощности кластеров как раз хватает обсчитать поведение отдельных белковых молекул.

[Feol]

Люфты, дрейфы, забития оптики  и премного тракта ни одна модель не покажет.

Модель всегда можно доработать и добавить все изменения и особенности реального аппарата. Вот доработать реальный аппарат обычно невозможно.

Мда. Просто на слово поверьте, описать в модели реальное устройство на 99% достоверно- не в силах современной вычислительной мощности компьютеров. МОДЕЛЬ всегда основывается на упрощениях, граничных условиях и недопонимании реальных процессов. И это в реальной работе чаще всего выходит боком.

Нет другого выхода. На стенде разрозненные механические имитаторы вращения приборов, физические имитаторы ориентиров и т. п. настолько безбожно далеки от истины, что там, по крайней мере, когда я работал (по 2004 г.) на все погрешности до 1 градуса приходилось просто не обращать внимание. Иногда раздвигая пороги в бортовом ПО и т. п. Удаётся проверять только логику и, частично, динамику, но зато в полном объеме с реальным железом. На модели все гораздо тоньше и точнее. Кроме того, при моделировании с введением шумов можно обеспечить 100% воспроизводимость результата при разных прогонах, что бывает очень важно. Лучше всего было бы, конечно, экспериментировать на реальном КА в реальном полёте, видя всё со стороны - но это невозможно. На практике, в части системы ориентации имеющаяся мат. модель давала очень хорошие, достаточные  результаты. Сейчас я думаю, что стало не хуже. А при разработке приборов более детальное моделирование. Сам сейчас автор реализации мат. модели звёздного датчика 329к. Там больше упор на физику, отдельно моделируется накопление заряда каждого пикселя ПЗС с введением разного рода внешних и внутренних помех, оптика объектива и алгоритмы прибора на фоне этого. В мат. модели КА для отладки систем это не очень нужно, хотя и интересно было бы съынтегрить. Модель ценна, опять-таки тем, что имеющийся стенд настолько груб, что многое уловить просто не позволяет. Нет на реальном оборудовании, конечно же, и воспроизводимости результатов. Так же можно вводить дефекты прибора и смотреть, что будет, что на реальном приборе непросто сделать. В общем, мат. моделирование сейчас весьма полезное дело на практике, ИМХО.

[goran d]

Насчет скорости асемблера и компилятора. Посмотрел на код ассемблера, который производит GCC при -O3 оптимизации. Код - ето парсер. Сравнивает переменную много раз с разными стоимостями, но почему-то не держит ее в реестре, а в памяти. Уж точно етот код можно сделать в ручную немного быстрее. Хотя толку от етого, конечно, немного.

[Feol]

Разница в том что БОКЗ выделяет звезды и их отождествляет

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

Про БОКЗ ничего не знаю.. С прибором, к которому имею отношение (новая разработка, не ИКИ) основная проблема - выделение звёзд на фоне шумов ПЗС, и, особенно, снижение влияния этих шумов на точность определения ориентации. Есть 2 подхода: в первом каждый кадр (или группа кадров) обрабатывается независимо. Выполняется поиск и обнаружение световых источников, селекция помех, распознавание звезд (по угловым расстояним между ними), определение ориентации. Во втором подходе выполняется поиск и обнаружение световых источников, селекция помех, распознавание звезд (по угловым расстояним между ними), затем переход к слежению за группой звёзд с глубокой фильтрацией шумов положения, определением ориентации, предсказанием входящих в поле зрения новых звёзд, их захватом, постановкой на слежение, накоплением точности по фильтру и подключением к определению ориентации. Достоинство второго подхода, в основном, в большей точности за счет снижения влияния шумов. Иногда можно реализовать и более частую выдачу выходной информации. Недостаток в динамическом запаздывании (из-за многокадровой фильтрации) выходных данных и, главное, в возможности длительного ложного слежения после сбоя, особенно при медленном повороте оси визирования прибора. Можно устранить периодическим повтором поиска и обнаружения. В части селекции помех важной является межкадровая обработка. Объектив прибора работает в расфокусе, формируя специальную гауссоиду рассеяния. Это делается для того, чтобы движение звёзд 'раскладывалось' на уровни яркости пикселей. Иными словами, движение точечного источника внутри пикселя обнаружить нельзя, а между пикселями будет непонятно, что. При движении пятна изменяются яркости занимаемых им пикселей, что позволяет вычислить энергетический центр с точностью, намного превышающей разрешающую способность матрицы по числу пикселей. Число пикселей на практике имеет относительно небольшое значение. Наиболее сложный момент - влияние факторов космического полёта на помехи ПЗС. Очень трудно предсказуемое дело до практического облёта. Особенно на радиационно тяжёлых орбитах. Слышал, что все зарубежные приборы сделаны чуть ли не на одной и единственной американской матрице ПЗС. Ну а мы выворачиваемся, с чем можем . Алгоритмы распознавания и определения ориентации просты и особых проблем не вызывают. В первом случае перебор пар звёзд по каталогу, во втором случае чистая математика. При правильных значениях на входе детерминирован правильный результат. Основная сложность, повторюсь, в селекции помех разного рода и фильтрации шумов на фоне не совсем понятной картины того, что будет происходить в действительности.

Ниже, для иллюстрации, пример 'фотографии' с ПЗС. Синтезирована в модели ПЗС на основании теории, наземных тестов, проверок в ускорителе элем. частиц. Облёт дал мало информации из-за нештатного выведения и ненормальной работы КА. 'Фото' содержит 31 звезду, 28 помех от протонов, дробовые шумы, электрические шумы, ряд экспериментальных данных по фону, неравномерность св. чувствительности пикселей, учёт темновых токов пикселей и АЦП.

[Not]

Июньская публикация Лаборатории надежности ПО (JPL) - формальный анализ декларативных полетных программ (Flight rules)

http://www.havelund.com/Publications/tracecontract-ladee.pdf

[Дем]

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

лучше меньше, чем ничего.

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

А что сложного-то? Вот надо например клапаном щёлкнуть - выставляем два активных выхода, они через "И" на ключ. А не выставили второй в заданный период - первый автоматом сбросился.

[zyxman]

лучше меньше, чем ничего.

Несомненно! Но АМС всегда были, есть и будут на острие технического прогресса, так что прийдется всегда делать трудный выбор, повторять ли уже известное или делать новое и рискованное.

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

А что сложного-то?

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

Ну условно, компьютер IBM RAD 6000 стоит 200000-300000$, промышленный компьютер такого уровня стоит ну пусть 2000$, а если делать совсем уникальный компьютер с такими дополнительными защитами, он будет стоить еще на пару порядков дороже чем RAD 6000.
Плюс, драйвера и ОС для RAD 6000 более-менее стандартные и уже отлаженные выше крыши применением в различных устройствах вплоть до мыльниц-роутеров, а тут всё совсем новое.

[Unispace]

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

Интересно, спасибо. Но неожиданно, я полагал, что природа звездного неба и ненужность высокой скорости захвата обеспечит высокое SNR с сенсора. Однако 35 лет назад уже работало ? А за это время процессоры стали на несколько порядков мощнее. Получается, что уж с этой подсистемой алгоритмически-математических проблем быть не должно.
В добавление к вроде глупой теории о том, что на орбите не весь ФГ, а лишь разгонное железо. А нельзя ли именно этим объяснить, что орбита снижается меньше расчетной ? Законы Ньютона помню    Уж лучше бы он полетел.. хоть куда-нибудь

[В И]

Уж лучше бы он полетел.. хоть куда-нибудь

Сегодня и полетит ! Я сказал. :roll:

— Я слова заветные знаю. Земля, прощ...

:wink:

[Not]

Будем дальше рассуждать о роли транзистора в научно-техническом прогрессе?  :wink:

Не будем, по причинам, уже указанным мной. Когда создадите своими руками железо, напишете для него код, характерный для систем математической обработки информации, отладите, запустите в работу, тогда будет предмет для дискуссии. Тогда вы будете видеть всю систему, железо+софт+математические алгоритмы, целиком, и не акцентировать на какой-то одной стороне. Замечу, что, строго говоря,  полновесного предмета все равно не будет, потому что мы здесь не обсуждаем, кто что может. А информации от НПОЛ по-прежнему нет. Возможно, и не будет.

Да где уж нам, неучам, против гениев тавтологии. Заметит он  :lol:

[ZOOR]

zyxman.
наверное Вы меня не поняли. Имелась ввиду отладка ПО БВК. Т.е применительно к взаимодействию БОКЗ, как вариант, эмулятор должен был выглядеть так.
Раздербаненый БОКЗ на матрицу которого проецируется сгенерированная картинка участка звездного неба.  И ПО такого стенда реализуют алгоритмы разрешения изображения "наоборот" - по задаваемому положению КА генерируют картинку.
Подозреапю, что аттестовать такой стенд будет сложнее, чем его сделать.

Уткнуть датчик через оптический переходник в дисплей с запущенной программой Google Earth    Нет, в этом модуле никаких алгоритмических проблем быть не должно.

Как в воду глядел - http://www.iki.rssi.ru/ofo/pdf/stand_prepr.pdf (рис.4)  
Кста, они же БОКЗ и делали - http://ofo.ikiweb.ru/p_phobos.php

[Feol]

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

Насколько я знаю (могу далеко не всё знать), до БОКЗ, в нашей стране нынешнее НПП Геофизика-Космос для космических аппаратов НПО ПМ (ОАО ИСС) создавала только датчик полярной звезды. Использовался с 1982 г. на Гейзере. Прибор отслеживал одну звезду с использованием, фактически, небольшого телескопа, болометрического фотоприёмника и имел совершенно другую массу, потребление, по началу недостаточную помехоустойчивость к летающим вокруг КА разного рода частицам. На фоторазведывательных КА использовались по несколько подобных приборов, смотрящих на разные звёзды. Так же создавались аналогичные приборы для отслеживания заданных звёзд с ракет подводных лодок, стоят они и на известной Булаве. О проблемах с ними ничего не слышал . Для этих приборов нет проблемы помех от частиц, ибо ракета летит с ускорением, так же достаточен очень короткий ресурс работы. В настоящее время в мире активно развивается совершенно новое направление ПЗВ: приборы с широким полем зрения на базе фотоприёмников с ПЗС, работающие по нескольким звёздам одновременно, автономно выдающие полную информацию об ориентации прибора в геоцентрической системе координат, имеющие небольшой объектив, малые габариты, массу, энергопотребление и сроки службы от 10 лет и более. В Европе их выпускает французский Sodern, у нас первыми такой прибор сделали в ИКИ (БОКЗ). Теоретически, одного такого прибора при наличии баллистической информации достаточно для создания прецизионной трёхосной системы ориентации КА. Однако, установка таких датчиков на КА представляет собой сложную проблему. Надо, чтобы в окрестность, несколько превышающую поле зрения (градусов 20 - 30 обычно), не попадали Солнце, Луна, Земля (а если орбита такая, что угловой диаметр до 120 градусов?), элементы конструкции КА, которые могут иметь большие габариты, вращаться, поворачиваться, угол м/у осью визирования приборов и направлением выхлопа всех реактивных двигателей желательно обеспечить не менее 90 град. для предотвращения загрязнения объектива, и т. п. По этому, на практике разработчики КА эти приборы не очень любят. А окупают себя они, в основном, высокой точностью определения ориентации ценой малой массы и потребления.

[Feol]

zyxman.
наверное Вы меня не поняли. Имелась ввиду отладка ПО БВК. Т.е применительно к взаимодействию БОКЗ, как вариант, эмулятор должен был выглядеть так.
Раздербаненый БОКЗ на матрицу которого проецируется сгенерированная картинка участка звездного неба.  И ПО такого стенда реализуют алгоритмы разрешения изображения "наоборот" - по задаваемому положению КА генерируют картинку.
Подозреапю, что аттестовать такой стенд будет сложнее, чем его сделать.

Уткнуть датчик через оптический переходник в дисплей с запущенной программой Google Earth    Нет, в этом модуле никаких алгоритмических проблем быть не должно.

Как в воду глядел - http://www.iki.rssi.ru/ofo/pdf/stand_prepr.pdf (рис.4)  
Кста, они же БОКЗ и делали - http://ofo.ikiweb.ru/p_phobos.php

Безумно кошмарный ИКИшный софт у этого стенда. Тихий ужас.

[avp]

"за всё приходится платить" (с) , и изучить еще один язык небольшая плата. По опыту изучение самого языка Erlang занимает пару недель.

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

Вот изучение OTP, версионной системы и отладчика и вообще специфики рантайма конечно может занять значительно больше, но код человек сможет писать очень быстро и очень быстро сможет присоединиться к живому проекту.

На одних только иммутабельных величинах программировать сложные алгортимны очень трудно.  Это факт. Хотя теоретически это возможно.

Я вообще-то говорил комплексно про СИСТЕМУ Erlang/OTP, и она НЕВОЗМОЖНА в отрыве от языка.

Реализацию рантайма ещё надо написать и отладить. При этом скорее всего ещё ОС придётся делать. Для новой железки это неподъёмная задача. Компиляторы и ВМ вылизываются и отлаживаются десятилетиями. Такое возможно только на долгоиграющей стабильной платформе типа PC.

Связность  определяется предметной областью, а не языком.

В случае Erlang/OTP вы автоматически будете писать слабосвязанно, ибо запрещено почти всё что дает сильные связи.

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

Любой скриптовый язык это может.

ПОЛНУЮ изоляцию НЕ ЛЮБОЙ.

Нет никакой полной изоляции. Её обеспечивает рантайм, либо ОС.

Точнее проблема что вы читаете язык, а я пишу про СИСТЕМУ, в которой и ВМ и библиотеки и дебаггеры и даже собственная версионная система.

А я ещё раз говорю - каким боком это относится к КА и всяким контроллерам? Откуда возмётся это сверхнадёжное ПО для какой нибуть малосерийной железки?.

Вообще-то правильно разделять программиста-математика-алгоритмиста и программиста-кодера.
Аналитик это вообще отдельный человек.

Аналитик это тот кто составляет ТЗ на ПО.

Легковесные потоки и message passing есть много где.

Но практически нигде нет полноценной изоляции процессов

Если бы это было краеугольным камнем... Это лишь мелкая фича, которая ситуацию не меняет.

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

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

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

По существу у Erlang задачи НЕ псевдо-параллельные, а реально параллельные асинхронные, потому что могут жить на физически разных машинах.

А причём тут софт КА? Такие фичи точно не нужны.

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

Что-то вы непонятное тут говорите. Такое впечатление что вам про Erlang "Рабинович напел"

Это среда заточенная для систем массового обслуживания. Для ПО КА её фичи малополезны.

[PIN]

В настоящее время в мире активно развивается совершенно новое направление ПЗВ: приборы с широким полем зрения на базе фотоприёмников с ПЗС, работающие по нескольким звёздам одновременно, автономно выдающие полную информацию об ориентации прибора в геоцентрической системе координат, имеющие небольшой объектив, малые габариты, массу, энергопотребление и сроки службы от 10 лет и более. В Европе их выпускает французский Sodern

В Европе их производит даллеко не одна компания. Потому что никак не "новое направление". Тот же Sodern делает такие датчики более 2х десятилетий. Датчики 2го поколения (о таком идет речь в данном контексте) летают уже 15 лет.

[PIN]

Однако, установка таких датчиков на КА представляет собой сложную проблему. Надо, чтобы в окрестность, несколько превышающую поле зрения (градусов 20 - 30 обычно), не попадали Солнце, Луна, Земля

Не стоит преувеличивать. Обычно используется 2-3 датчика, при этом ослепление одновременно двух из них - редкое событие. Угол, о котором Вы пишите, у современных датчиков находится в диапазоне 15 (Луна) - 20 (Солнце) градусов.

[Feol]

В настоящее время в мире активно развивается совершенно новое направление ПЗВ: приборы с широким полем зрения на базе фотоприёмников с ПЗС, работающие по нескольким звёздам одновременно, автономно выдающие полную информацию об ориентации прибора в геоцентрической системе координат, имеющие небольшой объектив, малые габариты, массу, энергопотребление и сроки службы от 10 лет и более. В Европе их выпускает французский Sodern

В Европе их производит даллеко не одна компания. Потому что никак не "новое направление". Тот же Sodern делает такие датчики более 2х десятилетий. Датчики 2го поколения (о таком идет речь в данном контексте) летают уже 15 лет.

Да, именно так.

[Feol]

Однако, установка таких датчиков на КА представляет собой сложную проблему. Надо, чтобы в окрестность, несколько превышающую поле зрения (градусов 20 - 30 обычно), не попадали Солнце, Луна, Земля

Не стоит преувеличивать. Обычно используется 2-3 датчика, при этом ослепление одновременно двух из них - редкое событие. Угол, о котором Вы пишите, у современных датчиков находится в диапазоне 15 (Луна) - 20 (Солнце) градусов.

Это полураствор - в каждую сторону от оси визирования. Полное поле зрения, допустим, у 329к, 22x17 градусов (+-11 / +-8.5). А проблема - смотря на каком КА. В отношении той темы, по которой я еще работал в ИСС, это было безумно сложно. Но о ней не буду рассказывать - насколько мутная, настолько же и закрытая тема ('Л...')