Любая система по возможности должна быть написана с возможностью повторного использования. Системы, используемые в КА, как нельзя лучше отвечают этому требованию. Экспериментально отработанные и имеющие опыт эксплуатации системы становятся фундаментом для дальнейшей модернизации при использовании на аппаратах аналогичного класса. Решения, примененные в рамках отдельной работы, в дальнейшем могут быть использованы полностью или частично при разработке и принципиально новых КА. Достигается такая возможность тщательной проработанностью архитектуры бортового ПО, разработкой принципов декомпозиции целевой задачи на функциональные модули, а также согласование протоколов обмена и стандартов кодирования. Таким образом любой утилитарный модуль системы может быть легко заменен на другой, необходимый в текущем проекте. Заимствование уже отработанного кода позволяет существенно ускорить разработку как программного кода систему, так и конструкторской и эксплуатационной документации. Использование единой системы позволяет упростить работу эксплуатирующего персонала.
Еще одним несомненным плюсом модульной архитектуры ПО является возможность замены модуля на уже запущенной системе с целью исправления ошибок в ПО, либо внесения новой функциональности.
Тестирование и отработка бортового ПО
Тестированию и отработке ПО всегда уделялось огромное значение. Ведь именно на этом этапе появляется возможность установить корректность выбранных алгоритмов и правильность кодирования.
В доцифровую эпоху, при разработке рулевых машин для ракет A4 немецкие инженеры использовали для моделирования полета простое устройство – маятник Хойзермана. В дальнейшем при проектировании отечественных ракет специалисты использовали электромеханическую модель – банмодель, разработанную немецким специалистом доктором Хохом[13]. При переходе на цифровую технику и с ростом мощностей ЭВМ появилась возможность использовать программно-математические модели, способные моделировать процессы протекающие на ракетах и КА, а также имитировать полет на любых его участках с достаточной точностью[1]. Моделирование позволяет получить достаточно надежные данные о работе системы управления КА более дешевыми средствами, чем испытание реального объекта. Моделирование является единственным методом изучения количественных и качественных сторон системы управления перед непосредственно полетом. К моделям систем предъявляются жесткие требования по достоверности имитации тех или иных процессов, одновременно с этим определяется необходимая глубина моделирования. Теоретическая математическая модель КА и полетной обстановки характеризуется степенью приближения имитационного процесса к реальным процессам, в связи с этим результаты имитационной отработки всегда носят частный характер. Тем не менее, этот метод является наиболее эффективным методом исследования такой сложной системы как КА. Математическая имитационная модель должна обеспечивать:
-моделирование работы всех бортовых систем КА и происходящих в них процессов;
-реакция моделируемых систем на управляющие воздействия;
-моделирование движения центра масс космического аппарата и вращения относительно центра масс;
-моделирование окружающей обстановки: небесных светил, магнитного поля, звездного неба и т. д.;
-генерирование полного потока телеметрической информации;
-моделирование информационных связей между модулями и системами КА;
-ввод нештатных ситуаций в модели систем и модулей КА.
Сам процесс испытаний ПО можно разделить на частные и комплексные испытания. Частные испытания ставят перед собой целью испытать отдельные системы или подзадачи. Комплексные же испытания заключаются в совместной отработке работы всех систем. Сами испытания строятся по схеме с возрастанием показательности и ставят перед собой конечную цель натурного воссоздания штатной работы КА. Так на заключительных этапах тестирования производятся тестовые сценарии моделирующие первые сутки полета космического аппарата с выполнением им всех предусмотренных режимов и операций.
Необходимо отметить что ряд систем, таких как ПО системы управления движением и навигацией, вообще не могут быть проверены до полета кроме как на имитационной модели. Создание модели наиболее достоверно моделирующей механические свойства космического аппарата и физических явлений, оказывающих на него воздействия является одним из наиболее критичных этапов разработки.
Документирование проекта
Выпуск эксплуатационной документацией является одним из наиболее ответственных этапов разработки проекта. Неточности или отсутствие в документации достаточных для полноценного управления сведений может привести к возникновению нештатной ситуации. Эксплуатационная документация должна разрабатываться параллельно кодированию, а ее отработка осуществляться на этапе наземных испытаний. Одной из наиболее серьезных проблем является поддержание актуальности документации в процессе внесения изменений в код ПО. Одним из возможных решений является подробное документирование исходных программ с использованием специфических форматов комментариев, для возможности последующего автоматического построения описания структуры ПО и его составных частей. Данная информация может быть помещена в базу данных и дальнейшее формирование актуальной документации будет сопряжено с выборкой описаний из базы данных. Одной из наиболее известных систем генерации документации на основе исходных кодов является Doxygen - генератор документации для си-подобных языков (в основном) с открытым исходным кодом. Данная система позволяет проанализировать исходный код и построить документацию в различных форматах от html до postscript, что позволяет произвести дальнейшую автоматизированную обработку данных документов для генерации полноценной документации всего проекта в требуемом формате[31]. Использование специализированных ключевых слов в комментариях к исходному коду, позволяет впоследствии переносить их в документацию. Так, например, можно описать назначение функции, обозначить набор входных и выходных данных. При описании структуры можно описать все ее поля, и их назначение, список допустимых значений. Для сложных программных систем такой вид документирования является крайне желательным.
Другим сопутствующим видом исходных данных для написания документации могут являться комментарии в системе управления версиями исходного кода. Краткое описание каждой ревизии предоставляет дополнительный источник данных, необходимых для составления документации.
Заключение
Космическая отрасль по своей природе является достаточно консервативной в выборе средств для построения бортовых комплексов управления и возможности их апостериорной (после запуска) модификации. Положительные результаты, полученные в ходе одного космического проекта, традиционно используются в рамках большого количества аналогичных космических аппаратов. Несмотря на это именно космонавтика является одним из основополагающих стимулов для развития техники и технологии построения сложных адаптивных систем управления, таких как БКУ КА. Постепенно на смену морально устаревающим программно временным устройствам приходят полноценные цифровые комплексы управления, основанные на использовании электронно-вычислительных машин. Основой эффективной работы с такой машиной является индустриальная, апробированная в десятках, а может быть и сотнях проектов операционная система реального масштаба времени. Прикладные задачи, связанные с управлением КА требуют от операционной системы быстрой реакции на асинхронно возникающие события и безотказности работы в течение всего срока существования КА.
В связи с развитием микроэлектроники и общей тенденции к миниатюризации появляются классы малых и микро массогабаритных космических аппаратов. Это позволяет перейти к кластерным запускам. Так, например, кластерный запуск КА «Канопус-В» состоял из запуска собственно КА «Канопус-В», Белорусского космического аппарата - БКА, КА МКА ФКИ, TET1 и ADS-1B. Это приводит к увеличению объема наземной отработки – вместо одного-двух необходимо тестировать группу космических аппаратов. При этом чрезвычайно важно быть уверенным в базовых программных средствах, используемых в бортовой вычислительной системе. Надежность и успешный опыт их использования позволяют в условиях дефицита времени сконцентрироваться на отработке алгоритмов работы КА, а не тратить время на отработку «сырых» операционной системы.
Использование операционной системы реального времени на КА позволяет быстро разрабатывать и эффективно отлаживать прикладное ПО, а также иметь возможность повторного использования кода в последующих проектах. К тому же программное обеспечение может быть верифицировано (всесторонне, с использованием формальных методов и моделей проанализировано и протестировано) на Земле с использованием математических моделей сколь угодно высокой точности.
Описанный в настоящей работе КА «Канопус-В» №1 в настоящее время успешно выполняет целевую задачу на околоземной орбите. Концепции заложенные при разработке его ПО позволяют использовать до 90 процентов его кода в бортовом разрабатывающегося в настоящее время ПО КА «Михайло Ломоносов», запуск которого запланирован на 2013 год.
Разработка программного обеспечения больших проектов всегда представляет трудную инженерную задачу. В настоящее время при разработке космических аппаратов широко применяются хорошо зарекомендовавшие себя аппаратные разработки. До 80 процентов приборов установленных на КА являются частично модифицированными, либо применяются без изменений. В таких условиях написание бортового модульного ПО является жизненно необходимым. Часто аппаратно космический аппарат готов к запуску задолго до окончания разработки ПО. Использование ОСРВ позволяет существенно снизить временные затраты на разработку бортового программного кода.
В настоящей работе приведены качественные и количественные аргументы в пользу выбора операционной системы VxWorks. Правильность выбора подтверждена созданием и эксплуатацией космических аппаратов «Канопус-В» и БКА, а также использованием созданной базовой платформы в процессе создания КА «Михайло Ломоносов».
Список сокращений
БВС – Бортовая вычислительная система
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 |
