Содержание к диссертации
Введение
ГЛАВА 1. Анализ принципов построения картографических изображений на экране бортовых систем индикации 14
1.1 Обзор методов и средств генерации геоинформационных ресурсов. 14
1.1.1 Основные виды картографических изображений 14
1.1.2 Оперативное геоинформационное картографирование 18
1.2 Виды геоинформационных ресурсов. Принципы декомпозиции картографических изображений 20
1.2.1 Модели организации пространственных данных 22
1.2.2 Принципы организации информации в геоинформационных системах 1.3 Роль и место бортовых систем картографической информации в составе авиационного комплекса. Режимы работы систем отображения картографической информации 27
1.4 Обзор систем автоматизированной генерации геоинформационных ресурсов. Постановка задачи автоматизации процессов разработки бортовой системы картографической информации 1.4.1 Автоматизация подготовки геоинформационных ресурсов 33
1.4.2 Задача автоматизации разработки и отладки бортовой системы картографической информации 39
1.5 Выводы 41
ГЛАВА 2. Способы повышения качества проектирования бортовых систем картографической информации 43
2.1 Автоматизированное рабочее место разработчика бортовых систем картографической информации 43
2.1.1 Задачи автоматизации проектирования БСКИ 43
2.1.2 Состав рабочего места разработчика и назначение основных компонентов 44
2.2 Унифицированный алгоритм автоматизированного формирования индикационных кадров 47
2.2.1 Анализ сложности и эффективности алгоритмов 47
2.2.2 Алгоритм автоматизации формирования индикационных кадров
2.3 Оптимизированная структура входных данных для обеспечения динамических характеристик доступа к геоинформационным ресурсам 59
2.4 Особенности программирования бортовой системы картографической информации
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. Автоматизированная система проектирования бортовых систем картографической информации 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 Перспективы развития средств эмуляции аппаратного обеспечения 127
4.3 Методы автоматизации процесса тестирования бортовых систем
картографической информации 129
4.3.1 Автоматизация процесса тестирования БСКИ 129
4.3.1 Автоматизированная проверка результатов тестирования 131
4.4 Выводы 134
Заключение 136
Список литературы
- Виды геоинформационных ресурсов. Принципы декомпозиции картографических изображений
- Задачи автоматизации проектирования БСКИ
- Оптимизированная структура входных данных для обеспечения динамических характеристик доступа к геоинформационным ресурсам
- Использование принципа эмуляции аппаратного обеспечения в системе автоматизированного проектирования
Виды геоинформационных ресурсов. Принципы декомпозиции картографических изображений
Картографическое изображение представляет собой условное отображение поверхности Земли в уменьшенном виде, перенесенное на плоскость [2, 3]. В авиации картографические изображения играют особую роль, поскольку являются основным ориентиром для навигации в самолетовождении. Осуществление перелетов без использования карт не представляется возможным. Сначала для нужд авиации использовались обычные топографические карты местности, однако они быстро выявили ряд недостатков при их применении для решения задач, возникающих в процессе самолетовождения. В результате стала очевидной необходимость разработки специальных карт для использования в авиации. Авиационная карта – карта, снабжающая экипаж необходимыми данными для подготовки и осуществления перелетов. По назначению авиационные карты можно разделить на полетные, бортовые и карты специального назначения [60]. Полетные карты применяются при навигации по маршрутам и трассам в районе полетов. С помощью бортовых карт и данных, получаемых от радиотехнических и астрономических средств, определяется текущее местоположение самолета во время перелета. В специальных картах содержится дополнительная информация, позволяющая повысить точность навигации. К специальным картам относятся: карты магнитных склонений, карты часовых поясов, бортовые небесные карты и др. Карты используются на всех этапах, как при подготовке, так и при проведении полета. Основные цели использования карт при подготовке: прокладка, изучение и корректировка маршрута полета самолета; определение географических координат узловых точек маршрута; измерение путевых углов и расстояний между узловыми точками; изучение рельефа местности и положения высотных строений, находящихся в районе полета. Во время совершения перелета необходимость использования карт возрастает. Решение следующих задач требует использования изображений местности: проведение визуальной и радиолокационной ориентировки; контроль над отклонениями от маршрута, корректировка отклонений и прокладка линий движения; определение навигационных ориентиров.
У каждой из карт, используемых в авиации, отличается содержимое. Содержанием или нагрузкой карты называется степень отображения на ней различных топографических элементов местности. При составлении карты играют роль множество параметров, определяющих ее назначение, и, в зависимости от конечной цели, выбираются масштаб и набор элементов местности, подлежащих отображению.
На первый план авиационных карт чаще всего выносятся гидрографические объекты (реки, каналы, водохранилища, озера, моря и т. п.), поскольку они являются надежными ориентирами [60]. Так же для повышения точности визуального ориентирования наносятся: рельеф подстилающей поверхности, дорожные сети, высотные объекты, населенные пункты и др. Для навигации в процессе проведения полета так же необходимо внести в содержимое карты места пролегания часто используемых воздушных маршрутов и иную информацию, формирующую у наблюдателя представление о загруженности воздушных трасс. Нанесение на карты топографических элементов осуществляется с помощью условных знаков, которые делятся на несколько категорий: масштабные условные знаки – для отображения элементов местности, которые можно выразить в текущем масштабе карты: моря, крупные населенные пункты и т. п.; внемасштабные условные знаки – для обозначения топографических элементов слишком мелких для представления в используемом масштабе: вышки связи, заводские трубы, мостовые опоры и т. п.; линейные условные знаки – для нанесения объектов, не обладающих достаточной шириной: реки, дорожные сети, газопроводы и т. п. Обычно линейные знаки используются вне масштаба и дают обозначение только длине ориентиров; пояснительные условные знаки – для дополнительной информации об объектах местности. Обычно представляют собой надписи и цифры. Обозначают высоту значимых точек рельефа, названия объектов местности и т. п. Многие задачи, возникающие при навигации, требуют хорошего представления о рельефе местности. Для наглядного представления рельефа местности на картах используются различные методы [20]: метод горизонталей; метод отмывки; гипсометрический метод; комбинированные метод.
Горизонталью называется линия, которая соединяет на отображении местности точки с одинаковой высотой. Образующиеся замкнутые концентрические линии дают представление о перепадах высот. Расстояние между двумя соседними горизонталями дает представление о том, насколько резко изменяется высота, – чем ближе линии друг к другу, тем больше крутизна склона. При использовании способа «отмывки» рельеф отображается оттенением неровностей поверхности. Результирующее изображение является более наглядным и дает возможность с легкостью получить представление о местности и определить положение основных ориентиров. Недостатками способа являются отсутствие возможностей точного определения крутизны перепадов и значений высот отдельных точек.
Гипсометрический способ представляет рельеф с помощью заливки областей определенным цветом в зависимости от их высоты. Таким образом формируется изображение, дающее наглядное представление об изменениях рельефа и предоставляющее возможность точного определения высоты в нужных точках.
В комбинированных способах сочетаются несколько из описанных выше, при этом происходит компенсирование недостатков и, в результате, изображение несет повышенную информационную нагрузку в наиболее удобном для зрительного восприятия виде.
С развитием техники появилась возможность хранения карт в электронном виде и возможность вывода карт в виде изображения на экране в кабине летательного аппарата [70]. Цифровые карты обладают рядом преимуществ перед бумажными: повышенная точность представления координат; возможность оперативного изменения масштаба; возможность динамического изменения информационной нагрузки. Возможно осуществлять хранение графических отображений местности в растровом и векторном виде. У обоих способов имеются свои недостатки и преимущества. В случае с векторными изображениями существенно уменьшаются затраты ресурсов на хранение и обработку данных. Помимо этого, векторные карты:
Задачи автоматизации проектирования БСКИ
Следующим свою работу выполняет модуль ядра операционной системы. Она реализует критические функции управления системными задачами и приложениями, планирования, защиты памяти, обработки исключений и прерываний. Кроме того, для повышения быстродействия системы почти вся функциональность каналов обмена данными между приложениями (и между системными задачами) реализована в ядре. Модуль ядра ОС выполняет следующие функции:
Далее вызывается менеджер модуля. Его задачей является инициализация системы, после чего производится обработка событий, генерируемых при возникновении аварийных ситуаций во время выполнения других компонентов системы.
Модуль операционной системы раздела отвечает за выполнение приложения в разделе и предоставление приложению сервисов интерфейса APEX. В каждом разделе выполняется свой экземпляр данного модуля, что обеспечивает независимое выполнение приложений.
Потоки, выполняющие код приложения некоторого раздела, и потоки, реализующие код операционной системы раздела, могут выполняться процессором только тогда, когда этот раздел является активным, то есть в течении времени, отведенного разделу во временной диаграмме разделов.
Для адаптации системы к конкретному вычислительному модулю предназначен отдельный программный модуль, традиционно называемый пакетом поддержки модуля. Функции, входящие в состав этого программного модуля, выполняют настройку аппаратуры процессора, системного и сторожевого таймеров, а также обеспечивают ОСРВ необходимой информацией о доступной физической памяти, особенностях системы прерываний и расположении таблицы конфигурации системы в физической памяти. Пакет поддержки модуля не входит в состав, но компилируется вместе с кодом ОСРВ.
Для работы целевого программного обеспечения в составе БСКИ под управлением операционной системы требуется создать три стыковочных модуля: старт-файл, файл прерываний и файл конфигурации. Допускается объединять файлы или «делить» их в зависимости от используемого языка программирования.
Для работы с сервисными процедурами ОСРВ, необходимо в исходных модулях целевого программного обеспечения подключить файлы-спецификации, содержащие ссылки на процедуры операционной системы и описания основных констант, необходимых системе для работы.
В старт-файле должны содержаться две процедуры: процедура инициализации и процедура обработки серьезных системных ошибок. Первая процедура не имеет параметров и входных данных. Процедура должна быть написана на языке ассемблера и включать в себя: инициализацию системных регистров модуля вычислителя; инициализацию аппаратуры модуля вычислителя (если требуется); инициализацию секций данных и переменных, необходимая для работы с процедурами, написанными на языке С; установку глобального указателя и указателя стека; перепись процедуры начальной обработки прерываний в ОЗУ; инициализацию системного таймера (если требуется) и его запуск; установку некоторых системных переменных (необходимая часть для работы системы, в ней идет установка системного стека и занесения в переменную первого доступного адреса оперативной памяти); вызов процедуры инициализации управляющей программы.
Вторая процедура вызывается в случае возникновения системных ошибок ОСРВ, при которых становится невозможным дальнейшее выполнение приложения. Операционная система передает в качестве параметра функции код ошибки. В процедуре должны выполняться обработка переданных ошибок и передача управления в соответствующее обработке место. Возврата в систему быть не должно.
Процедура может быть написана на языке С или на ассемблере. Написание функции подразумевает подключения файла-спецификации, содержащего описания основных констант для работы системы и кодов системных ошибок.
Файл прерываний должен состоять из небольшой процедуры начальной обработки прерываний, которая содержит переход на основной обработчик всех прерываний процессора, и сам обработчик прерываний.
Основной обработчик прерываний должен содержать анализ и обработку всех видов прерываний. Обработка должна производится с учетом аппаратной структуры модуля вычислителя и всего блока в целом. Для обеспечения связи с системой в обработчике системного таймера должна вызываться процедура прерывания таймера. Данный вызов должен производиться после пользовательской обработки этого прерывания.
Для корректной обработки прерываний необходимо вызвать процедуру сохранения контекста системы. Для выхода из процедуры обработки прерывания, с восстановлением контекста, необходимо перейти по адресу процедуры восстановления контекста.
Файл конфигурации системы определяет рабочие характеристики системы. Содержимое этого файла используется подпрограммами инициализации модуля, для настройки начальных условий выполнения. В этом файле содержатся все определения: доступная память, количество ячеек памяти, очередей, групп флажков событий, семафоров и информация о задачах.
При создании данного файла, необходимо подключить файлы-спецификации, один из которых содержит описания структур конфигурации, а второй – описания основных констант системы.
Конфигурация в целом определяется следующим набором структур: Определения доступной памяти. Операционная система должна знать последний адрес памяти, используемый компоновщиком (или первый свободный адрес), и последний адрес памяти, доступный в аппаратных средствах. Определения ячеек памяти. Операционная система обеспечивает управление памятью постоянной длины. Память постоянной длины часто называют «порциями» памяти. Содержимое структуры определяет «порции» памяти системы. Определения очередей. Операционная система обеспечивает связь задач через набор предопределенных очередей. Содержимое структуры определяет очереди системы. Размер системного стека. Операционная система должна распределить память для стека системы в подпрограмме инициализации. Желательный размер стека передается в переменной типа беззнакового целого.
Оптимизированная структура входных данных для обеспечения динамических характеристик доступа к геоинформационным ресурсам
Универсальный протокол обмена может быть применен для обмена между любыми устройствами по интерфейсу. Данным протоколом определяются наиболее общие функции и форматы обмена информацией, используемые в устройствах, поддерживающих интерфейс. При поддержке такими устройствами данного протокола возможно использование уже написанного и отлаженного программного обеспечения, реализующего данный протокол. Протокол определяет информационный обмен между двумя устройствами: главным (MASTER) и подчиненным (SLAVE). Любой обмен инициируется главным устройством, которое посылает код команды обмена и затем посылает и/или принимает данные в соответствии с форматом данной команды. Все команды разбиты на группы. Любое устройство, поддерживающее данный протокол, обязано реализовать команды, относящиеся к группе общих команд. Реализация остальных групп команд не обязательна. Устройство MASTER может получить информацию о том, какие группы стандартных команд поддерживаются устройством SLAVE с помощью команды «Получить информацию об устройстве». Если подчиненное устройство заявляет, что оно поддерживает какую-либо группу стандартных команд, то оно должно реализовать все команды, входящие в эту группу. Если же подчиненное устройство не поддерживает какую-либо группу команд, то оно может реализовывать команды с кодами из этой группы как оно считает нужным. Таким образом, каждая конкретная пара устройств MASTER-SLAVE может реализовывать дополнительные необходимые в данном конкретном случае функции. Для стандартных групп команд определены стандартные коды подтверждений, которые подчиненное устройство может возвращать в ответ на команду главного. В протоколе определены следующие группы стандартных команд:
Общие функции. Эта группа команд предназначена для инициализации и управления информационным обменом между устройствами, поддерживающими данный протокол. Функции передачи данных. Команды этой группы предназначены для передачи больших блоков данных между устройствами. Команды, относящиеся к группе команд передачи данных фиксированной длины, требуют использования дополнительной команды установки размера буфера, после чего обмен происходит блоками заданного размера. Программирование FLASH по стандарту JEDEC. Команды этой группы предназначены для программирования FLASH в подчиненном устройстве в соответствии со стандартом JEDEC. Устройство, поддерживающее эту группу команд, обязано также поддерживать группу команд передачи данных. Чтение-запись одного байта. Команды этой группы предназначены для примитивного обмена байтовыми данными. Подчиненное устройство может интерпретировать адрес и данные по своему усмотрению. Чтение-запись данных по заданному адресу. Команды этой группы предназначены для обмена данными произвольных форматов. В каждой команде от главного устройства передаются размер адреса и данных, адрес, после чего происходит передача либо прием данных. Адрес и данные передаются младшими байтами вперед. Подчиненное устройство может интерпретировать адрес и данные по своему усмотрению. Циклические чтение-запись данных по заданному адресу. Команды этой группы предназначены для отладки подчиненного устройства и представляют собой команды чтения/записи данных по заданному адресу, повторяемых подчиненным устройством до приема байта завершения команды. Идентификация. Команда используется для запроса информации у подчиненного устройства. Размер адреса и данных, а также значение адреса определяют тип запрашиваемой информации. 3.4.3 Встроенное алгоритмическое обеспечение целевой платформы В состав встроенного программного обеспечения входят несколько компонентов, каждый из которых решает определенную задачу, взаимодействуя с интерфейсом через драйвер.
Загрузчик обеспечивает возможность загрузки файлов из ПК через интерфейс в целевой модуль и запись их в ОЗУ, ПЗУ или FLASH модуля. Также обеспечиваются функции стирания FLASH, вычисления контрольных сумм, проверки загруженных файлов.
Монитор представляет собой программу, предоставляющую пользователю возможность управления модулем через консольный терминал (ПК), подключенный по каналу. Пользователь может набирать в терминале символьные команды, которые передаются в модуль для выполнения. Результат выводится на экран терминала тоже в символьном виде.
Тестовый монитор обеспечивает программе, выполняемой на ПК, подключенном к модулю RISC процессора через интерфейс, доступ к ресурсам модуля процессора и внешней шины модуля процессора по протоколу USRP. Устройство, подключаемое к модулю процессора, является главным, модуль процессора – подчиненным. Тестовый монитор также позволяет программе на главном устройстве получать информацию о зарегистрированных в модуле RISC процессора прерываниях и устанавливать свой обработчик прерываний. Тестовый монитор также может содержать набор тестов, выполнение которых оптимизируется по командам, предаваемым через интерфейс. Результат выполнения тестов передается в ПК в определенном формате.
Специальное ПО используется для решения специфических задач, выполняемых модулем. Например, модуль может быть превращен в подыгрывающее устройство, входящее в состав стенда отладки и управляемое программой имитационного моделирования, выполняемой на ПК.
Использование принципа эмуляции аппаратного обеспечения в системе автоматизированного проектирования
Проведение тестирования программного обеспечения является неотъемлемой частью процесса проектирования [42, 80]. Выполнение этой процедуры в ручном режиме может потребовать повышенных временных затрат и, при длительном выполнении, не исключено возникновение ошибок, вызванных усталостью оператора. Использование специализированных программ, позволяющих автоматизировать прогон тестов и последующую проверку результатов тестирования позволяет в значительной мере минимизировать время выполнения процедуры, вместе с тем, снижая влияние человеческого фактора.
Выполнение программы проверки в рамках одного раздела ОСРВ требует загрузки в память аппаратного обеспечения БСКИ (либо его программной имитации) определенного набора компонентов данных: инициализатор выполняет подготовку имеющихся ресурсов к использованию и производит запуск низкоуровневого ПО; файл конфигурации определяет набор внутрисистемных ресурсов (портов без очереди, портов с очередью, досок объявлений и пр.), которые доступны в текущем контексте; ядро операционной системы после запуска передает управление стартовому процессу программы в составе БСКИ; исполняемый файл программы в стартовом процессе производит инициализацию необходимых для дальнейшей работы ресурсов и передает управление процессам, выполняющим конкретные прикладные задачи.
Для проведения тестирования БСКИ в ручном режиме необходимо каждый раз производить загрузку указанных файлов, ожидать завершения выполнения программы, после чего просматривать сообщения, отправляемый в канал вывода, чтобы определить успешно ли выполнен тест. Таким образом, для прогона даже небольшого количества проверочных программ (несколько десятков), потребуется несколько часов монотонной работы пользователя. При этом наличие специализированного ПО, автоматизирующего процесс тестирования, не представляется возможным, поскольку существующие инструменты рассчитаны на работу с программами и данными, разрабатываемыми для стационарных пользовательских систем.
Основными функциями, которые требуются от инструментальных средств автоматизации тестирования, являются: последовательная загрузка в память изделия исполняемых файлов, необходимых для выполнения каждого отдельного теста; ожидание завершения работы проверочной программы и определение успешности по заданным критериям; запись сообщений, передаваемых в процессе выполнения по каналу связи.
Для того, чтобы иметь возможность реализовать первые две из указанных функций, программе проверки необходим набор записей в специальном формате, содержащих пути загружаемых файлов и критерий прекращения выполнения текущего теста. Как только одно из условий завершения становится истинным, работа системы останавливается и производятся сброс настроек и загрузка следующего набора исполняемых файлов. При этом, в зависимости от проверяемых функций, причиной для прекращения работы может служить не только сообщение об успешном/неуспешном выполнении программы, но и таймаут после ожидаемой критической ошибки системы.
Запись логов достигается простым созданием потока, записывающего в файл всю информацию, получаемую по каналу вывода. Пример окна предлагаемого решения, выполняющего автоматизацию тестирования в среде эмуляции приведен на рис. 4.9. В левой части расположен список тестов для загрузки, позволяющий определить состав текущего набора проверок из имеющихся. Дополнительно в списке приводится информация о предполагаемых таймаутах выполнения (по внутреннему времени эмулируемой системы и внешнему(реальному) времени) и критерии завершения. Выбрав интересующую строчку можно вызвать дополнительный диалог (справа), позволяющий редактировать интересующие значения в интерактивном режиме. После настройки всех необходимых параметров выполняется запуск текущего прогона, во время которого возможно выполнение других работ.