Управление разработкой бортового программного обеспечения

В ОАО «Информационные спутниковые системы» имени академика М. Ф. Решетнева используется и развивается эффективная технология создания и сопровождения бортового программного обеспечения (БПО) спутников связи и навигации [1; 2].

Технология основывается на специальном архитектурном расслоении БПО, использовании при разработке и сопровождении БПО интегрированной среды разработки и верификации БПО и на специальных методах гарантирования качества, базирующихся на трех составляющих: качестве компонент БПО, качестве управления конфигурацией БПО, качестве верификации и подтверждения БПО [3].

С использованием этой технологии успешно в заданные сроки с требуемым качеством и в рамках заданных ресурсов создаются спутники связи и навигации, использующие в составе бортовых комплексов управления различные вычислительные платформы.

Многолетний опыт создания серии спутников, таких как ЭКСПРЕС-АМ и ГЛОНАСС-М, позволил выработать эффективную типовую структурную декомпозицию работ по конкретному проекту, представленную на рис. 1 [4].

На рис. 1 выделено три рабочих области: первая область представляет состав работ по созданию и сопро вождению инструментальных средств разработки БПО [3] - технологического комплекса производства программ БПО (ТКПП) и наземного отладочного комплекса БПО (НОК); вторая область представляет собственно работы по созданию БПО спутника с использованием средств ТКПП и НОК. В третьей области представлены работы по отработке и подтверждению ПО отдельных подсистем и БПО в целом на отработочных и летных изделиях подсистем спутника и спутника в целом.

Началом работ по созданию БПО нового спутника считается выпуск исходных данных на логику функционирования космического аппарата (ИД ЛФ КА). После этого головной отдел по разработке БПО совместно с отделами разработчиками ПО подсистем начинает работу по определению требований к БПО в целом, требований к ПО подсистем и по распределению ресурсов бортового комплекса управления между подсистемами. Данная работа выполняется в рамках документа «Исходные данные на БПО» (ИД БПО). Работа выполняется одновременно с разработкой исходных данных на логику функционирования подсистем, но не может быть завершена до их выпуска. Разумеется, во всех случаях выпуска документов речь идет о выпуске редакции документа в том объеме, который не-

Рис. 1. Типовой график разработки БПО: 1 - рабочая область инструментальных средств: 1.1- НОК; 1.2- ТКПП; 2 - рабочая область ЖЦ БПО: 2.1 - компоненты ПО системы; 2.2 - архитектура ПО системы;

2.3 - архитектура БПО; 2.4 - архитектура ПО БКУ; 2.5 - компоненты ПО БКУ; 3 - рабочая область повреждения

о т оз О. О О С $ S ° ® §    1 X М io 8 is § 5- _ pl о S           1

c UD c c b- 0) 03 I 0 Q. О О ” о Cl С = UI c 5 н x co S ! 8 =5 8 ex r c ^ 2 H Ф S и g 3 lg c

Ф V ! o С ф ф ; О ; ° : iSl о х ! а 3 Г It! ► —/ s i 03 5 U ;

с: о 1 с 03 Iе о m S н a g и CL °

ш о

П< В 1 : I! : о : ° 9 г gob: 5s : $ "й о > : 0 Sc: со . о ■ с; ■ из ■ О г: • 5 :

ф о О

о ^ S 2 В to re   M Q.   S

£О gs о

Ш 0) si 58 T U О О ^ m >  ф gm Ф x О i 5s 1 5 8 C S Ф = 3 5 | S^ CL

1 11 S § U3 о О О С с о ^ L 5 О Г: I а =

о ' 88 = 1 Ю ге * 9-5 ГО ш

S          8     - 1 £

1 1 1 1 1 1 1 1 1

0)    ' s       lO 8 5 So hl b S X 8 O s i 1 ” S 8 '^ ^ 1 5 z      ?

1 й-

а 5 5 ; з: ■;

из II S О о

g I---- 5 I

К   4 c m ^ 5 5 ° >8 о я e °-

jl g a §i

с; а S

Л 3 о 10 ГО

е LD ГО X 5 S о а tL ---►

io 2 о ID 5 а

i

из О е = 8 го

CN

oj

(N 04

СО 04

■О 04

LO 04

СО

V-

04

обходим для продолжения работ и информация по которому достигла устойчивого состояния.

После выпуска первой редакции ИД на БПО работы переходят на уровень подсистем. Вначале выполняется архитектурное проектирование ПО подсистем в рамках документов архитектурного проекта на ПО подсистемы, затем выполняется детальное проектирование, программирование и автономное тестирование компонент подсистемы, определенных архитектурным проектом и, наконец, осуществляется системное тестирование ПО подсистемы в целом, сначала в режимах подсистемы, а затем в режимах КА.

Архитектурный проект ПО БКУ дополнительно выступает в качестве документа, интегрирующего БПО в целом.

Проектирование и программирование ПО подсистем осуществляется на базе возможностей, предоставляемых ПО БКУ, поэтому архитектурный проект на ПО БКУ в объеме, определяющем межсистемные интерфейсы, выпускается, как показано на графике, опережающим образом.

По этой же причине создание компонент ПО БКУ разбивается на два этапа: на первом - «Разработка и АО ПО БКУ для КО ПО систем» - создаются компоненты ПО БКУ, без которых невозможны сборка и системное тестирование ПО подсистем, т. е. среда программного функционирования и среда программного управления [3]; на втором - «Разработка и АО ПО БКУ для КО БПО» - компоненты, решающие задачи собственно БКУ, включая средства интегрального управления спутником.

После окончательного определения ЛФ КА и завершения этапов архитектурного проектирования всех подсистем на уровне изделия начинается разработка макропрограмм автономного управления КА, которая должна быть завершена к моменту начала работ по системному тестированию БПО в целом - этап «КО БПО».

Заканчивается деятельность во второй области графика изготовлением БПО, т. е. созданием Выпуска БПО [5], и передачей БПО в состав БКУ изделия.

Поскольку БПО относится к классу встроенного программного обеспечение, то его подтверждение методически осуществляется в рамках соответствующих подсистем и изделия в целом. В технологии создания КА в ОАО «ИСС» для отработки и подтверждения БПО выделено четыре отработочных изделия, работы на которых представлены на графике в его третьей области. При этом лабораторно-отработочный комплекс БКУ (ЛОК) возникает только при создании первого спутника, БКУ которого строится на новой вычислительной платформе. В этом случае требуется тщательная отработка взаимодействия новой общесистемной части ПО БКУ с новыми аппаратными средствами, поэтому во второй области вводится дополнительный этап - «Разработка и АО ПО БКУ для ЛОК», а в третьей - «Отработка ПО БКУ на ЛОК».

Следует отметить следующие зависимости работ второй и третьей области, существенно влияющие на график работ по конкретному проекту

Во-первых, на отработку в составе изделия 1.08БКУ должно поступать ПО БКУ в объеме, созданном на этапе «Разработка и АО ПО БКУ для КО ПО систем», и только после завершения этапа «КО ПО БКУ для КО ПО сис тем». При этом этап «КО ПО БКУ для КО БПО» не может быть завершен до завершения отработки ПО БКУ на изделии 1.08БКУ

Во-вторых, этап «КО БПО» не может быть закончен, а изготовление БПО не может быть начато до отработки ПО СОС на отработочном изделии 01.ИМ.

Рассмотрим теперь зависимость второй области от первой.

На средствах ТКПП БПО осуществляется весь комплекс работ по созданию, автономному тестированию и сопровождению объектов БПО, а также управление этими работами. На средствах НОК осуществляется системное тестирование ПО подсистем и БПО в целом, или, другими словами, их комплексная отладка.

Подготовка ТКПП БПО для изделия, использующего в составе БКУ новую вычислительную платформу, предполагает, во-первых, работы по созданию и/или адаптации для этой платформы всех используемых систем программирования [3], а, во-вторых, поэтапную подготовку архивов объектов для этого проекта.

В случае если средства программирования уже реализованы в ТКПП БПО, его подготовка сводится к подготовке архивов.

Подготовка НОК БПО для изделия, использующего в составе БКУ новую вычислительную платформу предполагает, во-первых, работы по созданию программной модели этой платформы, во-вторых, работы по созданию объектов конкретного изделия: архивов версий БПО, баз данных телеметрических параметров и команд управления, моделей аппаратуры БКУ и моделей поведения подсистем.

В случае если программная модель вычислительной платформы уже была реализована в НОК в рамках работ по предыдущим изделиям, подготовка НОК сводится к поэтапной подготовке объектов изделия: на первом этапе - объектов, необходимых для КО ПО БКУ в объеме, созданном на этапе «Разработка и АО ПО БКУ для КО ПО систем»; на втором - в объеме, необходимом для системного тестирования ПО подсистем и БПО в целом.

При этом комплексная отладка моделей поведения систем на НОК может быть начата не раньше завершения этапа «Подготовка НОК для КО ПО БКУ».

Следует отметить, что модели поведения систем являются частью НОКа только структурно, функционально они являются частью процедур системного тестирования ПО соответствующих подсистем и было бы более логично работы по их созданию рассматривать в рамках второй рабочей области и относить к прямым затратам на разработку БПО. Пересмотр в этом аспекте технологии разработки БПО и типового графика работ запланирован.

Несмотря на то, что представленный на рис. 1 типовой график разработки БПО выглядит как график, реализующий только каскадный подход, на самом деле, на его основе путем соответствующей декомпозиции реализуются и эволюционный, и итерационный подходы.

Для эффективной реализации рассмотренного типового графика работ в реальном производственном процессе разработана модель организационно-распорядительного документооборота, концепция которого представлена на рис. 2 [5; 6].

Суть концепции состоит в том, что типовой график работ покрывается иерархически упорядоченной системой Запросов-Отчетов (ЗАО), определяющих перечень и сроки всех работ. Декомпозиция осуществляется до уровня неразделяемой конкретной работы, выполняемой конкретным исполнителем, на которую выпускается Задание-Заключение (ЗАЗ). ЗАЗ определяет не только состав работы и сроки ее выполнения, но и создаваемый в рамках этой работы объект и затраченные на его создание ресурсы (измеряемые в человеко-часах). Таким образом, информация о состоянии совокупности ЗАЗ дает полную информацию о состоянии работ по соответствующему ЗАО.

Рис. 2. Модель организационно-распорядительного документооборота: ЗАО - запрос-отчет;

ЗАЗ - задание-заключение; ОПР - отчет о проблеме; ОШП - ошибка в программе; ИТР - изменение требований;

АП - архитектурный проект; ИД - исходные данные

Вначале создается ЗАО на создание БПО в целом, объектом разработки в этом случае является Выпуск БПО, работами - создание ПО подсистем, КО БПО и изготовление БПО. На следующем уровне создаются ЗАО на создание ПО подсистем, конечным объектом разработки в этом случае выступают Сборки ПО подсистем, а работами - архитектурное проектирование, разработка и АО компонент, сборка ПО подсистем и КО подсистем на НОК и так далее до уровня неделимых работ, как, например, работа по разработке и АО конкретной компоненты, или работа по выполнению конкретной сборки ПО подсистемы, на которые оформляются ЗАЗы (рис. 2).

Все выявляемые в процессе работ несоответствия по объектам и работам, завершенным в рамках ранее выданных и закрытых ЗАО, парируются Отчетами о проблемах (ОПР), которые в общем случае либо порождают новый ЗАЗ непосредственно - в случае квалификации несоответствия как ошибки в ранее выполненной работе, либо через выпуск нового ЗАО - в случае изменения требований к ранее созданному объекту.

Модель построена на основе прототипов ее отдельных составляющих, успешно апробированных в рамках работ по разработке ПО БКУ в более чем десяти проектах спутников, в том числе в проектах СЕСАТ, ЭКСПРЕССАМ и ГЛОНАСС-М.

Для ее поддержки был разработан и успешно апробирован в рамках проектов ЭКСПРЕС-АМ и ГЛОНАСС-М прототип системы управления электронным распорядительным документооборотом - система управления объектами, работами и проблемами - СОКРАТ [7; 8].

Для внедрения модели в процесс разработки БПО в полном объеме необходимо распорядительный документооборот сделать полностью электронным, т. е. обеспечить автоматизированную генерацию всех предусмотренных моделью распорядительных документов, обеспечить автоматическое передвижение электронной распорядительной документации между участниками разработки и архивами, автоматическое формирование и хранение истории документов и контроль их завершенности, а также автоматическое формирование статистической информации о ходе работ по проекту и использовании ресурсов на основе информации из этих документов.

Работы по этому направлению ведутся в рамках работ по совместному проекту НПО ПМ и ИСИ СО РАН в Новосибирске - проект АСПИД (Автоматизированная Система управления Проектами, Изделиями и Документами), направленных на создание высокоэффективной автоматизированной системы управления разработкой и долговременным сопровождением БПО спутников связи и навигации. Начало внедрение электронного документооборота в рамках этой системы запланировано на конец 2009 г.

Реализация этого проекта должна, в том числе, существенно облегчить решение проблем долговременного сопровождения БПО спутников связи и навигации, ставшей особенно актуальной, в связи с существенно возросшими сроками активного существования современных спутников.