Космический аппарат (КА) состоит из множества технически сложных систем, каждая из которых включает в себя большое количество электронных приборов. Приборы в свою очередь состоят из электронных компонентов, на которые оказывают влияние неблагоприятные факторы космического пространства. Предусмотреть меры защиты необходимо в процессе изготовления КА, а это требует сил и времени. На заре изготовления КА создание одного изделия занимало порядка 6–9 лет. При этом срок активного существования такого аппарата, т.е. непосредственной эксплуатации по его целевому назначению, составлял 1–3 года. На сегодняшний день ситуация кардинально поменялась. Срок активного существования спутника растет и составляет для современных аппаратов не менее 15 лет, а срок изготовления – 2–3 года. Такие сроки задают заказчики и, чтобы успешно существовать в современных условиях конкурентной гонки, их приходится выдерживать. Практически с каждым новым проектом на спутник возлагаются все новые и новые функции, аппаратура становится сложней и включает в себя все большее количество автономных модулей.
Поэтому существует потребность в системе, которая решит следующие проблемы.
1. Сокращение времени изготовления КА.
2. Повышение качества проводимых работ по изготовлению аппарата.
3. Представление документации, сопровождающей все циклы создания аппарата, в таком виде, чтобы в ней наиболее полно отражалась информация об изделии и специфике его работы и была удобна в использовании как разработчиком аппарата, так и его Заказчиком.
Важной, трудоемкой и довольно длительной частью создания КА являются его испытания. И, в первую очередь, автоматизация должна затронуть этап разработки документации, сопровождающей испытания, этап проведения самих испытаний и этап выпуска отчетной документации по результатам испытаний [4].
Для каждого модуля, прибора или системы приборов существует единая концепция проверок функционирования. Какими бы они разными не были, в любом цикле испытаний можно выделить одни и те же этапы. Получается, что, разработав процедуры испытаний для какого-то одного прибора, можно успешно распространить их на другие. Таким образом, автоматизирован будет процесс испытаний КА в целом.
Этапы этого процесса следующие.
Прежде всего – это определение последовательности операций с объектом испытаний (назовем так прибор или модуль в составе КА, на примере которого будут разрабатываться типовые процедуры испытаний). При описании порядка операций лучше всего руководствоваться рекомендациями разработчика прибора (модуля), но это не говорит о том, что ни в коем случае нельзя отступать от порядка, приемлемого для разработчика. Какие-то отступления всегда возможны. По окончании этого этапа получим глобальный алгоритм испытаний.
Вторым этапом является систематизация перечня инструментов управляющего воздействия на объект испытаний (команд, заданий командно-программной информации). Идентификационные номера команд могут меняться от изделия к изделию, но для этого существует структура запросов в системе управления базой данных команд. Базы данных управляющих воздействий должны содержать в себе следующую информацию: идентификационный номер команды (массива) либо номер функциональной группы команд; наименование; действие; гиперссылка, запускающая малый тест оборудования, и примечание/дополнительная информация.
Третьим этапом будет упорядочивание данных контроля объекта испытаний и правильности его функционирования. Это большой объем значений технических характеристик, значений всевозможных регистров, телеметрических параметров объекта испытаний. Базы данных параметров должны содержать в себе следующую информацию: номер; наименование; прибор (модуль); электрический соединитель; цепь; тип кабеля; значение при нормальных условиях; значение при повышенной температуре; значение при пониженной температуре; дополнительная информация. По необходимости список полей базы может быть расширен. Современный рынок программного обеспечения предлагает большое количество систем управления базами данных и инструментов к ним, позволяющих вносить, хранить и извлекать в нужном порядке любые объемы данных. Разработан ряд языков программирования, которые дают возможность построить гибкую структуру запросов к созданной базе данных.
В-четвертых, необходимо установить логические связи между операциями, определенными на первом этапе, с информацией, характеризующей объект испытаний (третий этап). Т.е. задать условия: в какой момент выполнения действий над объектом какой параметр контролировать и в какой момент выводить результат контроля на монитор оператора.
В-пятых, система должна анализировать полученные значения измерений, значения с телеметрических датчиков и все другие параметры на предмет «норма» и «ненорма». Для этой задачи потребуется база данных, содержащая значения, требуемые в соответствии с Техническим заданием на прибор (модуль), которые прописаны заказчиком аппаратуры (изделия).
В-шестых, для имеющихся точек останова процедуры испытаний (они должны быть проставлены на этапе определения конкретных операций) должны быть директивы (сообщения) для оператора испытаний, предназначенные для сигнализирования о «норме»/«ненорме» параметров объекта испытаний, содержащие краткое заключение о допуске аппаратуры к дальнейшим испытаниям и возможный перечень дальнейших действий оператора.
В-седьмых, все операции должны отражаться в виде документа, описывающего порядок работ, который можно было бы предоставить заказчику и по которому удобно было бы ориентироваться по ходу проведения испытаний.
В-восьмых, необходимо заложить возможность проведения каких-то операций повторно, прописав два варианта: повтор без потери имеющихся данных и повтор с записью новых полученных данных.
Как результат работы автоматизированной системы испытаний логично получить отчетную документацию. В ней должны быть наглядно представлены действия над объектом испытаний, измеренные характеристики аппаратуры и программно сформированные параметры, заключение о допуске, выводы и рекомендации, отчеты по отдельным циклам (процедурам) и итоговый отчет по испытаниям прибора (модуля).
С момента изготовления до сдачи заказчику КА «проживает» этапы наземных и лётных испытаний. Схема жизненного цикла изделия, который нужно автоматизировать, представлен на рисунке.
Таким образом, автоматизированная система должна решить следующие задачи.
1. Автоматизацию разработки процедур испытаний.
2. Оптимизацию процесса испытаний за счет унифицированного набора средств измерений и обработки данных испытаний.
3. Автоматизацию процесса верификации результатов испытаний.
4. Автоматизацию вывода отчетной информации и составления отчетов по испытаниям.
Как уже было сказано, испытания проходят по одинаковому для разных приборов сценарию. Имеется ряд типовых процедур, которые заимствуются с предыдущих изделий, имеющих лишь различные модификации входных данных при изменениях приборов.
Схема испытаний изделия
Для оптимизации процесса испытаний необходимо стремиться к унификации рабочего места испытаний и средств измерений. От изделия к изделию рабочее место будет претерпевать очень незначительные изменения, и унификация существенно сократит время испытаний и уменьшит материальные затраты.
Выработав критерии удачного/неудачного завершения каждого теста, значений норм/ненорм параметров, мы быстро и легко сможем наблюдать результат и реагировать на него.
Отчетная информация подведет итог всех операций над объектом испытаний и даст заключение о допуске прибора к штатной эксплуатации, либо рекомендации по улучшению выполнения его функций.
Приступая к решению задач автоматизации, надо изначально разделить собственно внедрение тех или иных приложений, автоматизирующих конкретные процессы обработки данных [3] и внедрение платформы для подобной автоматизации.
Целью внедрения платформы автоматизации является:
• Удешевление разработки и внедрения конечных приложений.
• Обеспечение удобства пользователя и унификация интерфейса всех приложений.
• Сокращение стоимости эксплуатации и сопровождения комплекса приложений.
• Обеспечение общего информационного пространства, возможности интегрированного поиска и извлечения знаний, накапливаемых в различных приложениях.
• Обеспечение унифицированных средств мониторинга процессов и контроля исполнения.
• Обеспечение возможности сбора статистической и аналитической информации о скорости и своевременности исполнения этапов.
Успех каждой автоматизации тестирования лежит в определении правильного инструмента автоматизации. Для того чтобы сделать окончательный выбор, необходимо провести детальный анализ различных инструментов.
Критерии отбора и выбора инструментов автоматизации [1]:
• Лицензия и стоимость
o Стоимость продукта
o Стоимость поддержки в год
o Стоимость обучения
o (Возможно) Стоимость консультаций
o Тип лицензии (Именованная или параллельная)
o Репутация и финансовая стабильность компании, предоставляющей продукт
•Технические моменты
o Поддержка операционных систем
o Поддержка баз данных
o Интеграция с тестируемой системой
o Необходимость отдельных серверов или же машин
o Совместимость с интеграционными инструментами
o Версионный контроль
o Открытость и расширяемость кода для интеграции с другими инструментами
o Настраиваемые отчеты
• Разработка
o Время и деньги, необходимые на разработку
o Навыки и опыт работы людей, которые будут работать над автоматизацией
o Кодирование и запись/воспроизведение
o Легкость написания тестовых сценариев
o Простота поддержки тестовых сценариев
o Документация.
Существует более 20 технологий проектирования организационно-технических систем и несколько сотен специальных инструментов, предназначенных для автоматизации этого процесса. Существуют также средства моделирования, входящие в состав комплексных систем управления предприятиями (SAP/R3, BAAN, Oracle Application и др.).
При сравнении различных средств моделирования систем целесообразно рассматривать их особенности по следующим группам функциональных возможностей:
• средства построения моделей;
• средства анализа моделей;
• средства оптимизации моделируемых систем по их моделям;
• поддержка библиотек типовых моделей;
• оформление регламентов и документации;
• поддержка разработки моделей баз данных и программных средств;
• интеграция с другими программными продуктами (CASE-средствами, ERP-системами, прикладными программами) [2].
С точки зрения возможностей построения моделей систем обычно учитываются такие свойства средств и методологий моделирования, как:
• универсальность (возможность и способы представления различных аспектов моделируемой системы для разных классов систем);
• открытость (возможность моделирования новых, первоначально не рассматривавшихся сторон системы, учета развития моделируемой системы и т.п.).
Вопрос универсальности средств моделирования требует некоторого уточнения этого понятия. Как отмечалось выше, в практике моделирования основными отображаемыми в моделях сторонами системы являются:
• структурная организация системы
• функции системы и ее составных частей (например, подразделений)
• процессы, протекающие в системе
• распределение ресурсов по процессам
• распределение ответственности за процессы и ресурсы.
Кроме того, на более высоких, концептуальных уровнях представления системы описываются назначения и организационно-управленческие установки системы, такие как миссия, цели, стратегии, политики и другие.
Реализация всех необходимых объектов и свойств системы может осуществляться:
1) либо за счет построения и использования различных типов моделей для отображения разных сторон системы;
2) либо посредством использования одного типа модели, трактовка компонент и связей которой при отображении различных свойств системы будет варьироваться.
Поэтому под универсальностью, видимо, следует понимать именно возможность и способы отображения представлений различных аспектов (срезов) моделируемой системы [5].
В результате исследования разработана структура СУБД, которая позволит легко заносить, хранить и извлекать данные, полученные в процессе электрических испытаний бортового комплекса управления; сформирована гибкая система запросов СУБД, которая подходит для различных КА как коммерческим, так и военного назначения; создана система, которая проделывает анализ информации и формирует заключение о степени соответствия параметров требованиям Технического задания.
Рецензенты:
Шлепкин А.К., д.ф.-м.н., профессор, зав. кафедрой прикладной математики и информационно-компьютерной безопасности, Красноярский государственный университет, г. Красноярск;
Попов А.М., д.ф.-м.н., профессор, директор института информатики и телекоммуникаций, Сибирский государственный аэрокосмический университет имени академика М.Ф. Решетнёва, г. Красноярск.
Работа поступила в редакцию 11.04.2013.