научная статья по теме АВТОМАТИЗАЦИЯ РАЗРАБОТКИ КОМПЛЕКСНЫХ СИСТЕМ ЭЛЕКТРОННОЙ ИНДИКАЦИИ И СИГНАЛИЗАЦИИ ЛЕТАТЕЛЬНЫХ АППАРАТОВ Энергетика

Текст научной статьи на тему «АВТОМАТИЗАЦИЯ РАЗРАБОТКИ КОМПЛЕКСНЫХ СИСТЕМ ЭЛЕКТРОННОЙ ИНДИКАЦИИ И СИГНАЛИЗАЦИИ ЛЕТАТЕЛЬНЫХ АППАРАТОВ»

С 50-летию УлГШУ1

УДК 629.7.066.3

АВТОМАТИЗАЦИЯ РАЗРАБОТКИ КОМПЛЕКСНЫХ СИСТЕМ ЭЛЕКТРОННОЙ ИНДИКАЦИИ И СИГНАЛИЗАЦИИ ЛЕТАТЕЛЬНЫХ АППАРАТОВ

К. В. Ларин, В. В. Шишкин, С. И. Елькин

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

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

1 Окончание тематической подборки статей, посвященной 50-летию Ульяновского государственного технического университета. Начало см. в № 11, 2007.

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

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

Таким образом, для разработки КСЭИС требуемого качества в минимальные сроки нужно создать технологию объектно-ориентированного проек-

тирования (ООП), опирающуюся на комплекс инструментальных средств, поддерживающих не только автоматизацию процесса проектирования, но и параметризацию систем на основе паттернов проектирования.

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

Датчики и Системы • № 12.2007 _ 35

Рис. 1. Структурно-функциональная схема процесса разработки КСЭИС

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

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

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

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

— идентичность по системе координат;

— разрешающая способность плоскости изображения в текущем проекте;

— интерфейс задания примитивов и идентичность представления примитивов в плоскости изображения;

— способ хранения введенных данных;

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

Для подготовки изображений предлагается использовать инструментальный комплекс, включающий в себя СУБД, редактор и транслятор. На технологической схеме данный комплекс входит в блок "Разработка ПО новой системы", и от него требуется:

— вводить, модифицировать, хранить и каталогизировать типовые элементы в их базовом состоянии, синтезируемые объекты и группы с учетом

36

Sensors & Systems • № 12.2007

ь

fi)

s ?

3

§

м

КЗ

о о

N

Файлы типовых программных комплексов

Типовые БД

JБД звуковых сообщений БД типов аппаратуры БД типов систем-источников БД типовых изображений

Графика 2Т> Звуковые сообщения Логическая обработка Предупреждение критических режимов Прием/выдача параметров

Borland С++ Builder

^^ в т. ч. CVS (система управления версиями)

f Сборка, отладка, автономная проверка модулей

(from БД 'новой системы)

«realize»

БД новой системы

5

Разработка БД новой системы

Файлы данных Файлы программного кода Файлы типовых программных комплексов

«document» ТЗ на систему

^ \ Разработка ПО новой системы

Автономная модель

[модель адекватна]

«document» Л ТЗ на ПО

Трансляция и компоновка

<].......... Компоновщики

Б TMS320C3x/4x Code Generation Tools x86 Bcc32/tasm/tlnik

«realize»

Файлы загружаемые в аппаратуру

Библиотеки Исполняемые модули

«document» л

ТЗ на Стенд системы

БД HACK

БД параметров системы Данные аппаратуры HACK Тесты проверок и имитаций

Стендовые испытания

V

«device» Стенд

А

«device» HACK ПК Фрегат

Потоки имитационной информации

Рис. 2. Технологическая схема процесса разработки КСЭИС

со

начальных состояний базовых элементов, а также задавать методы инициализации, обработки и синтеза;

— управлять проектом, содержащим как иерархию характеристик синтезируемого изображения, так и характеристики аппаратуры синтеза и визуализации, и с учетом характеристик аппаратуры сигнализировать программисту о критических местах в данных и методах;

— формировать файлы, содержащие иерархию описания данных в терминах языка программирования, принятого для разработки КСЭИС.

Структуры данных, представляющие собой изображения КСЭИС, представляются набором связанных таблиц в СУБД и доступны редактору, с помощью которого можно визуализировать и модифицировать эти данные. Задача транслятора — представить данные СУБД в виде С-файла иерархического набора данных, образующего управляющий поток синтеза изображения, который описывает:

— элементы изображения в их начальном состоянии в виде набора данных для синтеза и метода визуализации элемента по его данным;

— объединение элементов в объекты, со своим набором данных, методом воздействия на данные элементов и методом обслуживания визуализации элементов;

— объединение объектов в фигуру, со своим набором данных, методом воздействия на данные объектов и методом обслуживания визуализации объектов.

Под набором данных для описания понимаются вершины ребер графа представления объекта, способы их объединения, видимость, цвет, цвет внутреннего пространства и другие методы работы с ними [2].

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

Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.

Показать целиком