Метод «протокол в протоколе», примененный
в ПО отработки подсистем блока
управления перспективных КА
Прудков
Виктор Викторович,
магистр, аспирант Сибирского
государственного аэрокосмического университета им. академика М.Ф. Решетнёва,
инженер-программист ОАО «ИСС» им.
академика М.Ф. Решетнева».
В настоящее время в ОАО «ИСС» им.
академика М.Ф. Решетнева» интенсивность графиков изготовления РЭА современных
космических аппаратов для проведения отработочных испытаний в объёме наземно-экспериментальной
отработки и комплектации штатных изделий исключительно высока. Необходимость
увеличивать эффективность отработки радиоэлектронной аппаратуры (РЭА) и
сокращать ее сроки для вновь создаваемых изделий влечет за собой создание
унифицированных и автоматизированных рабочих мест наземно-экспериментальной
отработки РЭА.
Разрабатываемые на предприятии
блоки управления, входящие в состав бортового комплекса управления (БУ БКУ),
для современных и перспективных космических аппаратов проектируются по
модульному принципу. В состав блока управления входят: центрально-процессорный
модуль (ЦПМ) и интерфейсные модули сопряжения (ИМС или подсистемы). ЦПМ
позволяет реализовать все логические функции конкретной аппаратуры программными
средствами. ИМС осуществляют управления системами КА. Информационно логическая
связь ЦПМ и ИМС осуществляется по последовательному периферийному интерфейсу
(ППИ). Управление БУ осуществляется бортовым центральным вычислительным
комплексом (БЦВК) по мультиплексному каналу обмена (МКО) [1]. ЦПМ
принимает команды управления по МКО от БЦВК, декодирует их, и выдает слова
данных (СД), содержащие команды управления (КУ), в соответствующие подсистемы
БУ (ИМС). Так же БЦВК считывает СД от ЦПМ, содержащие
телеметрическую информацию.
Сейчас срок активного
существования космических аппаратов составляет 10-15 лет, и для его обеспечения,
как одной из задач, является верификация надежности бортовой РЭА, одной из задач
которой является отработка логики функционирования ИМС и ее составляющих. ИМС
аппаратно представляют собой блоки, выполняемые в виде универсального
конструктива. Они выполняют свои специализированные задачи, выполняя
роль связующего звена между БЦВК и системами КА.
В ходе отработки логики
функционирования ИМС должны быть подтверждены заложенные схемные и технические
решения на соответствие техническому заданию (ТЗ). Данный этап называется лабораторно-отработочные
испытания ИМС и заключается в выявлении ошибок при их проектировании, изготовлении,
а так же ошибок в проектах ПЛИС ИМС.
Для реализации этого этапа в отделе
проектирования и разработки бортовой РЭА было создано рабочее место (РМ)
автономной отработки ИМС, приведенное на рисунке 1, на базе лабораторного отработочного
комплекса [2].
Рис. 1.
Рабочее место автономной отработки ИМС.
Рабочее место автономной
отработки ИМС состоит из персонального компьютера (ПК), ЦПМ и подключаемых ИМС.
Для информационного обмена ПК и ЦПМ используется плата производства фирмы «Элкус»
TE1-PCI2, поддерживающая протокол МКО. Для связи ПК и ИМС используется плата
PIO-D186.
Использование ЦПМ в составе
рабочего места позволило:
·
сэкономить
время на разработку аппаратных интерфейсов для управления ИМС от ПК;
·
приблизить управление ИМС к штатному, тем самым дополнительно проверяя
его информационное сопряжение с ЦПМ.
Аппаратная часть такого рабочего места реализует структуру и
устанавливает информационные связи для различных ее элементов. Основным же
инструментом для достижения генеральной цели такой системы, является программное
обеспечение (ПО). Такое ПО должно обеспечивать гибкую
и полную проверку всех логических функций отрабатываемых подсистем, а так же
проводить их отработку в сжатые сроки и с наименьшими трудозатратами.
Большое количество требований предъявляемых к ПО и наличие ограничивающего
фактора, такого как отсутствие единой информационно-логической связи между ПК и
ИМС, предполагают не тривиальное построение ПО.
Написание программной оболочки на ПК не составляет труда, необходимо еще
управлять ПО ЦПМ, которое в свою очередь управляло бы ИМС. Следовательно, чем
больше объем проверок для конкретной ИМС, тем сложнее должно быть ПО ЦПМ, для
реализации этих процедур, которыми в свою очередь должен управлять оператор с
ПК. Данный подход не является гибким и унифицированным, т.к. подразумевает
постоянное наращивание, корректировку и прошивку ПО ЦПМ в зависимости от
возникающих задач в процессе отработки ИМС. Для решения данной проблемы
необходимо создание наиболее гибкого ПО ЦПМ, которое бы не само выполняло какие-то
действия в ходе отработки, а реализовывало бы только транзитную связь данными между
ПК и ИМС, тем самым возложив функцию управления ИМС на ПК, что было бы очень
удобно для оператора. Для этого необходимо было провести анализ протоколов
обмена ПК-ЦПМ и ЦПМ-ИМС, с целью возможности реализации данного варианта.
В ходе анализа протоколов МКО (ПК-ЦПМ) и ППИ (ЦПМ-ИМС) было выявлено,
что можно встроить протокол ППИ в МКО. Т.е. передавать посылки формата ППИ в информационных СД протокола МКО, но с одним ограничением:
количество передаваемых информационных СД по МКО равно 32, по протоколу ППИ не
оговорено, а значит, может быть и больше. Проанализировав количество СД в
посылках для различных подсистем, было выявлено, что их количество не превышает
22 за один обмен, следовательно, данным ограничением можно пренебречь. Таким
образом, можно встроить протокол ППИ в МКО, т.е передавать
в сообщениях формата МКО, уже заданные сообщения в формате ППИ. Данный метод «протокол
в протоколе» позволяет объединить единой информационно-логической связью ПК и
ИМС, путем их общения на уровне формата ППИ.
На основе данного метода был разработан
протокол обмена ПК и ЦПМ, который был реализован в ПО автономной отработки ИМС
[3].
Суть разработанного протокола заключается в следующем: разработчик,
проверяющий ИМС, передает с ПК в ЦПМ сообщения по МКО, составленные в
соответствии с протоколом ППИ (31 СД МКО), и дополнительную информацию обмена
(1 СД МКО – в нем содержатся различные форматы обмена с ИМС). Приняв полученные
сообщения, ЦПМ декодирует их согласно дополнительной информации, т.е. устанавливает
тип обмена и выдает сообщение по ППИ (принятое в сообщении МКО) в ИМС.
Примененный метод «протокол в протоколе» делает протокол МКО «прозрачным» и
позволяет формировать сообщения по ППИ на компьютере. Благодаря применению
данного метода нет необходимости корректировать ПО ЦПМ, достаточно прошить его
один раз и можно использовать для проверки любых ИМС различных изделий. А
оперирование СД ИМС на компьютере позволяет применять различные процедуры
автоматизации на ПК (такие как: генерация тестов, предварительный анализ
тестов, анализ полученных данных и т.д.), с целью сокращения времени отработки
конкретной ИМС.
Таким образом, применение
метода «протокол в протоколе» позволило создать гибкое и унифицированное ПО способное
решать поставленные задачи автономной отработки ИМС.
В настоящее время с помощью разработанного
программного обеспечения, реализующего метод «протокол в протоколе», проведена
автономная отработка ИМС блоков управления космических аппаратов «Муссон»,
«Глонасс-К», а так же оно используется при отработке КА «Луч-5», «Амос-5». В
ходе проведения испытаний была подтверждена правильность выбранного подхода к
построению программного обеспечения и использованию метода «протокол в
протоколе».
Метод «протокол в протоколе» применим
для реализации единой информационно-логической связи двух устройств, не имеющих
прямого сопряжения между собой, путем встраивания одной не прямой информационно-логической
связи в другую, если это предоставляется возможным.
Литература
1. ГОСТ Р
52070-2003. Интерфейс магистральный последовательный. Системы электронных модулей.
2. Пичкалев А. В. Испытания
радиоэлектронной аппаратуры на лабораторном отработочном комплексе / А. В.
Пичкалев // Решетневские чтения: материалы XII Междунар. науч. конф.; Сиб. гос.
аэрокосмич. ун-т. Красноярск, 2008. С. 158-159.
3. Прудков В. В. Особенности построения программного обеспечения автономной отработки подсистем
блока управления перспективных КА / В. В. Прудков // Решетневские
чтения: материалы XIII Междунар. науч. конф.; Сиб. гос. аэрокосмич. ун-т. Красноярск,
2009. С. 531–532.
Поступила
в редакцию 08.11.2010 г.