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

[Feol]

Unispace практик и отлично понимает, о чём пишет. Всё именно так и есть. Если эти мысли кому-то кажутся странными и не очевидными, то это признак того, что Вы не имели практического опыта подобной работы со всеми вводными. Без обид, ибо неосведомлённость не порок и порицать за неё даже самого себя не нужно. Но факты - фактами. И, напротив, развитие современного ПО для ПК в виде нереального нагромождения избыточных абстракций тоже пошло по естественному пути - было редкое сочетание постоянного роста тактовой частоты, востребованности максимального быстрой разработки и быстрого и непредсказуемого роста пожеланий к новой функциональности ПО.

[Feol]

У Unihorna смешались в кучу кони, люди... Зарплата, абстракции, многозадачность, реклама, и еще бог знает что. Давайте так:

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

Not, Вы просто работаете в другой области и занимаетесь другими задачами. Вы (и я, и все остальные) не можете в жизни реально соприкоснуться со всем. Это невозможно. И тут не получится диалога на одном языке.  Это нормально.

[Not]

Not, Вы просто работаете в другой области и занимаетесь другими задачами. Вы (и я, и все остальные) не можете в жизни реально соприкоснуться со всем. Это невозможно. И тут не получится диалога на одном языке.  Это нормально.

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

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

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

"Если отладка - процесс удаления ошибок, то программирование должно быть процессом их внесения" - Эдгар Дейкстра.

Если вы себя ставите выше Дейсктры - то извольте объясниться.

[Feol]

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

Единственное, что сейчас улучшает ситуацию, это грамотность, опыт и внутренняя самодисциплина разработчика и обширные испытания системы в целом. Но это, увы, не гарантирует ничего!

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

И в свете этого - далее. Если Вы решили научно заняться этим вопросом ("Меня интересуют высоконадежные системы. Причем надежность рассматривается с точки зрения качества алгоритмов. Качество алгоритмов включает в себя как их техническое совершенство, с точки зрения вычислительных возможностей и их устойчивости к аппаратным проблемам, так и минимизации количества ошибок..."), то это похвальное дело. Но не спрашивайте у инженеров-практиков, как решить эту Вашу задачу! Ибо наука идёт впереди всего. А инженерное использование её достижений - это вторая ступень. Тут Вы должны предложить нам решение этой проблемы! А мы проверим это на практике и, если даст эффект, то будем использовать. Образно говоря, Вы пытаетесь узнать у каменщиков, как повысить прочность кирпичей и их долговечность. Каменщик вам либо напрямую скажет, что не знает, или станет объяснять, как он старается повысить прочность и долговечность возводимой им стены из имеющихся кирпичей (класть надо аккуратно и т. п. , что не является ответом на Ваш вопрос.

Таким образом, суть спора в том, что Вы поднимаете вопрос о технологическом механизме обеспечения надёжности алгоритмов в научной постановке. Ибо на сегодняшний день такого механизма нет. А практики пытаются вам объяснить, что они могут сделать имеющимися у них средствами. Это явно не о том, и Вы на них обижаетесь за то, что они не могут решить Вашу задачу! Если Вы решили заниматься научными вопросами (настоящими, не имеющими решения на момент постановки!), то, прежде всего, Вы должны чётко уяснить себе тот факт, что Вам не у кого спрашивать совета! Вам предстоит открыть то, что ещё никто не знает! Ход процесса познания Вы можете обсуждать в своей среде и это может быть полезно, но любое общение со следующими уровнями работы (разработчики, пользователи и т. п.) будет, как минимум, бесполезным. А в худшем случае это может быть конфликтным - ибо может показаться, что Вы пытаетесь решить свою задачу чужими силами. Уверяю Вас, любой разработчик с практическим опытом умеет выявлять и парировать ситуации, когда его заставляют делать чужую работу, ибо на практике такое, увы иногда возникает.

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

[Wishbone]

Для тех, кто до сих пор не открыл Америку:

http://www.nrc.gov/about-nrc/regulatory/research/digital/regs-guidance.html

(АСУ для ядерных реакторов, у нас лет на 8-10 было отставание, да и сейчас не всё переняли, иногда даже к американцам обращаются).

 :roll: Каждый раз, когда я слышу, что программист или инженер способны сами обеспечить надёжность ПО, моя рука тянется ... к кнопке RESET.

[Дядя Вова]

Уважаемые, можете просветить: какая аппаратура сейчас применяется для отладки ПО БВК?
Так понимаю, что тот же БОКЗ ФГ на этапе отладки ПО должен эмулироваться/симулироваться аппаратно-программным комплексом. Логично, что этот комплекс должен быть разработан разработчиком этого БОКЗ.

[zyxman]

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

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

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

И такие технологии есть и активно практически используются. Но действительно не на десктопах, а в серверном программировании.
Конкретно читайте Erlang/OTP и Enterprise Java.

[Unispace]

У Unihorna смешались в кучу кони, люди... Зарплата, абстракции, многозадачность, реклама, и еще бог знает что. Давайте так:

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

Я вам скажу пожестче. Когда вы получите опыт программно-аппаратной разработки цифровых систем управления и обработки реального времени, тогда и будем говорить дальше. У меня такой опыт есть, железо - от транзистора до DSP, программы - несколько асмов и несколько языков высокого уровня, плюс немалые знания об одном из самых сложных классов распределенного оборудования, где работают одновременно тысячи процессоров. Поэтому мой опыт куда ближе к созданию АМС, чем пространные мудрости тестирования ПО от сисадминов, программеров окошек и QA-товарищей. И мы по-прежнему не имеем никакой внятной информации, поэтому обсуждать, что там и кто виноват, в конкретике, пока не можем.

[zyxman]

Уважаемые, можете просветить: какая аппаратура сейчас применяется для отладки ПО БВК?

Судя по тому что я читаю на этом форуме и по моему личному опыту общения с разработчиками ПО из военки, отлаживается всё это на дремучем кустарном уровне - в обычном дебаггере на ПК.

Так понимаю, что тот же БОКЗ ФГ на этапе отладки ПО должен эмулироваться/симулироваться аппаратно-программным комплексом.

Не обязательно.
Я разрабатываю в том числе и ПО для астрономов. Конкретно сейчас делаю программу обработки видео с метеорами - по сути оно хоть и не то же самое что БОКЗ, но входная информация практически такая-же - работаем со звездным полем. Разница в том что БОКЗ выделяет звезды и их отождествляет, я же выделяю из разницы двух кадров наличие движущейся "звезды" и пытаюсь по каким-то критериям отфильтровать другие движущиеся объекты.
Программа отлаживается на некотором множестве видеороликов, где есть эти самые метеоры.

Логично, что этот комплекс должен быть разработан разработчиком этого БОКЗ.

НЕТ. По нормальной логике комплекс тестирования должны разработывать СОВСЕМ другие люди.

[Unispace]

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

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

[Вал]

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

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

Она не сработает, только если крышку с объектива не снять перед установкой АМС в КГЧ РН. Астронавигация, это самая отработанная и безотказная часть конструкции и алгоритмов любого аппарата. И одна из самых простых.

[ZOOR]

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

Когда 20 лет назад учился, было модно все делать по http://www.bookwork.ru/book/pratt_dip , в частности http://www.tvp.ru/conferen/vsppm10/speso137.pdf

Как в данном конкретном случае реализовано - не знаю

Она не сработает, только если крышку с объектива не снять перед установкой АМС в КГЧ РН. Астронавигация, это самая отработанная и безотказная часть конструкции и алгоритмов любого аппарата. И одна из самых простых.

Ну положим, крышку забыли снять или кабель прикрутить....
Так что , при этом АМС в даун уходить должна? - совсем уж глупо алгоритм БКУ составить надо было
Согласен, что дело не в БОКЗ ИМХО

[Дядя Вова]

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

Подозреапю, что аттестовать такой стенд будет сложнее, чем его сделать.

[Unispace]

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

Когда 20 лет назад учился, было модно все делать по http://www.bookwork.ru/book/pratt_dip , в частности http://www.tvp.ru/conferen/vsppm10/speso137.pdf

Как в данном конкретном случае реализовано - не знаю

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

[Unispace]

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

Подозреапю, что аттестовать такой стенд будет сложнее, чем его сделать.

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

[Ded]

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

Подозреапю, что аттестовать такой стенд будет сложнее, чем его сделать.

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

Осталось понять, куда в датчик "втыкать" оптический переходник. Если моя информация корректна, то БОКЗ по запросу выдает углы ориентации относительно своей системы координат.

[Дядя Вова]

Осталось понять, куда в датчик "втыкать" оптический переходник

Ну, это частности. Важно, что при такой симуляции задействован весь
тракт преобразования, в т.ч. соединители, математика датчика.

Как эти вещи реализованы были при отладке ПО ФГ - вот что интересно.

[Ded]

Осталось понять, куда в датчик "втыкать" оптический переходник

Ну, это частности. Важно, что при такой симуляции задействован весь
тракт преобразования, в т.ч. соединители, математика датчика.

Как эти вещи реализованы были при отладке ПО ФГ - вот что интересно.

Вы не прочли вторую часть моего сообщения.

Для отработки необходима имитация паузы между запросом и ответом от БОКЗ.

Необходимо искать ОДНУ причину отказа.

[zyxman]

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

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

Наткнулся на текст журнала "Вестник ФГУП НПО им. Лавочкина" (№2 за 2009). Там есть раздел, посвященный методике тестирования алгоритмов БКУ. В частности, есть описание тестирования алгоритма ориентации КА с использованием данных БОКЗ и БИБ. Процесс сводится к периодическому двунаправленном обмену данными между программой-эмулятором показаний БОКЗ и БИБ и устройством, которые авторы называют "бортовой машиной" (БМ). Обмен производится через файлы, т.е. на одном шаге программа-эмулятор формирует файлы "в оговоренном формате" с показаниями БОКЗ и БИБ, на следующем шаге БМ формирует файл с программой воздействия на элементы системы ориентации, после чего процесс повторяется. Из этого описания видно, что комплексного эмулятора, который моделирует поведение аппарата в целом, не существовало. Есть некие тесты проверки отдельных систем, с неизвестным уровнем качества исполнения. Лично мне показалось странным использование файлового обмена для проведения процесса эмуляции. Т.е. в процессе тестирования не было обмена данными в штатном виде.
Вообще, надо сказать, сам стиль изложения материала авторами не производит никакого впечатления: какие то полулюбительские кривоватые формулировки. При описании процесса зачем то приведены имена файлов, формируемых эмулятором БОКЗ и БИБ, как будто эта информация имеет какое-то важное значение для понимания процесса тестирования. Есть и другие странные моменты. В общем, не хочу наезжать на создателей и тестировщиков, но от прочтения документа осталось тягостное впечатление.

http://www.novosti-kosmonavtiki.ru/phpBB2/viewtopic.php?p=841486#841486
а тут этот самый "вестник":
http://vestnik.laspace.ru/archives/showproduct/1/2

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

Подозреапю, что аттестовать такой стенд будет сложнее, чем его сделать.

Вот именно поэтому я и говорю, что стенд должен делать не разработчик БОКЗ, а третья сторона или представитель заказчика.
Ибо разработчик очевидно заинтересован продать что угодно и поэтому заинтересован и в стенде убрать невыгодные ему режимы, дабы показать свое изделие в лучшем свете, а вот заказчик заинтересован не купить абы что.
Но включать третью сторону в этот интимный процесс всё усложняет и удорожает, поэтому скорей всего всё происходит на уровне анекдота:

- вовочка, докажи теорему Пифагора
- Богом клянусь!

И собственно, я думаю что действительно алгоритмы ЦОД там скорей всего в порядке.
А подкачать могло совсем другое - встречалось сообщение что в БОКЗ применили матрицу иностранного производства, а собственно БОКЗ это получается фотоаппарат, а у матрицы своя циклограмма работы и иностранные матрицы очевидно отличаются от отечественных, и есть ненулевая вероятность что баг в подключении матрицы и из-за этого нет картинки.

[profan]

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

Подозреапю, что аттестовать такой стенд будет сложнее, чем его сделать.

Дядя Вова - не у того спрашиваете  
Он сам писал, что его личный опыт - это отладка в дебаггере.

В основной теме выкладывали ссылку на документ
http://vestnik.laspace.ru/archives/showproduct/1/2
Там есть раздел про стенды.  см стр 38.
Только вот плохо, если ПО стендов пишут те же люди, что и ПО борта.