CC BY
89
УЦК 62.506
А. Н. Антамошкин, О. С. Иноземцева, А. А. Колташев, С. А. Краус
ТЕХНОЛОГИЯ РАЗРАБОТКИ БОРТОВОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: УПРАВЛЕНИЕ РАБОТАМИ И ОББЕКТАМИ
Рассмотрена технология разработки бортового программного обеспечения спутников связи и навигации в аспекте обеспечения эффективного управления его конфигурацией в условиях долговременного сопровождения.
В ФГУП «Научно-производственное объединение прикладной механики имени академика М. Ф. Решетне-ва» (НПО ПМ) создана и развивается эффективная технология разработки и долговременного сопровождения бортового программного обеспечения (БПО) спутников связи и навигации [1; 2]. Эта технология базируется на специальном архитектурном расслоении БПО, использовании при его разработке и сопровождении интегрированной среды разработки и верификации БПО и на специальных методах гарантирования качества, базирующихся на трех составляющих: качестве компонентов БПО, качестве управления конфигурацией БПО и качестве верификации и подтверждения БПО [3].
Одной из важных составляющих этой технологии является рассматриваемая ниже модель управления объектами и работами.
Определение объектов разработки и сопровождения БПО основано на концепции архитектурного расслоения БПО (рис. 1). Эта концепция позволяет выделить типовой набор компонентов, слоев и подсистем БПО, функционально привязав их к подсистемам изделия и структурно объединив набором стандартных интерфейсов и слоев, таких как бортовая среда программного функционирования и среда программного управления [2].
Рис. 1
Слои и стандартные интерфейсы позволяют создавать унифицированные компоненты БПО, обеспечивая его переносимость на новые вычислительные платформы и другие изделия, а так же возможность простой модификации БПО при эксплуатации.
Привязка к подсистемам спутника позволяет четко определить требования к программному обеспечению (ПО), ответственность за архитектурное проектирование, системное тестирование и подтверждение БПО, что должно обеспечить прозрачную и эффективную организацию работ и определение типов объектов разработки.
При проектировании и разработке БПО выделяется три уровня (типа) конфигурационных единиц: компонент ПО подсистемы спутника, сборка ПО подсистемы и выпуск БПО [4; 5].
Исходя из структурной декомпозиции БПО (см. рис. 1) при его разработке и сопровождении в модели управления объектами и работами (рис. 2) выделено девять разновидностей объектов:
- проект программы ПО подсистемы;
- проект БПО;
- проект ПО подсистемы;
- проект макропрограмм интегрального управления;
- проект блоков команд управления ПО подсистемы;
- проект входных данных (ВЦ) ПО подсистемы;
- сборка ПО подсистемы изделия;
- сборка БПО изделия;
- выпуск БПО изделия.
Каждая конфигурационная единица БПО представлена в виде программного проекта - электронной папки специальной структуры с именем, отражающим версию объекта, и содержащей всю информацию, необходимую для разработки и сопровождения объекта данного типа.
Компонент ПО подсистемы содержит документацию, исходные модули программы, пакеты для проведения автономной отладки (АО) программы, результаты отладки и результаты работы системы измерения и другие файлы, необходимые для разработки или доработки компонента. Компонент разрабатывается в рамках изделия как объект, унифицированный по соглашениям, интерфейсам, языку программирования и библиотекам типов данных, благодаря чему он может быть пригоден к заимствованию на другие изделия. Унифицикация компонентов позволяет идентифицировать их именем, содержащим версию компонента, без ссылки на изделие. Структура компонента ПО системы определяется средствами его разработки, а именно: кросс-системой программирования на языке Модула-2 [ 1; 2 ].
Сборка ПО подсистемы содержит исходные модули программ ПО подсистемы и все необходимое для проведения сборки. Имя сборки ПО подсистемы включает тему, изделие и номер изменения сборки.
Выпуск БПО изделия содержит сборку БПО изделия (она проводится для отработки и включает сборки ПО подсистем и входные данные ПО бортового комплекса управления (БКУ)), массивы КПИ изделия, материалы
прошивки изделия и спецификацию. Имя выпуска включает тему, изделие и номер изменения сборки.
Примеры построения объектов каждого уровня (типа) представлены ниже (рис. 3).
Все конфигурационные единицы создаются и сопровождаются по стандартным сценариям работ, предусматривающим в аспекте управления конфигурацией, пять уровней ответственности:
- за идентификацию, состав и согласованность БПО конкретного изделия в целом;
- идентификацию, состав и согласованность ПО подсистемы конкретного изделия;
- состав и согласованность проекта компонента;
- состав и целостность сборки ПО подсистемы конкретного изделия;
- состав и целостность выпуска БПО конкретного изделия.
Так, например, сценарий разработки унифицированного компонента БПО предусматривает четыре этапа по уточнению требований к компоненту в процессе его разработки: анализ архитектурного проекта завершен; проектирование завершено; программирование завершено; разработка и автономное тестирование завершены. Эти этапы обеспечивают согласование позиций проектанта ПО подсистемы и разработчика компонента.
Управление работами и объектами обеспечивается тремя подконтрольными электронными архивами: архивом проектов унифицированных программ, архивом изделий БПО и архивом распорядительных документов.
Архив проектов и архив изделий состоят из рабочего и базового архивов, каждый, причем в рабочем архиве хранятся компоненты, находящиеся в стадии разработки, в базовом - компоненты, завершенные и принятые в состав ПО подсистемы или изделия.
Архив распорядительных документов представляет собой множество баз данных специфицированных по темам и изделиям. Каждая база включает полную информацию обо всех объектах, работах и проблемах, возникающих и существующих при разработке любого изделия по всем темам.
Информация об объекте разработки и выполнении типового сценария его разработки хранится в виде задания-заключения (ЗАЗ) на разработку компонента или сборку ПО подсистемы. Информация о работах по созданию или изменению ПО подсистемы сохраняется в виде документа запроса-отчета (ЗАО) на доработку ПО подсистемы. Информация об обнаруженных в процессе эксплуатации компонента проблемах хранится в виде отчета о проблеме (ОПР) в программном обеспечении.
Задание-заключение идентифицируется темой, ПО системы, а также ключевым словом «ЗАЗ» и своим порядковым номером. Оно выпускается на все виды работ, которые указываются в его заголовке:
- на разработку программы или входных данных (в виде одного или нескольких программных модулей, являющихся составной частью архитектурного проекта ПО системы);
- изменение программы;
- сборку ПО системы;
- тестирование ПО подсистемы и т. п.
После выпуска ЗАЗ на разработку программы БПО начинается детальное проектирование и программирование программы одним программистом. ЗАЗ инициирует начало работы над единицей архитектурного проектирования и утверждается по окончанию автономной отладки и передачи модулей программы для включения в состав сборки ПО системы.
Задание-заключение содержит следующую информацию:
- основание для выполнения работы (документ требований, документ архитектурного проекта, ЗАО или ОПР;
- наименования, версии и типы одного или нескольких объектов разработки, содержание их изменения;
- наименование и версию папки проекта программы, которую следует передать в архив программ для хранения после завершения работы;
- наименование, версии и атрибуты объектов, которые следует передать в архив изделий;
- обозначения программных документов, которые нужно выпустить;
- подписи исполнителя и согласующих сторон при инициировании работы;
- сроки разработки по этапам детального проектирования и выпуска документа;
- подписи приемки и согласования этапов работы;
- информацию о трудоемкости этапов работы и работы в целом;
- количественные характеристики создаваемого объекта соответственно его типу;
- подпись, утверждающую ЗАЗ.
Запрос-отчет идентифицируется аналогично ЗАЗ:
темой, ПО системы, ключевым словом «ЗАО» и порядковым номером. ЗАО является документом, инициирующим новый цикл работ в рамках ПО подсистемы, и содержит следующие данные:
- перечень создаваемых или изменяемых объектов;
- основание (уточнение исходных данных, ОПР);
- имена изменяемых компонентов объекта;
- содержание изменения функции объекта или ссылку на такой компонент;
- согласующие подписи о начале работ;
- необходимые этапы работ и их сроки;
- подписи и отметки о выполнении работ;
- утверждающую подпись начальника отдела.
Отчет о проблеме идентифицируется темой, ПО системы, ключевым словом «ОПР» и своим порядковым номером. ОПР выпускается при обнаружении проблемы в программном обеспечении после завершения этапа разработки компонентов ПО подсистем. Инициатором отчета о проблеме может быть любой специалист, обнаруживший проблему в БПО, но подготовка и выпуск ОПР осуществляется ответственным за ПО системы. В процессе рассмотрения проблемы, уточняется источник и причины возникновения проблемы, технологический уровень программирования, проектирования или определения требований, на котором проблема возникла, т. е. класс проблемы, вырабатывается решение по устранению проблемы и улучшению технологии работ.
Отчет о проблеме ОПР содержит:
- ПО системы и версию, в которой обнаружена проблема;
- компонент ПО системы и его версия, в котором обнаружена проблема;
- фамилию инициатора отчета о проблеме и место обнаружения проблемы;
- фамилию ответственного за ПО подсистемы, выпустившего ОПР;
- название проблемы;
- класс (ошибка программиста, изменение требований и т. п.);
- приоритет (критично, обычный порядок и т. п.);
- описание проблемы;
- среда (инструментальные средства или реальные изделия);
- рекомендуемое решение;
- решение совета по рассмотрению ПО;
- даты открытия и закрытия отчета о проблеме;
- ссылки на прилагаемые документы (если есть).
Отчет о проблеме с классом проблемы «Изменение
требований» является основанием для выпуска ЗАО, а ОПР с классом проблемы «Ошибка программиста» -основанием для выпуска ЗАЗ.
Цанные о ЗАЗ, ЗАО, ОПР и разрабатываемых компонентах ПО системы хранятся в базах данных системы управления объектами и работами.
Каждый компонент ПО подсистемы создается на основании ЗАО как объект разработки, специфицированный архитектурным проектом ПО подсистемы в рамках конкретного изделия. После утверждения первой редак-
Проект программы ПО подсиствлы
Ц окумвнт ацил
Описание программы
Программа и методика испытаний
Л сходные модули программы
Л акеты для проведения АТ программы, зезупьтаты отладки и р аб оты системы измерения______________________________
Цругие файлы, необходимые для разработки или ц ор аб отки пр огр аммы
И ИЯ
Имя программы Версия
Изменение
Структура
Л
DOC (документация);
ADD (т х нош отческие исходные модули
для АО);
SRC (исходные модули проекта);
DBG (пакеты отладки, результаты работы
отладчика);
— IZM (результаты работы системы измерения); СМР (б спомогательная директория для
компиляции),
__файлпроекта-,
вспомогательные файлы (для проведения
разработки/доработки)
Пор яд) к работы
Разрабатыв ается по ЗАЗ
Запись ь базовый архив по утверждению ЗАЗ
Сборка ПО подсистемы шдишя
Документации
Исходные модули программ ПО подсистемы
Файпынеобхсдимые для проведениясборки
Имя
Тема ПО подсистемы Изделие Версия
Структура
Л
D О С (документация);
SRC (исх одные модули);
ABS (исполняемые модули, файлы *.тар); СМР (вспомогательная директория для
компиляции);
ф{шлы проектов
__файлы калтоноеки
__калит дные файлы
Пор яд) к работы
Р азр аб атыв ает сл по ЗАЗ
Запись в базовый архив по утверждению ЗАЗ
Рис. 3
Выпуск ЕЕ
Документация
Спецификация
Техш
Z борка БПО изделия
МассивыКПИ изделия
Материалы прошивки БПО
Ф айпы, не о бх о димые для п
Пия
Т ема Имя выпуска БПО
Структура
А
DOC (документа::
PPZY
МКР1_<Имя по денете]
соотве
лніссішн КПИ
Порядок работы
Запись в архив ЗАЗ
ции архитектурного проекта информация о всех компонентах вместе с графиком их разработки заносится в архив сопровождения объектов, работ и проблем этого изделия.
При внесении компонента в этот архив выпускается задание-заключение на разработку компонента ПО подсистемы. Цанное задание фиксирует ответственных за состав и согласованность проекта компонента и предусматривает четыре этапа по уточнению требований к нему в процессе его разработки: анализ архитектурного проекта завершен; проектирование завершено; программирование завершено; разработка и автономное тестирование завершены. Эти требования обеспечивают согласование позиций проектанта ПО подсистемы и разработчика компонента. По завершении этапа разработки и автономного тестирования проект компонента передается в архив унифицированных программ, после чего ошибки в компоненте исправляются на основании отчетов о проблеме в программном обеспечении, а доработка компонента в связи с изменением требований осуществляется по запросам-отчетам, уточняющим требования архитектурного проекта и одновременно определяющим полный цикл работ, требующих повторения.
Разработка компонента заканчивается передачей всей документации сопровождения, оформленной как программный проект, в архив проектов унифицированных программ, а сам компонент, настроенный на конкретное применение, передается в архив изделия в составе сборки ПО подсистемы.
Описанная выше модель управления объектами и работами позволяет не только отражать историю изменения объектов БПО, но и автоматизированно управлять конфигурацией БПО: документировать возникшие проблемы, инициировать работы по их устранению, контролировать завершенность проблем, целостность сборок и выпусков БПО, санкционированность и завершенность всех его изменений.
Модель построена на основе прототипов ее отдельных составляющих, успешно апробированных в более, чем десяти проектах спутников, в том числе в проектах «СЕСАТ», «Экспресс-АМ» и «ГЛОНАСС-М».
В настоящее время данная модель в полном объеме реализуется при выполнении работ по совместному проекту НПО ПМ и Института систем информатики Сибирского отделения Российской академии наук (Новосибирск) - проекту АСПИЦ (автоматизированная система управления проектами, изделиями и документами), направленному на создание высокоэффективной автоматизированной системы управления разработкой и долговременным сопровождением БПО спутников связи и навигации.
В рамках проекта АСПИЦ реализуются электронные архивы сопровождения программных проектов компо-
нентов БПО, архив сборок и выпусков БПО и система управления. Эта система должна автоматизировать процедуры архивации и контроля конфигурации объектов хранения, подготовку сборок и выпусков БПО, включая контроль согласованности компонентов, обеспечивать санкционированный гипертекстовый доступ к объектам хранения, а также доступ к отдельным частям проектов, соответствующих ответственности специалистов, ведение истории изменения архивов, выборку для конкретного изделия согласованных версий проектов программ и автоматизацию выпусков БПО.
При создании АСПИЦ должен быть реализован и электронный документооборот, обеспечивающий передвижение объектов разработки и электронной распорядительной документации между участниками разработки и архивами, хранение истории объектов, возможность контроля завершенности работ и закрытия проблем.
Реализация проекта АСПИЦ должна существенно облегчить решение проблемы долговременного сопровождения БПО спутников связи и навигации, ставшей особенно актуальной в связи с существенно возросшими сроками активного существования современных спутников.
Библиографический список
1. Колташев, А. А. Эффективная технология управления циклом жизни бортового программного обеспечения спутников связи и навигации / А. А. Колташев // Авиа-космич. приборостроение. 2006. № 12. С. 118-124.
2. Колташев, А. А. Технология разработки и сопровождения мобильного программного обеспечения спутников связи / А. А. Колташев // Изв. вузов. Приборостроение. 2004. № 4. С. 56-63.
3. Колташев, А. А. Технологические аспекты создания бортового программного обеспечения спутников связи / А. А. Колташев, А. Н. Антамошкин // Вестн. Сиб. гос. аэрокосмич. ун-та им. акад. М. Ф. Решетнева / Сиб. гос. аэрокосмич. ун-т. Красноярск, 2005. Вып. 6. С. 93-95.
4. Колташев, А. А. Управление конфигурацией бортового программного обеспечения спутников связи и навигации / А. А. Колташев // Решетневские чтения : материалы X Междунар. науч. конф. / Сиб. гос. аэрокосмич. ун-т. Красноярск, 2006. С. 21-22.
5. Управление конфигурацией бортового программного обеспечения спутников связи и навигации в условиях долговременного сопровождения / А. А. Колташев, О. С. Иноземцева, С. А. Краус и др. // Навигационные спутниковые системы, их роль и значение в жизни современного человека : материалы Всерос. науч.-техн. конф. Железногорск, 2007. С. 86-88.
A. N. Antamoshkin, O. S. Inozemtseva, A. A. Koltashev, S. A. Kraus
ON-BOARD SOFTWARE ENGINEERING: OBJECT AND WORK’S MANAGEMENT
Technology of development and maintenance of the on-board software of communication and navigation satellites is considered in aspect of its efficient configuration management by in conditions of long-term maintenance.
