Основной тенденцией в авиастроении в настоящее время является усложнение бортовых программ [1]. Однако многократное усложнение ПО аппаратно-программных комплексов (АПК), к которым можно отнести современную авиационную технику, приводит к увеличению числа ошибок при написании и интеграции ПО, а следовательно, к росту затрат на их разработку и тестирование.

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

Интегрирование ПО различных разработчиков в единую версию тем сложнее, чем больше команд участвует в проекте. Задача выявления проблем несовместимости ПО разных разработчиков и их скорейшего устранения особенно остро стоит при работе со сложными АПК, работающими в реальном времени. Основной путь решения данной проблемы – стандартизация и унификация разрабатываемого ПО, что позволит перейти от творческого программирования к формализованному и четко описанному [2].

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

Многие фирмы создают продукты, направленные на решение узких задач (THALES, ГосНИИАС и др.), не находящих широкого распространения. Информации об алгоритмах, используемых в данных программных продуктах, в открытой печати нет.

Предлагаемый метод относится к средствам автоматизации разработки больших программных комплексов реального времени.

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

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

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

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

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

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

Благодаря ей можно получить обновленную версию ПО с гарантированным отсутствием ошибок неверной обработки (распаковки/запаковки) информации ее потребителями гораздо быстрее, чем при ручном написании программ. Это значительно сокращает время разработки и внесения изменений в ПО. Существует большое число продуктов для автоматической кодогенерации [3, 4], однако использование данных средств при разработке ПО сложных АПК, работающих в реальном времени, сильно ограничено. Так как подобные продукты предназначены для решения широкого круга задач, зачастую вычислительная сложность получаемых программ на порядок выше, чем у приложений, написанных вручную [5]. Этот недостаток незначителен при разработке обычных приложений, однако при необходимости создания комплекса, работающего в режиме реального времени при ограниченности вычислительных ресурсов, его значимость многократно увеличивается. Ручное написание программ существенно увеличивает сроки разработки и стоимость конечного продукта, а также повышает вероятность появления ошибок. Но в случае генерации сравнительно простых функций, осуществляющих интерфейсные обмены, эффективность автоматической генерации бесспорна, особенно ввиду больших объемов кода и возможности их частой модификации. Поэтому целесообразно создать систему автоматизированной разработки программных компонентов управления потоками данных, направленную на решение задачи генерации программ, осуществляющих межмодульные обмены.

Таким образом, наиболее универсальным пред­ставляется построение ПО сложных АПК в виде иерархической структуры, изображенной на рисунке 1.

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

Такое разделение позволяет обеспечить легкую переносимость ФПО в другие разделы, на другой процессорный модуль (в случае многопроцессорной архитектуры) или устройство, обеспечить полную изолированность ФПО от архитектуры АПК и значительно сократить трудозатраты на перепроверку ФПО после внесения изменений.

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

СлПО состоит из двух основных частей:

-      автоматически генерируемых на основе БД интерфейсных функций (средство генерации этих функций далее будем называть препроцессором интерфейсов (ППИ));

-      ручного кода, обеспечивающего управление передачей информации по различным каналам информационного взаимодействия или между задачами (здесь имеются в виду задачи диспетчеризации, управления мезонинными устройствами (карты МКИО, Arinc 429 и т.д.), вызов автоматически сгенерированных функций обмена информацией и т.п.).

В процессе функционирования СлПО выполняет следующие основные функции:

-      старт ПО после подачи питания на устройство;

-      реализация управления в выполняемой программе, загруженной в устройство;

-      реализация потоков данных в многопроцессорной среде между компонентами ФПО и каналами передачи данных, а также между самими компонентами ФПО;

-      управление каналами передачи данных между бортовыми системами;

-      контроль корректности функционирования ПО;

-      реакция на исключительные ситуации, возникающие в процессе работы ФПО, и др.

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

Системное ПО включает в себя операционную систему реального времени (ОСРВ), программу загрузки ФПО, программы тестов встроенного контроля аппаратуры, драйверы управления контроллерами каналов обмена данными с внешними устройствами.

Системное ПО может отличаться составом драйверов и тестов встроенного контроля. В системное ПО устройства включаются только драйверы и тесты, соответствующие составу оборудования данного блока.

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

СКПО (рис. 2) как основной элемент структуры функциональной программы обладает следующими свойствами:

-      является элементом нижнего уровня потока управления выполнением;

-      в программах управления вводом-выводом СлПО каждый СКПО имеет единый интерфейс;

-      является перемещаемым компонентом ФПО в среде многопроцессорной вычислительной системы.

Организация программ СКПО и механизм их подключения к комплексу программ раздела обеспечивают простую и надежную процедуру интеграции программ СКПО.

Программа каждого СКПО содержит локальный диспетчер СКПО, исполнительные модули ФПО, модули входного и выходного интерфейсов СКПО.

Функциональный алгоритм, для выполнения которого предназначен СКПО, реализуется программными функциями исполнительных модулей (модулей ФПО).

Множество исполнительных модулей может быть произвольным и полностью определяться прикладными функциями, которые должен выполнять СКПО. Входной и выходной интерфейсы СКПО определяются в терминах сигналов интерфейса или их составных конструкций (структуры и массивы). Каждому входному сигналу СКПО соответствует входная переменная некоторого исполнительного модуля СКПО, а выходному сигналу – выходная переменная. Сигналы входного и выходного интерфейсов СКПО могут быть как сигналами, передаваемыми между СКПО и каналами связи АПК, так и данными, передаваемыми между различными СКПО.

Входной интерфейс СКПО обеспечивается модулем входного интерфейса СКПО, а выходной – модулем выходного интерфейса.

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

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

Локальный диспетчер выполняет функции СлПО и ФПО, в том числе

-      реализует поток управления внутри СКПО путем вызова программных функций входного и выходного интерфейсов и исполнительных модулей (функция ФПО);

-      отвечает за реакцию на исключительные ситуации в своем СКПО (функция СлПО);

-      обеспечивает связь по управлению с вызывающим его диспетчером (функция СлПО).

Активизация работы СКПО выполняется путем активизации его локального диспетчера с использованием аппарата событий ОСРВ.

Одна из основных целей выбора предлагаемой архитектуры – существенно облегчить процесс интеграции ПО сложных АПК. Основные проблемы при этом связаны с интеграцией потоков данных между компонентами программ и устройствами АПК через каналы передачи данных, а также между самими компонентами программ. Для решения проблемы в данном случае используется автоматическая генерация исходных кодов программ, выполняющих управление потоками данных. При этом генерируется весь комплекс таких программ, что гарантирует корректное управление потоками данных в пределах всего комплекса. Генерируемые компоненты управления потоками данных входят в состав СлПО.

Исходные данные для генерации программных компонентов управления потоками данных находятся в БД ПИВ, в которой хранятся описания этих потоков.

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

-      БД ПИВ устройств АПК и ФПО;

-      систему автоматической генерации исходных кодов программ управления потоками данных ПО (препроцессор интерфейсов);

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

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

БД ПИВ содержит некоторую служебную информацию и информацию, определяющую статические и динамические характеристики таких элементов интерфейса АПК, как

-      все сигналы (параметры) и их характеристики, передаваемые между составными частями АПК, а также между компонентами ФПО;

-      компоненты данных (слова, сообщения и т.д.), передаваемые по каналам связи АПК и содержащие сигналы;

-      каналы связи, по которым происходит передача компонентов данных;

-      абоненты – источники и приемники данных;

-      интерфейсы СКПО в терминах сигналов;

-      распределение СКПО по процессорам (для многопроцессорных систем).

Интерактивные средства взаимодействия пользователей системы с БД позволяют наполнять БД информацией, выполнять контроль целостности и непротиворечивости данных, содержащихся в базе, выдавать из БД информацию об интерфейсах в фиксированных форматах.

Препроцессор интерфейсов предназначен для автоматической генерации описаний элементов системы передачи данных в ПО, а также «С»-программ управления потоками данных ПО. Эти функции выполняются на основе описания потоков данных, находящихся в БДПИВ.

В частности, препроцессор интерфейсов выполняет следующие основные функции.

·       Автоматическое проектирование

-      сети передачи данных между разделами программы в виде множества каналов связи ОСРВ между разделами и соответствующих каналам портами ОСРВ;

-      множества сообщений, передаваемых по этим каналам, с формированием их описаний для дальнейшего использования программами СлПО;

-      множества сообщений, передаваемых по каналам связи с составными частями АПК;

-      множества буферов в ПО для промежуточного хранения передаваемых данных.

·       Генерацию «С»-программ, содержащих описания вышеперечисленных компонентов.

·       Генерацию «С»-программ модулей входного и выходного интерфейсов СКПО, а также некоторых других программных компонентов управления потоками данных ПО.

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

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

Литература

1.      Павлов А.М. Принципы организации бортовых вычислительных систем перспективных летательных аппаратов // Мир компьютерной автоматизации: Встраиваемые компьютерные системы. 2001. Т. 4.

2.      Дейкстра Э. Дисциплина программирования // М.: Мир, 1978.

3.      Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. М.: Финансы и статистика, 1998.

4.      Вендров А.М. Современные технологии создания программного обеспечения: Обзор // Jet Info Online, 2004. № 4.

5.      Бобровский С. Программная инженерия // СПб: Питер, 2003.