САНКТ-ПЕТЕРБУРГСКИЙ НАЦИОНАЛЬНЫЙ

ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ ИНФОРМАЦИОННЫХ

ТЕХНОЛОГИЙ, МЕХАНИКИ И ОПТИКИ

На правах рукописи

Коновалов Павел Викторович

Автоматизация процессов создания бортовой системы

картографической информации и ее компонентов

05.13.12 – Системы автоматизированного проектирования (приборостроение)

Диссертация на соискание ученой степени

кандидата технических наук

Научный руководитель:
д.т.н., доцент
Жаринов Игорь Олегович

Санкт-Петербург – 2015 г.
 2

ОГЛАВЛЕНИЕ

ОГЛАВЛЕНИЕ ........................................................................................................ 2

СПИСОК СОКРАЩЕНИЙ ..................................................................................... 5

ВВЕДЕНИЕ .............................................................................................................. 7

ГЛАВА 1. АНАЛИЗ ПРИНЦИПОВ ПОСТРОЕНИЯ КАРТОГРАФИЧЕСКИХ

ИЗОБРАЖЕНИЙ НА ЭКРАНЕ БОРТОВЫХ СИСТЕМ ИНДИКАЦИИ ........ 14

1.1 Обзор методов и средств генерации геоинформационных ресурсов. ....... 14

1.1.1 Основные виды картографических изображений.................................. 14
1.1.2 Оперативное геоинформационное картографирование ........................ 18

1.2 Виды геоинформационных ресурсов. Принципы декомпозиции

картографических изображений .......................................................................... 20
1.2.1 Модели организации пространственных данных .................................. 22
1.2.2 Принципы организации информации в геоинформационных
системах .............................................................................................................. 24

1.3 Роль и место бортовых систем картографической информации в составе

авиационного комплекса. Режимы работы систем отображения
картографической информации ........................................................................... 27

1.4 Обзор систем автоматизированной генерации геоинформационных

ресурсов. Постановка задачи автоматизации процессов разработки бортовой
системы картографической информации ........................................................... 33
1.4.1 Автоматизация подготовки геоинформационных ресурсов ................ 33
1.4.2 Задача автоматизации разработки и отладки бортовой системы
картографической информации ........................................................................ 39

1.5 Выводы ............................................................................................................. 41

ГЛАВА 2. СПОСОБЫ ПОВЫШЕНИЯ КАЧЕСТВА ПРОЕКТИРОВАНИЯ

БОРТОВЫХ СИСТЕМ КАРТОГРАФИЧЕСКОЙ ИНФОРМАЦИИ ............... 43

2.1 Автоматизированное рабочее место разработчика бортовых систем

картографической информации ........................................................................... 43
2.1.1 Задачи автоматизации проектирования БСКИ ...................................... 43
2.1.2 Состав рабочего места разработчика и назначение основных
компонентов ....................................................................................................... 44
 3

2.2 Унифицированный алгоритм автоматизированного формирования

индикационных кадров ......................................................................................... 47
2.2.1 Анализ сложности и эффективности алгоритмов ................................. 47
2.2.2 Алгоритм автоматизации формирования индикационных кадров. ..... 51

2.3 Оптимизированная структура входных данных для обеспечения

динамических характеристик доступа к геоинформационным ресурсам ....... 59

2.4 Особенности программирования бортовой системы картографической

информации ........................................................................................................... 65
2.4.1 Система адресации бортовой системы картографической
информации ........................................................................................................ 66
2.4.2 Система прерываний, используемая в БСКИ......................................... 68
2.4.3 Система контроля БСКИ .......................................................................... 70

2.5 Выводы ............................................................................................................. 71

ГЛАВА 3. АВТОМАТИЗАЦИЯ СОЗДАНИЯ ТАБЛИЦ КОНФИГУРАЦИИ

БОРТОВЫХ СИСТЕМ КАРТОГРАФИЧЕСКОЙ ИНФОРМАЦИИ ............... 73

3.1 Системное и прикладное программное обеспечение как элемент бортовой

системы картографической информации ........................................................... 73
3.1.1 Архитектура системного программного обеспечения .......................... 74
3.1.2 Особенности структуры системного ПО БСКИ .................................... 77
3.1.3 Особенности подготовки системы к работе ........................................... 80

3.2 Автоматизация создания таблиц конфигурации бортовых систем

картографической информации ........................................................................... 83
3.2.1 Структура конфигурационной информации .......................................... 84
3.2.2 Автоматизированная среда конфигурирования..................................... 86

3.3 Особенности оптимизации проектных решений для эффективного

использования ресурсов аппаратной платформы БСКИ .................................. 91

3.4. Унифицированный протокол взаимодействия рабочей станции с

проектируемым оборудованием .......................................................................... 94
3.4.1 Общая схема взаимодействия платформ ................................................ 95
3.4.2 Универсальный протокол обмена ........................................................... 96
3.4.3 Встроенное алгоритмическое обеспечение целевой платформы ........ 98
3.4.4 Алгоритмическое обеспечение инструментального компьютера ....... 99

3.5 Выводы ........................................................................................................... 101

 4

ГЛАВА 4. АВТОМАТИЗИРОВАННАЯ СИСТЕМА ПРОЕКТИРОВАНИЯ

БОРТОВЫХ СИСТЕМ КАРТОГРАФИЧЕСКОЙ ИНФОРМАЦИИ ............. 103

4.1 Средства автоматизированной отладки ...................................................... 103

4.1.1 Автоматизация обработки отладочной информации .......................... 104
4.1.2 Анализ проектных решений................................................................... 110

4.2. Использование принципа эмуляции аппаратного обеспечения в системе

автоматизированного проектирования ............................................................. 111
4.2.1 Принцип построения программы-эмулятора ....................................... 113
4.2.2 Сравнение программы-эмулятора с существующими аналогами ..... 117
4.2.3 Генерация проектных решений ............................................................. 119
4.2.4 Архитектура программы-эмулятора САПР.......................................... 124
4.2.5 Перспективы развития средств эмуляции аппаратного
обеспечения ...................................................................................................... 128

4.3 Методы автоматизации процесса тестирования бортовых систем

картографической информации ......................................................................... 129
4.3.1 Автоматизация процесса тестирования БСКИ .................................... 129
4.3.1 Автоматизированная проверка результатов тестирования ................ 134

4.4 Автоматизация процесса оформления конструкторской документации

компонентов бортовой системы картографической информации ................. 136

4.5 Выводы ........................................................................................................... 138

ЗАКЛЮЧЕНИЕ ................................................................................................... 139

СПИСОК ЛИТЕРАТУРЫ................................................................................... 140

 5

СПИСОК СОКРАЩЕНИЙ
АНИ – аэронавигационная информация,
АРМ – автоматизированное место разработчика,
БСКИ – бортовая система картографической информации,
ВАП – виртуальное адресное пространство,
ВПИ – внутрипроцессорный интерфейс,
ГИС – геоинформационная система,
МК – микроконтроллер,
ОВД – организация воздушного движения,
ОГК – оперативное геоинформационное картографирование,
ОЗУ – оперативное запоминающее устройство,
ОС – операционная система,
ОСРВ – операционная система реального времени,
ПЗУ – постоянное запоминающее устройство,
ПК – персональный компьютер,
ПО – программное обеспечение,
РМП – рабочее место программиста,
САПР – система автоматизированного проектирования,
СУПБД – система управления пространственной базой данных,
ЦММ – цифровая модель местности,
ЦП – цифровой процессор,
ЭВМ – электронно-вычислительная машина,
AICM – aeronautical information conceptual model,
APEX – application executive,
ARM – advanced RISC machine,
ATPCS – ARM thumb procedure call standard,
DIE – debug information entry,
ELF – executable and linkable format,
ISR – interrupt service routine,
LR – link register,
 6

MIPS – microprocessor without interlocked pipeline stages,

PC – program counter,
PCI – peripheral component interconnect,
RISC – restricted instruction set computer,
SP – stack pointer,
SPARC – scalable processor architecture,
USB – universal serial bus,
XML – extensible markup language.
 7

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

При этом, к разработке БСКИ предъявляются повышенные требования,

поскольку в результате принятия ошибочных проектных решений может быть
спровоцировано возникновение аварийной ситуации. Несмотря на ряд
существующих решений, облегчающих и автоматизирующих процесс
создания бортовых систем картографической информации, задачу
автоматизации разработки нельзя считать решенной в полной мере, что делает
актуальным создание единой системы автоматизированного проектирования,
результатом работы которой станет полный набор инструментов,
необходимых для разработки бортовых картографических систем.
Разработкой автоматизированных средств, решающих задачи
проектирования геоинформационных ресурсов занимается ряд отечественных
фирм, в частности: КБ «Панорама», ЗАО «НПО Центр Электронной
Картографии и Систем автоматизированного проектирования», Санкт-
Петербургское ОКБ «Электроавтоматика». За рубежом подобные средства
проектирования представлены разработками компаний Esri Corporation,
Windriver, Autodesk.
Цель диссертационной работы состоит в создании и исследовании
средств автоматизации проектирования, автоматизирующих процессы
разработки, отладки и тестирования компонентов бортовых систем
картографической информации.
Объектом исследования диссертационной работы является бортовая
система картографической информации, отвечающая за обработку
геоинформационных ресурсов и формирование картографических
изображений в составе бортового навигационного комплекса авионики.
Предметом исследования диссертационной работы являются средства
автоматизированного решения проектных задач разработки, отладки и
тестирования компонентов бортовых систем картографической информации.
Для достижения указанной цели потребовалось решить следующие
основные задачи:
 9

1. Разработать алгоритм автоматизированного формирования

индикационных кадров, используемый в составе бортовой системы
картографической информации.
2. Разработать структуру данных бортовой системы картографической
информации, обеспечивающую скоростной доступ пользователя (пилота) к
геоинформационным ресурсам.
3. Разработать автоматизированное рабочее место для генерации и
исследования проектных решений в области создания компонентов бортовых
систем картографической информации.
4. Разработать новое средство взаимодействия «проектировщик –
система», основанное на принципах программной эмуляции аппаратного
обеспечения.
5. Разработать средства автоматизации взаимодействия
инструментальной ЭВМ с аппаратной платформой бортовой системы
картографической информации.
Методы исследования. В диссертационной работе использовались
теоретические и экспериментальные методы исследования, теория выбора,
методы и алгоритмы автоматизированного проектирования, теория автоматов.
В процессе решения задач диссертационного исследования применялись
методы объектного-ориентированного программирования.
Научная новизна результатов исследования заключается в следующем:
1. Предложена структура данных, повышающая скорость доступа
пользователя к геоинформационным ресурсам в процессе формирования на
борту летательного аппарата индикационных кадров, содержащих
картографическую информацию.
2. Предложен алгоритм автоматизированного формирования
индикационного кадра, основанный на принципе соответствия числа
отображаемых слоёв и наполнении массива геоинформационных данных
текущей полётной ситуации.
 10

3. Предложена схема автоматизированного рабочего места для

создания компонентов бортовых систем картографической информации,
включающая программное, математическое, информационное и
технологическое обеспечение САПР.
4. Предложен набор программных средств, автоматизирующих
процессы подготовки, отладки и тестирования компонентов бортовой системы
картографической информации.
Практическая значимость результатов диссертационного
исследования:
1. Результаты, изложенные в диссертации, могут быть использованы
для решения задачи автоматизации процессов создания БСКИ,
осуществляющих предоставление лётному составу геоинформационной
информации в процессе полета.
2. Предложенные алгоритмы и структуры являются составной частью
программного обеспечения САПР, отвечающего за формирование
индикационных кадров, содержащих геоинформационные данные.
3. Предложенные компоненты САПР являются основой для создания
инструментальных средств автоматизации процессов создания компонентов
БСКИ и их использования на последующих этапах сопровождения системы в
эксплуатации.
Положения, выносимые на защиту:
1. Алгоритм и структура данных, позволяющие автоматизировать
процесс формирования картографических изображений и обеспечить
заданные значения динамических характеристик отображения
индикационных кадров, необходимых для успешного решения задачи
оперативного картографирования в условиях полета летательного аппарата.
2. Автоматизированное рабочее место и универсальный протокол
взаимодействия инструментальной ЭВМ с аппаратной платформой БСКИ,
обеспечивающие процессы генерации и исследования проектных решений в
области создания и тестирования компонентов БСКИ.
 11

3. Система автоматизированного проектирования компонентов

бортовой системы картографической информации, основанная на принципах
программной эмуляции аппаратного обеспечения.
4. Система автоматизированного проектирования для генерации
проектных решений в области создания конфигурационных данных бортовой
системы картографической информации.
Апробация результатов диссертационного исследования. Основные
результаты диссертационной работы докладывались и обсуждались на
различных конференциях, в том числе на: XLII-XLIV научной и учебно-
методической конференции, НИУ ИТМО (2013-2015 г.); XV-XVII
конференции молодых ученых «Навигация и управление движением», Санкт-
Петербург, ОАО «Концерн «ЦНИИ «Электроприбор». (2013-2015 г.); II
Всероссийском конгрессе молодых ученых СПб НИУ ИТМО (2013 г.);
Молодежной научно-практической конференции «Инновации в авиации и
космонавтике-2014», МАИ (2014 г.); XХ Международной научно-
практической конференции студентов, аспирантов и молодых ученых
«Современные техника и технологии», г. Томск (2014 г.); XVIII
Всероссийской научно-практической конференции «Научное творчество
молодежи. Математика и Информатика», г. Анжеро-Судженск (2014 г.); XIII
Международной научно-практической конференции им. А.Ф. Терпугова
«Информационные технологии и математическое моделирование», г. Анжеро-
Судженск (2014 г.).
Публикации. По теме диссертации опубликовано 14 научных работ, в
том числе 4 статьи [19, 50, 64, 65] в журналах, включенных в Перечень
ведущих рецензируемых научных журналов и изданий, в которых должны
быть опубликованы основные научные результаты диссертации на соискание
ученой степени доктора и кандидата наук, 2 статьи [75, 76] опубликованы в
изданиях, отраженных в базе цитирования Scopus, 6 работ [1, 30, 31, 33, 37, 38]
опубликованы в сборниках научных трудов всероссийских, региональных и
международных конференций.
 12

Внедрение результатов. Результаты диссертационной работы

используются в разработках ФГУП «Санкт-Петербургское ОКБ
«Электроавтоматика» им. П.А. Ефимова». В частности, при создании
бортовых систем картографической информации внедрены:
1. Алгоритм автоматизированного формирования индикационных
кадров.
2. Структура данных картографической информации, используемая
для генерации картографических изображений.
3. Автоматизированное рабочее место для исследования свойств и
параметров средств работы с картографической информацией, включающее
программное, информационное и технологическое обеспечение САПР.
Также результаты диссертационной работы используются в учебном
процессе Санкт-Петербургского Национального исследовательского
университета информационных технологий, механики и оптики на кафедре
Машинного проектирования бортовой электронно-вычислительной
аппаратуры (МП БЭВА).
Основные понятия, определения и результаты диссертационного
исследования введены в следующие дисциплины:
1. Методы и средства отображения информации аналого-цифровых
вычислительных комплексов;
2. Автоматизация проектирования аппаратных и программных
компонентов аналого-цифровых вычислительных комплексов.
В данных дисциплинах внедрены следующие результаты диссертации:
1. Средства автоматизации конфигурирования компонентов бортовой
системы картографической информации.
2. Средства эмуляции аппаратного обеспечения и средства
взаимодействия инструментальной ЭВМ с аппаратной платформой БСКИ.
Структура и объем диссертации. Диссертация состоит из введения, 4
глав с выводами, заключения, списка литературы. Общий объем диссертации
составляет 152 страницы, включая 26 рисунков и 3 таблицы. Список
 13

литературы включает 84 наименования. В приложении диссертации

представлены акты внедрения.
 14

ГЛАВА 1. АНАЛИЗ ПРИНЦИПОВ ПОСТРОЕНИЯ

КАРТОГРАФИЧЕСКИХ ИЗОБРАЖЕНИЙ НА ЭКРАНЕ
БОРТОВЫХ СИСТЕМ ИНДИКАЦИИ

1.1 Обзор методов и средств генерации геоинформационных ресурсов.

1.1.1 Основные виды картографических изображений

Картографическое изображение представляет собой условное

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

Карты используются на всех этапах, как при подготовке, так и при

проведении полета. Основные цели использования карт при подготовке:
• прокладка, изучение и корректировка маршрута полета самолета;
• определение географических координат узловых точек маршрута;
• измерение путевых углов и расстояний между узловыми точками;
• изучение рельефа местности и положения высотных строений,
находящихся в районе полета.
Во время совершения перелета необходимость использования карт
возрастает. Решение следующих задач требует использования изображений
местности:
• проведение визуальной и радиолокационной ориентировки;
• контроль над отклонениями от маршрута, корректировка отклонений
и прокладка линий движения;
• определение навигационных ориентиров.
У каждой из карт, используемых в авиации, отличается содержимое.
Содержанием или нагрузкой карты называется степень отображения на ней
различных топографических элементов местности. При составлении карты
играют роль множество параметров, определяющих ее назначение, и, в
зависимости от конечной цели, выбираются масштаб и набор элементов
местности, подлежащих отображению.
На первый план авиационных карт чаще всего выносятся
гидрографические объекты (реки, каналы, водохранилища, озера, моря и т. п.),
поскольку они являются надежными ориентирами [60]. Так же для повышения
точности визуального ориентирования наносятся: рельеф подстилающей
поверхности, дорожные сети, высотные объекты, населенные пункты и др. Для
навигации в процессе проведения полета так же необходимо внести в
содержимое карты места пролегания часто используемых воздушных
маршрутов и иную информацию, формирующую у наблюдателя
представление о загруженности воздушных трасс.
 16

Нанесение на карты топографических элементов осуществляется с

помощью условных знаков, которые делятся на несколько категорий:
• масштабные условные знаки – для отображения элементов местности,
которые можно выразить в текущем масштабе карты: моря, крупные
населенные пункты и т. п.;
• внемасштабные условные знаки – для обозначения топографических
элементов слишком мелких для представления в используемом масштабе:
вышки связи, заводские трубы, мостовые опоры и т. п.;
• линейные условные знаки – для нанесения объектов, не обладающих
достаточной шириной: реки, дорожные сети, газопроводы и т. п. Обычно
линейные знаки используются вне масштаба и дают обозначение только длине
ориентиров;
• пояснительные условные знаки – для дополнительной информации об
объектах местности. Обычно представляют собой надписи и цифры.
Обозначают высоту значимых точек рельефа, названия объектов местности и
т. п.
Многие задачи, возникающие при навигации, требуют хорошего
представления о рельефе местности. Для наглядного представления рельефа
местности на картах используются различные методы [20]:
• метод горизонталей;
• метод отмывки;
• гипсометрический метод;
• комбинированные метод.
Горизонталью называется линия, которая соединяет на отображении
местности точки с одинаковой высотой. Образующиеся замкнутые
концентрические линии дают представление о перепадах высот. Расстояние
между двумя соседними горизонталями дает представление о том, насколько
резко изменяется высота, – чем ближе линии друг к другу, тем больше
крутизна склона.
 17

При использовании способа «отмывки» рельеф отображается оттенением

неровностей поверхности. Результирующее изображение является более
наглядным и дает возможность с легкостью получить представление о
местности и определить положение основных ориентиров. Недостатками
способа являются отсутствие возможностей точного определения крутизны
перепадов и значений высот отдельных точек.
Гипсометрический способ представляет рельеф с помощью заливки
областей определенным цветом в зависимости от их высоты. Таким образом
формируется изображение, дающее наглядное представление об изменениях
рельефа и предоставляющее возможность точного определения высоты в
нужных точках.
В комбинированных способах сочетаются несколько из описанных выше,
при этом происходит компенсирование недостатков и, в результате,
изображение несет повышенную информационную нагрузку в наиболее
удобном для зрительного восприятия виде.
С развитием техники появилась возможность хранения карт в
электронном виде и возможность вывода карт в виде изображения на экране в
кабине летательного аппарата [70]. Цифровые карты обладают рядом
преимуществ перед бумажными:
• повышенная точность представления координат;
• возможность оперативного изменения масштаба;
• возможность динамического изменения информационной нагрузки.
Возможно осуществлять хранение графических отображений местности
в растровом и векторном виде. У обоих способов имеются свои недостатки и
преимущества. В случае с векторными изображениями существенно
уменьшаются затраты ресурсов на хранение и обработку данных. Помимо
этого, векторные карты:
• позволяют с большей легкостью переходить от одного масштаба к
другому;
 18

• дают возможность распределять объекты по слоям в зависимости от

информационной нагрузки;
• не содержат «шумов» изображения.
К недостаткам векторного отображения можно отнести трудоемкость
подготовки и меньшую наглядность по сравнению с растровым [11, 64].
В свою очередь растровые изображения отличают относительная
легкость получения фотографических изображений, повышенная
требовательность к вычислительным ресурсам при обработке и хранении и
сложности масштабирования. Возможно совмещение изображений, которое
позволяет в некоторой степени компенсировать недостатки, однако трудо- и
ресурсоемкость комбинированного способа накладывает ограничения на его
использование.

1.1.2 Оперативное геоинформационное картографирование

Оперативное геоинформационное картографирование (ОГК)

подразумевает под собой формирование и отображение картографической
информации и масштабе реального времени [24]. ОГК преследует цели
быстрого и своевременного информирования пользователя и предоставления
возможностей по изменению состава итогового изображения.
Оперативные карты используются при решении широкого спектра задач,
в том числе в авиации, для оповещения о возникновении неблагоприятных
условий и процессов, наблюдения за развитием ситуации, составления
прогнозов и рекомендаций по минимизации оказываемого влияния.
В качестве исходных данных служат материалы, получаемые из
различных источников: аэрокосмическая съемка, данные приборов, в
некоторых ситуациях – результаты непосредственного наблюдения и т.п.
Эффективность работы системы ОГК определяется следующими
параметрами:
 19

• надежностью автоматизированной системы, отвечающей за

обработку данных. Определяется зависимостью стабильности работы системы
от скорости ввода данных, оперативностью работы с имеющейся базой
данных, быстродействием вычислительных устройств и приборов,
предоставляющих данные;
• наглядностью результирующих карт, их информативностью и
подбором цветовой гаммы, обеспечивающих легкость зрительного восприятия
в условиях повышенной стрессовой нагрузки.
Для отображения динамики процессов современное программное
обеспечение содержит наборы модулей, формирующих всевозможные
варианты последовательного информирования об изменениях в ситуации:
• перемещение картографического изображения по экрану;
• перемещение отдельных элементов содержания (объектов, знаков) по
карте;
• показ изменений отдельных элементов содержания (объектов,
знаков), их размеров, ориентации, мигание знаков, топологические
преобразования и др.;
• варьирование окраски (пульсация и дефилирование), изменение
интенсивности, создание эффекта вибрации цвета;
• изменение освещенности или фона, «подсвечивание» и «затенение»
отдельных участков карты;
• масштабирование изображения или его части, использование эффекта
«наплыва» или удаления объекта.
В составе комплекса бортового оборудования за отображение на экране
пилота навигационных данных отвечает бортовая система картографической
информации (БСКИ) [39]. Получая данные от бортовых приборов,
определяющих текущее местоположение, БСКИ производит расчеты и
формирует изображение, позволяющее определить текущее местоположение
летательного аппарата, определить точность следования заданному маршруту
 20

полета, произвести, при необходимости, корректировку траектории полета.

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

1.2 Виды геоинформационных ресурсов. Принципы декомпозиции

картографических изображений

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

решения задач навигации при подготовке и осуществлении авиационных
перелетов необходимо проведение предварительной обработки. Чаще всего
возникает необходимость проведения векторизации. Векторизацией
называется процесс преобразования первичного изображения (полученного в
результате аэрофотосъемки или съемки со спутника данных) из растрового
формата в векторный [57, 58], более подходящий для использования в
условиях ограниченных вычислительных ресурсов бортового оборудования.
Различают три вида векторизации:
• ручная векторизация по подложке. Для осуществления ручной
векторизации необходимо специальное программное обеспечение (довольно
требовательное к вычислительной мощности рабочей станции). Обработка
представляет собой ручную обводку контуров объектов на выводимом на
экран изображении. Результирующее изображение отличается высокой
точностью, однако затраты (трудовые, временные) на осуществление и
 21

повышенные требования к качеству исходного материала снижают

эффективность применения данного метода;
• интерактивная векторизация по подложке. В отличие от предыдущего
способа, в данном случае значительная часть рутинных операций выполняется
автоматически. Пользователь при работе задает основное направление, после
чего ручная обработка требуется только при возникновении неопределенных
операций. Насколько часто возникают подобные ситуации – напрямую
зависит от качества исходных материалов и сложности рельефа;
• автоматическая векторизация. При использовании данного метода
предполагается минимальное вмешательство со стороны человека. Для
подготовки исходных материалов требуется провести предварительное
устранение шумов и погрешностей сканирования (при переводе в цифровой
формат ранее использовавшихся бумажных карт). После проведения процесса
векторизации возникает необходимость дополнительной ручной обработки
для устранения ошибочных распознаваний. К качеству исходного материала в
данном случае предъявляются повышенные требования. В результате
трудоемкость подобной постобработки может превысить трудоемкость
полностью ручной обработки исходного изображения.
Для повышения удобства при доступе и обработке, все данные,
используемые при отображении навигационной информации, необходимо
хранить в составе четко организованной и структурированной базы данных.
Такая база представляет собой геоинформационный ресурс, состоящий из
набора геопространственных данных [71]. Различные виды
геопространственных данных содержат в себе определенный тип информации
о местности. После подготовки, представляющей собой выборку и
совмещение нескольких слоев, каждый из которых содержит отдельный вид
геопространственных данных, получается итоговое изображение, содержащее
информацию, запрошенную оператором.
 22

1.2.1 Модели организации пространственных данных

Наиболее распространенной моделью, используемой для организации

данных, является слоевая модель [47], показанная на рис.1.1. Существенная
особенность данной модели заключается в разделении объектов на
тематические слои, после чего объекты, относящиеся к одному слою,
формируют часть изображения, несущую в себе определенный вид данных.
После разделения объекты одного слоя хранятся в отдельном файле, имеющем
свою систему идентификаторов. Наличие собственного набора
идентификаторов позволяет обращаться к нужным объектам как к элементам
определенного подмножества. В некоторых случаях слой делится на
несколько частей в горизонтальной плоскости для удобства использования (по
аналогии с отдельными листами карт). Такое разделение повышает удобство
систематизирования базы геопространственных данных и позволяет
уменьшить размер файлов, используемых при дальнейшей обработке.

Рисунок 1.1. Пример слоевой организации данных, N – номер слоя, X –

географическая широта, Y – географическая долгота
 23

В рамках слоевой модели существует две реализации: векторно-

топологическая и векторно-нетопологическая модели.
ID Сегменты
А 1,2
B 1, 3, 4, 5, 6
C 2, 4, 5, 6, 7

A
1 5
C
B
7
3 1
B
C 2
4
A

Рисунок 1.2. Векторно-топологическая модель (пример)

Пример первого варианта реализации – векторно-топологической –

приведен на рис.1.2. Ограничением при использовании такой модели является
невозможность разместить объекты всех геометрических типов в пределах
одного листа тематического слоя. Например, система ARC/INFO позволяет в
одном покрытии поместить только точечные или только линейные, или
полигональные объекты, либо их комбинации, за исключением совмещения
точечных и полигональных, либо всех трех типов вместе.
Векторно-нетопологическая модель является более гибкой моделью
организации данных, однако, чаще всего в один слой помещаются объекты
только одного геометрического типа.
В зависимости от конкретной реализации, число слоев может быть
довольно большим. Удобство слоевой организации заключается в
возможности манипулировать большими группами объектов, находящихся в
составе одного слоя, как одним целым. Например, можно с легкостью
добавлять и исключать слои из итогового изображения, задавать
определенные операции, основанные на межслоевом взаимодействии.
 24

Наряду со слоевой моделью, можно встретить использование объектно-

ориентированной модели [64]. Для представления объектов в данном случае
используется топологическое дерево, определяющее принадлежность
объектов к той или иной категории (топографический классификатор). Пример
топографического классификатора приведен на рис.1.3.
Водоёмы

Искусственные Естественные

Котлованы Водохранилища Озёра Пруды

Для нужд населения Для хозяйственных нужд Неиспользуемые

Рисунок 1.3. Пример топографического классификатора

Акцент в объектно-ориентированной модели смещается на положение

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

1.2.2 Принципы организации информации в геоинформационных

системах

Информация в геоинформационных системах (ГИС) хранится в двух

раздельных базах данных: географической и атрибутивной [46]. Для примера
целесообразно рассмотреть основные принципы, по которым проводится
 25

организация данных в виде векторной модели.

Рисунок 1.4. Пример использования векторной модели для описания

геообъектов

Любой графический объект можно представить в виде набора

графических примитивов с определенными координатами вершин,
исчисляемых в заданной системе координат. В зависимости от ГИС может
различаться набор используемых примитивов, но в любом случае в качестве
базовых используются точка, линия, дуга, полигон. Местоположение
точечного объекта, например, радиовышки, задается парой координат (x, y).
Линейные объекты, такие как реки, трассы, газопроводы и пр., задаются при
помощи набора координат (x1, y2; …; xn, yn). Наконец, площадные объекты
(крупные водоемы, населенные пункты, лесные массивы и т. п.) определяются
замкнутым набором координат (x1, y1; … xn, yn; x1, y1), показанным рис.1.4.
Описание отдельных объектов можно отнести к преимуществам векторной
модели, однако она плохо подходит для отражения непрерывно
изменяющихся параметров.
 26

Помимо информации о координатах местоположения объектов в базе

географических данных возможно сохранение информации о графическом
представлении. Например: толщина, цвет и тип линий, отображающих
линейный объект, цвет и тип штриховки полигонального объекта, толщина,
цвет и тип линий, обозначающих границы полигонального объекта. Для
каждого графического примитива проводится сопоставление атрибутивной
информации, описывающей его качественные и количественные
характеристики. Информация об атрибутах хранится в полях баз данных,
отведенных под хранение различных типов информации: текстовой,
графической, числовой и т. д. Объединение геометрических примитивов и
набора атрибутов представляет собой описание простого объекта.
В современных объектно-ориентированных ГИС работа осуществляется
с классами и семействами объектов, в результате чего пользователь получает
возможность сформировать более полное представление о свойствах объектов
и закономерностях, присущих их поведению [66, 68].
Осуществление взаимосвязи между графическим представлением
объекта и его атрибутами возможно с помощью уникальных идентификаторов
[48]. Такие идентификаторы в том или ином виде присутствуют в любой ГИС.
Многие ГИС представляют пространственную информацию как
отдельные прозрачные слои, содержащие изображения объектов местности.
Объекты распределяются по слоям в зависимости от тех задач, которые
необходимо решить в каждом конкретном случае. Чаще всего информацию,
содержащуюся в каждом отдельном слое, составляют данные, хранящиеся в
пределах одной таблицы базы данных. Иногда разделение производится по
типу графических примитивов, используемых для отображения объектов:
точечные, линейные, площадные. В некоторых случаях слои составляются по
определенным свойствам объектов: слой газопроводов, слой дорожной сети,
слой водных объектов. Практически в любой ГИС у пользователя имеется
возможность управления слоями. Основные свойства, поддающиеся
настройке, – видимость слоя, разрешение на редактирование, доступность для
 27

использования. Помимо этого, имеется возможность повышения

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

1.3 Роль и место бортовых систем картографической информации в

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

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

набор вычислительных блоков, основной задачей которых является хранение
массива картографической информации и синтеза потока двумерного или
трехмерного отображения геоинформационных данных, выводимого на
бортовые средства индикации – многофункциональные цветные индикаторы,
выполняемые на базе плоских жидкокристаллических панелей [20, 21].
Возможность реализации геоинформационных приложений в составе
бортового вычислительного комплекса ограничивает ряд технических
особенностей. Например, базы данных, содержащие геоинформационные
ресурсы, необходимые для решения базовых задач навигации, могут достигать
в размере нескольких гигабайт. Помимо этого, со временем возрастают
требования к детализации цифровых моделей, что в свою очередь влечет за
собой дальнейшее увеличение объемов памяти, необходимых для хранения
геопространственных данных. Так же, ряд целевых задач бортового
оборудования, имеющих повышенную эффективность за счет использования
геоинформационных ресурсов, требуют одновременного выполнения в
режиме реального времени. Часть этих задач может располагаться в
различных блоках бортовой системы. Наконец, функции, занимающиеся
обработкой геопространственных данных, в большинстве случаев
 28

предъявляют серьезные требования к вычислительным ресурсам, в основном

за счет большого объема входных данных, необходимых для выполнения.
Большинство приложений на практике используют один из трех
вариантов системной архитектуры комплексной поддержки бортовых
геоинформационных приложений [16, 18]:
• множество баз геопространственных данных. В данном случае
подразумевается, что в каждом блоке комплекса, использующем
геоинформационные ресурсы, имеется собственная база данных, состав
которой определяется решаемыми задачами;
• централизованная бортовая база геопространственных данных. При
использовании этой схемы в составе комплекса имеется отдельно
реализованная система управления базой пространственных данных
(СУБПД), предоставляющая выборки исходных данных, используемых при
решении целевых задач;
• единый бортовой геоинформационный ресурс. Подразумевает
наличие специализированной бортовой цифровой картографической системы
(БЦКС) в составе комплекса. БЦКС объединяет в себе функции СУБПД и
ГИС, передавая по запросам потребителей данные, представляющие собой
результаты предварительной обработки выборки исходных
геопространственных данных.
В первом случае, несмотря на непосредственную близость взаимного
расположения данных и их потребителей, проявляется большой недостаток,
заключающийся в наличии большого числа точек ввода исходных данных.
Второй вариант ограничивается одной точкой ввода и позволяет улучшить
эксплуатационные свойства системы в целом, однако для реализации его
преимуществ накладываются высокие требования к пропускной способности
каналов обмена данными, поскольку необработанные геопространственные
данные имеют значительный объем. Наконец, третий вариант совмещает в
себе положительные качества первых двух – удобство эксплуатации и
 29

сравнительно небольшой пропускной канал (незначительно больше в

сравнении с требованиями к первому варианту). Таким образом, благодаря
ряду решающих преимуществ большинство современных бортовых
вычислительных систем имеют в своем составе единый геоинформационный
ресурс.
Для более детального рассмотрения архитектуры построения единого
бортового ресурса удобно использовать три уровня абстракции:
• верхний – уровень целевых задач;
• средний – уровень частных задач;
• нижний – уровень задач выборки геопространственных данных.
При использовании многоуровневой архитектуры построения
компоненты нижних уровней предоставляют сервисы, необходимые для
работы верхних уровней, при этом компоненты каждого из уровней не имеют
представления о схеме работы компонентов соседних уровней. Такая
организация говорит о том, что компоненты уровня выборки предоставляют
данные, необходимые для работы компонентам частных задач, а результаты
их работы передаются в качестве исходных данных уровню целевых задач.
В компонентах на уровне целевых задач реализуются функции решения
целевых задач и функции межсистемного обмена сообщениями. Данный
уровень обладает архитектурой клиент-серверного приложения. От
функциональных систем поступают сформированные запросы, после чего в
бортовой картографической системе осуществляется планирование
выполнения запросов в зависимости от очередности поступления и
распределения приоритетов, обусловленного текущими условиями. После
обработки очереди задачи распределяются между компонентами,
отвечающими за их решение, и по готовности результаты отправляются
потребителю.
Использование клиент-серверной архитектуры подразумевает, что обмен
сообщениями происходит в асинхронном режиме, т. е., в случае отсутствия
 30

ответа на запрос, работа клиента продолжается с понижением качества. Обмен

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

производительности и более низких требований к аппаратной части системы

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

данным, для большей части хранимой в базе информации. Таким образом

существенно повышается производительность системы управления базой
данных. Данные же, обновляемые в процессе перелета, имеют настолько
небольшой объем, что их индексирование не отнимает значительного
количества ресурсов.
В составе бортового вычислительного комплекса бортовая система
картографической информации реализована в составе двух блоков: блока
данных и вычислительного блока.
Блок данных обладает небольшими габаритами и предназначен для
установки в кабине пилота либо в оперативном отсеке. Конструкция блока
предусматривает монтирование и оперативную замену носителя базы данных.
Сопряжение с вычислительным блоком осуществляется при помощи
высокопроизводительного последовательного канала. Носитель базы данных
состоит их следующих компонентов:
• адаптер подключения flash-карты;
• процессор, управляющий доступом к базе данных и каналам обмена;
• адаптер каналов обмена с вычислительным блоком.
Вычислительный блок представляет собой вычислительную систему,
построенную по модульному принципу и предполагающую возможность
установки дополнительных модулей с целью увеличения вычислительных
возможностей. В состав блока вычислителей входят следующие модули:
• модуль сопряжения с блоком данных и базовых интерфейсов;
• модуль синтеза графической информации;
• модуль универсального вычислителя.
При возникновении необходимости расширения вычислительных
ресурсов системы для увеличения количества решаемых задач имеется
возможность установки дополнительных универсальных вычислителей.
Целесообразно выполнение сопряжения модулей в составе вычислительной
системы на основе высокоскоростных последовательных каналов. Таким
 33

образом, в состав БСКИ входят специализированный графический модуль и

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

1.4 Обзор систем автоматизированной генерации геоинформационных

ресурсов. Постановка задачи автоматизации процессов разработки
бортовой системы картографической информации

1.4.1 Автоматизация подготовки геоинформационных ресурсов

Решение задач подготовки геоинформационных ресурсов, используемых

в бортовых авиационных системах, в Российской Федерации осуществляет
конструкторское бюро «Панорама».
Используемый при подготовке документов аэронавигационной
информации комплекс КБ Панорама представляет собой набор инструментов
для ведения базы аэронавигационных данных, проектирования маршрутов
вылета подхода и посадки, моделирования аэронавигационной обстановки,
формирования аэронавигационных карт и обмена данными с другими
информационными системами посредством экспорта и импорта в обменном
формате ARINC424-18. В комплекс входят единая база аэронавигационных
данных и инструменты для решения прикладных задач, выполняющие
различные функции по подготовке, моделированию, проектированию и
публикации аэронавигационных данных. Комплекс разработан в соответствии
с требованиями документов ИКАО.
 34

Решение некоторых прикладных задач, таких как «Подготовка

документов аэронавигационной информации» и «Расчет аэродромных
маршрутов», интегрировано в ГИС «Карта 2011», включающую в себя так же
базы данных, рабочие аэронавигационные карты, шаблоны листов сборника
аэронавигационной информации и шаблоны аэронавигационных карт.
Основным источником аэронавигационной информации является
реляционная база аэронавигационных данных, которая создана в соответствии
с моделью AICM (Aeronautical Information Conceptual Model). Модель AICM
рекомендована международной организацией планирования и координации
воздушного движения «Евроконтроль». Структура базы данных позволяет
хранить и обрабатывать все элементы авиационной деятельности. Комплекс
позволяет формировать все виды аэронавигационных карт, тематические
документы, страницы сборников аэронавигационной информации (Air
navigation Information Publication, далее сборник АНИ) на национальном и
международном языках. База данных комплекса и формируемые документы
могут применяться для анализа полетов в районе аэродрома, моделирования
воздушной обстановки, планирования использования воздушного
пространства и управления воздушным движением.
Аэронавигационные карты, формируемые в результате работы
комплекса, находятся в соответствии с документом Doc8697 ИКАО
(«Руководство по аэронавигационным картам»). Аэронавигационные карты,
формируемые в электронном виде, базируются на специальном
аэронавигационном классификаторе dfc.rsc. В зависимости от решаемых
задач, имеется возможность формировать следующие виды
аэронавигационных карт:
• маршрутную карту ИКАО;
• карту района;
• карту стандартного вылета по приборам;
• карту стандартного прибытия по приборам;
 35

• карту захода на посадку по приборам;

• карты визуального захода на посадку;
• карту аэродрома с созданием таблицы метеорологического
минимума;
• карту наземного аэродромного движения и мест стоянок;
• карту местности конечного этапа захода на посадку;
• карту аэродромных препятствий класса «А», «B» и «C».
В соответствии с документами Doc8168 «Правила аэронавигационного
обслуживания. Производство полетов воздушных судов (PANS-OPS) Том II.
«Построение схем визуальных полетов и полетов по приборам» и Doc9371
«Руководство по шаблонам для схемы ожидания, обратной схемы и схемы
типа «ипподром», функция «Расчет аэродромных маршрутов» позволяет
проектировать, моделировать и анализировать следующие виды шаблонов:
• все виды шаблонов вылета по прямой;
• все виды участков прибытия;
• шаблон «ипподром»;
• шаблоны «разворот на посадочную», «разворот 45х180», разворот
«80х260»;
• шаблоны посадки по;
• шаблон ухода на второй круг по прямой;
• шаблона поверхности оценки препятствий.
Прикладная функция «Подготовка документов аэронавигационной
информации» обрабатывает базу данных АНИ, рабочую аэронавигационную
карту и шаблоны для формирования листов сборника АНИ. Дополнительным
источникам информации могут служить данные в обменном формате ARINC.
При работе с базами данных имеется возможность выполнять следующие
операции:
• вводить информацию в базу данных АНИ;
• обновлять информацию на карте из базы данных АНИ;
 36

• экспортировать информацию из базы данных в обменный формат

ARINC;
• экспортировать информацию с карты в формат ARINC;
• импортировать информацию с формата ARINC на карту;
• импортировать и обновлять информацию с формата ARINC в базе
данных;
• экспортировать информацию в листы сборника АНИ;
• формировать внерамочное оформление аэронавигационных карт по
данным из базы данных;
• импортировать списки регистрационных номеров воздушных судов в
файл.
Прикладная функция «Расчет аэродромных маршрутов» отвечает за
создание шаблонов участков маршрутов вылета, подхода и посадки, а также
проводит поверхностный анализ препятствий в районе аэродрома. Каждый
шаблон состоит из проектируемой части участка маршрута, зон оценки
препятствий и буферных зон. Каждый маршрут содержит последовательную
цепочку шаблонов, которые могут совмещаться. Проекты маршрутов
объединяются в схемы с последующим удалением перекрывающихся зон,
входящих в состав шаблона. Схема проходит испытания в соответствии с
требованиями документа Doc8168, утверждается и отмечается в базе данных
как актуальная. Новые маршруты становятся доступными для передачи в
качестве входных данных для функции «подготовка документов
аэронавигационной информации» и могут быть откорректированы и
опубликованы. Подготовка проектировщиком схем осуществляется в
соответствии с программой ИКАО, описанной в документе Doc9906
«Руководство по обеспечению качества при разработке схем полетов Том 2.
Подготовка проектировщиков схем полетов (Разработка программы
подготовки проектировщиков схем полетов)». В результате работы программа
формирует готовые шаблоны всех основных видов участков маршрута вылета,
 37

подхода и посадки, а также защитных схем «ипподром» и разворотов. Шаблон

представляет собой набор объектов карты, в который входит: участок
маршрута, основная зона и ее буфер. В зависимости от типа маршрута и
особенности построения шаблон может не содержать маршрутной части,
буфер (дополнительной зоны) на начальном этапе вылета. Шаблоны могут
содержать дополнительные элементы, например, специальные точки и
защитные линии. Каждый шаблон содержит точку вставки и ось. Точка
вставки и ось включаются в набор для возможности согласования шаблонов
при построении единого маршрута.
Вывод информации осуществляется в формате ARINC, сборник
аэронавигационной информации или на аэронавигационную карту
непосредственно из базы данных. Система ОВД маршрутных карт может
экспортироваться в формат ARINC непосредственно с карты,
сформированной комплексом. Импорт и экспорт маршрутов стандартного
вылета подхода и посадки через формат ARINC осуществляется через базу
данных. Импорт информации по основным точкам, маршрута, аэропортам,
районам и зонам ОВД выполняется напрямую в базу данных или на карту.
Сборник аэронавигационной информации – представляет собой
документ, содержащий аэронавигационную информацию и прочие данные,
используемые для навигации на борту воздушного судна, обслуживания и
управления воздушным движением наземными службами. Сборник состоит из
трех разделов и содержит каталоги аэронавигационной информации,
аэронавигационные карты национальные и региональные правила и
процедуры полетов.
В качестве инструмента подготовки геоинформационных ресурсов может
быть так же рассмотрена группа программных продуктов ArcGIS for Desktop,
предоставляющая весь необходимый инструментарий для полноценной
работы с географической информацией: создания и редактирования данных,
оформления и публикации карт, построения запросов и анализа информации.
Решения ArcGIS for Desktop представляют набор программ с единым
 38

интерфейсом и общими принципами работы, но отличающихся по доступной

функциональности.
Основные функции ArcGis:
1. Пространственный анализ. ArcGIS for Desktop включает сотни
инструментов для проведения пространственного анализа. С их помощью
реализуется возможность использовать имеющиеся данные в качестве
источника для получения новой информации, оптимизировать решение
множества ГИС-задач, таких как:
• расчет плотности и расстояния;
• выполнение статистического анализа;
• анализ наложения (оверлей) и близости.
2. Управление данными. Благодаря поддержке более чем 70 форматов,
комплекс позволяет легко объединять в своем проекте разнородные данные
для отображения и последующего анализа. Инструменты для создания,
организации и управления пространственной, табличной, описательной
информацией предоставляют ряд возможностей:
• поиск географической информации;
• создание, просмотр и управление метаданными;
• оптимизация схем баз геоданных.
3. Картографирование и визуализация. Создание качественной
картографической продукции без необходимости использования
специализированных программ для графического дизайна. В ArcGIS for
Desktop доступны:
• большая библиотека условных обозначений;
• готовые шаблоны карт, легко настраиваемые под ваши задачи;
• коллекция дополнительных элементов для оформления карт.
4. Расширенное редактирование. ArcGIS for Desktop обеспечивает
простое и быстрое создание и редактирование данных. Большое количество
дополнительных инструментов и настроек помогут в решении
специализированных задач, например, при одновременном изменении
 39

нескольких объектов, точных геометрических построениях, обнаружении и

решении конфликтов между объектами. Поддержка многопользовательского
редактирования позволяет настроить рабочий процесс внутри организации,
обеспечить доступ к одним и тем же данным сразу для нескольких отделов.
5. Геокодирование. Использование геокодирования позволяет решать
множество различных задач – от простого анализа данных и обработки
клиентской базы до оптимизации размещения объектов недвижимости и
планирования путей развития бизнеса. После геокодирования адресной базы
имеется возможность отобразить все местоположения на карте, выявить
существующие взаимосвязи и логику пространственного распределения.
6. Картографические проекции. Благодаря поддержке большого числа
географических систем координат и проекций в ArcGIS for Desktop позволяет
объединить в едином проекте данные из разнородных источников.
Встроенные алгоритмы пересчета гарантируют точность при отображении и
редактировании исходных данных, проведении вычислений и анализа,
построении карт.
7. Изображения. ArcGIS for Desktop предоставляет различные варианты
работы с растровыми данными. Они могут выступать в качестве фона
(подложки) для тематических векторных слоев, использоваться в
пространственном анализе, поддерживается дополнительная настройка
отображения наборов растровых данных, создание мозаик.

1.4.2 Задача автоматизации разработки и отладки бортовой

системы картографической информации

Процесс разработки компонентов БСКИ состоит из нескольких этапов:

• создание аппаратного обеспечения;
• написание кода функциональной программы;
• компиляция под целевую аппаратную платформу;
• создание файлов конфигурации;
 40

• отладка системы с записанным в нее ПО.

Каждый из этапов имеет свои особенности и возможности для повышения
удобства и качества процесса автоматизированной разработки.
Написанием программного кода функционального ПО позволяют
заниматься и простейшие текстовые редакторы, но в настоящее время
предпочтительно использование различных инструментов, повышающих
уровень автоматизации процесса. Существуют свободно распространяемые
среды разработки, имеющие широкий набор функций, в том числе подсветку
синтаксиса, средства автозаполнения и предварительной компиляции для
отлавливания мелких ошибок. Однако, возможности разработки
специализированного прикладного ПО в таких средах несколько ограничены
из-за отсутствия интеграции с целевыми аппаратными платформами.
Компиляция готового кода осуществляется средствами предоставляемого
разработчиками аппаратного обеспечения компилятора. В настоящее время
для удобства использования компиляторы встраиваются в единую среду
автоматизированной разработки, тем самым убирая необходимость проводить
компиляцию функционального ПО из командной строки.
Решение задач конфигурации компонентов БСКИ в настоящее время в
большинстве проектов решена на примитивном уровне в виде ручного
редактирования файлов, содержащих таблицы конфигурации. Данный
процесс отличает повышенная трудоемкость, а при отсутствии каких-либо
автоматизированных средств проверки результатов на поиск и исправление
ошибок могут быть затрачены значительные временные ресурсы [45].
Процесс отладки результирующего ПО в составе БСКИ включает в себя
ряд задач: «прогон» готового программного обеспечения в программной среде
его дальнейшего функционирования, проверка соответствия результатов
выполняемых функций исходным требованиям к изделию и т. д.
С целью снижения временных затрат и повышения качества итогового
продукта – бортовой системы картографической информации и ее
 41

компонентов – требуется создание инструментальных средств автоматизации

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

1.5 Выводы

Реализация дальних авиационных перелетов без использования

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

называемой системой индикации. Она отвечает за предоставление экипажу

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

ГЛАВА 2. СПОСОБЫ ПОВЫШЕНИЯ КАЧЕСТВА

ПРОЕКТИРОВАНИЯ БОРТОВЫХ СИСТЕМ КАРТОГРАФИЧЕСКОЙ
ИНФОРМАЦИИ

2.1 Автоматизированное рабочее место разработчика бортовых систем

картографической информации

2.1.1 Задачи автоматизации проектирования БСКИ

Задача разработки средств автоматизации проектирования компонентов

бортовых картографических систем осложняется рядом факторов. Несмотря
на наличие в свободном доступе автоматизированных инструментальных сред
проектирования широкого назначения, обладающим богатым набором
функций, их применение ограничивается отсутствием
узкоспециализированных средств автоматизации [42, 46]. Например, для
контроля процессов выполнения в среде проектирования операционной
системы, управляющей работой БСКИ, помимо исполняемых файлов
программ, требуются файлы данных конфигурации, определяющие набор
физических ресурсов системы, доступных функциональному приложению.
При этом существующие инструментальные решения, позволяющие
автоматизировать процесс создания таблиц конфигурации, либо отсутствуют,
либо предназначены для работы с только одним видом системного
программного обеспечения.
Процессы автоматизированного проектирования компонентов БСКИ
связаны со средой выполнения программного обеспечения. Поскольку
создание программ и аппаратной платформы БСКИ ведется практически
параллельно, несколько групп разработчиков функциональных приложений и
компонентов оказываются в ситуации, когда отсутствует возможность
проверить работу программного кода на аппаратуре, ввиду существования
единственного опытного образца изделия, занятого на испытаниях. Решением
 44

является создание программы-эмулятора, являющейся программным

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

2.1.2 Состав рабочего места разработчика и назначение основных

компонентов

Схема автоматизированного рабочего места (АРМ), позволяющего

создавать, отлаживать и тестировать функциональные приложения и
физические компоненты БСКИ, приведена на рис. 2.1.
Основным программным инструментом АРМ для подготовки проектной
документации является интегрированная среда разработки, позволяющая
создавать и редактировать электронные документы с исходным форматом и
производить их обработку под целевую физическую платформу изделия [10,
17]. Для этой цели может быть использована одна из существующих сред
автоматизированной разработки с возможностью подключения и настройки
сторонних компонентов программного обеспечения АРМ (Microsoft Visual
Studio, NetBeans и т.п.).
Результатом автоматизированных процессов обработки являются
документы в формате бинарных файлов целевой платформы. В одной из
секций данных бинарного файла содержится отладочная информация в
специальном формате. Ввиду того, что приложения бортовых
картографических систем исполняются в специальной программной среде, у
 Среда разработки
Бинарные файлы программного
обеспечения
Редактор кода

Отладочная информация
Разработчик Компилятор

Отладчик Эмулятор

Модуль отладки Среда эмуляции

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

Универсальный протокол
Автоматизированная
Отчет, техническая
проверка результатов
Аппаратное обеспечение документация на проект
тестирования

АРМ работы с изделием

Рисунок 2.1. Схема автоматизированного рабочего места разработчики БСКИ
 46

пользователя отсутствует возможность использования существующих средств

для отладки. Таким образом, одним из компонентов, доступных разработчику
в составе АРМ должно быть программное средство, автоматизирующее
процесс обработки и анализа отладочной информации и передающее
полученную структуру физического устройства инструментальному средству
отладки.
Как упоминалось выше, для обеспечения возможности работы
функциональных программ в среде операционной системы БСКИ необходимо
создать файл данных конфигурации, задающий условия выполнения
функциональных приложений [37]. Целью создания таких файлов данных
служит специализированный инструмент автоматизации – конфигуратор,
представляющих собой интерактивную автоматизированную среду
проектирования с программно реализованным графическим интерфейсом и
возможностью проверки предложенной конфигурации на соответствие ряду
критериев качества проекта, определяемых стандартом на создание данного
вида компонентов авиационных систем.
Дальнейшая работа пользователя с разрабатываемыми компонентами
БСКИ состоит в проверке выполнения, поиске ошибок и тестировании на
соответствие изделия предполагаемым функциям, заданным в техническом
задании. При этом, у разработчика должна быть возможность производить
указанные действия при отсутствии целевой аппаратной платформы. Такую
возможность предоставляет программно реализуемая на инструментальной
ЭВМ среда-эмулятор, основным назначением которой является имитация
вычислительного поведения аппаратуры БСКИ. Дополнительные функции,
подключаемые к эмулятору, позволяют автоматизировать некоторые
процессы проектирования, либо повысить их эффективность по заданным
критериям качества. В частности, модуль отладки, на основе полученной
ранее структуры физического устройства, позволяет пользователю в
интерактивном режиме исследовать процесс работы программного
 47

приложения и следить за соответствием выполняемых машинных инструкций

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

2.2 Унифицированный алгоритм автоматизированного формирования

индикационных кадров

2.2.1 Анализ сложности и эффективности алгоритмов

В процессе решения прикладных задач по проектированию компонентов

БСКИ возникает необходимость осуществлять процедуру выбора наиболее
 48

подходящего алгоритма автоматизированного формирования индикационных

кадров из возникающих вариантов [27, 41]. При этом оптимальность
использования той или иной «конструкции» алгоритма зависит от конкретной
задачи, решаемой проектировщиком в данный момент. От алгоритма
формирования индикационных кадров требуется способность удовлетворять
противоречащим друг другу условиям:
• алгоритм должен быть простым для понимания, перевода в
программный код и отладки;
• алгоритм должен максимально эффективно использовать
вычислительные ресурсы БСКИ вне зависимости от аппаратной платформы и
выполняться по возможности быстро (в сравнении с циклом бортовой задачи).
Приоритетность одного из двух условий определяется особенностью
реализуемой на борту задачи. Если разрабатываемая программа, реализующая
алгоритм, должна выполняться за ограниченное время и сравнительно
небольшое количество раз, то первое требование наиболее важно. В таком
случае стоимость создания управляющей программы оптимизируется по
стоимости написания (а не выполнения) этой программы. Однако в случае,
когда при решении бортовой задачи требуется использование значительных
вычислительных ресурсов БСКИ, стоимость выполнения функциональной
программы может превысить стоимость ее написания, особенно при
многократном выполнении. В этой связи более предпочтительным является
путь создания сложного комплексного алгоритма, в случае, если его
использование позволит результирующей программе сократить время
выполнения на целевой платформе. Таким образом, возникает необходимость
проведения автоматизированным способом предварительной оценки
сложности и эффективности алгоритма, прежде чем принимать окончательное
решение об использовании и реализации в виде законченного программного
кода.
 49

Сложность алгоритма – величина, отражающая порядок величины

требуемого ресурса (времени или дополнительной памяти) в зависимости от
размерности задачи [40].
При возникновении необходимости оценки сложности чаще всего
используется временная сложность. Очевидным способом проверки является
экспериментальный, однако на практике этот способ обнаруживает ряд
недостатков. Необходимо учитывать, что на время выполнения программ
влияет ряд следующих факторов:
• временная сложность алгоритма;
• качество скомпилированного кода исполняемой программы;
• машинные инструкции, используемые для выполнения.
Последние два фактора приводят к невозможности применения типовых
единиц измерения (секунды, миллисекунды), так как использование двух
разных компиляторов либо двух разных вычислителей может давать заметные
расхождения во временной оценке одного и того же алгоритма. Так же,
процесс написания экспериментальных программ для каждого варианта
алгоритма может значительно повысить временные затраты.
Существует метод, позволяющий теоретически оценить время
выполнения алгоритма [9]. Часто временная сложность алгоритма зависит от
количества входных данных. В таком случае существует некоторая функция
зависимости времени работы алгоритма от числа входных данных.
Практически время выполнения алгоритма зависит на только от
количества входных данных, но и от их значений, например, время работы
некоторых алгоритмов сортировки значительно сокращается, если
первоначально данные частично упорядочены, тогда как другие методы
оказываются нечувствительными к этому свойству. Чтобы учитывать этот
факт, полностью сохраняя при этом возможность анализировать алгоритмы
независимо от входных данных, различают максимальную, среднюю и
минимальную сложности [36].
 50

Теоретическая оценка временной сложности алгоритма осуществляется с

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

хоть и в меньшей степени. Кроме того, код, содержащий безусловные

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

2.2.2 Алгоритм автоматизации формирования индикационных кадров.

С учетом сделанных выводов предлагается алгоритм, формирующий

индикационные кадры для отображения картографической информации.
Блок-схема алгоритма приведена на рис. 2.2 и содержит следующие фазы:
1. Выбирается для отображения требуемая цифровая модель местности
из базы геопространственных данных по списку доступных в бортовой базе
данных моделей. Указатели на модели хранятся в массиве model_ids, для
каждой модели на экран выводится ее название, хранящееся в переменной
model_ids[i].display_name.

2. Выбирается система координат — аналогично выбору модели

местности, однако вместо названий для наглядности на экран выводятся
основные параметры выбираемой системы координат: plane_X, plane_Y –
начальные координаты системы отсчета, X_count, Y_count – количество
квадратов вдоль каждой из осей, pixel_size – размер пикселя.

3. Выбирается вид и параметры картографической проекции — сначала

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

4. Выбирается масштаб — основной или один из производных

масштабов отображения данных цифровой модели местности: основной
масштаб устанавливается выбором делителя, в результате чего
 52

устанавливается значение переменной scale_factor, после чего появляется

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

5. Задается ручным вводом произвольный угол ориентирования

(поворота) картографического изображения.
6. Задается ручным вводом координат произвольная точка привязки
картографического изображения.

7. Выбирается состав отображаемых элементов (слоев), в результате

устанавливаются флаги в битовой маске used_model_id.

8. Выбирается из списка доступных способ отображения рельефа.

9. Включение или выключение отображения географической основы
картографических изображений (крупных географических объектов), в
результате производится установка булева значения show_base.

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

отображаемым объектам различных категорий значимости, в результате
устанавливаются флаги в битовой маске show_idx.
11. Включение или выключение индикации координатных сеток, в
результате производится установка булева значения show_net.

12. Выбирается «летнее» или «зимнее» содержание географической

основы картографических изображений («летнее» содержание включает
объекты, визуально наблюдаемые в полете летом, «зимнее» — зимой), в
результате происходит установка значения флага summer_base. Значение false
приводит к выводу зимней основы, значение true – к выводу летней.

13. Выбирается «дневное» или «ночное» содержание географической

основы картографических изображений («дневное» содержание включает
объекты, визуально наблюдаемые в светлое время суток, «ночное» — в
темное), в результате происходит установка значения флага daytime_base.
 53

Значение false приводит к отображению ночной основы карты местности,

значение true – дневной основы.

14. Включение или выключение пользовательских настроек карты

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

15. Выбирается из списка доступных заданный вид картографической

анимации.

Начало А

Ввод
значения
Ввод выбраной
model_id
нет системы координат

нет
Проверка значения
model_id
Проверка введённых
параметров

Значение
корректно?
Значения
корректны?

да
да

А Б

Рисунок 2.2. Фрагмент алгоритма формирования индикационных кадров

 54

Ввод вида
Б картографической
проекции

Проверка введённого
значения
нет

Значение
корректно?

да

Установка значений
дополнительных
параметров вида проекции
нет

Ввод Проверка
дополнительных установленных
параметров модели значений

нет Значения
Проверка введённых
значений корректны?

да

Значения
корректны? Использовать
базовую модель?

да
да

Рисунок 2.2. Фрагмент алгоритма формирования индикационных кадров

 55

Установка
выбранной модели

Поворот Задан угол

изображения на да поворота
заданное значение изображения?

нет

Ввод способа
отображения
рельефа
нет

Проверка введённого
значения

Значение
корректно?

да

Формирование базового
изображения

Рисунок 2.2. Фрагмент алгоритма формирования индикационных кадров

 56

Задана
да произвольная точка
привязки?

нет

Установка произвольной Установка базовой

точки привязки точки привязки

Проверка маски
user_model_id

Добавление Установлены
дополнительных да дополнительные
объектов флаги?

нет

Добавление
show_base true
объекта

false

Проверка маски
show_idx

Рисунок 2.2. Фрагмент алгоритма формирования индикационных кадров

 57

Установлены
Добавление
да дополнительные
надписей
флаги?

нет

Добавление
true show_net
координатной сетки

false

summer_base
false true

Установить зимнее Установить летнее

содержание основы содержание основы

false daytime_base true

Установить ночное Установить дневное

содержание основы содержание основы

Проверка маски
user_set

Рисунок 2.2. Фрагмент алгоритма формирования индикационных кадров

 58

Добавление Установлены
дополнительных да дополнительные
объектов флаги?

нет

Ввод вида
картографической
анимации
нет

Проверка введённого
значения

Значение
корректно?

да

Вывод итогового
изображения

Конец

Рисунок 2.2. Фрагмент алгоритма формирования индикационных кадров

 59

2.3 Оптимизированная структура входных данных для обеспечения

динамических характеристик доступа к геоинформационным ресурсам

Геопространственные данные представляют собой цифровой массив

данных, включающий метаданные и картографические модели [12, 44].
Метаданные содержат справочную пространственную информацию.
Картографические модели включают:
• модель местности, представляющую собой векторизованные данные
об объектах местности;
• модель рельефа, содержащую данные о неровностях земной
поверхности в матричном виде;
• модель обстановки, содержащую векторизованные данные об
объектах навигационной и тактической обстановки в районе полетов.
Метаданные содержат идентификационную информацию array_id,
контрольную информацию array_size, данные scale_index об источнике
картографической информации, используемой для построения моделей,
параметры картографической проекции plane_arguments, параметры условной
системы координат plane_X, plane_Y, pixel_size и адресную информацию
data_adress. Структура метаданных в синтаксисе языка С имеет вид:
{array_id, array_size, scale_index, plane_arguments, plane_X, plane_Y,
pixel_size, data_adress}

Модель местности включает в себя: классификационные данные,

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

{model_id, model_size, metric_descriptors, semantic_descriptors,

placement_desctriptors},

где model_id, model_size – справочные данные о модели,

metric_descriptors – таблица адресов, указывающих на место хранения
метрической информации, semantic_descriptors – таблица адресов,
указывающих на место хранения семантических данных,
placement_desctriptors – таблица адресов, указывающих на информацию о
расположении объектов.
Метрические данные являются частью цифровой модели местности и
представляют собой координаты точек, определяющих местоположение и
очертания объектов. Кодирование осуществляется с применением условной
системы координат и условной единицы координат. Для ограничения района
задания данной модели местности используется прямоугольная рамка.
Стороны рамки ориентированы по направлениям осей, а нижний левый угол
совпадает с началом условной системы координат. В качестве условной
единицы измерения координат используется пиксель, численно равный длине
стороны квадрата, покрывающего ровно один элемент изображения.
Прямоугольный район внутри рамки делится на квадраты размером 64 на
64 пикселя. При описании цифровой модели местности применяется два вида
нумерации квадратов карты: двойная и сквозная. При двойной нумерации
используется два индекса, один из которых увеличивается при переборе
квадратов по столбцам (строкам) вдоль первой оси условной системы
координат в порядке возрастания значений координат, другой – вдоль второй
оси. При сквозной нумерации используется лишь один индекс. Он
увеличивается при переборе квадратов по столбцам (строкам) вдоль первой
оси условной системы координат в порядке возрастания значений координат с
переходом, по достижению крайнего квадрата столбца (строки), к
следующему столбцу (строке) по направлению второй оси, также в порядке
возрастания значений координат. В обоих случаях нумерация начинается с
 61

квадрата, содержащего точку начала отсчета условной системы координат.

Перевычисление индексов квадратов при смене системы нумерации
выполняется по формулам:
k = i + j × I;
i = k mod I ;
j = [ k / I ],

где k = 0 … K – 1 – индекс квадрата при сквозной нумерации, K – общее

количество квадратов, i = 0 … I – 1 и j = 0 … J – 1 – индексы квадрата при
двойной нумерации вдоль направлений соответственно первой и второй осей
условной системы координат, I и J – количество квадратов в сетке вдоль
направлений соответственно первой и второй осей условной системы
координат, mod – операция взятия остатка от деления, [...] – операция взятия
целого от деления. Очевидно, что справедливо соотношение K = I × J.
Координаты метрики объектов в ЦММ задаются приращениями
координат характерных точек объектов относительно точек начала отсчета
соответствующих квадратов. Точка начала отсчета в каждом квадрате
совпадает с его угловой точкой, имеющей минимальные значения условных
координат. В общем случае перевычисление приращений условных координат
в координаты проекции карты и обратно выполняются по формулам:
−
= ,
64 × ∆
−
= ,
64 × ∆
− − 64 × ∆ ×
∆ = ,
∆/4
− − 64 × ∆ ×
∆ = ,
∆/4
∆
= + 64 × ∆ × + ∆ × ,
4
 62

∆
= + 64 × ∆ × + ∆ × ,
4

где X и Y – координаты точки в системе координат проекции карты (в

метрах), X0 и Y0 – координаты начала отсчета условной системы координат в
системе координат проекции карты, ∆x и ∆y – приращения условных
координат точки внутри соответствующего квадрата (единица значения любой
из координат численно равна пиксель/4, диапазон изменения значений
координат – 0…255). Выбор 8-разрядного слова для кодирования координат
обеспечивает неразрывность отображений, расположенных в нескольких
квадратах площадных и линейных объектов в масштабах, крупнее исходного
в 2 и 4 раза, а также существенное упрощение масштабирования объектов при
переходе от основного масштаба к производным за счет использования
определенного количества старших битов координат.
По способу формирования метрики, в зависимости от форм и размеров,
объекты местности подразделяются на следующие виды: площадной,
линейный, векторный и точечный. Формирование метрики площадного
объекта выполняется в соответствии со следующими правилами:
• точки метрики площадного объекта должны являться углами
многоугольника, образованного последовательным соединением отрезками
прямых линий соседних в последовательности точек, а также последней с
первой; причем последняя точка метрики должна совпадать с первой, замыкая
таким образом контур площадного объекта;
• ни одна из сторон многоугольника не должна пересекать других его
сторон, кроме смежных сторон;
• первой должна следовать точка, имеющая максимальное значение
вертикальной координаты, порядок следования остальных точек должен
обеспечивать обход углов многоугольника против часовой стрелки;
 63

• любая прямая линия, параллельная горизонтальной оси, должна

пересекать границы объекта (многоугольника) не более чем в двух точках;
если реальный объект имеет контуры более сложного многоугольника, то он
разбивается на несколько простых, удовлетворяющих данному правилу;
• все точки метрики многоугольника должны лежать в одном квадрате;
если объект простирается на несколько квадратов, то он искусственно
усекается соответствующими отрезками границ квадрата, которые в связи с
этим отражаются в метрике.
Формирование метрики линейного объекта выполняется в соответствии
со следующими правилами:
• точки метрики линейного объекта должны являться узлами ломаной
линии, образованной последовательным соединением отрезками прямых
линий соседних в последовательности точек;
• ни один из отрезков ломаной линии не должен пересекать других,
кроме смежных;
• некоторые линейные объекты имеют несимметричные условные
графические обозначения (например, овраг или обрывистый берег водоема).
При формировании последовательности точек для таких объектов это
необходимо учитывать;
• все точки метрики ломаной линии должны лежать в одном квадрате;
если объект простирается на несколько квадратов, то он искусственно
усекается соответствующими точками на границах квадрата, которые в связи
с этим становятся частью метрики.
Формирование метрики векторного объекта выполняется в соответствии
со следующими правилами:
• первая пара координат метрики должна описывать приращения
условных координат центра объекта относительно начала отсчета
соответствующего квадрата;
 64

• вторая пара координат метрики указывает точку конца вектора,

проведенного из центра объекта и определяющего его ориентацию для случая,
если бы центр объекта располагался в точке с координатами {127, 127}, то есть
в условной системе координат векторный объект ориентирован вдоль линии,
заданной координатами следующих двух точек: {64 × i + ∆x0 , 64 × j + ∆y0}, {64
× i + ∆x0 + ∆x1 − 127, 64 × j + ∆y0 + ∆y1 − 127}, где ∆x0, ∆y0 и ∆x1, ∆y1 – пары
координат соответственно первой и второй точек метрики векторного объекта;
если значения второй пары координат метрики одновременно равны 127, то
векторный объект считается неориентированным.
Формирование метрики точечного объекта выполняется в соответствии
со следующим правилом:
• единственная пара координат метрики должны соответствовать
приращениям условных координат центра объекта или для некоторых типов
объектов иной характерной точки.
Структура метрических данных в синтаксисе языка С имеет вид:
{object_id, object_key, visualization_parameters, object_color,
object_primitives},

где object_id, object_key – идентификационная информация о

метрическом объекте, visualization_parameters – параметры его визуализации,
object_color – цвет, используемый для отображения объекта, object_primitives
– примитивы, используемые для построения объекта.
Семантические данные представляют собой данные, специфичные для
отдельных типов объектов (названия объектов, высоты препятствий, значения
магнитных склонений и т.п.).
Модель рельефа относится к пространственным моделям,
представляемым в растровом виде, и содержит массив данных высот рельефа
в зоне полета летательного аппарата. Данные по высотам рельефа
представляют собой набор значений, характеризующих максимальные
 65

превышения высот поверхности земли над определенным уровнем в пределах

заданной области полета. Модель рельефа имеет вид:
{model_id, model_size, relief_descriptors},

где model_id, model_size – идентификационная и справочная информация

о модели, relief_descriptors - таблица адресов, указывающих на место хранения
информации о рельефе местности.
Модель обстановки имеет структуру, аналогичную структуре модели
местности и отличается от нее только типом хранимой информации
(навигационная и тактическая обстановка).
В процессе отображения геопространственных данных на основе
введенных структур используются следующие принципы формирования
изображений:
• поточное чтение метрических данных с селекцией видов
отображаемых данных;
• формирование списка подписей, подлежащих отображению, на
основе семантической информации объектов, попадающих в кадр индикации
и масштаба представления геопространственных данных;
• идентификация объекта по заданным координатам, определение его
свойств и семантических параметров;
• определение метрических данных, семантических параметров и
свойств объекта по заданному идентификатору.

2.4 Особенности программирования бортовой системы

картографической информации

В процессе работы бортовая система картографической информации

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

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

бортовом индикаторе [13, 25, 35].
При создании системного программного обеспечения БСКИ необходимо
учитывать особенности используемой аппаратной платформы. Это позволяет
в полной мере задействовать имеющиеся возможности и добиться заметного
прироста быстродействия проектируемой системы. Основными
функциональными компонентами (модулями авионики) картографической
системы являются:
• модуль вычислительный;
• модуль графического контроллера;
• модуль обмена дискретной информацией;
• модуль мультиплексного обмена;
• модуль внешней памяти.
Используемые модули по принципу работы с интерфейсом
взаимодействия делятся на активные и пассивные. Вычислительный модуль,
выполняющий функции центрального процессора, является активным, в
соответствии с программой модуль осуществляет запросы, прием, обработку
и выдачу данных по основной межмодульной шине связи. При обмене с
вычислителем графический модуль является пассивным, в свою очередь
становясь активным во время обращения к памяти. Все остальные модули
относятся к пассивным, отвечают за получение запросов и данных от
вычислителя и отправляют данные по интерфейсам обмена.

2.4.1 Система адресации бортовой системы картографической

информации

Система адресации устройств в составе БСКИ обеспечивает:

• возможность обмена данными между устройствами внутри модуля
(внутрипроцессорная адресация);
 67

• возможность обмена данными между модулем и другими

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

FFFFFFFF FFFFFFFF

Сегмент 2

C0000000 C0000000
BFFFFFFF BFFFFFFF
Сегмент 1
A0000000
9FFFFFFF
Сегмент 0
80000000
7FFFFFFF

40000000
Пользовательский 3FFFFFFF
сегмент
20000000
1FFFFFFF

00000000 00000000

Рисунок 2.3. Распределение виртуальной памяти БСКИ

ВПИ представляет собой параллельную магистраль с 32-разрядной

шиной адреса. Разрядность шины адреса обеспечивает возможность доступа к
4 Гб виртуального адресного пространства. Распределение виртуальной
 68

памяти и соответствие ей физического адресного пространства показано на

рис. 2.3.
Процессор содержит встроенную кэш-память. Команды и данные
кэшируются раздельно. Кэш-память может работать в одной из двух
конфигураций:
• 16 Кб для команд, 4 Кб для данных;
• 8 Кб для команд, 8 Кб для данных.
• Для обмена данными между вычислительным модулем и другими
устройствами внутри БСКИ используется магистральный интерфейс.
Разрядность шины адреса (18 разрядов) обеспечивает возможность доступа к
256 Кбайт адресного пространства. Для удобства обращения на соединители
некоторых из модулей выведены адресные ключи, определяющие положение
модулей в адресном пространстве БСКИ.

2.4.2 Система прерываний, используемая в БСКИ

Прерывание – приостановка выполнения текущей последовательности

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

• адрес вектора исключительной ситуации «Сброс»;

• адрес универсального вектора, который используется для всех
остальных типов исключительных ситуаций.
Обратившись программным способом по этим адресам можно
идентифицировать причину возникновения прерывания и инициировать
соответствующий «обработчик» прерывания. Предварительную обработку
прерываний (определение приоритета, выбор входа процессора) производит
контроллер внешних устройств. Он принимает сигналы прерывания от
внутренних устройств модуля (контроллер последовательных кодов,
программируемые таймеры). Подключенные к внешнему интерфейсу модули
выставляют запрос прерывания на специально выделенную линию
контроллера. При этом приоритет обработки определяется в зависимости
удаления устройства от процессора в направлении распространения сигнала.
Прерывания, генерируемые аппаратурой, после обработки в контроллере
внешних устройств поступают на соответствующий вход процессора
вычислительного модуля:
• INT0 - прерывание аварии питания;
• INT1 – прерывание от системного таймера;
• INT2 – прерывание по зависанию при записи в память;
• INT3 – прерывания от сопроцессора FPU;
• INT4 – прерывания от внутреннего МПИ;
• INT5 – прерывания от внешнего МПИ.
Максимальный приоритет имеет вход INT0, минимальный - INT5.
Устройство, запросившее прерывание, по разрешению процессора выдает
ему адрес вектора прерывания, определяющего вход в процедуру обработки
данного прерывания.
 70

2.4.3 Система контроля БСКИ

Тестовый контроль предусматривает выполнение программы,

содержащей примеры с заранее подсчитанными ответами. Примеры
подбираются таким образом, чтобы любой отказ из числа принятых к
рассмотрению приводил к неправильному выполнению примера и
обнаружению отказа. Примеры подбираются для конкретной схемы.
Программы тестового контроля являются машинно-ориентированными,
не зависят от решаемых БСКИ задач. Полнота тестового контроля БСКИ в
целом в большой степени зависит от выделенного на тестовый контроль
объема памяти, а в части устройств ввода-вывода – также и от наличия
обеспечивающего тестовый контроль оборудования.
Тестовый контроль может выполняться в одном из трех режимов:
1. Наземный режим тестового контроля.

Тест наземного контроля предусматривает проверку БСКИ вне комплекса

с подключенными средствами наземного контроля при наличии сигнала
«Наземный контроль». Наземный режим обеспечивает автоматизированную
проверку БСКИ и используется в следующих случаях:
• при регламентных работах;
• при входном контроле и проверке после хранения;
• при поиске неисправных модулей;
• при серийном производстве для всех видов испытаний.
2. Режим автономного контроля (расширенный режим).

Расширенный режим тестового контроля – тест автономного контроля

выполняется по сигналу «Автономный контроль», поступающему из
комплекса. В этом режиме выполняется более полная проверка ОЗУ и
устройств ввода-вывода. Рабочая программа не выполняется.
3. Стандартный режим.
 71

Тестовый контроль БСКИ в стандартном режиме – тест встроенного

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

2.5 Выводы

Представленная схема автоматизированного рабочего места

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

Важными факторами, влияющими качество разрабатываемого проекта,

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

ГЛАВА 3. АВТОМАТИЗАЦИЯ СОЗДАНИЯ ТАБЛИЦ

КОНФИГУРАЦИИ БОРТОВЫХ СИСТЕМ КАРТОГРАФИЧЕСКОЙ
ИНФОРМАЦИИ

3.1 Системное и прикладное программное обеспечение как элемент

бортовой системы картографической информации

Отличительной особенностью системного программного обеспечения

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

3.1.1 Архитектура системного программного обеспечения

Операционная система, используемая в составе БСКИ, представляет

собой ОСРВ, предназначенную для встроенных применений [65]. Исправное
функционирование ОСРВ подразумевает возможность параллельного
выполнения в изделии нескольких приложений в соответствии со стандартом
ARINC-653. На рис. 3.1 приведена схема программных компонентов БСКИ,
выполняющегося под управлением ОСРВ.
Выполнение каждого из программных приложений производится в
отдельном разделе, тем самым обеспечивая строгий контроль со стороны
операционной системы за доступом приложения к физическим ресурсам
(процессорному времени, памяти, объектам синхронизации и т.д.). Разделы,
ограничивающие область работы задач, изолированы друг от друга. При
возникновении необходимости взаимодействия приложений из разных
разделов, информация передается с использованием специальных каналов
связи. Планирование временных ограничений выполнения задач, так же, как и
создание конфигурации каналов взаимодействия, осуществляется на этапе
разработки системы. Взаимная изоляция приложений друг от друга реализует
возможность безопасного выполнения на одном процессоре приложений
разной степени критичности. Под безопасным выполнением в данном случае
понимается невозможность возникновения ситуации, в которой действия
задачи меньшего уровня критичности повлияют каким-либо образом на
функционирование приложения, обладающего большим уровнем критичности
[56].
Со стороны операционной системы приложениям предоставляется набор
сервисов, которые в полной мере реализуют интерфейс Application Executive
(APEX), описание которого приводится в стандарте ARINC-653, часть 1.
Приложения представляют собой программы, которые выполняют
основную целевую функцию картографической системы. Помимо
приложений, под управлением операционной системы могут выполняться
 75

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

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

Рисунок 3.1. Схема компонентов программного обеспечения, работающего

под управлением ОСРВ в составе БСКИ

отвечает за выполнение приложения в разделе и предоставление приложению

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

Потоки приложения для обращения к ОС раздела используют механизм

системного вызова и специальную инструкцию процессора. Ядро ОС
транслирует системные вызовы от потоков приложения в специальные
события, обрабатываемые потоком ОС раздела.
Системные потоки могут напрямую вызывать сервисы ОС. Многие
сервисы ОС для выполнения критических операций на некоторое время
запрещают прерывания, однако время выполнения таких участков кода мало
и не зависит от параметров системы, т.е. составляет О(1). Это достигается
отсутствием в критических участках кода ОС операций, имеющих
неопределенную длительность, таких, например, как просмотр списка.
С каждым системным потоком ядро связывает очередь событий,
ожидающих обработки этим потоком. Событие может быть сгенерировано
ядром, другим потоком, процедурой обработки прерывания или самим
потоком-обработчиком. Обработка различных событий является основной
функцией системных потоков.
Системные потоки имеют возможность устанавливать процедуры
обработки прерываний (ISR – Interrupt Service Routine). Процедуры обработки
прерываний выполняются независимо от выполнения системных потоков.

3.1.2 Особенности структуры системного ПО БСКИ

Назначение управляющей операционной системы в составе БСКИ

состоит в том, чтобы обеспечить подходящую среду для выполнения и
обслуживания множества прикладных бортовых подзадач [79]. Операционная
система строится по модульному принципу и состоит из следующих модулей:
• инициализация ядра;
• ядро;
• менеджер модуля;
• ОС раздела (менеджер приложения).
Структура модулей операционной системы БСКИ показана на рис. 3.2.
 78

Пакет поддержки модуля

ОС

Менеджер Модуль
Ядро
модуля инициализации ядра

ОС раздела
(менеджер приложения)

Рисунок 3.2. Структура модулей операционной системы БСКИ

При запуске операционной системы первым должен быть вызван модуль

инициализации ядра. После получения управления, модуль становится
ответственен за подготовку ядра ОСРВ к работе и выполняет следующие
действия:
• запрещение всех прерываний;
• инициализация процессора;
• инициализация физической памяти;
• инициализация прерываний;
• инициализация внутренних данных ядра;
• создание потока менеджера модуля;
• разрешение всех прерываний;
• переход на управление планированием для поиска потоков, готовых к
выполнению.
При выполнении инициализации ядра также вызываются функции пакета
поддержки модуля.
 79

Следующим свою работу выполняет модуль ядра операционной системы.

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

модуля, выполняют настройку аппаратуры процессора, системного и

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

3.1.3 Особенности подготовки системы к работе

Для работы целевого программного обеспечения в составе БСКИ под

управлением операционной системы требуется создать три стыковочных
модуля: старт-файл, файл прерываний и файл конфигурации. Допускается
объединять файлы или «делить» их в зависимости от используемого языка
программирования.
Для работы с сервисными процедурами ОСРВ, необходимо в исходных
модулях целевого программного обеспечения подключить файлы-
спецификации, содержащие ссылки на процедуры операционной системы и
описания основных констант, необходимых системе для работы.
В старт-файле должны содержаться две процедуры: процедура
инициализации и процедура обработки серьезных системных ошибок.
Первая процедура не имеет параметров и входных данных. Процедура
должна быть написана на языке ассемблера и включать в себя:
• инициализацию системных регистров модуля вычислителя;
• инициализацию аппаратуры модуля вычислителя (если требуется);
• инициализацию секций данных и переменных, необходимая для
работы с процедурами, написанными на языке С;
• установку глобального указателя и указателя стека;
• перепись процедуры начальной обработки прерываний в ОЗУ;
• инициализацию системного таймера (если требуется) и его запуск;
 81

• установку некоторых системных переменных (необходимая часть для

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

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

этом файле содержатся все определения: доступная память, количество ячеек
памяти, очередей, групп флажков событий, семафоров и информация о
задачах.
При создании данного файла, необходимо подключить файлы-
спецификации, один из которых содержит описания структур конфигурации,
а второй – описания основных констант системы.
Конфигурация в целом определяется следующим набором структур:
• Определения доступной памяти. Операционная система должна знать
последний адрес памяти, используемый компоновщиком (или первый
свободный адрес), и последний адрес памяти, доступный в аппаратных
средствах.
• Определения ячеек памяти. Операционная система обеспечивает
управление памятью постоянной длины. Память постоянной длины часто
называют «порциями» памяти. Содержимое структуры определяет «порции»
памяти системы.
• Определения очередей. Операционная система обеспечивает связь
задач через набор предопределенных очередей. Содержимое структуры
определяет очереди системы.
• Размер системного стека. Операционная система должна
распределить память для стека системы в подпрограмме инициализации.
Желательный размер стека передается в переменной типа беззнакового
целого.
• Группы флагов событий. Операционная система обеспечивает флаги
для каждого события через предопределенный набор групп флагов событий.
Пользователь ответственен за связь фактических событий с флагами события
внутри групп. Количество групп событий в системе определяется в
переменной типа беззнакового целого. Количество событий внутри группы
 83

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

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

3.2 Автоматизация создания таблиц конфигурации бортовых систем

картографической информации

Традиционно процесс создания таблиц конфигурации состоит в

редактировании набора данных или таблиц, на основе которых потом
формируются данные, загружаемые в изделие [45, 61]. Ручное редактирование
данных, расположенных в нескольких таблицах конфигурации, представляет
собой трудоемкий процесс и требует высокой квалификации разработчика.
Кроме того, вследствие необходимости учета большого объема
взаимосвязанных данных, формируемых несколькими предприятиями-
соисполнителями, процесс конфигурации, выполняемый в ручном режиме,
 84

сопровождается возникновением ошибок проектирования, которые могут

проявиться как на этапе сборки системы, так и во время ее эксплуатации на
объекте.
Среди производителей ОСРВ в настоящее время интерактивное
инструментальное средство автоматизации конфигурирования
рассматриваемого уровня существует только для ОС PikeOS фирмы SYSGO.
Одна из самых используемых [79] ОСРВ VxWorks вообще не имеет
инструментальных средств конфигурирования, вынуждая пользователя
вручную выполнять редактирование текстовых конфигурационных файлов.

3.2.1 Структура конфигурационной информации

Неотъемлемым компонентом БСКИ является ее программное

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

том числе, интерфейс прикладного ПО для изделий, выполненных в

соответствии с принципами интегрированной модульной авионики [15, 49,
69].
Прикладное ПО, разработанное для операционных систем (ОС),
поддерживающих стандарт ARINC 653, является переносимым между этими
ОС. Таким образом, конфигурирование изделия и его ПО так же становится в
значительной степени независимым от конкретной ОС. С другой стороны,
внутренняя архитектура каждой ОС уникальна, поэтому часть
конфигурационной информации об изделии и его компонентах является
специфичной для конкретной ОС. Кроме того, необходимо конфигурировать
различные данные об аппаратуре с учетом особенностей аппаратного
обеспечения целевой проектируемой системы [23].
Таким образом, можно выделить три составные части структуры
конфигурационной информации БСКИ, построенных на основе ОСРВ,
поддерживающих стандарт ARINC 653:
• зависимая от целевой функции системы;
• зависимая от ОС;
• зависимая от физической аппаратуры целевой системы.
Конфигурационная информация, зависимая от целевой функции системы,
формируется совместно специалистами организации, разрабатывающей
прикладное ПО, и специалистами организации, ответственной за интеграцию
всех компонентов ПО — системным интегратором проекта. Информация,
зависимая от ОС, формируется системным интегратором на основе данных,
предоставляемых разработчиком ОС. Информация, зависимая от физической
аппаратуры, учитывается при установке ОС на конкретный вычислительный
модуль, и формируется системным интегратором. Разработчики ОС
предусматривают возможность дополнительного конфигурирования данных
об аппаратуре на этапе проектирования изделия, т.е. уже после установки ОС
 86

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

функционального назначения конкретного вычислительного модуля.

3.2.2 Автоматизированная среда конфигурирования

При разработке БСКИ возникает потребность в автоматизации процесса

ее конфигурирования [16, 67]. Автоматизация процесса конфигурирования
выполняется на АРМ, оснащенном инструментальной ЭВМ и программными
средствами САПР. Программное обеспечение АРМ представляет собой
единую среду проектирования, охватывающую весь объем конфигурационной
информации. Основным пользователем автоматизированной среды является
системный интегратор, к которому поступает информация от разработчиков
компонентов БСКИ.
Подготовку конфигурационной информации, необходимой для
инициализации и выполнения функциональных приложений, а также для
организации связей между программными приложениями, системный
интегратор выполняет на инструментальной ЭВМ с помощью специального
программного компонента – «Конфигуратор», поставляемого разработчикам
изделия вместе с его операционной системой. Конфигуратор позволяет
создавать и редактировать конфигурационные данные в интерактивном
режиме и использует для хранения информации файл в формате XML
(eXtensible Markup Language). Пример рабочего окна для конфигурирования
картографической информации показан на рис 3.3.
Для того чтобы сделать конфигурационную информацию доступной ОС,
необходимо сформировать и загрузить в память целевого вычислителя ее
двоичное представление. САПР «Конфигуратор» позволяет автоматически
генерировать электронный файл данных, содержащий конфигурационные
данные, структурированные определенным образом. Результатом процесса
автоматизированного создания файла является загружаемый компонент,
содержащий двоичные данные. Формат хранения загружаемого компонента с
 87

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

средств загрузки в целевую аппаратную платформу. Наиболее часто
применяется формат хранения данных motorola-32 (mot) [79].

Рисунок 3.3. Пример рабочего окна САПР «Конфигуратор» для настройки

состава отображения картографической информации

На рис. 3.4 показаны информационные связи САПР «Конфигуратор» с

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

исходные тексты приложений библиотеки

конфигурация (С) (С, Ассемблер) (С, ассемблер)

компилятор целевой платформы

88
конфигурационные данные (mot) исполняемые файлы приложений (elf) разделяемые библиотеки, файлы данных (mot)

изделие БСКИ
средства загрузки в целевую платформу
Рисунок 3.4. Функциональная схема взаимодействия САПР «Конфигуратор» с другими элементами инструментального
ПО в составе АРМ
 89

диаграммы для ее представления пользователю в интуитивно понятном виде.

Конфигурационная информация представляется в виде иерархического
дерева с дополнительными горизонтальными связями между отдельными
ветвями. Каждый последующий уровень дерева подразумевает большую
детализацию представления информации, а каждая отдельная ветвь дерева
представляет структурно независимый блок данных. Горизонтальные связи
содержат информацию о взаимодействии структурно или функционально
независимых элементов и представляются в дереве специальными узлами —
листьями дерева.
При этом пользователь САПР имеет возможность видеть на экране
инструментальной ЭВМ полное дерево конфигурационной информации на
всю его глубину, «перемещаться» по нему, сворачивать и разворачивать
отдельные ветви. Также для каждого узла дерева по желанию пользователя на
экране может быть показана конфигурационная информация, представляемая
этим узлом и в некоторых случаях его узлами – потомками.
Для удобства пользователя в САПР реализован альтернативный способ
представления и редактирования конфигурационной информации в виде
таблиц, диаграмм и их комбинаций, содержащих логически связанную
конфигурационную информацию из различных ветвей дерева. Возможны
различные виды такой логической группировки. Для каждого из них
используется своя диаграмма, позволяющая выделить главный аспект
группируемой информации.
Кроме того, представление в виде диаграммы позволяет органично
сочетать конфигурационную информацию, относящуюся к различным
уровням иерархического дерева. Например, одна из диаграмм, реализованных
в САПР «Конфигуратор» позволяет не только конфигурировать каналы связи
между приложениями функционального ПО, но также ввести информацию,
необходимую драйверу или ОС для организации этих каналов на основе
физических сетевых интерфейсов, доступных системе, и с учетом
особенностей используемых протоколов.
 90

Среда проектирования позволяет пользователю генерировать данные,

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

3.3 Особенности оптимизации проектных решений для эффективного

использования ресурсов аппаратной платформы БСКИ

В связи с появлением новых аппаратных решений, использующих в

качестве вычислительного процессора компоненты компании ARM (Advanced
RISC (Restricted Instruction Set Computer) Machine), возникает необходимость
вносить изменения в существующие компоненты БСКИ, поскольку
архитектура нового аппаратного обеспечения отличается от использующейся
ранее. Решение задачи переноса полученных ранее проектных решений на
новую аппаратную платформу позволит разрабатывать аппаратно-
независимые, унифицированные проектные решения для синтеза нового
бортового приборного оборудования.
Использование ядром вычислительной системы микропроцессоров ARM-
архитектуры означает, что в качестве операндов в программном коде могут
использоваться только значения, загруженные в 32-х разрядные регистры
микропроцессора[52]. Несмотря на то, что система команд содержит операции
чтения и записи для любых целочисленных типов данных, имеющих и не
имеющих знаковое расширение, работа с восьми- и шестнадцатиразрядными
локальными переменными (например, тип данных char или short) может
привести к значительному увеличению размера кода из-за необходимости
производить преобразование типов данных. В связи с этим, при написании
кода оптимальным будет использования типа данных int при описании
локальных переменных и параметров, для размещения которых планируется
использование регистров микропроцессора.
Одним из существенных отличий архитектуры ARM от других
архитектур микропроцессоров является предикация — возможность
условного исполнения команд. Условное исполнение команд в авионике
подразумевает, что выполнение команд зависит от текущего состояния флагов
микропроцессора. В архитектурах, отличных от ARM (MIPS (Microprocessor
without Interlocked Pipeline Stages), PowerPC, SPARC (Scalable Processor
 92

ARChitecture) и др.), избирательное выполнение команд достигается

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

Таблица 1. Распределение регистров по стандарту ATPCS

Регистр Назначение
R15 Program Counter (PC), счетчик команд
Link Register (LR), содержит адрес возврата при передаче
R14 управления инструкцией BL (выполняет переход на указанный
адрес)
R13 Stack Pointer (SP), указатель стека программ
R12
R11 Регистры общего назначения
R10
R09
R08
R07
R06 Для размещения локальных переменных;
R05 вызываемая функция сохраняет используемые регистры в стеке
R04
R03 Для передачи параметров, возврата значения и в качестве
R02 временных (scratch) регистров;
R01 вызываемая функция не сохраняет значения этих регистров в
R00 стеке

Подобное преимущество достигается добавлением в коды инструкций

ассемблера ARM особого 4-битового поля (предиката). Одно из значений
предиката указывает безусловное выполнение инструкции, другие три
 93

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

команды. Недостатком такого подхода является сокращение числа бит,
используемых для кодирования смещения при работе с памятью. С другой
стороны, объем генерируемого кода значительно сокращается в связи с
отсутствием необходимости введения в программное обеспечение инструкций
ветвления для небольших if-блоков условного перехода.
Распределение регистров микропроцессора осуществляется в
соответствии со стандартом ATPCS (ARM Thumb Procedure Call Standard) как
показано в таблице 1. Такое распределение приводит к наложению некоторых
ограничений на используемые переменные, в частности, функция не может
одновременно содержать 14 локальных регистровых переменных, включая
параметры [29]. Размещение большего числа переменных осуществляется в
памяти. Доступ к значениям, хранимым в памяти, приводит к увеличению
затрат вычислительной мощности изделия, поэтому при написании кодов
программ следует избегать использования большого количества переменных.
Рассматривая особенности распределения регистров, можно сделать
следующие выводы, позволяющие оптимально использовать имеющиеся в
изделии вычислительные ресурсы:
• при использовании не более чем четырех скалярных параметров
функции, передача значений должна осуществляться через регистры;
• при необходимости передачи в функцию более чем четырех
параметров, лучшим решением будет использование структуры данных с
передачей в функцию указателя на нее;
• при использовании функцией четырех параметров следует ограничить
количество локальных переменных до десяти;
• крайне нежелательно написание функций с переменным числом
параметров.
Еще одним решением аппаратной платформы, позволяющим повысить
производительность вычислений, является битовая сегментация. При битовой
 94

сегментации каждому биту в области битовых сегментов соответствует адрес

слова из области псевдоимен. Такое описание дает возможность производить
манипуляции с битами в реальной памяти, обращаясь к значениям только по
адресам слов, что избавляет программиста от необходимости введения
специальных команд, увеличивающих сложность в реализации
вычислительного процесса.
Помимо описанных средств, в процессорах ARM-архитектуры
реализован режим Thumb. В данном режиме используется сокращенная
система из 36 команд, полученных преобразованием команд стандартного
набора до 16-разрядных кодов. Такое решение позволяет сократить длину
используемых команд и снижает требуемый объем памяти подпрограмм.
Работа в данном режиме имеет ряд недостатков. В частности, в системе команд
Thumb отсутствуют инструкции деления (функция деления реализуется
программно или с использованием операций сдвига).
При разработке БСКИ имеет немаловажное значение тот факт, что
инструкции микропроцессоров ARM-архитектуры являются «атомарными»
[79]. Это означает, что процесс выполнения инструкций не может быть
прерван обработчиком прерываний. В результате, если инструкция
осуществляет запись большого числа регистров, может значительно
увеличиться время реакции на прерывания, что недопустимо для систем
реального времени. Избежать подобных задержек помогает использование
меньшего числа локальных переменных при написании программного кода
функционального кода ПО БСКИ.

3.4. Унифицированный протокол взаимодействия рабочей станции с

проектируемым оборудованием

В процессе разработки новых аппаратных средств возникает

необходимость проводить тестирование, как всей системы, так и отдельных ее
компонентов [34, 70], при этом желательно получение результатов в форме
 95

наглядных сообщений и/или диаграмм. Имея возможность проведения

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

3.4.1 Общая схема взаимодействия платформ

Программное обеспечение, позволяющее управлять работой аппаратных

модулей с помощью инструментального ПК, делится на две основные группы:
встроенное программное обеспечение целевой платформы и программное
обеспечение инструментальной ЭВМ.
Встроенное программное обеспечение целевой платформы включает в
себя: драйверы, обеспечивающие взаимодействие по интерфейсу USB,
тестовое программное обеспечение, обеспечивающее доступ к ресурсам
модуля, монитор состояния аппаратной части платформы, загрузчик,
обеспечивающий прием информации, и при необходимости программы,
решающие какие-либо специфические задачи.
 96

Инструментальный ПК использует ряд подключаемых компонентов

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

ПК
Изделие
Интерфейсный

Программная оболочка
Загрузчик
компонент

Монитор
Контроллер Компонент Компонент
Драйвер USB порт
канала протокола идентификации
Тестовое ПО

Дополнительные
Спец. ПО
компоненты

Рисунок 3.5. Общая схема программного взаимодействия платформ БСКИ и

инструментальной ЭВМ по интерфейсу USB

3.4.2 Универсальный протокол обмена

Универсальный протокол обмена может быть применен для обмена

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

Протокол определяет информационный обмен между двумя

устройствами: главным (MASTER) и подчиненным (SLAVE). Любой обмен
инициируется главным устройством, которое посылает код команды обмена и
затем посылает и/или принимает данные в соответствии с форматом данной
команды. Все команды разбиты на группы. Любое устройство,
поддерживающее данный протокол, обязано реализовать команды,
относящиеся к группе общих команд. Реализация остальных групп команд не
обязательна. Устройство MASTER может получить информацию о том, какие
группы стандартных команд поддерживаются устройством SLAVE с
помощью команды «Получить информацию об устройстве». Если
подчиненное устройство заявляет, что оно поддерживает какую-либо группу
стандартных команд, то оно должно реализовать все команды, входящие в эту
группу. Если же подчиненное устройство не поддерживает какую-либо группу
команд, то оно может реализовывать команды с кодами из этой группы как
оно считает нужным. Таким образом, каждая конкретная пара устройств
MASTER-SLAVE может реализовывать дополнительные необходимые в
данном конкретном случае функции. Для стандартных групп команд
определены стандартные коды подтверждений, которые подчиненное
устройство может возвращать в ответ на команду главного. В протоколе
определены следующие группы стандартных команд:
• Общие функции. Эта группа команд предназначена для
инициализации и управления информационным обменом между
устройствами, поддерживающими данный протокол.
• Функции передачи данных. Команды этой группы предназначены для
передачи больших блоков данных между устройствами. Команды,
относящиеся к группе команд передачи данных фиксированной длины,
требуют использования дополнительной команды установки размера буфера,
после чего обмен происходит блоками заданного размера.
 98

• Программирование FLASH по стандарту JEDEC. Команды этой

группы предназначены для программирования FLASH в подчиненном
устройстве в соответствии со стандартом JEDEC. Устройство,
поддерживающее эту группу команд, обязано также поддерживать группу
команд передачи данных.
• Чтение-запись одного байта. Команды этой группы предназначены
для примитивного обмена байтовыми данными. Подчиненное устройство
может интерпретировать адрес и данные по своему усмотрению.
• Чтение-запись данных по заданному адресу. Команды этой группы
предназначены для обмена данными произвольных форматов. В каждой
команде от главного устройства передаются размер адреса и данных, адрес,
после чего происходит передача либо прием данных. Адрес и данные
передаются младшими байтами вперед. Подчиненное устройство может
интерпретировать адрес и данные по своему усмотрению.
• Циклические чтение-запись данных по заданному адресу. Команды
этой группы предназначены для отладки подчиненного устройства и
представляют собой команды чтения/записи данных по заданному адресу,
повторяемых подчиненным устройством до приема байта завершения
команды.
• Идентификация. Команда используется для запроса информации у
подчиненного устройства. Размер адреса и данных, а также значение адреса
определяют тип запрашиваемой информации.

3.4.3 Встроенное алгоритмическое обеспечение целевой платформы

В состав встроенного программного обеспечения входят несколько

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

Также обеспечиваются функции стирания FLASH, вычисления контрольных

сумм, проверки загруженных файлов.
Монитор представляет собой программу, предоставляющую
пользователю возможность управления модулем через консольный терминал
(ПК), подключенный по каналу. Пользователь может набирать в терминале
символьные команды, которые передаются в модуль для выполнения.
Результат выводится на экран терминала тоже в символьном виде.
Тестовый монитор обеспечивает программе, выполняемой на ПК,
подключенном к модулю RISC процессора через интерфейс, доступ к
ресурсам модуля процессора и внешней шины модуля процессора по
протоколу USRP. Устройство, подключаемое к модулю процессора, является
главным, модуль процессора – подчиненным. Тестовый монитор также
позволяет программе на главном устройстве получать информацию о
зарегистрированных в модуле RISC процессора прерываниях и устанавливать
свой обработчик прерываний. Тестовый монитор также может содержать
набор тестов, выполнение которых оптимизируется по командам,
предаваемым через интерфейс. Результат выполнения тестов передается в ПК
в определенном формате.
Специальное ПО используется для решения специфических задач,
выполняемых модулем. Например, модуль может быть превращен в
подыгрывающее устройство, входящее в состав стенда отладки и управляемое
программой имитационного моделирования, выполняемой на ПК.

3.4.4 Алгоритмическое обеспечение инструментального

компьютера

Для работы с аппаратными платформами в составе программного

обеспечения инструментального ПК используется специализированная
программная оболочка. Пример окна программы приведен на рис. 3.6. Она
 100

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

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

Рисунок 3.6. Окно программы для работы с аппаратными платформами

На более низком уровне взаимодействие обеспечивают COM-

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

разрабатываются для конкретного изделия авионики, но затем могут быть

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

3.5 Выводы

Работа ПО БСКИ должна осуществляться под управлением

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

ресурсов, помогает не только ускорить процесс конфигурирования, но и

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

ГЛАВА 4. АВТОМАТИЗИРОВАННАЯ СИСТЕМА

ПРОЕКТИРОВАНИЯ БОРТОВЫХ СИСТЕМ КАРТОГРАФИЧЕСКОЙ
ИНФОРМАЦИИ

4.1 Средства автоматизированной отладки

Процесс отладки является неотъемлемой частью разработки БСКИ.

Результатом работы с программой-отладчиком обычно становится выявление
ошибок, часть которых может возникнуть из-за невнимательности и усталости
проектировщика при создании документации будущего изделия [14, 81].
Как показывает практика, интерактивная отладка с использованием точек
останова и возможностью построчного выполнения инструкций является
более продуктивной и надежной для выявления ошибок проекта. Помимо
этого, может появиться необходимость просмотра и ручного изменения
содержимого регистров или оперативной памяти. Информация о смещениях,
указывающих место хранения отдельных переменных, что позволяет
соотнести строку кода в исходном файле целевого ПО с областью размещения
в оперативной памяти физического устройства, хранится в специальном
формате в составе бинарного файла, получаемого при компиляции [53].
Поскольку программное обеспечение БСКИ выполняется в
автоматизированной среде, возникают сложности с использованием
существующих средств автоматизированной отладки. В связи с этим
предлагается решение, автоматизирующее преобразование отладочной
информации к виду, облегчающему проектировщику восприятие проекта и
обеспечивающему возможность дальнейшего использования полученной на
данном этапе проектирования информации с целью интерактивной отладки
компонентов создаваемого изделия.
 104

4.1.1 Автоматизация обработки отладочной информации

В процессе взаимодействия проектировщика и САПР формируется

отладочная информация. Отладочная информация добавляется пользователем
в исполняемые файлы при указании специальных ключей компилятора [32,
43]. Она позволяет:
• устанавливать точки останова по номеру строки в файле исходного
кода, устраняя необходимость работы пользователя с физическими адресами;
• отображать и производить редактирование значений глобальных и
локальных переменных и параметров функций;
• просматривать стек вызовов;
• выполнять пошаговое выполнение программы в изделии в
соответствии со строками исходного кода взамен единичных инструкций
ассемблера.
Для загрузки в аппаратные модули и выполнения в среде установленной
в БСКИ операционной системы средства разработки компилируют проект в
файл ELF (Executable and Linkable Format) с возможностью включения
отладочной информации. До недавнего времени, компилятор целевой
платформы, используемый разработчиками БСКИ, создавал исполняемые
файлы, содержащие отладочную информацию в формате stabs. Данный
формат не имеет официальной документации, что, в результате, приводит к
отсутствию единой формы представления и документирования отладочных
записей, изменяющейся с выпуском обновлений компилятора [26].
Современные компиляторы генерируют отладочную информацию в
соответствии со стандартизированным форматом DWARF. Он подразумевает
хранение данных изделия в виде древовидной структуры. Каждый из узлов
дерева, называемый DIE (Debug Information Entry), имеет родителя и может
иметь потомков. Узел содержит информацию о своем типе и список
атрибутов. В атрибутах может содержаться всевозможная информация, такая
как ссылки на другие узлы или структуры данных. DIE делятся на два типа:
 105

содержащие описание данных и описание исходного кода. Каждый объект

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

Рисунок 4.1. Пример рабочего окна программы, производящей визуализацию

структуры отладочной информации
 106

Отладочная информация хранится в бинарном формате и без

предварительной обработки не приспособлена для восприятия человеком.
Первый раз преобразование производится с помощью утилиты dwarfdump,
преобразующей бинарную запись к текстовому виду. Следующий этап работы
подразумевает преобразование текстового файла в древовидную структуру с
подразделением на секции. Проектировщику предлагается
специализированная программа, после указания входного файла, производит
расшифровку текста и представляет структуру отладочной информации в
удобном для восприятия и манипуляций виде. Пример рабочего окна
программы приведен на рис. 4.1.
На рис. 4.2 показана схема переходов конечного автомата, отвечающего
за структурный разбор, результатом которого является иерархическое дерево,
содержащее все секции, описанные в исходном файле. Для реализации
необходимой функциональности выделено двадцать восемь состояний:
1. Initial. Начальное состояние, в котором находится автомат до
поступления первых данных для разбора.
2. Debug Line Section Found. Найдена секция .debug_line, содержащая
информацию о номерах строк для конкретной единицы компиляции
(исходного файла).
3. Debug Line Section Info Found. Найдена вспомогательная
информация, описывающая текущую секцию.
4. Debug Info Section Found. Найдена секция .debug_info, основная
секция, содержащая записи отладочной информации.
5. Debug Pubnames Section Found. Найдена секция .debug_pubnames.
Для того, чтобы облегчить и ускорить поиск записей о различных
программных сущностях (объектах данных, функциях и типах), в файле могут
содержаться секции, делающие возможным поиск по имени объекта. Секция
.debug_pubnames содержит информацию об именах функций и структур
данных.
 107

12 7 6 5 4 2

13 9 17 15 3

14 10 8 18 16

11 20 19

21

22

26 23 24

27 28 25

Рисунок 4.2. Схема переходов конечного автомата для преобразования

отладочной информации
 108

6. Debug String Section Found. Найдена секция .debug_string,

представляющая собой таблицу используемых в программе строк. При
необходимости, запись отладочной информации ссылается на данную
таблицу, указывая смещение искомой строки.
7. Debug Aranges Section Found. Найдена секция .debug_aranges,
представляющая собой таблицу диапазонов адресов. Записи таблицы
описывают каждую единицу компиляции и соответствующие ей адреса
памяти.
8. Debug Aranges Compile Unit Found. Найдена информация о единице
компиляции, предваряющая записи о диапазоне.
9. Debug Aranges Blank Found. Найдена пустая строка в секции, которая
либо предваряет первую запись, либо разделяет последующие в определенном
порядке.
10. Debug Arange Start Found. Найдена запись, описывающая диапазон
адресов единицы компиляции.
11. Debug Arange End Found. Найдена строка, отмечающая конец записи
о диапазоне.
12. Debug Frame Section Found. Найдена секция .debug_frame.
Отладочная информация дает возможность производить виртуальное
распутывание, определяя архитектурно независимую основу для хранения
информации о том, как те или иные процедуры сохраняют и восстанавливают
состояние регистров в процессе своей деятельности. Секция содержит записи,
описывающие местонахождение информации, относящейся к определенной
функции.
13. Frame Description Entries Section Found. Найдена строка,
обозначающая начало массива записей.
14. Frame Description Entry Found. Найдена запись с информацией о
фрейме.
15. Line Number Offset Found. Найдена строка, соотносящая номер
строки со смещением в памяти.
 109

16. Line Number Offset End Found. Найден конец записей, описывающих
местонахождение строк.
17. Compile Unit Found. Найдено описание единицы компиляции.
18. Compile Unit Debug Information Entry Found. Найдена запись
отладочной информации, соответствующая текущей единице компиляции.
19. Compile Unit Attribute Found. Найден атрибут записи отладочной
информации.
20. Compile Unit End Found. Найден конец описания единицы
компиляции.
21. Local Symbols Section Found. Найден раздел, содержащий
информацию о типах и переменных, используемых в пределах текущей
единицы компиляции
22. Local Symbols Debug Information Entry Found. Найдена запись
отладочной информации из раздела локальных переменных.
23. Local Symbols Attribute Found. Найден атрибут записи отладочной
информации.
24. Loclist Found. Найдено начало массива, описывающего объект, чье
местоположение может меняться в течении его существования.
25. Loclist Entry Found. Найдена запись, описывающая одно из
положений непостоянного объекта.
26. Ranges Found. Когда набор адресов записи отладочной информации
не может быть представлен в виде одного смежного диапазона, атрибут
содержит запись в виде списка диапазонов. Данное состояние сигнализирует
о том, что найдено начало списка.
27. Ranges Header Found. Найден заголовок, описывающий список
диапазонов.
28. Ranges Entry Found. Найдена запись, описывающая один из
диапазонов массива.
Помимо показанных на схеме состояний существует еще ошибочное
состояние, в которое можно попасть из любого другого при возникновении
 110

ситуации, не предусмотренной в конкретной ситуации. После этого текущая

секция помечается как поврежденная и автомат переводится в состояние
Initial.
После визуализации отладочного дерева возникает необходимость
произвести вычисление специальных выражений, описывающих
местонахождение некоторых переменных и структур данных. Например,
выражение:
DW_OP_reg3 DW_OP_piece 4 DW_OP_reg10 DW_OP_piece 2
указывает, что значение переменной размером 6 байт разбито на две
части: первые четыре байта находятся в третьем регистре, следующие два
байта хранятся в регистре 10.
На данном этапе проводится полный анализ полученной структуры в ходе
которого определяются:
• местонахождение переменных в памяти, регистрах, стеке и т. д.;
• область видимости каждой переменной (локальная, глобальная);
• состав сложных типов и структур (с возможностью развернуть и
изучить простые типы, составляющие интересующий объект);
• соотнесение строк исходного кода программы с физическими
адресами машинных инструкций для пошаговой отладки.
Полученная информация позволяет программе отладчику подключиться
к исполняемой задаче, а пользователю – управлять ходом ее работы, реализуя
функции, необходимые для интерактивной отладки.

4.1.2 Анализ проектных решений

Дальнейшая работа с программой-отладчиком имеет типовой набор

функций [6, 72], но, тем не менее, обладает рядом технических отличий.
Первым и главным их них является автоматизированная среда, в которой
происходит процесс отладки. Программное обеспечение бортового
картографического комплекса выполняется под управлением
 111

специализированной операционной системы реального времени. Поэтому,

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

4.2. Использование принципа эмуляции аппаратного обеспечения в

системе автоматизированного проектирования

Технология эмуляции вычислительных процессов и процессов обмена,

протекающих в информационно-управляющих системах подвижных
объектов, сегодня широко используется при разработке большинства
программно-управляемых изделий. Значительные успехи достигнуты
исследователями в создании средств эмуляции для отработки аппаратных
решений[49]. Наглядными примерами являются среды проектирования и
программирования аппаратных средств Xilinx Foundation, Max Plus, LabVIEW,
MicroCap и др.
Технология эмуляции позволяет анализировать поведение
вычислительного узла (модуля авионики) на предварительных этапах
проектирования (эскизно-техническое проектирование, техническое
 112

предложение), когда в распоряжении разработчика отсутствует готовое

физическое устройство и требуется оценить целесообразность принятия и
последующего внедрения в производство какого-либо проектного решения [7,
62].
Применение технологии эмуляции при разработке вычислительных
компонентов БСКИ сегодня находится в зачаточном состоянии и в
значительной степени определяется возможностями используемой
разработчиками среды проектирования. Вместе с этим технология эмуляции
функционального поведения вычислительной платформы позволят
различным группам разработчиков (программистам, интеграторам проекта,
тест-инженерам и пр.) работать одновременно, уменьшая, тем самым,
суммарное время разработки изделия и способствуя принятию правильного
проектного решения. Особенно актуально применение технологии эмуляции
при разработке компонентов для систем, к функционированию которых
предъявляются повышенные требования по безопасности целевого
применения, в частности, к авиационным вычислительным системам и
комплексам[4].
Актуальность разработки технологии эмуляции при проектировании
БСКИ обусловлена несколькими факторами. Во-первых, аппаратное
обеспечение вычислительной системы авионики на начальных этапах
проектирования либо отсутствует (еще не изготовлено в производстве), либо
изготовлено в единичным (опытном) экземпляре и используется различными
группами разработчиков, находящимися в состоянии «взаимной
конкуренции» за обладание временным ресурсом использования образца.
Во-вторых, возможности современных отладочных средств,
используемых при тестировании аппаратно-программного обеспечения
сложных программно-управляемых систем, ограничены, особенно, если
отладке подлежит компонент низкоуровневого системного программного
обеспечения [51, 55].
 113

В-третьих, проверить выполнение некоторых ветвей программного кода

на реальной аппаратной платформе в ряде случаев оказывается
проблематично, а иногда и вовсе невозможно. Примером такого случая
является фрагмент программного кода, реализующий реакцию
вычислительной системы на различные отказы узлов (модулей) аппаратуры, в
том числе и отказ самого модуля-вычислителя в составе вычислительной
системы или комплекса.
Наконец, исполнение на физической аппаратуре большого объема тест-
программ, необходимых для прохождения этапа сертификации программного
обеспечения авионики [22, 63], даже при использовании средств
автоматизации является достаточно трудоемкой процедурой, а в процессе
разработки комплексов программ и их сертификации такие эксперименты
выполняются многократно.

4.2.1 Принцип построения программы-эмулятора

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

в состав САПР АРМ имитировать на инструментальной ЭВМ другую
программу или устройство. Применение программы-эмулятора позволяет,
помимо прочего, облегчить процесс разработки ОСРВ для изделий
интегрированной модульной авионики, соответствующих отраслевому
стандарту ARINC 653 [65, 80]. Дальнейшее использование эмуляции
целесообразно на этапе разработки системного и прикладного программного
обеспечения, работающего под управлением ОСРВ, а также на этапе
разработки конструкторской документации и позволяет решить проблему
совместимости в будущем проекте аппаратного и программного
компонентов[28].
В качестве примера приводится целевая аппаратная платформа,
представляющая собой базовый вычислительный модуль авионики —
процессорную плату, реализованную на основе микропроцессора архитектуры
 114

MIPS4. Функциональная схема базового вычислительного модуля авионики

приведена на рис. 4.3. В состав аппаратных средств модуля входят:
• цифровой процессор ЦП 1;
• цифровой процессор ЦП 2;
• контроллер-коммутатор памяти, реализованный на базе элементов
программируемой логики;
• контроллер RS-232;
• системный таймер;
• аппаратные средства взаимодействия между процессорами (система
«почтовых ящиков», обеспечивающая обмен сообщениями между
процессорами), реализованные на базе элементов программируемой логики;
• постоянное запоминающее устройство ПЗУ общего доступа, в
качестве которого использовалась FLASH-память;
• несколько оперативных запоминающих устройств (ОЗУ),
объединенных по схеме независимых «банков ОЗУ»;
• ОЗУ общего доступа (ОЗУОД);
• контроллер PCI для процессора ЦП 2, подключенный по системному
параллельному интерфейсу CPCI, необходимый для информационного обмена
вычислительного модуля в составе многомодульной вычислительной
системы;
• контроллер PCI, необходимый для подключения двух плат-мезонинов
к вычислительному модулю по системному параллельному интерфейсу PMC;
• управляющий микроконтроллер (МК), имеющий доступ к ПЗУ
процессоров через свою внешнюю шину;
• ОЗУ общего доступа ЦП 1 и МК;
• ОЗУ общего доступа ЦП 2 и МК.
 115

ОЗУ 8Мб ОЗУ 8Мб

ОЗУ 8Мб

ЦП 1 ЦП 2
Контроллер RS-232

Системный таймер

Контроллер
Шина ЦП 1

PCI

ОЗУ
Контроллера
PCI 8Мб

ОЗУОД 8Мб

Почтовые ящики

ПЗУ 64Мб

Внешняя шина МК

Общее ОЗУ Общее ОЗУ

ЦП 1 и МК
МК ЦП 2 и МК

Рисунок 4.3. Функциональная схема базового вычислительного модуля,

работа которого имитируется в эмуляторе

Эмулятор представляет собой совокупность программных средств,

исполняемых на инструментальной ЭВМ, входящей в состав АРМ, в
 116

диалоговом режиме. В задачи, решаемые имитатором вычислительного

модуля, входят:
• эмуляция работы следующих аппаратных устройств: процессоров,
шины адрес/данные, ОЗУ (в том числе режим общего доступа для
процессоров), ПЗУ, контроллера RS-232, системного таймера, аппаратных
средств взаимодействия между процессорами;
• эмуляция выполнения программного обеспечения на двух
процессорах одновременно;
• возможность задания различных режимов работы модуля,
независимое управление пуском, остановкой обоих процессоров;
• загрузка файлов в ячейки памяти ОЗУ/ПЗУ эмулируемого модуля и
чтения ячеек памяти ОЗУ/ПЗУ с сохранением данных в файле;
• реализация окна консольного терминала интерфейса RS-232;
• дизассемблер содержимого ячеек памяти;
• отображение полного состояния всех устройств модуля и
возможность изменения состояния любого устройства во время отладки
программного кода;
• возможность установки пользователем точек остановки по событиям,
возникающим в процессе работы эмулируемой аппаратуры (исключение,
переполнение, изменение, обращение по адресу, обращение к ОЗУ и пр.);
• возможность отслеживать данные в памяти в соответствии с их
типами (низкоуровневая отладка), возможность устанавливать точки останова
при изменении данных в памяти;
• обеспечение возможности отладки программного кода при его
выполнении с использованием механизма «виртуальной памяти»;
• сохранение истории выполнения программы в различных режимах
(последовательность вызова подпрограмм, последовательность выполняемых
процессором инструкций в пределах выбранной функции или программы в
целом);
 117

• сохранение полного состояния конфигурации модуля в «точках

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

4.2.2 Сравнение программы-эмулятора с существующими

аналогами

Таблица 2. Сравнительные характеристики платформ эмуляции

Собственная
№ Характеристика QEMU Wind River
разработка
1. Эмулируемая аппаратная: бортовой аппаратная: программная:
платформа вычислительный различные виды выполнение
модуль МВ70 процессоров и приложений
(включая уникальные периферия ARINC 653 под
контроллеры персонального управлением ОС
собственной компьютера VxWorks
разработки) и
различные его
модификации
2. Поддержка отладки приложения, нет приложения,
приложений соответствующие соответствующие
стандарту ARINC 653 стандарту
под управлением ОС ARINC 653 под
ЭОС управлением ОС
VxWorks
3. Поддержка разработки да (ОС ЭОС) нет нет
ОС
4. Инструментальная Windows Linux Windows, Linux
платформа ОС
3. Установка Копирование Установка и JTAG-эмуляторы
исполняемого файла настройка из Wind River ICE /
на компьютер командной строки Wind River Probe,
среда разработки
и отладки Wind
River Workbench
и отладочные
платы Wind River
4. Графический интерфейс есть нет есть
 118

Эмуляция, чаще всего, полностью имитирует аппаратную среду[77].

Исходя из перечисленных выше задач предлагаемого эмулятора, были
рассмотрены в качестве аналогов коммерческий эмулятор фирмы Wind River
и свободно распространяемый эмулятор QEMU. В таблице 2 представлено
сравнение характеристик эмуляторов (предлагаемого и аналогов).
При разработке эмулятора были учтены все положительные и
отрицательные стороны известных эмуляторов, а также особенности
разрабатываемого продукта прикладного характера. Из табл. 2 видно, что
эмулятор существенно упрощает разработку проекта и дает возможность
генерировать документацию на проект. На рис. 4.4 и 4.5 приведены
скриншоты, дающие представление о графическом интерфейсе пользователя,
реализованном эмулятором Wind River Workbench и предлагаемым
эмулятором соответственно.

Рисунок 4.4. Среда разработки и отладки Wind River Workbench

 119

Рисунок 4.5. Рабочее окно предлагаемой программы-эмулятора в режиме

отладки ПО для базового вычислительного модуля целевой платформы

4.2.3 Генерация проектных решений

Разработка эмулятора выполняется в несколько этапов. Результатом

первого из них является модель процессорного модуля (см. рис. 4.3),
способная выполнять код загружаемого программного обеспечения и
выводить сообщения, направляемые на консоль, в окне терминала
инструментальной ЭВМ [5]. Для проверки работы модели изделия создаются
тестовые программы, выполнение которых на эмуляторе и на аппаратуре
должно показать полную идентичность исполнения инструкций и
приемлемую близость рассчитываемого на эмуляторе времени выполнения
программы к реальному времени выполнения той же программы на
физической аппаратуре. Таким образом подтверждается правильность
предложенных разработчиками моделей физических устройств.
 120

На следующем этапе производится параллельная работа над

расширением функциональных возможностей эмулятора и, одновременно с
этим, разработка ОС РВ. Таким образом, код ОС РВ отлаживается с
использованием имеющейся модели и, вместе с тем, выполняется
тестирование и правка самой программы-эмулятора как средства
автоматизации проектирования. Аналогичный подход часто используется при
разработке компиляторов языков программирования, когда предыдущая
версия компилятора используется для компиляции кода следующей версии
самого компилятора. В данном случае совершенствуются и модели
физических устройств.
В результате экспериментов за довольно короткий срок реализуются и
исследуются несколько вариантов проектных решений будущего изделия, из
которых потом выбирается наилучший. Таким образом, весь объем работ
второго этапа проводится с использованием эмулятора и практически не
требует наличия у разработчиков целевой аппаратной платформы, заданной в
САПР на уровне моделей.
Корректность набора тестов, дополнительно проверяется в среде
VxWorks (распространенной ОС РВ, соответствующей стандарту ARINC 653
и используемой в качестве «эталонной»). Следует отметить, что проверка, для
удобства, проводится не на реальной аппаратной платформе, а на эмуляторе
Wind River Workbench, выполняющемся на ПК.
В завершение этапа проводится полное тестирование на целевой
аппаратной платформе, выявляющее дополнительные ошибки проекта,
которые могут быть не обнаружены при тестировании на эмуляторе. Такие
ошибки, как правило, не превышают 5% от общего числа выявленных ошибок.
Следующий этап разработки связан со значительным расширением
набора тестов, необходимым для выполнения сертификации проекта в
соответствии с нормативными документами, принятыми в авиационной
отрасли. При разработке тестов возникают определенные сложности. В
отличие от прикладного ПО авионики, которое разрабатывается для
 121

конкретного изделия, операционная система, являясь универсальным ПО,

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

контроллера получает возможность отлаживать программный код, пользуясь

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

начало формального
тестирования

Подготовка и модификация
да
проекта

Формальное интеграция с целевой

тестирование аппаратной платформой

изменение конфигурации и Отклонения

нет
драйверов ПО значительны

компиляция тестов и
конфигурации для компиляция тестов и
эмулируемой аппаратной конфигурации для целевой
платформы аппаратной платформы

пакетное выполнение
пакетное выполнение
нет набора тестов на целевой
набора тестов на эмуляторе
аппаратной платформе
да

автоматический анализ автоматический анализ

протоколов тестов протоколов тестов

нет
дополнительный дополнительный
“визуальный” анализ “визуальный” анализ
протоколов тестов протоколов тестов

Тесты Тесты
пройдены пройдены

да

завершение формального
тестирования

Рисунок 4.6. Технология разработки ОС с использованием программы-

эмулятора

тестов применяется общее инструментальное ПО. Наличие у каждого

пользователя эмулятора позволяет распараллелить разработку и отладку
отдельных компонентов проекта и тестов. Каждый пользователь, вносящий
 124

изделия в проект имеет возможность самостоятельно выполнить

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

4.2.4 Архитектура программы-эмулятора САПР

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

использованием эмулятора. При создании нового проекта в первую очередь
необходимо определиться с составом эмулируемой аппаратной платформы.
Для этого в среде графического редактора с использованием графических
отображений устройств создается схема модуля. Каждый графический объект
связан с функциональным описанием компонента в формате xml. По
завершении работы с редактором схемы модуля пользователь получает файл
в формате xml, представляющий собой функциональную схему модуля. Этот
файл передаётся в САПР «Конфигуратор» для создания данных конфигурации
устройства. Результирующие файлы конфигурации вместе с функциональной
схемой модуля загружаются в среду эмуляции, в которой и происходит
выполнение приложений. При работе с программой-эмулятором имеется
возможность использовать функции автоматизации отладки и тестирования.
После завершения работы с эмулятором проектирование изделия
продолжается с помощью специализированного программного обеспечения
(например, Altium Designer). Полученный в результате файл проекта печатной
платы модуля передается на вход программы, обеспечивающей
автоматизированное формирование конструкторской документации на
изделие.
 Библиотека описаний Библиотека графических
компонентов (xml) примитивов Эмулятор

Функциональная Просмотр содержимого

схема модуля памяти и регистров

Редактирование набора
аппаратных компонентов
эмулируемой платформы Среда эмуляции Системное ПО БСКИ

Графическое Функциональная Модуль тестирования Модуль отладки

представление схема модуля
схемы (xml)

125
Редактор схемы модуля

Выходные файлы Среда проектирования

Создание конфигурации (результаты тестирования, аппаратных решений
компонентов аппаратной документация) (Altium Designer)
платформы БСКИ

Автоматизированная Автоматизированное
Файлы конфигурации (*.с) проверка результатов формирование
документаци
Конфигуратор
Библиотека шаблонов
результатов тестирования
Результаты • Проектное решение
нет совпадают с да • Конструкторская
шаблонами? документация

Рисунок 4.7. Функциональная схема процесса проектирования БСКИ с использованием программы-эмулятора

 126

Результатом выполнения тестовых задач являются выходные файлы,

содержащие результаты тестирования и предварительный проект
конструкторской документации изделия. Эти файлы передаются в среду
автоматизированной проверки результатов тестирования, которая сравнивает
полученные данные с заранее составленными шаблонами. В случае
неудачного исхода проверки происходит возврат к предыдущим этапам
проектирования для исправления проблемных мест проектируемого изделия.
После удачного выполнения всех проверок итоговые результаты
разработки формируются в готовое проектное решение с пакетом
конструкторской документации.
На рис. 4.8 приведена упрощенная диаграмма классов эмулятора,
отражающая связь архитектуры эмулятора с реализуемыми функциями.
Центральный процессор в предложенной системе эмуляции реализуется
посредством класса-интерпретатора. Такое исполнение подразумевает
пошаговый переход от предыдущей машинной инструкции к следующей с
выполнением операций, семантически эквивалентных оригинальным
инструкциям эмулируемого изделия. В состав класса входит массив битовых
переменных, отражающий состояние регистров процессора; байтовый массив,
являющийся представлением кэш-памяти; набор функций, изменяющих
внутреннее состояние объекта в зависимости от получаемых машинных
инструкций.
Память устройства эмулируется в виде объектов, каждый из которых
содержит ключ, указывающий на область памяти размером в машинное слово,
и «значение», содержащее информацию, хранящуюся по указанному ключом
адресу. Для записи и чтения информации используется набор функций,
преобразующих запросы, поступающие от эмулируемых устройств.
Базовым классом для всех эмулируемых устройств является класс Device,
реализующий интерфейсы, необходимые как собственно для эмуляции
процессов физических устройств, так и для обеспечения выполнения других
сервисных функций. Все потомки класса Device подразделяются на три
 127

основные группы. Классы, эмулирующие устройства, выполняющие

программы, реализуют дополнительный интерфейс ICPU. Классы,
эмулирующие функциональность шины данных, реализуют дополнительный
интерфейс IBus. Большую часть в иерархии классов, эмулирующих
аппаратуру целевой платформы, составляют потомки класса BusDevice,
эмулирующие устройства, подключаемые к шине данных. Для этого класс
BusDevice реализует дополнительный интерфейс IBusDevice. Потомками
этого класса являются классы, эмулирующие память, системный таймер,
контроллер USB и др.

ITracer IDebugger
Debug Simulator
BreakPoint ISimulator

Device

Watcher IVariable IDev Board

CPU ICPU Bus IBus BusDevice IBusDev

Memory TSys USB

Terminal ITerminal

Рисунок 4.8. Диаграмма классов программы-эмулятора САПР

Класс Board описывает вычислительный модуль целевой платформы,

содержащий заданный набор устройств, реализуемых классами,
порождаемыми от Device. Класс Simulator отвечает за процесс эмуляции
выполнения программы, включая сброс и останов процессоров, анализ
активности установленных событий отладки и вычисление времени
выполнения программы. Класс Debug реализует механизмы трассировки
 128

выполнения программ и работы с событиями отладки. Класс Watcher

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

4.2.5 Перспективы развития средств эмуляции аппаратного обеспечения

Дальнейшее применение эмулятора возможно в целях разработки

проектов бортовых систем, построенных по принципам интегрированной
модульной авионики, и использующих новую ОСРВ. Очевидно, что
использование эмулятора целевой платформы при разработке изделий
авионики может обеспечить те же преимущества, что и при разработке БСКИ:
1) автономность разработчиков, т.е. возможность параллельной
разработки составной части проекта и ее отладки коллективом
проектировщиков в чисто виртуальной среде без использования целевой
платформы;
2) опережающую разработку компонентов проекта, т.е. разработку
части проекта до появления целевой платформы и даже до выбора конечной
конфигурации целевой платформы. По результатам такой опережающей
разработки можно сделать оценку необходимых аппаратных ресурсов
(количества процессоров, объемов памяти), подготовить конструкторскую
документацию и сформировать окончательные требования технического к
составу целевой аппаратной платформе;
3) комфортную высокоуровневую отладку функциональных
приложений с возможностью сохранения результатов деятельности, и
возможностью повторения выполненных действий;
4) автоматизацию тестирования;
5) эмуляция сохраняет вид и поведение оригинальной системы;
 129

6) несмотря на высокую изначальную стоимость создания эмулятора,

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

4.3 Методы автоматизации процесса тестирования бортовых систем

картографической информации

4.3.1 Автоматизация процесса тестирования БСКИ

Проведение тестирования программного обеспечения является

неотъемлемой частью процесса проектирования [42, 80]. Выполнение этой
процедуры в ручном режиме может потребовать повышенных временных
затрат и, при длительном выполнении, не исключено возникновение ошибок,
вызванных усталостью оператора. Использование специализированных
программ, позволяющих автоматизировать прогон тестов и последующую
проверку результатов тестирования позволяет в значительной мере
минимизировать время выполнения процедуры, вместе с тем, снижая влияние
человеческого фактора.
Выполнение программы проверки в рамках одного раздела ОСРВ требует
загрузки в память аппаратного обеспечения БСКИ (либо его программной
имитации) определенного набора компонентов данных:
 130

• инициализатор выполняет подготовку имеющихся ресурсов к

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

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

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

Рисунок 4.9. Пример окна предлагаемого программного решения для

автоматизации тестирования БСКИ

Запись логов достигается простым созданием потока, записывающего в

файл всю информацию, получаемую по каналу вывода. Пример окна
предлагаемого решения, выполняющего автоматизацию тестирования в среде
эмуляции приведен на рис. 4.9. В левой части расположен список тестов для
 132

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

имеющихся. Дополнительно в списке приводится информация о
предполагаемых таймаутах выполнения (по внутреннему времени
эмулируемой системы и внешнему(реальному) времени) и критерии
завершения. Выбрав интересующую строчку можно вызвать дополнительный
диалог (справа), позволяющий редактировать интересующие значения в
интерактивном режиме. После настройки всех необходимых параметров
выполняется запуск текущего прогона, во время которого возможно
выполнение других работ.
Для сертификации оборудования на соответствие требованиям к
изделиям авионики, описываемым отраслевым стандартом КТ-254, а также
встроенного программного обеспечения системы в соответствии с
требованиями КТ-178В/С, необходимо проведение процесса верификации
изделия. Верификация подразумевает собой выполнение набора тестов, состав
которого определяется сертифицирующими органами, и оформление
полученных результатов в форме, определяемой совместно участвующими
сторонами. Таблица 3 представляет собой пример оформления результатов
одного теста из набора верификации.
Таблица 3. Пример оформления результата проведения теста
API.MEMORY_READ_CHECK успешно
Проверка чтения участка памяти.
Проверяются качественные и временные характеристики операции чтения
памяти
Метод проверки: Тестирование Тип: Исходное
Обоснование: Данное требование определено в документе
ВИДК.029506.081.

Поля таблицы содержат идентификатор теста, статус выполнения,

краткое и развернутое описания, метод проверки, тип и обоснования.
Предлагаемое программное решение позволяет формировать в
автоматизированном режиме документ, содержащий результаты
 133

тестирования, оформленные в соответствии с приведенными требованиями.

При этом возможно внесение изменений в шаблон оформления.

9
T, ч
8

0
10 20 30 40 50 60 70 80 90 100

N, шт.
Ручное оформление Автоматизированное формирование

Рис.4.10. Сравнение времени оформления сертификационной документации в

ручном и автоматическом режимах. Т – время выполнения, N – количество
тестов.

Для оценки снижения трудозатрат на оформление сертификационной

документации был проведен ряд испытаний, в ходе которых выполнялась
подготовка документов ручным вводом и при помощи предлагаемой
программы автоматизации тестирования. Полученные результаты приведены
на рис. 4.10. Из графиков можно судить о том, что, помимо сокращения
трудозатрат, в случае с автоматизированным формированием документации
наблюдается практически линейный рост временных затрат в зависимости от
количества описываемых тестовых испытаний, в то время как при ручном
оформлении наблюдается скачок роста при работе с количеством тестов,
превышающим 50 единиц. Такие результаты объясняются фактором усталости
 134

работника при выполнении монотонных задач. Поскольку типовой набор

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

4.3.1 Автоматизированная проверка результатов тестирования

После того, как завершится выполнение всех выбранных проверочных

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

Рисунок 4.11. Пример окна предлагаемого программного решения,

автоматизирующего проверку результатов тестирования

На рис. 4.11 приведен пример окна предлагаемой программы,

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

Рисунок 4.12. Сравнение результатов тестирования с ожидаемыми

значениями

4.4 Автоматизация процесса оформления конструкторской

документации компонентов бортовой системы картографической
информации

При наличии готового проекта аппаратного компонента бортовой

системы картографической информации в формате, совместимом с форматом
выходных файлов САПР Altium Designer, являющейся основным средством
проектирования печатных плат для изделий в различных отраслях
 137

промышленности, имеется возможность автоматизированным образом

сформировать пакет конструкторской документации на изделие.
Утилита «CDMake» подготавливает следующие виды конструкторской
документации:
• схема подключения модуля (Э5);
• схема межмодульного соединения (Э4);
• перечень элементов (ПЭЗ);
• спецификация элементов для оформления заказа на комплектующие;
• таблица цепей связей для монтажа.
Выходные данные представляются в виде текстовых документов,
совместимых с используемыми в настоящее время системами редактирования
текстовой документации (Microsoft Word, OpenOffice). Оформление
документов выполнено в соответствии с требованиями отраслевых
стандартов.
90

80
Снижение трудоемкости, %

70

60

50

40

30

20

10

0
1 2 3 4 5

Рис. 4.13. Уровни снижения трудозатрат на подготовку различных видов

конструкторской документации: 1 – схема подключения модуля, 2 – схема
межмодульного соединения, 3 – перечень элементов, 4 – спецификация
элементов, 5 – таблица цепей связей.
 138

На рис. 4.13 показаны уровни снижения трудозатрат на подготовку

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

4.5 Выводы

Неотъемлемой частью разработки БСКИ является отладка БСКИ с

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

ЗАКЛЮЧЕНИЕ
Решение задачи автоматизации процессов, связанных с разработкой,
отладкой и тестированием БСКИ имеет важное народно-хозяйственное
значение для выпуска качественных изделий авионики. В работе предложены
решения, повышающие скорость взаимодействия подсистем, формирующих
индикационные кадры с навигационной информацией, представлены
средства, позволяющие автоматизировать процессы создания компонентов
БСКИ и описан процесс параллельной разработки нескольких компонентов
проекта, позволяющий сократить временные затраты на выпуск качественной
продукции.
Таким образом, основными результатами работы являются:
1. Предложена структура данных, повышающая скорость доступа
пользователя к геоинформационным ресурсам в процессе формирования
индикационных кадров для отображения картографической информации в
процессе полета.
2. Предложен алгоритм автоматизированного формирования
индикационного кадра с учетом параметров, задаваемых пользователем и
условий, в которых осуществляется пилотирование.
3. Предложена схема автоматизированного рабочего места для
создания компонентов БСКИ, включающая программное, математическое,
информационное и технологическое обеспечение САПР.
4. Предложено программное средство для автоматизации процессов,
связанных с разработкой компонентов БСКИ, на основе средств эмуляции
аппаратной платформы БСКИ.
5. Предложен набор средств, автоматизирующих в составе АРМ
процессы настройки взаимодействия платформы инструментальной ЭВМ и
аппаратной платформы БСКИ и его компонентов.
 140

СПИСОК ЛИТЕРАТУРЫ
1. Батова С.В., Коновалов П.В., Благонравов С.А., Уткин С.Б. Автоматизация
конфигурирования операционных систем реального времени // Навигация
и управление движением / Материалы XVI конференции молодых ученых,
СПб, ГНЦ РФ ОАО «Концерн «ЦНИИ Электроприбор», 2014, с.384-388.
2. Берлянт А.М. Геоинформационное картографирование. // М.: 1997. – 64 с.
3. Берлянт А.М. Картография. Толкование основных терминов // М.: ГИС-
Ассоциация, 1998. С. 91–104.
4. Благодатских В.А. Стандартизация разработки программных средств / Под
ред. О.С. Разумова. // М.: Финансы и статистика, 2005. – 288с.
5. Богданов А.В., Кирсанова Ю.А., Уткин С.Б., Шек-Иовсепянц Р.А.
Некоторые вопросы создания и использования виртуальных и физических
моделей при разработке аппаратных и программных частей управляющих
цифровых комплексов // Мир авионики, 2001, №1, с.36-39.
6. Борисов Ю.И. Отечественная электронная промышленность и
компонентная база. Перспективы развития. // Электроника: НТБ, 2006, №2.
– с. 6 – 9.
7. Брауде Э. Технология разработки программного обеспечения. // СПб:
Питер, 2004. – 655с.
8. Бурдонов, И.Б., Косачев А.С., Пономаренко В.Н. Операционные системы
реального времени // М.: Институт системного программирования РАН,
2006. - 49 с.
9. Бурков, В.Н., Новиков Д.А. Как управлять проектами: научно-
практическое издание // М.: СИНТЕГ-ГЕО, 1997. - 188 с.
10. Валов А.В. Микропроцессоры и их применение в системах управления.
Учебное пособие // Челябинск, 2012. - 58 с.
11. Варфоломеев И.В., Савельев А.С. Представление и обработка
пространственных данных в ГИС: Методические указания // Красноярск:
КГТУ, 2003 – 34 с.
 141

12. Варфоломеев И.В., Савельев А.С., Ермакова И.Г. Алгоритмы и структуры

данных геоинформационных систем: Методические указания //
Красноярск: КГТУ, 2001 – 31 с.
13. Гатчин Ю.А., Видин Б.В., Жаринов И.О., Жаринов О.О. Метод
автоматизированного проектирования аппаратных средств бортового
оборудования // Известия вузов. Приборостроение, 2010, Т.53, №5, с.5-10.
14. Гатчин Ю.А., Видин Б.В., Жаринов И.О., Жаринов О.О. Модели и методы
проектирования интегрированной модульной авионики // Вестник
компьютерных и информационных технологий, 2010, №1, с.12-20.
15. Гатчин Ю.А., Жаринов И.О. Основы проектирования вычислительных
систем интегрированной модульной авионики: монография // М.:
Машиностроение, 2010, 224 с.
16. Гатчин Ю.А., Жаринов И.О., Жаринов О.О. Архитектура программного
обеспечения автоматизированного рабочего места разработчика бортового
авиационного оборудования // Научно-технический вестник
информационных технологий, механики и оптики, 2012, №2 (78), с.140–
141.
17. Географические информационные системы. Координатная основа. Общие
требования. ГОСТ Р 52572-2006. М.: Стандартинформ,2006.
18. Замай С.С., Якубайлик О.Э. Программное обеспечение и технологии
геоинформационных систем. Учебное пособие // Красноярск, 1998 – 110 с.
19. Жаринов И.О., Кирсанова Ю.А., Коновалов П.В., Костишин М.О.
Алгоритм формирования и вывода картографических изображений в
системах навигации пилотируемых летательных аппаратов //
Мехатроника, автоматизация, управление, 2014, №8
20. Жаринов И.О., Жаринов О.О. Бортовые системы картографической
информации. Принципы построения геоинформационных ресурсов: Учеб.
пособие. // СПб: ГУ ИТМО, 2008 – 48 с.
 142

21. Жаринов И.О., Жаринов О.О. Бортовые средства отображения

информации на плоских жидкокристаллических панелях: Учеб. пособие //
Информационно-управляющие системы. СПб: ГУАП, 2005 – 144 с.
22. Жаринов И.О., Жаринов О.О., Костишин М.О., Коновалов П.В.
Исследование распределения яркостного контраста изображения
геоинформационных данных авионики для основных отображаемых
цветов и их оттенков // Сборник трудов молодых ученых, аспирантов и
студентов научно-педагогической школы кафедры ПБКС
«Информационная безопасность, проектирование и технология элементов
и узлов компьютерных систем» / Под ред. Ю.А. Гатчина, СПб:
Университет ИТМО, 2015, с.41-46.
23. Жаринов И.О., Коновалов П.В. Классификация структуры данных,
используемых при отображении геоинформационных ресурсов в бортовых
системах картографической информации // Сборник трудов молодых
ученых, аспирантов и студентов научно-педагогической школы кафедры
ПБКС «Информационная безопасность, проектирование и технология
элементов и узлов компьютерных систем» / Под ред. Ю.А. Гатчина, СПб:
НИУ ИТМО, 2013, вып.1, с.118-121.
24. Журкин И.Г., Шайтура С. В. Геоинформационные системы // М.: КУДИЦ-
ПРЕСС, 2009. – 272 с.
25. Кирсанова Ю.А., Богданов А.В., Уткин С.Б., Шек-Иовсепянц Р.А.
Управление вычислениями в цифровых бортовых управляющих
комплексах // Мир авионики, 2000, №4, с.15-18.
26. Кирсанова Ю.А., Коновалов П.В., Жаринов И.О., Костишин М.О.,
Виноградов П.С. Режим автоматизированного формирования и
отображения геоинформационных кадров в системах навигации
пилотируемых летательных аппаратов // Сборник трудов молодых ученых,
аспирантов и студентов научно-педагогической школы кафедры ПБКС
«Информационная безопасность, проектирование и технология элементов
 143

и узлов компьютерных систем» / Под ред. Ю.А. Гатчина, СПб:

Университет ИТМО, 2015, с.19-27.
27. Ключарев А.А., Матьяш В.А., Щекин С.В. Структуры и алгоритмы
обработки данных. Учебное пособие // СПб, 2004 – 172 с.
28. Коновалов П.В., Батова С.В., Благонравов С.А. Автоматизация процесса
создания таблиц конфигурации для операционных систем реального
времени // Гироскопия и навигация, 2014, №2, с.138.
29. Коновалов П.В. Особенности формата хранения метрических данных для
использования в бортовых системах картографической̆ информации //
Гироскопия и навигация, 2014, №2, с.124-125.
30. Коновалов П.В. Особенности формата хранения метрических данных для
использования в бортовых системах картографической информации //
Навигация и управление движением / Материалы XVI конференции
молодых ученых, СПб, ГНЦ РФ ОАО «Концерн «ЦНИИ Электроприбор»,
2014, с.249-253.
31. Коновалов П.В., Батова С.В., Благонравов С.А. Автоматизированная среда
конфигурирования программного обеспечения операционных систем
реального времени в изделиях авионики // Сборник докладов XХ
Международной научно-практической конференции студентов,
аспирантов и молодых ученых «Современные техника и технологии» (14-
18 апреля 2014 г.), Томск: Изд-во Томского политехнического
университета, 2014, т.1, с.107-108.
32. Коновалов П.В., Уткин С. Б., Батова С. В. Комплекс программного
обеспечения, используемого в процессе тестирования и эксплуатации
вычислительных изделий авионики на основе интерфейса RS-232 //
Сборник трудов XIII Международной научно-практической конференции
им. А. Ф. Турпугова «Информационные технологии и математическое
моделирование» (г. Анжеро-Судженск, 20-22 ноября 2014 г.), Томск: Изд-
во Томского политехнического университета, 2014, ч.1, с.171-176.
 144

33. Коновалов П.В., Уткин С. Б., Батова С. В. Комплекс программного

обеспечения, используемого в процессе тестирования и эксплуатации
вычислительных изделий авионики на основе интерфейса RS-232 //
Сборник трудов XIII Международной научно-практической конференции
им. А. Ф. Турпугова «Информационные технологии и математическое
моделирование» (г. Анжеро-Судженск, 20-22 ноября 2014 г.), Томск: Изд-
во Томского политехнического университета, 2014, ч.1, с.171-176.
34. Копорский Н.С., Видин Б.В., Жаринов И.О. Бортовые средства
отображения информации современных пилотируемых летательных
аппаратов // В кн. Современные технологии / Под ред. С.А. Козлова, В.Л.
Ткалич, СПб: СПбГУ ИТМО, 2004, с.154-165.
35. Копорский Н.С., Видин Б.В., Жаринов И.О. Организация вычислительного
процесса в многомашинном бортовом вычислительном комплексе //
Известия вузов. Приборостроение, 2006, Т. 49, №6, с.41-50.
36. Копорский Н.С., Видин Б.В., Жаринов И.О. Система бортовой
картографической информации пилотируемых летательных аппаратов.
Основные принципы построения // Сб. трудов 10-ой международной
конференции «Теория и технология программирования и защиты
информации», СПб: СПбГУ ИТМО, 2006, с.18-23.
37. Костишин М.О., Шукалов А.В., Жаринов И.О., Коновалов П.В.
Автоматизация конфигурирования геоинформационных данных авионики
на рабочем месте оператора // Сборник тезисов докладов Московской
молодежной научно-практической конференции «Инновации в авиации и
космонавтике-2014» (МАИ, 22-24 апреля 2014 г.), Москва: Изд-во ООО
«Принт-салон», 2014, с.42-43
38. Костишин М.О., Жаринов И.О., Книга Е.В., Шукалов А.В., Богданов А.В.,
Коновалов П.В. Опыт применения мультипроцессора для формирования
видеопотока изображения геоинформационных данных в авионике //
Сборник трудов XVIII Всероссийской научно-практической конференции
«Научное творчество молодежи. Математика. Информатика» (г. Анжеро-
 145

Судженск, 24-25 апреля 2014 г.), Томск: Изд-во Томского университета,

2014, ч.1, с.147-152.
39. Костишин М.О., Жаринов И.О., Жаринов О.О. Оценка точности
визуализации местоположения объекта в геоинформационных системах и
системах индикации навигационных комплексов пилотируемых
летательных аппаратов // Научно-технический вестник информационных
технологий, механики и оптики. – 2014. –№ 1. – с. 130–137
40. Кофман М.М., Парамонов П.П., Сабо Ю.И. Методология проектирования
перспективных авиационных комплексов бортового оборудования //
Авиакосмическое приборостроение, 2003, №5, с.2-8.
41. Кубенский А.А. Структуры и алгоритмы обработки данных. Учебное
пособие // СПб, «БХВ-Петербург», 2004 – 466 с.
42. Парамонов П.П. Организация разработки и производства аппаратуры для
авиационных бортовых вычислительных комплексов автоматизации
управления ЛА // Датчики и системы, 2002, №11, с.64-66.
43. Парамонов П.П., Видин Б.В., Меженин А.В., Тозик В.Т. Методы
представления сложных полигональных моделей в графических системах,
работающих в реальном масштабе времени // Известия вузов.
Приборостроение, 2006, Т.49, №6, с.17-19.
44. Парамонов П.П., Видин Б.В., Сабо Ю.И., Жаринов И.О. Лингвистические
структуры в задачах отображения пилотажно-навигационной информации
на борту современного пилотируемого летательного аппарата // Научно-
технический вестник Санкт-Петербургского государственного
университета информационных технологий, механики и оптики, 2004,
вып.14, с.245-248.
45. Парамонов, П.П., Видин Б. В., Стрижевский В.С. Управление
конфигурациями в сертифицируемых программных разработках //
Мехатроника, автоматизация, управление / приложение «Управление и
информатика в авиакосмических системах», 2006, № 12. - С. 8 – 11.
 146

46. Парамонов П.П., Гатчин Ю.А., Жаринов И.О., Жаринов О.О., Дейко М.С.
Принципы построения отраслевой системы автоматизированного
проектирования в авиационном приборостроении // Научно-технический
вестник информационных технологий, механики и оптики, 2012, №6 (82),
с.111–117.
47. Парамонов П.П., Ильченко Ю.А., Жаринов И.О. Теория и практика
статистического анализа картографических изображений в системах
навигации пилотируемых летательных аппаратов // Датчики и системы,
2001, №8, с.15-19.
48. Парамонов П.П., Ильченко Ю.А., Жаринов И.О., Тарасов П.Ю.
Структурный анализ и синтез графических изображений на экранах
современных средств бортовой индикации на плоских
жидкокристаллических панелях // Авиакосмическое приборостроение,
2004, №5, с.50-57.
49. Парамонов П.П., Жаринов И.О. Интегрированные бортовые
вычислительные системы: обзор современного состояния и анализ
перспектив развития в авиационном приборостроении // Научно-
технический вестник информационных технологий, механики и оптики. –
2013, – № 2 (84). – c. 1–17
50. Парамонов П.П., Коновалов П.В., Жаринов И.О., Кирсанова Ю.А., Уткин
С.Б. Реализация структуры данных, используемых при формировании
индикационного кадра в бортовых системах картографической
информации // Научно-Технический Вестник Информационных
технологий, механики и оптики. - Санкт-Петербург, 2013. - Вып. 2(84). - С.
165-167.
51. Парамонов П.П., Коновалов П.В., Жаринов И.О., Кирсанова Ю.А., Уткин
С.Б. Особенности использования метрических данных при формировании
индикационного кадра в бортовых системах картографической
информации // Сборник трудов молодых ученых, аспирантов и студентов
научно-педагогической школы кафедры ПБКС «Информационная
 147

безопасность, проектирование и технология элементов и узлов

компьютерных систем» / Под ред. Ю.А. Гатчина, СПб: НИУ ИТМО, 2013,
вып.2, с.115-120.
52. Парамонов П.П., Коновалов П.В., Уткин С.Б., Виноградов П.С., Батова
С.В., Благонравов С.А. Современные направления развития бортовых
цифровых картографических систем для авиационного применения //
Сборник трудов молодых ученых, аспирантов и студентов научно-
педагогической школы кафедры ПБКС «Информационная безопасность,
проектирование и технология элементов и узлов компьютерных систем» /
Под ред. Ю.А. Гатчина, СПб: Университет ИТМО, 2015, с.47-55.
53. Парамонов П.П., Коновалов П.В., Уткин С.Б., Батова С.В., Суслов В.Д.
Особенности переноса операционной системы реального времени на
аппаратное обеспечение авионики, выполненное на основе
микропроцессоров ARM-архитектуры // Сборник трудов молодых ученых,
аспирантов и студентов научно-педагогической школы кафедры ПБКС
«Информационная безопасность, проектирование и технология элементов
и узлов компьютерных систем» / Под ред. Ю.А. Гатчина, СПб:
Университет ИТМО, 2015, с.56-60.
54. Парамонов П.П., Костишин М.О., Жаринов И.О. и др. Принцип
формирования и отображения массива геоинформационных данных на
экран средств бортовой индикации // Научно-технический вестник
информационных технологий, механики и оптики. – 2013. – № 6. – С. 136–
142
55. Парамонов П.П., Копорский Н.С., Видин Б.В., Жаринов И.О.
Многофункциональные индикаторы на плоских жидкокристаллических
панелях: наукоемкие аппаратно-программные решения // Научно-
технический вестник Санкт-Петербургского государственного
университета информационных технологий, механики и оптики, 2004,
вып.14, с.238-244
 148

56. Петренко А.К, Буздалов Д.В., Зеленов С.В., Корныхин Е.В., Страх А.В.,
Угненко А.А., Хорошилов А.В. Инструментальные средства
проектирования систем интегрированной модульной авионики // Труды
института системного программирования РАН, 2014, Выпуск №1 / том 26,
с.201-230.
57. Прэтт У. Цифровая обработка изображений. // Москва: Изд-во Мир, 1982–
478 c.
58. Розенфельд А. Распознавание и обработка изображений с помощью
вычислительных машин. // Москва: Изд-во Мир, 1972 – 232 c.
59. Самойлова Л.М. Средства разработки программного обеспечения для
встраиваемых 32-разрядных систем // Современная электроника, 2007, №4,
с.66-69.
60. Сарайский Ю.Н. Геоинформационные основы навигации. Учебное
пособие // СПб.: 2010. – 245 с.
61. Синицин, С.В. Управление изменениями в программных проектах
бортовых систем. // Авиакосмическое приборостроение, 2003, №2. – С. 12
– 16.
62. Хопкрофт Д., Мотвани Р., Ульман Д. Введение в теорию автоматов, языков
и вычислений // Издательский дом «Вильямс», 2002г.
63. Черный М.А., Кораблин В.И. Самолетовождение // М. «Транспорт»: 1973.
– 369 с.
64. Уткин С.Б., Батова С.В., Благонравов С.А., Коновалов П.В., Жаринов И.О.
Автоматизация создания таблицы конфигурации программного
обеспечения систем реального времени в авионике // Программирование,
2015, №4, с.40-46.
65. Батова С.В, Благонравов С.А., Уткин С. Б., Коновалов П.В. Опыт
применения технологии эмуляции процессов при разработке компонентов
программного // Программная инженерия, 2015, №8, c.18-25.
 149

66. Aitken S., Michel S. Who Contrives the Real in GIS? Geographic Information,
Planning and Critical Theory. // Cartography and geographic information
systems 22(1), 1995, pp. 17-29.
67. Bernstein M.M., Chulsoo K. AOS: an avionics operating system for multi-level
secure real-time environments // 10th Computer Security Applications
Conference. Proceedings, 1994. – pp. 236-245.
68. Bieber P., Boniol F., Boyer M., Noulard E., Pagetty c. New Challenges for
Future Avionic Architectures // AerospaceLab Journal 4, 2012, pp. 1-10.
69. Burrough P.A., Mcdonnell R.A. Principles of Geographical Information
Systems. // New York: oxford university press, 1998. – 219 p.
70. Davis B. GIS: A Visual Approach. // Onward Press, Thomson Learning, Canada,
1996. – 324 p.
71. Eveleens René L.C. Open Systems Integrated Modular Avionics – The Real
Thing // Mission Systems Engineering. – Educational Notes RTO-EN-SCI-176,
2006. – Neuilly-sur-Seine, November, France: RTO. – Paper 2. – P. 2-1 – 2-22.
72. Helfrick A. Principles of Avionics // Avionics Communications Inc., 2004. –
414 p.
73. Kniga E., Shukalov A., Paramonov P. Organization of onboard digital computer
system with reconfiguration // Communications in Computer and Information
Science, Vol.487, 2014, pp.197-204, DOI: 10.1007/978-3-319-13671-4_24.
74. Kniga E.V., Zharinov I.O. Analysis and algorithms of the control in advanced
digital avionics systems // Automation & Control: Proceedings of the
International Conference of Young Scientists «ISCAC-2013» (21-22 November,
2013), Saint Petersburg, National Research University Saint-Petersburg State
Polytechnical University, 2013, рр.28-32.
75. Konovalov P., Batova S., Utkin S., Blagonravov S. Software Complex Used for
Designing, Testing and Maintenance of Computing Products for Avionics //
Proceeding of International Conference on Mechanical Engineering,
Automation and Control Systems (16-18 October, 2014, Tomsk Polytechnic
University), 2014, pp.1-3, DOI: 10.1109/MEACS.2014.6986848.
 150

76. Utkin S.B., Batova S.V., Blagonravov S.A., Konovalov P.V., Zharinov I.O.
Automated construction of software configuration tables for real-time systems
in avionics // Programming and Computer Software, 2015, vol.41, №4, pp.219-
223, DOI: 10.1134/S0361768815040076.
77. Kostishin M.O., Zharinov I.O. Precision characteristics of the positioning of
objects in aircraft geoinformation systems // Automation & Control:
Proceedings of the International Conference of Young Scientists «ISCAC-2013»
(21-22 November, 2013), Saint Petersburg, National Research University Saint-
Petersburg State Polytechnical University, 2013, рр.92-96.
78. MacEachren A. M., Taylor D.R.F. Visualization in Modern Cartography. //
Modern Cartography. Pergamon, 1994. – 286 p.
79. Moir I., Jukes M., Seabridge A. Civil avionic systems // Aptara Inc., New Delhi,
India, 2013. – 553 p.
80. Moore J., Spitzer, C.R. Advanced distributed architectures // CRC Press, Boca
Raton, 2001. – pp. 33-1–33-12.
81. Pizzica S. An Integrate Approach to Robust Avionics Systems Design // 21st
Digital Avionics Systems Conference. Proceedings, Volume 1, 2002. – pp.4D1-
1 – 4D1-10.
82. Roark C., Kiczuk B. Open System Avionics Architectures // Aerospace and
Electronic Systems Magazine, IEEE, Volume 10, Issue 9, 1995. – pp. 18-22.
83. Sherry L., Feary M. Task Design and Verification Testing for Certification of
Avionics Equipment // 23rd Digital Avionics Systems Conference. Proceedings,
Volume 2, 2004. – pp.10.A.3 – 101-10.
84. Spitzer C.R. Digital Avionics Systems: Principles and Practice // Blackburn
Press, 2000. – 277 p.