CC BY
48
УДК 004.3:004.41:004:75 001: 10.18698/0236-3933-2018-2-69-86
О ПРИНЦИПАХ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННО-УПРАВЛЯЮЩЕЙ СИСТЕМЫ РОССИЙСКОГО СЕГМЕНТА МЕЖДУНАРОДНОЙ КОСМИЧЕСКОЙ СТАНЦИИ
Ф.А. Воронин favoronin@gmail.com
Д.С. Назаров oniksor@mail.ru
П.А. Пахмутов Pavel.Pahmutov@rsce.ru
А.В. Сумароков avsumarokov@gmail.com
ПАО «Ракетно-космическая корпорация «Энергия» имени С.П. Королёва», г. Королёв, Московская обл., Российская Федерация
Аннотация
Рассмотрена идеология, заложенная при разработке программного обеспечения информационно-управляющей системы российского сегмента Международной космической станции. Информационно-управляющая система служит для обеспечения проведения различных космических экспериментов на борту Международной космической станции. Ввиду повышающейся сложности планируемых и проводимых космических экспериментов имеющихся возможностей и вычислительных ресурсов на борту становится недостаточно. Подробно исследованы структура, принципы разработки и требования, которые были заложены при создании нового поколения компьютеров существующей системы. На примере работы созданного программного обеспечения в процессе проведения некоторых наиболее значимых экспериментов показаны преимущества и недостатки принятой концепции разработки
Ключевые слова
Международная космическая станция, космические эксперименты, информационно-управляющая система, бортовой компьютер, российский сегмент
Поступила в редакцию 22.06.2017 © МГТУ им. Н.Э. Баумана, 2018
Работа выполнена при финансовой поддержке РФФИ (гранты № 17-08-01635, № 18-08-01379)
Для целевого использования исследовательских модулей, интегрированных в состав российского сегмента (РС) Международной космической станции (МКС) [1, 2], и формирования высокотехнологичных условий проведения научных экспериментов на РС МКС в ПАО «РКК «Энергия» ведутся полномасштабные работы по созданию информационно-управляющей системы (ИУС) на новых модулях, по модернизации на уже существующем служебном модуле (СМ) «Звезда» (запуск осуществлен в 2000 г.), и объединению их с бортовым комплексом управления (БКУ) в единую информационную среду [3-5].
Информационно-управляющая система представляет собой отдельную по отношению к БКУ систему, которая непосредственно отвечает за выполнение целевой функции МКС. В целом управление научной аппаратурой на станции строится по иерархическому принципу (рис. 1).
Рис. 1. Структура ИУС
Верхним уровнем управления по отношению к ИУС является БКУ РС МКС и наземный комплекс управления. В свою очередь, ИУС управляет непосредственно комплексом целевых нагрузок, являющимся самым нижним уровнем в данной иерархии. Другими словами, БКУ отвечает за функционирование и управление РС МКС в целом, а ИУС реализует целевую функцию станции — проведение научных экспериментов посредством комплекса целевых нагрузок.
Ключевым элементом ИУС, обеспечивающим координированное управление и контроль полезных нагрузок, является бортовая цифровая вычислительная система. В состав задач данной системы входит:
1) получение управляющих команд и информационных ресурсов из БКУ, их дешифровка, обработка и маршрутизация в аппаратуру целевых нагрузок;
2) предоставление вычислительных ресурсов для реализации алгоритмов управления оборудованием целевых нагрузок [6-9];
3) сбор по цифровым интерфейсам телеметрической и статусной информации от аппаратуры целевых нагрузок, ее кодировка и передача через БКУ по радиоканалам на наземные пункты управления;
4) управление и контроль бортовыми средствами электропитания комплекса целевых нагрузок;
5) прием информации с результатами работы научной аппаратуры, ее временное хранение и маршрутизация для сброса на наземные станции, с использованием имеющихся на борту МКС радиосредств, обеспечивающих возможности передачи больших массивов данных [3].
Следует отметить, что обеспечение работы полезных нагрузок имеет ряд ключевых особенностей. В первую очередь это изменчивость состава аппаратуры — аппаратура для одних экспериментов доставляется на борт, другая аппаратура отключается в связи с окончанием тех или иных экспериментов. Так, состав научной аппаратуры может значительно меняться с течением времени.
Другой ключевой особенностью является то, что научная аппаратура в большинстве случаев поставляется сторонними организациями, имеет разные количественный и качественный составы, разные интерфейсы обмена данными и программную реализацию. Таким образом, ИУС должна иметь возможность интегрировать в состав комплекса целевых нагрузок абсолютно разную аппаратуру и уметь учитывать специфику ее функционирования. Ввиду того, что реализовать все многообразие существующих интерфейсов на борту МКС невозможно, информационное взаимодействие с аппаратурой полезных нагрузок на этапе планирования научных экспериментов и изготовления научной аппаратуры ограничивается следующим набором наиболее распространенных интерфейсов: MIL1553, CAN, Ethernet, RS422.
Как было указано в [3], для обеспечения унификации аппаратных средств с учетом возможности последующей модернизации ИУС и повышения общей надежности системы, аппаратная реализация компьютеров ИУС нового поколения идентична. Каждый компьютер системы после проведения модернизации будет построен на базе процессора Celeron-400 МГц с интерфейсами Ethernet, CAN, MIL STD 1553B, RS422 и двумя жесткими дисками с суммарной возможностью записи 40 Гб информации.
Использование в ИУС однотипных компьютеров обеспечивает их взаимозаменяемость и ремонтопригодность как на борту, так и на наземных средствах отработки и испытаний. Тем не менее каждый компьютер имеет свое уникальное программное обеспечение (ПО) и выполняет различные задачи. В настоящей работе подробно рассматриваются принципы построения и требования, заложенные при создании ПО компьютеров ИУС нового поколения. Обсуждены задачи, которые необходимо было решить в процессе его создания, и описан подход к унификации ПО, положенный в основу концепции его разработки.
Требования, предъявляемые к ПО компьютеров ИУС. Поскольку ИУС состоит из совокупности однотипных взаимозаменяемых компьютеров, то одним из ключевых требований при разработке ПО является его максимальная унификация. Ввиду приведенных особенностей ИУС, при проектировании ПО необходимо было обеспечить решение ряда ключевых задач.
Во-первых, непостоянство целевой аппаратуры накладывает требование на обеспечение программной поддержки периодически меняющего состава полезных нагрузок с минимальными затратами на создание и верификацию нового ПО.
Во-вторых, имеющийся набор разных логических и физических интерфейсов диктует необходимость обеспечения программной поддержки каждого интерфейса.
В-третьих, предъявляется одно из базовых требований ко всем управляющим бортовым компьютерам — работа в режиме реального времени.
В-четвертых, для разработки, отладки и непосредственного функционирования ПО на борту МКС необходимо обеспечить его платформонезависимость. Это связано с тем, что бортовые компьютеры и компьютеры, на которых разрабатывается и отлаживается ПО, имеют разные операционные системы.
Принципы создания и архитектура ПО. При разработке ПО компьютеров ИУС было предложено использовать объектно-ориентированный подход. В качестве языка программирования использовался С++. В итоге для удовлетворения всех предъявляемых требований при обсуждении архитектуры ПО была выбрана концепция построения ПО компьютеров ИУС, изображенная на рис. 2 [5].
\ Интерфейсное ПО ПО ПН1) для обеспечения ___У работы ПН
Стандартные
■ А N интерфейсы между
\г-1/ ядром ПО компьютера
ИУС и ПО ПН
Полезные нагрузки с различными аппаратно-программными интерфейсами (1553, Ethernet, CAN, RS422)
Рис. 2. Структура ПО компьютера ИУС
Для обеспечения унификации ПО между всей совокупностью имеющихся бортовых компьютеров ИУС на разных модулях МКС было предложено разбить все ПО на две основные части: ядро ПО и функциональное ПО.
Ядро ПО представляет собой неизменное базовое ПО, одинаковое для всех компьютеров ИУС. В базовом ПО реализованы функционал приема управляющей информации, базового конфигурирования для применения на разных компьютерах и модулях, служба времени, служба диспетчеризации компонентов ПО, формирование телеметрических массивов, обеспечение функционального ПО имеющимся набором интерфейсов. Функциональное ПО представляет собой уникальное программное обеспечение и используется для непосредственного управления и контроля каждой полезной нагрузки. Функциональное ПО разрабатывается индивидуально для каждой конкретной полезной нагрузки, учитывает специфику ее функционирования и принципы управления.
Другими словами, базовое ПО создано безотносительно к специфике управления конкретными полезными нагрузками, а вся реализация определенного космического эксперимента сосредоточена непосредственно в функциональном ПО, которое отдельно создается для каждой полезной нагрузки. При таком разделении базовое ПО только предоставляет общие интерфейсы — обмен данными по шинам MIL1553, CAN, Ethernet, RS422, маршрутизация данных, прием команд управления, выдача телеметрии и т. п. Эти программные компоненты предоставляют весь необходимый набор функций, которые используются функциональным ПО для управления конкретной, специфической научной аппаратурой.
Наличие для всех компьютеров ИУС РС МКС базового ПО со стандартными интерфейсами значительно упрощает и сокращает сроки его разработки и отработки, а также уменьшает затраты на последующее сопровождение. При этом значительно унифицируются и удешевляются наземные средства, необходимые для его отладки. Структура ПО (см. рис. 1) допускает при установке новой научной аппаратуры на борту РС МКС не создавать новую версию данного ПО. Выбранная архитектура ПО позволяет при этом ограничиться лишь загрузкой необходимого модуля управления новой научной аппаратурой. Отметим, что добавление нового модуля не затрагивает ПО компонентов базового ПО.
Принципы разработки базового ПО. Как уже было указано, базовое ПО одинаково для всех компьютеров ИУС. Для того чтобы удовлетворить всем остальным требованиям к ПО ИУС и учесть при его разработке особенности данной системы, были выбраны следующие основные принципы построения базового ПО:
• компонентный подход;
• как можно более глубокая унификация компонентов;
• унификация взаимодействия между компонентами;
• унификация программ обмена данными;
• обеспечение возможности работы под различными операционными системами путем предоставления разработчикам ПО платформонезависимых механизмов;
• обеспечение возможности гибкой настройки работы компонентов посредством использования конфигурационных файлов;
• использование при разработке ПО имеющихся стандартных библиотек и средств с открытым исходным кодом, таких как stl, boost, gmock, yaml и т. д.
Использование компонентного подхода означает, что базовое ПО разбито на программные компоненты (ПК) по их функциональному назначению. При проектировании базового ПО были стандартизованы и описаны протоколы взаимодействия компонентов друг с другом. Это позволило минимизировать влияние изменений в одном компоненте на другие в случае сохранения неизменного интерфейса взаимодействия между компонентами. Это обстоятельство значительно упрощает процесс отладки ПО, облегчает обнаружение и устранение ошибок.
Структура базового ПО в виде набора основных компонентов, входящих в его состав, приведена на рис. 3.
Ядро ПО ИУС
Г
о с
о о
н »
о S а. о
У
о о
о &
Общесистемное ПО
ГК обмена]
МПВУ j[ ТМ )| Маршрутизация j[ БНО || научными
данными )
v-4
Системное ПО
^ Управление подсистемами и механизмом протоколов
Г
Служба архивов
Служба времени
ПК работы с последовательным портом
ПК работы с файловой системой
Описание подсистем и фабрики ч подсистем
--
ПК обмена (МПЛ553, RS422, Ethernet, CAN)
О С
и о S IS
0
1
■е У
ЗЕ it
31
/ ,
Атомарные | операции
Абстракция от ОС
Потоки Процессы
Мьютексы
Разделяемая память
Драйверы устройств
Операционная система (QNX, Windows)
Внешний абонент
Функциональное ПО ИУС Ethernet
ПКПН1
ПКПН2
ПК ПН
N
CAN
RS422
Обозначения
лтерфейсы кс ядра ПО ИУС
^ ^ Интерфейсы компонентов
ПО для обеспечения работы полезных нагрузок
Стандартные интерфейсы А——|Ч между ядром ПО ИУС N l' и ПО ПН
Полезные нагрузки с различными аппаратно-программными интерфейсами (1553, Ethernet, CAN, RS422)
Рис. 3. Структура базового ПО ИУС PC МКС
Видно, что основой базового ПО является системное ПО, состоящее из диспетчера вычислительного процесса, отвечающего за подключение и запуск необходимых компонентов; службы времени; службы логгирования, предназначенной для сообщения и фиксирования наступления тех или иных событий в системе; службы работы с файловой системой, а также интерфейса, обеспечивающего абстракцию от операционной системы компьютера. Неотъемлемой частью данного интерфейса являются программы обмена по шинам MIL1553, CAN, Ethernet, RS-422.
В качестве надстройки над системным ПО служит общесистемное ПО. В его состав входят: компонент сбора и формирования телеметрии, отвечающий за формирование и передачу телеметрического потока в БКУ; компонент приема и маршрутизации команд управления, предназначенный для передачи команд из БКУ непосредственно полезным нагрузкам; компонент маршрутизации данных от программ обмена, необходимый для обеспечения возможности перенаправления потоков данных с разных интерфейсов в ПК или целевую аппаратуру и обратно; компонент баллистико-навигационного обеспечения, целевой функцией которого является обработка и обеспечение полезных нагрузок данными о параметрах движения МКС, поступающих в ИУС из системы управления движением и навигации; компонент обмена научными данными, который позволяет автоматизировать процесс получения и отправки научных данных от полезных нагрузок на Землю.
Отдельно следует остановиться на интерфейсе, обеспечивающем абстракцию от операционной системы компьютера. Данный интерфейс необходим для облегчения разработки и отладки ПО в связи с тем, что на бортовом компьютере ИУС МКС данное ПО работает под управлением операционной системы реального времени QNX. Процесс же его отработки и отладки в основном происходит на компьютерах под управлением систем семейства Windows. Поэтому базовое ПО должно быть максимально абстрагировано от конкретной операционной системы. В качестве решения данной проблемы создается некоторая абстрактная операционная система [10]. Эта абстрактная операционная система изолирует остальное ПО от синтаксиса и структуры конкретной используемой в данный момент в качестве целевой операционной системы, в качестве которой может служить QNX, VxWorks, ETS, Windows или др. Абстрактная операционная система предоставляет платформонезависимому ПО все интерфейсы для создания и использования разных объектов независимым от используемой операционной системы способом. Этими объектами могут быть потоки или задачи, процессы, механизмы синхронизации, механизмы выделения памяти.
По мере возможности обеспечивается кроссплатформенность ПО. Это позволяет в первую очередь организовать на компьютере каждого разработчика, которые работают в основном под управлением Windows, автоматизированное рабочее место [11], состоящее из всей совокупности бортовых алгоритмов и программ. Для отладки ПО в состав автоматизированного рабочего места также входят программы-модели, имитирующие работу внешних систем, таких как БКУ, аппаратура различных полезных нагрузок, другие компьютеры ИУС.
Для управления и контроля используется ПО выдачи команд управления и дешифровки телеметрической информации. Организованный таким образом процесс разработки ПО позволяет ускорить и упростить процессы компиляции, отладки и отработки разрабатываемых ПК. Дополнительно это открывает возможность создания тренажеров и имитаторов на других аппаратных и программных платформах. Описанная концепция обеспечивает минимизацию затрат на перенос разработанного ПО на другую платформу и максимальное соответствие работы имитатора бортового компьютера поведению реальной аппаратуры.
Как было указано, абстрактная операционная система предоставляет основные базовые сервисы, требуемые от целевой операционной системы, и состоит из набора классов и функций. Абстрактная операционная система предоставляет плат-формонезависимому ПО следующие базовые средства: целый тип, над которым возможны атомарные операции, и сами эти операции, например инкремент; чтение-запись; чтение-сравнение-изменение; локальный и именованный мьютекс; бинарный семафор; разделяемую память; поток; динамическую библиотеку; процесс; высокоточный таймер; некоторые вспомогательные классы.
Данного состава базовых средств достаточно для построения полноценной системы реального времени. Предусматривается расширение набора базовых средств, если необходимо. Поскольку большинство функций — встраиваемые или макросы, в которых делается вызов системной процедуры целевой операционной системы, использование абстрактной операционной системы не привносит ощутимых задержек для системных вызовов.
Аппаратная независимость программ обмена данными достигается путем разделения их на драйвер устройства, являющийся платформо- и аппаратно-зависи-мым, и непосредственно программный компонент обмена, являющийся при этом также платформо- и аппаратно-независи-мым. Программный компонент обмена
использует все интерфейсы базового П°. Рис. 4. Унификация программ обмена Таким образом, в программе обмена данными можно выделить несколько уровней (рис. 4).
Верхним уровнем является программный интерфейс, позволяющий выполнять передачу и прием данных по шине. Вторым уровнем будет уровень реализации профилей обмена, абстракции контроллера шины и оконечного устройства. Третий уровень — низкоуровневая работа с регистрами и памятью платы. Между вторым и третьим уровнем определен четкий протокол, который описывает виртуальное устройство.
Указанный подход позволяет обеспечить гибкость при смене интерфейсов обмена. Например, сохраняя профиль обмена и меняя только драйвер устройства, можно мгновенно перенаправить поток данных в любой другой интерфейс. В каче-
стве другого примера можно отметить, что драйверы работы с шиной Ethernet стандартизованы, а сама шина при этом позволяет подключать компьютер ИУС к любому персональному компьютеру. Следующим примером может служить то, что путем замены драйвера для интерфейса CAN или MIL1553 на драйвер интерфейса Ethernet, можно направить туда весь поток данных, что очень удобно при отладке. Это обеспечивается только заменой одного модуля третьего уровня, который непосредственно реализует указанный протокол.
Задача унификации механизмов взаимодействия между модулями решается путем взаимодействия компонентов только через строго определенный интерфейс. Таким образом, обеспечивается возможность обмена между компонентами, которые могут находиться в разных адресных пространствах или даже на разных компьютерах. Указанный подход к взаимодействию компонентов исключает их излишние взаимозависимости и минимизирует взаимодействия между ними.
Непосредственное управление функционированием компонентов, а именно загрузка, выгрузка, выделение времени процессора, возлагается на единый координационный программный модуль. При унификации механизмов взаимодействия между компонентами были четко определены интерфейсы базовых компонентов. Пользователи базовых компонентов получают только интерфейс приема или передачи данных и не имеют ни малейшего представления о конкретных деталях самого механизма передачи. Для пользователей этих объектов абсолютно неважно, находится ли модуль, с которым они взаимодействуют, в том же процессе или в том же компьютере и какие аппаратные средства задействованы в передаче данных. Это может быть как Ethernet, так и рефлективная память, как шина VME, так и разделяемая память, это может быть и шина 1553. Выбранный подход позволяет легко масштабировать вычислительную систему, например, при нехватке ресурсов на одном компьютере перенести часть модулей в другой компьютер.
Реализация такого взаимодействия между модулями обеспечивается с помощью механизма протоколов. Суть механизма протоколов состоит в том, что при взаимодействии различных компонентов один компонент является сервером, другой клиентом. При этом вполне допускается, что компонент может являться и клиентом и сервером одного и того же протокола.
Сам протокол представляет собой описание и форматы сообщений, которые могут пересылаться между ПК. Все сообщения являются асинхронными, т. е. передающая сторона не ждет, пока принимающая получит и обработает посланное ей сообщение. Каждый протокол имеет некоторое уникальное имя.
Технология работы с протоколами начинается с его описания в текстовом файле. В этом файле описываются типы сообщений, а также направление их передачи (от клиента к серверу или наоборот). Сообщение может иметь некий предопределенный тип, например целое число заданной размерности, число с плавающей точкой, символ, строка символов. Допускается также, что сообщение может иметь тип, заданный пользователем, в том числе динамически создаваемый и имеющий переменную длину.
После описания протокола в текстовом файле этот файл обрабатывается специальной утилитой, формирующей классы, необходимые для посылки и приема сообщений. Эти классы предоставляют высокоуровневый интерфейс, который скрывает все низкоуровневые детали реализации, например поиск процесса, обеспечивающего работу по этому протоколу. От пользователя также скрывается и выбор наиболее оптимальной среды передачи данных, в качестве которой может быть разделяемая память, сеть или использование функционала сообщений операционной системы. Этот выбор осуществляется автоматически в зависимости от взаимного расположения подсистем, при этом в случае смены аппаратной архитектуры может быть предусмотрен переход от формата low-endian к big-endian и обратно либо другие необходимые преобразования данных.
Таким образом, механизм протоколов также имеет трехуровневую структуру (рис. 5).
Рис. 5. Унификация взаимодействия между программными компонентами
В качестве верхнего уровня служит программный интерфейс передачи или приема сообщений, далее идет уровень непосредственно формирования сообщения и, наконец, самым нижним уровнем является транспортный. Как и в случае реализации аппаратной независимости программ обмена данными, здесь также обеспечивается значительная гибкость передачи данных. Если интерфейс взаимодействия между вторым и третьим уровнем строго определен, то простой заменой третьего уровня передачу данных, например через разделяемую память, можно заменить передачей по сети.
Для реализации возможности передачи данных в режиме реального времени или решения иных задач управления, требующих жесткой синхронности работы реализуется механизм диспетчеризации вычислительного процесса. Диспетчер синхронизирует вычислительный процесс на основе заранее определенного на этапе разработки инициализационного файла, в котором прописаны порядок и частотность вызова различных компонентов. Кроме того, диспетчер осуществляет начальную инициализацию вычислительного процесса. Поскольку жесткая привязка к тактам управления бортового компьютера необходима не всем программным компонентам, то некоторые задачи могут и должны выполняться в фоновом режиме. К одной из таких задач относится работа с файловой системой. Синхронизация синхронных и асинхронных задач также является одной из задач диспетчера.
Для настройки вычислительного процесса используются инициализацион-ные файлы. Конфигурационные файлы, в частности, содержат схемы загрузки ПК — в составе одного или разных процессов, настройки драйверов шин обмена, таблицы маршрутизации. Указанные файлы дают возможность гибко менять конфигурацию вычислительного процесса в зависимости от имеющихся ресурсов компьютера. Например, добавление нового потока данных для программы маршрутизации — это всего лишь описание его в конфигурационном файле, без внесения изменения в код компонента. Конфигурационные файлы позволяют менять конфигурацию системы через перезагрузку системы, в процессе же работы вычислительный процесс также может быть сконфигурирован с использованием управляющих воздействий, представляющих собой функции, изменяющие настройки различных компонентов системы. Использование конфигурационного файла позволяет применять одно и то же ПО как при испытаниях на автоматизированном рабочем месте разработчика или наземном комплексе отработки и отладки, так и непосредственно на бортовом компьютере.
Принципы отладки и тестирования ПО ИУС. Задачи отработки, испытаний и сопровождения компьютеров ИУС и их ПО в соответствии с концепцией проектирования ПО в ПАО «РКК «Энергия» являются одним из этапов жизненного цикла их разработки [2]. Для тестирования функциональных возможностей созданного ПО ИУС были спроектированы и разработаны средства наземного комплекса отработки (НКО) компьютеров ИУС. Для отработки взаимодействия компьютеров ИУС и научной аппаратуры используются специально разработанные математические модели научной аппаратуры.
В соответствии с общими принципами создания ПО для систем управления космических аппаратов и жизненным циклом разработки ПО ТВМ1-Н СМ основными этапами отладки и испытания ПО являются:
- автономная отладка и испытания на автоматизированном рабочем месте;
- комплексная отладка и испытания в составе НКО;
- стыковочные испытания ИУС и его ПО с реальной аппаратурой;
- испытания на комплексном испытательном стенде;
- испытания ИУС и его ПО на борту МКС.
Автономная отладка и испытания выполняются разработчиками ПО на своих рабочих местах. Программное обеспечение отлаживается в среде MS Windows. Для имитации научной аппаратуры используются виртуальные машины VMware с ПО научной аппаратуры и математические модели. Основными задачами данного этапа испытаний являются функциональные проверки управления и контроля научной аппаратуры из компьютеров ИУС.
Комплексная отладка и испытания в составе НКО проводятся группой тестирования. Основные задачи данного этапа испытаний — это проверка работы ПО компьютеров ИУС на реальной бортовой аппаратуре; проверка сопряжения между компьютерами ИУС и научной аппаратурой; функциональные проверки ПО компьютеров ИУС, которые невозможно выполнить на этапе автономной отладки.
Объект испытаний — компьютер ИУС и его ПО. Средством испытаний является компьютер управления испытаниями, который контролирует телеметрическую информацию от компьютера ИУС и управляет им. Модели систем и полезных нагрузок (научной аппаратуры) — это компьютер, на котором разработаны программные модели внешних по отношению к компьютеру ИУС систем и полезных нагрузок. Для оценки качества обмена используются анализаторы шин CAN, МКО. На рис. 6 приведена схема верификации ПО на НКО.
НКО бортовой вычислительной системы СМ/МЛМ/НЭМ
БВС Модели систем
НКО информационно-управляющей системы СМ / M JIM / НЭМ
Монитор шины МКО
МКО
Компьютер ИУС
CAN
HUB Ethernet
Монитор шины CAN
Ethernet
Модели систем и полезных нагрузок
Компьютер управления испытаниями (КУИ)
Рис. 6. Структура НКО ИУС
Наземный комплекс отработки ИУС может быть интегрирован с НКО бортовых вычислительных средств разных модулей РС МКС: служебного, многоцелевого лабораторного, научно-энергетического. В зависимости от задач данная принципиальная архитектура НКО применяется к испытаниям компьютеров ИУС каждого модуля МКС в отдельности, их интеграции и комплексным испытаниям.
Испытания на комплексном испытательном стенде — заключительный этап отработки ПО ИУС. Они проводятся для проверки электрических интерфейсов реальных приборов.
Процесс создания новой версии ПО ИУС соответствует заложенным принципам отладки и тестирования. На рис. 7 приведена последовательность этапов при разработке новой версии ПО ИУС.
Разработка новой версии начинается с формирования всех необходимых изменений разработчиками ПО. Для объединения всех изменений в единую версию используется система контроля версий Subversion. Из рис. 7 следует, что после завершения данного этапа непосредственное формирование бинарных исполняемых файлов для бортового компьютера ИУС РС МКС начинается с компиляции под ОС WIN32. Это делается для создания первых версий ПО и их
Рис. 7. Последовательность формирования новой версии ПО ИУС
автономной отладки на автоматизированном рабочем месте. Далее следует компиляция заголовочных (.h) файлов, которые служат для описания управляющих воздействий и телеметрической информации в человекочитаемом виде. Данные заголовочные файлы впоследствии будут использованы при сборке базы данных переменных и управляющих воздействий. Следующим этапом при сборке новой версии ПО является компиляция под QNX 6.5 — операционную систему, которая непосредственно используется на бортовых компьютерах ИУС. Генерация инициализационных (.ini) файлов необходима для создания разных версий ПО, которые могут быть использованы непосредственно в ИУС РС МКС, НКО или в качестве имитатора для отработки ПО целевой аппаратуры. Сборка документации с помощью системы документирования исходных текстов Doxygen необходима для автоматического формирования документации на ПО. Следующий этап — создание базы данных переменных и управляющих воздействий, что служит для формирования управляющей информации и обработки телеметрической и статусной информации ПО ИУС. И, наконец, финальным этапом является создание бинарного архива с образом версии ПО.
Результаты летно-конструкторских испытаний. Практический результат использования нового компьютера c разработанным ПО, доставленного и смонтированного на МКС, заключается в проведении ряда высокотехнологичных научных экспериментов.
В 2013 г. был выполнен эксперимент «Global Transmission Services 2-Даль-ность», целями которого являлось исследование и использование сигналов системы глобального времени с борта МКС для уточнения параметров орбитального движения [6, 7]. Результаты эксперимента применяются при создании наземных систем определения параметров орбитального движения космических аппаратов, использующих беззапросные измерения наклонной дальности и радиальной скорости. Управление и контроль аппаратуры Global Transmission Services осуществлялся с компьютера ТВМ1-Н СМ. Дополнительно компьютер ТВМ1-Н СМ осуществлял обработку баллистико-навигационной информации в необходимый для аппаратуры Global Transmission Services формат.
В 2014 г. совместно с канадской компанией UrtheCast начался эксперимент по дистанционному зондированию Земли с помощью системы оптических телескопов «Напор-МиниРСА» [8, 9, 12]. Система оптических телескопов представляет собой две камеры, установленные на борту РС МКС. Первая камера среднего разрешения устанавливается неподвижно на внешней поверхности СМ по направлению в надир. Камера предназначена для съемки поверхности в режиме «подметания» и получения изображений в виде полос шириной 37,7 и 47,4 км с проекцией пикселя на поверхность Земли 5,4 м (для высоты орбиты 350 км). Вторая камера высокого разрешения устанавливается на двухосную платформу наведения. Данная камера предназначена для видеосъемки участка подстилающей поверхности размером 5,36 х 3,56 км с проекцией пикселя на поверхность Земли 1,15 м (для высоты орбиты 350 км) со скоростью три кадра в секунду (время экспозиции одного кадра 0,3 с). Установка на поворотной платформе позволяет следить за точкой на земной поверхности, небесным телом и снимать видеоизображения выбранного объекта. При реализации данного эксперимента ТВМ1-Н СМ осуществляет наведение двухосной платформы на цели съемки, обеспечивает управление и контроль аппаратуры системы оптических телескопов.
Рассылка из ТВМ1-Н СМ баллистико-навигационной информации по сети Ethernet позволила исключить затраты времени экипажа на ежедневную ручную синхронизацию компьютеров экипажа РС МКС, увеличила точность и оперативность отображения экипажу текущего положения и ориентации МКС.
В процессе проведения экспериментов компьютер ТВМ1-Н СМ зарекомендовал себя как надежное вычислительное средство, предоставляющее широкий набор интерфейсов для подключения научной аппаратуры, а выбранный подход к проектированию ПО позволит интегрировать в него алгоритмы по управлению будущей научной аппаратурой и обеспечит проведение модернизации ИУС.
Следует также отметить, что в настоящее время выполняется наземная подготовка ряда научных экспериментов, проведение которых запланировано на СМ «Звезда» [13]. Среди них космический эксперимент «Терминатор», целью проведения которого является отработка новых методов космического мониторинга состояния средней атмосферы Земли. Объектом измерения в каждый момент времени является рассеянное солнечное и собственное излучение атмосферы в диапазоне высот верхней мезосферы — нижней термосферы в поле зрения блока из четырех фотоприемников. Управление и контроль аппаратуры осуществляется с компьютера ТВМ1-Н СМ.
Заключение. Рассмотрена идеология, заложенная при разработке ПО ИУС РС МКС. Подробно описаны структура, принципы разработки и требования, которые были заложены при создании нового поколения компьютеров существующей системы. На примере реальной работы созданного ПО при проведении на борту МКС некоторых наиболее значимых экспериментов были рассмотрены преимущества принятой концепции разработки.
ЛИТЕРАТУРА
1. Легостаев В.П., Марков А.В., Сорокин И.В. Целевое использование РС МКС: Значимые научные результаты и планы на следующее десятилетие // Космическая техника и технологии. 2013. № 2. С. 3-18.
2. Применение новых информационных технологий для повышения эффективности целевого использования российского сегмента МКС / Е.А. Микрин, А.В. Марков, И.В. Сорокин, С.И. Гусев, Д.Б. Путан, И.В. Дунаева // XXXVI академические чтения по космонавтике. Казань: КГТУ им. А.Н. Туполева, 2012. С. 449-450.
3. Воронин Ф.А., Пахмутов П.А., Сумароков А.В. О модернизации информационно-управляющей системы российского сегмента Международной космической станции // Вестник МГТУ им. Н.Э. Баумана. Сер. Приборостроение. 2017. № 1. C. 109-122.
DOI: 10.18698/0236-3933-2017-1-109-122
4. Воронин Ф.А., Дунаева И.В. Информационно-управляющая система для проведения научных экспериментов на Международной космической станции // Вестник Самарского университета. Аэрокосмическая техника, технологии и машиностроение. 2017. Т. 16. № 1. С. 20-30. DOI: 10.18287/2541-7533-2017-16-1-20-30
URL: http://journals.ssau.ru/index.php/vestnik/article/Yiew/4580
5. Воронин Ф.А. Разработка программного обеспечения информационно-управляющей системы Международной космической станции // Материалы 51-х Научных чтений памяти К.Э. Циолковского. Казань: Эйдос, 2017. 98 с.
6. Сумароков А.В. Об усреднении параметров орбитального движения МКС в космическом эксперименте GTS2 // Материалы XVI конференции молодых ученых «Навигация и управление движением». СПб.: ОАО «Концерн «ЦНИИ «Электроприбор», 2014. С. 334-341.
7. Микрин Е.А., Сумароков А.В., Зубов Н.Е., Рябченко В.Н. К вопросу решения задачи усреднения параметров орбитального движения Международной космической станции в ходе реализации космического эксперимента Global Transmission Services 2 // Вестник МГТУ им. Н.Э. Баумана. Сер. Приборостроение. 2015. № 5. C. 3-17.
DOI: 10.18698/0236-3933-2015-5-3-17
8. Сумароков А.В. Наведение камеры высокого разрешения при видеосъемке поверхности Земли с МКС // Материалы XVII конференции молодых ученых «Навигация и управление движением». СПб.: ОАО «Концерн «ЦНИИ «Электроприбор», 2015. С. 561-568.
9. Сумароков А.В. О наведении камеры высокого разрешения, установленной на борту МКС, посредством двухосной поворотной платформы // Вестник МГТУ им. Н.Э. Баумана. Сер. Приборостроение. 2016. № 4. С. 85-97. DOI: 10.18698/0236-3933-2016-4-85-97
10. Stallings W. Operating systems, internals and design principles. Prentice Hall, 2012. 768 p.
11. Микрин Е.А. Бортовые комплексы управления космическими аппаратами и проектирование их программного обеспечения. М.: Изд-во МГТУ им. Н.Э. Баумана, 2003. 333 с.
12. Тимаков С.Н., Сумароков А.В., Нефедов С.Е., Богданов К.А. Наведение оптической оси телескопа, установленного на поворотной платформе МКС, с учетом упругости конструкции // Материалы конференции «Управление в морских и аэрокосмических системах» (УМАС-2014). СПб.: ОАО «Концерн «ЦНИИ «Электроприбор», 2014. С. 557-566.
13. Воронин Ф.А., Назаров Д.С. Разработка программного обеспечения информационно-управляющей системы Международной космической станции (на примере научных экспериментов «ТЕРМИНАТОР», «МВН», «БТН-М2», «ИПИ-500») // XL Академические чтения по космонавтике. М.: Изд-во МГТУ им. Н.Э. Баумана, 2016. С. 366-367.
Воронин Федор Андреевич — инженер-математик 1-й категории Научно-технического центра ПАО «Ракетно-космическая корпорация «Энергия» им. С.П. Королёва» (Российская Федерация, 141070, г. Королёв, Московская обл., ул. Ленина, д. 4А).
Назаров Дмитрий Сергеевич — техник 1-й категории Научно-технического центра ПАО «Ракетно-космическая корпорация «Энергия» им. С.П. Королёва» (Российская Федерация, 141070, г. Королёв, Московская обл., ул. Ленина, д. 4А).
Пахмутов Павел Александрович — заместитель начальника отдела Научно-технического центра ПАО «Ракетно-космическая корпорация «Энергия» им. С.П. Королёва» (Российская Федерация, 141070, г. Королёв, Московская обл., ул. Ленина, д. 4А).
Сумароков Антон Владимирович — канд. физ.-мат. наук, старший научный сотрудник Научно-технического центра ПАО «Ракетно-космическая корпорация «Энергия» им. С.П. Королёва» (Российская Федерация, 141070, г. Королёв, Московская обл., ул. Ленина, д. 4А).
Просьба ссылаться на эту статью следующим образом:
Воронин Ф.А., Назаров Д.С., Пахмутов П.А., Сумароков А.В. О принципах разработки программного обеспечения информационно-управляющей системы российского сегмента Международной космической станции // Вестник МГТУ им. Н.Э. Баумана. Сер. Приборостроение. 2018. № 2. C. 69-86. DOI: 10.18698/0236-3933-2018-2-69-86
ON PRINCIPLES BEHIND DEVELOPING SOFTWARE FOR THE INFORMATION AND CONTROL SYSTEM OF THE RUSSIAN ORBITAL SEGMENT OF THE INTERNATIONAL SPACE STATION
F.A. Voronin favoronin@gmail.com
D.S. Nazarov oniksor@mail.ru
P.A. Pakhmutov Pavel.Pahmutov@rsce.ru
A.V. Sumarokov avsumarokov@gmail.com
S.P. Korolev Rocket and Space Corporation Energia, Korokv, Moscow Region, Russian Federation
Abstract Keywords
The study deals with the design paradigm behind the software International Space Station, space-constituting the information and control system of the Rus- based experiments, information and sian Orbital Segment of the International Space Station. The control system, onboard computer, information and control system supports conducting various Russian Orbital Segment space-based experiments on board the International Space Station. As the complexity of the experiments both planned and currently carried out increases, onboard computational resources and potential do not meet these demands anymore. We performed a detailed investigation of the structure, design principles and requirements implemented in the development of a new generation of computers for the existing system. We demonstrate the advantages and disadvantages of the development paradigm adopted with the example of software Received 22.06.2017 operation during certain most significant experiments © BMSTU, 2018
The work was carried out with the state financial support of the Russian Foundation for Basic Research (grant no. 17-08-01635, no. 18-08-01379)
REFERENCES
[1] Legostaev V.P., Markov A.V., Sorokin I.V. The ISS Russian segment utilization: research accomplishments and prospects. Kosmicheskaya tekhnika i tekhnologii [Space Technique and Technologies], 2013, no. 2, pp. 3-18 (in Russ.).
[2] Mikrin E.A., Markov A.V., Sorokin I.V., et al. [Application of new information technologies for raising efficiency of ISS Russian segment targeted use]. XXXVI akademicheskie chteniya po kosmonavtike [XXXVI Academic Readings on Cosmonautics]. Kazan, KGTU im. A.N. Tupoleva Publ., 2012, pp. 449-450 (in Russ.).
[3] Voronin F.A., Pakhmutov P.A., Sumarokov A.V. On information-control system modernization introduced in the Russian Segment of International Space Station. Vestn. Mosk. Gos. Tekh. Univ. im. N.E. Baumana, Priborostr. [Herald of the Bauman Moscow State Tech. Univ., Instrum. Eng.], 2017, no. 1, pp. 109-122 (in Russ.). DOI: 10.18698/0236-3933-2017-1-109-122
[4] Voronin F.A., Dunaeva I.V. Information control system for space experiments onboard international space station. Vestnik Samarskogo universiteta. Aerokosmicheskaya tekhnika, tekhnologii i mashinostroenie [Vestnik of Samara University. Aerospace and Mechanical Engineering], 2017, vol. 16, no. 1, pp. 20-30 (in Russ.). DOI: 10.18287/2541-7533-2017-16-1-20-30 Available at: http://journals.ssau.ru/index.php/vestnik/article/view/4580
[5] Voronin F.A. [Software development of management information system of ISS]. Mate-rialy 51 Nauchnykh chteniy pamyati K.E. Tsiolkovskogo [Proc. 51 Scientific Readings in memory of K.E. Tsyolkovsky]. Kazan, Eydos Publ., 2017. 98 p. (in Russ.).
[6] Sumarokov A.V. [On averaging orbital motion parameters of the international space station during conducting the GTS2 space experiment]. Materialy XVI konferentsii molodykh uchenykh «Navigatsiya i upravlenie dvizheniem» [Proc. XVI Conf. of Young Scientists "Navigation and Motion Control"]. Sankt-Petersburg, OAO «Kontsern «TsNII «Elektropribor» Publ., 2014, pp. 334-341 (in Russ.).
[7] Mikrin E.A., Sumarokov A.V., Zubov N.E., Ryabchenko V.N. Problem solution of averaging orbital motion parameters of the international space station during conducting the space experiment Global Transmission Services 2. Vestn. Mosk. Gos. Tekh. Univ. im. N.E. Baumana, Priborostr. [Herald of the Bauman Moscow State Tech. Univ., Instrum. Eng.], 2015, no. 5. C. 3-17 (in Russ.). DOI: 10.18698/0236-3933-2015-5-3-17
[8] Sumarokov A.V. [Pointing of high resolution camera in process of video recording of Earth surface from the International Space Station]. Materialy XVII konferentsii molodykh uchenykh «Navigatsiya i upravlenie dvizheniem» [Proc. XVII Conf. of Young Scientists "Navigation and Motion Control"]. Sankt-Petersburg, OAO «Kontsern «TsNII «Elektropribor», 2015, pp. 561-568 (in Russ.).
[9] Sumarokov A.V. On pointing of high resolution camera mounted on the International Space Station using biaxial rotating platform. Vestn. Mosk. Gos. Tekh. Univ. im. N.E. Baumana, Priborostr. [Herald of the Bauman Moscow State Tech. Univ., Instrum. Eng.], 2016, no. 4, pp. 85-97 (in Russ.). DOI: 10.18698/0236-3933-2016-4-85-97
[10] Stallings W. Operating systems, internals and design principles. Prentice Hall, 2012. 768 p.
[11] Mikrin E.A. Bortovye kompleksy upravleniya kosmicheskimi apparatami i proektirovanie ikh programmnogo obespecheniya [Onboard spacecraft control system and its software design]. Moscow, Bauman MSTU Publ., 2003. 333 p. (in Russ.).
[12] Timakov S.N., Sumarokov A.V., Nefedov S.E., Bogdanov K.A. [Pointing optical axis of telescope mounted on ISS rotating platform taking into account structural elasticity]. Materialy konferentsii «Upravlenie v morskikh i aerokosmicheskikh sistemakh» (UMAS-2014) [Proc. Conf. "Control in marine and space systems"]. Sankt-Petersburg, OAO «Kontsern «TsNII «Elektropribor» Publ., 2014, pp. 557-566 (in Russ.).
[13] Voronin F.A., Nazarov D.S. [Software development of management information system ISS (as exemplified by «TERMINATOR», «MVN», «BTN-M2», «IPI-500» experiments)]. XL Akademicheskie chteniya po kosmonavtike [XL Academic Readings on Cosmonautics]. Moscow, Bauman MSTU Publ., 2016, pp. 366-367 (in Russ.).
Voronin F.A. — mathematician engineer of the 1st rank, Scientific and Technological Centre, S.P. Korolev Rocket and Space Corporation Energia (Lenina ul. 4A, Korolev, Moscow Region, 141070 Russian Federation).
Nazarov D.S. — Technician of the 1st rank, Scientific and Technological Centre, S.P. Korolev Rocket and Space Corporation Energia (Lenina ul. 4A, Korolev, Moscow Region, 141070 Russian Federation).
Pakhmutov P.A. — Deputy Head of Department, Scientific and Technological Centre, S.P. Korolev Rocket and Space Corporation Energia (Lenina ul. 4A, Korolev, Moscow Region 141070 Russian Federation).
Sumarokov A.V. — Cand. Sc. (Phys.-Math.), Senior Research Fellow, Scientific and Technological Centre, S. P. Korolev Rocket and Space Corporation Energia (Lenina ul. 4A, Korolev, Moscow Region, 141070 Russian Federation).
Please cite this article in English as:
Voronin F.A., Nazarov D.S., Pakhmutov P.A., Sumarokov A.V. On Principles Behind Developing Software for the Information and Control System of the Russian Orbital Segment of the International Space Station. Vestn. Mosk. Gos. Tekh. Univ. im. N.E. Baumana, Priborostr. [Herald of the Bauman Moscow State Tech. Univ., Instrum. Eng.], 2018, no. 2, pp. 69-86 (in Russ.). DOI: 10.18698/0236-3933-2018-2-69-86
